BE6000 の導入には、vCPU と物理コアの 1 対 1 の割り当てがなければなりません。たとえば、16 の物理コアを搭載したホストがある場合、組み合わせの要件である 16 以下の vCPU を持つ仮想マシンの任意の組み合わせを導入できます。ESXi 5.0 および 5.1 において、1 つ以上の仮想マシンで Cisco Unity Connection を実行している場合は特別なケースになります。この場合、vCPU の合計数は物理コアの合計数から 1 を引いた数である必要があります。ESXi5.5 を使用するサーバの場合、高の遅延感度を使用するように Cisco Unity Connection 仮想マシンを設定することができます。この場合、少なくとも 1 つの他の仮想マシンで遅延感度が標準に設定されている場合は、vCPU の合計数は物理コアの合計数と同じにできます。

vCPU の数は物理コアの数を超えることはできないので、CPU 予約または制限を設定する必要はありません。物理コアをオーバーコミットすることはできません。

（注）	一部のプロセッサはハイパースレッディングをサポートします。これにより、ハイパーバイザが物理コアを 2 つの論理プロセッサとして認識できるようになります。論理プロセッサは共存の計画には使用できません。

詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html の「No Hardware Oversubscription」セクションを参照してください。

メモリのオーバーサブスクリプションがないようにするには、vRAM の設定と同等の物理メモリの予約を使用してすべての共存仮想マシンを設定します。たとえば、仮想マシンが 4 GB の vRAM で設定されている場合、4 GB の物理メモリの予約を割り当てます。

BE6000 または BE7000 アプライアンスの仮想化ソフトウェアに、仮想マシンをホストおよび実行するための追加の物理メモリが必要です。必要なメモリの容量については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-sizing.html#generalrulememory [英語] を参照してください。

（注）	ESXi ホストによるオーバーヘッドの予約は、BE6000S リリース 11.0 以前には該当しません。BE6000S は、導入モデル制限のある特別な設定であり、リリース 11.0 以前では他の Business Edition モデル用に説明した ESXi 用の追加メモリが付属せず、必要ありません。

たとえば、ESXi 5.1 を実行する BE6000 ホストに 32 GB の物理 RAM がある場合、ESXi に 2 GB、仮想マシンに 30 GB の RAM を使用できます。詳細については、http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.resmgmt.doc%2FGUID-98BD5A8A-260A-494F-BAAE-74781F5C4B87.html の「Understanding Memory Overhead」を参照してください。

サーバのダイレクト アタッチド ストレージ（DAS）は、最小限のパフォーマンス レベルを維持しながら、ホスト上で実行される仮想マシンの合計ディスク容量および IOPS（Input Output Operations Per Second）容量を提供する必要があります。

Business Edition アプリケーションの遅延要件がサードパーティ アプリケーションを制限することはほとんどありません。ただし、インストールの前に、非 Business Edition アプリケーションの遅延と負荷の要件を理解する必要があります。

DAS および RAID は製造時に設定され、BE6000 または BE7000 Unified Computing System の Tested Reference Configuration（TRC）のフィールド変更は許可されません。BE6000 TRC は、BE6000 のすべてのコラボレーション アプリケーションのストレージ要件を満たすように設計されています。BE7000 TRC は、www.cisco.com/go/virtualized-collaboration で説明するように、これらのアプリケーションより高い容量ポイントのストレージ要件を満たすように設計されています。

Business Edition アプリケーションの信頼性の高い動作を確保するには、ディスク遅延が 20 ミリ秒以内である必要があります。非 Business Edition アプリケーションを含む展開は、あらゆる状況において、カーネル コマンドの遅延が 3 ミリ秒を超えず、物理デバイスのコマンド遅延が 20 ミリ秒を超えないように検証することが推奨されます。詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/collaboration-virtualization-hardware.html#storageの「Sizing Shared Storage」を参照してください。

たとえば、DAS で TRC をテストする場合、TRC で動作するように設計されているすべての UC アプリケーションは、フル トラフィックでロードされ、すべての仮想マシンでソフトウェア アップグレードが同時に実行されます。これにより、ホストで可能な最大の IOPS 負荷が生成され、このテストが成功すると、DAS アレイが特定のセットの仮想マシンの I/O 負荷を処理できる可能性が高くなります。

要件を要約すると、ディスク サブシステムは、UC アプリケーションの遅延の要件に影響を与えることなく、すべてのアプリケーションに必要なディスク領域を用意し、仮想マシンが生成する集約 IOPS の負荷をサポートする必要があります。そうしない場合は、一部の仮想マシンを取り除く必要があります。

共存する仮想マシンの集約ネットワーキングの負荷は、物理ネットワーキング インターフェイスの容量を超えてはいけません。通常、最近のサーバの物理ネットワーク リソースの I/O 容量は、ホストされている仮想マシンのニーズを満たすのに十分です。UC アプリケーションについては、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-qos-designs-considerations.html の「QoS Design Considerations」を参照してください。

ホストで導入されている仮想マシンのネットワーキング要件と、それらのニーズを満たすためにホストのネットワーク ハードウェアをセットアップする方法を把握するようにしてください。アプリケーション パフォーマンスの問題が、ホスト内のネットワークの輻輳が原因であると判断された場合、一部の VM をホストから除外する必要があります。