Exadata VMライブ・マイグレーションによる計画停止時間の短縮

※本ページは、”Reducing Planned Downtime with Exadata VM Live Migration“の翻訳です。

（訳注）こちらの機能は現時点ではオンプレミスExadataで利用可能な機能です。

---

どのようなプラットフォームを運用していても、保守作業が終わることはないというのは現実です。

セキュリティ修正の適用、OSやアプリケーションソフトウェアの更新、ファームウェアの適用、ハードウェアコンポーネントの交換、そして時間の経過に伴う容量要件の変化――こうした作業はいずれも特別なことではありません。重要なのは、それらの作業がプラットフォーム上で稼働するアプリケーションやワークロードにどの程度の影響を与えるかという点です。

従来、Exadataインフラストラクチャの保守とアプリケーションの可用性は密接に結び付いていました。KVMホストをサービスから切り離す必要がある場合、その上で稼働するVMやアプリケーションワークロードは必然的に保守計画の対象となっていました。場合によってはアプリケーションを完全に停止する必要がありましたが、多くの場合は、アプリケーションの可用性や性能低下を考慮しながら、停止時間を綿密に計画し、業務部門の責任者と調整する必要がありました。

多くの環境では、こうした調整に要する時間の方が、実際の保守作業よりも長くなることがあります。

Exadata VM Live Migrationは、新たな高可用性技術ではありません。むしろ、既存のExadataの可用性機能を補完し、異なる課題に対応する技術です。Oracle Real Application Clusters（RAC）、Transparent Application Continuity、Active Data Guard、そしてMaximum Availability Architecture（MAA）は、障害時や計画保守時にアプリケーションを保護します。一方、Live Migrationは、稼働中のExadata VMをKVMホスト間で最小限の中断で移行できるようにすることで、その基盤となるインフラストラクチャの保守による運用上の影響を軽減します。

ここ数回のExadataリリースを通じて、私たちは計画的なプラットフォーム保守による運用への影響を着実に低減してきました。Exadata Live Updateは、サポート対象ソフトウェアの保守に伴う停止時間を短縮し、VM Live Migrationは、KVMホストをサービスから切り離す際によくある保守シナリオにおいて、その影響を軽減することで、さらなる運用効率の向上を実現します。

Exadata VM Live Migrationがユニークである理由

VMライブ・マイグレーション自体は新しい技術ではありません。ハイパーバイザーは何年も前からこの機能をサポートしています。Exadataで異なるのは、仮想マシン上で単にアプリケーションが動作しているわけではないという点です。そこでは、Exadataアーキテクチャと緊密に統合されたOracle Databaseが稼働しており、ExadataのRDMA over Converged Ethernet（RoCE）ファブリックを介して、ストレージ・サーバーや、必要に応じて他のデータベース・サーバーと常時通信しています。

RDMAとそのネットワーク・ファブリックは、Exadataを特徴づける重要な要素の一つです。これにより、Oracle DatabaseはRDMA経由でストレージ・サーバー上のXRMEMへ直接アクセスし、極めて低レイテンシなOLTP読み取りを実現します。また、Oracle RAC Cache Fusionがデータベース・インスタンス間でデータ・ブロックをやり取りするための高速インターコネクトも提供します。これらの機能によって、Exadataはミッションクリティカルなデータベースが求める低レイテンシかつ予測可能なパフォーマンスを実現しています。

このような環境で仮想マシンを移動することは、単にゲストOSをハイパーバイザー間で移動する以上の意味を持ちます。課題は、仮想マシンの移行中もExadataデータベースの実行環境を維持し、データベース性能やクラスタ動作を支えるRDMA通信経路を保ちながら、計画的なインフラ保守がデータベース性能へ影響を与えるイベントにならないようにすることです。

これこそが、Exadata VM Live Migrationが他と異なり、ユニークである理由です。単に仮想マシンを移動することが目的ではありません。移行中もOracle DatabaseがExadata上のデータベースとしての振る舞いを維持したまま稼働し続けられるようにすることで、インフラ保守を実施しながらも、お客様がExadataを選択した理由である高いパフォーマンス特性を損なわないことを目指しています。

Exadata VM Live Migrationが解決するのは、まさにこの課題です。

別の言い方をすれば、Exadata VM Live Migrationの本質は仮想マシンを移動することではありません。インフラ保守をアプリケーションのクリティカルパスから切り離すことにあります。

本記事は、機能概要や操作手順を紹介するものではありません。そうした内容については、製品ドキュメントがすでに十分に説明しています。ここでは、Live MigrationがExadata全体の保守戦略の中でどのような位置付けにあるのか、この機能が必要とされた背景、そしてどのような設計原則によって適用可能な環境が決まるのかを見ていきます。

よくある保守ウィンドウ

具体例を使って考えてみましょう。

月次のExadata保守サイクルがやってきました。今回は、X11M KVMホストのファームウェア更新が含まれています。

更新作業そのものは特に難しいものではありません。技術的な手順は確立されています。本当に重要なのは、そのホスト上で現在稼働しているワークロードをどう扱うかという点です。

従来の保守計画は、おそらく次のような流れになるでしょう。

• アプリケーション担当者と調整する
• 保守ウィンドウを設定する
• 可能であればサービスを移動または停止する
• 最初のKVMホスト上の仮想マシンを停止する
• ファームウェアを更新する
• KVMホストを再起動する
• 仮想マシンを再起動する
• アプリケーションを再接続する
• 次のKVMホストで同じ作業を繰り返す

これらの手順自体は特別難しいものではありません。しかし、運用負荷が大きくなるのは、インフラストラクチャと、その上で動作するワークロードが密接に依存しているためです。

Live Migrationは、この関係を変えます。

互換性のある別のKVMホストが利用可能であれば、保守開始前に稼働中のVMを移行できます。ワークロードの移行が完了すれば、元のKVMホストを更新し、その後サービスへ復帰させることができます。

ファームウェアの更新は依然として必要です。

ハードウェアの保守も依然として必要です。

しかし、インフラ保守とアプリケーションの可用性は切り離されます。

移動するのはデータではなく実行環境

Live Migrationについて最もよくある誤解の一つは、「すべてが移動する」と考えてしまうことです。

実際にはそうではありません。

Live Migrationが移動するのは、VMの実行環境です。OS、メモリ、そして実行状態が、互換性のある別のKVMホストへ移動します。

アプリケーションのデータは移動しません。

この点を強調するのは、VMストレージとデータベース・ストレージは異なる概念であり、それぞれ異なる方法で扱われるからです。

VMについては、そのファイルシステムはExascaleボリューム上に配置されている必要があります。

この共有ストレージこそが、Live Migrationを実現する重要なアーキテクチャ上の要素の一つです。VMのファイルシステムは、すでに両方のKVMホストからアクセス可能な共有ストレージ上に存在するため、移動する必要があるのはVMの実行環境だけです。ストレージ自体は、最初から必要な場所に存在しています。

では、Exascaleではなく、KVMホストのローカル・ストレージ上にあるディスク・イメージを使用するVMはどうでしょうか。Exadata System Software 26aiでは、こうしたVMのファイルシステムをExascaleボリュームへ移行できるようになり、Live Migrationを利用可能にする機能が追加されました。

一方、データベースについては事情が異なります。

データベース・ファイルがASM上にあるかExascaleストレージ上にあるかは、Live Migrationとは基本的に独立した要素です。VMがどの互換性のあるKVMホスト上で動作していても、データベースは従来どおりRDMAネットワーク・ファブリック経由でストレージへアクセスし続けます。

これも、Live MigrationがExadataアーキテクチャに自然に適合する理由の一つです。移動するのは実行環境だけであり、データベースは移行前とまったく同じ方法でストレージへアクセスし続けることができます。

図1. Live Migrationはデータではなく実行環境を移動する

運用上の制約を理解する

Live Migrationをデモした後、私が最初によく受ける質問があります。

「VMはどのKVMホストへでも移行できますか？」

まさに本質を突いた質問です。

答えは「いいえ」です。しかし、本当に重要なのは、その理由です。

先ほど、VMの実行環境を移動することと、データを移動することの違いについて説明しました。この考え方は、Live Migrationにおけるほぼすべての互換性要件を理解する鍵でもあります。

稼働中のVMは、同等の実行環境をすでに提供しており、VMが動作を継続するために必要なすべてのリソースへアクセスできるKVMホストにのみ移行できます。

そのため、ハードウェア、ネットワーク、オペレーティング・システム、そしてVMストレージに関する要件が存在します。

ハードウェア互換性

移行先のKVMホストは、あたかもVMが一度も移動していないかのように実行を継続できなければなりません。このため、Live Migrationは、同一世代のハードウェアかつ同一CPU構成を持つKVMホスト間でサポートされています。

例えば、以下の組み合わせです。

• X10M → X10M
• X11M → X11M
• 1ソケット → 1ソケット
• 2ソケット → 2ソケット

これはVMの移行先を制限するためではありません。移行後も互換性のある実行環境で処理を継続できることを保証するためです。

ネットワーク互換性

移行先のKVMホストは、同じRDMA対応Exadataファブリックに属している必要があります。

実際には、両方のKVMホストが同一のRoCEネットワークに接続されている必要があります。マルチラック環境では、それらのラックが単一のマルチラック構成として構成されていなければなりません。

それぞれ独立したRoCEネットワークを持つ別々のExadata環境間でVMを移行することはできません。

オペレーティング・システム互換性

基盤となるオペレーティング・システムも、実行環境の一部です。

そのため、Live Migrationでは、移行元と移行先のKVMホストが同じOSバージョンで動作している必要があります。例えば、Oracle Linux 8です。

ここで重要なのは、要件となるのは基盤OSのバージョンであり、必ずしもExadata System Softwareのバージョンではないという点です。

ストレージ互換性

最後に、移行先KVMホストは、VMのファイルシステムへあらかじめアクセスできる必要があります。このため、VMのファイルシステムはExascaleボリューム上に配置されている必要があり、両方のKVMホストは同じExascaleクラスタに属していなければなりません。

VMのファイルシステムを共有できなければ、移行完了後に移行先KVMホストが実行を再開する対象が存在しないためです。

これらの条件が満たされていれば、実際のLive Migrationは、サポートされているExadata管理ツールであるOEDACLIまたはmigratevmを使用して簡単に実行できます。

oedacli> migrate guest hostname=exadpm01vm01 mode=live srchost=exadpm01kvm01 tgthost=exadpm01kvm02

または

$ migratevm exadpm01vm01 exadpm01kvm02

オフライン・マイグレーションについて

Exadataでは、VMをKVMホスト間でオフライン・マイグレーションする方法も提供されています。例えば、X8MのKVMホストからX11MのKVMホストへVMを移行するといったシナリオに利用できます。

Exascaleボリュームが登場する以前は、このような移行は、VMを停止し、その内容と構成を移行元から移行先へコピーして、新しいホスト上でVMを再起動することで実現していました。

Exascaleの導入により、Live Migrationと同様に、共有ボリュームによってこのプロセスは大幅に簡素化され、高速化されています。

OEDACLIおよびmigratevmにはOFFLINEモードが用意されており、こうした煩雑な処理を自動的に実行してくれます。詳細については、以前のブログ記事をご覧ください。

オフライン・マイグレーションでは、アプリケーションに短時間の影響はあるものの、ホストの実行環境そのものを変更することができます。

停止させる対象を変える

インフラストラクチャの保守がなくなることはありません。

しかし変わりつつあるのは、その保守のたびにアプリケーションへ影響を与えるのが当然だという考え方です。

VM Live Migrationは、Live Updateのような機能と組み合わせることで、保守ライフサイクルの異なる側面をカバーします。両者は、Exadataの開発におけるより大きな方向性、すなわち保守がアプリケーションへ与える影響を最小限に抑えるという考え方を体現しています。

VM Live Migrationは、新たな高可用性機能ではありません。Oracle RAC、Transparent Application Continuity、Active Data Guard、そしてMaximum Availability Architecture（MAA）を補完し、計画的なインフラ保守による影響を軽減するための運用機能です。

Live Migrationが変えるのは、保守そのものではありません。

保守をなくすわけではなく、保守によって影響を受ける対象を変えるのです。

次にKVMホストの更新が必要になったとき、最初に考えることは、もはや

「アプリケーションへの影響を最も小さくするには、いつ保守すべきか？」

ではなく、

「データベースVMをどのKVMホストへ移行しようか？」

になるかもしれません。

これは考え方としては小さな変化ですが、Exadata環境の運用方法においては非常に大きな変化と言えるでしょう。