ノート:
- このチュートリアルでは、Oracle Cloudへのアクセスが必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
- Oracle Cloud Infrastructureの資格証明、テナンシおよびコンパートメントの値の例を使用します。演習を完了するときに、これらの値をクラウド環境に固有の値に置き換えます。
OCI Full Stack Disaster RecoveryによるOCI Kubernetes Engine(ステートフル)のスイッチオーバーおよびフェイルオーバー計画の自動化
イントロダクション
Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)は、世界中のOracle Cloud Infrastructure(OCI)リージョン間のコンピュート、データベース、アプリケーションの移行をワンクリックで調整します。お客様は、既存のインフラストラクチャ、データベースまたはアプリケーションを再設計または再設計することなく、特別な管理サーバーや変換サーバーを必要とせずに、1つ以上のビジネス・システムをリカバリするために必要なステップを自動化できます。
Oracle Cloud Infrastructure Kubernetes Engine (OKE)は、コンテナ化されたワークロードの開発、導入、運用を大規模に簡素化するマネージドKubernetesサービスです。OKEを使用すると、基盤となるOCI Compute、ネットワーキングおよびストレージ・サービスを活用するKubernetesクラスタを迅速に作成、管理および使用できます。
デプロイメント・アーキテクチャ
目的
このチュートリアルでは、次のタスクについて説明します。
- タスク1: OKEおよびOCI Full Stack Disaster Recoveryの動的グループおよびポリシーの作成
- タスク2: プライマリDR保護グループへのプライマリOKEクラスタの追加
- タスク3: プライマリDR保護グループへのボリューム・グループの追加
- タスク4: スタンバイDR保護グループへのスタンバイOKEクラスタの追加
- タスク5: 開始ドリル計画の作成
- タスク6: 開始ドリル計画の実行
- タスク7: スタンバイOKEクラスタで実行されているアプリケーションの確認
- タスク8: ストップ・ドリル計画の作成
- タスク9: ストップ・ドリル計画の実行
- タスク10: スタンバイOKEクラスタでのクリーンアップの確認
ノート:このチュートリアルでは、プライマリ・リージョンはフランクフルト、スタンバイ・リージョンはアムステルダムです。
前提条件
-
このチュートリアルでは、DR保護グループ(DRPG)がすでに存在し、両方のリージョンに既存のDR計画があることを前提としています。
-
このチュートリアルでは、リーダーに管理者権限があり、OCI Full Stack DRに必要なOracle Cloud Infrastructure Identity and Access Management (OCI IAM)ポリシーがすでに整っていることを前提としています。詳細は、フル・スタックDRを使用するためのIdentity and Access Management (IAM)ポリシーの構成およびフル・スタック・ディザスタ・リカバリのポリシーを参照してください。
-
このチュートリアルでは、リーダーにプライマリ・リージョンにデプロイされたOKEクラスタとスタンバイ・リージョンのピア・クラスタがあることを前提としています。詳細は、クラスタの作成を参照してください。
-
このチュートリアルでは、リーダーがプライマリOKEクラスタにデプロイされた切断(モック)されたMuShopアプリケーションを前提としています。詳細は、「MuShopのデプロイ」を参照してください。
-
OKEクラスタによって生成されたブロック・ボリュームは、(
vg_oke_mushop
)ボリューム・グループにすでに追加されています。クロス・リージョン・レプリカを使用してボリューム・グループを作成する必要があります。詳細は、ボリューム・グループの作成を参照してください。 -
プライマリ・リージョンおよびスタンバイ・リージョンにOCIオブジェクト・ストレージ・バケットを作成し、OKEバックアップを格納します。詳細は、オブジェクト・ストレージを参照してください。
タスク1: OKEおよびOCI Full Stack DRの動的グループおよびポリシーの作成
これらのポリシーにより、OCI Full Stack DRサービスはOCI Object Storageバケットにアクセスして構成バックアップをアップロードできます。OKEクラスタからのOCIオブジェクト・ストレージ・バケット・アクセスのポリシーは、クラスタ・タイプによって異なります。
-
管理対象ノード・プールの動的グループおよびポリシーを作成します。
-
<cluster1_dg>
という名前の動的グループを作成します。All {instance.compartment.id = '<compartment_ocid>'}
-
次のポリシーを作成します。
Allow dynamic-group cluster1_dg to manage object-family in compartment <compartment> Allow dynamic-group cluster1_dg to manage cluster-family in compartment <compartment>
-
-
仮想ノード・プールに対して次のポリシーを作成します。
Allow any-user to manage objects in tenancy where all { request.principal.type = 'workload', request.principal.namespace = 'brie', request.principal.service_account = 'brie-reader', request.principal.cluster_id = '<Cluster_OCID>'} Allow any-user to manage objects in tenancy where all { request.principal.type = 'workload', request.principal.namespace = 'brie', request.principal.service_account = 'brie-creator', request.principal.cluster_id = '<Cluster_OCID>'}
これらのポリシーは、サービス・アカウント
brie-reader
またはbrie-creator
を使用してbrieネームスペースで実行されているポッドに、OCIオブジェクト・ストレージ・バケットの読取りおよび書込みを行います。 -
コンテナ・インスタンスの動的グループおよびポリシーを作成します。これらのポリシーにより、OCI Full Stack DRサービスによって作成されたランタイム・コンテナ・インスタンスは、OKEクラスタおよびOCI Object Storageバケットにアクセスできます。
-
<bastion1_dg>
という名前の動的グループを作成します。All {resource.type='computecontainerinstance'}
-
次のポリシーを作成します。
Allow dynamic-group bastion1_dg to manage object-family in compartment <compartment> Allow dynamic-group bastion1_dg to manage cluster-family in compartment <compartment>
-
-
ジャンプ・ホストの動的グループおよびポリシーを作成します。
ジャンプ・ホストを使用している場合、このポリシーにより、OCI Full Stack DRはOKEクラスタおよびOCI Objectストレージ・バケットにアクセスできます。ジャンプ・ホストとクラスタが同じコンパートメントにある場合、OCIオブジェクト・ストレージ・バケットへのアクセスを提供する新しい動的グループおよびポリシーを作成するステップを回避できます。
-
<bastion1_dg>
という名前の動的グループを作成します。All {instance.compartment.id = '<compartment_ocid>'}
-
次のポリシーを作成します。
Allow dynamic-group bastion1_dg to manage cluster-family in compartment <compartment>Allow dynamic-group bastion1_dg to manage cluster in compartment <compartment>
-
ノート:
dynamic-group
の前にidentity_domain_name
を含めないと、グループがデフォルト・アイデンティティ・ドメインに属しているかのようにポリシー・ステートメントが評価されます。詳細は、ポリシーの仕組みを参照してください。
タスク2: プライマリDR保護グループへのプライマリOKEクラスタの追加
-
プライマリDRPG (
DRPG_MUSHOP_FRA
)で、「メンバー」を選択し、「メンバーの追加」をクリックします。 -
「リソース・タイプ」として「OKEクラスタ」を選択します。
-
次の必須情報を入力します。
- OKEクラスタ: OKEクラスタを入力します。
- バックアップ:バックアップ情報を入力します。
- バックアップ・バケット:バケットを選択します。
- 「バックアップ・スケジュールの指定」を選択します。
- スケジュール・タイプ:スケジュール・タイプを入力します。
- 開始時間:開始時間をUTCで入力します。
- 間隔:間隔を日数で入力します。
- 保持するバックアップの最大数(オプション):バックアップの最大数を入力します。
- 「イメージ・レプリケーション」を選択します。
- イメージ・レプリケーション・シークレット(オプション):イメージを選択します。
- ネームスペース(オプション):ネームスペースを入力します。
- ピアOKEクラスタ:ピアOKEクラスタを選択します。
-
「I understand that I must refresh and verify all the existing plans」を選択し、「追加」をクリックします。
タスク3: プライマリDR保護グループへのボリューム・グループの追加
-
プライマリDRPG (
DRPG_MUSHOP_FRA
)で、「メンバー」を選択し、「メンバーの追加」をクリックします。 -
「リソース・タイプ」として「ボリューム・グループ」を選択します。
-
次の必須情報を入力します。
- ボリューム・グループ:ボリューム・グループを選択します。
-
「I understand that I must refresh and verify all the existing plans」を選択し、「追加」をクリックします。
タスク4: スタンバイDR保護グループへのスタンバイOKEクラスタの追加
-
スタンバイDRPG (
DRPG_MUSHOP_AMS
)で、「メンバー」を選択し、「メンバーの追加」をクリックします。 -
「リソース・タイプ」として「OKEクラスタ」を選択します。
-
次の必須情報を入力します。
- OKEクラスタ: OKEクラスタを入力します。
- バックアップ:バックアップ情報を入力します。
- バックアップ・バケット:バケットを選択します。
- ピアOKEクラスタ:ピアOKEクラスタを選択します。
-
「I understand that I must refresh and verify all the existing plans」を選択し、「追加」をクリックします。
タスク5: ドリル・プランの開始の作成
-
スタンバイDRPG (
DRPG_MUSHOP_AMS
)で、「プラン」を選択し、「プランの作成」をクリックします。 -
プランの「名前」を入力し、「プラン・タイプ」として「ドリルの開始」を選択し、「作成」をクリックします。
数分後、プランには「アクティブ」状態が表示されます。
-
作成したプランを選択してコンテンツを表示します。
タスク6: ドリルの開始計画の実行
-
タスク5で作成したプランを選択します。
-
「事前チェックの有効化」を選択し、「プランの実行」をクリックします。
数分後、すべてのグループに「成功」状態が表示されます。
タスク7: スタンバイOKEクラスタで実行されているアプリケーションの確認
スタンバイOKEクラスタに接続し、アプリケーションが実行されているかどうかを確認します。MuShopアプリケーションの次のコマンドを実行します。
kubectel get all -n mushop
タスク8: ドリル・プランの停止の作成
-
スタンバイDRPG (
DRPG_MUSHOP_AMS
)で、「プラン」を選択し、「プランの作成」をクリックします。 -
プランの「名前」を入力し、「プラン・タイプ」として「ドリルの開始」を選択し、「作成」をクリックします。
数分後、プランには「アクティブ」状態が表示されます。
タスク9: ドリルの停止計画の実行
-
タスク8で作成したプランを選択します。
-
「事前チェックの有効化」を選択し、「プランの実行」をクリックします。
数分後、すべてのグループに Succuss状態が表示されます。
タスク10: スタンバイOKEクラスタでのクリーンアップの確認
スタンバイOKEクラスタに接続し、次のコマンドを使用してネームスペースのリストを確認します。
kubectl get namespaces
次のステップ
ドリル計画を作成して実行したら、スイッチオーバー計画とフェイルオーバー計画を作成します。
DR計画の準備を確実にするために、通常の日常業務に組み込む必要がある2つのベスト・プラクティスがあります。
- 事前チェックの定期的な実行。
- DRドリルの定期的な定期的な実行。
スタンバイDR保護グループ内のすべてのDR計画の週次事前チェックをスケジュールすることを検討してください。事前チェックはいつでも実行でき、本番ワークロードには影響しません。これにより、DR計画の整合性の確保、欠落しているメンバー・リソースの捕捉、ネットワークの欠落、ユーザー定義ステップによってコールされる予期されるスクリプトの検出不能などに役立ちます。
ディザスタ・リカバリの準備状況を検証するもう1つの非常に重要な方法は、定期的なDRドリルを月または四半期に1回スケジュールすることです。DRドリルは本番ワークロードにも影響しませんが、1回のボタンをクリックするだけで、スタンバイ・リージョンのロード・バランサのコンピュート、ストレージ、Oracleデータベースおよびバックエンド・セットのリカバリを検証できます。詳細は、次の各トピックを参照してください:
関連リンク
承認
- 著者 - Raphael Teixeira (Full Stack DRエンジニアリングの技術スタッフのプリンシパル・メンバー)
その他の学習リソース
docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。
製品ドキュメントについては、Oracle Help Centerを参照してください。
Automate Switchover and Failover Plans for OCI Kubernetes Engine (Stateful) with OCI Full Stack Disaster Recovery
G26599-01
February 2025
Copyright ©2025, Oracle and/or its affiliates.