通信フロー：一覧

• 概要
• DSVAの展開時
• 仮想マシンのvMotion時
• 不正プログラム対策機能の動作時（NSX-V編）
• 不正プログラム対策機能の動作時（NSX-T編）
• Webレピュテーション、ファイアウォール、侵入防御機能の動作時（NSX-V環境）
• Webレピュテーション、ファイアウォール、侵入防御機能の動作時（NSX-T環境）

通信フロー：概要

• 通信1：DSMとNSX-V/T Manager, vCenter間の通信

  仮想マシンの管理情報やNSXセキュリティグループの設定を取得します。

• 通信2：DSMとDSVA間の通信

  ハートビートや各種イベントの送付、タスクの実行命令、仮想マシンの管理情報などのやり取りを行います。

  DSVA管理下の各仮想マシンは直接DSMとの通信を行いません。各仮想マシンに対応したVirtual Agent（仮想マシンの管理情報）が管理下のDSVA上に作成され、DSVAがDSMと通信を行います。

  例外としてコンバインモードの実施時があります（コンバインモードに関してはこちらを参照ください）。コンバインモード実施時は仮想マシンの管理情報はDSVA側で管理されるVirtual Agentと仮想マシン内で実行されるAgentの2つがございます。 Virtual Agentは引き続きDSVAにより管理され、DSVAがDSMと通信を行います。AgentはAgent自身がDSMと通信を行います。DSMからAgentへの通信の際はDSMはvCenterから引き渡された仮想マシンのIPアドレス（1つ）を元にAgentと通信を行います。そのため、インタフェースが複数存在する場合は期待外のIPアドレスが引き渡される可能性があります。 その場合は引き渡されたIPアドレスの使用ではなく、DSMから仮想マシンへの名前解決を行うよう設定変更を行うことで回避が可能となります。詳細は製品Q&A： DSMからDSVAや仮想マシンへの通信時、名前解決をしていない を参照ください。

• 通信3：DSMとRelay間の通信

  ハートビートやセキュリティアップデートなどを行います。

• 通信4：DSVAからRelayへの通信

  セキュリティアップデート、アップデート用のソフトウェアの取得などを行います。

• 通信5：DSVAからSmart Protection Networkへの通信

  Smart Protection Network へのクエリを行います。

  5274ポートへの通信はLocal Smart Protection Networkが対象

• 通信6：Relayからダウンロードセンターへの通信

  ダウンロードセンターから最新のセキュリティアップデート、ソフトウェアアップデートの取得します。

通信フロー：DSVAの展開時

• 通信1：DSMとNSX-V/T Manager, vCenter間の通信

  DSVAのovfファイルやNSXセキュリティグループ、仮想マシンの管理情報の取得などを取得します。その後、ESXiにOVF情報、DSVAの情報（IPアドレスやNWラベルなど）が連携されESXi上でDSVAが展開されます。2台目以降は1台目のDSVAのスナップショットが各ESXi上に展開されます。

• 通信2： DSMとDSVA間の通信

  DSVAの展開後、DSVAが有効化されます。

• 通信3：DSVAとDSRの通信

  DSVAの有効化後、[DSM管理コンソール]>[システム設定]>[アップデート]タブ>[Virtual Applianceの配置]に設定されたバージョンにDSVAが自動的にアップグレードされます（初期設定ではDSM内の最新のビルドにアップグレードされます。詳細はこちらを参照ください）。その後、セキュリティアップデートが実施されます。

通信フロー：仮想マシンのvMotion時

• 通信1：DSMとNSX-V/T Manager, vCenter server間の通信

  仮想マシンの移動情報（どのESXiで管理されるかなど）の取得を行います。

• 通信2：DSMおよびDSVA間の通信

  仮想マシンの移動情報を受け、仮想マシンの移動元DSVA上で仮想マシンの管理情報（Virtual Agent）の削除し、一部管理情報をRelayに送信します。移動先DSVA上にて仮想マシンの管理情報（Virtual Agent）を作成、Relayから一部管理情報を取得します。

通信フロー：不正プログラム対策機能の動作時（NSX-V編）

• 通信1：仮想マシンとvShield-Endpoint-MUX（以下、MUX）プロセスへの通信

  仮想マシンのVMware Tools内のVMCIからESXi上のMUXプロセスへの通信。通信3まで完了後に不正プログラムのスキャンが行える状態となる。

• 通信2：MUXからGuest Introspectionへの通信

  MUXからGuest Introspectionの169.254.1.24:48655ポートにセッション構築される。

• 通信3：MUXからDSVAへの通信

  MUXとGuest Introspectionのセッションが構築後、MUXからDSVAの48651ポートにセッションが構築される。セッション構築完了後、仮想マシンからのスキャン情報の処理が可能となる。

• 通信4：DSMとDSVAの通信

  構築された通信3のセッション情報 （不正プログラム対策機能のドライバがオンライン）がハートビートにてDSMに送られ、該当仮想マシンの不正プログラム対策機能のステータスがオンとなる。

通信フロー：不正プログラム対策機能の動作時（NSX-T編）

• 通信1：仮想マシンとContext Multiplexer （以下、MUX）プロセスへの通信

  仮想マシンのVMware Tools内のVMCIからESXi上のMUXプロセスへの通信。通信2まで完了後に不正プログラムのスキャンが行える状態となります。

• 通信2： MUXからDSVAへの通信

  MUXからDSVAの48651ポートにセッションが構築されます。セッションの構築完了後、仮想マシンからのスキャン情報の処理が可能となります。

通信フロー：Webレピュテーション、ファイアウォール、侵入防御機能の動作時（NSX-V環境）

• 通信1：仮想マシンへのパケットの受信

  仮想マシン宛の通信パケットをESXiが受信

• 通信2：dvfilterからDSVAへの通信のリダイレクト

  ESXi上のdvfilterドライバからDSVAのdsa_slowpath_nx プロセスへパケットが転送されDSVAにて処理されます。

• 通信3：dvfilterから仮想マシンへの通信のリダイレクト

  DSVAでのパケット処理後にパケットのドロップに該当しない場合、ESXi上のdvfilterドライバから仮想マシンへパケットが転送されます。

• 通信4：DSMとDSVAの通信

  ハートビートや各種イベントの送付など

通信フロー：Webレピュテーション、ファイアウォール、侵入防御機能の動作時（NSX-T環境）

• 通信1：仮想マシンへのパケットの受信

  仮想マシン宛の通信パケットをESXiが受信

• 通信2：dvfilterからDSVAへの通信のリダイレクト

  ESXi上のdvfilterドライバからDSVAのdsa_slowpath_nsxt プロセスへパケットが転送されDSVAにて処理されます。この時、仮想マシンとDSVAが同じトランスポートゾーンオーバレイに属している必要があります（詳細はこちら）。

• 通信3：dvfilterから仮想マシンへの通信のリダイレクト

  DSVAでのパケット処理後にパケットのドロップに該当しない場合、ESXi上のdvfilterドライバから仮想マシンへパケットが転送されます。

• 通信4：DSMとDSVAの通信

  ハートビートや各種イベントの送付など

お問合せ時にはご利用いただいております環境上のDeep Security/VMware製品のバージョンをご確認させていただきます。本ドキュメントを参考に各コンポーネントのバージョンをご確認ください。 なお、バージョン間の互換に関しましてはこちらを参照ください。

バージョン確認一覧

• Step 1DSM
• Step 2Relay/DSA
• Step 3DSVA
• Step 4vCenter,ESXi Server
• Step 5NSX-V Manager
• Step 5NSX-T Manager
• Step 6vCenter tools,Guest Introspectionドライバー

DSMのバージョン確認

[DSM管理コンソール]>画面右上の[サポート情報]>[バージョン情報]

Relay/DSAのバージョン確認

[DSM管理コンソール]>[コンピュータ]>対象のコンピュータの[詳細]>[概要]>[処理]タブ>Agentソフトウェア内のバージョン

DSVAのバージョン確認

[DSM管理コンソール]>[コンピュータ]>対象のコンピュータの[詳細]>[概要]>[一般]タブ>Virtual Applianceのバージョン、Appliance（SVM）のバージョン

vCenter ServerとESXiのバージョン確認

[vCenter Serverの管理コンソール]>[グローバルインベントリリスト]>[リソース]>[vCenter Server]>[サマリ]

[vCenter Serverの管理コンソール]>[グローバルインベントリリスト]>[リソース]>[ホスト]>[サマリ]

NSX-V Managerのバージョン確認

• NSX-V Managerのバージョン

  [vCenter Serverの管理コンソール]>[Networking and Security]>[NSX ホーム]>[サマリ]

  

  Deep Security環境でNSXを使用する際は、使用するライセンスにより一部機能に制限が生じるため、ライセンスのエディションは重要な情報となります。 詳細はこちらを参照ください。

  ---

• Guest Introspectionのバージョン

  [vCenter Serverの管理コンソール]>[Networking and Security]>[インストールとアップグレード]>[サービスの展開]

  

  Guest Introspectionは不正プログラム対策および変更監視の機能利用時に使用されます。

  ---

• Network Introspectionのバージョン

  [vCenter Serverの管理コンソール]>[Networking and Security]>[インストールとアップグレード]

  

  Network IntrospectionはWebレピュテーション、ファイアウォール、侵入防御の機能利用時に使用されます。

  ---

NSX-T Managerのバージョン確認

[NSX-T managerの管理コンソール]>[システム]>[アプライアンス]

vCenter tools/Guest Introspectionドライバーのバージョン確認

• vCenter toolsのバージョン

  確認対象の仮想マシンにログイン>デスクトップ上のVMアイコンを右クリック>[VMware Toolsについて]

  

  ---

• Guest Introspectionドライバーのバージョン

  [ファイル名を指定して実行]から[C:\Windows\System32\drivers]>[vsepflt.sys]を右クリック>プロパティ

  

  留意事項

  VMware Tools にはNSX File Introspection Driver/NSXファイル自己検証ドライバ（旧：Guest Introspectionドライバー）が同梱されていますが、標準インストールではインストールされないため、Vmware Toolsのインストール時にカスタムorコンプリートインストールでNSX File Introspection Driverをインストールする必要があります。
  
  VMware Toolsカスタムインストール時の選択画面
  
  DSVAの動作におきまして、NSX Network Introspection Driver/NSX ネットワーク自己検証ドライバのインストールは不要です（詳細はこちら）。

  ---

DSM/Relay/DSA

DSVA

1. vCenter管理コンソールにログイン
2. [ホスト及びクラスタ]>対象のDSVAを右クリックし[電源]>[ゲストOSの再起動]

Guest Introspection VM(NSX-V環境)

1. vCenter管理コンソールにログイン
2. [ホスト及びクラスタ]>対象のGuest Introspection VMを右クリックし[電源]>[ゲストOSの再起動]

vShield-Endpoint-Mux(NSX-V環境)

1. ESXiにログインします。

2. 以下のコマンドを実施します。

   /etc/init.d/vShield-Endpoint-Mux restart

   

   起動後、以下のコマンドにてサービスがrunningとなっていることを確認ください。

   /etc/init.d/vShield-Endpoint-Mux status

nsx-context-mux(NSX-T環境)

1. ESXiにログインします。

2. 以下のコマンドを実施します。

   /etc/init.d/nsx-context-mux restart

   

   起動後、以下のコマンドにてサービスがrunningとなっていることを確認ください。

   /etc/init.d/nsx-context-mux status

DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理si障害点を洗い出すことがトラブルシュートのポイントとなります。

対応Step一覧

• Step 1問題発生対象の確認
• Step 2トラブルシューティング

【Step1】問題発生対象の確認

「不正プログラム対策エンジンがオフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A：DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。

【Step2】トラブルシューティング

整理した発生状況からトラブルシューティングを実施します。本項記載の「不正プログラム対策エンジンがオフライン」アラートの発生要因としましては主にMUXからDSVAの169.254.1.39:48651にセッションが張れていない状態が考えられます

• NSX-V環境の場合は以下図の通信3が該当します。（DSVA環境の通信フロー図の不正プログラム対策機能の動作時（NSX-V編）より抜粋）

  

  ---

• NSX-T環境の場合は以下図の通信2が該当します。（DSVA環境の通信フロー図の不正プログラム対策機能の動作時（NSX-T編）より抜粋）

  

  ---

※通信の詳細な解説は[DSVA環境の通信フロー]の項を参照ください

そのため、まずはDSVAの169.254.1.39:48651にMUXからセッションが構築されているかを確認します。

セッションの確立がされていない場合、その要因としては以下が考えられます。

• 要因1：セキュリティグループの設定

  確認ポイント

  • 対象仮想マシンにセキュリティグループ（NSX-V環境） or エンドポイント保護（NSX-T環境）の設定がされていない

  対処法

  • 設定されているセキュリティグループ（NSX-V環境） or エンドポイント保護（NSX-T環境）に対象の仮想マシンが含まれているかご確認ください。

    確認方法

    NSX-V環境の場合はApplianceのインストール (NSX-V)の[手順6：NSXセキュリティグループとポリシーを作成する]を参照ください。

    NSX-T 3.0未満の環境の場合Applianceのインストール (NSX-T)の[手順5: エンドポイント保護を設定する]を

    NSX-T 3.0以上の環境の場合アプライアンスを配信する（NSX-T 3.x）Endpoint Protectionの設定を参照ください。

  • 設定に問題がない場合、設定項目がDSMに同期されていない可能性があります。
    製品Q&A：DSVA環境のトラブルシューティングステップ>Step2>「vCenter/NSX Manager同期確認」 を参照しDSMとvCenter/NSX Managerとの同期を実施ください。

  ---

• 要因2：仮想マシン/VMware Toolsが起動していない

  確認ポイント

  • 仮想マシンがスリープになっていないか
  • 仮想マシンにVMware Tools及びGuest Introspectionドライバ(vsepflt)がインストールされているか
  • 仮想マシン上でVMware Toolsが起動しているか
  • Guest Introspection関連ドライバ(vsepflt/vmci)が停止していないか

  対処法

  • 仮想マシンにログインを行い、下記製品Q&Aをご参照の上、VMware Tools関連モジュールの正常性確認を実施ください。

    製品Q&A：DSVA環境のトラブルシューティングステップ >Step2>「保護対象仮想マシンのステータス確認(仮想マシンにログインの上確認)」>「Guest Introspectionドライバー状態（不正プログラム対策/変更監視機能利用時）」

  • 上記に問題がない場合、モジュールの読み込みのため対象仮想マシンのOS再起動を実施ください。

  • VMware toolsを最新版へアップデートください。

    VMware Toolsに関しましてはVMware製品側の互換性を満たしているかご確認ください（製品Q&A：Deep Security and VMware compatibility matrix（英語のみ）のVMware toolsの項を参照ください）。

  ---

• 要因3：MUXからDSVAへの通信有無

  確認ポイント

  • DSVAが正常動作しているか
  • Guest Introspection VMが存在/正常動作しているか（NSX-V環境のみ）
  • MUXプロセスが正常動作しているか

  対処法

  • 対象仮想マシンをvMotionなどで別のESXi上、別のDSVAの管理下に移動させセッションが構築されるか確認します。

    1. 対象仮想マシンの移動にてセッションが構築される場合は移動元のDSVA,Guest Introspection VM, MUXプロセスのいずれかが正常に動作していない可能性があります。

       製品Q&A：DSVA環境のトラブルシューティングステップ >Step2 にて各コンポーネントの正常性を確認ください。確認結果にて障害点が確認された場合、関連コンポーネントの再起動（各再起動の手順は本製品Q&A内の[各コンポーネントの再起動方法]を参照ください）、もしくはDSVA および Guest Introspection VMの再配信（再配信手順は本製品Q&A内の[DSVAの再配信方法]を参照ください）を実施することで事象の改善が見込まれます。

    2. 対象仮想マシンの移動にてセッションが構築されない場合はその他の要因が問題の可能性があります。

  ---

要因1から3の対処法にて改善が見られない場合、その他の要因としては以下が考えられます。

• 要因4：環境負荷

  ポイント

  • 環境負荷が高くDSVAの動作が安定しない

  対処法

  • DSVAの再起動（[各コンポーネントの再起動方法]の項を参照ください）
  • DSVAの再配信（[DSVAの再配信方法]の項を参照ください）

  DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる（目安としてCPUの場合は6～8core程度、メモリの場合は12～16GB程度）ことで事象が改善するかをご確認ください。

  ---

• 要因5：NSXコンポーネントの不具合

  NSX-Vでは「不正プログラム対策エンジンのオフライン」エラーが発生する不具合が多数報告されております。いずれもNSX-V Manager 6.4.4以上にて修正がされているものとなりますため、6.4.4以上でのご利用をご検討ください。

  • NSX-V Manager 6.4.1関連：
    Anti-Malware engine offline issue occurs when deploying Deep Security Virtual Appliance in NSX 6.4.1

  • NSX-V Manager 6.4.3関連：
    VMware NSX Data Center for vSphere 6.4.4 リリース ノート

    解決した問題 2216582：一部の仮想マシンがアンチウイルスで保護されないメモリ使用率が高いために仮想マシンの UUID が変更されると、変更後の仮想マシンに新しい設定が適用されません。一部の仮想マシンがアンチウイルスで保護されなくなります。

条件

• 不正プログラム対策機能のリアルタイム機能がオン
  →手動検索や予約検索のみの設定では使用不可

• 「不正プログラム対策エンジンのオフライン」ステータスが発生していない

• ドライバレベル（ディレクトリ）の検索除外でNotifier用のファイルを除外していない
  →詳細は製品Q&A：Deep Security Notifier のステータスが「不明/到達不能」になっているを参照ください

DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理し障害点を洗い出すことがトラブルシュートのポイントとなります。

【Step1】問題発生対象の確認

まずは「ファイアウォール/侵入防御エンジンがオフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A：DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。

【Step2】トラブルシューティング

• 要因1：Network Introspection設定ミス

  • 対処法(NSX-V環境の場合)

    [vCenter管理コンソール]>[ホーム]>[ネットワークとセキュリティ]>[Service Composer]>[セキュリティグループ]メニューでセキュリティポリシーのネットワークイントロスペクションサービスが設定されていること、セキュリティグループに該当の仮想マシンが所属していることを確認してください。

    

    ---

  • 対処法(NSX-T環境の場合)

    NSX-T環境でのネットワーク機能の利用の場合、Network Introspection設定が誤っている場合でもDeep Security上の管理コンソールでは特段エンジンオフラインといったエラーは発生しないものとなります。DSVA自体はパケットのリダイレクトを常時待っている状態となるためです。 そのため、本機能を利用時は必ず以下のリダイレクト設定をご確認ください。 Network Introspection設定確認ポイントは以下を参照ください。なお、詳細な解説はこちら を参照ください。

    1. [NSX-T管理コンソール]>[セキュリティ]>[設定]>[ネットワークイントロスペクション]メニューでサービスセグメント、サービスプロファイル、サービスチェーンの設定がされていること
       
       
       
       

    2. [NSX-T管理コンソール]>[セキュリティ]>[East-Westのセキュリティ]>[ネットワーク イントロスペクション (E-W)]にてリダイレクトポリシーおよび仮想マシンに対するルールが設定されていること
       

    補足

    NSX for vShield Endpoint ライセンスご利用時などでNSX側機能に制限がある場合でもDeep Security側のライセンスに問題がなければWebレピュテーション、ファイアウォール、侵入防御機能の機能を自体をオンにすることは可能となります （NSX側のライセンスに対するDeep Security側で使用可能となる機能に関しましてはこちらを参照ください）。 しかしながら、DSVAへのパケットのリダイレクトがされない状態となりますため、該当機能での処理は行われないものとなります。また、Deep Secutrity側にて特段エラーなどは発生しないものとなりますことをご留意ください。
    
    

• 要因2：DSVA or ESXi側プロセスの障害

  対処法

  DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる（目安としてCPUの場合は6～8core程度、メモリの場合は12～16GB程度）ことで事象が改善するかをご確認ください。

  1. ESXiにログイン

  2. 製品Q&A：DSVA環境のトラブルシューティングステップ>[Step 2環境の正常性確認]にて以下を確認ください。

     • DSVAのステータス確認
     • NSX 関連コンポーネントのステータス確認（NSX-V環境用）>Network Introspectionの状態確認(Webレピュテーション/ファイアウォール/侵入防御機能の利用時のみ)
     • ESXiコンポーネントのステータス確認>Webレピュテーション/ファイアウォール/侵入防御機能ご利用時
  3. DSVAの再起動（[各コンポーネントの再起動方法]の項を参照ください）
  4. DSVAの再配信（[DSVAの再配信方法]の項を参照ください）

侵入防御などの機能を一度有効化し、オフラインエラーが発生した後機能を無効にしても侵入防御/ファイアウォールエンジンオフラインエラーがクリアできない場合があります。
機能を無効化してもエンジンオフラインが消去できない場合、該当機能を無効にした後、一旦「Appliance保護の無効化」を実行し、その後再度「有効化」してください(この際、「再有効化」は選択しないでください)。

DSVAはVMware側の複数のコンポーネントと密接に連携することにより動作しております。そのため、Deep Security側コンポーネントのみでエラーが発生している場合でもVMware側コンポーネントの設定や動作不良によって発生する可能性もございます。 そのため、「どのESXi上」で「何台中何台の仮想マシン」に「どのようなタイミング」で「何のアラート」が発生しているかを整理し障害点を洗い出すことがトラブルシュートのポイントとなります。

対応Step一覧

• Step 1問題発生対象の確認
• Step 2トラブルシューティング

【Step1】問題発生対象の確認

まずは「オフライン」アラートがどのESXi上で何台の仮想マシンで発生しているか、 製品Q&A：DSVA環境のトラブルシューティングステップ>「【Step1】問題発生対象」の確認をもとにパターンを分類し発生対象ESXiと仮想マシンを整理します。

【Step2】トラブルシューティング

• 特定 or 複数の仮想マシンのみで発生している場合

  要因

  • DSMが仮想マシンの配置情報を取得できていない
  • DSVAの保有するVirtual Agentが破損している

  対処法

  1. DSVA環境のトラブルシューティングステップ>【Step2】環境の正常性確認>「vCenter/NSX Manager同期確認」を参照しDSMとvCenter/NSX Managerとの同期を実施ください。

     実施後、「警告/エラーのクリア」、「ステータスの確認」にて事象が改善するかを確認ください。

  2. 改善しない場合、該当の仮想マシンで「無効化」を実行後、「有効化」を実行(再有効化ではなく、一旦無効化後の有効化を実施ください)

     無効化-再度有効化を行うことによりDSVA内の保護対象マシンごとの設定(Virtual Agent)が消去/再作成されます。

     

  ---

• 1台のESXi上のすべての仮想マシンで発生している場合

  要因

  • 仮想マシンを管理しているDSVAが動作していない
  • DSVA自身のステータスがオフラインとなっている
  • DSVAがDSMの名前解決を出来ていない
  • DSM/DSVAの負荷が高い

  対処法

  1. DSVA環境のトラブルシューティングステップ>【Step2】環境の正常性確認>「vCenter/NSX Manager同期確認」を参照しDSMとvCenter/NSX Managerとの同期を実施ください。

     実施後、対象のDSVAにて「警告/エラーのクリア」、「ステータスの確認」にて事象が改善するかを確認ください。

  2. DSMにてハートビート拒否イベントが発生しているかを確認。詳細は製品Q&A：「Agent/Applianceのハートビートの拒否」イベントが発生するをご確認ください。

  3. 対象DSVAにログイン(ログイン方法は[DSVAへのログイン・SSHの有効化方法]を参照ください)

     • DSMへのハートビートをコマンドにて実施し、「HTTP Status:200 OK」が返ってくることを確認

       sudo /opt/ds_agent/dsa_control -m

       

     • 「HTTP Status:200 OK」以外の場合、DSVAがDSMの名前解決を行えているか確認（参考製品Q&A：[HowTo] DNS がない、または正しく構成されていない環境での運用方法）

       ping "DSMのFQDN"

       ※nslookup,digコマンドは用意されてませんため、名前解決の確認にPingを使用します。

       >DSMのFQDNは[DSM管理コンソール]>[管理]>[Managerノード]から確認可能です。
       

        

       ※DSMが複数存在する環境の場合はすべてのDSMのFQDNに対して実施ください。

       [管理コンソール]>[管理]>[システム設定]>[詳細]にてロードバランサの設定をされている場合は設定されたFQDNに実施ください。
       

  4. DSMにて対象DSVAのポリシーを切り分けのためなしに設定（後で設定を戻してください）

     

  5. 対象DSVAの再起動を実施（[各コンポーネントの再起動方法]を参照）

  6. 対象DSVAの再配信を実施（[DSVAの再配信方法]を参照）

  7. 再発する場合は対象DSVAのリソースを追加

     DSVAの再起動、再配信によるリフレッシュにて改善し、事象が再発する場合は環境負荷が高い可能性がありますので改めて サイジングをご確認ください。なお、サイジング表上リソースが満たされている環境であっても使用状況によりましてはリソースが不足している可能性がございます。 そのため、再起動後に再発がされる場合は一時的にでもDSVAに設定されているCPUおよびメモリリソースを段階的に上げる（目安としてCPUの場合は6～8core程度、メモリの場合は12～16GB程度）ことで事象が改善するかをご確認ください。

  8. 改善が見られない場合、DSMの再起動を実施（[各コンポーネントの再起動方法]を参照）

     DSMの使用する最大メモリ量は初期設定4GBとなっております。 こちらはインストールフォルダ内の「.vmoptions」ファイルにて調整が可能です（物理メモリが16GBなど搭載されている場合でも本ファイルに設定されております値が 最大値となります。詳細はDeep Security Managerのメモリ使用量の設定を参照ください）。 DSMの再起動後も時間の経過で再発する場合はメモリが不足している可能性がありますので、 サイジングをご確認いただき、最大メモリ量の調整を検討ください。 なお、複数台のDSMが存在する環境の場合は全台にて実施ください。