障害時リカバリの構成

このソリューション・プレイブックで提供されるスクリプトを使用して、プライマリKubernetesクラスタにYAMLスナップショットを作成し、別の(セカンダリ)Kubernetesクラスタにリストアできます。スクリプトをダウンロードして使用してYAMLスナップショットを構成する前に、構成を計画し、要件を理解することが重要です。

ノート:

このソリューションは、制御計画およびワーカー・ノードを含む両方のKubernetesクラスタがすでに存在することを前提としています。

構成の計画

プライマリ・システムに基づいて、セカンダリ・システムのリソースと構成を計画します。スクリプトでは、両方のKubernetesクラスタがすでに存在している必要があります。コマンドを実行するには、Kubernetesコマンドライン・ツールkubectlを使用して両方のクラスタにアクセスできる必要があります。

ノート:

このソリューションは、制御計画およびワーカー・ノードを含む両方のKubernetesクラスタがすでに存在することを前提としています。このプレイブックで提供される推奨事項およびスクリプトでは、リソース、コントロール・プレーンまたはワーカー・ノード構成はチェックされません。

次の図は、構成時に、完全に異なるKubernetesクラスタでアーティファクト・スナップショットをリストアできることを示しています。

図kube-api-dr.pngの説明

構成を計画する場合は、Restoreの次の要件を完了します。

プライマリ内の必要なワーカー・ノードおよびリソースがセカンダリで使用可能であることを確認します。
これには、ポッドの共有ストレージ・マウント、ロード・バランサおよびデータベースが含まれます。また、リストアされるネームスペースによって使用される外部システムも含まれます。
スクリプトを実行する前に、関連するネームスペースで使用される必要な永続ボリュームを手動で作成します。

デフォルト・アクションです。スクリプトは、プライマリで使用される永続ボリューム要求を作成します。ただし、永続ボリュームは異なるネームスペースの異なる要求によって共有される可能性があるため、自動化スクリプトでは、extract-applyスクリプトを実行する前に、セカンダリ・クラスタに永続ボリュームを手動で作成する必要があります。

または、maak8DR-apply.envファイルのnons_artifacts_types変数にpvを追加できます(つまり、export nons_artifacts_types="crd clusterrole clusterrolebinding pvを使用します)。これにより、スクリプトは、セカンダリで永続ボリュームを作成するように指示されます。この2番目のケースでは、ほかの永続ボリューム要求と競合が発生する可能性があるかどうかを判断するのはユーザー次第です。
セカンダリ・クラスタに、レプリケートされるネームスペースで使用されるコンテナ・イメージへの適切なアクセス権があることを確認します。
- レプリケートするネームスペースに存在するコンテナ・レジストリへのアクセスに使用されるシークレットは、このプレイブックで提供されるスクリプトによってコピーされます。レジストリへの資格証明が他のネームスペースに格納されている場合は、セカンダリで手動で作成する必要があります。または、シークレットがYAMLスナップショットにも含まれるように、資格証明にmaak8sapply: my_ns (my_nsはリストアされるネームスペース)のラベルを付けることもできます。たとえば、
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- プライマリ・ワーカー・ノードに手動でロードされたイメージを使用している場合は、セカンダリ・ワーカー・ノードにも手動でロードする必要があります。
  
  ノート:
  指定したスクリプトは、レプリケートされるネームスペースで使用されているイメージをレポートします。
各クラスタのKube APIエンドポイントに対してkubectl操作を実行できる要塞ノードを介して、プライマリおよびセカンダリ・クラスタへのアクセスを提供します。
sshまたはscpを両方(プライマリとスタンバイ)に使用でき、DR同期を調整できる3番目のノードを使用できます。ただし、不要なホップおよびセッション・オーバーヘッドを回避するために、Oracleではプライマリ要塞をDRコーディネータとして使用することをお薦めします。その他のオプションでは、用意されているスクリプトをカスタマイズする必要があります。
maak8sapply: my_nsラベルは、my_ns namespaceのリストア時にバックアップに含まれる名前のないリソースをセカンダリに適用する場合に使用します。

クラスタのルートに存在するアーティファクト(つまり、正確なネームスペースの一部ではない)の場合、スクリプトは、ネームスペース名を含むnamespace:およびgroup:フィールド参照を検索します。バックアップに含まれるその他の名前のないリソースが必要な場合は、追加するラベルを付けることができます。

たとえば、domains.weblogic.oracleカスタム・リソース定義はどのネームスペースにも含まれていませんが、apply操作のラベル付けに含めるには、kubectl label crd domains.weblogic.oracle maak8sapply=opnsを使用できます。

構成

YAMLスナップショットの障害時リカバリを構成します。

すべてのYAMLスナップショットの障害時リカバリ・スクリプトを「コードのダウンロード」からダウンロードします。

ノート:
メイン・スクリプトでは他の補助スクリプトが使用されるため、すべてのスクリプトが同じパスにある必要があります。
maak8DR-apply.envスクリプトを編集し、セカンダリ・システムへのアクセスに必要なアドレスとSSHキーを更新します。
たとえば、
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
必要に応じて、exclude_listおよびnons_artifacts_typesの値をカスタマイズします。
- exclude_list: これは、すべてのカスタム・ネームスペースのバックアップを試行する場合でも、バックアップから除外する必要があるネームスペースのスペース区切りのリストです。これは、セカンダリに適用できないコントロール・プレーン関連のネームスペースのコピーを回避するためです。
- nons_artifacts_types: ルート・ツリーに属する(つまり、正確なネームスペースの一部ではない)が、スナップショットにも含める必要があるリストまたはアーティファクトです。フレームワークは、バックアップされるネームスペースへの参照を検索します。
通常、ファイルに指定されているデフォルト値を使用できます。
```
#List of namespaces that will be excluded from the backup
export exclude_list="kube-system kube-flannel kube-node-lease kube-public"
#Root artifacts that will be included
export nons_artifacts_types="crd clusterrole clusterrolebinding"
```
選択したネームスペースをレプリケートする引数として指定するmaak8DR-apply.shスクリプトを実行します。
- 引数を指定しない場合、スクリプトは、exclude_list変数で指定されたネームスペースを除くすべてのネームスペースをレプリケートします。
- ネームスペースの正確なリストを使用する場合は、他のネームスペースとの依存関係に基づいてそれらを順序付ける必要があります。
  
  つまり、ネームスペースsoansがネームスペースopnsのサービスに依存または使用する場合、opnsがリストの最初に表示される必要があります。たとえば、./maak8DR-apply.sh soans opnsのかわりに、次を実行します:
```
./maak8DR-apply.sh opns soans
```

検証

maak8DR-apply.shスクリプトを実行した後、プライマリ・クラスタに存在していたすべてのアーティファクトがセカンダリ・クラスタにレプリケートされていることを確認します。セカンダリ・クラスタを確認し、セカンダリ・サイトのポッドがエラーなしで実行されていることを確認します。

maak8DR-apply.shスクリプトを実行すると、フレームワークによってworking_dirディレクトリが/tmp/backup.dateとして作成されます。maak8-get-all-artifacts.shおよびmaak8-push-all-artifacts.shスクリプトを個別に実行すると、各ケースでコマンドラインの引数として作業ディレクトリが提供されます。

必要なポッドがプライマリの状態と一致するまで、セカンダリのステータスを確認します。
デフォルトでは、ポッドおよびデプロイメントはセカンダリ・リージョンで開始されます。復元の最後に、セカンダリクラスタのステータスが表示されます。一部のポッドは、RUNNING状態に達するのにさらに時間がかかる場合があります。
プライマリの$working_dir/date/backup-operations.logファイルで、抽出および適用操作で発生する可能性があるエラーを確認します。
抽出および適用操作で発生する可能性があるエラーについては、セカンダリ内の$working_dir/restore.logおよび$working_dir/date/restore-operations.logファイルを確認してください。
restore-operations.logファイルには、詳細なリストア操作が含まれます。