概要
このドキュメントでは、Cisco Collaboration Virtualizationで定義された仮想化Cisco Unified Communications(UC)/コラボレーションアプリケーションのサポートポリシーの一部としてApplication Co-residency Support Policyで定義されたアプリケーション共存のサポートポリシーについて説明します。このテクニカルノートは、ユニファイドコンピューティングシステム(UCS)上のすべてのUCと、UCSテスト済みリファレンス構成、UCS仕様ベース、およびサードパーティサーバ仕様ベースのその他の仮想化ハードウェアオプションに適用されます。
前提条件
要件
次の項目に関する知識があることが推奨されます。
注：Web ページ リンクについては、このドキュメントの「関連情報」セクションを参照してください。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
共存と「Quality of Service（QoS）」
ネットワーク収束と仮想化の両方における主要な原則は、ハードウェア リソースの共有です。
いずれの場合も、ハードウェア リソースが次のように限定されている場合には、非 UC アプリケーションから UC を保護するために、Quality of Service（QoS）が必要になります。
-
音声/ビデオネットワークトラフィックが必要な帯域幅を確保し、遅延とジッタから保護されるようにするため、ルーティングおよびスイッチングネットワークハードウェアのQuality of Service(QoS)。
-
UC VMが必要なCPU、メモリ、ストレージ容量、およびストレージ/ネットワークパフォーマンスを確実に得られるようにするため、UC仮想化ルール（物理/仮想ハードウェアのサイジング、共存ポリシーなど）に準拠します。
ハードウェアとアプリケーションのすべての組み合わせをVM共存でテストすることは不可能です。特に、動作が予測不能または明確に定義されていないサードパーティアプリケーションVMでは不可能です。したがって、Cisco UCアプリケーションのリアルタイムパフォーマンスは、UCS Tested Reference Configurationにインストールされた後で、共存ポリシーのすべての条件に従った場合にのみコミットされます(「Collaboration Virtualization Sizing」を参照)。UCMやIMPなどのCPU予約をををサポートするアプリケーション場合)。
その他の環境では、導入前のテスト、ベースライン設定、仮想化の一般的な原則に従うこと、およびCisco UC仮想化のルール(Cisco Collaboration Virtualization)に従うことで、不確実性を低減できます。 ただし、シスコは、VM のリソース不足やパフォーマンスの問題が絶対に発生しないと保証することはできません。
非UCおよびサードパーティ仮想マシンのサポートに関する主な考慮事項
Cisco UC VMを非UC/サードパーティアプリケーションVMと共存させて実行する場合に、Cisco TACがサポートを効果的に提供できるようにするには、次のいずれかを確認する必要があります。
-
非UC/サードパーティVMは重要ではなく、トラブルシューティングを容易にするために必要な場合は一時的に電源を切ることができます。
-
非クリティカルな VM がない場合、アプリケーション パフォーマンス問題の解決策として、VM の再配置（一時的または永続的）のために、仮想ホストまたは物理サーバ上に予備キャパシティをプロビジョニングする必要がある。予備キャパシティは、冗長性確保のため、またはハードウェアやソフトウェアにメンテナンスが必要なときに VM の一時的ステージングを提供するために、今までも推奨されてきた設計面でのベスト プラクティスです。「予備キャパシティ」の例としては、追加の「空の」物理サーバ（「ホットスタンバイ」や一時的ステージングに対応する）、または利用率の低い既存のブレード/ラックマウント サーバなどがあります。
Cisco UC VMを非UC/サードパーティ製アプリケーションVMと共存させて実行する場合に、Cisco TACがサポートを効果的に提供できるようにするには、問題の診断または解決のために顧客から次のアクティビティが必要になる場合があります。
-
アプリケーションパフォーマンスの問題をトラブルシューティングまたは解決するための、ソフトウェアワークロードまたは物理ハードウェアへの変更。これらの変更が必要な場合の例としては、ハードウェアから十分なCPU、メモリ、ネットワーク、ディスク容量、またはストレージの入出力操作(IOPS)を受け取っていないUC VMが挙げられます。
-
実際の導入でこれらの変更がどのように表示されるかの例を次に示します。
-
ソフトウェア：パフォーマンスのトラブルシューティングを容易にするため、重要でないVMの一時的な電源オフ
-
ソフトウェア：仮想化ホスト/物理サーバを一時的または永続的なソリューションとして代替するには、重要なVMまたは重要でないVMを移動します。
-
シスコがトラブルシューティングの目的で必要と判断した場合、ホストで実行する仮想マシンの数を一時的に減らします。
-
ホストが過負荷であるとシスコが判断した場合、ホストで実行される仮想マシンの数を永続的に減らします。
-
高密度 UC アプリケーション VM を、密度がそれほど高くない複数の VM に分割し、次にそれらの密度がそれほど高くない VM を代替ホストに移動させる。たとえば、CUCM 10KユーザOVAを複数のCUCM 7.5KユーザOVAに分割し、それらのCUCM 7.5KユーザOVAの一部を再配置します。
-
これらのアプローチにより、過負荷の仮想化ホスト/物理サーバのソフトウェアワークロードを削減できるため、ワークロードがハードウェアリソースに不足することがなくなります。
-
Hardware:VM の電源オフまたは移動に代わる手段として、過負荷のホストを「修正」するための追加またはアップグレードを行う。
-
たとえば、ストレージ容量を増やし、IOPSを提供する物理ディスクを増やすことができます。
-
たとえば、より多くの物理メモリまたは複数の物理CPUコアを追加します。
-
たとえば、LANの輻輳に対処するための物理NICインターフェイスの追加。
-
これらのアプローチでは、過負荷ハードウェアの「アップグレード」によりリソース不足のソフトウェア ワークロードに対応できます。
シスコのサポートの提供は、お客様がシスコとの現在の全額支払い済みサポート契約を維持することが条件となります。
関連情報
フィードバック