amazon web services big-ip セットアップガイドmultiaz...2016/09/21 · 4 1. はじめに...

2016/9

Amazon Web Services BIG-IPセットアップガイド～マルチ AZ冗長化 & Auto Scaling～

F5 Networks Japan V1.0

Ⅹ

目次

1. はじめに ................................................................................................................................................................. 4

2. スタンドアローン構成 (BYOL) ................................................................................................................................. 5

2.1. VPC設定 ........................................................................................................................................................ 6

VPCウィザード ......................................................................................................................................... 6

インターネットゲートウェイ ......................................................................................................................... 7

サブネットの追加 ...................................................................................................................................... 7

ルートテーブルの設定............................................................................................................................... 9

Elastic IPの発行 ................................................................................................................................... 12

2.2. EC2で BIG-IP インスタンスを起動 ................................................................................................................. 13

AWS Marketplaceからインスタンスを生成 ............................................................................................. 13

管理インタフェースへの EIPの割り当て .................................................................................................. 17

BIG-IPへの SSHログイン(PuTTY利用) ................................................................................................ 18

Virtual Server用のセカンダリプライベート IPアドレス設定と EIPの割り当て ........................................... 21

2.3. EC2でWordPress インスタンスを起動 .......................................................................................................... 23


［参考］WordPressへの SSHログイン (PuTTY と Pagentの利用) ........................................................ 26

2.4. BIG-IPの設定 ............................................................................................................................................... 28

WebUIパスワードの設定 ....................................................................................................................... 28

ウィザードによる初期設定 ....................................................................................................................... 28

ネットワーク設定 ..................................................................................................................................... 32

サーバロードバランシングの設定 ............................................................................................................ 34

サーバロードバランシグの動作確認 ........................................................................................................ 36

3. マルチ AZでの冗長化 .......................................................................................................................................... 37

3.1. VPCの設定追加 ........................................................................................................................................... 38

AZ2のサブネット追加 ............................................................................................................................. 38

ルートテーブルの設定............................................................................................................................. 39

3.2. EC2で AZ2用の BIG-IP インスタンスを起動 ................................................................................................. 41


Virtual Server用セカンダリプライベート IPアドレスの設定 ...................................................................... 42

Elastic IPの発行 ................................................................................................................................... 43

3.3. セキュリティグループの変更 ........................................................................................................................... 45

3.4. IAMの設定 ................................................................................................................................................... 46

3.5. AZ2の BIG-IPの設定 ................................................................................................................................... 48

WebUIパスワードの設定 ....................................................................................................................... 48

ウィザードによる初期設定 ....................................................................................................................... 48

ネットワーク設定 ..................................................................................................................................... 49

Device Managementの設定 ................................................................................................................. 51

3.6. AZ1の BIG-IP設定....................................................................................................................................... 52

Platform設定の変更 .............................................................................................................................. 52

Self-IP設定の変更 ................................................................................................................................ 53

Default Route設定の変更 ..................................................................................................................... 53

冗長化用の設定 ..................................................................................................................................... 55

Virtual Serverの追加設定 ..................................................................................................................... 59

マルチ AZ冗長化用 iAppテンプレートによる設定 ................................................................................... 63

3.7. マルチ AZ間冗長の切替り動作確認 .............................................................................................................. 68

クライアント PCからのアクセス確認 ........................................................................................................ 68

Virtual Serverに割り当てられた Elastic IPの確認 ................................................................................. 68

AZ間の切替え ....................................................................................................................................... 69

クライアント PCからのアクセス確認 ........................................................................................................ 70

［参考］Debugログの確認 ...................................................................................................................... 70

3.8. マルチ AZ構成での Route Management設定 .............................................................................................. 71

BIG-IPの設定変更 ................................................................................................................................ 72

AWS EC2ネットワークインターフェイスの「送信元/送信先の変更チェック」の無効化 ................................ 73

VPC Routerのルート設定変更 ............................................................................................................... 74

Ⅹ

iAppの Route Management設定 .......................................................................................................... 77

マルチ AZ間冗長の切替り動作確認(Route Managementあり).............................................................. 78 4. Auto Scaling ........................................................................................................................................................ 79

4.1. Webサーバの Auto Scaling .......................................................................................................................... 79

WordPressのカスタム AMI .................................................................................................................... 80

Auto Scalingの起動設定 ....................................................................................................................... 81

Auto Scalingグループの作成................................................................................................................. 84

1-NICの BIG-IPの生成 ......................................................................................................................... 88

Webサーバの Auto Scaling動作確認 ................................................................................................... 99

4.2. BIG-IPの Auto Scaling ............................................................................................................................... 102

ELBの設定 .......................................................................................................................................... 103

BIG-IPのWAFの設定 ........................................................................................................................ 107

CloudWatchのカスタムメトリックの設定 ................................................................................................ 113

カスタム AMI生成前の処理 .................................................................................................................. 114

BIP-WAFのカスタム AMI ..................................................................................................................... 115

カスタムメトリックを使った CloudWatchアラームの作成 ........................................................................ 116

Auto Scalingの起動設定 ..................................................................................................................... 119

Auto Scalingグループの作成............................................................................................................... 122

BIG-IPの Auto Scalingの動作確認 ..................................................................................................... 126

4.3. 複数の Virtual Server を持つ BIG-IPの Auto Scaling ................................................................................. 129

BIP-WAFの設定 .................................................................................................................................. 130

BIP-WAFのカスタム AMI ..................................................................................................................... 130

セキュリティグループの編集 .................................................................................................................. 131

ELB002の追加 .................................................................................................................................... 131

起動設定のコピーと編集 ....................................................................................................................... 132

Auto Scalingグループの編集............................................................................................................... 135

動作確認 .............................................................................................................................................. 136

5. 終わりに ............................................................................................................................................................. 137

4

1. はじめに

本ガイドでは、Amazon Web Services (以降、AWS) 上での BIG-IP設定方法についてご案内します。

AWSマーケットプレイスから BIG-IPを展開することで、AWS上においても BIG-IPが持つ高度な L4-7ロードバランシ

ング機能をご利用頂くことが可能になります。

マルチ AZでの BIG-IP冗長化構成も可能で、また Elastic Load Balancer (以降、ELB) と組み合わせることで、負荷状

況に応じて自動的にスケールアウトする、Auto Scalingにも対応しています。

以降、豊富なスクリーンショットを用いて、BIG-IPによるサーバロードバランシグおよび BIG-IPの冗長化構成を、ステッ

プ byステップで設定できる形でご紹介していきます。

5

2. スタンドアローン構成 (BYOL)

まず、BIG-IPを 1台だけ展開し、以下のネットワークを構成していきます。

リージョンは Tokyo を選択しています。

Availability Zoneは ap-northeast-1aを選択しています。

VPC：F5JP-VPCの CIDR ブロックは 10.0.0.0/16 とし、VPC内の各サブネットを以下の位置づけとして作成します。

BIP-mgt-1a： BIG-IP管理用サブネット

BIP-ext-1a: BIG-IPの外部サービス用(Virtual Server用)サブネット

BIP-int-1a: BIG-IPのロードバランシング対象のサーバ用サブネット

Webアプリケーションとして、AWSマーケットプレイスに用意されているWordPress を使うこととします。

BIG-IPは、ライセンスは持ち込み型 (BYOL: Bring Your Own License) とします。

後の章のマルチ AZでの冗長化構成の際にも、この章で設定した BIG-IPを利用します。

(よって少しだけ、マルチ AZ冗長化を意識した設定もこの章で行います。)

6

2.1. VPC設定

まず、Amazon Virtual Private Cloud (VPC) を設定します。

VPCウィザード

(1) AWSへのログイン後に表示されるマネージメントコンソールのポータル画面から、VPC を選択します。

(2) VPCウィザードの開始ボタンを押します。

(3) 本ガイドでは、「1個のパブリックサブネットを持つ VPC」を選択します。

(4) VPC名、アベイラビリティーゾーン、サブネット名、を指定します。

(5) OKを押します。

VPC内で利用する CIDRブロックを指定

任意の名称を入力

IP CIDRブロック内からサブネットを指定

Availability Zone を選択


7

インターネットゲートウェイ

ナビゲーションペイン(左側メニュー)で「インターネットゲートウェイ」を選択します。

VPCウィザードによって、インターネットゲートウェイ (インターネットでの出入り口となるコンポーネント。図中の Internet

Gateway) が自動的に生成されていることがわかります。(ここは確認のみです。)

サブネットの追加

ネットワーク構成に合わせるためには、あと 2つのサブネットの追加が必要です。

その追加手順を示します。

(1) 「VPCでフィルタリング：」プルダウンで、作成した VPC を選択します。

(2) ナビゲーションペインで「サブネット」を選択します。

VPCウィザードによって生成されたサブネット(BIP-mgt-1a)が 1つだけ存在しています。

「サブネットの作成」ボタンを押します。

作成した VPCを選択

8

(3) BIP-ext-1aサブネットを追加します。

(4) BIP-int-1aサブネットを追加します。

(5) 以下のように 3つのサブネットが生成されました。



AZを選択

サブネットを指定



AZを選択

サブネットを指定

9

ルートテーブルの設定

VPCウィザードによって、2つのルートテーブルが生成されています。

① VPC内のサブネットとインターネットゲートウェイのルート(0.0.0.0/0→igw-XXXX)を持つルートテーブル

② VPC内のサブネット(10.0.0.0/16)だけを持つルートテーブル

①のルートテーブルに関連付けらたサブネットだけが、インターネットとの通信が可能になります。

BIP-mgt-1aおよび BIP-ext-1aはそれぞれインターネットからのアクセスを必要とするので、①に関連付けます。

BIP-int-1aはインターネットからのアクセスはさせないサブネット＝プライベートサブネットとするので、②に関連付けま

す。

(1) ナビゲーションペインで「ルートテーブル」を選択します。

(2) 「ルート」タブ内にインターネットゲートウェイのルート (0.0.0.0/0→igw-XXXX) を持つ方のルートテーブルを選択しま

す。

(3) 「サブネットの関連付け」を見ると、VPCウィザードによって BIG-mgt-1aだけが関連付けられています。

「編集」ボタンを押します。

VPC内のルーティング

インターネットゲートウェイへのルート

BIG-IP管理用(BIP-mgt-1a)

10

(4) BIP-ext-1aの関連付けにチェックを入れて、「保存」ボタンを押します。

(5) これで、BIP-mgt-1aに加え、BIP-ext-1a もインターネットアクセスが可能になりました。

(6) もう一つのルートテーブルの「ルート」タブをクリックすると、VPC内のサブネット (10.0.0.0/16) のルートだけを持って

いることが分かります。

関連付けにチェックを入れる


11

(7) 「サブネットの関連付け」タブをクリックします。

注) このルートテーブルが「メイン」になっています。

このことで、もう一方のルートテーブルに割り当てられていないサブネットは自動的にこちらに属することになりますので

設定変更はしなくても結果は同じです(以下スクリーンショットにもその旨の記載があります)。

しかし、例えば何らかの作業でルートテーブルに変更があったとき、気づかないうちに自動的に他のルートテーブルに紐

付けられてしまう、ということは避けたいので、本ガイドではあえて明示的に BIP-int-1aを関連付けておくことにします。

「編集」ボタンを押します。

(8) BIP-int-1aの関連付けにチェックを入れて、「保存」ボタンを押します。

(9) BIP-int-1aがプライベートサブネットとして関連付けられました。

関連付けにチェックを入れる

12

Elastic IPの発行

BIG-IPの管理インタフェース用の IP と、Virtual Server用 IPの 2つのパブリック IP を Elastic IP として用意しておきま

す。

(1) ナビゲーションペインから「Elastic IP」を選択して表示された画面で、「新しいアドレスの割り当て」ボタンを押します。

(2) 「はい、割り当てる」ボタンを押します。

(3) もう一度同じ操作を繰り返し、EIPを 2つ用意します。

(4) 以下は、まだ関連付けが行われていない 2つの EIPが割り当てられた状態です。

13

2.2. EC2で BIG-IPインスタンスを起動

Amazon Elastic Compute Cloud (Amazon EC2)で BIG-IP インスタンスを起動するまでの手順を示します。

AWS Marketplaceからインスタンスを生成

(1) AWSへのログイン後に表示されるマネージメントコンソールのポータル画面から、EC2を選択します。

(2) 表示された画面で「インスタンスの作成」ボタンを押します。

(3) AWS Marketplaceを選択し、検索フォームに"BIG-IP"と入力して Enterキーを押します。

(4) 本ガイドでは、以下を選択しました。「選択」ボタンを押します。

(5) インスタンスタイプは、本ガイドでは「m4.2xlarge」を選択しました。

「次の手順：インスタンス詳細の設定」ボタンを押します。

BIG-IP と入力して、「Enter」キーを押す

BYOLの記載があるもの

12.1.0

14

(6) 作成した VPC：F5JP-VPC を選択し、サブネット：BIP-mgt-1aを選択します。

ネットワークインターフェイスで、eth0に BIG-IPの管理インタフェース用のプライベート IPアドレスを設定します。

「デバイスの追加」ボタンを押すと eth1が現れます。

サブネットは BIP-ext-1a を選択し、BIG-IPの外部インタフェース用のプライベート IPアドレスを設定します。

「次の手順：ストレージの追加」ボタンを押します。

～略～

(7) EBSのボリュームタイプで「汎用 SSD(GP2)」を選択します。

「次の手順：インスタンスのタグ付け」ボタンを押します。


BIP-mgt-1a を選択

無効化を選択

プライマリ IPにプライベートアドレスを入力

サブネットで「BIP-ext-1a」を選択

プライマリ IPにプライベートアドレスを入力

汎用 SSD(GP2)を選択

15

(8) Name タグに「BIP-VE001」と入力します。

「次の手順：セキュリティグループの設定」ボタンを押します。

(9) 「新しいセキュリティグループを生成する」が選択された状態になっているはずです。

セキュリティグループ名と説明はそのまま利用してもよいですが、短めのほうが分かりやすいと思います。

SSHに関しては、送信元 IPアドレスを限定しておくことが推奨されています。

HTTP(80)を追加し、「確認と作成」ボタンを押します。

(10) 一通り内容を確認し、「作成」ボタンを押します。

名称を入力

デフォルトで選択されている

名称および説明を入力(任意)

限定することを推奨

16

(11) 新しい Key Pair を作ります。

「新しいキーペアの作成」が選択されていることを確認してください。

キーペア名に名称(任意)を入力します。

「キーペアのダウンロード」ボタンを押します。

BIG-IPにアクセスするための PCにそのキーをダウンロードします。

キーがダウンロードできたら、「インスタンスの作成」ボタンを押します。

(12) 「インスタンスの表示」ボタンを押します。

(13) ステータスチェックが「2/2のチェックに合格しました」になれば、BIG-IP インスタンスの生成は完了です。

新しいキーペアの作成を選択

名称(任意)を入力

キーペアのダウンロードを押す

17

管理インタフェースへの EIPの割り当て

BIG-IPの管理用インタフェース(BIP-mgt-1aに接続されたインタフェース)に、EIPを割り当てます。

(1) ナビゲーションペインで「Elastic IP」を選択します。

何も割り当てられていない 2つの EIPのうち、1つを右クリックし、「アドレスの関連付け」を選択します。

(2) 「インスタンス」で、生成した BIG-IPを選択します。

「プライベート IPアドレス」で、マネージメント側(BIP-mgt-1a側＝10.0.0.201)の IPを選択します。

「関連付ける」ボタンを押します。

(3) BIG-IPの管理用インタフェースに EIPが割り当てられました。

アドレスの関連付けを選択

プルダウンから選択 or

インスタンス IDを入力。

IPを選択

18

BIG-IPへの SSHログイン(PuTTY利用)

BIG-IPの管理用インタフェースに割り当てた EIPに対して、SSHでログインします。

以降、PuTTYを使った場合の手順を示します。

2.2.3.1. キーの変換 (PuTTYgen)

インスタンス生成時に Key Pair を生成＆ダウンロードしましたが、その Keyは.pem形式なので、そのままでは PuTTY

では使えません。よって、PuTTYgen を使って、PuTTYで使える形式(.ppk)に変換します。

(1) PuTTYgen を起動します。

(例:Windowsの[スタート] メニュー→[すべてのプログラム]→[PuTTY]→[PuTTYgen] をクリック。)

(2) Parametersの Type of key to generate:で RSAが選択されていることを確認し、「Load」ボタンを押します。

(3) ファイルを選択するWindowで、「All Files (*.*)」を選択します。

(4) BIG-IP インスタンス生成時に生成したキーペアの.pem ファイル(例：F5J-AWS-key.pem)を選択し、「開く」ボタンを押

します。このことで、PuTTY が使用できる形式(.ppk)に変換されます。

(5) [Save private key] ボタンを押して、その変換後のキーを保存します。

(パスフレーズなしでキーを保存することに関する警告が表示されますが、[Yes]ボタンを押します。)

19

2.2.3.2. Pagentの利用

Pagentに、変換したキー(.ppk)を登録しておくことで、SSHログインの際のキー指定を省略できます。

(1) Pagentを起動します。

(例:Windowsの[スタート] メニュー→[すべてのプログラム] → [PuTTY] → [Pagent] をクリック。)

(2) 「Add Key」ボタンを押します。

(3) ファイルを選択するWindowで、先ほど「.pem」から「.ppk」へ変換したファイルを選択し、「開く」ボタンを押します。

以下のように、キーが追加されます。

2.2.3.3. PuTTYでの SSHログイン

(1) PuTTYを起動します。

(2) Host Name (or IP address)に、BIG-IPの管理インタフェースに割当てた EIP を指定して、「Open」ボタンを押しま

す。

BIG-IPの管理インタフェースの EIP

20

(3) "login as:"と表示されます。

ユーザ名：adminを入力するだけで、キーを指定することなくログインできます。

(4) 確認のみです。

"list net interface"と入力します。

管理用(BIP-mgt-1a用)と外部アクセス用(BIP-ext-1a)の 2つのインタフェースが生成されていることがわかります。

admin@(ip-10-0-0-201)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net interface

net interface 1.1 {

if-index 48

mac-address 06:20:b9:8f:bc:83

media-fixed 10000T-FD

media-max 10000T-FD

}

net interface mgmt {

if-index 32

mac-address 06:05:a2:1e:c4:f9

media-active 100TX-FD

}

21

Virtual Server用のセカンダリプライベート IPアドレス設定と EIPの割り当て

外部サービス用サブネット：BIP-ext-1aに接続された BIG-IPのインタフェースに、セカンダリプライベート IPアドレスを追

加します。

このアドレスが Virtual Serverのアドレスとなり、このアドレスを EIP と関連付けます。

2.2.4.1. セカンダリプライベート IPアドレスの割り当て

(1) ナビゲーションペインで「ネットワークインターフェイス」を選択します。

表示された画面で、プライマリプライベート IP として 10.0.1.201のアドレスを持つインタフェースを見つけます。

そのインタフェースを右クリックし、「プライベート IPアドレスの管理」を選択します。

(2) 「新しい IPの割り当て」をクリックして、Virtual Server用の IPアドレスを入力します。

同時に「再割り当ての許可」にチェックを入れます(※後の章のマルチ AZ冗長構成で必要となるので、この時点で設

定しておきます)。

「更新する」ボタンを押します。

もう一度同じ画面が現れるので、今度は「キャンセル」をクリックします。

(3) 以下のようにセカンダリプライベート IPアドレスが割り当てられます。

10.0.1.201

プライベート IPの管理を選択

Virtual Server用 IPを設定

チェックを入れる (マルチ AZ冗長化用)

22

2.2.4.2. セカンダリプライベート IPへ EIPを割り当て

この Virtual Server用に割り当てたセカンダリプライベート IPアドレスに EIPを割り当てます。

(1) ナビゲーションペインで「Elastic IP」を選択します。

何も割り当てられていない EIPを右クリックして、「アドレスの関連付け」をクリックします。

(2) 「インスタンス」で、生成した BIG-IPを選択します。

「プライベート IPアドレス」で、Virtual Server用のセカンダリプライベート IPアドレス(10.0.1.101)を選択します。

「関連付ける」ボタンを押します。

(3) セカンダリプライベート IPアドレス(BIG-IPの Virtual Server用)に、EIPが割り当てられました。

これで EC2での BIG-IP インスタンス設定は完了です。

アドレスの関連付けを選択

プルダウンから選択 or

インスタンス IDを入力。

IPを選択

23

2.3. EC2でWordPressインスタンスを起動

BIG-IPのロードバランシング対象となるWordPress インスタンスを 2つ起動します。


(1) ナビゲーションペインで「インスタンス」を選択します。

「インスタンスの作成」ボタンを押します。

(2) AWS Marketplaceをクリックし、検索フォームに"wordpress"と入力し Enterキーを押します。

(3) 本ガイドでは以下のWordPress を選択しました。

(4) インスタンスタイプは、本ガイドでは「t2.micro」を選択しました。

wordpress と入力して、「Enter」キーを押す

24

(5) インスタンス数は 2 とします。ここではひとまず、Auto Scalingは設定しません。

作成した VPC：F5JP-VPC とプライベートサブネット：BIG-int-1aを選択します。

ネットワークインターフェイスはデフォルトのままとします。

～略～

(6) ストレージはサイズ(GiB)に 10を指定して、「次の手順：～」ボタンを押します。

(7) Name タグには「wordpress」と入力しておきます。


BIP-int-1a を選択

無効 (デフォルト)

デフォルトのまま

インスタンス数：2

名称を入力

25

(8) プライベートサブネットのWordPressへの SSHアクセスが必要な場合は、BIG-IP を踏み台としてアクセスすることに

します。よって、SSHでアクセスできる送信元を、VPC内に限定します。

(9) 一通り内容を確認し、「作成」ボタンを押します。

(10) 作成済みのキーペアを選択し、「インスタンスの作成」ボタンを押します。

(11) 「インスタンスの表示」ボタンを押します。



VPC内に限定

「既存のキーペアの選択」を選択

作成済みキーを選択

チェックを入れる

26

(12) wordpress インスタンスが 2つ生成されます。

［参考］WordPressへの SSHログイン (PuTTY と Pagentの利用)

WordPressには Public IP を割り当てていないので、インターネットから直接ログインすることはできません。

よって、ここでは BIG-IPを踏み台としてWordPressへ SSHログインする方法を示します。

BIG-IP には OpenSSHがデフォルトでインストールされているので、SSH-agentが利用できます。

よって、PuTTY と Pagent を使うことで、キーファイルを指定することなく、BIG-IPを踏み台としたWordPressへの SSH

ログインができます。

2.3.2.1. Pagentの起動

(1) Pagentを起動して、SSHログイン用のキーファイルを指定しておきます(参照：Pagentの利用)。

(一度起動しておけば、常駐プログラムとなり、タスクバーに表示されます。)

2.3.2.2. PuTTYで BIG-IPを踏み台にしてWordPressへ SSHログイン

(1) PuTTYを起動します。

(2) Pagentが持つキーを BIG-IPを経由してWordPressまでフォワーディングするための設定を行います。

Category:Connection→SSH→Authで、Authenticaton parametersの「Allow agent forwarding」にチェックを入れま

す。

Allow agent forwardingにチェック

27

(3) Category: Sessionで、"Load, save or delete a stored session"の下の"Default Settings"を選択して、「Save」ボタ

ンを押します。これで設定が保存されます。

(4) Host Name (or IP address)に、BIG-IPの管理インタフェースに割当てた EIP を指定して「Open」ボタンを押します。

(5) "login as"プロンプトに、"admin"と入力して Enterすることで、BIG-IPにログインできます。

(6) "run util bash"コマンドを実行し、bashに入ります。

admin@(ip-10-0-0-201)(cfg-sync In Sync)(Standby)(/Common)(tmos)# run util bash

[admin@ip-10-0-0-201:Standby:In Sync] ~ #

(7) "ssh -A ユーザ名@WordPressの IPアドレス"で、キーを指定することなくWordPressへログインできます。

(WordPressに自動的に割当てられたプライベート IPアドレスは、AWSマネージメントコンソールで確認して下さい。)

[admin@ip-10-0-0-201:Standby:In Sync] ~ # ssh -A [email protected]

Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-95-generic x86_64)

___ _ _ _

| _ |_) |_ _ _ __ _ _ __ (_)

| _ \ | _| ' \/ _` | ' \| |

|___/_|\__|_|_|\__,_|_|_|_|_|

*** Welcome to the Bitnami WordPress 4.6-1 ***

～略～

BIG-IPの管理インタフェースの EIP

28

2.4. BIG-IPの設定

このセクションでは、BIG-IPによるサーバロードバランシングができるまでの設定手順を示します。

WebUIパスワードの設定

WebUIへのログイン用アカウント：adminのパスワードを設定します。

TMSHで以下のコマンドを実行します。

(SSHログインしている状態で、"run util bash"コマンドで bashに入っている場合は、"exit"で TMSHに戻ります。)

admin@(ip-10-0-0-201)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# modify auth password admin

changing password for admin

new password: <パスワード(任意)>

confirm password: <パスワード(任意)>

admin@(ip-10-0-0-201)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# save sys config

ウィザードによる初期設定

WebUIへ初めてログインした際には、ウィザードが実行されますので、それを使って初期設定を行っていきます。

(1) 管理インタフェースに割り当てた EIPに、Webブラウザで HTTPSアクセスします。

例：https://52.198.53.72

Usernameは"admin"で、Passwordは先ほど CLIで設定した文字列でログインします。

(2) 「Next」ボタンを押します。

admin

CLIで設定したパスワード

29

(3) 「Activate」ボタンを押します。

(4) 調達済み(または Evaluation用)のレジストレーションキーを入力し、「Next」ボタンを押します。

※ 「Activation Method」はデフォルトで Automaticが選択されています。

このことによって、F5のライセンスサーバに自動的にアクセスし、レジストレーションキーが正しいものであればライセ

ンスファイルを取得し、アクティベートします。

(5) EULA (End User License Agreement) です。「Accept」ボタンを押します。

※

30


(7) ライセンスの確認画面です。「Next」ボタンを押します。

～略～

(8) リソースプロビジョニング画面です。デフォルトのまま「Next」ボタンを押します。

～略～

31

(9) BIG-IPがデフォルトで持つ SSL証明書です。「Next」ボタンを押します。

(10) Platform設定です。

Host Nameは FQDN形式("."区切り)で入力する必要があります。

Time Zoneは Asia/Tokyo とします。

Admin Accountパスワードは、CLIで設定したものと同じものでも違うものでも問題ありません。

(11) 再度、設定した adminアカウントでのログインを求められますので、再ログインしてください。

ホスト名を FQDN形式で入力

任意の文字列

32

(12) 以降もウィザードを続けて、冗長化設定まで行うことが可能ですが、まずはスタンドアローン設定を行いますので、本

ガイドでは「Finished」ボタンを押します。

ネットワーク設定

2.4.3.1. VLAN設定

まず、インタフェースに VLANを割り当てます。

「Network」→「VLANs」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。


Interface: 1.1 Tagging: Untagged

を選んで「Add」ボタンを押す

33

2.4.3.2. Self IP設定

作成した VLANに、IPアドレスを割り当てます。

「Network」→「Self IPs」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

2.4.3.3. Routes設定

インターネットへのデフォルトゲートウェイを設定します。

「Network」→「Routes」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。


IPアドレスと

Netmask を入力

作成済み VLANを選択


宛先および Netmaskに 0.0.0.0 を入力

AWSのゲートウェイのアドレスを入力

34

サーバロードバランシングの設定

2.4.4.1. Pool設定

ロードバランシング対象の 2つのWordPress を Pool として設定します。

(1) 「Local Traffic」→「Pool」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

(2) 確認のみです。

作成された Pool名をクリックして、「Members」タブをクリックすると、登録された Pool Membersが確認できます。

Statusがグリーンであれば、ヘルスモニターは成功しています。


ヘルスモニターを選択。

Address と Portを指定して、

「Add」ボタンを押す。

2つのサーバ分実施する。

35

2.4.4.2. Virtual Serverの設定

インターネットからのトラフィックを受け付ける Virtual Serverの設定です。

「Local Traffic」→「Virtual Servers」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように設定

します。

～略～


Virtual Serverの IPアドレス(AWSのセカンダリプライベート IP)と

TCPポート番号(80)を設定

http を選択

Auto Map を選択

作成した Pool を選択

36

サーバロードバランシグの動作確認

Virtual Server用のプライベート IPに割り当てた Elastic IPにWebブラウザでアクセスし、WordPress画面が表示され

ることを確認してください。

例) http://52.198.61.129

37

3. マルチ AZでの冗長化

2つの AZ間での BIG-IP冗長化を構成していきます。

前章のスタンドアローンとして生成した BIG-IPをそのまま使い、別の AZ(AZ2:ap-northeast-1c)に新しく 2台目の

BIG-IPを生成します。 2台目もライセンス持ち込み型 (BYOL: Bring Your Own License) とします。

AZ2の各サブネットを以下の位置づけとして作成します。

BIP-mgt-1c： BIG-IP管理用サブネット

BIP-ext-1c: BIG-IPの外部サービス用(Virtual Server用)サブネット

BIP-int-1c: BIG-IPのロードバランシング対象のサーバ用サブネット

冗長化切替り発生の際に、新しく Activeになった BIG-IPが AWS APIへアクセスし、旧 Activeの Virtual Serverに

割り当てられた EIP を、自身の Virtual Serverに付け替える、という動作で AZ間切替えを実現します。

AWS APIへは BIG-IPの Self IPからのアクセスが必要なので、Self IPに EIPを割り当てます。

本ガイドでは AZ2へのWordPress追加は省略していますが、必要に応じて既述の手順を参照して追加し、動作を確

認してみてください。

38

3.1. VPCの設定追加

AZ2のサブネット追加

AZ2 (ap-northeast-1c)で利用するサブネットを追加します。

(1) AWS VPC設定画面に入ります。

(2) ナビゲーションペインの「サブネット」をクリックして表示された画面で、「サブネットの作成」ボタンを押します。

(3) AZ2の BIG-IPの管理用サブネット(BIP-mgt-1c)を作成します。

(4) AZ2の BIG-IPの外部サブネット(BIP-ext-1c)を作成します。

(5) サーバ用サブネット(BIP-int-1c)を作成します。


VPCを選択

ap-northeast-1c を選択

10.0.10.0/24


VPCを選択


10.0.11.0/24


VPCを選択


10.0.12.0/24

39

(6) 3つのサブネットが追加された状態です。

ルートテーブルの設定

AZ2のサブネットをルートテーブルに関連付けます。

(1) ナビゲーションペインで「ルートテーブル」を選択します。

(2) 「ルート」タブ内にインターネットゲートウェイのルート (0.0.0.0/0→igw-XXXX) を持つ方のルートテーブルを選択しま

す。

(3) 「サブネットの関連付け」で、BIG-IPの管理用サブネット(BIP-mgt-1c)と外部用サブネット(BIP-ext-1c)を関連付けま

す。


インターネットゲートウェイへのルート

40

(4) もう一つのルートテーブル：「ルート」タブに VPC内のサブネット (10.0.0.0/16) のルートだけを持っている方を選択し

ます。

(5) 「サブネットの関連付け」で、プライベートサブネット(BIP-int-1c)を関連付けます。


41

3.2. EC2で AZ2用の BIG-IPインスタンスを起動


1台目の BIG-IP と同様に、EC2の AWS Marketplaceから BIG-IPを AZ2へ追加します。

以下に、1台目との違いだけを記載します。

(1) インスタンスの詳細の設定

～略～

(2) Name タグには、区別しやすいように 1台目の BIG-IP とは異なる値(例：BIP-VE002)を設定しておきます。

AZ2の BIG-IP管理用セグメント(BIP-mgt-1c)を選択

BIP-mgt-1c用 IP(10.0.10.202)を設定

BIG-IP外部用セグメント(BIP-ext-1c)を選び、IP(10.0.11.202)を設定


1台目とは異なる名称にしておく

42

Virtual Server用セカンダリプライベート IPアドレスの設定

AZ2の BIG-IPにも、AZ1の BIG-IPが持つ Virtual Server (10.0.1.101:80) とは別の Virtual Server (10.0.11.102:80)

の設定が必要です。そのためのセカンダリプライベート IPアドレスを設定します。

(1) ナビゲーションペインで「ネットワークインターフェイス」を選択します。

(2) BIG-IPの外部セグメントのアドレス：10.0.11.202を持つインタフェースを探して、右クリックし、「プライベート IPアドレ

スの管理」を選択します。

(3) 「新しい IPの割り当て」をクリックして、Virtual Server用のプライベート IPアドレスを入力します。

同時に「再割り当ての許可」にチェックを入れます。

「更新する」ボタンを押します。

(4) 以下のようにセカンダリプライベート IPアドレスが割り当てられます。

10.0.11.202

プライベート IPの管理を選択

②Virtual Server用 IP(10.0.11.102)を設定

③チェックを入れる

①クリック

43

Elastic IPの発行

以下 3つの EIP を追加します。

① BIP-VE001の Self IP用 (AWS API連携用)

② BIP-VE002の管理用

③ BIP-VE002の Self IP用 (AWS API連携用)

(1) ナビゲーションペインで「Elastic IP」を選択し、「新しいアドレスの割り当て」ボタンを押して、3つ発行します。

(2) 発行した EIPのいずれかひとつを右クリックして、「アドレスの関連付け」を選択します。

(3) 「インスタンス」で AZ1の BIG-IP(BIP-VE001)を選択(またはインスタンス IDを入力)し、「プライベート IPアドレス」で

外部セグメント：BIP-ext-1aのアドレス(10.0.1.201)を選択します。

AZ1の BIG-IPのインスタンスの選択

(またはインスタンス IDを入力)

10.0.1.201 を選択

44

(4) 同様の手順で、「インスタンス」で AZ2の BIG-IP(BIP-VE002)を選択(またはインスタンス IDを入力)し、「プライベート

IPアドレス」で管理用セグメント：BIP-mgt-1cのアドレス(10.0.10.202)を選択します。

(5) 同様の手順で、「インスタンス」で AZ2の BIG-IP(BIP-VE002)を選択(またはインスタンス IDを入力)し、「プライベート

IPアドレス」で外部セグメント BIP-ext-1cのアドレス(10.0.11.202)を選択します。



10.0.10.202 を選択



10.0.11.202 を選択

45

3.3. セキュリティグループの変更

BIG-IPの冗長化構成用に 2つのポート(TCP/4353，UDP/1026)が使われるので、セキュリティグループでそれらを許可

します。加えて、通信テスト用に ICMP も通るように設定しておきます。

(1) AWS EC2設定画面へ入ります。

(2) ナビゲーションペインの「セキュリティグループ」をクリックします。

オブジェクトが多すぎる場合は VPC IDでフィルタリングします。

BIG-IP用に作成したセキュリティグループを選択します。

「インバウンド」タブで「編集」ボタンを押します。

(3) TCP/4353および UDP/1026 を許可するルールを以下のように追加します。

BIG-IP間で利用するだけなので、送信元は VPC内のサブネットに限定します。

加えて、通信テスト用に ICMP も追加します。

オブジェクトが多すぎる場合、VPCでフィルター

冗長化用

通信テスト用

46

3.4. IAMの設定

マルチ AZ間の切り替えには、AWSの APIを通じて、Virtual Server用の Elastic IP を付け替える、という処理が必要

です。よって、その AWS API を利用するための権限を IAMで設定します。

(1) AWSへのログイン後に表示されるマネージメントコンソールのポータル画面から、Identity & Access Management

を選択します。

(2) 「新規ユーザの作成」をクリックします。

(3) ユーザ名(任意)を入力して、「作成」ボタンを押します。

(4) 「認証情報のダウンロード」ボタンを押します。

(5) 認証情報が入った CSV ファイルをローカル PCへダウンロードします。

後にそのファイル内の値 (Access Key，Secret Key) を使います。

(6) 作成したユーザにポリシーを割り当てます。作成したユーザをクリックします。


クリック

47

(7) 「アクセス許可」タブをクリックし、「ポリシーのアタッチ」ボタンを押します。

(8) 「AmazonEC2FullAccess」ポリシーを割り当てます。

フィルターにその文字列の一部を入れて検索します。

AmazonEC2FullAccessの先頭にチェックを入れて、「ポリシーのアタッチ」ボタンを押します。

(9) 以下のように、「AmazonEC2FullAccess」がポリシーとして割り当てられます。

48

3.5. AZ2の BIG-IPの設定

WebUIパスワードの設定

WebUIへのログイン用アカウント：adminのパスワードを設定します。

AZ2の BIG-IPの管理用インタフェースに割り当てた EIPに対して SSHでログインします。

WebUI用アカウント：adminのパスワードを変更します。

admin@(ip-10-0-10-202)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# modify auth password admin




admin@(ip-10-0-10-202)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# save sys config

ウィザードによる初期設定

Webブラウザで AZ2の BIG-IPの管理インタフェース用 EIPにアクセスします。

(1) AZ1の BIG-IP と同様の手順を実施し、以下の Platform画面が出るまで進みます。

(2) Platform画面です。

冗長化の際には、DHCPによるアドレス取得を停止する必要があります。以下のように設定します。

この後も、AZ1の BIG-IPの初期設定と同様に、WebUIの再ログインを実施します。

ログイン後に現れた画面で「Finished」ボタンを押します。

Manual を選択

プライベート IPアドレス，ネットマスク、

マネージメント用デフォルトルートを設定

ホスト名を FQDN形式で指定

Asia/Tokyo を選択

任意の文字列

49

ネットワーク設定

3.5.3.1. VLAN設定

「Network」→「VLANs」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

～略～

3.5.3.2. Self-IP設定

アドレス設定に加え、冗長化用に 2つのポート(TCP/4353，UDP/1026)を使うので、そのポートの許可設定を行います。

「Network」→「Self IPs」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。


Interface: 1.1 Tagging: Untagged

を選んで「Add」ボタンを押す


IPアドレスと

Netmask を入力

作成済み VLANを選択

Allow Custom を選択

① TCP と Portを選択し、

ポート番号(4353)を入力して


② UDP と Portを選択し、

ポート番号(1026)を入力して、


50

3.5.3.3. Default Route設定

この構成では、2つの AZに存在する BIG-IPそれぞれに、異なる Next-Hop を指定した Default Routeが必要です。

BIG-IPは通常の Config同期を行うと、Routes設定も同期します(＝2つの BIG-IPが同じ Next-Hopを持ちます)。

それを避けるために、Partitionを同期しない設定にして、その Partition内に Default Route を指定します。

(1) Partitionを作ります。

「System」→「Users」→「Partition List」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように

設定します。

～略～

(2) 画面右上の Partition：を、設定した Partition(LOCAL_ONLY)へ切り替えます。

(3) 「Network」→「Routes」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

(4) 画面右上の Partition：を、Commonへ切り替えます。


チェックを外す

「None」を選択

traffic-group-local-only(non-floating)を選択




51

Device Managementの設定

AZ1の BIG-IP との冗長化を構成するために必要な設定を行います。

(1) 「Device Management」→「Devices」で表示された自身の BIG-IPをクリックします。

(2) 「Device Connectivity」タブから「ConfigSync」を選択し、以下のように設定します。

(3) 「Device Connectivity」タブから「Failover Network」を選択し、以下のように設定します。

これで、AZ2の BIG-IPの冗長化準備は完了です。

クリック

externalの Self IP を選択

ConfigSync を選択


52

3.6. AZ1の BIG-IP設定

AZ1の BIG-IPの設定変更および設定追加を行います。

Platform設定の変更

AZ2の BIG-IP同様に、AZ1の BIG-IPでも DHCPを止める必要があります。

「System」→「Platform」で表示された画面で、以下のように設定変更します。

Manual を選択

プライベート IPアドレス，ネットマスク、

マネージメント用デフォルトルートを設定

ホスト名を FQDN形式で指定

Asia/Tokyo を選択

任意の文字列

53

Self-IP設定の変更

AZ2の BIG-IP と同様に、冗長化用に 2つのポート(TCP/4353，UDP/1026)の許可設定を行います。

「Network」→「Self IPs」で表示された「external-ip」をクリックし、以下のように設定を変更します。

Default Route設定の変更

AZ2の BIG-IP と同様に、コンフィグ同期しない Partition を作成して、その中に Default Route を設定します。

(1) スタンドアローン構成時に作成した、Partition: Commonに存在する Default Route を一旦削除します。

「Network」→「Routes」で表示された Default Routeの先頭にチェックを入れ、「Delete」ボタンを押します。

Allow Custom を選択

① TCP と Portを選択し、

ポート番号(4353)を入力して


② UDP と Portを選択し、

ポート番号(1026)を入力して、


54

(2) Partitionを作ります。

「System」→「Users」→「Partition List」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように

設定します。

～略～

(3) 画面右上の Partition：を、設定した Partition(LOCAL_ONLY)へ切り替えます。

(4) 「Network」→「Routes」で表示される画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

(5) 画面右上の Partition：を、Commonへ切り替えます。



「None」を選択

traffic-group-local-only(non-floating)を選択




55

冗長化用の設定

AZ2の BIG-IP との冗長化を構成するための設定を行います。

3.6.4.1. Devices設定

(1) 「Device Management」→「Devices」で表示された自身の BIG-IPをクリックします。

(2) 「Device Connectivity」タブから「ConfigSync」を選択し、以下のように設定します。

(3) 「Device Connectivity」タブから「Failover Network」を選択し、以下のように設定します。

クリック


ConfigSync を選択


56

3.6.4.2. Device Trust設定

2つの BIG-IP間で証明書を交換することで、信頼関係を結びます。

(1) 「Device Management」→「Device Trust」で表示された画面の「Peer List」タブをクリックし、「Add」ボタンを押しま

す。

(2) 現れた画面で、以下のように設定します。

(3) AZ2の BIG-IPの証明書情報が表示されます。「Finished」ボタンを押します。

AZ2の BIG-IPの管理インタフェースアドレス

admin

設定済みのパスワード

57

3.6.4.3. Device Group設定

2つの BIG-IPをグループ化して、そのグループ内で Config同期および Network Failoverする / しないの設定を行い

ます。

このマルチ AZでの冗長化では、Config(自動)同期および Network Failover をする、という設定を行います。

(1) 「Device Management」→「Device Groups」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下

のように設定します。

(2) 作成した Device Group名(my_sync_failover_group (Includes Self))をクリックして現れた画面の「Failover」タブを

クリックします。現れた画面で、以下のように設定します。

(3) 一時的にアドレスの小さいほう(本ガイドの構成では bip-ve001.aws)が Standbyになりますが、そのまま設定を続行

します。

名前(任意)を入力

Sync-Failover を選択

2つの BIG-IPを Includesへ

「<<」ボタンで移動する



58

3.6.4.4. Configの初期同期

Device Group設定で「Automatic Sync」を有効にしたので、Config変更を行った際には自動的に同期されますが、最

初だけは手動で同期する必要があります。

「Device Management」→「Overview」で表示された画面で、以下の操作を実施します。

以下のように Sync Statusがグリーンになれば、Config同期は成功です。

AZ1の BIG-IPを選択する

Syncボタンを押す

59

Virtual Serverの追加設定

スタンドアローン構成で作成した Virtual Server(10.0.1.101:80)はそのまま使い、AZ2用の Virtual Server を追加しま

す。

(1) 「Local Traffic」→「Virtual Servers」で現れた画面右上の「Create」ボタンを押します。

(2) 現れた画面で以下のように設定します。Virtual Serverの IPアドレスは AZ2用を指定してください。

このまま使う。


AZ2の Virtual Serverの IPアドレス(AWSで設定した

セカンダリプライベート IP)と TCPポート番号(80)を設定

http を選択

Auto Map を選択

60

～続き～

(3) 以下のように 2つの Virtual Serverが作成された状態になります。

(4) Virtual Address を Traffic Groupから外します。

注) Traffic Group とは、Virtual IPなどのオブジェクトをグループ化したものです。

この Traffic Groupを処理する権限を持つ BIG-IPが Active、持たないほうが Standby となります。

このマルチ AZ構成においては、Virtual IPの権限を Active/Standbyの切替り発生時に移動させないようにして、

Elastic IPの付替えだけ行いたいので、Traffic Groupから外します。

「Virtual Address List」タブをクリックし、どちらか一方の IPアドレスをクリックします。


61

(5) 以下のように設定します。

(6) もう一方の IPアドレスも同様に、以下のように設定します。

チェックを外し、

None を選択。

チェックを外し、

None を選択。

62

(7) Traffic-Groupがどちらの IPアドレスも Noneに変更になったことを確認します。

(8) IAMで作成したユーザの Access Key / Secret Keyを入力します。

「System」→「Configuration」で表示された画面の「AWS」タブをクリックして現れた画面で、以下のように設定します。

IAMユーザから取得した Access Key と

Secret Keyを入力

63

マルチ AZ冗長化用 iAppテンプレートによる設定

Elastic IPの付替えを行うための AWS APIアクセス用のスクリプトは、iApp というテンプレートで用意されています。

F5のダウンロードサイト(https://downloads.f5.com)から Downloadできます。(※ユーザ登録が必要です。)

3.6.6.1. iAppテンプレートのダウンロード

(1) Webブラウザで F5のダウンロードサイト(上記 Link)へアクセスし、「Find a Download」ボタンを押します。

～略～

(2) 「iApp Templates」をクリックします。

64

(3) 「iApp Templates」をクリックします。

(4) iappsXXX.zip ファイルをクリックします。

(5) Download Locationを聞いてきますので、JAPANをクリックすると、ダウンロードが開始されます。

(6) その ZIP ファイルを解凍します。

(7) その解凍後に「RELEASE_CANDIDATES」フォルダがあります(2016/8/末現在)。

そのフォルダ内の「f5.aws_advanced_ha.v1.0.1rc1.tmpl」が、マルチ AZ構成用の iAppテンプレートです。

3.6.6.2. iAppテンプレートによる設定

ダウンロードした iAppテンプレートを使って、マルチ AZ冗長化設定を行います。

(1) AZ1の BIG-IPのWebUIへアクセスします。

(2) 「iApps」→「Templates」で表示された画面で、「Import」ボタンを押します。

(3) File Nameのところで、ダウンロードした iAppテンプレートを指定して、「Upload」ボタンを押します。

ダウンロードした iAppテンプレートを指定。

65

(4) Import されると、以下のようになります。

(5) 「iApps」→「Application Services」で表示された画面右上の「Create」ボタンを押します。

(6) 表示された画面で、以下のように設定します。


Upload した iAppテンプレートを選択。

Debug を有効にする

「Yes,～」を選択

Virtual

Serverの EIP

AZ1 BIG-IP用の VIP

を選択

AZ2 BIG-IP用の VIP

を選択

66


(8) AZ2の BIG-IPでも、iAppテンプレートの「Finished」を実施する必要があります。

「iApps」→「Application Services」で表示された画面で、AZ1の BIG-IPで作成した iAppの名前(multi-az)をクリックし

ます。

(9) 「Reconfigure」タブをクリックします。

(10) コンフィグが同期されています。そのまま「Finished」ボタンを押します。

～略～

67

3.6.6.3. Traffic-Groupの切替え(Active/Standbyの切替え)

現在、AZ2の BIG-IPが Activeになっていますので、AZ1の BIG-IPが Activeになるように Traffic-Groupを切り替え

ます。


(2) 「Device Management」→「Traffic Groups」で表示された画面で、traffic-group-1の先頭にチェックを入れ、「Force

to Standby」ボタンを押します。

(3) 以下の画面に変わります。もう一度「Force to Standby」ボタンを押します。

以上で、マルチ AZ間冗長の設定は完了です。

次のセクションで動作を確認します。

68

3.7. マルチ AZ間冗長の切替り動作確認

実際に AZ間の Active/Standby切替えを行って、クライアントからWordPressへのアクセスが復旧することを確認しま

す。

クライアント PCからのアクセス確認

クライアント PCのWebブラウザから EIPに対してアクセスして、WordPress画面が表示されることを確認します。

Virtual Serverに割り当てられた Elastic IPの確認

まず、Virtual Server用の Elastic IP(52.198.61.129)がどこに割り当てられているかを確認します。

(1) AWSマネージメントコンソールから、「EC2」を選択します。

(2) ナビゲーションペインで「Elastic IP」を選択し、フィルターで Virtual Serverの Elastic IP(52.198.61.129)を指定しま

す。

(3) 本ガイドでは現在、AZ1の Virtual Serverアドレス：10.0.1.101に Elastic IP(52.198.61.129)が割り当てられていま

す。

Virtual Serverの EIPでフィルター

69

AZ間の切替え


(2) Traffic-Groupを AZ2の BIG-IPへ切替えます。

「Device Management」→「Traffic Groups」で表示された画面で、traffic-group-1の先頭にチェックを入れ、「Force to

Standby」ボタンを押します。

(3) 以下の画面に変わります。もう一度「Force to Standby」ボタンを押します。

(4) AWSマネージメントコンソールの EC2で Elastic IPの状態を確認します。

AZ2の BIG-IPの Virtual Serverへの付替えが行われています。

70

クライアント PCからのアクセス確認

もう一度クライアント PCのWebブラウザから EIPへアクセスし、切り替わり後にも、WordPressが表示されることを確

認してください。

［参考］Debug ログの確認

iAppテンプレートで Debug を有効にすると、/var/log/ltmに動作時の Debugログが出力されます。

BIG-IPへ SSHでアクセスし、以下のコマンドを実行して確認できます。

例) AZ1から AZ2の BIG-IPへの切替り発生時(AZ2の BIG-IPのログ)：

admin@(bip-ve002)(cfg-sync In Sync)(Standby)(/Common)(tmos)# run util bash

[admin@bip-ve002:Standby:In Sync] ~ # tail -f /var/log/ltm Aug 26 19:44:37 bip-ve002 notice logger: /usr/libexec/aws/aws-failover-tgactive.sh (traffic-group-1): Started.

Aug 26 19:44:37 bip-ve002 info aws_advanced_failover: EIP takeover started.

Aug 26 19:44:38 bip-ve002 debug aws_advanced_failover: columns: EIP 2, AZ1 3, AZ2 4

Aug 26 19:44:38 bip-ve002 debug aws_advanced_failover: IPs from iApp: 52.198.61.129 10.0.1.101 10.0.11.102

Aug 26 19:44:38 bip-ve002 debug aws_advanced_failover: instanceId is i-164a5499

Aug 26 19:44:38 bip-ve002 debug aws_advanced_failover: region is ap-northeast-1

Aug 26 19:44:39 bip-ve002 debug aws_advanced_failover: networkDescriptionCache is at /tmp/tmpbZt0xb

Aug 26 19:44:41 bip-ve002 debug aws_advanced_failover: size of EIP mapping array is 1

Aug 26 19:44:41 bip-ve002 debug aws_advanced_failover: considering row 0, EIP 52.198.61.129, VIP1 10.0.1.101,

VIP2 10.0.11.102

Aug 26 19:44:42 bip-ve002 debug aws_advanced_failover: EIP 52.198.61.129, chosen AZ 2

Aug 26 19:44:42 bip-ve002 debug aws_advanced_failover: reassigning EIP 52.198.61.129, row 0

Aug 26 19:44:42 bip-ve002 debug aws_advanced_failover: VIP is 10.0.11.102

Aug 26 19:44:42 bip-ve002 debug aws_advanced_failover: ENI is eni-24256f79

Aug 26 19:44:42 bip-ve002 notice logger: /usr/libexec/aws/aws-failover-tgactive.sh (traffic-group-1): Completed.

Aug 26 19:44:43 bip-ve002 debug aws_advanced_failover: addressDescription is ADDRESS 52.198.61.129 i-

df80bb40 vpc eipalloc-63541606 eipassoc-9bcb3bfc eni-c0e0688a 10.0.1.101

Aug 26 19:44:43 bip-ve002 debug aws_advanced_failover: EIPAllocationId for EIP 52.198.61.129 is eipalloc-63541606

Aug 26 19:44:45 bip-ve002 debug aws_advanced_failover: ec2AssociateAddress ADDRESS (nil) (nil)

eipalloc-63541606 eipassoc-37c63650 eni-24256f79 10.0.11.102

Aug 26 19:44:45 bip-ve002 info aws_advanced_failover: Reassigned EIP 52.198.61.129 to VIP 10.0.11.102 on

interface eni-24256f79

Aug 26 19:44:45 bip-ve002 info aws_advanced_failover: No reconfiguration of AWS routes was requested.

Aug 26 19:44:45 bip-ve002 info aws_advanced_failover: EIP takeover completed.

71

3.8. マルチ AZ構成での Route Management設定

ユーザのニーズによっては、クライアントが持つグローバル IPアドレスをそのままWebサーバまで届けてほしい、という

場合があります。

例えば、サーバ側で、IPパケットの送信元アドレスでロギングしたい、というような場合です。

ここまでに行ってきた Virtual Serverの設定では、BIG-IPが送信元アドレスを自身のアドレス (BIG-IPの Self IPアドレ

ス) に変換してWordPressに送っています。

Virtual Serverの作成時に設定した、Source Address Translationの「Auto Map」指定がそれにあたります。

この Source Address Translationの Auto Map設定によって、クライアントからの HTTP リクエストの送信元は BIG-IP

のアドレスに変換されて送出されるので、WordPressからの HTTPレスポンスは確実に BIG-IPに戻ってくる、というメリッ

トはあります。

しかし、この設定のままでは、上記のようなニーズは満たせません。

このニーズを満たすためには、以下の 3箇所の設定変更が必要です。

① ［BIG-IP］ Source Address Translation設定を「Auto Map」から「None」に変更する

② ［AWS］ EC2ネットワークインターフェイスの「送信元/送信先の変更チェック」を無効化する

③ ［AWS］ VPC Routerのルート設定を変更する

③の挙動については後述しますが、例えば AZ1→AZ2への切替り発生時には、③を AZ1→AZ2へ動的に変更する必

要があります。それを実現するのが、iAppテンプレートの一番下にある「Route Management」設定です。

以降、その設定を行っていきます。

72

BIG-IPの設定変更

Source Address Translation を「Auto Map」から「None」に設定変更して、送信元をクライアント IPアドレス(Global IP

アドレス)のままWebサーバへパケットを送り出す設定にします。


(2) 「Local Traffic」→「Virtual Servers」で表示された AZ1用の Virtual Server(WP-vs001)をクリックして表示された画面

で、以下の設定変更を行います。

～略～

～略～

(3) AZ2用の Virtual Server(WP-vs002)でも、同様の設定変更を行います。

「None」を選択

73

AWS EC2ネットワークインターフェイスの「送信元/送信先の変更チェック」の無効化

AWSでは、EC2ネットワークインターフェイスに設定された IPアドレスを持つパケット以外は、デフォルトでは通さない設

定になっています。

よって、これを許可します。

(1) EC2のナビゲーションペインで「ネットワークインターフェイス」を選択します。

(2) AZ1の BIG-IPの外部用インタフェースを探して右クリックし、「送信元/送信先の変更チェック」を選択します。

74

(3) 以下のように設定変更します。

(4) AZ2の BIG-IPの外部インタフェースに対しても同様の設定変更を行います。

これで、送信元/送信先が BIG-IPの IPアドレスではない IPパケットでも通過できるようになりました。

VPC Routerのルート設定変更

サーバ→BIG-IP方向のトラフィックは、今の設定のままでは通りません。

BIP-int-1aサブネットが関連付けられたルートテーブルには、クライアントの Global-IPへの宛先が存在していないため

です。

よって、インターネットゲートウェイへのルート(0.0.0.0/0→igw-XXXX)を持たないほうのルートテーブルに 0.0.0.0/0を追

加し、そのターゲットには BIG-IPのインタフェース IDを指定することで回避します。

無効を選択

75

(1) EC2のナビゲーションペインで「インスタンス」を選択し、AZ1の BIG-IPをクリックします。

「説明」タブ内の eth1のインタフェース IDを確認し、メモ帳などにコピーしておきます。

例) eni-c0e0688a

(2) VPCのナビゲーションペインで「ルートテーブル」を選択します。

0.0.0.0/0を持たないほうのルートテーブルの「ルート」タブで「編集」ボタンを押します。

VPC IDでフィルター

クリック

76

(3) 「別ルートの追加」ボタンを押します。

送信先：0.0.0.0/0、ターゲット：BIG-IPの eth1のインタフェース ID (eni-c0e0688a)を入力します。

「保存」ボタンを押します。

(4) 以下の状態になります。

これで、Webサーバからの HTTPレスポンスの宛先がクライアント IP(Global-IP)であっても、BIG-IPまで到達できるよう

になりました。

送信先：0.0.0.0/0，ターゲット：BIG-IPの eth1のインタフェース ID

77

iAppの Route Management設定

上記の VPCのルート設定では、0.0.0.0/0のターゲットを静的に AZ1の BIG-IPの外部インタフェース IDに指定しまし

た。

この場合、BIG-IPの Activeが AZ2に切替っても、HTTPレスポンスは AZ1へルーティングされてしまいます。

この問題を解決してくれるのが、Route Management設定です。

この設定によって、AZ1から AZ2へ BIG-IPの Activeが切替った際に、AWS APIを通じて、0.0.0.0/0のターゲットを

AZ2の BIG-IPの外部インタフェース IDへ切替えてくれます。

その設定方法を示します。

(1) AWSマネージメントコンソール→VPC→ルートテーブルで、0.0.0.0/0→"AZ1の BIG-IP"の設定を行ったほうのルート

テーブル IDを確認します。(本ガイドでは「rtb-52ec3f36」です。)


(3) 「iApps」→「Application Services」で表示された、作成済みの iAppをクリックします。Route Managementで、以下

のように設定変更します。

～略～

以上で Route Management設定は完了です。

次のセクションで動作を確認します。

Yes,～を選択

ルートテーブル ID 0.0.0.0/0

外部インタフェースを選択

78

マルチ AZ間冗長の切替り動作確認(Route Managementあり)

実際に AZ間の Active/Standby切替えを行って、クライアントからWordPressへのアクセスが復旧することを確認しま

す。

(1) クライアントのWebブラウザから Virtual Server用 Elastic IPにアクセスして、WordPress画面が表示されることを

確認してください。

(2) このとき、WordPressに SSHログイン (方法は既述) し、tcpdumpを使ってキャプチャしてみてください。

クライアント IPは Global IPのまま到達していることがわかります。

(3) BIG-IPの Traffic-Groupの Active/Standbyを切り替えます(方法は既述)。

(4) クライアントのWebブラウザから Virtual Server用 Elastic IPにアクセスして、WordPress画面が表示されることを

確認してください。

(5) AWS VPCのルートテーブルを確認します。

rtb-52ec3f36のルートテーブルの 0.0.0.0/0のターゲットが、AZ2の BIG-IPのインタフェース IDに自動的に切り替

わります。

ターゲットが AZ2の BIG-IPに自動的に変更されている

79

4. Auto Scaling

Webサーバや BIG-IP インスタンスの負荷に応じて動的にインスタンスを増減させる、Auto Scaling設定を行います。

設定は以下 2つのパートに分かれます。

① Webサーバの Auto Scaling

② BIG-IPの Auto Scaling

以降、それぞれの設定を行っていきます。

4.1. Webサーバの Auto Scaling

まず、Webサーバ(WordPress)の Auto Scaling設定を行っていきます。

WebサーバであるWordPressの負荷に応じて、動的にインスタンス数を増減する設定を行います。

BIG-IPは、AWS APIにアクセスして定期的にWebサーバ数を確認し、ロードバランシング対象設定を動的に増減し

ます。

後の章で設定する BIG-IPの Auto Scalingのために、1-NICの BIG-IPを 1台生成します。(Auto Scalingは 1-NIC

のみ対応しています。)

80

WordPressのカスタム AMI

Auto Scalingする際のベースとなるイメージ＝AMIを作ります。

(1) AWS EC2設定画面に入ります。

(2) ナビゲーションペインの「インスタンス」を選択し、作成済みのWordPress をいずれかひとつ選び、右クリックします。

「イメージ」→「イメージの作成」を選択します。


(4) 「閉じる」ボタンを押します。


81

Auto Scalingの起動設定

生成した AMIを使って、WordPressの Auto Scalingの起動設定を行います。

起動設定は EC2 インスタンスを生成する際のステップに似ていて、Auto Scalingで自動的に起動するインスタンスをど

のような設定(インスタンスタイプやセキュリティグループ等)にしておくか、を指定するイメージです。

(1) ナビゲーションペインの「AUTO SCALING」の下の「起動設定」を選択します。

(2) 「起動設定の作成」ボタンを押します。

(3) 「マイ AMI」を選択し、作成した AMIを選んで「選択」ボタンを押します。

(4) インスタンスタイプは、本ガイドでは「m3.medium」を選択しました。

注) 「t1.micro」などの t系インスタンスは、その特性上、高い CPU使用率の状態を長時間維持できません。

Auto Scaling動作確認時に CPU使用率を擬似的に高く維持することでインスタンスを増やす動作を確認したいので、

本ガイドでは「m3.medium」を選択しました。

「次の手順：～」ボタンを押します。

82

(5) 詳細設定です。

以下のように設定し、「次の手順：～」ボタンを押します。

(6) 何も設定しないで、「次の手順：～」ボタンを押します。



パブリック IPを割当てない、を選択

83

(7) セキュリティグループの設定です。作成済みの「WordPress」を選択し、「確認」ボタンを押します。

(8) 一通り内容を確認して、「起動設定の作成」ボタンを押します。

(9) 作成済みのキーペアを選択し、「起動設定の作成」ボタンを押します。

(10) 「この起動設定を使用して Auto Scalingグループを作成する」ボタンを押して、Auto Scalingグループ設定に移りま

す。



84

Auto Scalingグループの作成

作成した起動設定を使って、Auto Scalingグループを設定します。

どのような状況になったときに、いくつのインスタンスを起動するのか、という指定を行います。

(1) 詳細設定です。以下のように設定します。

(「サブネット」設定で、AZ1 と AZ2のサブネットをそれぞれ指定しておくことで、両方の AZに分散してインスタンスを

起動してくれます。)

(2) スケーリングポリシー設定です。

どのようなときにインスタンスを起動/削除するかをここで決めます。以下のように設定します。

そして、"グループサイズの増加"の下にある、「新しいアラームの追加」をクリックして、CloudWatch設定を行います。


最初に何台起動するか、の指定

VPCを選択

AZ1 と AZ2のサブネットを指定する

CloudWatch詳細モニタリングを有効化する

スケーリングポリシーを使用して～を選択

本ガイドでは「通常 2，最大 8」を指定

クリック

85

(3) インスタンスを増やす際の CloudWatchアラームの設定です。

本ガイドでは「CPU使用率が 50%以上になった場合」にアラーム出力する、と指定しました。

(本ガイドでは、「通知」は利用しません。)

(4) "グループサイズの減少"の下にある、「新しいアラームの追加」をクリックします。

(5) インスタンスを減らす際の CloudWatchアラームの設定です。

本ガイドでは「CPU使用率が 20%未満になった場合」にアラーム出力する、と指定しました。

50%以上


名前(任意)を指定

クリック

20%未満


名前(任意)を指定

86

(6) 「アクションを実行：」で、増減するインスタンス数を指定し、「次の手順：～」ボタンを押します。

(7) 本ガイドでは通知は利用しませんので、そのまま「次の手順：～」ボタンを押します。

「追加」の後ろに"2"を指定

「削除」の後ろに"2"を指定

87

(8) 自動起動されたインスタンスのタグを指定します。

本ガイドでは、Name タグを利用することにしました。「確認」ボタンを押します。

(9) 一通り確認し、「Auto Scalingグループの作成」ボタンを押します。


(11) 開始時のインスタンス数を 2に指定したので、自動的 2つのインスタンスが生成されます。

WebサーバであるWordPressの Auto Scaling設定は以上です。

Name を指定

(※先頭を大文字にすること) 名前(任意)を入力

88

1-NICの BIG-IPの生成

1-NICの BIG-IPを、まずは 1台だけ生成します。

後の章で、このインスタンスからカスタム AMI を生成し、その AMIを BIG-IPの Auto Scalingで利用します。

4.1.4.1. AWS Marketplaceからインスタンスを生成

(1) EC2で「インスタンスの作成」ボタンを押します。

(2) AWS Marketplaceで、Utility Billing(従量課金)の BIG-IP を選んで、「選択」ボタンを押します。

(3) 本ガイドでは「m4.2xlarge」を選択しました。「次の手順：～」ボタンを押します。

(4) 詳細設定です。以下 2点に注意して設定します。

① サブネットは、BIG-IPの外部サブネット：BIP-ext-1aを指定します。

② 自動割り当てパブリック IPを有効にします。


～略～


BIP-ext-1a を選択

有効化を選択


時間毎に課金される記載があるもの

89

(5) EBSのボリュームタイプで「汎用 SSD(GP2)」を選択します。


(6) Name タグに区別しやすい値を入れておきます。


(7) 1-NICの BIG-IP用のセキュリティグループを生成します。

「ルールの追加」ボタンを押して、TCP/8443を許可する設定を追加します。

「確認と作成」ボタンを押します。

汎用 SSD(GP2)を選択




限定することを推奨

TCP/8443 限定することを推奨

90

(8) 一通り確認し、「作成」ボタンを押します。

(9) 作成済みのキーペアを選択し、「インスタンスの作成」ボタンを押します。



91

4.1.4.2. BIG-IPを 1-NICで利用するための設定

(1) ナビゲーションペインで「インスタンス」を選択し、起動した BIG-IPのパブリック IPを確認します。

(2) SSHで BIG-IPのパブリック IPへアクセスし、ログインします。

(3) WebUIログイン用の adminパスワードを変更します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify auth password admin




(4) 1-NIC用の設定を行います。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify sys httpd ssl-port 8443

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify net self-allow defaults add

{ tcp:8443 }

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify net self-allow defaults

delete { tcp:443 }

(5) 設定を保存します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# save sys config

Saving running configuration...

/config/bigip.conf

/config/bigip_base.conf

/config/bigip_user.conf

Saving Ethernet mapping...done

92

4.1.4.3. BIG-IPの初期設定

(1) 「https://パブリック IP:8443」でアクセスし、admin と設定変更したパスワードでログインします。


(3) ライセンス内容の確認です。「Next」ボタンを押します。

～略～

93

(4) リソースプロビジョニング画面です。

後の章でWeb Application Firewall設定を行うので、「Application Security (ASM)」にチェックを入れます。

「Next」ボタンを押します。

～略～

(5) 「Continue」ボタンが出るまで、約 1分程度待ちます。

「Continue」を押します。

(6) BIG-IP自身の証明書の確認です。「Next」ボタンを押します。

～略～

94

(7) adminのパスワードをもう一度指定します。

(8) 再ログインを促す画面が出ます。

Username: admin と、設定したパスワードでログインします。

(9) ［不具合］ WebUIへの再ログイン後に、また証明書を確認する画面が出て、次に進んでもまた戻る場合があります。

この場合には、BIG-IPに SSHでログインし、以下のコマンドを実行し、WebUIのウィザードを停止します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify sys global-settings gui-

setup disabled

(10) WebUI画面の右上の「Logout」ボタンを押して、再度ログインし直します。

(11) 以下のような画面が出ます。

任意の文字列

95

(12) IAMで作成したユーザの Access Key / Secret Keyを入力します。

「System」→「Configuration」で表示された画面の「AWS」タブをクリックして現れた画面で、以下のように設定します。

4.1.4.4. サーバロードバランシング設定

オートスケールされるWebサーバに対するロードバランシング設定を行います。

(1) Poolの作成

WebサーバであるWordPress用の Pool を設定します。

BIG-IPが定期的に AWS APIにアクセスして、起動しているWordPressの情報を取得して Pool メンバーに自動登録し

てくれるので、ここでは Pool メンバーは設定しません。

「Local Traffic」→「Pool」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように設定します。

IAMユーザから取得した Access Key と

Secret Keyを入力


ヘルスモニターを選択。

(設定しない)

96

(2) Virtual Serverの設定

ELBからのトラフィックを受け付ける Virtual Serverの設定です。

この BIG-IPは後の章で Auto Scaling用の AMIのベースとして利用します。

その設定を意識して、Destination Address/Mask は、ネットワーク指定：10.0.0.0/16 とします。

「Local Traffic」→「Virtual Servers」で表示された画面右上の「Create」ボタンを押して現れた画面で、以下のように設定

します。

～略～

～略～


10.0.0.0/16 を指定

ポート：80

HTTPプロファイルを選択

Auto Map を選択


97

4.1.4.5. iAppの利用

AWS APIを通じて、どの Auto ScalingグループからWebサーバの情報を取得し、どの Poolにそれらをメンバーとして

設定するのか、といった情報をこの iAppで指定します。

(1) 「iApps」→「AWS」で表示された画面右上の「Create」ボタンを押します。



(4) 以下の状態になります。


f5-iAppLX-aws-autoscale を選択

設定した Poolの名前を指定

WordPressの Auto Scalingグループの名前を指定

Pool メンバーのポート番号(80)を指定

98

4.1.4.6. iCallの設定

AWS APIへ一定の周期でアクセスするための設定(iCall設定)を行います。

BIG-IPには、iCall という機能があります。

iCallによって、一定の周期でスクリプトを実行することや、ログをトリガーとしてスクリプトを実行することができます。

(1) SSHで BIG-IPにログインします。

(2) 以下のコマンドで、事前に用意されている iCallスクリプトをコンフィグファイルに読み込みます。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# load sys config merge file

/usr/share/aws/autoscale/aws-autoscale-icall-config

Loading configuration...

/usr/share/aws/autoscale/aws-autoscale-icall-config

(3) 周期間隔はデフォルトで 600秒(10分)と長めなので、本ガイドでは、以下のコマンドで 60秒に変更します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify sys icall handler periodic

autoscaleHandler interval 60

(4) 設定された iCall を以下のコマンドで確認します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys icall

sys icall handler periodic autoscaleHandler {

first-occurrence 2016-08-30:12:21:11

interval 60

script autoscale

}

sys icall script autoscale {

app-service none

definition {

exec /usr/libexec/aws/autoscale/aws-autoscale-pool-manager.sh

}

description none

events none

}

(5) コンフィグを保存します。


Saving running configuration...

/config/bigip.conf

/config/bigip_base.conf

/config/bigip_script.conf

/config/bigip_user.conf

Saving Ethernet mapping...done

99

4.1.4.7. Poolの確認

1分経過すると iCallスクリプトが動作し、BIG-IPは AWS上で起動しているWordPressの情報を AWSから取得しま

す。そして、それらを Pool メンバーとして登録します。

「Local Traffic」→「Pools」で表示された Pool名(wp-pool)をクリックし、「Members」タブを確認します。

現在、Auto Scalingによって 2つのWordPressが起動しているので、その 2つが Pool メンバーとして登録されます。

Webサーバの Auto Scaling動作確認

WordPress インスタンスの CPU使用率を上昇させて、Auto Scalingが動作し、それに合わせて BIG-IPの Pool メンバ

ーも増加することを確認します。

(1) SSHで、BIG-IPを踏み台にして、WordPressにログインします。

その方法については、既述「［参考］ WordPressへの SSHログイン」を参照してください。

(2) WordPressで以下コマンドを実行します。

bitnami@ip-10-0-2-4:~$ sudo yes >> /dev/null &

(※上記コマンドを、WordPress×2台の両方で実施したほうが早く確認できると思います。)

［参考］Yes コマンドの詳細については以下をご参照ください。

https://ja.wikipedia.org/wiki/Yes_(UNIX)

(3) top コマンドで、CPU使用率が高くなったことを確認してください。

bitnami@ip-10-0-2-4:~$top

100

(4) AWSマネージメントコンソールの CloudWatchに入ります。

(5) ナビゲーションペインの「アラーム」を選択して、アラームを確認します。

CPU使用率が 50%超えたことを示すアラーム(WP-autoscale-001-Group-CPU-over50)が上がっているはずです。

(6) EC2の「インスタンス」を確認します。

CloudWatchのアラームをトリガーとして、2つだったWordPressが自動的にそれ以上に追加起動されていることを

確認します。

(7) BIG-IPのWP-Poolが 2つ以上に増えたことを確認します。

101

(8) 念のため、BIG-IPのパブリック IPにアクセスして、WordPress画面が表示されることを確認してください。

(9) ［参考］Webサーバの Auto Scalingログの確認

BIG-IPに SSHでログインし、以下のコマンドを実行することで、動作ログを確認することができます。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# run util bash

[admin@ip-10-0-1-175:Active:Standalone] ~ # tail -f /var/log/ltm Aug 30 12:53:11 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Starting.

Aug 30 12:53:11 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Using region ap-northeast-1

Aug 30 12:53:11 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Using AutoScaling Url

http://autoscaling.ap-northeast-1.amazonaws.com

Aug 30 12:53:11 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Updating pool : wp-pool with

instances from Auto Scale Group : WP-autoscale-001-Group

Aug 30 12:53:18 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Auto Scale Group : WP-autoscale-001-

Group contains 4 instances

Aug 30 12:53:18 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : WP-autoscale-001-Group : 10.0.12.81

10.0.2.198 10.0.12.220 10.0.2.4

Aug 30 12:53:19 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : wp-pool contains 4 instances

Aug 30 12:53:19 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : wp-pool : 10.0.12.220 10.0.12.81

10.0.2.198 10.0.2.4

Aug 30 12:53:19 ip-10-0-1-175 notice logger: aws-autoscale-pool-manager.sh : Finished.

102

4.2. BIG-IPの Auto Scaling

次に、BIG-IPの Auto Scaling設定を行っていきます。

BIG-IPは ELBのロードバランシング対象として動作します。

Auto Scalingによって起動した BIG-IPはそれぞれが独立して動作します。

カスタム AMIを生成する前に、Web Application Firewall(WAF)設定を実施しておきます。

このことによって、WAFの Auto Scalingを実現します。

Webサーバの Auto Scaling を止めることなく、BIG-IPの Auto Scaling も同時に利用できます。

103

ELBの設定

まず、BIG-IPのロードバランシグを行うための ELBを設定します。

(1) AWSマネージメントコンソールから EC2へ入ります。

(2) ナビゲーションペインで「ロードバランサー」を選択します。

(3) 「ロードバランサーの作成」ボタンを押します。

(4) 本ガイドでは、「標準ロードバランサー」を選択しました。「次へ」ボタンを押します。

104

(5) ロードバランサーの設定です。

本ガイドでは簡易的に、TCP80(HTTP)のみのリスナー設定とします。

サブネットは、外部サブネット×2つ(BIP-ext-1a と BIP-ext-1c)を選択します。

以下のように設定し、「次の手順：～」ボタンを押します。

(6) ELB用のセキュリティグループ設定です。以下のように設定し、「次の手順：～」ボタンを押します。

(7) 「次の手順：～」ボタンを押します。

ロードバランサーの名前(任意)を入力

VPCを選択

デフォルトのまま。

上記の「利用可能なサブネット」から、

"+"を押して外部サブネットを 2つ選ぶ




105

(8) WordPressには index.html ファイルは存在しないので、代わりに pingパスに「/」を指定し、その他の値も検知を早

めるように調整して、「次の手順：～」ボタンを押します。

(9) EC2 インスタンスは何も選択しないで、そのまま「次の手順：～」ボタンを押します。

(10) Name タグの値を指定して、「確認と作成」ボタンを押します。

(11) 一通り確認し、「作成」ボタンを押します。

"/"に変更

Name を指定

(※先頭を大文字にすること)


10秒に変更

2回に変更

106


ELBの設定は以上です。

107

BIG-IPのWAFの設定

カスタム AMIを生成する前に、BIG-IPに対して簡易的なWAFの設定を行います。

4.2.2.1. ウィザードによる設定

(1) BIG-IPのWebUIへアクセスします。

(2) 「Security」→「Application Security」で表示される画面右上の「Create」ボタンを押します。

(3) 「Existing Virtual Server」を選んで、「Next」ボタンを押します。

(4) ここまでの設定では、Virtual Server×1個設定しただけなので、デフォルトでその Virtual Serverが選ばれていま

す。そのまま「Next」ボタンを押します。

Existing Virtual Server を選択


108

(5) 「Create a security policy manually or user templates (advanced)」を選択し、「Next」ボタンを押します。

～略～

(6) ポリシーの名前と「Rapid Deployment security policy」設定して、「Next」ボタンを押します。

～略～

(7) 必要なシグネチャを選択し、Signature Staging を外して、「Next」ボタンを押します。

～略～


Rapid Deployment Security Policy を選択

Apache, PHP,

WordPress MySQL

を選択


109

(8) 一通り設定を確認し、「Finish」ボタンを押します。

(9) Enforcement Modeを Blockingにします。

(10) 「Apply Policy」ボタンを押します。

Blocking を選択

110

4.2.2.2. 攻撃ログ取得のための設定(Virtual Serverの設定変更)

(1) 「Local Traffic」→「Virtual servers」で表示された、作成済みの Virtual Server(WP-WAF-vs001)をクリックします。

(2) 「Security」タブ→「Policies」をクリックします。

(3) Log Profileで「Log illegal requests」を選んで、「Update」ボタンを押します。

Log illegal requests を

「<<」で選択

111

4.2.2.3. WAFの動作確認

WAFが動作しているかを確認するため、擬似的に攻撃してみます。

(1) クライアント PCのWebブラウザから BIG-IPのパブリック IPに、Webブラウザで"/test.php"にアクセスしてみます。

例) http://52.196.228.56/test.php

以下のように、攻撃として検知されます。

(2) BIG-IPでは、以下のようなログが出力されます。

「Security」→「Event Logs」→「Application」→「Request」を確認します。

"/test.php"のアクセスは、Information Leakage攻撃として検知されていることがわかります。

112

4.2.2.4. 負荷テスト向けの設定(一部のシグネチャの無効化)

BIG-IPの Auto Scalingの動作確認を行う際に、本ガイドでは Apache Benchツールを使って BIG-IPに負荷をかけま

す。

このままのWAFの設定では、Apache Benchはシグネチャでブロックされてしまうので、解除しておきます。

(1) 「Security」→「Application Security」→「Attack Signatures」で表示された画面で、Advanced Filter を使って、

Apache Benchをブロックするシグネチャに絞り込みます。

(2) Signature IDに「200021132」を入力し、「Go」ボタンを押します。

表示された「DoS tool (ab)」をクリックします。

～略～

(3) Enabledのチェックを外して無効化し、「Update」ボタンを押します。

WAFの設定は以上です。

選択

200021132

クリック


113

CloudWatchのカスタムメトリックの設定

CloudWatchで指定できるデフォルトのメトリック(CPU使用率，トラフィック量等)に加え、この設定を使えば、BIG-IP独

自の値も、CloudWatchのアラームとして利用できます。その設定方法を示します。

(1) SSHで BIG-IPにログインします。

(2) 以下のコマンドを実行します。

注) autoscale-group-idに指定する値は、AWS上で設定する BIG-IPの Auto Scalingグループ名と一致させる必要があ

ります。本ガイドでは「BIP-autoscale-001-Group」としています。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify sys autoscale-group

autoscale-group-id BIP-autoscale-001-Group

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys autoscale-group

sys autoscale-group {

autoscale-group-id BIP-autoscale-001-Group

}

(3) iCallを使って、定期的(デフォルト 60秒毎)に BIG-IP独自のメトリック値を AWSの CloudWatchに通知します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# load sys config merge file

/usr/share/aws/metrics/aws-cloudwatch-icall-metrics-config

Loading configuration...

/usr/share/aws/metrics/aws-cloudwatch-icall-metrics-config

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys icall

sys icall handler periodic autoscaleHandler {


interval 60

script autoscale

}

sys icall handler periodic metricUploadHandler {


interval 60

script uploadMetrics

}

sys icall script autoscale {

app-service none

definition {

exec /usr/libexec/aws/autoscale/aws-autoscale-pool-manager.sh

}

description none

events none

}

sys icall script uploadMetrics {

app-service none

definition {

exec /usr/libexec/aws/metrics/reportMetrics.sh

}

description none

events none

}

(4) 設定を保存します。


114

(5) AWSの CloudWatchで、「BIP-autoscale-001-Group」のカスタムメトリックスが生成されていることを確認します。

カスタム AMI生成前の処理

設定が完了した BIG-IPからカスタム AMIを生成する前に、以下のコマンドを実行する必要があります。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# run util finalize-custom-ami

Clean-up of authorized key succeeded.

Clean-up of /config/bigip.license file succeeded. Instance deployed from the Model AMI will re-license

after booting.

Clean-up of /.auto_licensed file succeeded. Instance deployed from the Model AMI will re-license after

booting.

Emptying /var/lib/dhclient/dhclient.leases succeeded. Old DHCP leases removed.

Instance ready to become Model AMI for AutoScaling.

WARNING: If you exit the current SSH session, you won't be able to log-in back without restart.

admin@(ip-10-0-1-175)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)#

BIG-IPで実施する設定は以上です。

設定した autoscale-group-id を選択

BIG-IP固有のメトリック

115

BIP-WAFのカスタム AMI

Auto Scalingする際のベースとなるイメージ＝AMIを作ります。


(2) ナビゲーションペインの「インスタンス」を選択し、作成した BIG-IP(1-NICで、WAF を設定した BIG-IP)を選び、右クリ

ックします。

「イメージ」→「イメージの作成」を選択します。




116

カスタムメトリックを使った CloudWatchアラームの作成

BIG-IPから提供されるカスタムメトリックを使って、CloudWatchのアラーム出力する設定を行います。

(1) CloudWatch設定画面に入ります。

(2) ナビゲーションペインで「アラーム」を選択し、「アラームの作成」ボタンを押します。

(3) 「カスタムメトリックス」から「BIP-autoscale-001-Group」を選択し、「次へ」ボタンを押します。

117

(4) 本ガイドでは、「クライアント側コネクション数が一定数を超えたら Auto Scaleする」という指定にします。

「client_side_traffic.cur_conns」にチェックを入れて、「次へ」ボタンを押します。

(5) 「クライアント側コネクション数が 50を超えたらアラーム出力する」と指定します。

以下のように設定し、通知は使わないので「削除」をクリックします。

「アラームの作成」ボタンを押します。

名前と説明を入力(任意)

50以上と指定

削除をクリック

118

(6) 同様の手順で、「クライアント側コネクション数が 10を下回ったらアラーム出力する」と指定します。

以下のように設定し、通知は使わないので「削除」をクリックします。

「アラームの作成」ボタンを押します。

名前と説明を入力(任意)

10以下と指定

削除をクリック

119

Auto Scalingの起動設定

BIG-IPのカスタム AMIを指定して、起動設定を行います。


(2) ナビゲーションペインの「AUTO SCALING」の下の「起動設定」を選択します。

(3) 「マイ AMI」を選択し、作成した AMIを選んで「選択」ボタンを押します。

(4) 本ガイドでは「m4.2xlarge」を選びました。「次の手順：~」ボタンを押します。

120


AWS API連携のためにはパブリック IPが必要なので、その設定を選びます。


(6) 何も変更せずに、「次の手順：～」ボタンを押します。



パブリック IP割り当てを選択

121

(7) 作成済みのセキュリティグループ「BIG-IP WAF」を選択して、「確認」ボタンを押します。

(8) 一通り内容を確認して、「起動設定の作成」ボタンを押します。




122

(10) 「この起動設定を使用して Auto Scalingグループを作成する」ボタンを押して、Auto Scalingグループ設定に移りま

す。

Auto Scalingグループの作成

作成した起動設定を使って、Auto Scalingグループを設定します。


以下のように設定します。

・グループ名は、「CloudWatchのカスタムメトリックの設定」で指定したものと同じ値※を利用してください。

・AZ1 と AZ2のサブネットの両方を指定することで、2つの AZそれぞれに BIG-IPが起動されます。

※名前(任意)を入力

最初に何台起動するか、の指定

VPCを選択

AZ1 と AZ2のサブネットを指定する

CloudWatch詳細モニタリングを有効化する


作成済み ELBを選択

123

(2) スケーリングポリシーの設定です。

ここでは、CloudWatchで作成済みの BIG-IPのクライアント側コネクション数を指定したアラームを選択します。

(3) 本ガイドでは通知は利用しませんので、そのまま「次の手順：～」ボタンを押します。

「追加」の後ろに"2"を指定

「削除」の後ろに"2"を指定

最大数に"4"を指定

作成済みのアラームを選択

作成済みのアラームを選択

選択

124

(4) 自動起動されたインスタンスのタグを指定します。

本ガイドでは、Name タグを利用することにしました。「確認」ボタンを押します。

(5) 一通り確認し、「Auto Scalingグループの作成」ボタンを押します。


(7) 開始時のインスタンス数を 2に指定したので、自動的 2つのインスタンスが生成されます。

Name を指定

(※先頭を大文字にすること) 名前(任意)を入力

125

(8) ELBから BIG-IPへのヘルスモニターが成功するまで＝「InService」になるまで待ちます。

(約 20分程度かかります。)

126

BIG-IPの Auto Scalingの動作確認

ELBの DNS名に Apache Bench ツールで負荷をかけて、BIG-IPのクライアント側コネクション数を増やします。

その結果、BIG-IP (およびWordPress)が Auto Scalingすることを確認します。

(1) ELBの DNS名を確認します。

本ガイドの ELBの DNS名は「ELB001-154611597.ap-northeast-1.elb.amazonaws.com/」です。

(2) Apache Benchを実行する Linux インスタンスを一時的に AWS上に生成します。

BIP-ext-1aまたは BIP-ext-1cなどの外部からアクセスできるサブネットに、Amazon Linux を起動します。

ELBの DNS名にアクセスできるよう、パブリック IPの割当てが必要です。

インスタンスタイプは若干大きめの「m4.xlarge」あたりがよいかと思います。

(3) Amazon Linuxに SSHでログインします。ログイン時の Usernameは「ec2-user」です。

(4) Amazon Linuxには Apache Benchがインストールされていないので、yum でインストールします。

[ec2-user@ip-10-0-1-193 ~]$ sudo yum -y install httpd

127

(5) Amazon Linuxで以下のコマンドを実行します。

[ec2-user@ip-10-0-1-193 ~]$ ab -n 99999999 -c 100 ELB001-154611597.ap-northeast-1.elb.amazonaws.com/ &

(6) しばらくすると、CloudWatchで BIG-IPのクライアント側コネクション数が 50を超えたことを警告するアラームが上が

ります。

(7) WordPressの CPU使用率が 50%を超えたことを警告するアラームも上がります。

128

(8) 結果、Auto Scalingによって、BIG-IP×4台、WordPress×8台が起動されます。

(9) 同時に、Webブラウザから ELBの DNS名にアクセスして、Webサービスができていることを確認します。

(10) 「/test.php」にアクセスして、攻撃を検知することも確認します。

129

4.3. 複数の Virtual Server を持つ BIG-IPの Auto Scaling

一つの BIG-IP インスタンスに、複数の Virtual Server を持たせた状態で Auto Scale したい、というニーズがあります。

その実現方法を記載します。

BIG-IPには、以下の 2つの Virtual Server を設定します。

VS1 10.0.0.0/16:80 VS2 10.0.0.0/16:81

VS1 と VS2それぞれ用に ELBを起動します。

VS1 ELB001 VS2 ELB002

この状態で、BIG-IP も Pool も Auto Scalingすることが可能です。

以降、設定のポイントのみ記載します。

130

BIP-WAFの設定

カスタム AMI作成前の BIG-IP インスタンスに対して、以下を実施します。

(1) BIG-IPに、Port:81の Virtual Server を追加設定します。

(2) 以下のコマンドを実行します。

admin@(ip-10-0-1-175)(cfg-sync Standalone)(Active)(/Common)(tmos)# run util finalize-custom-ami

BIP-WAFのカスタム AMI

設定変更済みの BIG-IPから、カスタム AMI を作ります。

(1) EC2→インスタンスを選択

(2) BIP-WAF インスタンスを右クリック→イメージ→イメージの作成

(3) カスタム AMI イメージ：「BIP-WAF-2VS_Base」

131

セキュリティグループの編集

セキュリティグループに、TCP/81の許可設定を行います。

ELB002の追加

ELB を一つ追加します。

ELB001 と違いは、リスナー設定のインスタンスのポートを 81にするのみです。

132

起動設定のコピーと編集

(1) 作成済みの起動設定 BIP-autoscale-001をコピーして編集します。

(2) 「AMIの編集」をクリックします。

(3) 検索フォームにカスタム AMI名の一部を入れて検索し、「選択」ボタンを押します。

(4) 「はい、～」を選択して、「次へ」ボタンを押します。

(5) そのまま「次の手順：～」ボタンを押します。

133

(6) 必要に応じて、名前を編集し、「次の手順：～」ボタンを押します。

(7) そのまま「次の手順：～」ボタンを押します。

名前を編集(任意)

134

(8) そのまま「確認」ボタンを押します。

(9) 一通り内容を確認し、「起動設定の作成」ボタンを押します。




135


Auto Scalingグループの編集

(1) 作成済みの Auto Scalingグループ：「BIP-autoscale-001-Group」を選んで、「編集」ボタンを押します。

(2) 以下 2箇所を編集します。

新しく作成した起動設定：BIP-autoscale-002を選択

ロードバランサーを追加

「保存」ボタンを押します。

BIP-autoscale-002 を選択

ELB002 を追加

136

(3) 既存の 2つのインスタンスを削除します。

(4) しばらくすると、新しく生成したカスタム AMIを使った BIG-IP インスタンスが起動します。

起動完了まで 20～25分程度です。

動作確認

以下は 2つの ELBの DNS名です。

［ELB001の DNS名］ ELB001-154611597.ap-northeast-1.elb.amazonaws.com

［ELB002の DNS名］ ELB002-92961920.ap-northeast-1.elb.amazonaws.com

それぞれにWebブラウザからアクセスして、応答があることを確認します。

例) ELB002の DNS名へのアクセス。

137

5. 終わりに

AWS上での基本的な BIG-IPセットアップに関しては以上で終了となります。

BIG-IPには、送信元 IPや Cookie を用いたセッション維持、外部 Syslogサーバへの詳細な通信ログ送信、iRule と呼

ばれるスクリプティング機能を利用したトラフィック処理のカスタマイズなど、本セットアップガイドにてカバーしきれない豊富

な機能が実装されています。使い方次第で単純な負荷分散から高度なトラフィックコントロールまで、様々にご利用頂けま

す。

また、ソフトウェアモジュールライセンスを追加することで、ネットワークファイアウォール、Webアプリケーションファイアウ

ォール、フェデレーション(シングルサインオン)、SSL-VPN機能など、アプリケーションアクセスを最適化する為の多彩な機

能が使用できるようになります。

詳細は各種WEBサイトにてご確認いただくか、購入元にお問い合わせください。

＜F5ネットワークスWEBサイトの紹介＞

F5ネットワークスジャパン総合サイト

https://f5.com/jp/homepage

F5 Tech Depot：エンジニア向け製品関連情報サイト

http://www.f5networks.co.jp/depot/

AskF5：ナレッジベース総合サイト（英語） http://support.f5.com/kb/en-us.html

DevCentral：F5ユーザコミュニティサイト（英語：アカウント登録が必要です） https://devcentral.f5.com/ F5ネットワークスジャパン合同会社

〒107-0052東京都港区赤坂 4-15-1 赤坂ガーデンシティ 19階

本資料は F5ネットワークスジャパンのエンジニアが特定のソフトウェアバージョンの動作仕様に基づいて作成した構築・設計を補助するための資料であり、メーカー公式資料とは異なります。資料の記載内

容に誤りがあった際には指摘に基づいて修正を行いますが、内容についての責任は一切負いません。また、修正、変更、改訂は予告無く行われます。

https://f5.com/jp/homepage

http://www.f5networks.co.jp/depot/

http://support.f5.com/kb/en-us.html

https://devcentral.f5.com/

amazon web services big-ip セットアップガイドmultiaz...2016/09/21 · 4 1. はじめに...

Documents