原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/customer-managed-vm-maintenance-with-reboot-migration
クラウドプロバイダーに基盤となるインフラストラクチャの管理を任せることが出来る点が、クラウドへワークロードを移行する主要なメリットの一つです。これのおかげで、特定のビジネスソリューションに対してより多くのリソースを注力できます。しかしながら、時としてメンテナンスが発生してクラウドリソースの利用ができなくなることがあります。そのため、スケジュール済みダウンタイムを把握しておくだけでなく、ビジネスニーズに従ってクラウド利用不可の状態に備えることが重要です。
Oracle Cloud InfrastructureのComputeサービスの場合、Customer Managed VM Maintenanceを使って、こうしたまれなハードウェアメンテナンスイベントに関連付けられたダウンタイムをコントロールできます。お使いのVMをサポートする基盤システムに対するメンテナンスイベントが計画されると、スケジュール済みメンテナンスイベントの前にいつでもインスタンスを再起動することで別のクラウドインフラストラクチャにお使いのVMを移行できます。
同じ情報はOracle Cloud Infrastructureのコンソールからもご覧いただけます。スケジュール済みのメンテナンスの影響を受けるすべてのVMインスタンスにはMaintenance Rebootフラグのマークが付きます。
この情報を無視すれば、インスタンスは再起動を含む予定されたメンテナンスプロセスを踏みます。しかし、スケジュール済みメンテナンスの前に、より都合のよい時間にインスタンスを再起動してサービスの可用性を向上することができます。コンソール、API、CLIから再起動を実行できます。インスタンス再起動時にクラウドの別のインフラストラクチャでインスタンスを実行すると、メンテナンスフラグが消えます。
コンソールには一度に1個のリージョンのリソースが表示されますので、各リージョンで個別にクエリを実行する必要があります。
APIもしくはCLIの場合、timeMaintenanceRebootDueプロパティを使ってフラグ付きインスタンスをフィルタリングできます。以下のスクリプトを使って、テナントの有効な全リージョンにわたり、全ての対象インスタンスをリストアップできます。
将来は、この機能が全てのVMシェイプ、non-iSCSIブロックボリュームやセカンダリVNICがアタッチされているインスタンスをサポートすることになるでしょう。
https://blogs.oracle.com/cloud-infrastructure/customer-managed-vm-maintenance-with-reboot-migration
クラウドプロバイダーに基盤となるインフラストラクチャの管理を任せることが出来る点が、クラウドへワークロードを移行する主要なメリットの一つです。これのおかげで、特定のビジネスソリューションに対してより多くのリソースを注力できます。しかしながら、時としてメンテナンスが発生してクラウドリソースの利用ができなくなることがあります。そのため、スケジュール済みダウンタイムを把握しておくだけでなく、ビジネスニーズに従ってクラウド利用不可の状態に備えることが重要です。
Oracle Cloud InfrastructureのComputeサービスの場合、Customer Managed VM Maintenanceを使って、こうしたまれなハードウェアメンテナンスイベントに関連付けられたダウンタイムをコントロールできます。お使いのVMをサポートする基盤システムに対するメンテナンスイベントが計画されると、スケジュール済みメンテナンスイベントの前にいつでもインスタンスを再起動することで別のクラウドインフラストラクチャにお使いのVMを移行できます。
How It Works
実際のメンテナンスイベントがスケジュールされるおよそ2週間前に、Oracle Cloud Infrastructureからメール通知を受け取ります。このメールには、日付と停止時間、このイベントによって影響を受けるインスタンスのリスト、そしてメンテナンス日時までの任意のタイミングで異なるインフラストラクチャにインスタンスを移行する方法が明示されています。この通知メールが正しい受信箱に届くように、Oracle Cloud Infrastructureのアカウントをメールアドレスにしておくとよいでしょう。同じ情報はOracle Cloud Infrastructureのコンソールからもご覧いただけます。スケジュール済みのメンテナンスの影響を受けるすべてのVMインスタンスにはMaintenance Rebootフラグのマークが付きます。
この情報を無視すれば、インスタンスは再起動を含む予定されたメンテナンスプロセスを踏みます。しかし、スケジュール済みメンテナンスの前に、より都合のよい時間にインスタンスを再起動してサービスの可用性を向上することができます。コンソール、API、CLIから再起動を実行できます。インスタンス再起動時にクラウドの別のインフラストラクチャでインスタンスを実行すると、メンテナンスフラグが消えます。
Checking for Scheduled Maintenance
運用ポリシーの一環として、定期的にメンテナンス再起動が必要な全てのインスタンスを確認したい、と思うかもしれません。コンソールでは、Advanced Searchの以下の事前定義済みクエリを使うことができます。"Query for all instances which have an upcoming scheduled maintenance reboot"
コンソールには一度に1個のリージョンのリソースが表示されますので、各リージョンで個別にクエリを実行する必要があります。
APIもしくはCLIの場合、timeMaintenanceRebootDueプロパティを使ってフラグ付きインスタンスをフィルタリングできます。以下のスクリプトを使って、テナントの有効な全リージョンにわたり、全ての対象インスタンスをリストアップできます。
Instances flagged for reboot migrationこのスクリプトを日次実行すれば、緊急時であっても、フラグの付いたインスタンスへの対応に十分な時間を確保できるようになります。
https://github.com/radudobrinescu/oci-miscellaneous/blob/master/list_maintenance_instances.py
Considerations
この機能は現在、OracleのイメージもしくはカスタムイメージのLinux OSを実行するStandardVMシェイプに限定されています。non-iSCSIブロックボリュームをアタッチしていたりセカンダリVNICを持っていたりするインスタンスの場合、ブロックボリュームやセカンダリVNICをインスタンス再起動の前にデタッチしておく必要があります。再起動後、これらを再度アタッチして通常の運用を再開できます。将来は、この機能が全てのVMシェイプ、non-iSCSIブロックボリュームやセカンダリVNICがアタッチされているインスタンスをサポートすることになるでしょう。