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

用語

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

構成

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

バージョン情報

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化した前提で進めます。)

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

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

ELBの用意

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

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

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

DSMの設定

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

動作確認

確認手法

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

確認ポイント

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

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

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

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

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

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

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

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

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

用語

構成