VMware環境の見直しでは、主に二つの判断が発生します。
一つめは、仮想マシンを動かすハイパーバイザーを何にするかというソフトウェアの選択です。必要な機能、可用性を成立させる条件、管理方法、移行方式、担当者のスキルなどを確認します。
二つめは、サーバーとストレージをどのように構成するかというインフラ構成方式の選択です。サーバーと外部ストレージを分けた構成を継続するか、コンピュートとストレージをまとめたHCIを採用するかを検討します。
|
判断区分 |
主な確認内容 |
|
ハイパーバイザーの選択 |
必要な機能、可用性の成立条件、管理方法、移行方式、運用スキル |
|
インフラ構成方式の選択 |
既存ストレージの扱い、拡張単位、障害時の影響、ハードウェア構成 |
|
周辺条件の確認 |
バックアップ、モニタリング、ネットワーク、契約、保守窓口、運用体制 |
この切り分けをしないまま比較表を作ると、ハイパーバイザーの機能とインフラ構成の違いが同じ表に混在します。可用性に関するソフトウェア機能の評価と、ノード障害時にどの範囲へ影響が及ぶかというインフラ構成上の評価は、分けて記載する必要があります。
HCIを検討する場合は、次の順序で整理します。
ハイパーバイザーに求める条件を確認する
現行のハードウェアとストレージをどう扱うか決める
インフラ構成方式を比較する
バックアップ、モニタリング、契約、保守を確認する
書類では判断できない項目をPoCで確認する
なお、仮想化ソフトウェア、Private Cloud offering、HCI solutionは、それぞれ位置付けが異なります。個別製品を検討する場合は、ソフトウェアの選択、インフラ構成方式、対象バージョンの要件を分けて確認してください。本記事では個別製品の要件や優劣には踏み込まず、HCIという構成方式を候補に含めるための判断項目に絞ります。
Hyper-VとVMwareを比較｜機能差より先に確認したい運用・移行条件
ハイパーバイザー候補としてHyper-Vを確認する場合は、機能名の有無だけでなく、可用性、運用スキル、移行方式、周辺製品の条件を確認します。
HCIを検討する出発点は、構成をまとめることではありません。最初に確認したいのは、現在の構成で何が課題になっており、その課題をインフラ構成方式の変更によって解決できるかです。
仮想化ソフトウェアに関する費用を見直したい
ハードウェアやストレージの更新時期が近い
障害発生時の切り分けに時間がかかる
サーバーとストレージの管理を整理したい
将来の増設方法を明確にしたい
運用が特定の担当者に依存している
バックアップやモニタリングを含めて運用を見直したい
仮想化ソフトウェアの契約や費用が主な課題であれば、インフラ構成を変更せず、ハイパーバイザーのみを見直す選択肢もあります。一方、ハードウェアとストレージの更新時期が近く、障害対応や運用方法も同時に見直したい場合は、HCIを含めてインフラ構成方式を比較する余地があります。
検討を始める前に、少なくとも次の情報を整理しましょう。
既存ストレージの製品、構成、使用状況
ハードウェアとストレージの保守終了時期
コンピュートとストレージ容量の使用状況
今後追加する可能性があるワークロード
障害発生時の一次対応と問い合わせ先
使用しているバックアップ・モニタリング製品
運用手順と担当者のスキル
ソフトウェア、ハードウェア、保守サービスの契約先
この整理が不十分なままでは、HCIが自社の課題を解決できるか判断できません。移行時期そのものをまだ決めていない場合は、HCIを比較する前に、契約更新、ハードウェア保守、予算、移行に必要な期間から着手時期を整理します。
VMware移行はいつ始めるべきか｜今すぐ動く環境・待てる環境の判断基準
契約更新、ハードウェア保守、予算、繁忙期などを踏まえ、移行検討に着手すべき時期を整理します。
現在使用しているストレージを継続利用するか、インフラとあわせて見直すかを確認します。既存ストレージを更新したばかりの場合、HCIへの移行によって、その資産の役割が変わる可能性があります。
確認する項目は次のとおりです。
製品と構成
使用容量と空き容量
パフォーマンス上の要件
保守終了時期
接続しているサーバーやワークロード
バックアップやレプリケーションとの関係
移行後も継続利用する用途の有無
既存ストレージを継続利用できるかだけでなく、継続利用することが運用上適切かも確認します。想定例として、ストレージを更新した直後にVMware移行を検討する状況では、HCIへの全面移行だけを前提にせず、既存ストレージを活用する構成も比較対象に残します。
HCIでは、採用する製品や構成によって、ノード単位で拡張する方式があります。コンピュートだけ、またはストレージ容量だけを追加したいときに、必要量と追加単位が一致するとは限りません。
確認する項目は次のとおりです。
コンピュートの将来需要
ストレージ容量の将来需要
ワークロードを追加する予定
候補構成の追加単位
増設時に必要なライセンスと保守契約
増設時の停止や構成変更
設置スペース、電源、ネットワークポート
ストレージ容量だけが増える見込みであれば、ノードの追加によってコンピュートも増える構成が自社に適しているかを確認します。
各ノードがコンピュートとストレージの役割を担う構成では、ノード停止時に仮想マシン、ストレージ、ネットワーク、管理機能へどのような影響が生じるかを確認します。
確認する項目は次のとおりです。
ノード停止時の仮想マシンの動作
残りのノードで必要なワークロードを稼働できるか
ストレージの冗長性
障害発生中に許容できる追加障害
復旧時に必要な操作
障害箇所の切り分け担当
業務側が許容できる停止時間
可用性設計に矛盾がないか
可用性機能があることと、自社の構成で想定どおりに動くことは同じではありません。成立条件と対応手順まで確認し、書類だけでは判断できない場合はPoCの確認項目に含めます。
HCIを採用すると、日常の管理方法や障害発生時の確認手順が変わる場合があります。コンピュートとストレージを一つの管理体系から扱えても、ネットワーク、バックアップ、モニタリング、ハードウェア保守まで一つにまとまるとは限りません。
確認する項目は次のとおりです。
仮想マシンの作成と変更
リソースとストレージ容量の確認
アラートの確認
管理者権限の設定
ソフトウェアとファームウェアの更新
バックアップの取得と復元
障害発生時の切り分け
手順書の更新範囲
担当者の教育範囲
管理画面の集約だけで「運用が容易になる」と判断せず、削減できる作業と新たに発生する作業の両方を確認します。
管理画面が集約される場合でも、契約や問い合わせ窓口まで一つになるとは限りません。
確認する項目は次のとおりです。
契約対象と契約先
契約期間と更新時期
保守対象
問い合わせ窓口と対応時間
一次切り分けの担当
製品間の問題が疑われる場合の対応範囲
構成変更時に必要な手続き
問い合わせ先の数だけでなく、障害発生時に誰が最初に状況を確認し、どの段階から外部へ問い合わせるかを決めておくことが重要です。
見直さない場合：現行インフラを活用し、ハイパーバイザーのみを変更する案も比較します。
見直す場合：ステップ 2へ進みます。
継続利用する場合：既存ストレージを活用できる構成も比較対象に残します。
継続利用しない場合、またはストレージの更新時期が近い場合：ステップ 3へ進みます。
追加単位に合う場合：ステップ 4へ進みます。
合わない場合、または将来需要が不明な場合：増設時の構成・費用を追加確認します。
説明できる場合：ステップ 5へ進みます。
説明できない場合：候補を確定せず、設計確認またはPoCの対象にします。
確認できている場合：HCIをPoC候補に残します。
確認できていない場合：製品候補の確定を保留し、対応可否と責任範囲を確認します。
|
判断結果 |
次に行うこと |
|
HCIを候補に残す |
書類で判断できない項目をPoCで確認する |
|
不明点を追加確認する |
確認先、担当者、期限を決める |
|
ほかの構成も比較する |
既存ストレージを活用する構成などを比較対象に残す |
HCIを採用しないことは、検討不足を意味しません。既存資産、拡張計画、障害時の影響、運用体制を踏まえ、現在の構成方式を継続する判断も選択肢になります。
構成情報、製品資料、保守条件を確認しても、実際の運用や障害時の挙動を判断できない項目があります。HCIを候補に残した場合は、書類では確認できない項目をPoCへ回します。
|
区分 |
主な確認内容 |
|
運用 |
日常操作、権限、手順書の変更範囲 |
|
障害時の挙動 |
ノード停止時の動作、再稼働、障害切り分け |
|
復旧 |
バックアップ取得、復元単位、復旧方法 |
|
周辺連携 |
モニタリング、アラート通知、既存運用ツールとの連携 |
PoCを開始する前に、本番環境との差分と合否基準を決めます。「環境を構築できた」「仮想マシンが起動した」という結果だけでは、移行後に運用を継続できるか判断できません。PoCで確認できなかった項目は「未確認」として記録し、追加確認または運用設計の対象にします。
VMware代替の検証はこれで解決！「オールインワン PoCメニュー」で始めるVM Essentials導入ガイド
VM Essentialsを具体的な候補として検討している場合は、検証環境の用意や確認項目、PoC支援の進め方を紹介した記事も参考にしてください。
以下の項目を「確認済み」「未確認」「該当なし」に分けます。
|
確認項目 |
確認済み |
未確認 |
該当なし |
|
既存ストレージの構成と保守終了時期を把握している |
□ |
□ |
□ |
|
既存ストレージを移行後も継続利用するか決めている |
□ |
□ |
□ |
|
コンピュートの将来需要を把握している |
□ |
□ |
□ |
|
ストレージ容量の将来需要を把握している |
□ |
□ |
□ |
|
候補構成の追加単位を確認している |
□ |
□ |
□ |
|
ノード障害時の影響範囲を説明できる |
□ |
□ |
□ |
|
業務側が許容できる停止時間を確認している |
□ |
□ |
□ |
|
バックアップ・モニタリングの対応可否を確認している |
□ |
□ |
□ |
|
契約先、保守窓口、一次切り分けの担当を確認している |
□ |
□ |
□ |
|
PoCで確認する項目と合否基準を整理できる |
□ |
□ |
□ |
「未確認」がある場合でも、直ちにHCIを候補から外す必要はありません。未確認項目について、確認先、担当者、期限を整理します。特に、既存ストレージ、障害時の影響、バックアップ・モニタリング、契約・保守が未確認の場合は、製品候補の確定を保留します。
HCIはインフラ構成方式を示すため、HCIの採用判断とハイパーバイザーの選択は分けて確認します。ただし、製品やサービスによって、利用できるハイパーバイザーや対応構成に条件があります。候補ごとに対象バージョン、ハードウェア、ストレージ、ネットワークの条件を確認してください。
採用する製品と構成によって異なります。接続可否だけでなく、保守期間、使用状況、パフォーマンス、障害発生時のサポート範囲を含めて確認します。
日常の管理手順、ノード障害時の挙動、バックアップからの復旧、モニタリング連携を確認します。PoC開始前に本番環境との差分と合否基準を決め、確認できなかった項目は「未確認」として記録します。
HCIは、VMwareと直接置き換える同分類の製品ではありません。ハイパーバイザーを何にするかというソフトウェアの選択と、サーバーやストレージをどのように組み合わせるかというインフラ構成方式の選択を分けて考えます。
HCIを候補に含める場合は、次の5つを確認します。
既存ストレージを継続利用するか
コンピュートとストレージの拡張単位が将来計画に合うか
ノード障害時の影響範囲を許容できるか
運用・監視方法の変更を現在の体制で吸収できるか
契約・保守の責任範囲を整理できるか
重要なのは、構成を集約すること自体ではなく、その変更が現在の課題の解決につながるかです。HCIを候補に残しPoCへ進む、不明点を追加確認する、既存ストレージを活用する構成などほかの選択肢も比較する、のいずれかを判断します。
チェックリストに未確認項目があり、確認先や進め方を決められない場合は、製品候補を確定する前に、現状環境と構成条件を整理する方法があります。
横河レンタ・リースでは、現状環境、既存構成、関連する契約情報について、整理の進め方をご相談いただけます。製品を決める前に、自社で確認すべき項目を明確にしたい場合はお問い合わせください。