Exadata VMライブ移行による計画停止時間の短縮 (2026/07/27)
Exadata VMライブ移行による計画停止時間の短縮 (2026/07/27)
https://blogs.oracle.com/exadata/reducing-planned-downtime-with-exadata-vm-live-migration
投稿者：Alex Blyth | Product Management Architect - Exadata
あらゆるプラットフォームを運用する上で避けられない現実の一つは、メンテナンス作業が決して終わらないということです。
セキュリティ修正プログラムの適用、オペレーティングシステムやアプリケーションソフトウェアのアップデート、ファームウェアの適用など、メンテナンスは欠かせません。ハードウェアコンポーネントはいずれ交換が必要になります。容量要件も時間とともに変化します。これらはどれも特に珍しいことではありません。興味深いのは、これらの作業がプラットフォーム上で稼働するアプリケーションやワークロードにどれほどの影響を与えるかということです。
従来、Exadataインフラストラクチャの保守とアプリケーションの可用性は密接に関連していました。KVMホストを停止する必要が生じた場合、そのホスト上で稼働している仮想マシン（VM）とアプリケーションワークロードは必然的に保守計画の対象となりました。場合によっては、アプリケーションを完全に停止する必要がありました。多くの場合、アプリケーションの可用性、パフォーマンスの低下、停止期間の調整、そしてビジネスオーナーとの交渉などについて、綿密な計画を立てる必要がありました。
多くの環境では、こうしたやり取りにメンテナンス自体よりも時間がかかります。Exadata
VM Live Migration は、別の高可用性テクノロジーではありません。むしろ、異なる問題に対処することで、Exadata の既存の可用性機能を補完します。Oracle Real Application Clusters、Transparent Application Continuity、Active Data Guard、およびより広範な Maximum Availability Architecture は、障害発生時や計画メンテナンス時にアプリケーションを保護します。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とRDMAファブリックは、Exadataの決定的な特徴の一つです。これにより、Oracle DatabaseはRDMAを介してストレージサーバ上のXRMEMに直接アクセスすることで、極めて低遅延のOLTP読み取りを実行できます。また、Oracle RAC Cache Fusionがデータベースインスタンス間でブロックを交換するために使用する高速インターコネクトも提供します。これらの機能により、Exadataはミッションクリティカルなデータベースが依存する低遅延で予測可能なパフォーマンスを実現します。
したがって、この環境で仮想マシンを移動するということは、単にハイパーバイザー間でゲストオペレーティングシステムを移動させる以上の意味を持ちます。課題は、仮想マシンの移動中にアクティブなExadataデータベース実行環境を維持すること、つまり、計画されたインフラストラクチャのメンテナンスをデータベースのパフォーマンス低下につながるような事態にすることなく、データベースのパフォーマンスとクラスタ運用を支えるRDMA通信パスを維持することです。
これが、Exadata VM Live Migration の独自性と他との違いです。単に仮想マシンを移動するだけではありません。稼働中の Oracle Database を移動することで、移行中も Exadata 上でデータベースとして動作し続けるため、お客様が Exadata を選んだ理由であるパフォーマンス特性を損なうことなく、インフラストラクチャのメンテナンスを実行できます。
Exadata VM Live Migrationは、まさにその問題を解決します。
言い換えれば、Exadata VM Live Migrationは、仮想マシンを移動させることだけが目的ではありません。インフラストラクチャのメンテナンスをアプリケーションのクリティカルパスから切り離すことが目的なのです。
これは、機能概要や手順ガイドを新たに作成するものではありません。製品ドキュメントには既にこれらのトピックが十分に網羅されています。ここでは、ライブマイグレーションがExadataのメンテナンス全体の中でどのような位置づけにあるのか、なぜこの機能が存在するのか、そしてライブマイグレーションを効果的に活用できる場所を決定するエンジニアリング原則について考察します。
おなじみのメンテナンス期間
具体例を挙げて説明しましょう。
毎月のExadataメンテナンスサイクルの時期がやってきました。このメンテナンスには、X11M KVMホストのファームウェアアップデートが含まれています。
アップデート自体は特に興味深いものではない。技術的な作業内容は十分に理解されている。本当の問題は、現在そのホスト上で稼働しているワークロードをどうするかということだ。
従来のメンテナンスプランは、おそらく見覚えのあるものだろう。
- アプリケーションオーナーと連携する
- メンテナンス期間をスケジュールする
- 可能な限り移転またはサービス停止を行う
- 最初のKVMホスト上の仮想マシンをシャットダウンします。
- ファームウェアのアップデートを実行します。
- KVMホストを再起動します
- 仮想マシンを再起動します
- アプリケーションを再接続する
- 次のKVMホストに進みます
これらの手順はどれも特に難しいものではありません。しかし、運用上のオーバーヘッドは、インフラストラクチャと、その上で実行されるワークロードとの間の依存関係から生じます。
ライブマイグレーションは、その関係性を変える。
互換性のある別のKVMホストが利用可能な場合は、メンテナンス開始前に稼働中の仮想マシンを移行できます。ワークロードの移行が完了したら、元のKVMホストを更新してサービスを再開できます。
ファームウェアのアップデートが必要です。
ハードウェアのメンテナンスは依然として必要です。
インフラストラクチャの保守とアプリケーションの可用性を切り離しました。
データではなく、実行を移動させる
最もよくある誤解の一つは、ライブマイグレーションによってすべてが移行されると思い込むことです。
実際はそうではありません。
ライブマイグレーションは、仮想マシンの実行環境を移行します。オペレーティングシステム、メモリ、および実行状態は、互換性のあるKVMホスト間で移動されます。
アプリケーションのデータは移動しません。
私がこのように区別するのは、VMストレージとデータベースストレージは異なる概念であり、したがって扱い方も異なるためです。
VMの場合、ファイルシステムはExascaleボリューム上に存在する必要があります。
この共有ストレージは、ライブマイグレーションを実現する上で重要なアーキテクチャ要素の一つです。VMのファイルシステムは既に両方のKVMホストからアクセス可能なストレージ上に配置されているため、VMの実行環境のみを移動すれば済みます。ストレージは既に必要な場所に配置されています。
しかし、非エクサスケールのローカルディスクイメージ（KVMホストのローカルストレージ上のイメージ）をバックエンドとするVMを実行している場合はどうでしょうか？Exadata System Software 26aiでは、これらのVMファイルシステムをエクサスケールボリュームに移行する機能が追加され、ライブマイグレーションを利用できるようになります。
データベースはまた別の話です。
データベースファイルがASMに存在するか、エクサスケールストレージに存在するかは、ライブマイグレーションとはほとんど関係ありません。どの互換性のあるKVMホストが現在VMをホストしているかに関わらず、データベースはRDMAネットワークファブリックを介してストレージにアクセスし続けます。
それが、ライブマイグレーションがExadataアーキテクチャに自然に馴染む理由の一つです。実行環境は移動しますが、データベースは以前とまったく同じようにストレージにアクセスし続けます。
図1. ライブマイグレーションは実行環境を移動しますが、データは移動しません。
運用上の境界を理解する
ライブマイグレーションのデモンストレーションを行った後、私がよく最初に聞かれる質問の一つは次のとおりです。
「仮想マシンを任意のKVMホストに移動できますか？」
それはまさに的確な質問だ。
答えはノーだが、興味深いのはその理由だ。
先ほど、仮想マシンの実行環境の移動とデータの移動の違いについて説明しました。この同じ原理は、ほぼすべての互換性要件を説明するのに当てはまります。
実行中の仮想マシンは、同等の実行環境を提供し、かつ仮想マシンが実行を継続するために必要なすべてのリソースにアクセスできる別のKVMホストにのみ移動できます。
これは、ハードウェア、ネットワーク、オペレーティングシステム、および仮想マシンのストレージに影響を与えます。
ハードウェアの互換性
移行先のKVMホストは、仮想マシンが移動しなかった場合と同様に実行を継続できる必要があります。
そのため、ライブマイグレーションは、同じハードウェア世代およびCPU構成のKVMホスト間でのみサポートされます。
例えば：
これは、仮想マシンが実行できる場所を制限することではありません。移行後も互換性のある環境で実行が継続されることを保証するためのものです。
ネットワーク互換性
宛先のKVMホストも、同じRDMA対応のExadataファブリックの一部である必要があります。
実際には、これは両方のKVMホストが同じRoCEネットワークに接続されている必要があることを意味します。マルチラック環境では、ラックは単一のマルチラックデプロイメントとして構成する必要があります。それぞれ独立したRoCEネットワークを持つ別々のExadataデプロイメント間でVMを移動することはできません。
オペレーティングシステムの互換性
基盤となるオペレーティングシステムも、実行環境の一部を構成する。
したがって、ライブマイグレーションでは、ソースと宛先の KVM ホストが同じ基盤となるオペレーティングシステム バージョンを実行している必要があります。たとえば、Oracle Linux 8 などです。
これは、基盤となるオペレーティングシステムを指しており、必ずしもExadataシステムソフトウェアのバージョンを指すわけではないことに注意してください。
ストレージの互換性
最後に、宛先KVMホストは既にVMのファイルシステムにアクセスできる必要があります。
これが、VMのファイルシステムがExascaleボリューム上に存在する必要がある理由であり、両方のKVMホストが同じExascaleクラスタに属している必要がある理由です。
VMのファイルシステムへの共有アクセスがない場合、移行完了後、移行先のKVMホストが実行を再開できるものは何もありません。
OEDACLIこれらの条件が満たされると、サポートされている Exadata 管理ツールまたはを使用して移行自体を実行するのは簡単ですmigratevm。
oedacli> migrate guest hostname=exadpm01vm01 mode=live srchost=exadpm01kvm01 tgthost=exadpm01kvm02
または
$ migratevm exadpm01vm01 exadpm01kvm02
オフライン移行についてはどうでしょうか？
Exadataは、KVMホスト間でVMをオフラインで移行する手段も提供しており、X8MからX11M KVMホストへのVMの移動といったシナリオに対応できる点も特筆すべきです。Exascaleボリュームが登場する以前は、VMを停止し、ソースとターゲット間でVMの内容と構成をコピーし、新しいホストでVMを再起動することで、この移行を実現していました。
Exascaleでは、ライブマイグレーションと同様に、ボリュームを使用することでプロセスがはるかに簡単かつ迅速になります。OEDACLIまた、migratevmオフラインモードも搭載されており、面倒な作業を自動的に行ってくれます。オフラインモードの詳細については、以前の記事をご覧ください。
オフライン移行では、アプリケーションへの影響は小さいものの、ホストの実行環境を変更することができます。
止めるべきことを変える
インフラ整備はなくなることはない。
変わるのは、メンテナンス中は必ずアプリケーションに影響が出るという私たちの認識です。
VMライブマイグレーションは、ライブアップデートなどの機能を補完し、メンテナンスライフサイクルの異なる側面に対応します。これらは、Exadataエンジニアリングにおけるより広範な方向性、すなわちメンテナンスによるアプリケーションへの影響を軽減するという方向性を反映しています。
VMライブマイグレーションは、単なる高可用性技術ではありません。計画的なインフラストラクチャメンテナンスの影響を軽減することで、Oracle RAC、透過的アプリケーション継続性、Active Data Guard、およびより広範な最大可用性アーキテクチャを補完する運用機能です。
ライブマイグレーションが変えるのは、メンテナンスそのものではありません。
ライブマイグレーションはメンテナンスをなくすものではありません。メンテナンスが影響を与えるべき対象を変えるものです。
次回KVMホストのアップデートが必要になった場合、最初に問うべきことはもはや次のとおりではないかもしれません。
「いつがアプリケーションへの影響が最も少ないでしょうか？」
それは単に次のことかもしれません。
「データベースVMはどこに移動すればいいですか？」
これは考え方の微妙な変化ではあるが、Exadataの導入運用方法においては大きな変化となる。
コメント
コメントを投稿