OpenShift Red Hat OpenShift on IBM Cloud クラスタ上のData Foundation地域災害復旧
Virtual Private Cloud 4.17 and later
地域災害復旧は、地理的地域の利用が不可能な場合でも、事業の継続性を確保します。 Red Hat のAdvanced Cluster Management(ACM)を使用すると、 OpenShift Data Foundation(ODF)クラスター向けの地域災害復旧ソリューションを設定できます。
各ステップには、どのクラスターで実行すべきかを示すラベルが付いています。 以下の凡例を参考にしてください。
| タグ | クラスター |
|---|---|
| Hub cluster | ハブクラスタ (ACMがインストールされているクラスタ)で実行すべき手順。 |
| Managed cluster | 各管理対象クラスター (プライマリおよびセカンダリの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. ハブクラスタを作成する
Hub cluster
これは、プライマリおよびセカンダリの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.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes -
出力からクラスタIDを確認してください。 後の手順で必要になります。
ステップ 2. ハブクラスタの信頼済みプロファイルを作成する
Hub cluster
-
信頼済みプロファイルを作成します。
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 -
クラスタ内に信頼済みプロファイルのシークレットが作成されていることを確認してください。 このコマンドの実行には、最大10分ほどかかる場合があります。 ACMアドオンのインストールを進める前に、秘密鍵が表示されるまでお待ちください。 秘密鍵が作成される前に操作を進めると、ACM アドオンのインストールに失敗します。
oc get secrets -n kube-system | grep ibm-cloud-credentials -
ODFバージョン 4.21 以降を使用している場合は、ハブクラスタに OpenShift GitOps オペレーターをインストールしてください。
-
ハブクラスタの OpenShift Webコンソールの Coreプラットフォームビューで、「 Ecosystem 」>「 Software Catalog 」に移動し、 Red Hat OpenShift GitOps。
-
この Red Hat OpenShift GitOps タイルをクリックしてください。
-
[ オペレーターのインストール ] ページで、インストールする更新チャネルと「 GitOps 」のバージョンを選択します。
-
インストール済みのネームスペースを選択してください。 デフォルトのインストールネームスペースは
openshift-gitops-operatorです。GitOps のバージョン 1.10 以降では、デフォルトのネームスペースが
openshift-operatorsからopenshift-gitops-operatorに変更されました。 -
クラスタの監視を有効にするには、「 このネームスペースで、Operatorが推奨するクラスタ監視を有効にする 」チェックボックスを選択してください。
-
**「インストール」**をクリックします。 Red Hat OpenShift GitOps クラスタのすべてのネームスペースにインストールされています。
-
「 Red Hat OpenShift 」 GitOps オペレータが [Operators] > [Installed Operators] に一覧表示されており、[ Status ] が [Succeeded] となっていることを確認してください。
インストールが完了すると、 OpenShift GitOps によって、
openshift-gitopsネームスペース内にすぐに使用可能な Argo CD インスタンスが自動的に設定され、コンソールのツールバーに Argo CD のアイコンが表示されます。 -
ステップ 3. マネージド・クラスタを作成する
Managed cluster
-
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.31_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.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
ステップ 4. ハブ・クラスタにACMアドオンをインストールする
Hub cluster
CLI を使用して、ハブクラスターに ACM アドオンをインストールします。
-
ACMアドオンのデフォルト版を探してください。
ibmcloud oc cluster addon versions -
ACMのアドオンオプションを確認してください。 コマンドでは、前の手順で確認したデフォルトのバージョンを指定してください。 アドオンをインストールする際に含めたいオプションがあれば、それをメモしておいてください。
ibmcloud oc cluster addon options --addon acm --version DEFAULT_VERSION -
コマンドを実行して、アドオンを有効にしてください。 必ず「
billingPlan」および「isLicenseAccepted」パラメータを指定してください。ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'billingPlan=PLAN' --param 'isLicenseAccepted=BOOLEAN'コマンドのパラメータ。 各パラメータタイプの例については、以下のコマンド例を参照してください。
--cluster- 必須。 ACM アドオンをインストールするハブクラスタの ID。
--param 'billingPlan='- 必須。 ACMで選択したい課金プラン。 ACMの Kubernetes プランでは、「
KUBERNETES」を指定してください。 --param 'isLicenseAccepted='- 必須。 選択した課金プランのライセンス契約に同意する場合は、これを「
true」に設定してください。 ライセンスに同意しない限り、このアドオンは正常にインストールされません。 本ライセンスに同意することにより、お客様は適用される利用規約に同意し、選択したプランに含まれるサービス内容を理解したことを認めるものとします。
「 Kubernetes 」向けのACM 課金プランを使用してACMアドオンをインストールするコマンド例。
ibmcloud oc cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true' -
アドオンがインストールされたことを確認してください。 アドオンが以下の出力に表示されるまで、数分かかる場合があります。
- ハブクラスタ上で、
acmhubリソースが作成されていることを確認してください。
oc get acmhub ``` 出力例。 ```sh {: screen} NAME AGE acm-auto 1h ``` 1. ハブクラスタ上で、 `acmhub` のステータスを確認してください。 ```sh {: pre} oc describe acmhub ``` 出力例。 ```sh {: screen} Status Message: ACM installed successfully ``` - ハブクラスタ上で、
ステップ 5. 管理対象クラスターをACMにインポートする
Hub cluster Managed cluster
両方のマネージドクラスタをACMにインポートし、ハブクラスタがそれらを管理できるようにします。
-
ハブクラスタの「 OpenShift 」Webコンソールを開きます。
-
「 フリート管理 」の画面で、「 クラスターをインポート 」をクリックします。
-
最初の管理対象クラスター の名前を入力し、該当する場合はクラスターセットを選択し、さらに該当する場合は追加のラベルを入力してください。
-
「 インポート」モードでは、「 インポートコマンドを手動で実行する 」を選択し、「 次へ 」をクリックします。
-
必要に応じて自動化テンプレートを選択し、「 次へ 」をクリックします。
-
詳細を確認し、「 コマンドを生成 」をクリックしてください。 表示されているコマンドをコピーしてください。
-
最初のマネージドクラスタにログインし、そのクラスタ用に構成された
kubectlを使用して、コピーしたコマンドを実行します。 -
2~7の手順を、2つ目の管理対象クラスタについても繰り返します。
-
フリート管理の観点から、続行する前に、管理対象のクラスタが両方とも一覧に表示され、「 Ready 」ステータスになっていることを確認してください。
ステップ 6. サブマリーナーアドオンの設定
Hub cluster Managed cluster
Submariner アドオンを設定し、2つの管理対象クラスター間でクラスター間ネットワークを確立します。 ご利用のインフラストラクチャおよびクラスタの種類に応じて、以下のオプションから1つを選択してください:
- 選択肢 1: Transit Gateway (推奨) — 仮想サーバーインスタンス(VSI)およびベアメタル・ワーカーノードを備えた、 Red Hat OpenShift on IBM Cloud および Red Hat OpenShift Virtualization Service(ROVS)のクラスターの両方でサポートされています。
- オプション 2: ネットワーク負荷分散 (NLB) — VSI ワーカーノードのみを含む Red Hat OpenShift on IBM Cloud クラスターでのみサポートされています。
オプション 1: IBM Cloud Transit Gateway を使用して VPC を接続する(推奨)
Hub cluster
高性能なVPC間ダイレクト通信には、 IBM Cloud Transit Gateway をご利用ください。 このオプションは、VSI およびベアメタルインフラストラクチャ上の、 Red Hat OpenShift on IBM Cloud および Red Hat OpenShift 仮想化サービスクラスタをサポートしています。
-
管理対象クラスターで使用されているVPCを特定します:
- 以下の場合 Red Hat OpenShift on IBM Cloud: IBM Cloud コンソールにアクセスし、[ナビゲーションメニュー] > [コンテナ ] > [クラスター ] の順に選択し、対象のクラスターを選択して、 VPC を確認してください。
- Red Hat OpenShift 仮想化サービスの場合: IBM Cloud コンソール > ナビゲーションメニュー > インフラストラクチャ > OpenShift 仮想化 > クラスターを選択 > VPC を確認してください。
-
Transit Gateway を作成し、管理対象クラスターのVPC両方に接続を追加します:
- IBM Cloud コンソール で、 インフラ > ネットワーク > Transit Gateway の順にアクセスします。
- 「作成」 をクリックします。
- Transit Gateway 名前 にアクセスし、 リソースグループ を選択してください。
- ルーティングを選択してください:
- ローカルルーティング :管理対象のクラスターが両方とも同じリージョン内にある場合は、このオプションを選択してください。
- グローバルルーティング :管理対象クラスターが複数のリージョンにまたがってデプロイされている場合は、このオプションを選択してください。
- [ 接続] で、両方の VPC に対する接続を追加します:
- 接続 1 :ネットワーク接続用の VPC を選択し、クラスター 1 のリージョンを選択してから、クラスター 1 用の VPC を選択します。
- 接続 2 :ネットワーク接続用の VPC を選択し、クラスタ 2 のリージョンを選択してから、クラスタ 2 の VPC を選択します。
- 「作成」 をクリックします。
-
ハブクラスター上に ClusterSet リソースを作成し、管理対象クラスターを追加します:
- ハブ・クラスタのACMコンソールで、「 Fleet Management 」>「 Infrastructure 」>「 Clusters 」> ClusterSet。
- [クラスタセットの作成] をクリックし、クラスタセットの名前(例:
<CLUSTERSET>)を入力します。 - [ クラスタの割り当てを管理 ] をクリックし、管理対象のクラスタを両方ともクラスタセットに追加します。
-
ハブクラスタ上で、Submariner Brokerの設定ファイル
submariner-broker.yaml`` を作成します。apiVersion: submariner.io/v1alpha1 kind: Broker metadata: name: submariner-broker namespace: <CLUSTERSET>-broker labels: cluster.open-cluster-management.io/backup: submariner spec: globalnetEnabled: true管理対象クラスタ間でネットワーク(ポッドおよびサービスのCIDR)が重複している場合は、
globalnetEnabled: trueを設定してください。 管理対象クラスター間でCIDRが重複していない場合は、globalnetEnabled: falseに設定してください。 -
ブローカーの設定をハブクラスターに適用します。
oc apply -f submariner-broker.yaml -
ハブクラスター上で、マネージドクラスター 1 用の「
SubmarinerConfig」カスタムリソースファイル(SubmarinerConfig-mc1.yaml)を作成します。apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <MANAGED_CLUSTER1> spec: cableDriver: libreswan forceUDPEncaps: true gatewayConfig: gateways: 2 NATTEnable: false -
ハブクラスタ上で、マネージドクラスタ 2 用の
SubmarinerConfigカスタムリソースファイル(SubmarinerConfig-mc2.yaml)を作成します。apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <MANAGED_CLUSTER2> spec: cableDriver: libreswan forceUDPEncaps: true gatewayConfig: gateways: 2 NATTEnable: false -
SubmarinerConfigのリソースを両方とも、ハブクラスタに適用してください。oc apply -f SubmarinerConfig-mc1.yaml oc apply -f SubmarinerConfig-mc2.yaml -
ハブクラスター上で、マネージドクラスター 1 用の「
ManagedClusterAddOn」カスタムリソースファイル(ManagedClusterAddOn-mc1.yaml)を作成します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: submariner namespace: <MANAGED_CLUSTER1> spec: installNamespace: submariner-operator -
ハブクラスタ上で、マネージドクラスタ 2 用の
ManagedClusterAddOnカスタムリソースファイル(ManagedClusterAddOn-mc2.yaml)を作成します。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: submariner namespace: <MANAGED_CLUSTER2> spec: installNamespace: submariner-operator -
ManagedClusterAddOnのリソースを両方とも、ハブクラスタに適用してください。oc apply -f ManagedClusterAddOn-mc1.yaml oc apply -f ManagedClusterAddOn-mc2.yaml -
ACMコンソールで、Submarinerアドオンのステータスが「正常」と表示されていることを確認してください。
- 「 フリート管理 」>「 インフラストラクチャ 」>「 クラスター 」> ClusterSet。
- クラスターセットを選択し、「 Submariner アドオン 」をクリックしてください。
- 「 接続ステータス 」が緑色のチェックマークとともに「 正常 」と表示されていることを確認してください。
-
(任意)
subctlCLI を使用して、Submariner の接続性および診断テストをさらに実行します:- ローカルシステムに
subctlCLIツールをインストールします:
curl -Ls https://get.submariner.io | bash export PATH=$PATH:~/.local/bin echo export PATH=\$PATH:~/.local/bin >> ~/.profile- 管理対象クラスタ 1 におけるゲートウェイおよびルートエージェントの接続を確認してください:
subctl diagnose connections --kubeconfig ./<MANAGED_CLUSTER1_KUBECONFIG>.yaml- 管理対象クラスタ 2 におけるゲートウェイおよびルートエージェントの接続状況を確認してください:
subctl diagnose connections --kubeconfig ./<MANAGED_CLUSTER2_KUBECONFIG>.yaml- クラスタ間でエンドツーエンドの接続性テストスイートを実行します:
subctl verify --context <MANAGED_CLUSTER1_CONTEXT> --tocontext <MANAGED_CLUSTER2_CONTEXT> --only connectivity --verbose --image-override=submariner-nettest=quay.io/submariner/nettest:0.24.1 - ローカルシステムに
オプション 2: ネットワーク負荷分散装置を使用して VPC を接続する
Hub cluster
ネットワーク・ロード・バランサーを使用して、ACMコンソールからSubmarinerアドオンをインストールおよび設定するには、以下の手順に従ってください。 このオプションは、VSI ワーカーノードのみを含む Red Hat OpenShift on IBM Cloud クラスターでのみサポートされています。 詳細については、『 Red Hat 』のドキュメントにある「 コンソールを使用した Submariner のデプロイ 」を参照してください。
- ハブクラスタ上のACMコンソールに移動します。 [「 フリート管理 」>「 クラスター 」>「 クラスターセット」 ] をクリックします。
- [ クラスタセットの作成 ] をクリックします。 プロンプトに従って、2つの管理対象クラスタをクラスタセットに追加します。
- クラスタセットにSubmarinerアドオンをインストールするオプションをクリックします。
- アドオンインストールの対象クラスタとして管理クラスタを選択します。
- 両方のクラスタの設定を確認する際は、以下の設定を図のように変更し、それ以外はデフォルトのままにしてください:
globalnetEnabled: true(チェック済み)gateways: 2NATTEnable: false(チェック解除)cableDriver: vxlan
- **「インストール」**をクリックします。
- 「Submariner」アドオンのステータスが「正常」(緑色のチェックマーク)と表示されるまでお待ちください。 これには最大20分ほどかかる場合があります。
手順 7. OpenShift Data Foundation のインストールと設定
Managed cluster
2つの管理対象クラスタにODFをインストールして設定します。 プライマリおよびセカンダリの管理対象クラスタの両方でこれらの手順を完了していることを確認してください。
このセクションで oc コマンドを実行する前に、コンテキストが、設定対象のマネージドクラスタに設定されていることを確認してください。 ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin を実行してコンテキストを切り替え、その後、 oc config current-context で確認してください。
-
管理対象のクラスターごとに、 IBM Cloud コンソールから「 OpenShift Data Foundation」アドオンをインストールしてください。
- クラスタの 「概要」 ページに移動し、「 アドオン 」セクションまで下にスクロールします。
- 「 OpenShift Data Foundation 」の下で、「 インストール 」をクリックします。
- 「 NooBaa マルチクラウド・オブジェクト・ゲートウェイのデプロイ 」のチェックボックスにチェックを入れます。
- もう一度「 インストール 」をクリックして確定してください。
- ODF アドオンのステータスが「 有効化中 」から「 通常 」(緑色のチェックマーク)に変わるまで待ってから、次の手順に進んでください。
-
ODFが正常にインストールされたことを確認してください。 出力で、ステータスが
Readyと表示されていることを確認する。UI上の「 正常 」ステータスは、アドオンが展開されたことを示していますが、ODFオペレーターがリソースの初期化と登録を完了するには、まだ数分かかる場合があります。
oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
各管理対象クラスタにおいて、以下の手順を実行する必要があります。 ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin を使用してコンテキストを最初のマネージドクラスターに切り替え、このセクションの最後まですべての手順を完了してから、2番目のマネージドクラスターに切り替えて、同じ手順を繰り返してください。
-
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}}}}'出力例。
storagecluster.ocs.openshift.io/ocs-storagecluster patched -
サービス輸出を確認する。 出力に表示されるまで数分かかるかもしれない。
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 -
ocs-provider-serverのサービスエクスポートを作成します。oc apply -f - <<EOF apiVersion: multicluster.x-k8s.io/v1alpha1 kind: ServiceExport metadata: name: ocs-provider-server namespace: openshift-storage EOF出力例。
serviceexport.multicluster.x-k8s.io/ocs-provider-server created -
コマンドを実行して
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.ocs.openshift.io/ocs-storagecluster annotated -
storageClusterリソースの準備ができていることを確認する。oc get storagecluster -n openshift-storage出力例。
NAME PHASE ocs-storagecluster Ready
ステップ 8. 地域災害復旧ポリシーの設定
Hub cluster
ハブ・クラスタに ODF Multicluster Orchestrator をインストールし、2 つの管理対象クラスタ間でミラーリングを有効にするディザスタリカバリ(DR)ポリシーを作成します。
-
ハブクラスタにODF Multicluster Orchestratorをインストールします。
- まだインストールしていない場合は、ハブクラスタに OpenShift の GitOps オペレーターをインストールしてください。 インストール手順については、 の「ステップ 2」の最後をご覧ください。 ハブクラスタ「 」の信頼済みプロファイルを作成します。
- ハブ・クラスタの OpenShift Webコンソールで、 Coreプラットフォームのビューを表示し、「 Ecosystem 」>「 Software Catalog 」の順に選択して、「 ODF Multicluster Orchestrator 」を検索します。
- 「 ODF Multicluster Orchestrator 」タイルをクリックします。 前のセクションで管理対象クラスターにインストールした ODF バージョンと同じバージョン番号を必ず選択してください。 その他のデフォルト設定はすべてそのままにし、「 インストール 」をクリックしてください。
- オペレーターリソースが「
openshift-operators」プロジェクトにインストールされ、すべてのネームスペースから利用可能であることを確認してください。 もう一度「 インストール 」をクリックして確定してください。
ODF Multicluster Orchestrator は、依存関係として、ハブクラスタに OpenShift のDRハブオペレーターもインストールします。
-
オペレータポッドが動作していることを確認して、インストールを確認します。 このコマンドを実行する前に、CLIのコンテキストがハブクラスターに設定されていることを確認してください。
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 -
ハブクラスター上で、同期間隔を5分に設定したDRポリシーを作成し、パラメータに各管理対象クラスターを指定してください。 これにより、管理対象クラスターの両方に NooBaa オブジェクトバケットが作成され、ボリュームのレプリケーションのためにODF Cephブロックプールのミラーリングが有効になります。
-
ハブクラスタの OpenShift Webコンソールで、 フリート管理の画面から、「 Data Services 」>「 Disaster recovery 」>「 Policies 」> 「Create DRPolicy 」の順に選択します。
-
以下のパラメータを含むDRポリシーを作成する。
- 接続済みのクラスター:PRIMARY_MANAGED_CLUSTER_NAME、SECONDARY_MANAGED_CLUSTER_NAME
- レプリケーションポリシー:非同期
- 複製間隔: 5m
- 該当する場合は、[ 詳細設定 ] の下にある [ 復元およびクローン化された PersistentVolumeClaims の災害復旧サポートを有効にする(Data Foundationのみ)] を選択してください。
Red Hat このオプションは、検出されたアプリケーションおよび、クローン化または復元されたRBDボリュームが積極的にサポートされている環境でのみ使用すべきであると明示されています。
-
-
ハブ・クラスター で、以下のコマンドを実行し、DRポリシーが作成され、管理対象のクラスターに適用されたことを確認してください。 これらのコマンドを実行する前に、CLIのコンテキストがハブクラスターに設定されていることを確認してください。
ibmcloud oc cluster config --cluster HUB_CLUSTER_NAME --adminoc get drpolicy DRPOLICY_NAME -o jsonpath='{.status.conditions[].reason}{"\n"}'出力例。
Succeededoc get drclusters出力例。
NAME AGE managed-cluster1 4m42s managed-cluster2 4m42s -
各管理対象クラスター において、DRポリシーが適用され、正常な状態にあることを確認してください。 これらのコマンドを実行する前に、各管理対象クラスターのCLIコンテキストに切り替えてください。
ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME --adminoc 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 3d12hoc 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、これらのオペレーターを管理する責任はない。
お客様は、更新、監視、回復、再インストールを含むがこれに限定されない、これらのオペレーターの管理に責任を負うものとする。
| 演算子 | 説明 | 詳細情報 |
|---|---|---|
| OpenShift データ保護API ( OADP ) オペレーター |
|
データ保護のための 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 を参照してください。