(1)統合率にフォーカスし過ぎ
仮想マシン(VM)/サーバの数値でサーバ統合の統合率として測ります。統合率は物理サーバの許容量と仮想化したいワークロードのタイプに依存します。高い統合率は可能ですが、それがビジネス的にベストとは限りません。高い統合率はサーバに加重負担をかけ、災害時における故障サーバからのワークロードのリスタートを困難にします。最後に理想的なサーバ統合率の特定はバランスを取ることです。
(2)荷重統合
統合時にユーザは多くの利点があります。サーバ故障時に予備の容量が充分でないレベルまで統合率を増加させることは新規サーバまたは修理するプロビジョンを混乱させます。荷重統合はユーザのVMのマイグレーションとワークロードのバランス能力を制限するものです。またそれは限られたリソースでのVMの競合が減速原因のアプリケーション・パフォーマンスに悪影響します。
(3)統合率に対する無関心
一般的に企業は本番環境とミッション・クリティカルなワークロードに移行する前にテストと開発システムで段階アプローチから仮想化をスタートさせます。もし仮想化を最初のステップで、手に余るサーバを仮想化した時にはサーバ仮想化計画を再評価することは不可能で、失敗に終わります。統合レベルを増加させるもっとも単純な手法は古いサーバをもっとワークロードを処理できる新規で高容量のサーバにリプレースすることです。もし準備不足で、サーバを完全にリプレースする十分な予算が無ければ、最も大きな問題を起こす可能性があるメモリーのアップグレードを考えるべきです。もしまったく予算が無ければ、VMのリソース・アロケーション・レベルを再評価し、制限の設定は新たなVMを追加するために十分なリソースを解放することができます。
(4)VMスプロール（不規則性）への対応の遅れ
VMスプロールの管理の方策が無く、仮想化へジャンプ・スタートした時には、直ぐに問題に直面します。多くのユーザがVMスプロールの犠牲に陥る理由はそれが大きな問題として現れるまで、静かに何か月、何年も有することです。VMのライフサイクル管理を初期のサーバ統合プランの一部として扱うことで、スプロールが起こる前に問題を回避することができます。
(5)ファイルオーバ、マイグレーションの必要性の配慮不足
サーバ統合計画の設計には2つの基本的なアプローチがあります。各サーバーでの予備容量を残す。またはファイルオーバ、マイグレーションの必要な時用の予備のサーバをスタンバイさせる。どちらのアプローチも可能ですが、それはどのようなファイルオーバ、マイグレーションが必要かに起因します。各サーバーでの予備容量を持つアプローチは新規システムをオンラインにすることなく、リスース使用をバランスさせ、サーバをアップデートするためにワークロードをライブ・マイグレードする柔軟性を持っています。しかしファイルオーバのニーズのために統合化を最大限にして予備機を準備することはより良いリソースの利用になります。またサーバ統合計画を計画する時にワークロードを考慮する必要があります。非常に負荷のあるアプリケーションでは稼働するサーバの使用されていないパーセンテージを大きくするより、予備のサーバをスタンバイさせる方が理にかなっています。
ソース：SearchServerVirtualization
RSSフィードを取得する
ピンバック: VMware/Hyper-V対応ツール 技術ブログ