Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerRuntime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。
Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。
VM/ベアメタルの Runtime Fabric の場合、バックアップと復元のプロセスには logforwarder や smtp などのアプライアンス関連のカスタムリソースのバックアップと復元が含まれます。バックアップと復元のプロセスには、アプリケーションによって生成された InfluxDB に保存されたメトリクスデータのバックアップは含まれません。
バックアップと復元のプロセスを使用して、VM/ベアメタル上の Runtime Fabric から自己管理型 Kubernetes 上の Runtime Fabric に移行することはできません。 |
バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。
Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。
VM/ベアメタルの Runtime Fabric をアップグレードする。場合によっては、クラスターをバックアップし、新しい Runtime Fabric バージョンを使用して同じクラスターに新しいクラスターをインストールしてから、そのクラスターにバックアップを復元する必要があることがあります。
スタンバイクラスターへのフェールオーバーを実行する。
バックアップと復元のプロセスを使用して 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 backup <path_to_backup_file>
このコマンドにより、現在のシステム状態のバックアップが <path_to_backup_file>
に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: /opt/anypoint/runtimefabric/backup.tar.gz
)。
VM/ベアメタルの Runtime Fabric の場合、rtfctl
バイナリは /opt/anypoint/runtimefabric/
ディレクトリにあります。クラスター内のコントローラーノードで特権ユーザーとしてバックアップコマンドを実行していることを確認します。後で復元するためにバックアップを使用するには、バックアップファイルを Runtime Fabric に含まれていない別のマシン上のセキュアなストレージにコピーします。
たとえば、次のコマンドでは scp
を使用してバックアップを別のドライブにコピーします。
scp your_username@remotehost:/opt/anypoint/runtimefabric/backup.tar.gz /backup-path/to-restore.tar.gz
自己管理型 Kubernetes の Runtime Fabric の場合、rtfctl
バイナリが現在のディレクトリに存在し、ユーザーの $PATH
に kubectl
が存在することを確認します。さらに、Kubernetes (kubectl
) コンテキストが目的のバックアップクラスターに設定されていることを確認します。
クラスターを復元する前に、次の情報を確認してください。
|
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。
既存の Runtime Fabric クラスターを使用する。
バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。
Vm/ベアメタル上で Runtime Fabric アプライアンスを復元するには、Runtime Fabric アクティベーションデータを指定せずに Runtime Fabric インストールスクリプトを実行します。インストールスクリプトを実行したら、復元プロセスを完了します。
自己管理型 Kubernetes 上の Runtime Fabric でクラスターを復元する場合は、rtfctl
インストールコマンドを実行せずにクラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。
クラスターを復元するための対象オプションを選択します。
クラスターに rftctl
がインストールされていることを確認します。
作成してあるバックアップファイルをコピーして、rtfctl
で使用できるようにします。
VM/ベアメタルの Runtime Fabric の場合、圧縮されたバックアップファイルを、復元する環境のコントローラーノードのディレクトリにコピーします。たとえば、このファイルは次のコマンドを使用して安全に転送できます。
scp /backup-path/to-restore.tar.gz your_username@remotehost:/opt/anypoint/runtimefabric/
Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。
kubectl scale --replicas=0 -n rtf deployment.apps/agent
バックアップからクラスターを復元します。
./rtfctl restore <path_to_backup_file>
+ このプロセスは、完了するまで数分かかる場合があります。
自己管理型 Kubernetes の Runtime Fabric の場合、rtfctl
バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。