サーバー仮想化はここ10年ほど人気が高まっており、今では単に普及しているだけでなく、標準的な手法だと考える人もいます。しかし、仮想化プロジェクトの計画、実装、そして維持に関する最新のアドバイスは何でしょうか？英国ロンドンに拠点を置く4D Data Centersの創設者兼テクニカルディレクターであるDavid Barker氏と、ジョージア州とサウスカロライナ州にオフィスを構えるIntelliSystemsのパートナー兼シニアテクニカルエンジニアであるPeter Rittwage氏の2人の専門家に話を伺いました。（注：サーバー仮想化に関するこの記事は、無料のPDFダウンロードとしてご利用いただけます。）
参照: 仮想化ポリシー (Tech Pro Research)
Koblentz: 顧客アカウントの典型的な規模について説明してください。
バーカー氏：当社のクライアントは、従業員数名規模の中小企業から1,000名を超える大企業まで、規模は多岐にわたります。クライアント層は、コロケーション、パブリッククラウド、プライベートマネージドクラウドが混在しています。仮想化分野ではコロケーションが最大のシェアを占めていますが、小規模クライアントの大半は当社が運営するパブリッククラウドプラットフォームを利用しています。一方、大企業は[Microsoft] Hyper-Vや[Dell Technologies] VMwareをベースとしたプライベートマネージドクラウドプラットフォームを選択する傾向があります。
Rittwage:標準的な規模は 25 ユーザー程度ですが、300 人以上のユーザーや、数台のコンピューターだけのユーザーもいます。
Koblentz: 最近、サーバーを仮想化する際、最大の課題は何でしょうか?
バーカー氏：仮想化における最大の課題は、依然としてインフラストラクチャとアプリケーション間でのリソースの共有です。どのような観点から見ても、インフラストラクチャ内では、他のものよりも優先順位を高く設定する必要があるものがいくつかあります。
仮想化プラットフォームの設計は、競合するリソース間のバランスを取る作業です。ボトルネックは依然として存在する可能性が高いものの、アプリケーションへの影響が最小限に抑えられる場所に移動できれば理想的です。外部WANトラフィックとストレージトラフィックの両方について、ネットワークプロビジョニングを考慮する必要があります。1Gbネットワークインターフェースを備え、使用率がかなり高い物理マシン100台を、10台のハイパーバイザーノードに統合する場合、NIC数が少ないシステムで実行されるトラフィックの集中化に対応するには、ネットワークを少なくとも10Gbに増強する必要があるでしょう。既存のネットワークをそのまま新しい仮想化環境にそのまま移行できるとは限りません。
ストレージにも同様の問題が存在します。ほとんどの仮想化環境では、依然として中央ストレージアレイがプロビジョニングされており、これが仮想化システムの導入におけるボトルネックとなることがよくあります。10GBのストレージネットワークがあれば、アレイへのストレージスループットは十分に確保できると考えられますが、物理ディスクから利用可能なディスクI/Oは、アプリケーションが複数の物理サーバーに分散されている場合はそれほど問題にならないため、しばしば見落とされがちです。つまり、多数の仮想マシンからの読み取り/書き込み処理にディスクが追いつかなくなり、特にディスクI/Oに大きく依存するデータベースアプリケーションなどでは、パフォーマンスに影響が出始めます。
Rittwage: USB接続が必要なハードウェアセキュリティドングルにはまだ遭遇しますが、仮想化レイヤーを経由せずにVMゲストに接続できない場合もあります。また、仮想化を「サポート」せず、製品サポートも行わないソフトウェアベンダーに遭遇することも稀にありますが、今ではそのようなケースは少なくなっています。
参照: クラウド vs. データセンターの決定 (ZDNet 特別レポート) | レポートを PDF でダウンロード (TechRepublic)
Koblentz: 仮想化プロジェクトを計画する際に、これらの課題に対処するためのソリューションは何ですか?
Barker:ストレージ アレイ内での SSD キャッシュやクラスター化されたストレージ プラットフォームへの移行など、これらの問題の一部を軽減するのに役立つ技術的なソリューションはありますが、課題を軽減するために検討する際には、それら自体に欠点があることを考慮する必要があります。
問題を軽減する最良の方法の一つは、現在の物理サーバーの詳細なベンチマークを実施し、インフラストラクチャの仮想化方法を計画することです。ハードウェアや仮想化に関する決定を下す前に、各サーバーがWANトラフィックに使用している帯域幅、通常負荷時およびピーク負荷時のCPU/RAM使用率、そして各サーバー内で発生しているディスクI/Oの量を把握しておく必要があります。
この情報を早期に入手することで、少なくとも現在のパフォーマンスを提供し、できれば新しいチップセット、より高性能なメモリなどによってパフォーマンスが向上するようなハードウェア調達を決定できます。また、仮想化環境内での障害シナリオを適切にマッピングし、少なくとも物理ハイパーバイザー ノードの障害に対応できる予備のハイパーバイザー リソースがあることを確認することも重要です。こうすることで、実行中の仮想マシンが、そのノードで既に実行されている仮想マシンやアプリケーションのパフォーマンスに過度の影響を与えることなく、移行先のリソースを持つようになります。
参照: データセンター自動化ガイド (ZDNet 特別レポート) | レポートを PDF 形式でダウンロード (TechRepublic)
Rittwage:通常、ハードウェアキー以外の代替ライセンスソリューションが利用可能ですが、移行前にその点について知っておく必要があります。USBデバイスを仮想化するソフトウェアもあります。
Koblentz: 仮想化ソフトウェアを実際にインストール/構成/保守するときによくある間違いは何ですか?
Barker:仮想化を導入する際によくある問題は、次のようにまとめられます。
1.ノードリソースの不適切なバランス調整。これは、24コアのCPUを搭載しながらRAMを64GBしか搭載していないような状況です。仮想化環境ではRAMは仮想マシン間で共有されないため、CPUが不足するよりもずっと前にメモリが不足する可能性があります（CPUは通常、当初の計画よりも過剰にサブスクライブされますが、目安としては物理コア1つに対して仮想コア4つ、つまり1:4の割合で割り当てられます）。
2.ストレージと要件の不一致。CPUよりもディスクサイズを適切に設定することの方がおそらく重要です。ストレージコストはCPUコアのプロビジョニングに比べて急速に増大します。10Gb iSCSIは非常に高速ですが、回転式ディスクは実際には非常に遅いことに注意してください。高トランザクションのデータベースを多数仮想化しようとする場合、大量のディスクI/Oが必要になり、15Kディスクの大規模なアレイが必要になる可能性があります。
3.ネットワークと仮想スイッチが多すぎる。仮想化環境では、各ゲスト仮想マシン用のvLANと、各vLANにハイパーバイザーノードの管理IPアドレスを持つネットワークが多数存在することがよくあります。これは通常必須ではなく（管理IPアドレスはゲスト仮想マシンと同じネットワークに存在する必要はありません）、プラットフォーム管理の複雑さを増すだけです。そのようなレベルのネットワーク分離が特に必要な場合を除き、ネットワーク数を最小限に抑え、アクセスリストまたはファイアウォールルールを使用してネットワーク上の仮想マシン分離を管理してください。
4. 同様に、仮想スイッチが多すぎるという問題もよくあります。環境内に多数のvLANが必要な場合は、通常、vLANごとに個別の仮想スイッチは必要ありません。vLAN/仮想スイッチを適切に設計すれば、ほとんどのユースケースで十分なネットワーク分離が実現できます。
Rittwage: vCPU、RAM、ストレージの設定ミスはよくあることです。私が修正しなければならない問題の多くは、管理者が共有ストレージを過剰に割り当ててしまったことに起因しています。最初は容量をあまり取らない大きなダイナミックドライブを構成することも可能ですが、制御不能な状態に陥ると、適切な計画なしにすべてのゲストVMの容量が不足する可能性があります。また、すべてのサーバーを統合することでネットワークに危険な単一障害点が生じないよう、ハードウェアの品質と安定性にも細心の注意を払う必要があります。常に冗長化されたハードウェアを用意してください。
Koblentz: 2008 年や 2013 年に何かを行う最善の方法が、必ずしも 2018 年に同じことを行う最善の方法であるとは限りません。仮想化の初期のトレンドのうち、消え去ったものは何でしょうか?
Barker:仮想化の基本原理は、VMware が 1999 年にワークステーション製品を導入し、2001 年に ESX を導入したときから変わっていません。特に、パフォーマンスが向上し、ストレージに対する需要が増加しました。
おそらく最も大きな変化は、仮想化管理、ネットワーク、そして仮想マシンの移行の分野でしょう。初期の仮想マシンは非常に静的な傾向がありました。物理サーバーを仮想化し、そのサーバー内で複数の仮想マシンを稼働させていましたが、それらはどこにも移動しませんでした。そして、物理サーバーに障害が発生すると、そのサーバー上のすべての仮想マシンも停止していました。vMotionなどの製品の導入により、この問題は解消され、障害発生時に物理サーバー間で仮想マシンを容易に移行できる、大規模なハイパーバイザークラスターが実現しました。これはVMwareのvMotionとHyper-Vs Replicaによってさらに進化し、物理的に離れた場所にある別々のクラスターに仮想マシンをほぼリアルタイムで複製することで、クラスター全体の障害リスクに対処できるようになりました。
Rittwage:かつてのストレージ仮想化ははるかに遅く、仮想マシンに割り当てられたRAWドライブパーティションやドライブが目立っていました。しかし、今ではそのようなことはなく、必要もありません。ローカル仮想ストレージへのペナルティはほとんど、あるいは全くありません。
コブレンツ：（現時点で）将来に関する懸念のうち、根拠がないと判明したものは何ですか？逆に、過小評価されていたものは何ですか？
Barker:最も大きな懸念は、仮想化のセキュリティと、同一の物理インフラ内で複数の仮想マシンを稼働させるリスクに関するものでしたが、どちらも杞憂に終わりました。最近、CPUアーキテクチャにおけるSpectreとMeltdownの脆弱性が明らかになり、こうした懸念の一部が再燃しましたが、パッチはすぐにリリースされ、この脆弱性を悪用するにはシステム自体へのルートアクセスまたは管理者アクセスが必要でした（攻撃者がプライベートクラウドへのアクセス権を持っている場合、問題ははるかに深刻です）。一般的に、リソースの分離と仮想マシンの分離は完全に安全であることが分かっており、問題が発生するのは、展開時にこれらが適切に構成されていない場合です。ネットワークの分離とストレージの分離（必要な場合）を備えた適切に設計された仮想環境は非常に安全です。
Rittwage : ハイパーバイザーを攻撃するマルウェアやウイルスについては常に話題になっていますが、私はまだ見たことがありません。そのようなものをプログラムするのは非常に難しいのではないかと思います。
Koblentz: どのような状況で、大手の仮想化製品ではなく、マイナーな仮想化製品やアプリケーション固有の仮想化製品を選択すべきでしょうか?
Barker: 99 パーセントの使用ケースでは、Hyper-V、VMware、または KVM/Xen を使用した仮想化が最適な方法になります。その決定は、これらのプラットフォームを管理するためのスキルと、ライセンス費用 (KVM/Xen から Hyper-V、そして最も高価な VMware まで範囲が広がります) を支払う意欲によって決まります。
VMware には優れた管理ツールがあり、ハードウェア仮想化の提供において実績がありますが、特に大規模な導入をまとめる場合には、比較的高額になります。
主にWindows環境で、ゲストマシンのほとんどがWindows Serverで稼働している場合は、Hyper-V環境が適している可能性があります。Windows Data CentreエディションまたはWindows Server Hyper-V Coreを使用して適切に導入すれば、ライセンスコストを削減でき、管理インターフェースもユーザーにとって使い慣れたものになります。
参照: Microsoft の最新の Windows Server 2019 テストビルドには、Hyper-V 2019 の最初のプレビューが含まれています (ZDNet)
KVMとXenはどちらも優れたオープンソースのハイパーバイザープラットフォームですが、管理インターフェースが不足しています。OpenStack環境の導入やOnAppなどのフロントエンドの利用といった選択肢はありますが、これらのツールやオープンソースソフトウェア全般の使用経験がない場合、設計が複雑になる場合があります。
Rittwage:重要なビジネス ロールのために専攻以外で何かを導入するかどうかはわかりませんが、製品の練習や学習、または一時的な障害復旧の状況では、VirtualBox が使用されているのを見たことがあります。
Koblentz: どのような状況でサーバーを仮想化しないことを選択すべきでしょうか?
Barker:ほとんどのワークロードは仮想化できますが、CPU/RAM使用率が特に高いアプリケーションやディスクI/O負荷の高いアプリケーションがある場合は、より広範な仮想化環境内でスタンドアロンサーバーとして運用する方が効果的です。また、物理サーバーをハイパーバイザーとして展開し、その上で単一の仮想マシンのみを実行することも可能で、これは仮想化環境がもたらす管理と移行のメリットを維持しながら、必要なリソースをアプリケーションが確実に利用できるようにするための優れた方法です。
参照：写真：サーバールームの現実世界の悪夢（TechRepublic）
同様に、レガシーアプリケーションを仮想環境に導入する際には問題が生じる可能性があります。仮想CPUや仮想NICは物理ハードウェア自体と通信するように設計されているため、すべてのアプリケーションが仮想CPUや仮想NICとスムーズに連携できるとは限りません。仮想化市場の成熟に伴い、これらのアプリケーションは時間の経過とともに減少し、懸念事項も少なくなっています。
Rittwage:一般的に、高CPU負荷または高IOP負荷の特定の機能（例えば、高負荷のSQLサーバー）にすべてのリソースを使用する予定であれば、その機能を仮想化する理由はほとんどありません。仮想化とは、基盤となるハードウェアを他のタスクと共有することです。
Koblentz: 今後 5 年を見据えて、仮想化において、まだほとんどの人が認識していない新たな課題や懸念事項は何だとお考えですか。
Barker:主に、ハイパーバイザー ノード間で定期的に移行されるワークロードと仮想マシンをサポートするために、物理ネットワーク ハードウェア上でのネットワーク仮想化への移行が進むのではないかと考えています。また、仮想インフラストラクチャをサポートする物理ネットワーク インフラストラクチャが SDN、スクリプト、および vxLAN 用に適切に設計されていることを確認することも必要になるでしょう。
もう一つの分野は、仮想マシン内でのコンテナ化の利用が継続的に増加することです。DockerやKubernetesといった製品は、仮想マシン自体内でOSとアプリケーションの仮想化を実現します。適切なユースケースでは、これは導入のスピード、環境の一貫性、そして仮想マシン間でのアプリケーションワークロードの即時移行といった大きなメリットをもたらします。
Rittwage:現時点ではかなり成熟しているので、今後 5 年間でどのような新たな課題が現れるかどうかはわかりません。
Koblentz: 一般的に、サーバー仮想化プロジェクトの実装と保守の担当者に他に何かアドバイスはありますか?
Barker:成長を見据えた計画を立てましょう。設計フェーズでは、既存環境のベンチマークを実施した後、新しいハイパーバイザーや追加ストレージを導入してプラットフォームを拡張する方法について、環境への影響を最小限に抑えながら計画することが大切です。仮想化環境では、より高い可用性が求められます。初期構築時にはスイッチポートが不足していたため、プラットフォーム全体を再設計することなく、ディスクセットを追加したり、ハイパーバイザーを4つ追加したりできる必要があります。
また、適切なバックアップ戦略を確実に維持しておくことも重要です。現在はすべてが仮想化されており、インフラの物理コンポーネントの障害に対する耐性は大幅に向上していると思われますが、それでも問題は発生します。すべてを仮想化することで、仮想マシンのスナップショットや[バックアップアプライアンス]などのテクノロジーを活用した、他のバックアップ戦略が可能になります。これらの技術により、すべてが個別のサーバー上に存在していたときよりも、バックアップの取得、管理、そして復元がはるかに容易になります。
Rittwage氏：パフォーマンス、成長、冗長性を考慮した計画を立てましょう。高価なサーバーは5年以上使い続けられると期待されています。多くの企業で仮想化への移行を成功させてきたコンサルタントを活用しましょう。
画像: デイビッド・マクドナルド、ゲッティイメージズ/iStockphoto
