デュアル・リージョンの災害復旧の設計

この設計では以下の構成を使用しています。

ネットワーク
vCenter
VMware NSX®マネージャー
Caveonix RiskForesight™
VMware アリア・オペレーション™・ログ
VMware Aria Operations™ for Networks
VMware アリア・オペレーション™・マネージャー
AD/DNS/NTP
Veeam®
KMIP for VMware®
Hyper Protect Crypto Service

ネットワーク設計

Regulated Workloadsインスタンスを2つ使うので、ネットワーク設計はそれぞれのリージョンにあり、アンダーレイネットワーキングとオーバーレイネットワーキングで文書化されています。

ネットワークレベルでの重要な設計要素は、 VMware Aria Operations Manager分析クラスタを使用するためのクロスリージョンネットワークの採用である。リージョン間ネットワークは、保護リージョンと復旧リージョンの両方で同じ IP サブネット・スペースを使用できるようにするレイヤー 3 の構造になっています。通常運用時は、リージョン間ネットワークは保護リージョンの vSRX または FortiGate に結び付けられています。つまり、このネットワークのデフォルト・ゲートウェイはその vSRX または FortiGate です。そして、保護リージョンの vSRX または FortiGate が、このネットワークを通知して他のネットワークから到達可能にします。復旧運用時には、リージョン間ネットワークはリカバリー・リージョンの vSRX または FortiGate に結び付けられます。そして、リカバリー・リージョンの vSRX または FortiGate が、このネットワークを通知して他のネットワークから到達可能にします。クロスリージョンネットワークを使用することで、 VMware Aria Operations Manager Analyticクラスタがリカバリリージョンにリカバリされても同じIPアドレスを保持することができます。

以下のネットワークの設計判断について確認してください。

IBM Cloud® クラシック・ネットワーク環境では、データ・センターをまたいで VLAN を拡張することはできません。そのため、この設計では、物理的なネットワーク・インフラストラクチャーのレベルで拡張された VLAN は使用しません。
VMware NSX™ の設計の中には、地理的に離れた vSphere クラスター間でセグメントを拡張できるものもありますが、このような設計では共通の NSX クラスターが必要であり、リージョン間の独立性に関する設計要件を満たしていません。
地理的に分散した vSRX アプライアンス間にネットワークを拡張することが可能です。ただし、この設計ではこのユース・ケースは提示しません。
復旧作業を最小化するために、復旧された管理コンポーネントでは同じ IP アドレスが使用されます。
トラフィックを分離するために、この設計ではリージョン間、また、リージョンと SaaS 利用者および SaaS プロバイダー間にはトンネル (お客様の要求によって実行される GRE または IPsec) を使用します。
リージョンと SaaS プロバイダーおよび SaaS 利用者の間では BGP を使用して、通常運用時および災害復旧起動時に、適切な場所にある必要なルートがアドバタイズされます。
VMware Aria Operations Manager DRの設計では、クロスリージョンサブネットに同じIPアドレスを使用して、アナリティクスクラスターをリカバリリージョンで再起動する必要があります。このプロセスを実行するには、リージョン間 IBM Cloud ポータブル・サブネットをリカバリー・リージョンに「移動」します。このようなプロセスを実行できる理由は、このサブネットのデフォルト・ゲートウェイが vSRX であるからです。ただし、SaaS プロバイダーの VPN トンネルを使用しない限り、このサブネットに vSRX の外部からネイティブにアクセスすることはできません。

vCenter Server

各リージョンには、そのリージョンの内部の ESXi ホストを管理するための vCenter Server インスタンスがあります。各インスタンスは別個の SSO ドメインです。 IBM Cloud 設計では、組み込みプラットフォーム・サービス・コントローラー (PSC) を備えた vCenter Server Appliance (VCSA) が使用されます。リージョンごとに 1 つの vCenter と別個の SSO ドメインを使用することで、サービスを分離できます。

各リージョンの内部では、vSphere High Availability (HA) によってアプライアンスの可用性を確保します。ビジネス回復力のために、アプライアンスのイメージ・レベルおよびファイル・レベルのバックアップを取ることをお勧めします。これらのバックアップはリージョンのローカルに保管されるので、迅速なリストアが可能になります。

Veeam のバックアップ・コピー・ジョブも構成することをお勧めします。 Veeam リポジトリー・サーバーに障害が発生した場合は、もう一方のリージョンにあるアプライアンス・バックアップのコピーを使用できます。

Veeam は、アプライアンスのイメージ・レベルのバックアップを取るために使用されます。ただし、このタイプのバックアップではデータベースが静止されないので、使用不可のイメージになることがまれにあります。そのため、スケジュールによるファイル・レベルのバックアップも取ることをお勧めします。

VCSAイメージをリストアするには、VCSA経由の接続が利用できないため、まず管理クラスタ内のESXiホストにアタッチするようにVeeam Backup and Replication Managerを構成します。 Veeam UI のリストア・ウィザードで、「VM 全体 (Entire VM)」を選択し、「VCSA」を選択し、「新規ロケーションへのリストア (Restore to a new location)」を選択して、該当する ESXi サーバーを選択します。

バックアップの一部として、vDS スイッチ構成をバックアップすることをお勧めします。そのためには、バックアップ・ジョブでトリガーされるスクリプトを使用します。詳細については、 PowerCLI VMware vCenter から仮想分散スイッチ（VDS）の完全な情報を収集してください。

VCSA は、障害後のアプライアンスのリカバリーに役立つ、ファイル・ベースのバックアップ/リストアのメカニズムをサポートしています。ファイル・ベースのバックアップを実行する方法は、VCSA の管理ユーザー・インターフェース (UI) を使用する方法だけです。この設計では、リポジトリー・サーバー上の SFTP/SMB 共有をターゲット・ディレクトリーとして使用します。このディレクトリーが Veeam のファイル・コピー・ジョブでもう一方のリージョンにコピーされるので、回復力が強化されます。

ファイル・ベースのリストアでは、新規 VCSA をデプロイしてから、その新規アプライアンスにファイル・ベースのバックアップのデータをリストアするというプロセスになります。

NSX Manager

NSX Manager は、仮想ネットワークセグメント、 Tier-0、 Tier-1 ゲートウェイなどの NSX コンポーネントを作成、設定、監視するためのユーザーインターフェイスと API を提供します。 NSX Manager は、NSX インフラストラクチャの管理プレーンと制御プレーンの両方を実装します。この設計では、保護リージョンと復旧リージョンにはそれぞれ NSX Manager クラスタがあり、トランスポートゾーンのスパンはリージョン内に限定されています。リージョンごとのNSXマネージャーは、各リージョンが独立しているとみなされるように、サービスの分離を可能にする。

クラスタ仮想 IP アドレスを使用すると、NSX Manager クラスタのユーザーインターフェイスと API の HA が提供されます。 vSphere HA を使用することで、アプライアンスに障害が発生した場合の事業継続性を確保します。

NSX マネージャのイメージベースのバックアップはサポートされていません。したがって、NSX の唯一のオプションとして、SFTP サーバーを使用してスケジュールされた NSX アプライアンスのバックアップを構成することをお勧めします。この設計では、SFTP サーバーの宛先はローカルの Veeam リポジトリー・サーバー上のディレクトリーです。この Windows® サーバーを SFTP サーバーとして構成し、必要に応じてバックアップ・ファイルのリカバリーに使用します。必要なコンポーネントの数を抑えるために、別個のスタンドアロン SFTP サーバーは使用しません。代わりに、Veeam リポジトリー・サーバーの Windows OS の内部で SFTP サービスを使用します。

Veeam Repositoryサーバに障害が発生すると、VCSAとNSX Managerのバックアップが失われます。そのため、Veeam ファイル・コピー・ジョブを使用してローカル・リージョンからリモート・リージョンにファイルをコピーすることで、バックアップのオフサイト・コピーを提供します。

NSX Manager アプライアンスが操作できない間、データプレーンに影響はありませんが、構成の変更はできません。リストア・プロセスでは、まず一方のノードをリストアしてから、もう一方のノードを追加するように指示されます。

リージョン管理は独立しているので、お客様のネットワーク回復力戦略とオーバーレイ・ネットワーク設計に応じて、保護リージョンとリカバリー・リージョンのネットワーク構成を同期させる必要があります。ワークロードのネットワークには、さまざまなネットワーク回復力戦略を選択できます。リカバリー後に、一部のワークロードで、同じ IP アドレスまたは異なる IP アドレッシング・スキームの使用が必要になることもあります。

両方のリージョンを一貫した方法で構成するために、自動処理機能を使用してオーバーレイ・ネットワークのコンポーネントを作成することをお勧めします。必要な同期を提供するために、構成管理の自動化 (PowerCli、Ansible、Terraform など) を使用することをお勧めします。

Caveonix RiskForesight

IBM Cloud for VMware® Regulated Workloads の自動処理機能によって、保護リージョンとリカバリー・リージョンの両方にオールインワン型の Caveonix RiskForesight アプライアンスがデプロイされます。デュアルリージョン設計では、回復リージョンのアプライアンスのみが使用され、保護リージョン vCenter, NSX マネージャーがアセットリポジトリとして構成されるように再構成されます。単一の Caveonix RiskForesight インスタンスを使用して保護リージョンとリカバリー・リージョンの両方のコンプライアンスおよびサイバーリスクを管理することで、すべての環境を単一画面で確認できます。リカバリー・リージョンに単一の Caveonix RiskForesight インスタンスを置いておくことで、DR の起動時には DR 作業を一切行うことなくそのインスタンスを使用できます。

RiskForesight インスタンスの可用性とビジネス回復力は、vSphere HA を使用して確保します。 VM のイメージ・レベルのバックアップの場合、これらのバックアップを Veeam リポジトリー・サーバーのリカバリー・リージョンに構成して保管します。そのバックアップを保護サイトにコピーする Veeam バックアップ・コピー・ジョブを構成して、バックアップのオフサイト・コピーを提供できるようにします。

ワークロード VM のコンプライアンスとサイバーリスクの管理に Caveonix RiskForesight を使用している場合は、 RiskForesight インスタンスのスケーリングを見直してください。可用性と保存の要件に合わせて、オールインワン型のデプロイメントを適切なデプロイメントに置き換えてください。詳しくは、Caveonix RiskForesight のデプロイメント・モデルを参照してください。

VMware Aria Operations for Logs

Regulated Workloadsオートメーションは、2 つのリージョンそれぞれに統合されたロードバランサーを備えた 4 台のアプライアンスで構成される VMware Aria Operations for Logs 環境を展開します。詳細については、VMware Aria Operations for Logs を参照してください。

デュアルリージョン設計では、各リージョンは、もう一方のリージョンの VMware Aria Operations for Logs インスタンスにログ情報を転送するように構成されます。この転送設定により、 VMware Aria Operations for Logs クラスタのいずれかを使用して、いずれかのリージョンから利用可能なログを照会することができる。その結果、 VMware Aria Operations for Logsクラスタにフェイルオーバー構成は必要なく、各クラスタは配置されたリージョンに関連付けられたままです。この方法によって DR 起動時のフェイルオーバー構成が最小限に抑えられます。

VMwareの使用と vSphere の使用により、その地域内で HA が提供されます。事業継続性のために、Veeam を使用して、クラスター・ノードのイメージ・レベルのバックアップを構成してください。

VMware ネットワーク向けアリア・オペレーション

VMware Aria Operations for Networks サービスは、Regulated Workloads 用のオプションの手動インストールです。詳細については、VMware Aria Operations for Networks を参照してください。

デュアルリージョンデザインでは、各リージョンに VMware Aria Operations for Networks インスタンスを手動でインストールし、そのリージョンの監視と管理を行います。保護リージョンのインスタンスをリカバリー・リージョンにリカバリーする必要はありません。 VMware Aria Operations for Networksのインスタンスは、リージョンごとに配置され、各リージョンが独立しているとみなされるように、サービスの分離を可能にします。

VMwareの使用と vSphere の使用により、その地域内で HA が提供されます。事業継続性のために、ファイル・レベルのバックアップを構成してください。 Broadcom® はイメージレベルのバックアップをサポートしていますが、 VMware Aria Operations for Networks アプライアンスをシャットダウンすることを推奨しています。このプロセスは、アップグレードするときには現実的ですが、通常のバックアップにとっては非現実的です。そのため、SSH バックアップがサポートされるファイル・レベルのバックアップを構成することをお勧めします。 VMware Aria Operations for NetworksでVeeam Repositoryサーバをターゲットとしてスケジュール・バックアップを設定します。そのバックアップを保護サイトにコピーする Veeam ファイル・コピー・ジョブを構成して、バックアップのオフサイト・コピーを提供できるようにします。

VMware アリア・オペレーション・マネージャー

Regulated Workloads オートメーションは、プライマリノード1台、プライマリレプリカノード1台、および各リージョンのデータノード2台の計4ノードからなる統合 VMware Aria Operations Managerアナリティクスクラスターを展開する。詳細については、VMware Aria Operations Manager の設計を参照してください。

このデュアル・リージョン設計では、デプロイされるこのアーキテクチャーを使用します。必要な設計を作成するために、次のようなプロビジョニング後のタスクが必要になります。

保護リージョン
- 4 ノードの分析クラスターは再利用されます。2 つの追加のリモート・コレクターは追加のプライベート・ポータブル・サブネット上にデプロイされます。
- 分析クラスターは Veeam レプリケーションで保護し、リカバリー・リージョンにフェイルオーバーします。 IP アドレスは変更しません。
- リモート・コレクターはフェイルオーバーしません。コレクターはリージョンに固有のものです。
リカバリー・リージョン
- 4 ノードの分析クラスターは削除します。既存のポータブルなプライベート・サブネットを使用して、リモート・コレクターを 2 つデプロイします。
- 分析クラスターをホストするサブネットと同じサブネットがリカバリー・リージョンで使用可能になるように、vSRX を構成します。通常運用時は、このネットワークでは VM はホストされず、このネットワークは切り離されています。 DR の起動時には、このネットワークと、リカバリーされた分析クラスターが、リモート・コレクターから到達可能になります。このネットワークに、vSRX の外部にある IBM Cloud アンダーレイ・ネットワークから直接到達することはできません。ただし、VPN 接続を使用すれば到達可能です。

以下の設計判断について確認してください。

VMware Aria Operationsの自動デプロイメントを保護地域に再利用することで、デプロイメント後のタスクが軽減される。
リージョン固有およびクロスリージョンコンポーネントの概念を持つ VMware Aria Operations のマルチリージョン設計を使用すると、VMware Aria Operations 分析アプライアンスを同一のネットワーク構成にリカバリできます。アプライアンスの IP を割り当て直すことは可能ですが、複雑さが増します。
リモート・コレクター・ノードをリージョンごとに 2 台デプロイして、リージョン間でフェイルオーバーしないアプリケーションからメトリックを収集する負荷を分析クラスターから取り除きます。
Veeam Replicationを使用することで、 VMware Aria Operations Analyticsクラスタのレプリカを提供し、リカバリリージョンでのリカバリを可能にします。
リモート・コレクターはデータを保管しないので、Veeam でバックアップする必要があるのは分析クラスターだけです。ただし、再デプロイメントを簡単にするためにバックアップを作成します。

AD、DNS、および NTP

Regulated Workloads オートメーションは、各インスタンスに Microsoft® Windows VMのペアをデプロイする。これらの VM は、AD、DNS、および NTP サーバーとして構成されます。これらのサービスはリージョンごとに独立していて、各リージョンに別個の AD フォレストがあります。保護リージョンのサービスをリカバリー・リージョンにリカバリーする必要はありません。

vSphere HAはVM自体の可用性を提供し、マイクロソフトドメインのコンセプトは、VM上で実行されるサービスの可用性を提供する。 Microsoft Windows ビジネスの回復力のために、VM のイメージ・レベルのバックアップを構成してそのリージョンの Veeam リポジトリー・サーバーに保管してください。そのバックアップをもう一方のサイトにコピーする Veeam バックアップ・コピー・ジョブを構成して、バックアップのオフサイト・コピーを提供できるようにします。

Veeam

Regulated WorkloadsデュアルリージョンでのVeeam Backup and Replicationでは、以下の使用例が想定されます：

ケース 1. 管理コンポーネントのみのバックアップおよび複製。
ケース 2. 管理コンポーネントのバックアップと複製、およびワークロードのバックアップ。
ケース 3. 管理コンポーネントのバックアップと複製、およびワークロードのバックアップと複製。

Regulated Workloadsデュアルリージョンのデザインは、ユースケース1に焦点を当てています。ただし、ワークロードのバックアップと複製の個々のニーズに応じてユース・ケース 2 と 3 を解決できるように、ガイドラインが提供されています。

保存データと転送中データのための Veeam 暗号化を構成して、VM データが暗号化されずに保管または転送されること (デフォルト設定) がないようにします。 Veeam 暗号化では、パスワードまたはパスフレーズを使用する必要があります。鍵の管理用の HPCS インスタンスは使用されません。 VM をリストアした場合は、暗号化ストレージ・ポリシーを選択して、VM が vSphere データ・ストアで暗号化されるようにしてください。

規制されたワークロードのデュアル・リージョン設計でVeeam Backup and Replicationを使用することは、保護されたリージョンの暗号化キーがリカバリ・リージョンで必要とされないことを意味します。したがって、 VMware サービス用のHPCSとKMIPを別々に使用することができる。

デュアル・リージョン・パターンで使用するデプロイメント・シナリオを作成するには、デプロイメント後に以下の操作が必要です。

各リージョンで Veeam VM を削除します。
各リージョンで Windows ベアメタル・サーバーを注文します。このサーバーの仕様は、Veeam on bare metal server 入門に記載しています。ユース・ケース 1 には小規模なサーバーで十分です。

ユース・ケース 2 および 3 では、ベアメタル・サーバーの数とサイズを計算する必要があります。詳しくは、リポジトリ・ストレージを参照してください。

保護リージョンのベアメタル Windows サーバーは、以下のコンポーネントをホストします。

プロキシ - プロキシは、ソース・データストアからVMデータを取得し、処理し、ターゲットに配信するために使用される「データ・ムーバー」コンポーネントである。原則として、プロキシーはソース・データのできる限り近くに配置してください。このプロキシーが、保護リージョンにある管理コンポーネントで使用されます。
リポジトリー - 保護リージョンの管理コンポーネントのバックアップ・ファイルの保管に使用される場所。リカバリー・リージョンからのバックアップ・コピー・ジョブのターゲットでもあります。
SFTP /SMB サーバー - これらのサーバーは Veeam のサービスではなく、ネイティブの Windows サービスです。一部の管理コンポーネントのファイル・レベルのバックアップに使用されます。 Veeam ファイル・コピー・ジョブは、ファイルをリカバリー・リージョンにコピーして保護を強化します。

リカバリー・リージョンのベアメタル Windows サーバーは、以下のコンポーネントをホストします。

バックアップ・サーバ - レプリケーションを使用する2サイト環境では、DRサイトにVeeam Backupサーバ・コンポーネントをインストールするのがベスト・プラクティスです。災害が発生した場合は、バックアップ・サーバーを使用してリカバリーを開始できます。
Veeam Backup and Replication Database - Veeam Backup and Replicationは、バックアップ・インフラストラクチャ、ジョブ設定、ジョブ履歴、セッション、およびその他の構成データに関する情報を Microsoft SQL Server データベースに保存します。
Enterprise Manager - Enterprise Manager は、Web インターフェースを使用して、1 つ以上のバックアップ・サーバーの管理およびレポート生成を一元的に行えるようにします。この設計ではバックアップ・サーバー・インスタンスは 1 つしかありませんが、バックアップ・ジョブまたはバックアップ・コピー・ジョブに暗号化を使用する場合は、Enterprise Manager をデプロイすることをお勧めします。災害復旧に使用できるように、Enterprise Manager サーバーをリカバリー・サイトにインストールすることをお勧めします。
プロキシー・サーバー - このプロキシーは、リカバリー・リージョンにある管理コンポーネントに使用されます。
リポジトリー - リカバリー・リージョンの管理コンポーネントのバックアップ・ファイルの保管に使用される場所。保護リージョンからのバックアップ・コピー・ジョブのターゲットでもあります。
SFTP /SMB サーバー - これらのサーバーは Veeam のサービスではなく、ネイティブの Windows サービスです。一部の管理コンポーネントのファイル・レベルのバックアップに使用されます。 Veeam ファイル・コピー・ジョブは、ファイルを保護リージョンにコピーして保護を強化します。

以下の Veeam の設計判断について確認してください。

パフォーマンスと可用性を最適化するためには、Veeam コンポーネントを別々の仮想サーバーおよび物理サーバーに配置することがベスト・プラクティスと見なされています。ただし、小規模な環境では、この方法によって複雑さが増します。そのため、ユースケース 1 ではオールインワン型のデプロイメントのシナリオを選択します。
保護対象の VM の総数が少ないので、ユース・ケース 1 のデータベースでは、組み込みデータベース・オプションを選択します。
ベアメタルサーバーとダイレクトアタッチストレージのオプションは、仮想化インフラのコンピュートとストレージから分離されたバックアップインフラを提供するために使用される。
2 サイト環境では、Veeam Backup サーバー・コンポーネントを DR サイトにインストールすることがベスト・プラクティスです。災害状況では、Veeam Backupサーバは復旧を開始することができます。
パスワードを失った場合の保護を使用できるように Enterprise Manager をデプロイします。 Enterprise Manager 管理者は、チャレンジ応答メカニズムを使用してバックアップ・ファイルをロックを解除できます。
高帯域幅接続を使用し、プロキシーをソース・データのできる限り近くに配置することをお勧めします。ソースからプロキシーへのトラフィックはまだ最適化されていません。つまり、このリンクではバックアップ・データの 100% が転送されます。プロキシーとリポジトリーの間は、正常に機能する接続で十分です。このリンクでは最適化されたデータ (通常はソース・データのサイズの約 50 %) が転送されるからです。そのため、保護リージョンとリカバリー・リージョンの両方にプロキシーを配置してください。
プロキシーは Windows Server または Linux OS でホストすることができます。それらのパフォーマンスにほとんど違いはありません。オールインワン型のデプロイメントのシナリオでは、Windows OS が使用されます。
リポジトリー・サーバーとしては、パフォーマンスを最大化し、保護する必要がある実稼働環境をバックアップ・ストレージから分離するために、ベアメタル・サーバーをお勧めします。また、この手法をプロキシーの機能と組み合わせて、仮想環境およびネットワークに対するオーバーヘッドを最小限に抑えることもお勧めします。ベスト・プラクティスは、バックアップと仮想化インフラストラクチャーに同じストレージを使用しないことです。その単一のシステムが失われると、実稼働環境とバックアップの両方でデータのコピーが失われることになるからです。
リポジトリー・サーバーは Windows にすることも Linux にすることもできます。オールインワン型のデプロイメントのシナリオでは、Windows OS が使用されます。また、Microsoft Windows ベースのリポジトリーの場合、Veeam は連邦情報処理標準 (FIPS 140) に準拠した Windows Crypto API を使用します。 Linux ベースのリポジトリーの場合、Veeam は、静的にリンクされた OpenSSL 暗号化ライブラリー (FIPS 140 のサポートなし) を使用します。
ベアメタル・サーバーの場合、ブロック・ストレージ・デバイスは、ローカル・ディスクにすることも、iSCSI を使用して SAN を介して提供される LUN にすることもできます。 VMware 規制ワークロード設計では、iSCSI を使用する SAN はサポートされません。そのため、ローカルディスクを使用する。
Veeam Backup and Replication構成のスケジュールされた暗号化バックアップを構成し、Veeamファイルコピージョブを使用してファイルを保護領域にコピーします。そうすることで、障害が発生した場合には Veeam Backup サーバーを再ビルドし、オフサイト・コピーから構成をリストアすることができます。
ユース・ケース 1 のストレージ所要量は少ないので、IBM Cloud Object Storage を使用するキャパシティー層は構成しません。

ユース・ケース 2 および 3 には、以下のガイダンスが適用されます。

バックアップ・リポジトリーの分離とスケーリングを可能にしてパフォーマンスを向上させるには、ワークロード・クラスターの 1 次サブネットでホストされる追加のベアメタル・サーバーをデプロイします。
パフォーマンスと可用性を最適化するためには、Veeam コンポーネントを別々の仮想サーバーおよび物理サーバーに配置することがベスト・プラクティスと見なされています。 vSphere HAを通じてHAを提供するため、Veeam Backupサーバに仮想マシンを使用することを検討してください。また、環境の成長に合わせて、非常に柔軟にサイズの変更とスケーリングを行うことも可能になります。
Microsoft SQL Server 2016 ExpressエディションはVeeam Backup and Replication標準インストールに含まれています。保護対象の VM が 500 台を超える環境では、別のバージョンの Microsoft SQL Server を使用することを検討してください。
ストレージ所要量が多い場合は、障害ドメインを小容量で対処しやすい状態にするために、各ボリュームのサイズを 200 TB 以下にすることをお勧めします。大きいリポジトリーにするには、複数のエクステントによるスケールアウト・バックアップ・リポジトリーを使用してください。
IBM Cloud Object Storage リポジトリーは単独では使用できませんが、Veeam のスケールアウト・バックアップ・リポジトリーのキャパシティー層として構成できます。大規模なデプロイメントの場合や、アーカイブ所要量が大きいデプロイメントの場合は、このタイプのリポジトリーを検討してください。

KMIP for VMware

Key Management Interoperability Protocol (KMIP) for VMware サービスは、vCenter と Hyper Protect Crypto Service の相互接続を可能にするための、24 時間 365 日の高可用性サービスを提供します。 Regulated Workloadsの暗号化設計の詳細については、暗号化を参照してください。

KMIP は、リージョン・ベースのサービスです。したがって、 Regulated Workloads デュアルリージョン設計では、別のKMIPインスタンスが使用され、 vCenter とHyper Protect Crypto Serviceにインターフェースされる。利用可能な地域は、ダラス、ワシントンDC、シドニー、ロンドン、フランクフルト、東京。 KMIPサービスを注文する際、 Regulated Workloads インスタンスがデプロイされているリージョンでKMIPインスタンスを選択します。

Hyper Protect Crypto Service

IBM Hyper Protect Crypto Service (HPCS) は、FIPS 140-2 レベル 4 の認定を受けたハードウェア・セキュリティー・モジュールを基礎としています。 IBM Cloud for VMware® Regulated Workloads SaaS プロバイダーと SaaS コンシューマーが暗号鍵を管理できるようにする。

詳しくは、以下を参照してください。

現在、HPCS は、ダラス、ワシントン DC、シドニー、およびフランクフルトのリージョンで使用可能です。ロンドンと東京の Regulated Workloads インスタンスに対して、異なる地域のHPCSインスタンスを使用することは可能ですが、理想的ではありません。

Regulated Workloadsデザインには、暗号化のための2つのユースケースがあります：

SaaS プロバイダー - 管理 VM とワークロード VM の暗号化に使用される VMware vSphere 暗号化。これらの鍵は、SaaS プロバイダーによって管理されます。
SaaS コンシューマー - オプションのアプリケーション・レベルの暗号化で、VMの暗号化に加えてアプリケーション・データの暗号化にも使用される。これらの鍵は、SaaS 利用者によって管理されます。

SaaS Providerの鍵管理のための Regulated Workloads デュアル・リージョン設計では、2つの別個のHCPSインスタンスが、 VMware Serviceのためのリージョン固有のKMIPとともに使用される。この HCPS インスタンス間で鍵が共有されることはありません。

Veeam Backup and Replication は、暗号化されていないデータにアクセスできます。バックアップやレプリケーションのデータにはソース暗号鍵は必要ありません。バックアップのリストア時やレプリカの構成時には、ターゲットの暗号化ストレージ・ポリシーを指定します。

Regulated Workloadsデュアルゾーン設計では、以下のステップでリージョン間のバックアップとリストアのプロセスを説明します：

保護対象の VM は、VMware データ・ストアで、VMware vSphere 暗号化を使用して暗号化されています。
保護対象の VM のバックアップを取得します。
VM バックアップ・ファイルは、保護リージョンの Veeam リポジトリーにあるディスクに、Veeam 暗号化を使用して暗号化された状態で保管されます。その暗号化を保護しているパスワードは、Veeam データベースに保管されます。
ローカル・リストアが必要になると、VMware データストア暗号化ストレージ・ポリシーを使用し、KMIP for VMware サービスを介して保護リージョンの HPCS インスタンスにある暗号鍵で VM を再暗号化します。
Veeam ネットワーク暗号化が、リカバリー・リージョンへのファイルとバックアップのコピー・ジョブに使用されます。
VM バックアップ・ファイルは、リカバリー・リージョンの Veeam リポジトリーにあるディスクに、暗号化された状態で保管されます。
リカバリー・リージョンでリストアが必要になると、Veeam データストア暗号化ストレージ・ポリシーを使用し、KMIP for VMware サービスを介してリカバリー・リージョンの HPCS インスタンスにある暗号鍵で VM を再暗号化します。

Veeam暗号化の詳細については、暗号化標準を参照してください。

SaaS Consumer鍵管理のための Regulated Workloads デュアル領域設計では、保護領域で使用されるのと同じ暗号鍵が回復領域でも必要となる。現在、HPCS は、2 つのリージョンで同じ暗号鍵を使用することをサポートしていません。最初の HPCS インスタンスで障害が発生した場合は、もう一方のリージョンの HPCS インスタンスに鍵をリストアできます。