Cisco Secure Workload クラスタ間の移行

この章では、移行パス、前提条件、制限事項、および移行を実行して成功を確認するためのワークフローガイダンスに関する段階的なプロセスの概要を示します。このプロセスでは、Cisco Secure Workload M4 または M5 クラスタから、39RU や 8RU などの一致するフォームファクタを持つ M6 クラスタにデータと構成を移行します。

この章は、次の項で構成されています。

クラスタ間の移行の概要

Cisco Secure Workload のプライマリクラスタからスタンバイクラスタにデータを転送する場合は、Data Backup and Restore（DBR）方式を使用することを推奨します。DBR を使用すると、プライマリクラスタから S3 互換ストレージにデータがコピーされ、同じデータがストレージからスタンバイクラスタに復元されます。特定の移行ニーズに応じて、「リーンモード」または「完全モード」のバックアップを選択できます。

リーンバックアップモードまたは完全バックアップモードの詳細については、『Cisco Secure Workload ユーザーガイド』の「Data Backup and Restore (DBR)」の項を参照してください。


（注）  

このガイドでは、プライマリクラスタは M4 または M5 ですが、M6 はスタンバイクラスタとして参照されています。

エンドツーエンドの移行ワークフロー

Cisco Secure Workload では、クラスタ間の移行は複雑なプロセスです。スムーズな移行を確保するには、プライマリクラスタからスタンバイクラスタにデータを移行するために必要な手順の概要を示すエンドツーエンドのワークフローに従います。移行アクティビティを最大化するには、各手順を順番に実行することが重要です。

図 1. 移行の準備

プライマリクラスタとスタンバイクラスタの前提条件

プライマリクラスタとスタンバイクラスタの前提条件には、いくつかの手順と考慮事項が含まれています。

プライマリクラスタ構成

プライマリクラスタ構成には、ストレージ、データバックアップ、クラスタデータのバックアップ、帯域幅、および WAN リンク管理の設定が含まれます。

スタンバイクラスタ構成

スタンバイクラスタの設定には、スタンバイモードでのスタンバイクラスタの展開、保管場所の設定、およびプリフェッチされたデータの確認が含まれます。

復元前の検証

復元プロセスを開始する前に、スタンバイデータストレージ構成、プライマリとスタンバイのクラスタ構成、クラスタ間のピアリングを確認し、両方のクラスタのファイアウォールルールが同一であるか確認します。

スタンバイクラスタでのデータの復元

スタンバイクラスタでデータを復元して、クラスタデータをプリフェッチし、クラスタデータを復元します。

復元後および DNS 反転前の検証

スタンバイクラスタでデータを復元したら、包括的な検証プロセスを実行します。このプロセスには、インベントリとラベルの確認、パイプラインのアクティブ化、サービスに関する緑色のステータスの検証、範囲ツリーの永続化、フローカウントがプライマリクラスタと一致することの確認が含まれます。

データ移行の検証

スクリプトを使用して、復元プロセスの完了後にプライマリクラスタとスタンバイクラスタの両方に着信するフローデータを検証できます。

クラスタ間の移行の準備

Cisco Secure Workload のプライマリクラスタからスタンバイクラスタにデータを移行する場合は、Data Backup and Restore アプローチを使用することを推奨します。このアプローチには、プライマリクラスタから S3 互換ストレージへのデータのコピー、そのストレージからスタンバイクラスタへのデータの復元が含まれます。特定の移行要件に応じて、リーンモードまたは完全モードのバックアップを選択できます。

リーンモードまたは完全モードバックのアップの詳細については、『Cisco Secure Workload ユーザーガイド』の「Data Backup and Restore (DBR)」の項を参照してください。

プライマリクラスタとスタンバイクラスタの前提条件

ご使用の環境が次のハードウェアおよびソフトウェア要件を満たしていることを確認します。

外部オブジェクトストレージの設定

  • S3v4 標準に準拠した外部オブジェクトストレージが使用可能であることを確認します。

  • 39RU および 8RU クラスタの場合、完全バックアップの場合は 50TB のストレージ容量を推奨しますが、リーンバックアップの場合は最小の 1TB で十分です。詳細については、「Object Store Requirements」を参照してください。

  • プライマリクラスタとスタンバイクラスタの組み合わせのリスト。

    表 1. クラスタ SKU

    プライマリクラスタ SKU

    スタンバイクラスタ SKU

    8RU-PROD

    8RU-M4 

    8RU-M5

    8RU-M6 

    39RU-GEN1

    39RU-M4

    39RU-M5

    		 39RU-M6 

有効な Data Backup Restore ライセンスの取得

有効な Data Backup Restore（DBR）ライセンスを取得するには、Cisco TAC にケースを送信します。ソフトウェア利用資格は、プライマリクラスタにのみ必要で、スタンバイクラスタには必要ありません。

帯域幅の考慮事項

  • プライマリクラスタから S3 サーバーにデータをバックアップし、スタンバイクラスタにデータを復元する場合は、10Mbps 以上の帯域幅を推奨します。

  • オブジェクトストアがプライマリクラスタとスタンバイクラスタの両方に近い場所にあることを確認します。

ハードウェアおよびソフトウェアの要件

  • 移行を開始する前に、プライマリクラスタとスタンバイクラスタが同じフォームファクタ（8RU または 39RU）であることを確認します。データ移行は、同じフォームファクタのクラスタ間でのみ実行されます。詳細については、『Cisco Secure Workload M6 クラスタ導入ガイド』を参照してください。

  • プライマリクラスタを最新バージョンの Cisco Secure Workload 3.9 にアップグレードし、スタンバイクラスタに同じバージョンを展開していることを確認します。プライマリクラスタとスタンバイクラスタのソフトウェアエージェントのバージョンは同じである必要があります。詳細については、「Cisco Secure Workload リリース 3.9.1.1 へのアップグレード」を参照してください。

  • Data Backup and Restore 機能を使用するには、ソフトウェアエージェントのバージョンが 3.3 以降であることを確認します。エージェントのバージョンを確認するには、ナビゲーションウィンドウで、[管理（Manage）] > [ワークロード（Workloads）] > [エージェント（Agents）] > [エージェントリスト（Agent List）]の順に選択します。

    図 2. エージェントリスト

  • Kafka と WSS の完全修飾ドメイン名（FQDN）の要件を確認して検証します。移行中のクラスタ間の通信を維持するために、Kafka 構成が FQDN 標準に準拠していることを確認します。詳細については、「Kafka FQDN Requirements」を参照してください。

バックアップモード

  • 完全バックアップモード

    • 構成、データ、サーバー設定、および履歴テレメトリを含む包括的なバックアップオプションを使用するには、[完全バックアップ（Full Backup）] モードを選択します。このモードでは、プライマリクラスタがスタンバイクラスタに完全に複製されます。完全バックアップモードでは、バックアップするフローデータの量に応じて、必要なストレージ容量は最大 50TB です。

  • リーンモード

    • 構成データをバックアップするには、リーンモードを選択します。このモードは、履歴テレメトリなしでプライマリクラスタからスタンバイクラスタに重要な設定のみ複製されます。最小ストレージ要件は 1TB です。データの冗長性が主な関心事ではない場合、移行は合理化されます。


（注）  

クラスタ間でデータを転送する場合、完全バックアップでは、リーンバックアップよりも多くの時間とストレージ容量が必要です。基本的な構成設定のみを含む迅速な移行の場合は、リーンモードを使用することを推奨します。プライマリクラスタの元のデータには引き続きアクセスでき、必要に応じて、データは完全バックアップモードを使用してスタンバイクラスタに転送されます。

セキュリティチェック

移行中にプライマリクラスタに関連するアラートや警告を確認するには、次の手順を実行します。

  • ナビゲーションウィンドウで、[概要（Overview）] > [セキュリティダッシュボード（Security Dashboard）]の順に選択します。[セキュリティダッシュボード（Security Dashboard）] ページで、プライマリクラスタに関連するアラートや警告を確認します。

    詳細については、『Cisco Secure Workload ユーザーガイド』の「Cluster Status」の項を参照してください。

  • ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [クラスタ構成（Cluster Configuration）]の順に選択し、このページで、WSS および Kafka のプライマリクラスタの FQDN 構成がスタンバイクラスタ構成と一致することを確認します。

プライマリクラスタ構成

手順

ステップ 1

ストレージの設定

  1. 完全バックアップモード用に 50TB、リーンバックアップモード用に 1TB のストレージを設定するには、S3v4 準拠のオブジェクトストアに新しいバケットを作成します。一般的に使用される S3v4 ストレージデバイスは次のとおりです。

    • Amazon S3

    • Google Cloud Storage

    • Microsoft Azure Blob Storage

    • MinIO オブジェクトストレージ

  2. 次の詳細を入力します。

    • ストレージの名前

    • ストレージに設定されている S3 準拠のバケット名

    • S3 準拠のストレージエンドポイントの URL

    • （特定のストレージのオプション）S3 準拠のストレージのリージョン。

    • ストレージのアクセスキー

    • ストレージの秘密鍵

    後で参照できるように、これらすべての詳細を正確に記録してください。

  3. バケットのクラスタへの排他的な読み取り/書き込みアクセス権を付与します。

  4. プライマリクラスタのナビゲーションウィンドウで、[プラットフォーム（Platform）] > [データバックアップ（Data Backup）]の順に選択します。ステップ b で収集した情報を入力します。

  5. （任意）バックアップされたデータのマルチパートアップロードを使用する場合は、[マルチパートアップロードの使用（Use Multipart Upload）] を有効にします。

  6. （オプション）必要に応じて、HTTP プロキシを有効にできます。

  7. （任意）ストレージサーバーを認証するには、次の点を確認します。

    • CA 証明書の詳細の可用性。

    • [サーバーCA証明書の使用（Use Server CA Certificate）] の有効化。

  8. [テスト（Test）] ボタンをクリックして確定します。

ステップ 2

データバックアップの設定

プライマリクラスタでデータバックアップを設定するには、『Cisco Secure Workload ユーザーガイド』の「Configure Data Backup」の項に記載されている手順を実行します。

ステップ 3

クラスタデータのバックアップ

プライマリクラスタでデータバックアップを設定すると、継続モードを無効にしていない限り、クラスタデータのバックアップは日中のスケジュールされた時刻に自動的にトリガーされます。プライマリクラスタでは引き続きデータがバックアップされ、バックアップのステータスは、[データバックアップ（Data Backup）] ダッシュボード（[プラットフォーム（Platform）] > [データバックアップ（Data Backup）]）で確認できます。詳細については、『Cisco Secure Workload ユーザーガイド』の「Backup Status」を参照してください。

ステップ 4

外部ストレージでのデータバックアップのモニター

レプリケーションプロセスをモニターして、すべてのデータが正確に転送されていることを確認し、このフェーズで発生する可能性のある問題に迅速に対処します。

ステップ 5

帯域幅の推奨事項

クラスタと S3 互換ストレージ間で Backup and Restore システムを設定する場合は、それらを接続するリンクの帯域幅を考慮することが重要です。プライマリクラスタとスタンバイクラスタをストレージに接続して、データのバックアップと復元を容易にします。各移行では 1 秒ごとに特定の量の帯域幅が消費されるため、リンクの潜在的な飽和を評価し、適宜計画する必要があります。

ステップ 6

WAN リンク管理

WAN リンクが飽和状態になる可能性を考慮することが重要で、特に、移行トラフィックが多いピークの営業時間を考慮する必要があります。必要に応じて、中断を回避し、指定された移行期間内で移行を実行するようにデータ転送をスケジュールします。

スタンバイクラスタ構成

手順

ステップ 1

バックアップされたデータを復元するには、スタンバイモードでスタンバイクラスタを展開します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Deploying Cluster in Standby Mode」を参照してください。

  1. スタンバイクラスタで、[プラットフォーム（Platform）] > [データバックアップ（Data Backup）]の順に選択します。

  2. 次の詳細事項を入力します。

    • ストレージの名前

    • ストレージに設定されている S3 準拠のバケット名

    • S3 準拠のストレージエンドポイントの URL

    • （任意）特定のストレージに対する S3 準拠のストレージのリージョン

    • ストレージのアクセスキー

    • ストレージの秘密鍵

  3. （オプション）必要に応じて、HTTP プロキシを有効にできます。

  4. （任意）ストレージサーバーを認証するには、次の点を確認します。

    • CA 証明書の詳細の可用性。

    • [サーバーCA証明書の使用（Use Server CA Certificate）] の有効化。

  5. [テスト（Test）] ボタンをクリックし、S3 テストが完了したことを確認します。エラーがある場合は、ストレージのアクセシビリティ、およびクラスタの権限を確認します。

  6. テストが完了したら、[次へ（Next）] をクリックします。

バックアップデータが正しくプリフェッチされていることを確認し、バックアップのエラーをモニターします。詳細については、『Cisco Secure Workload ユーザーガイド』の「Data Restore」を参照してください。

ステップ 2

ta_guest ユーザーがスタンバイクラスタにアクセスできるか確認するには、ユーザーの作成または編集時に SSH キーを追加します。ユーザーを追加または変更するには、ナビゲーションウィンドウで、[ユーザーアクセス（User Access）] > [ユーザー（User）]の順に選択します。

図 3. スタンバイクラスタのユーザーの詳細

復元前の検証

復元プロセスを開始する前に、次のデータがプライマリクラスタからスタンバイクラスタにプリフェッチされていることを確認します。

手順

ステップ 1

スタンバイデータストレージ構成がプライマリデータストレージ構成と一致していることを確認するには、プライマリクラスタで [データバックアップ（Data Backup）] に移動し、スタンバイクラスタで [データ復元（Data Restore）] に移動します。両方のクラスタの WSFS、Kafka、および UI FQDN のクラスタ構成が同一であることを確認します。

ステップ 2

スタンバイクラスタのナビゲーションウィンドウで、[プラットフォーム（Platform）] > [クラスタ構成（Cluster Configuration）]の順に選択します。[プライマリクラスタサイト名（Primary Cluster Sitename）] フィールドに正しいプライマリクラスタ名が含まれていることを確認します。

ステップ 3

スタンバイクラスタと同じ方法で、すべてのエージェント、コネクタ、および外部オーケストレータからプライマリクラスタにアクセスできることを確認します。認証および認可の目的で LDAP または SSO を使用している場合は、LDAP および SSO に関連付けられたエンドポイントにアクセスできることを確認します。

ステップ 4

エージェントがプライマリクラスタと同じ方法でスタンバイクラスタと通信できるようにするには、両方のクラスタのファイアウォールルールが同じであることを確認します。対象には、ワークロード上のファイアウォールと、ワークロードとクラスタ間のネットワーク上のファイアウォールが含まれます。

ステップ 5

クラスタの完全修飾ドメイン名（FQDN）を設定し、ソフトウェアエージェントが完全修飾ドメイン名（FQDN）を解決できることを確認します。

ステップ 6

エージェントリストページのすべてのエージェントに、フェールオーバーの準備ができていることを示す緑色のチェックマークが表示されていることを確認します。さらに、エージェントのスムーズなフェールオーバーのために、すべてのエージェントがスタンバイクラスタに接続されていることを確認します。

ステップ 7

プライマリクラスタ UI への中断のないアクセスを確保するために、プライマリクラスタとスタンバイクラスタの両方にバックアップの完全修飾ドメイン名（FQDN）を作成することを推奨します。たとえば、プライマリクラスタのデータを復元し、DNS を反転すると、FQDN「cluster1.enterprise.com」と「cluster2.enterprise.com」の両方がスタンバイクラスタを指すようになります。その結果、cluster1.enterprise.com の GUI にアクセスできなくなりますが、プライマリクラスタと同じ IP アドレスを指す DNS サーバー「cluster1-backup.enterprise.com」に FQDN を作成することで、引き続き GUI にアクセスできます。データを復元して DNS を反転すると、「cluster1-backup.enterprise.com」と「cluster2-backup.enterprise.com」の両方がスタンバイクラスタを指し、「cluster1-backup.enterprise.com」は引き続きプライマリクラスタを指すようになります。

ステップ 8

スタンバイクラスタデータのプリフェッチが正しく機能していることを確認します。プリフェッチされたデータがプライマリクラスタのデータと一致することを検証するには、ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [データ復元（Data Restore）]の順に選択します。

ステップ 9

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [クラスタステータス（Cluster Status）]の順に選択し、プライマリクラスタとスタンバイクラスタの両方の正常性ステータスを確認します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Cluster Status」を参照してください。

ステップ 10

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [スナップショット（Snapshot）]の順に選択し、プライマリクラスタのスナップショットを作成します。このスナップショットは、移行中に発生した問題のトラブルシューティングに役立ちます。

スタンバイクラスタでプリフェッチされたバックアップデータが最新であることを確認します。

ステップ 11

ユーザー「ta_guest」がスタンバイクラスタにアクセスできるか確認します。このユーザーは、移行関連の問題が発生した場合に、トラブルシューティングの目的でスタンバイクラスタへのアクセスが許可されます。「ta_guest」ユーザーの詳細については、『Cisco Secure Workload ユーザーガイド』の「Users」を参照してください。

ステップ 12

クラスタ構成の検証を実行して、クラスタ構成情報を primary-config-data.txt に保存します。詳細については、『Cisco Secure Workload ユーザーガイド』の 「Cluster Configuration Validation」を参照してください。

ステップ 13

プライマリクラスタのコネクタおよび外部オーケストレータ機能からのデータを primary-ext-orch-data.txt に保存します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Connector and External Orchestrator Functional Validation」を参照してください。

ステップ 14

プライマリクラスタでデータフローの検証ワークフローを実行して得たデータを、primary-flow-data.txt という名前のファイルに保存します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Data Flow Validation」を参照してください。

スタンバイクラスタのクラスタデータ

クラスタデータは、次の 2 つのフェーズで復元できます。

  • 必須フェーズ：サービスの再起動に必要なデータを復元して、クラスタを使用できるようにします。必須フェーズにかかる時間は、構成、インストールされているソフトウェアエージェントの数、およびフローメタデータによって異なります。必須フェーズでは、構成の規模に応じて、GUI に 1 時間アクセスできないため、必須フェーズ中に TA ゲストキーをサポートに使用できることを確認してください。

  • 遅延フェーズ：バックグラウンドでクラスタのフローデータを復元している間、クラスタを引き続き使用して、GUI にアクセスできます。このフェーズ中、クラスタはデータパイプライン、フロー検索、およびエージェントからクラスタに送信される新しいデータの通常の機能で動作します。

詳細については、『Cisco Secure Workload ユーザーガイド』の「Cluster Restore」を参照してください。

スタンバイクラスタでデータを復元するには、次の手順を実行します。

ストレージ構成を確認します。

手順

ステップ 1

スタンバイクラスタのナビゲーションウィンドウで、[プラットフォーム（Platform）] > [データ復元（Data Restore）]の順に選択し、ストレージ構成が成功したことを確認します。ストレージを再設定することもできます。

ステップ 2

[チェックの実行（Perform Check）] をクリックして、クラスタの正常性を確認します。

図 4. データ復元の前提条件

（注）  

 

  • 復元中に警告メッセージが表示された場合でも、復元プロセスを続行できます。

  • ただし、エラーが発生した場合、[復元プロセスの開始（Start Restore Process）] ボタンは自動的に無効になります。エラーを修正してから、ステータスを確認することを推奨します。サービスの正常性ステータスを表示するには、ナビゲーションウィンドウで、[トラブルシューティング（Troubleshooting）] > [サービスステータス（Service Status）]の順に選択します。

ステップ 3

プライマリクラスタのバックアップスケジュールを停止する進行中のバックアップがないことを確認します。バックアップが進行中の場合は、そのバックアップが完了するのを待ってからスケジュールを非アクティブにします。

ステップ 4

復元プロセスを開始するには、[復元プロセスの開始（Start Restore Process）] をクリックします。次の図に示されているように、GUI で復元プロセスの段階を確認できます。

図 5. データ復元プロセスの段階

ステップ 5

[復元（Restore）] ページの下部にある [今すぐ復元（Restore Now）] ボタンをクリックします。

ステップ 6

[データ復元の確認（Confirmation Data Restore）] ウィンドウで、[確認（Confirm）] ボタンをクリックします。確認後、データ復元プロセスが順番に実行され、プロセスの最後に、スタンバイクラスタがプライマリになります。データ復元プロセスをモニターして、期待どおりに進行していることを確認します。

（注）  

 

復元の準備段階と復元後のクリーンアップ段階では、GUI にアクセスできないため、復元プロセスを開始する前に、必要なすべてのアクションが完了していることを確認してください。

クラスタデータのプリフェッチ

クラスタデータの復元を開始する前に、クラスタでデータをプリフェッチする必要があります。データのバックアップに使用されるのと同じストレージバケットからチェックポイントデータをプリフェッチします。データをプリフェッチしてデータのステータスを確認するには、『Cisco Secure Workload ユーザーガイド』の「Prefetch Cluster Data」の項に記載されている手順を実行します。

スタンバイクラスタのクラスタデータ

クラスタデータは、次の 2 つのフェーズで復元できます。

  • 必須フェーズ：サービスの再起動に必要なデータを復元して、クラスタを使用できるようにします。必須フェーズにかかる時間は、構成、インストールされているソフトウェアエージェントの数、およびフローメタデータによって異なります。必須フェーズでは、構成の規模に応じて、GUI に 1 時間アクセスできないため、必須フェーズ中に TA ゲストキーをサポートに使用できることを確認してください。

  • 遅延フェーズ：バックグラウンドでクラスタのフローデータを復元している間、クラスタを引き続き使用して、GUI にアクセスできます。このフェーズ中、クラスタはデータパイプライン、フロー検索、およびエージェントからクラスタに送信される新しいデータの通常の機能で動作します。

詳細については、『Cisco Secure Workload ユーザーガイド』の「Cluster Restore」を参照してください。

スタンバイクラスタでデータを復元するには、次の手順を実行します。

ストレージ構成を確認します。

手順

ステップ 1

スタンバイクラスタのナビゲーションウィンドウで、[プラットフォーム（Platform）] > [データ復元（Data Restore）]の順に選択し、ストレージ構成が成功したことを確認します。ストレージを再設定することもできます。

ステップ 2

[チェックの実行（Perform Check）] をクリックして、クラスタの正常性を確認します。

図 6. データ復元の前提条件

（注）  

 

  • 復元中に警告メッセージが表示された場合でも、復元プロセスを続行できます。

  • ただし、エラーが発生した場合、[復元プロセスの開始（Start Restore Process）] ボタンは自動的に無効になります。エラーを修正してから、ステータスを確認することを推奨します。サービスの正常性ステータスを表示するには、ナビゲーションウィンドウで、[トラブルシューティング（Troubleshooting）] > [サービスステータス（Service Status）]の順に選択します。

ステップ 3

プライマリクラスタのバックアップスケジュールを停止する進行中のバックアップがないことを確認します。バックアップが進行中の場合は、そのバックアップが完了するのを待ってからスケジュールを非アクティブにします。

ステップ 4

復元プロセスを開始するには、[復元プロセスの開始（Start Restore Process）] をクリックします。次の図に示されているように、GUI で復元プロセスの段階を確認できます。

図 7. データ復元プロセスの段階

ステップ 5

[復元（Restore）] ページの下部にある [今すぐ復元（Restore Now）] ボタンをクリックします。

ステップ 6

[データ復元の確認（Confirmation Data Restore）] ウィンドウで、[確認（Confirm）] ボタンをクリックします。確認後、データ復元プロセスが順番に実行され、プロセスの最後に、スタンバイクラスタがプライマリになります。データ復元プロセスをモニターして、期待どおりに進行していることを確認します。

（注）  

 

復元の準備段階と復元後のクリーンアップ段階では、GUI にアクセスできないため、復元プロセスを開始する前に、必要なすべてのアクションが完了していることを確認してください。

復元後および DNS 反転前の検証

スタンバイ クラスタ インターフェイスがダウンしたら、クラスタへの接続を試行します。データ復元プロセスが完了したら、GUI にログインできます。


（注）  

データ復元プロセスが完了すると、複数のサービスが約 1 時間 [非正常（UNHEALTHY）] 状態になります。すべてのサービスが各データにアクセスできるようになると、ステータスが [正常（HEALTHY）] に変わります。

スタンバイクラスタのデータを復元したら、次の点を確認します。

手順

ステップ 1

ライセンスのコピーを準備し、以前のバージョンと比較します。

ステップ 2

すべてのインベントリと注釈の可用性を確認し、[クラスタ構成（Cluster Configuration）] ページとサイト情報で IP アドレスを確認します。

ステップ 3

パイプラインは、データが取り込まれるまで、最初は [非正常（UNHEALTHY）] と表示されます。すべてのパイプラインがアクティブであることを確認します。

ステップ 4

すべてのサービスで緑色のステータスが表示されていることを確認します。一部のサービスのステータスは緑色になるまで、最大 1 時間かかる場合があります。パイプラインなどのフローデータを必要とするサービスは、データ復元プロセスが完了するまで待機するため、最も時間がかかる可能性があります。現在、データバックアップサービスに関する問題は無視しても問題ありません。

ステップ 5

重要なのは、クラスタ証明書が WSS と同じ CA に存在することを確認することです。確認するには、ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [クラスタ構成（Cluster Configuration）]の順に選択します。センサー CA 証明書をダウンロードし、クラスタ証明書が WSS と同じ CA に存在しているか確認します。

ステップ 6

トラブルシューティングのためにスタンバイクラスタのスナップショットを取得して、範囲ツリーが保持されていることを確認します。

ステップ 7

クラスタ構成の検証を実行して、次の手順を実行します。

  • スタンバイクラスタ構成情報を確認して確定します。

  • プライマリクラスタとスタンバイクラスタの両方の構成を比較検証し、スタンバイクラスタのユーザーのリストを除き、構成が一致していることを確認します。

    （注）  

     

    スタンバイリストにはプライマリユーザーとスタンバイユーザーの両方が含まれるため、スタンバイ上のユーザーのリストはプライマリリストよりも多くなります。

ステップ 8

フローカウントがプライマリクラスタとスタンバイクラスタの間で一致していることを確認します。フローデータが大きい場合、スタンバイクラスタでの復元に時間がかかる場合があります。詳細については、「フロー入力データの検証方法」を参照してください。その後、スタンバイクラスタのデータをプライマリクラスタのデータと比較します。

（注）  

 

スタンバイクラスタには、次のようないくつかの依存関係があるため、プライマリクラスタよりもフローが少ない場合があります。

  • プライマリクラスタの最後のバックアップのタイムスタンプ

  • スタンバイクラスタで復元されたデータのタイムスタンプ

  • エージェントからプライマリクラスタに送信されたデータ

    （最後のバックアップ後に）エージェントからプライマリクラスタに送信されたデータは、転送中に失われるため、スタンバイクラスタには復元されないことに注意してください。

DNS の反転

DNS 反転は、プライマリクラスタの FQDN がスタンバイクラスタ VIP を指すように DNS サーバーレコードを変更するアクションです。このアクションにより、エージェント、外部オーケストレータ、およびコネクタがプライマリクラスタではなくスタンバイクラスタに接続できるようになります。


（注）  

ワークロードとクラスタを処理するように設定されている DNS サーバーにおいて、クラスタの外部で DNS 反転アクションを実行してください。

DNS を反転するには、次の手順を実行します。

手順

ステップ 1

プライマリクラスタのサービスの停止

  • エージェント、コネクタ、および外部オーケストレータと連携するプライマリクラスタ内のすべてのサービスを停止してから、スタンバイクラスタを指すようにドメインネームシステム（DNS）エントリを変更する必要があります。そうすることで、各コンポーネントはプライマリクラスタへの接続を失い、接続の再確立を試みます。

  • DNS エントリを反転すると、エージェント、コネクタ、および外部オーケストレータは自動的にスタンバイクラスタに再接続します。プライマリクラスタのサービスを停止する段階的な手順については、「サービス停止ワークフロー」の項を参照してください。

ステップ 2

FQDN の反転

次の FQDN を反転し、各 FQDN に関連付けられている IP アドレスがスタンバイクラスタに関連付けられている VIP を指していることを確認します。

  • WSS FQDN

  • ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [クラスタ構成（Cluster Configuration）]の順に選択し、Kafka FQDN を確認します。最大 3 つの Kafka FQDN が存在する可能性があります。

クラスタ WSS と Kafka の DNS を反転すると、クラスタの [データ復元（Data Restore）] ページの FQDN チェックが緑色に変わります。

図 8. データ復元成功

DNS 反転後の検証

スタンバイクラスタの DNS を反転したら、次のシナリオを確認します。

手順

ステップ 1

プライマリクラスタとスタンバイクラスタの両方のスナップショットを作成します。

ステップ 2

プロキシの有無にかかわらず、エージェントのすべてのバージョンが再接続されていることを確認します。

  • スタンバイクラスタのデータを復元するには、ナビゲーションウィンドウで、[プラットフォーム（Platform）] > [データ復元（Data Restore）]の順に選択します。

  • エージェントを再接続したら、プライマリクラスタと同じ数のエージェントがスタンバイクラスタに再接続されていることを確認します。エージェントの再接続時刻は異なる可能性があるため、検証には時間がかかる場合があります。プライマリクラスタのアクティブなエージェントの数をモニターし、同じ数のエージェントがスタンバイクラスタで再接続されていることを確認します。これは、[データ復元（Data Restore）] ページの [復元されたエージェント（Agents Restored）] データから確認できます。

    エージェントの詳細については、「センサーの検証」を参照してください。

ステップ 3

コネクタと外部オーケストレータが接続されていることを確認します。コネクタが接続されていない場合は、スタンバイクラスタからコネクタへのルートがあり、コネクタの接続を許可するようにファイアウォールルールが設定されていることを確認します。ナビゲーションウィンドウで、[ワークロード（Workloads）] > [コネクタ（Connectors）]の順に選択し、ログを確認して障害を特定します。段階的な検証手順については、「コネクタと外部オーケストレータ機能の検証」を参照してください。

ステップ 4

すべてのアラート通知、電子メール、および syslog データは転送できませんが、アラートはすべて再発行されます。

ステップ 5

パイプラインが適切に機能していることを確認し、必要に応じてプライマリクラスタの GUI FQDN をスタンバイクラスタに移行します。

ステップ 6

目的の結果を得るには、プライマリクラスタのクラスタ GUI FQDN を変更し、スタンバイクラスタの IP アドレスに置き換える必要があります。

この手順を完了後、ブラウザまたはクラスタ API を使用してプライマリクラスタの FQDN にアクセスすると、スタンバイクラスタにリダイレクトされます。

データ移行の検証

ここでは、プライマリクラスタからスタンバイクラスタへのデータ移行が成功したことを確認する手順の概要を示します。

ストレージの検証

プライマリクラスタとスタンバイクラスタでストレージを設定する前に、ストレージの検証を完了します。s3-test.py Python スクリプトを使用してストレージを検証します。このスクリプトには、Python 3 と、requirements.txt ファイルにリストされている特定のパッケージが必要です。

S3 ストレージ構成を検証するには、次の手順を実行します。

手順

ステップ 1

s3-test.conf 構成ファイルにストレージの詳細を入力します。詳細には、ストレージ URL とポート番号、S3 アクセスキー、S3 秘密鍵、およびバケットの詳細が含まれます。

ステップ 2

次のオペレーティングシステムでスクリプトを実行します。

  • Linux および Mac の場合：python s3-test.py

  • Windows の場合：python s3-test.py

s3-test.py スクリプトは、バケットの検証、バケットからの読み取り/書き込み、およびバケットからのオブジェクトの一括削除を実行して、バケットへのアクセスをテストします。これらの基本テストにより、S3 互換ストレージ構成が正しいことを確認します。

スクリプトからは次の出力が生成されます。

図 9. 検証エラー
図 10. 検証成功
図 11. ヘルプ画面

クラスタ構成の検証

プライマリクラスタとスタンバイクラスタの両方から構成の概要をキャプチャします。移行プロセスが完了したら、両方のクラスタを比較して、構成が同一であることを確認します。次の点を確認してください。

  • 復元プロセスの前にプライマリクラスタ構成をキャプチャします。

  • 必須の復元フェーズが完了したら、スタンバイクラスタ構成をキャプチャします。この時点で、構成がスタンバイクラスタに移行されます。

手順

ステップ 1

検証スクリプトでは OpenAPI が使用されます。API キーは、『Cisco Secure Workload ユーザーガイド』の「OpenAPI」の項に記載されている手順を使用して取得できます。

ステップ 2

すべての API キーの権限を選択し、API キーを含む JSON ファイルをダウンロードします。

図 12. API キーを含む JSON ファイル

ステップ 3

プライマリクラスタでチェックリストスクリプトを実行して、検証する必要がある構成項目のリストを準備し、スクリプトの出力を記録します。このスクリプトでは、比較可能な両方のクラスタ構成に関する概要が表示されます。相違がある場合は、プライマリクラスタとスタンバイクラスタの完全な構成を比較して、不一致の有無を判断します。

図 13. 出力例
表 2. 構成コンポーネントのリスト
構成コンポーネント 検証済み
手動ラベル 対応
範囲 対応
インベントリフィルタ 対応
エージェントプロファイル 対応
エージェントインテント 対応
ワークスペース 対応
ワークスペースポリシー（最新バージョン） 対応
ワークスペースクラスタ 対応
ロール 対応
ユーザー 対応
除外フィルタ：デフォルトおよびワークスペース 対応
外部オーケストレータ 対応
クライアントサーバーの構成（サーバーポート） 対応
フォレンジック：プロファイルとインテント 対応
ポリシーテンプレート（カスタムテンプレート） ×
収集ルール 対応
デフォルトの ADM 構成 対応
アラート設定/パブリッシャ 対応
セキュアコネクタ 対応
仮想アプライアンス（Ingest または Edge） 対応
コネクタ 対応
データタップの構成 対応

（注）  

 

すべての構成項目が適切に移行され、不一致がないことを確認するために、移行後にスタンバイクラスタに対してスクリプトが実行されます。

ステップ 4

すべてのクラスタ構成をダウンロードするモードでチェックリストスクリプトを実行します。download-src コマンドと download-dst コマンドを使用して、両方のクラスタから JSON 構成ファイルをダウンロードします。この構成が安全に保存されていることを確認します。

ステップ 5

データの復元プロセスが完了したら、スタンバイクラスタでステップ 2 ～ 7 を繰り返します。

ステップ 6

プライマリクラスタとスタンバイクラスタの構成の詳細を比較します。クラスタ構成に不一致がある場合は、構成の詳細をステップ 5 で収集したデータと比較して、違いを特定します。

プライマリクラスタのサービスの停止

このスクリプトを使用し、プライマリクラスタのサービスを停止して、エージェント、コネクタ、および外部オーケストレータを接続解除できます。


注意    

プライマリクラスタでのみサービスを停止できます。スタンバイクラスタ上で、またはサービスを移行していない場合は、このスクリプトを実行しないでください。

サービス停止スクリプトを実行するには、次の手順を実行します。

手順

ステップ 1

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択します。[アクション（Action）] として [POST] を選択します。

ステップ 2

[スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

ステップ 3

[本文（Body）] フィールドに、service_shutdown.sh.asc ファイルの詳細を入力します。

ステップ 4

[送信（Send）] をクリックします。

図 14. サービス停止スクリプトの実行

コネクタと外部オーケストレータ機能の検証

ここでは、移行後にスタンバイクラスタを使用してコネクタと外部オーケストレータ間の接続を確認する方法について説明します。

  • プライマリクラスタで検証手順を実行し、データを収集します。

  • 復元が完了したら、スタンバイサーバーで同じ手順を実行します。

    2 つのデータセットを比較して、同一であることを確認します。

GUI の [Maintenance Explorer] ページから、署名付きスクリプトとして検証スクリプトを実行します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Explore/Snapshot Endpoints Overview」を参照してください。


（注）  

検証スクリプトと生成される出力の詳細については、ext_appliances_health_README.md ファイルを参照してください。

コネクタと外部オーケストレータ間の接続とログファイルの詳細を確認するには、次の手順を実行します。

手順

ステップ 1

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に runsigned?log2file=true と入力します。

  • [本文（Body）] フィールドに、ext_appliances_health.sh.asc ファイルの詳細を入力します。

  • [Send] をクリックします。

図 15. 出力例のログファイル

ステップ 2

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択し、次の手順を実行します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に cat?args=/local/logs/tetration/snapshot/cmdlogs/snapshot_runsigned_log.txt と入力します。

  • [送信（Send）] をクリックします。

図 16. 出力例のログファイル

ステップ 3

出力には、コネクタと外部オーケストレータのステータスが表示され、結果が [失敗（FAIL）] または [合格（PASS）] として要約されます。結果が [失敗（FAIL）] の場合は、ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択し、次の手順を実行します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に unsigned?log2file=true&args=--dry_run -d と入力します。

  • [送信（Send）] をクリックします。

コネクタと外部オーケストレータの詳細については、ログファイルを参照してください。移行ステータスが [失敗（FAIL）] である理由の詳細な説明は、すべてのコネクタと外部オーケストレータからの出力に表示されます。

データフローの検証

データ復元プロセス完了後、スクリプトを使用して、プライマリクラスタとスタンバイクラスタに着信するデータフローのデータを検証します。

手順

ステップ 1

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択し、次の手順を実行します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に runsigned と入力します。

  • [本文（Body）] フィールドに dbr_druid_m6_migration.sh.asc ファイルの詳細を入力します。

  • [送信（Send）] をクリックします。

ステップ 2

GUI に表示される flow_stats_primary.txt ファイルにデータを保存します。検証の出力には、次の 2 つの部分があります。

  • 出力の上部には、データソースと各データソースのフローカウントが表示されます。また、各データソース内に含まれるフローのデータの比較が表示されます。

  • 出力の下部は、情報の操作とプルに使用される JSON 出力です。

ステップ 3

復元プロセスが完了し、スタンバイクラスタが復元されたら（遅延復元を含む）、スタンバイクラスタに対してステップ 1 を繰り返し、結果を flow_stats_standby.txt に 保存します。

ステップ 4

プライマリクラスタとスタンバイクラスタの出力を比較します。出力は同一である必要があります。

図 17. プライマリクラスタとスタンバイクラスタの出力の確認

センサー情報の検証

移行が完了したら、同じ手順を使用してスタンバイクラスタのセンサー情報を収集します。2 つのクラスタの出力を比較して、エージェントが正しく移行されたことを確認します。移行前にプライマリクラスタのセンサー情報を収集するには、次の手順を実行します。

手順

ステップ 1

ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に runsigned と入力します。

  • [本文（Body）] フィールドに、tenant_sensor_summary.sh.asc ファイルの詳細を入力します。

  • [送信（Send）] をクリックします。

ステップ 2

センサー情報は CSV ファイルに書き込まれ、情報は GUI にも表示されます。CSV ファイルのデータは、データの分析に使用されます。

CSV ファイルからデータを取得するには、ナビゲーションウィンドウで、[トラブルシュート（Troubleshoot）] > [Maintenance Explorer]の順に選択します。

  • [アクション（Action）] として [POST] を選択します。

  • [スナップショットホスト（Snapshot Host）] に orchestrator.service.consul と入力します。

  • [スナップショットパス（Snapshot Path）] に cat?args=/tmp/summary.csv と入力します。

  • [本文（Body）] フィールドには詳細を入力しないでください。

  • [送信（Send）] をクリックします。

データが画面に表示されます。CSV データをファイルに保存します。

トラブルシューティング：Data Backup and Restore

S3 構成チェックの失敗

ストレージテストが失敗した場合は、右側のペインに表示される障害シナリオを特定し、以下の点を確認します。

  • S3 準拠のストレージの URL が正しい。

  • ストレージのアクセスキーと秘密鍵が正しい。

  • ストレージ上にバケットが存在し、正しいアクセス権限（読み取り/書き込み）が付与されている。

  • プロキシが設定されている（ストレージに直接アクセスする必要がある場合）。

  • マルチパート アップロード オプションが無効になっている（Cohesity を使用している場合）。

S3 構成チェックのエラーシナリオ

次の表は、一般的なエラーシナリオと解決策を示したものであり、すべてを網羅したものではありません。

表 3. S3 構成チェック中に表示されるエラーメッセージと解決策
エラー メッセージ

シナリオ

対処法

見つからない（Not found）

 正しくないバケット名 ストレージに設定されているバケットの正しい名前を入力します。

SSL接続エラー（SSL connection error）

SSL 証明書の有効期限または検証のエラー

SSL 証明書を確認します

無効な HTTPS URL

  • ストレージの正しい HTTPS URL を再入力します。

  • SSL 証明書の検証中に発生した障害を解決します。

接続がタイムアウトしました（Connection that is timed out）

S3 サーバーの IP アドレスに到達できません

クラスタと S3 サーバーの間のネットワーク接続を確認します

URLに接続できません（Unable to connect to URL）

正しくないバケットリージョン

正しいバケットのリージョンを入力します

無効な URL

S3 ストレージエンドポイントの正しい URL を再入力します

Forbidden

無効な秘密鍵

ストレージの正しい秘密鍵を入力します

無効なアクセスキー

ストレージの正しいアクセスキーを入力します

S3設定を確認できません（Unable to verify S3 configuration）

その他の例外または一般的なエラー

しばらくしてから S3 ストレージの設定を試みます

チェックポイントのエラーコード

次の表は、チェックポイントの一般的なエラーコードを示したものであり、すべてを網羅したものではありません。

表 4. チェックポイントのエラーコード

エラー コード

説明

E101：DBのチェックポイントの失敗（E101: DB checkpoint failure）

Mongodb oplog のスナップショットを取得できません

E102：フローデータのチェックポイントの失敗（E102: Flow data checkpoint failure）

Druid データベースのスナップショットを取得できません

E103：DBスナップショットのアップロードの失敗（E103: DB snapshot upload failure）

Mongo DB スナップショットをアップロードできません

E201：DBのコピーの失敗（E201: DB copy failure）

Mongo スナップショットを HDFS にアップロードできません

E202：設定のコピーの失敗（E202: Config copy failure）

Consul-Vault スナップショットを HDFS にアップロードできません

E203：設定のチェックポイントの失敗（E203: Config checkpoint failure）

consul-vault データのチェックポイントを実行できません

E204：チェックポイント中の設定データの不一致（E204: Config data mismatch during checkpoint）

最大再試行回数後に consul/vault チェックポイントを生成できません

E301：バックアップデータのアップロードの失敗（E301: Backup data upload failure）

HDFS チェックポイントの失敗

E302：チェックポイントのアップロードの失敗（E302: Checkpoint upload failure）

Copydriver が S3 にデータをアップロードできませんでした

E401：チェックポイント中のシステムアップグレード（E401: System upgrade during checkpoint）

このチェックポイント中にクラスタがアップグレードされました。チェックポイントは使用できません

E402：チェックポイント中のサービスの再起動（E402: Service restart during checkpoint）

Bkpdriver が作成状態で再起動しました。チェックポイントは使用できません

E403：前のチェックポイントの失敗（E403: Previous checkpoint failure）

前回の実行でチェックポイントが失敗しました

E404：別のチェックポイントが進行中（E404: Another checkpoint in progress）

別のチェックポイントが進行中です

E405：チェックポイントを作成できない（E405: Unable to create checkpoint）

チェックポイントのサブプロセスでエラーが発生しました

失敗：完了（Failed: Completed）

先行するチェックポイントの一部が失敗しました。同時に開始する複数のチェックポイントが重複している可能性があります

データ復元プロセス中のエラー

  • ストレージ構成フェーズ：S3 ストレージ構成時のエラーのトラブルシューティングに推奨される解決策については、「S3 構成チェックのエラーシナリオ」を参照してください。

  • セカンダリクラスタの正常性を確認するための事前チェック：正常ではないサービスまたは警告があるサービスの場合は、[サービスステータス（Service Status）] ページに移動して、サービスを正常にレンダリングするための詳細情報を確認します。

  • ストレージへの接続を確認するための事前チェック：

    表 5. ストレージ接続の事前チェック中のエラー

    エラーシナリオ

    説明

    構成された S3 ストレージからデータをダウンロードできない。

    ネットワーク接続が原因で、S3 ストレージへのアクセスに失敗しました。接続が復元され、新しいチェックポイントが S3 ストレージからプリフェッチされるまで、エラーメッセージが表示されます。

    セカンダリ（バックアップ）クラスタ SKU がプライマリクラスタと互換性がない。

    39 RU から別の 39 RU クラスタにのみデータを復元していることを確認します。8 RU クラスタデータは 8 RU クラスタにのみ復元できます。

    セカンダリ（バックアップ）クラスタのバージョンがプライマリと異なっている。

    プライマリクラスタとセカンダリクラスタで同じバージョンが実行されていることを確認します。

    MongoDB の復元に失敗する。

    MongoDB メタデータを復元できません。この問題は、次のチェックポイント プリフェッチ時に修正されます。

    DBRInfo マニュアルの形式が不明である。

    S3 ストレージ内のチェックポイントメタデータが破損しているか、マニュアルが間違ったストレージにあります。S3 ストレージから dbrinfo.json ファイルをダウンロードし、確認のために Cisco TAC と共有します。

    コピーサービスと同期できない。

    データ復元マネージャと S3 コピーサービスの間で内部エラーが発生しました。問題のトラブルシューティングについては、Cisco TAC にお問い合わせください。

  • FQDN 事前チェック：FQDN 事前チェックに対して警告サインが表示された場合、FQDN の DNS エントリがセカンダリクラスタを指していません。

    解決策：データを復元後、DNS エントリを変更して、ソフトウェアエージェントとセカンダリクラスタ間の接続を有効にします。

  • データ復元フェーズ：データ復元の確認ダイアログボックスで、外部オーケストレータのチェックボックスに緑色のチェックマークが付いていない場合は、セカンダリクラスタと外部オーケストレータ間の接続を確認します。


    （注）  

    データが復元され、セカンダリクラスタがプライマリ状態になっても、[データ復元（Data Restore）] ページは引き続き使用でき、復元の所要時間と再接続したエージェントの数を確認できます。データが復元されないクラスタの場合、[データ復元（Data Restore）] ページは空白になります。