OpenShift Red Hat OpenShift on IBM Cloud クラスタ上のData Foundation地域災害復旧

仮想プライベートクラウド 4.17 そしてその後

地域災害復旧は、地理的地域の利用が不可能な場合でも、事業の継続性を確保します。 Red Hat のAdvanced Cluster Management（ACM）を使用すると、 OpenShift Data Foundation（ODF）クラスター向けの地域災害復旧ソリューションを設定できます。

各ステップには、どのクラスターで実行すべきかを示すラベルが付いています。以下の凡例を参考にしてください。

クラスタタグの凡例
タグ	クラスター
ハブクラスタ	ハブクラスタ（ACMがインストールされているクラスタ）で実行すべき手順。
マネージド・クラスター	各管理対象クラスター（プライマリおよびセカンダリのODFクラスター）で実行すべき手順。

このソリューションの大まかな手順は以下の通りです

ハブクラスタを作成します。
ハブ・クラスタの信頼済みプロファイルを作成します。
マネージドクラスタを作成します。
ハブクラスタ上でACM用のシークレットを準備します。
ハブクラスタにACMアドオンをインストールします。
管理対象クラスタにSubmarinerをインストールし、クラスタ間の接続を確立します。
管理対象クラスタにODFをインストールします。
地域災害復旧ポリシーを設定します。

このセットアップでは、ACMをインストールしたハブクラスタがODFクラスタを管理します。プライマリ ODF クラスタが利用できなくなった場合、ハブクラスタはプライマリ ODF クラスタからセカンダリ ODF クラスタへ、アプリケーションとデータを移行します。

ODF Regional Disaster Recovery は、サブスクリプション型、 ApplicationSet-based, によって検出された、および VM ベースのアプリケーションに対応しています。詳細については、このページの下部にある「対応アプリケーションおよびワークロード」をご覧ください。

開始前に

クラスターを作成する前に、クラスター作成コマンドに入力する必要があるVPCおよび Cloud Object Storage の詳細情報を用意しておいてください。

VPC IDを取得してください。各クラスターで使用するVPCのIDをメモしておいてください。
```
ibmcloud is vpcs
```
特定のVPCのサブネットの詳細を取得します。各クラスターで使用するサブネットIDをメモしておいてください。
```
ibmcloud is subnets --vpc VPC_ID
```
Cloud Object Storage のインスタンスを一覧表示してください。
```
ibmcloud resource service-instances --service-name cloud-object-storage
```
使用するインスタンスのCRNを取得します。「 ID 」フィールドの値を確認してください。
```
ibmcloud resource service-instance SERVICE_INSTANCE
```

ステップ 1. ハブクラスタを作成する

ハブクラスタ

これは、プライマリおよびセカンダリのODFクラスタを管理するためにACMをインストールするクラスタです。ハブクラスタに、少なくとも 16 vCPU x 64 GB の演算容量が利用可能であることを確認してください。

各クラスタについて、CLIで --disable-outbound-traffic-protection パラメータを含めるか、UIでアウトバウンド・トラフィックの保護を無効にするオプションを選択して、アウトバウンド・トラフィックを許可するようにしてください。

us-east 、ACMをインストールする VPCクラスタを作成する。これはODFクラスタを管理するために使用できるハブ・クラスタです。ハブクラスターには、RHCOS を実行するワーカーノードが 3 台以上あり、利用可能な演算能力が 16 vCPU 以上かつ 64 GB 以上であり、アウトバウンドトラフィックが無効化されており、 ACMの参加要件の要件をすべて満たしていることを確認してください。次のコマンド例は、 us-east にACM用のクラスタを作成します。
```
ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name acm-hub-cluster-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
```
出力からクラスタIDを確認してください。後の手順で必要になります。

ステップ 2. ハブ・クラスタの信頼済みプロファイルを作成する

ハブクラスタ

信頼済みプロファイルを作成します。

ibmcloud iam trusted-profile-create acm-operator-profile

Red Hat OpenShift のコンピュートリソースにおいて、 kube-system ネームスペースをスコープとするコンピュートリソースのトラストルールを作成します。

ibmcloud iam trusted-profile-rule-create acm-operator-profile \
  --name kube-system-rule \
  --type Profile-CR \
  --conditions claim:namespace,operator:EQUALS,value:kube-system \
  --cr-type ROKS_SA

IAMアクセスポリシーをプロファイルに割り当てます。 CLUSTER_ID を、ご使用のハブクラスタ ID に置き換えてください。

ibmcloud iam trusted-profile-policy-create acm-operator-profile \
  --roles Reader,Viewer,Operator,Editor \
  --service-name containers-kubernetes \
  --service-instance CLUSTER_ID

ハブクラスタに信頼済みプロファイルを割り当てます。クラスタに信頼済みプロファイルを割り当てると、それを削除することはできません。
```
ibmcloud oc experimental trusted-profile set --cluster CLUSTER_NAME_OR_ID --trusted-profile TRUSTED_PROFILE_ID
```
ODFバージョン 4.21 以降を使用している場合は、ハブクラスタに OpenShift GitOps オペレーターをインストールしてください。インストール手順については、「 Webコンソールでの Red Hat OpenShift GitOps Operatorのインストール」を参照してください。

ステップ 3. マネージド・クラスタを作成する

マネージド・クラスター

us-east に、RHCOS を実行するワーカーノードを少なくとも 3 台、利用可能なコンピューティング容量が少なくとも 16 vCPU および 64 GB であり、アウトバウンドトラフィック保護が無効になっている VPC クラスターを作成します。これがプライマリ管理ODFクラスタとなる。次のコマンド例は、 us-east にクラスタを作成します。
```
ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-1-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
```
jp-tok に、RHCOS を実行するワーカーノードを少なくとも 3 台、利用可能なコンピューティング容量が少なくとも 16 vCPU および 64 GB であり、アウトバウンドトラフィック保護が無効になっている VPC クラスターを作成します。これはセカンダリ管理ODFクラスタとなる。高可用性のためには、セカンダリクラスタのネットワークがプライマリクラスタのネットワークと重ならないようにしてください。次のコマンド例は、 jp-tok にクラスタを作成します。
```
ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-2-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone jp-tok --version 4.21.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
```

ステップ 4. ACMに向けたシークレットの準備

ハブクラスタ

ACM で管理したい各クラスターについて、ハブクラスター上に、管理対象クラスターのアクセストークンとサーバー URL を含むシークレットを作成する必要があります。

ACM アドオンのインストールプロセス中にマネージドクラスタをインポートする場合は、インストールを開始する前に、以下の手順を完了してください。ハブクラスターにアドオンをインストールした後で、シークレットを作成し、マネージドクラスターをインポートすることを選択した場合は、CLI を使用して追加の手順を実行することで、これを行うことができます。

管理したい各クラスターについて、以下の手順を実行してください。

ACM で管理したいクラスター上で、 URL コマンドを実行してサーバーを検索します。出力の中から、「 URL 」のマスター 値を見つけ、それを書き留めておいてください。シークレット内で参照するサーバーは、 URL です。また、以下の手順でもこの URL を使用します。
```
ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
```
出力例。
```
NAME:                           mycluster
ID:                             1234567
State:                          normal
Created:                        2025-01-22T19:22:16+0000
Location:                       dal10
Master URL:                     https://c100-e.<region>.containers.cloud.ibm.com:<port>
...
```
Red Hat OpenShift のOAuthサーバーのベース URL を取得します。「 MASTER_URL 」を、前の手順で求めた「 URL 」に置き換えてください。このコマンドは、 /oauth/token という接尾辞を除いた、 URL という基底名を抽出します。
```
curl -sS MASTER_URL/.well-known/oauth-authorization-server | jq -r .token_endpoint | sed 's#/oauth/token##'
```
出力例。
```
https://c111-e.us-east.containers.cloud.ibm.com:31282
```
前の手順で取得したエンドポイントを使用して、アクセストークンを取得します。次の cURL コマンドを実行してください。この際、 URL を前の手順で得られた出力に、 API_KEY を自身の IBM Cloud APIキーに置き換えてください。出力の中から、 Locationレスポンスに含まれる ACCESS_TOKEN を探してください。これは、シークレットに含めるアクセス・トークンです。

curl 要求の例:
```
curl -u 'apikey:API_KEY' -H "X-CSRF-Token: a" 'URL/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -vvv
```
出力例。 ACCESS_TOKEN は Location レスポンス文字列に含まれています。
```
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 2030 00:00:00 GMT
< Location: TOKEN_ENDPOINT/oauth/token/implicit#access_token=ACCESS_TOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer
...
```
ハブクラスター上で、クラスターアクセストークンとサーバー URL を含むシークレットを作成します。シークレットの作成に関する詳細については、『 Kubernetes 』ドキュメントの「シークレットの操作」を参照してください。

秘密の例。
```
apiVersion: v1
kind: Secret
metadata:
  name: SECRET_NAME
  namespace: SECRET_NAMESPACE  # The namespace that the secret is to be created in
type: Opaque
stringData:
  token: ACCESS_TOKEN
  server: SERVER_URL
```

ステップ 5. ハブ・クラスタにACMアドオンをインストールする

ハブクラスタ

CLI を使用して、ハブクラスターに ACM アドオンをインストールします。

ACMアドオンのデフォルト版を探してください。
```
ibmcloud oc cluster addon versions
```
ACMのアドオンオプションを確認してください。コマンドでは、前の手順で確認したデフォルトのバージョンを指定してください。アドオンをインストールする際に含めたいオプションがあれば、それをメモしておいてください。
```
ibmcloud oc cluster addon options --addon acm --version DEFAULT_VERSION
```
アドオンで管理するクラスターをインポートしたい場合は、まだ行っていない場合は、「 ACM用のシークレットの準備」の手順に従ってください。ハブクラスター上で作成したクラスターID、およびシークレットの名前とネームスペースを必ず保存しておいてください。この手順は、ハブクラスタにアドオンがインストールされた後に実行することも可能ですが、インストール後に管理対象クラスタをインポートするには、追加の手順が必要となります。
コマンドを実行して、アドオンを有効にしてください。インストールプロセス中にクラスタをインポートする場合は、 billingPlan および isLicenseAccepted パラメータを必ず指定してください。また、必要に応じて --managedClusters パラメータも指定してください。
```
ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'managedClusters=["clusterid:CLUSTER_ID;secretname:SECRET_NAME;secretnamespace:SECRET_NAMESPACE;action:IMPORT"]' --param 'billingPlan=PLAN' --param 'isLicenseAccepted=BOOLEAN'
```
コマンドのパラメータ。各パラメータタイプの例については、以下のコマンド例を参照してください。
--cluster

必須。 ACM アドオンをインストールするハブクラスタの ID。

--param 'managedClusters=["]
オプション。アドオンのインストールプロセス中に、管理対象クラスタをインポートするには、このパラメータを1回以上指定してください。この手順は後で実行することもできます。詳細については、「 ACM 用のシークレットの準備」を参照してください。

以下の値を指定します。
clusterid: インポートするマネージドクラスタのID。
secretname: ハブクラスター上で作成したシークレットの名前。このシークレットには、管理対象クラスターの認証情報が格納されています。
secretnamespace: ハブクラスター上で作成したシークレットのネームスペース。このシークレットには、管理対象クラスターの認証情報が格納されています。
action:IMPORT: 管理対象クラスタのIMPORTアクションを指定するパラメータ。
--param 'billingPlan='

必須。 ACMで選択したい課金プラン。 ACMの Kubernetes プランでは、「 KUBERNETES 」を指定してください。

--param 'isLicenseAccepted='

必須。選択した課金プランのライセンス契約に同意するには、「 TRUE 」を指定してください。本ライセンスに同意することにより、お客様は適用される利用規約に同意し、選択したプランに含まれるサービス内容を理解したことを認めるものとします。
「 Kubernetes 」向けのACM 課金プランを使用してACMアドオンをインストールし、マネージドクラスターをインポートするためのコマンド例。
```
ibmcloud ks cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'managedClusters=["clusterid:w7rthce34gfbq7ww12d3;secretname:managed-secret-1;secretnamespace:managed-ns1;action:Import"]' --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
```

アドオンがインストールされたことを確認してください。アドオンが以下の出力に表示されるまで、数分かかる場合があります。

ハブクラスタ上で、 acmhub リソースが作成されていることを確認してください。

    oc get acmhub
    ```
    出力例。

    ```sh {: screen}
        NAME       AGE
        acm-auto   1h
    ```
1. ハブクラスタ上で、 `acmhub` のステータスを確認してください。

```sh {: pre}
    oc describe acmhubstatus
    ```
    出力例。

    ```sh {: screen}
    status
        phase: Ready
    ```

ステップ 6. サブマリーナーアドオンの設定

マネージド・クラスター

Submarinerアドオンをインストールして構成する手順に従って、2つの管理対象クラスタ間の接続を確立します。これらの手順はACMコンソールを使用します。詳細については、『 Red Hat 』のドキュメントにある「コンソールを使用した Submariner のデプロイ」を参照してください。

ACMコンソールに移動する。次に、[ フリート管理 ] > [ インフラストラクチャ ] > [ クラスタ ] > [ クラスタセット ]をクリックします。
Create a cluster setをクリックします。プロンプトに従って、2つの管理対象クラスタをクラスタセットに追加します。
クラスタセットにSubmarinerアドオンをインストールするオプションをクリックします。
アドオンインストールの対象クラスタとして管理クラスタを選択します。
両方のクラスタの構成を確認する際は、以下の設定を変更し、残りはデフォルトのままにしておきます。次に、「 インストール 」をクリックします。
```
globalnetEnabled: true (checked)
gateways: 2
NATTEnable: false (unchecked)
cableDriver: vxlan.
```
Submarinerアドオンのステータスが「健全（緑）」と表示されるまでお待ちください。これには最大20分ほどかかる場合があります。

手順 7. OpenShift Data Foundation のインストールと設定

マネージド・クラスター

2つの管理対象クラスタにODFをインストールして設定します。プライマリおよびセカンダリの管理対象クラスタの両方でこれらの手順を完了していることを確認してください。

OpenShift Data Foundationアドオンを 2つの管理クラスタにインストールする手順に従ってください。デフォルトのODFバージョン以降を指定する。インストール時にアドオンオプションとして NooBaa を有効にするオプションが含まれていることを確認してください。
ODFファンデーションが正常にインストールされたことを確認する。出力で、ステータスが Ready と表示されていることを確認する。
```
oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
```
コマンドを実行して、 storageCluster リソースの multiClusterService セクションの ACM Managed Cluster Name を更新する。これにより、ODFは GlobalNet。詳細については、 OpenShift Data Foundationクラスタを管理クラスタ上に作成するを参照してください。

コマンドの MANAGED_CLUSTER_NAME を管理クラスターの名前に置き換えてください。
```
kubectl patch storagecluster -n openshift-storage ocs-storagecluster --type merge -p'{"spec":{"network":{"multiClusterService":{"clusterID":"MANAGED_CLUSTER_NAME","enabled":true}}}}'
```

サービス輸出を確認する。出力に表示されるまで数分かかるかもしれない。

oc get serviceexport -n openshift-storage

出力例:

NAME              AGE
rook-ceph-mon-d   4d14h
rook-ceph-mon-e   4d14h
rook-ceph-mon-f   4d14h
rook-ceph-osd-0   4d14h
rook-ceph-osd-1   4d14h
rook-ceph-osd-2   4d14h

以下のYAMLを使用して、 ocs-provider-server。

apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: ocs-provider-server
  namespace: openshift-storage

コマンドを実行して storageCluster リソースを更新し、作成した ocs-provider-server サービスエクスポートを使用するようにします。

oc annotate storagecluster ocs-storagecluster -n openshift-storage ocs.openshift.io/api-server-exported-address=MANAGED_CLUSTER_NAME.ocs-provider-server.openshift-storage.svc.clusterset.local:50051.

storageCluster リソースの準備ができていることを確認する。

oc get storagecluster -n openshift-storage

出力例。

NAME                    PHASE  
ocs-storagecluster      Ready

ステップ 8. 地域災害復旧ポリシーの設定

ハブクラスタ

ハブクラスタに ODF Multicluster Orchestrator をインストールし、2 つの管理対象クラスタ間でミラーリングを有効にする DR ポリシーを作成してください。

ODF Multicluster Orchestratorをインストールします ACMハブクラスタ。互換性を確保するため、前のセクションで管理クラスタにインストールしたODFバージョンと同じバージョン番号をインストールしてください。

オペレータポッドが動作していることを確認して、インストールを確認します。

oc get pods -n openshift-operators

出力例。

NAME                                        READY   STATUS       RESTARTS    AGE
odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h

ACMハブ・クラスタで、同期間隔5分のDRポリシーを作成し、パラメータに各管理クラスタを指定します。これにより、両方の管理クラスタに NooBaa オブジェクトバケットが作成され、ボリュームレプリケーション用のODF Cephブロックプールミラーリングが有効になります。
1. ACMコンソールに移動し、 Fleet management > Data services > Disaster Recovery > Policies > Create DR Policyをクリックします。
2. 以下のパラメータを含むDRポリシーを作成する。
  - 接続済みのクラスター：PRIMARY_MANAGED_CLUSTER_NAME、SECONDARY_MANAGED_CLUSTER_NAME
  - レプリケーションポリシー：非同期
  - 複製間隔： 5m
ハブ・クラスタでコマンドを実行して、DRポリシーが作成され、管理対象のクラスタに適用されたことを確認します。
```
oc get drpolicy DRPOLICY_NAME -o jsonpath='{.status.conditions[].reason}{"\n"}'
```
```
oc get drclusters
```
出力例。
```
NAME        AGE
managed-cluster1   4m42s
managed-cluster2   4m42s
```

管理対象の各クラスタで、DRポリシーが適用され、健全な状態であることを確認します。

oc get csv,pod -n openshift-dr-system

出力例。

NAME                                                                          DISPLAY                         VERSION        REPLACES   PHASE
clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0       Openshift DR Cluster Operator   4.15.0                    Succeeded
clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0             VolSync                         0.8.0                     Succeeded
NAME                                             READY   STATUS    RESTARTS   AGE
pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h

oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'

出力例。

{"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}

オプションです：ODF地域災害復旧機能を強化するためにインストールできるオペレータを確認してください。
オプション ：ディザスタリカバリ構成をテストする。

ODF地域災害復旧のためのオプション・オペレーター

ODF Regional Disaster Recovery機能を強化するために、ACMハブまたは管理クラスタにインストールできるオプションのオペレータを確認してください。なお、 IBM、これらのオペレーターを管理する責任はない。

お客様は、更新、監視、回復、再インストールを含むがこれに限定されない、これらのオペレーターの管理に責任を負うものとする。

ODF地域災害復旧のためのオプション・オペレーター
オペレーター	説明	詳細情報
OpenShift データ保護API ( OADP ) オペレーター	OpenShift クラスタ用のバックアップおよびリストア API を作成するために使用します。管理クラスタにインストールします。	データ保護のための OpenShift API の紹介

災害復旧構成のテスト

災害復旧ソリューションをテストするためのサンプルアプリケーションを作成します。詳細は、「災害復旧アプリケーションのテスト用サンプルアプリケーションの作成」を参照してください。

ACMコンソールからサブスクリプションベースのアプリケーションをデプロイします。アプリケーションのトポロジータブは、すべてのアプリケーションリソースが正常にデプロイされると緑色で表示されます。
申請ページで 、「アクション」 > 「データポリシーの管理」 の順にクリックします。
このアプリケーションに、先に作成したDRポリシーを割り当てます。
アプリケーションポッドがプライマリクラスタ上で実行されていることを確認します。
申請ページで 、「アクション」 > 「フェールオーバーアプリケーション」 の順にクリックします。セカンダリ ODF クラスタをターゲットクラスタとして選択します。 [開始] をクリックします。
アプリケーションポッドがセカンダリクラスタに移動されたことを確認します。
申請ページで 、「アクション」 ＞ 「申請の移転」 の順にクリックします。プライマリ ODF クラスタをターゲットクラスタとして選択します。 [開始] をクリックします。
アプリケーションポッドがプライマリクラスタに戻されたことを確認します。

ODF地域災害復旧環境のアップグレード

ODF-RDR 環境のコンポーネントをいつ、どのようにアップグレードするかについては、「 ODF 地域災害復旧環境のアップグレード」を参照してください。

トラブルシューティング

ODFのリージョン間災害復旧構成で問題が発生した場合は、「 OpenShift Data Foundationのリージョン間災害復旧構成の確認」を参照し、セットアップ内の各コンポーネントの状態を確認してください。

対応アプリケーションおよびワークロード

セットアップが完了したら、リージョナル・ディザスタリカバリを適用できるアプリケーションやワークロードの種類を確認してください。

サブスクリプション・ベース

アプリケーションは、 GitHub, Helm のレポや、 Object Storage のような外部ソースからデプロイされる。

詳細については、 Red Hat ドキュメントのサンプルサブスクリプションベースアプリケーションの作成を参照してください。

ApplicationSet-based

アプリケーションは、継続的デリバリーを管理する GitOps オペレーターを使用して、 GitHub リポジトリからデプロイされます。これには2つのサブタイプがある：

GitOps プルモデル（ ArgoCD pull） ：管理クラスタは GitOps 演算子を使用して GitHub からアプリケーションをプルします。

GitOps プッシュ・モデル ( ArgoCD push)： GitOps オペレータは、デプロイやアップデートの際にアプリケーションを管理クラスタにプッシュします。

詳細については、 Red Hat ドキュメントの「 Creating Application-set based applications 」を参照してください。

GitOps サブタイプの詳細については、 Red Hat ドキュメントの「 Deploying Argo CD with Push and Pull model 」を参照してください。

発見されたアプリケーション

あるアプリケーションが、ACMを使用せずにマネージドクラスタに事前にデプロイされた。この場合、プリインストールされたアプリにACMディスカバリーを使用しても、DRポリシーを構成することができる。

詳細については、 Red Hat ドキュメントの「 Disaster recovery protection for discovered applications 」を参照してください。

VM 展開を含むアプリケーション

VM ベースのアプリケーションは、ACM コンソールから管理クラスタ上にデプロイされる。これらの VM アプリケーションは、前述の通り、サブスクリプション型、 ApplicationSet-based,、またはディスカバリー型として利用可能です。これらのタイプのアプリケーションについては、ACMコンソールから VM の操作を開始、停止、一時停止、削除するためのオプションが利用可能です。

詳細については、 Red Hat ドキュメントの Red Hat Advanced Cluster Management for Virtualization を参照してください。