Azure Site Recovery では、テナント サブスクリプションについてマルチテナント環境がサポートされます。 また、マイクロソフト クラウド ソリューション プロバイダー (CSP) プログラムを使用して作成され、管理されているテナント サブスクリプションのマルチテナントもサポートします。
この記事では、マルチテナント VMware の Azure へのレプリケーションについて、その実装と管理の概要を示します。
マルチテナント環境
主なマルチテナント モデルとして次の 3 つがあります。
共有ホスティング サービス プロバイダー (HSP) : パートナーが物理インフラストラクチャを所有し、共有リソース (vCenter、データセンター、物理記憶領域など) を使用して、複数のテナント VM を同じインフラストラクチャ上でホストします。 パートナーは管理サービスとしてディザスター リカバリーの管理を提供できます。また、テナントはセルフサービス ソリューションとしてディザスター リカバリーを所有できます。
専用ホスティング サービス プロバイダー: パートナーが物理インフラストラクチャを所有しますが、専用リソース (複数の vCenter、物理データストアなど) を使用して個別のインフラストラクチャ上の各テナントの VM をホストします。 パートナーは管理サービスとしてディザスター リカバリーの管理を提供できます。また、テナントはセルフサービス ソリューションとしてディザスター リカバリーを所有できます。
管理サービス プロバイダー (MSP) :VM をホストする物理インフラストラクチャを顧客が所有し、パートナーがディザスター リカバリーを有効にして管理します。
共有ホスティング サービス プロバイダー (HSP)
他の 2 つのシナリオは共有ホスティング シナリオのサブセットであり、同じ原則を使用します。 違いについては、この共有ホスティング ガイダンスの最後に説明します。
マルチテナント シナリオの基本要件は、各テナントを分離することです。 テナントは別のテナントがホストしている内容を観察できないようにする必要があります。 この要件はセルフサービス環境では非常に重要な場合がありますが、パートナー管理された環境ではセルフサービス環境ほど重要ではありません。 この記事では、テナントの分離が必須であることを前提とします。
アーキテクチャは、次の図のようになります。
1 つの vCenter サーバーを使用した共有ホスティング
この図では、各顧客が個別の管理サーバーを使用しています。 この構成により、テナントによるアクセスをテナント固有の VM に制限し、テナントを分離できます。 VMware VM のレプリケーションでは、構成サーバーを使用して VM を検出し、エージェントをインストールします。 マルチテナント環境にも同じ原則が適用されますが、vCenter アクセス制御を使用して、VM 検出の制限が追加されます。
この場合のデータ分離要件とは、機密性の高いすべてのインフラストラクチャ情報 (アクセス資格情報など) を、テナントに対して非公開のまま維持することを意味します。 そのため、管理サーバーのすべてのコンポーネントをパートナーの排他的制御下に置くことをお勧めします。 管理サーバーのコンポーネントは、次のとおりです。
- 構成サーバー
- プロセス サーバー
- マスター ターゲット サーバー
個別のスケール アウト プロセス サーバーも、パートナーの管理下に置かれます。
構成サーバー アカウント
マルチテナント シナリオでは、すべての構成サーバーで次の2 つのアカウントが使用されます。
vCenter アクセス アカウント:このアカウントは、テナント VM を検出するために使用されます。 このアカウントには、vCenter のアクセス許可が割り当てられます。 アクセス リークを防ぐため、これらの資格情報はパートナー自身が構成ツールに入力することをお勧めします。
仮想マシン アクセス アカウント:このアカウントは、テナント VM にモビリティ サービス エージェントを (自動プッシュで) インストールするために使用されます。 これは通常、テナントがパートナーに提供するドメイン アカウントか、パートナーが直接管理するアカウントです。 テナントが詳細情報をパートナーと直接共有することを望まない場合は、テナントが構成サーバーに時間限定でアクセスし、資格情報を入力することもできます。 また、パートナーの支援を得て、テナントがモビリティ サービス エージェントを手動でインストールすることもできます。
vCenter アカウントの要件
構成サーバーには、特別なロールが割り当てられたアカウントを構成します。
このロール割り当ては、各 vCenter オブジェクトの vCenter アクセス アカウントに適用されるようにし、子オブジェクトには伝達されないようにする必要があります。 アクセスが伝達されると、他のオブジェクトに誤ってアクセスする可能性があるため、この構成によってテナントの分離を確保できます。
![[Propagate to Child Objects]\(子オブジェクトに伝達\) オプション](media/vmware-azure-multi-tenant-overview/assign-permissions-without-propagation.png)
もう 1 つのアプローチとして、ユーザー アカウントとロールをデータセンター オブジェクト レベルで割り当て、それらを子オブジェクトに伝達する方法もあります。 その後、特定のテナントからアクセスされては困るすべてのオブジェクト (他のテナントに属する VM など) について、アカウントに "アクセスなし" ロールを付与します。 ただし、この構成は扱いが煩雑です。 親から継承されたアクセス権がすべての新しい子オブジェクトにも自動的に付与されるので、予期しないアクセス制御が行われる恐れがあります。 そのため、最初の方法を使用することをお勧めします。
vCenter アカウントを作成する
定義済みの "読み取り専用" ロールを複製して新しいロールを作成し、ロールにわかりやすい名前を付けます (この例では Azure_Site_Recovery)。
このロールに次のアクセス許可を割り当てます。
データストア:領域の割り当て、データストアの参照、低レベルのファイル操作、ファイルの削除、仮想マシン ファイルの更新
ネットワーク:ネットワークの割り当て
リソース:リソース プールへの VM の割り当て、電源がオフの VM の移行、電源がオンの VM の移行
タスク:タスクの作成、タスクの更新
VM - 構成:All
VM - [Interaction](操作)> [Answer question](質問への回答)、[Device connection](デバイスの接続)、[Configure CD media](CD メディアの設定)、[Configure floppy media](フロッピー メディアの設定)、[Power off](電源を切る)、[Power on](電源を入れる)、[VMware tools install](VMware ツールのインストール)
VM - [Inventory](インベントリ)> [Create from existing](既存のものから作成する)、[Create new](新規作成)、[Register](登録)、[Unregister](登録の解除)
VM - [Provisioning](プロビジョニング)> [Allow virtual machine download](仮想マシンのダウンロードを許可)、[Allow virtual machine files upload](仮想マシン ファイルのアップロードを許可)
VM - [Snapshot management](スナップショットの管理)> [Remove snapshots](スナップショットの削除)
![[ロールの編集] ダイアログ ボックス](media/vmware-azure-multi-tenant-overview/edit-role-permissions.png)
各種オブジェクトについて、(テナントの構成サーバーで使用される) vCenter アカウントにアクセス レベルを割り当てます。
オブジェクト 役割 解説 vCenter 読み取り専用 さまざまなオブジェクトを管理するために vCenter によるアクセスを許可する場合にのみ必要です。 このアカウントをテナントに提供することも、vCenter での管理操作に使用することもない場合は、このアクセス許可を削除できます。 データセンター Azure_Site_Recovery ホストとホスト クラスター Azure_Site_Recovery フェールオーバー前とフェールバック後にアクセス可能なホストだけがテナントの VM を保持するように、アクセスがオブジェクト レベルであることを再確認します。 データストアとデータストア クラスター Azure_Site_Recovery 同上 ネットワーク Azure_Site_Recovery 管理サーバー Azure_Site_Recovery CS マシンの外部にあるすべてのコンポーネント (CS、PS、MT) へのアクセスが含まれます。 テナント VM Azure_Site_Recovery 特定のテナントのすべての新しいテナント VM もこのアクセスを確実に取得します。そうしないと、Azure Portal から検出できなくなります。
これで vCenter アカウントのアクセスが完了しました。 この手順は、フェールバック操作を完了するための最小限のアクセス許可要件を満たしています。 これらのアクセス許可を既存のポリシーで使用することもできます。 既存のアクセス許可セットを変更して、手順 2. で説明したロールのアクセス許可を追加するだけです。
フェールオーバーのみ
ディザスター リカバリー操作がフェールオーバーまでしか行われないように制限する (つまり、フェールバック機能を使用しない) 場合は、前述の手順に次の例外を適用します。
- vCenter アクセス アカウントに Azure_Site_Recovery ロールを 割り当てる代わりに、読み取り専用ロールだけをそのアカウントに割り当てます。 このアクセス許可セットでは、VM のレプリケーションとフェールオーバーは許可されますが、フェールバックは許可されません。
- 上記のプロセスの他のすべてのものはそのままになります。 テナントの分離を確保し、VM の検出を制限するために、すべてのアクセス許可は引き続きオブジェクト レベルでのみ割り当てられ、子オブジェクトには伝達されません。
テナント サブスクリプションにリソースをデプロイする
Azure Portal でリソース グループを作成してから、通常のプロセスごとに Recovery Services コンテナーをデプロイします。
コンテナー登録キーをダウンロードします。
コンテナー登録キーを使用して、テナントの CS を登録します。
2 つのアクセス アカウント (vCenter サーバーにアクセスするためのアカウントと、VM にアクセスするためのアカウント) の資格情報を入力します。
コンテナー内でサーバーを登録する
- Azure Portal を使用し、以前に作成した資格情報コンテナー内で、作成した vCenter アカウントを使用して vCenter サーバーを構成サーバーに登録します。
- 通常のプロセスごとに、Site Recovery の "インフラストラクチャの準備" プロセスを完了します。
- これで VM をレプリケートする準備ができました。 [レプリケート]>[仮想マシンの選択] に、目的のテナントの VM だけが表示されていることを確認してください。
専用ホスティング ソリューション
次の図に示すように、専用ホスティング ソリューションのアーキテクチャの違いは、各テナントのインフラストラクチャがそのテナントに対してのみ設定されていることです。
複数の vCenter を使用する専用ホスティング シナリオ
管理されたサービス ソリューション
次の図に示すように、管理されたサービス ソリューションのアーキテクチャの違いは、各テナントのインフラストラクチャが他のテナントのインフラストラクチャから物理的にも分離されていることです。 通常、このシナリオは、テナントがインフラストラクチャを所有し、ソリューション プロバイダーにディザスター リカバリーを管理してもらう場合に発生します。
複数の vCenter を使用する管理されたサービス シナリオ
次のステップ
- Site Recovery のロールベースのアクセス制御の詳細について学習する。
- Azure に VMware VM のディザスター リカバリーを設定する方法を学習する。
- VMware VM の CSP を使用したマルチテナントの詳細について説明します。