Microsoft Hyper-Vマネジメント:絶対避けるべき15のミス


仮想化の技術とはかなり複雑なもので、Microsoft Hyper-Vの管理も多分に漏れません。頭を痛めているシステム管理者も多いのではないでしょうか。

本稿では、Microsoft Hyper-V環境を管理する上で、誰もが犯しがちな15のミスを検証していきます。それは、同時に、Hyper-Vマネジメントを劇的に改善させる最適化のヒントにもなるはずです。

その1:メモリーとCPUの不均衡

仮想マシン(VM)のシステム要件はそのリソース許容量を超えていることがほとんどで、メモリーリソースがCPUよりもずっと先に不足することは予想に難くありません。RAMが64GBだけの24コアCPUボックスを使うのは、避けたほうが得策です。理由は単に、メモリーを1つのVMから他のVMに転送できないからです。それに対し、CPUリソースは共有が可能なので、諸々のVMからのロード管理を複数コアに任せることができます。仮想環境で必要となる処理能力をあらかじめ把握するには、パフォーマンスモニタートレースを利用し、専門家のアドバイスを聞き、ベンチマークの資料を参照するしかありません。Microsoftは1つの物理コアにつき仮想CPUは12コア以下にするよう推奨しているので、その点も覚えておきましょう。

その2:ストレージの処理能力に対するネットワークスループット超過

ストレージ処理速度の要件を、実際のシステムパフォーマンスに対して読み違えることによる一般的なミスです。RAID-10が現在利用可能な最速RAIDであると有識者には言われています。そのため、RAID-10アレイを8ディスク構成にして、フル稼働で10GbEのデュアルポートアダプタに接続するのが一般的になっています。これでも悪くはないのですが、10GbEの両ポートに無駄が著しく、設定のミスにつながりやすい欠点があります。

代わりに、CPUに対する適正なディスクサイズを徹底したほうが得策です。ストレージのコストはあっと言う間に膨らむものです。実際のI/O要件を丁寧に見積もり、それでも不確かなら、毎分数百件のトランザクションを実行するデータベースは他のアプリケーションとは比較にならないほど高いI/Oスループットを要する点に留意してください。ディスク要件を合計すれば、相当なものになるはずですが、平均30 IOPSのロードを処理するVMが14台あれば、15,000 RPMで動く4ディスクをオーバーワークさせるようなことはまずないでしょう。

その3:SSDと回転ディスクの不均衡

インフラストラクチャのパフォーマンスを考慮するのであれば、複数の仮想マシン(VM)に個々に異なるアクセスを行う環境では、ソリッドステートドライブ(SSD)を使うのが賢明な選択でしょう。しかし、適切に使用されないと意味がありません。Hyper-Vサーバーが直接SSDにインストールされた仮想環境では、SSDが回転ディスクを猛稼働させるかもしれません。ディスクI/Oの大部分を使うのはVMです。SSDの高スピードと低レイテンシは、VMデータの処理にこそ有効利用すべきでしょう。

その4:ネットワークリソースの不均衡

スタンドアロンのHyper-Vホストをネットワークカード2枚で構築し、1つのNiCをOS管理専用にして、もう1つで全VMをまかなう構成が、かつて標準仕様と考えられていました。また、この構成は、2008 R2やそれ以前のリリースでは、サポートの対象外になるのを防ぐためには必須でした。しかし、ネイティブなNiCチーミングが可能となった今日では、より良い選択肢が増えています。

1つか2つの物理アダプタをVM専用にし、他の物理アダプタをCSVトラフィック専用にする構成も、かつて一般的でしたが、もはや不要になっています。2012 R2以降、クラスタ通信の帯域幅を適正に保つ限り、専用のCSVネットワークは必要とされません。

その5:リソース割り当ての誤り

すべての処理を固定のHyper-V仮想ハードディスク(VHDX)でまかなおうとする構成も、よくある間違いの1つです。VHDXは処理速度が高く、ストレージを予定外にオーバープロビジョニングしてしまうことも防げますが、無駄も大きいのではないでしょうか。例えば、下記のような単純計算でもオーバープロビジョニングにはならず、さらに豊富なディスクスペースを回復することも可能になります。

個々の仮想マシン(VM)をゲストOSのC:ドライブに、その他のVHDXファイルはデータに対して割り当てれば、C:ドライブは万全です。それぞれを60GBに設定すれば、永続的に40GB以下で済む可能性が非常に高いです。仮に20のVMがあるとすれば、少なくとも400GBがセーブされます。それでも固定VHDXを使うなら、最低400GBのディスクスペースが無駄になることを見越すべきでしょう。

これはあくまで一例に過ぎませんが、同様の理論が仮想環境を構築する際、様々な局面に当てはまるはずです。慎重に計画し、ボトルネックとなり得るのはどこなのかを見極め、それを排除することを第一に考えるべきです。

その6:ネットワークと仮想アダプタの作り過ぎ

スタンドアロンのHyper-Vシステムでは、管理用のOSを単一IPの単一ネットワークに置く場合がほとんどです。IPにはDNSを設定し、名前で接続できるようにしましょう。このIPは異なるサブネットやVLANにも設定できるので、注意してください。管理OSのIPをゲストが使う個々のVLANまたはサブネットに設定しないように気を付けてください。さらに、ゲストのトラフィックは管理OSを経由しないので、仮想マシンのトラフィックに対して仮想アダプタを作る必要もありません。

その7:むやみにページファイルを最適化する

ページファイルは、各種アプリケーションが通常OS内に有効な物理メモリー以上のメモリーにアクセスすることを可能にします。アプリケーションがメモリーを過剰に消費し、システムがRAM不足に陥ったとき、Windowsは自動的にメモリーを、使用頻度のもっとも低い部分から隠れたページファイルに移して、アプリケーションが実際に必要とするメモリーを空けるしくみになっています。

最小アプリケーションからページファイルにメモリーを移すと、ハードドライブに軋轢が生じ、種々の問題につながる可能性があります。ページファイルは最適化するよりも、むしろ無効にするべきです。RAMの処理速度はハードドライブよりずっと上なので、そのほうが合理的です。ページファイルを無効にすると、Windowsはすべてを常時、より高速なRAMに処理させようとします。ハイパーバイザーのページファイルにはほとんど用途がなく、適切なスペースの割り当てのみ必要な点にも留意してください。

その8:動的メモリーを活用しない

SQLとExchangeサーバーで動的メモリーを使用することに否定的な専門家もいますが、それに怯む必要はありません。Dynamic Memoryはいつでも再調整できるので、最大・最小サイズを控えめに設定することをお薦めします。ただし、Dynamic Memoryの最小サイズを減らし、最大サイズを増やすと、ゲスト稼働中に固定メモリーを修正できない点には気を付けてください。

その9:VM構成の初期設定を盲目的に受け入れる

仮想マシン(VM)をウィザードで作成すると、vCPUは1つだけなので注意が必要です。ゲストOSがWindows XP/Server 2003より新しいバージョンの場合、vCPUは少なくとも2つは欲しいところです。動的メモリーを有効にすると、最大値は1TBに初期設定されますが、実際にはそんなに必要ないはずです。そもそも物理メモリーが1TBないので、サポートされません。前述の通り、メモリー使用の最大値はいつでも増やすことができますが、メモリーを減らす場合、ゲストを終了させなければなりません。このばかでかい初期設定値をそのまま使用すると、ホストが他のゲストへ自動的に割り当て調整する機能が阻害される危険があります。

その10:管理オペレーティングシステムの過負荷

管理オペレーティングシステム(OS)は、仮想マシン(VM)、バックアップソフトウェア、マルウェア対策のセキュリティツールのみに使用し、マネジメントボックスにそれ以外のものを含めるべきではありません。つまり、VMではないもの、VMのバックアップや保護を目的としないものは、VM内で稼働すべきです。仮想環境をそのように構成すれば、処理速度と効率の向上のみならず、問題解決(トラブルシューティング)が円滑になります。

その11:ホストをドメインに加えない

特別な理由がない限り、Hyper-Vホストを境界ネットワークに置くのは薦められません。ドメインが使えるのなら、ホストはドメインに置くべきです。ホストをワークグループに置くべきではありません。考えてもみてください。ホストをワークグループに残せば、セキュリティリスクが高まり、そのリスクに晒されたワークグループは、すなわちドメインが侵害されるのと同じ危機的状況を生みます。攻撃者にしてみれば、ホストに侵入できれば、すべてのVHDXゲストファイルにアクセスできるのですから。

その12:テスト不足

適切なテストを怠る傾向は、大変嘆かわしい、多くの企業に蔓延する深刻な落とし穴です。よく知られたハードウェアや使い慣れた構成は必ず連携して正しく機能するはず、という誤った前提に端を発している場合が多いです。これは何度強調してもし過ぎることはありません。実用化する前に、綿密に計画し、慎重に設定配備し、充分テストすること。その手順の1つでも怠れば、運用過程で問題が膨れ上がっていきます。

その13:PowerShellを毛嫌いする

気持ちはわかります。PowerShellは独自のコマンドラインと独特のプログラミング言語を使わなければならず、学習に時間かかります。しかし、PowerShellを使用すれば、多くの管理タスクが同時進行で自動化・実行でき、幅広い機能性がもたらされます。PowerShellによって、ユーザーは以下のツールを利用することができます。

  • コマンドプロンプト
  • PowerShellコマンド
  • .NET Framework API
  • Windows Management Instrumentation(WMI)
  • Windows Component Object Model(COM)

オープンソースのアプリケーションであるPowerShellでは、LinuxやUnixユーザーがスクリプトやコマンドを自動化して、冗長な管理ジョブを単純化することも可能になります。

その14:ライセンスのしくみを理解しない

Microsoftライセンスのしくみを理解するのは決して簡単ではありませんが、財務および法務上のリスクを回避するために、とても重要なことです。ルールをきちんと理解していないと、コンプライアンス上の各種問題を誘引し、組織内でもIT部門と購入担当の部門間での相互不理解につながります。

独自に調べて、自分なりにライセンスの知識を完璧にすることはできますが、所属する会社の特定要件に沿ったライセンス管理プログラムに参加することを強く推奨します。

その15:アンチウィルスのベストプラクティスを実践しない

WindowsサーバーをCore版で起動し、管理OSへのアクセスを慎重に制御すれば、ホストの安全は保たれる、と考える管理者は少なくありません。それがセキュリティ対策として充分な会社もあるでしょうが、多くの企業では業界特有のルールや規制に縛られ、仮想ホストを含むすべてのエンドポイントにアンチウィルス保護を導入することが厳格な要件になっています。

もちろん、Hyper-Vホストにアンチウィルスを走らせることは可能ですが、構成を誤るとパフォーマンスが損なわれ、一連のVMをダウンさせる可能性もあります。Hyper-Vホストにアンチウィルスを設置するなら、特に慎重な構成が必要になります。

以上で紹介してきた様々な問題は、いずれもVeeam EssentialsClimb Cloud Backup & Securityのような適切なマネジメントソリューションによって回避することができます。30日間無償トライアルをダウンロードして、仮想インフラストラクチャの各種課題をいかに解決するか、体験してみてください。

関連トピックス

Microsoft Hyper-Vマネジメント:絶対避けるべき15のミス への2件のフィードバック

  1. climb のコメント:

    中小規模向けのHyper-V/VMware環境統合ソリューションのVeeam Essentials:
    https://www.climb.co.jp/soft/veeam/essentials/

  2. climb のコメント:

    Microsoftパートナーのクライムが提供するAzure対応ソリューション:
    https://www.climb.co.jp/soft/azure/
    ●Azureに仮想マシンを簡単移行/災害対策
    ●オンプレミスDBをAzureへ簡単に移行、連携
    ●データを簡単にAzureへバックアップ
    ●Azure上で実行されるワークロードの保護を簡単構成
    ●Azure仮想マシンを暗号化、クラウドでもVMを安全に利用
    ●Azure上でのVDI利用をもっと簡単に

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください