Corp ENT 3C PPT Template Title

(1)

NSX-VDI環境でのDeep Security

9.5/9.6簡易サイジング情報

(Rev1.2)

2016/11/22

(2)

本資料について

• 本資料内に記載されているサイジング情報は過去の弊社実

績となりあくまでも指標となります。実環境での性能・動

作を保証するものではありません。

• 導入の際は、実際の使用環境を想定したパフォーマンス試

験を事前に実施いただくことを推奨いたします。

• 状況により、弊社エンジニア及びサポート担当から本資料

と異なる設定や推奨値を提示させていただくことがござい

ます。

• 本資料の再配布をご希望の場合、本資料入手先弊社担当ま

で事前にご一報ください。

(3)

Deep Security VDI-NSX環境構築注意ポイント

• 以下に分けて説明いたします

1. Deep Security Manager(DSM)

2. DSM用Database

3. DSVA

4. Deep Security Relay(DSR)

③

④

_④

①

(4)

DSM簡易サイジング

• CPU/メモリ/Disk/Network – (500～)1,000台を超えるVDIを保護する場合、DSM1ノードに割り当てるCPUは4vCPU, 最大メモリを 8GB程度に増加させる (OSへの割り当てはOSのオーバヘッド分を考慮し、12GB程度とする)ことを推奨します。 – DSMとしてのvCPU上限は特にございませんが、DSM1台のみに極端に大きなCPU/メモリを割り当てるよりDSMノード自体を増やすことによる効果のほうが大きいため、DSM1台での運用時は2台目のDSM 増設を検討してください – DSMとしてのIOPSの指標は特にございませんが、OSやDatabaseの仕様が満たされている状態であれば特に問題は確認しておりません。 – DSMはすべての構成・イベント情報をデータベースに保存するため、プログラム自体のDisk容量としては5GB程度確保いただければ問題ありませんが、障害発生時など、デバッグレベルのログを生成する場合は一時的に大量のログを保存する必要がありますので、合計10GB程度確保することを推奨します。 – DSが利用するコンポーネント間の通信に関しては最低1Gbpsの帯域を推奨しております。 • ノード数 – 1,000台を超えるVDI保護環境の場合、DSMを2台以上の構成とすることを強く推奨します – 以降、1,000台増える毎にDSMを1台追加を検討してください – 各DSMは共通のDBを使用するため、DSM5台以上の構成はスケーラビリティの観点から推奨できません。保護対象が5,000台超の場合、クラスタを分けることを検討してください

※DSMノード自体は構築完了後でも既存のサービスを停止することなく追加を行うことが

可能ですが、設計・構築フェーズを終えた後のノード・リソースの追加は場合よって再テス

トなど追加の費用・工数が発生するため、余裕を持った設計を推奨いたします。

(5)

DSMのメモリ/CPU追加について

• 使用可能メモリについて – DSMは標準インストール状態ではOSが持っているメモリ量に関わらず、4GBまでしかメモリを使用することができません – 多くのユーザケースでDSMをインストールしたOSに大量のメモリを割り当てているにも関わらず、 DSMのメモリ設定が変更されていないケースが発生しているため、DSMの最大使用可能メモリ設定が意図通り行われているか確認してください。 – DSMの最大メモリ使用量の追加方法については、下記インストールガイドのP.84「Deep Security Managerの最大メモリ使用量を設定する」を参照してください • http://files.trendmicro.com/jp/ucmodule/tmds/96/sp1/Deep_Security_9.6_SP1_Install_Guide_nsx_JP.pdf • CPU数について – DSMは利用できるCPUコア数により、同時処理できるジョブの数が自動調整される仕様となっており、少ないコア数で大量のジョブが発生する環境(例：保護対象ノードが多すぎる、同時に多数のスケジュールタスクを設定する、VDI環境で大量のvMotion、保護ノードの一斉有効化など多数の変更が同時に発生する場合)で運用した場合、ジョブ処理が遅延(失敗)する原因となります。 – 同時処理ジョブ数に上限が設定されているため、場合によりCPU負荷が低い(余裕がある)状態でも処理能力不足が発生する場合があります。

(6)

DSMのメモリ/CPU使用量の確認方法

• [管理]-[システム情報]-[システムの詳細]-[Managerノード]メニューより確認可能です。

• 以降、本メニューからその他のパフォーマンスに関する情報を得ることが可能です。

最大メモリが3.56GBと表示されている場合、デフォル ト(4GB)から最大メモリ量が変更されていない最大メモリ＝使用メモリとなっている場合、DSMは使用できるメモリ量をすべて使っている状態 DSMノードのCPU数と使用率

(7)

DSMのノード追加(クラスタ構成)の必要性

• DSMの同時ジョブ処理数と内部リソース(配分)値の確認 – DSMの同時ジョブ処理数は通常設定ではCPUコア数のみにより左右され、メモリの搭載量に影響されません。 – CPUコア数によって増加するリソースは内部CPUリソース値のみであり、DBリソース、ネットワークリソースはDSMノード毎に固定値となるため、CPUリソースの使用率が低い場合でも同時ジョブ処理数が制限されることがあります。 – DBリソース・及びネットワークリソース値を増加させるためにはDSMノードの追加が必要となります(内部パラメータの変更によっても変更は可能ですが、公開可能な資料はございません) CPUリソース値のみ割り当てられたCPUコア数に応じて増加 DBリソース、ネットワークリソースは100のまま

(8)

DSMのリソース使用状況

• リソース使用状況の確認 – リソースの利用状況については瞬間値の確認は可能ですが、現状長時間の履歴をモニタ、ログに記録する機能はありません – 累積負荷が最大リソース量を頻繁に超えるような状況が見られた場合、処理能力不足が発生している状況です。(超えていても、必ずしも問題が発生するわけではありません) 最大リソース量に対する瞬間使用値情報更新ボタン累積負荷が最大リソース量を超える値が頻繁に発生する場合、リソース不足の傾向がある

(9)

DSM用簡易DBサイジング

• DBノードについて

–

DSMノードとの同居はDSMの2台構成が必要など、一定規模以上の環境では同居は非推

奨、DSMノードとは別ノードとすることを推奨

–

必ずしもDBサーバ自体をDSM専用ノードとする必要はありません。

他システムのDBと共用されることが考えられます。

• メモリ/CPU

–

DSMの情報はすべてDBに記録されるため、DB側でボトルネックとならないように設定

–

CPUは4~8vCPU, 8GB~16GBメモリ程度(Windows /SQL Server環境)

• ディスク容量

–

各DS Agent/VA上でのイベント発生量やイベント保持期間設定により、必要なディスク

(10)

DB簡易パフォーマンス確認

• 簡易確認方法

– データベースクエリに対する時間を確認することにより簡易的にDBパフォーマンスを確認することが可能です。 – 2msを超える値が見られる場合、DB側の処理能力不足を確認する必要があります。 2ms (2,000,000 ns)を超えていないこと

(11)

DSVA簡易サイジング

• DSVAの使用リソースは、Deep Securityのどの機能を利用するかにより、大幅に変動しま

す。

–

不正プログラム対策のみ使用する場合

• デフォルト(2vCPU / 4GBメモリ)でカバーできるケースが多いと想定されます。 • 集約率が100台超の場合、4vCPU/8GB程度に設定することを推奨します。 • 以降、＋50台毎に2vCPU、2GB追加を想定しております。こちらも過去の弊社実績となり、あくまでも指標となります。

–

侵入防御・変更監視を併用する場合

• 使用するルール数や、流れているトラフィックにより、消費されるメモリが増加するため、メモリ使用率が高くなる傾向にあります。 • 集約率が低い(50台程度)場合でも4vCPU/8GB程度に設定しておくことを推奨 ※大量の不必要なIPSルールが適用されていた環境では60台程度の集約率にもかかわらず、10GBほどのメモリが消費されていた実例あり

(12)

DSVAの負荷状況確認(診断パッケージ)

• DSVAの診断パッケージから過去の負荷状況を確認することが可能です

• 使用方法

1. 取得した診断パッケージを解凍し、¥Agent¥dsva¥charts.htmlをFireFoxまたはChromeで開く 2. 参照ボタンを押し、診断パッケージの¥Agent¥dsva¥system_stat.csvを選択する Tips: 表示はUTC（協定世界時）表記 となるため、JTC(日本標準時)は表示 の時間からグラフから+9時間して読 み取ります。

(13)

Deep Security Relay(Relay機能有効化済みDSA)サイジング

• 設置ノードについて – DSMと同居でインストールされるケースが一般的です。 – 通常のパターンやコンポーネントのダウンロード機能に加え、VDI環境ではvMotion時のDSVA 間の設定移行の際に利用されるため、最低でもDSM設置ノード数と同数以上のDSRを用意 [DSMノードに同居]することを推奨します。 • CPU/メモリ/Disk/Network – DSRをDSMと同居で利用する場合、DSR用にCPU/メモリなどを追加いただく必要は特にございません。DSR単体で利用する場合、OS自体が問題なく動作するCPU/メモリ量を確保ください。 – DSRはエンジン、ルール、パターンなどのコンポーネントに加え、Agentなどのアップグレード用プログラムを配信するためにローカルDiskへ保存します。これら配信用データのために追加で10GB程度のDisk容量を確保ください。 • Relayグループ – 複数のRelayノードを含んだRelayグループを構成し、サービスを提供するAgent(DSVA)を限定できるため、大規模環境ではVDIのグループ単位などに対してRelayグループを割り当てることが可能です。

(14)