Hyper-VとVMwareを比較｜機能差より先に確認したい運用・移行条件

「機能は似ている」で止まってしまう比較

比較表を並べると、主要な機能の欄には両方に印がつくことが多くなります。しかしこの印は、似た役割の機能が存在することを示すだけで、同じ条件で同じように動くという意味ではありません。

例えば、次のような状況を想定してみます。機能比較表で両方に印がついた項目を要件充足とみなして設計に進んだところ、共有ストレージの方式が可用性の要件に合わないと分かり、構成の見直しに戻ることになった。機能があること自体は誤りではなかったが、それが動作する条件を確認していなかった、というケースです。

印の有無ではなく、確認する観点で見る

確認すべきなのは、機能の有無ではなく次の三点です。

• その機能が動作するための前提条件は何か。ハードウェア、ネットワーク、ストレージ、ソフトウェアの構成にどのような要件があるか

• その機能を使うために、どのような設定と管理作業が必要になるか

• 移行の際、既存の環境から引き継げるものと、作り直しになるものは何か

本記事では、両者の違いを一覧で示すことはしません。条件は対象とする Version や構成によって変わり、一般化した表は自社の判断に使えないためです。代わりに、何をどこで確認すればよいかを整理します。

この表の確認先が示すとおり、Hyper-V 側の条件は Microsoft の公開情報で、周辺製品との連携は各製品の提供元で確認します。一つの比較記事だけで判断できる範囲ではありません。

比較の前に、自社側の制約を書き出す

確認の前提として、自社側の条件を先に整理しておいてください。Hyper-V を検討する場合、次の四つが判断を左右します。

• 運用を担う人数と、その人たちの経験がどちらの製品寄りか

• 既存資産のうち、Windows 環境と Linux 環境の比率

• 業務を止められる時間帯と、その長さ

• 使用しているバックアップ製品、監視ツール、その他の周辺製品

評価軸を借り物で済ませると、自社にとって重要でない項目に点数をつけ、重要な項目が抜けたまま結論を出すことになります。なお、候補全体をどう比較し、どの軸に重みを置くかという設計については、VMware代替候補をどう比較するか｜技術・運用・契約・移行の判断軸で扱っています。

構成と管理の違いを運用視点で見る

製品が変わると、日常の運用手順はほぼ作り直しになります。比較すべきは管理画面の見た目ではなく、その先にある運用への影響です。

日常運用の手順

一つめは、日常運用の手順そのものです。仮想マシンの作成、リソースの変更、状態の確認。これらの操作方法が変われば手順書は書き直しになります。数十ページの手順書を持つ組織であれば、無視できない作業量です。

担当者の習熟にかかる時間

二つめは、担当者の習熟にかかる時間です。

例えば、次のような状況を想定してみます。Windows Server の管理経験がある担当者を移行の主担当に据えたところ、構築までは順調に進んだ。しかし移行後、クラスターのメンテナンス手順とネットワークの設計で判断がつかず、外部への問い合わせが増えた。管理画面の操作は問題なかったが、その下の設計思想が未習得だった、というケースです。

注意したいのは、Windows Server の管理経験があることと、Hyper-V の運用ができることは別だという点です。一般的な管理に慣れていても、次の五領域は改めて確認と習得が必要になります。

この表を担当者ごとに埋めてみてください。習得が必要な領域が多いほど、移行後に運用が回るまでの期間は長くなります。未確認の欄が残る場合、それ自体が検証で確かめるべき項目です。

このうち権限の設計は、移行後のセキュリティ運用に直結します。現在の環境で誰がどの操作を実行できるかを整理し、移行先で同じ区分を再現できるかを確認してください。再現できない場合、権限体系そのものを設計し直すことになります。あわせて、操作の記録がどこに残るか、監査で求められる情報が取得できるかも確認対象です。ここが移行後に不足していると分かると、追加の仕組みが必要になります。

自動化の作り直し

三つめは、自動化しているものがあれば、その作り直しです。スクリプトで定型作業を回している場合、管理体系が変われば作り直しになります。この工数を移行費用に含めているかどうかが判断の分かれ目です。ライセンス費用の比較だけで判断すると、この部分がまるごと抜け落ちます。

手順書の作り直しは地味な作業ですが、省略すると移行後の運用が知っている人にしか回せない状態になります。属人化は移行の副作用として起こりやすく、移行直後は気づきにくい問題です。

可用性と障害時の動きを比較する

Failover Clustering の成立条件

障害時に仮想マシンを別のホストで起動し直す仕組みは、いずれの製品にも用意されています。ただし動作するための条件は製品ごとに定められており、条件を満たさなければ機能は使えません。

Hyper-V の場合、この仕組みは Failover Clustering の機能として提供されます。成立条件は Microsoft が公開している情報で確認できます。確認すべき項目と、満たさない場合に起こることは次のとおりです。

• Cluster を構成するための要件。ノードの構成、対応するハードウェアの条件。満たさない場合、クラスターを組めず自動的な切り替えができない

• 共有ストレージの要件。使用できる方式と、その構成条件。満たさない場合、ストレージの追加投資が必要になる

• ネットワークの要件。必要な経路と、その構成条件。満たさない場合、ネットワーク機器の構成変更が発生する

• 仮想マシンを停止せずに移す機能が動作する条件。とくに、移行元と移行先のプロセッサの互換性。満たさない場合、移行やメンテナンスのたびに停止時間が必要になる

なお、仮想マシンを停止せずに移す機能そのものは、フェールオーバー クラスタリングを使わない構成でも利用できます。ただし障害時の自動的な切り替えを成立させるには、クラスターの構成が前提になります。

これらの条件は Windows Server の Version によって異なる場合があります。自社が対象とする Version の情報を、次のページで確認してください。

現在の構成がこれらの要件を満たすかどうかが判断の分かれ目です。共有ストレージの方式やネットワークの構成が要件に合わない場合、可用性を成立させるために追加の投資が必要になります。

障害時の切り分けとサポート窓口

もう一つの観点は、障害が起きたときの動き方です。切り分けをどこまで自社で行い、どこからサポートに投げるのか。サポートの窓口が製品ごとに分かれているか、一つにまとまっているか。複数ベンダーの製品を組み合わせた構成では、原因がどこにあるかで問い合わせ先が変わり、切り分けに時間がかかることがあります。

可用性は設計しただけでは確認になりません。実際にホストを停止させ、想定どおりに切り替わるか、切り替わるまでにどれくらいかかるかを見ておかないと、本番で初めて挙動を知ることになります。

移行の手間と、周辺製品の対応

移行方式と停止時間

移行にかかる手間は、比較軸の一つとして最初から組み込んでおく必要があります。

一つめは、仮想マシンをどう移すかという方式です。方式によって、移行中に業務を止める必要があるか、どれくらいの時間がかかるかが変わります。台数が多い環境では、この差が全体の期間に効きます。

二つめは、止められる時間です。方式が決まっても、業務側が許容できる停止時間に収まらなければ、方式を見直すか分割して移すかの判断が必要になります。

周辺製品の対応可否

三つめが、周辺製品の対応可否です。バックアップ製品、監視ツール、ジョブ管理の仕組み。これらが移行先の環境に対応していなければ、周辺製品ごと入れ替える前提になり、費用も期間も当初の想定から変わります。

監視については、対応可否だけでなく、取得できる情報の粒度も確認してください。対応していても、これまで取れていた項目が取得できなくなると、しきい値と通知の設計をやり直すことになります。

周辺製品の対応可否は、移行先候補を絞る条件になり得ます。機能面で要件を満たしていても、既存のバックアップ製品が対応していないために選べない、という結論もあり得ます。比較の前提となる現状把握については、VMware環境の棚卸し方法｜移行検討前に確認する構成・契約・依存関係で扱っています。

向いているケース、向いていないケース

どちらが優れているかではなく、どちらが自社の条件に近いかで考えます。次の表は、Hyper-V を候補とする場合に固有の確認方法を整理したものです。

この表のどこに自社が当てはまるかを、実際の数字と製品名で埋めてみてください。埋まらない欄があれば、そこが棚卸しの不足箇所です。

なお、慎重に見極めたい条件に該当しても、移行できないという意味ではありません。設計の考え方を見直す必要がある、という意味です。実際に動かさないと分からない部分も残るため、候補として残すのであれば検証が望ましいでしょう。

また、Hypervisor の選択とは別に、構成方式ごと見直す方向もあります。この論点は別の記事で扱います。

現行契約の条件を確認したうえで判断したい場合は、VMwareライセンス・契約変更の影響をどう確認するか｜契約・構成・更新期限の整理をご覧ください。

よくある質問

Q1. 既存の VMware の運用ノウハウは、どこまで使えますか

仮想化の考え方そのものは共通していますが、操作手順や管理体系は異なります。仮想マシンやクラスターといった概念の理解は活きる一方、日常の操作方法、トラブル時の確認箇所、自動化のつくり方は改めて習得が必要です。移行計画には、この習熟期間を見込んでおくことが現実的です。

Q2. 機能比較表で両方に印がついている項目は、確認しなくてよいでしょうか

印がついていることは、似た役割の機能が存在することを示すだけです。動作するための構成要件、必要な設定作業、移行時の制約は製品ごとに異なります。自社にとって重要な機能は、印の有無ではなく、その機能が動作する条件を製品提供元の公開情報で確認し、自社の構成が条件を満たすかを見てください。本記事の観点一覧が、確認の出発点として使えます。

まとめ

Hyper-V が自社の代替候補になるかは、機能一覧では判断できません。本記事で扱った判断軸は次の七つです。

• 類似する役割の機能があっても、成立条件、構成要件、管理方法、移行制約は同一ではないこと

• 比較は、機能の有無ではなく、動作条件・設定作業・移行時の制約という三点で確認すること

• Windows Server の管理経験と Hyper-V の運用は別であり、Cluster、Network、Storage、権限、障害対応の五領域を確認すること

• 権限の設計は、移行後のセキュリティ運用と監査要件に直結すること

• 管理体系が変わると運用手順書と自動化の作り直しが発生し、その工数は見積もりに含めること

• 可用性の成立条件は、対象とする Windows Server の Version の情報で確認すること

• 周辺製品が対応していない場合、その候補は現実的に選べないこともあること

他社の判断がそのまま当てはまるわけではないため、自社の制約条件を書き出したうえで比較軸を組み立てることが出発点になります。次に行う作業としては、本記事の観点一覧と五領域の表を、自社の数字と製品名で埋めるところから始められます。

書類上の比較で残った候補は、実際に動かして確かめる工程が必要です。とくに可用性と復旧は、検証しないと分からない領域です。

自社の構成が移行先の要件を満たすか、周辺製品が対応しているか。この確認には、構成情報が整理されていることと、要件を読み解く前提知識の両方が必要です。

横河レンタ・リース株式会社では、日本ヒューレット・パッカード社の Platinum パートナーとして、仮想環境のアセスメントから設計、構築、移行、運用保守までを提供しています。現構成と移行先要件の突き合わせ、検証範囲の設計からご相談いただけます。

アセスメントサービスについてより詳しくお知りになりたい方は、以下の記事も併せてお読みください。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース