Runtime Fabric のバックアップと復元
Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。
Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。
バックアップと復元のプロセスを使用する状況
バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。
-
Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。
-
Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。
-
スタンバイクラスターへのフェールオーバーを実行する。
|
バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。 |
バックアップされるデータ
Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。
バックアップされる内容は次のとおりです。
-
コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細
-
クラスターレベルのセキュアプロパティ
-
デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ
-
現在の
rtfctl バージョン -
現在の Runtime Fabric エージェントバージョン
-
次のようなアプリケーション詳細:
-
ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定
-
Runtime Manager で設定されているアプリケーションプロパティ
-
-
次のような他の MuleSoft 設定のデータ
-
オブジェクトストア
-
Edge
-
Anypoint Monitoring と外部ログフォワーダー
-
バックアップされないデータ
-
アプリケーションの状態に関するデータ
-
Ops Center のデータ
-
コントロールプレーンのデータ
バックアップ実行後の変更内容が復元されない
バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には [applying (適用中)] として表示されます。
バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。
-
アプリケーションの作成
-
アプリケーションの削除
-
アプリケーション設定の更新
-
エージェントのアップグレード
バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。
バックアップを作成する
バックアップを作成するに、次の準備をしてください。
-
Runtime Fabric が正しくインストールおよび設定されていることを確認します。
-
rtfctl コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで rtfctl version を実行します。 -
rtfctl バイナリが現在のディレクトリに存在し、kubectl がユーザーの $PATH に存在することを確認します。さらに、Kubernetes (kubectl) コンテキストが目的のバックアップクラスターに設定されていることを確認します。
|
VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。 |
バックアップを作成するには、次のコマンドを実行します。
./rtfctl backup <path_to_backup_file>copy
このコマンドにより、現在のシステム状態のバックアップが <path_to_backup_file> に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: /opt/anypoint/runtimefabric/backup.tar.gz)。
復元を実行する
|
クラスターを復元する前に、次の情報を確認してください。
|
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。
-
既存の Runtime Fabric クラスターを使用する。
-
バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。
Runtime Fabric でクラスターを復元する場合は、rtfctl インストールコマンドを実行せずにクラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。
-
クラスターを復元するための対象オプションを選択します。
-
クラスターに
rftctl がインストールされていることを確認します。 -
作成してあるバックアップファイルをコピーして、
rtfctl で使用できるようにします。 -
Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。
kubectl scale --replicas=0 -n rtf deployment.apps/agentcopy -
バックアップからクラスターを復元します。
./rtfctl restore <path_to_backup_file>
+ このプロセスは、完了するまで数分かかる場合があります。
Runtime Fabric の場合、rtfctl バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。