障害時リカバリの構成

このソリューション・プレイブックに付属のスクリプトを使用して、プライマリ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コーディネータとして使用することをお薦めします。その他のオプションでは、提供されるスクリプトをカスタマイズする必要があります。
my_ns namespaceのリストア時に、バックアップに含まれる名前のないリソースをセカンダリに適用する場合は、maak8sapply: my_nsラベルを使用します。

クラスタのルート(つまり、正確なネームスペースの一部ではない)に存在するアーティファクトの場合、スクリプトは、ネームスペース名を含む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ファイルには、詳細なリストア操作が含まれます。