share facebook facebook twitter menu hatena pocket slack

2016.10.10 MON

Deep Security Managerを冗長構成化し、Agentとの間にELBを配置する

吉田 浩和

WRITTEN BY 吉田 浩和

こんにちは、ひろかずです。
Deep Security Managerを冗長構成にすると、負荷分散が気になりますよね。
Deep Securityでは、ELBを介した構成がサポートされています。
今回は、本当に分散されているの?という需要があったので、一筆書きます。

用語

Deep Security = DS
Deep Security Manager = DSM
Deep Security Agent = DSA

構成

今回はこんな構成を用意しました。

76dea99b-f10c-4399-771e-6704d7c71562

バージョン情報

DSMサーバ

RHEL-6.5_GA-20140929-x86_64-11-Hourly2-GP2 (ami-7df0bd4d)
Deep Security Manager 9.6.3177(9.6sp1)
Deep Security Agent 9.6.2-5022

DSA

amzn-ami-hvm-2016.03.3.x86_64-gp2 (ami-7172b611)
Deep Security Agent 9.6.2-7050

RDS

構成図には書いてませんが、RDS for Oracleを使用しています。
Oracle SE One 11.2.0.4.v8

準備

細かな手順は省略しますが、ポイントを記載します。

DSMの冗長構成化

1台目のDSMを構成した後、2台目のDSMを構成する際に、パラメータファイルにAddressAndPortsScreen.NewNode(最終行)を指定します。

# cat dsm.properties
CredentialsScreen.Administrator.Username=xxxxxxxx
CredentialsScreen.Administrator.Password=xxxxxxxx
DatabaseScreen.DatabaseType=Oracle
DatabaseScreen.Hostname=dbname.xxxxxxxx.us-west-2.rds.amazonaws.com
DatabaseScreen.DatabaseName=ORCL
DatabaseScreen.Transport=TCP
DatabaseScreen.Username=xxxxxxxx
DatabaseScreen.Password=xxxxxxxx
AddressAndPortsScreen.NewNode=True

インストールコマンドは1台目と変わりません。
途中でちょっと怖い警告が出ますが、問題ありません。

# ./Manager-Linux-9.6.3177.x64.sh -q -console -varfile ./dsm.properties
:
[WARNING] データベース内に一致するManagerノードが見つかりませんでした。アップグレード/修復を続行できません。
[WARNING] データベースを上書きすると、既存のデータがすべて削除されます。
:
Deep Security Managerを開始しています...
インストールを終了しています...

DSAを導入します。

# rpm -ivh Agent-Core-RedHat_EL6-9.6.2-5028.x86_64.rpm
準備中...                ########################################### [100%]
   1:ds_agent               ########################################### [100%]
ds_agent を起動中: [  OK  ]

DSM管理画面上のコンピュータ画面からコンピュータを新規作成し、追加したDSMサーバのIPアドレスをコンピュータ名に設定して有効化します。
Relayの有効化は必要に応じて行って下さい。(今回は追加したDSMのDSAもRelay化した前提で進めます。)

044918c4-c829-53f0-e8af-5cb3e37f34af
9b469cbf-ceac-862c-6417-b4e345ecb400

作業が完了すると、以下のような状態になっています。

bcb5e068-d45b-97c4-c9af-508d36f846bc

DSMも冗長化されていますね。

e2f01d68-3869-546a-0057-7f533e202574

ELBの用意

今回は、VPC内のDSAからの通信を受け付ける目的なので、Internal ELBを用意します。

8c2c26d4-a3e7-0123-b89c-0e17d6cf8a34

挙動を見るためにELBログを有効化しておきます。

e7784e6f-c809-5d13-2f01-0260d2016002

Security Groupは、DSAサーバからInboundでポート4119,4120,4122を空けるよう設定するといいでしょう。
2台のDSMサーバをアタッチすればELBの準備は終わりです。

DSMの設定

DSM管理画面上で、ELBで待ち受けるように構成します。
詳細画面に作成したELBのDNS名を設定します。

a04b5c2c-46e3-7c47-b45c-6935d6572700

動作確認

確認手法

ELBログで負荷分散状況を確認します。
DSMの機能(デフォルト)では、アクセスログや通信の流入状況は取得されません。

確認ポイント

ELBにはクロスゾーン・ロード・バランシング機能があります。
今回は、クロスゾーン・ロード・バランシング機能を有効化、無効化した状態それぞれでどのようにアクセスが分散されたかを確認ポイントとします。

クロスゾーン・ロード・バランシング機能「あり」の場合

ELBログをExcelに貼り付けて、解りやすく色分けしました。
ELBにアタッチされているインスタンスがZone-a, Zone-bに居るので、ELBもそこに配置されていますね。
クロスゾーンロードバランシングの機能通り、きれいにラウンドロビンされています。
ただ、ゾーンを跨ぎの転送は、転送料金がかかってしまいますね。

02cf969b-6bb3-c4fc-a8f8-cb18715431e5

クロスゾーン・ロード・バランシング機能「なし」の場合

DSAは、同じゾーンに居るDSMにアクセスしているのがわかります。
同じゾーンにDSMがいないDSAは、それぞれにアクセスしていますね。
転送量を抑えるなら、DSMがいないゾーンには、DSAを配置しないという考え方もあります。

7b86e15c-8e30-fa11-b31e-42bff44dc4ce

(おまけ)クロスゾーン・ロード・バランシング機能「なし」の場合でDSM片系を停止した場合

DSM片系(Zone-a配置)を停止した時の状態も確認してみました。
当然のことながら、稼働系に通信は流れたのですが、Zone-aに居たELBが消えて、Zone-cに移りました。
サービス維持には問題ありませんが、興味深い挙動ですね。

e621a379-d17a-a3b9-430f-f499eb31985f

負荷も分散されるというところがわかったので、今日はここまでです。
お疲れ様でした。

元記事はこちら

Deep Security Managerを冗長構成化し、Agentとの間にELBを配置する

吉田 浩和

吉田 浩和

cloudpackの中の人。 securitypackと運用、保守を中心に、構築もやってます。 エンタープライズ系SIerを経て、クラウドの最前線で奮闘の日々を送ってます。