VMwareからその次へ：ハイパーバイザー移行時のデータ保護

2023年にブロードコムがVMwareを買収したことで、移行の波が収まる気配はない。しかし、VMwareから他のハイパーバイザーに移行する場合、技術上および運用上の重大なリスクが生じる可能性がある。

ITチームは、移行開始時には必ずしも明らかではない課題に備えなければならない。

価格の上昇、ライセンスの変更、カスタマー・サポートのシフトによって、VMware の顧客は代替製品を探すようになった。最近の運用上の問題は、その助けにはなっていない。

昨年は、ブロードコムのURLリダイレクトが原因で、VMware Workstationの自動アップデートが失敗しました。2026年、移行は続くガートナーのジュリア・パーマー調査副社長は最近、VMwareは2028年までにワークロードの35％を失うだろうと予測した。

これらのワークロードの多くは、Microsoft Hyper-V、Azure Stack HCI、Nutanix AHV、Proxmox VE、KVMなどのプラットフォームに移行するだろう。残念ながら、この道のりには課題がつきまとう。ハイパーバイザーの切り替えは、大きなリスクを伴うインフラの変更です。

ITプロフェッショナルは、データを無傷で利用できる状態で移行を成功させることに集中する必要があります。

ハイパーバイザーの移行が技術的に危険な理由

簡単そうに聞こえる：データをエクスポートし、新しいフォーマットに変換してから新しいハイパーバイザーにインポートする。しかし、このプロセスは見た目よりもはるかにリスクが高い。

ハイパーバイザーは相互運用できないからだ。複数の技術的変数が、移行が失敗したり不安定になったりするリスクを高めている。ハイパーバイザーは、ディスクフォーマット、ハードウェア抽象化、ドライバースタック、ネットワーキング・モデルが異なる。

仮想ハードウェア・バージョン、ストレージ・コントローラ、チップセット・エミュレーション、ネットワーク仮想化レイヤーは、必ずしもきれいに変換されるとは限りません。

スナップショットとテンプレートの動作も異なります。微妙な設定の違いであっても、ワークロードが本番環境でのプレッシャーにさらされたときに初めて表面化する不安定性を生み出す可能性がある。

a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

ハイパーバイザーの移行を成功させるにはバックアップが不可欠

プラットフォーム移行の最も重要な前提条件は、変換ツールではありません。検証された、復元可能なバックアップです。

組織は、IT担当者が同じハイパーバイザーだけでなく、異なるハードウェアやまったく異なる仮想化プラットフォームにリストアできる、フルイメージでアプリケーションの一貫性があるバックアップでワークロードを保護する必要があります。

ITチームは、カットオーバー後だけでなく、移行を開始する前にリカバリ・ドリルを実施する必要があります。

プラットフォームにとらわれないバックアップ・アーキテクチャは、必要なセーフティ・ネットを提供します。これにより、移行元環境から移行先環境へのリストアが可能になり、互換性やパフォーマンスに問題が発生した場合、元のプラットフォームに迅速に戻すことができます。

つまり、データの安全性とアクセス性を維持することができるのです。

Any-to-Anyハイパーバイザーリカバリ（物理環境、仮想環境、クラウド環境から他の移行先へのリストア）は、移行リスクを低減し、長期的なベンダーロックインを減らすという利点もある。

移行時にほとんどのチームが過小評価する3つのリスクを回避する方法

最も慎重に計画され、実行された移行であっても、予測可能な理由で失敗することがあります。

1.チームがダウンタイムを過小評価しがち

多くのチームが、最悪のシナリオとは対照的に、理想的なレベルのダウンタイムを計画している。残念なことに、マイグレーションはメンテナンスウィンドウを超えることが多い。システムが安定していないときにウィンドウが閉じてしまうと、企業はトランザクションの失敗、業務の停滞、SLA違反、風評被害などに見舞われる可能性がある。

そのため、移行計画には、事前に正式な事業継続戦略を盛り込む必要がある：

• 各作業負荷は現実的にどれくらいの時間オフラインにできるのか？
• ロールバックが必要な場合はどうするのか？
• 可否の判断は誰が行うのか？
• 復旧に予想以上の時間がかかる場合のコミュニケーション計画は？

バックアップとリカバリは非常に重要である。ワークロードを元のプラットフォームに迅速にリストアできるかどうかが、短時間の遅延と数日間の停止との分かれ目となる。

2.バックアップとリカバリのギャップは移行を悩ませる

移行は、バックアップとディザスタリカバリにとって危険なグレーゾーンを生み出します。そのようなときこそ、リカバリ可能性が最も高くなければならない。どちらの環境からでもバックアップをリストアするのにかかる時間は非常に重要です。

よくあるギャップは以下のような場合です：

• VMエクスポート中にバックアップチェーンが切断される。
• プラットフォームの変換後に増分バックアップ・ジョブが失敗する。
• アプリケーションと整合性のあるスナップショットが、新しいハイパーバイザー上で検証されない。
• DRのレプリケーション・ターゲットが、段階的なカットオーバー中に同期されない。

バックアップとリカバリは、移行中も継続的に機能する必要がある。ITチームは、移行が完了するまで、レガシー・プラットフォームとターゲット・プラットフォームの両方からワークロードをリカバリできるように、重複期間中も並列保護を維持する必要がある。

3.攻撃対象が拡大するため、バックアップ・イメージの保護が必要

移行によって攻撃対象も拡大します。

2つのハイパーバイザースタックが稼働することで、複雑さが急増します。バックアップリポジトリ、特にイメージレベルのバックアップは、価値の高いターゲットになり得ます。マイグレーション中に攻撃者に侵害されると、ロールバックやリカバリーのオプションがなくなってしまいます。

この段階では、不変性が不可欠です。ITチームは、特権アカウントによる変更または削除からバックアップ・イメージを保護する必要があります。役割ベースのアクセス制御を強化し、管理者アクセスを制限する必要があります。

同様に重要なのは、3-2-1原則の遵守です：少なくとも3つのデータのコピーを2つの異なるメディアに保存し、1つはオフサイトまたはオフラインに保存する。移行時には、この3つ目のコピーが重要な保険となる。

本番環境とプライマリ・バックアップ・インフラの両方が影響を受けた場合、隔離されたコピーが復旧経路を確保します。

ネイティブに統合されたプラットフォームの価値

パラレル・プロテクションを維持することは、運用リスクを低減するために不可欠です。しかし、管理の複雑さも増します。2つのハイパーバイザスタック、複数のストレージシステム、並列の保護ポリシーを、ギャップを生じることなく共存させなければなりません。

統合サイバー保護プラットフォームは、ITチームのこのプロセスを簡素化することができます。統合されたサイバー保護プラットフォームは、単一の制御ポイントを通じて、物理サーバー、ハイパーバイザー、クラウドのワークロードに一貫したバックアップ、リカバリ、セキュリティ制御を提供することで、複雑さを軽減することができます。

Acronis Cyber Protectにネイティブに統合された保護機能と移行機能により、ロールバック準備と継続的な同期を維持しながら、移行スケジュールを短縮できます。

レジリエンスの機会としての移行

VMwareからの移行により、1つのコンセプトが明確になりました。移行計画は1回限りのプロジェクトではなく、長期的なコンピテンシーです。

移行を成功させるチームは、ハイパーバイザーの移行をレジリエンスの演習として扱う。事前にバックアップを検証し、クロスプラットフォームのリカバリ機能を確保し、ロールバックパスを維持し、ランサムウェアに対してバックアップストレージを強化し、移行後のデータの完全性を検証する。

このような安全策を講じることで、移行はより予測しやすくなり、成功する可能性が大幅に高まります。

VMwareの移行は、時間がかかり、リスクが高く、破壊的である必要はありません。

Acronis Cyber Protectを使用すれば、ITチームは、AIを活用したセキュリティ、バックアップ、リカバリを1つのネイティブな統合ソリューションで実現しながら、移行を加速する柔軟で応答性の高いプラットフォームを手に入れることができます。

VMwareからの移行を計画している場合、アクロニスがどのように組織の移行を迅速化し、すべてのステップで保護を維持するかをご覧ください。

Acronis Cyber ProtectがVMwareからの移行をどのように加速するかをご覧ください。

アクロニスがスポンサーとなり、執筆しました。