UC on UCS ~ Cisco UCアプリケーションの仮想化における設計とポイント

ビジネス推進グループ
技術本部 第2製品技術部 UCチーム
中山 剛

2011年11月30日

概要

Cisco社が提供するUC(Unified Collaboration)は、仮想環境に対応していますが、仮想環境で可用性を維持しながら柔軟に拡張を進めるには、設計が重要になります。本記事では、同じくCisco社が提供するサーバ Cisco UCS(Unified Computing System)上に仮想環境を構築し、その上で Cisco UC(Unified Collaboration)を実現する際に覚えておいてもらいたいポイントをご紹介します。(2011年11月30日作成)

Cisco UCによるコミュニケーションインフラとは

Cisco UCが提供する機能の概要

Cisco UC(Unified Communications、以降UC)はIP Phoneをコントロールして電話の機能を提供するCUCM(Cisco Unified Communications Manager、以降CUCM)を中心に、ボイスメール、プレゼンス、インスタントメッセージ、モビリティ、ビデオといった様々なコミュニケーションツールを統合的に提供するアプリケーション製品です。中枢となる主な製品として、図1に示す4種類のアプリケーションが存在します。必要なものを選択することで、様々な業種に対して最適なコミュニケーションインフラの提供を可能とし、ワークスタイルの変革による生産性向上を実現します。

図1.UC環境を構成するアプリケーション

拡大表示

拡張性と可用性への柔軟に対応

Cisco UCのアプリケーション製品は、MCS7800シリーズと呼ばれる専用のIAサーバに直接インストールすることによりその機能がユーザへ提供されていました。いわゆるベアメタルサーバとしての提供形態であり、一種類のアプリケーションを導入するためには一台の物理サーバが必要となります。また、キャパシティの拡大と可用性の強化へ対応する為、Cisco UCの各アプリケーションはそれぞれ求められる形態に応じてクラスタリングを構成する仕組みが実装されています。同種のアプリケーションを導入した物理サーバを追加することでクラスターを増強することが可能です。

図2.柔軟な拡張性を持つシステム

図2に示される様に、機能拡張を自在に行える仕組みや非常に高い可用性と拡張性を併せ持つCisco UCは、ユーザにおけるビジネスの成長に応じた利用環境の変化へ柔軟に対応することができるコミュニケーションインフラとして最適あると言えます。

ベアメタル環境の課題とUC on UCSによる解決

物理サーバ増加への対策

先に述べたように、非常に高い拡張性を持つ反面、UC環境の規模拡大に伴って必要となる物理サーバの台数は増加することとなります。たとえばIP Phoneのコントロールだけを考えた場合、ひとつのCUCMクラスターで管理できる端末数は最大3万台(利用する機能やコール数などの条件による)と非常に大規模な環境に対応することが可能です。しかしながら、最大規模のクラスターを実現するには最低でも11台の物理サーバが必要となります。単なるIPテレフォニーの環境からユニファイドコラボレーション環境へと移行してゆくためには更なる物理サーバの追加が必要となります。
 それでも拠点毎の分散配置が必須となる旧来のレガシー交換機環境と比べれば、センタライズ構成を取ることでシステムの集約が可能となりメリットがあります。しかしながら、システムの拡張・拡充を進めた結果、増設を積み重ねた大量の物理サーバはそれ自身の管理・運用・保守という点において課題を抱えることとなります。

図3.肥大したUC環境を仮想化により集約

肥大化してしまったUC環境は、他の多くのアプリケーションと同様に仮想化することでより少ないハードウェア上に集約することが可能です。Cisco社が提供するサーバ製品であるUCS(Unified Computing System、以降UCS)を用いることで、最大8台分のUCアプリケーションを1台の仮想化プラットフォーム上に集約することが可能です。物理サーバの台数が大幅に削減されるため、ハードウェアの管理コストの削減につながります。

ハードライフサイクルに関する課題と対策

ベアメタル環境におけるUCアプリケーションの課題は、サーバ台数の増加以外にも存在します。汎用IAサーバのOEM製品であるMCS7800シリーズのライフサイクルは決して長いものではありません。一般的な汎用OSはハードウェアベンダーからドライバーやデプロイツールが提供されるため、デバイスが変更になっても大きな問題にはなりません。
一方UCアプリケーションは専用OSによりインストーラが作りこまれています。インストール作業の簡素化や汎用OSにおけるセキュリティリスクの軽減と言ったメリットはありますが、ハードウェアの世代が更新されることに対しては課題が残ります。対応するハードウェアが販売終了となってからキャパシティ拡張のためにサーバを追加したくても、新たなハードウェアに導入済みのソフトウェアバージョンが適合しないケースが発生します。

図4.仮想化によりハードウェアライフサイクルを吸収

この課題はUCアプリケーションを仮想化することで解消されます。VMware ESXiがハードウェアの世代交代による差分を吸収するため、ソフトウェアとハードウェアの依存関係が無くなります。システムの拡張はこれまで以上に柔軟なものとなり、現用環境を新たな仮想化プラットフォームへ移行する作業も安全で容易に実施可能とします。

UC on UCSのキャパシティデザイン

UC on UCSを実現するためのコンポーネント

UCアプリケーションの仮想化はシステムリリースバージョン8.0からサポートが開始され、8.5においてほぼ全てのUCプリケーションへの対応が完了しています。UCアプリケーションを仮想化する際のコンポーネントは2種類あり、サーバプラットフォームとしてのUCS、仮想化を実現するためのVMware ESXiが必要となります。それぞれのコンポーネントについて、サポートされる構成やバージョンが次の通り規定されています。

1)ハードウェア:Cisco UCS

C on UCSを実装するために最適化されたパーツ構成で組まれた専用のUCS型番がリリースされています。B200で構成されたブレードタイプと、C200 / C210で構成されたラックマウントサーバタイプの計3種類となります。各製品における構成の詳細は図5を参照してください。

図5.UC on UCS用に提供されているUCSプラットフォーム

これらの専用型番以外にも、B / CシリーズでESXiをSAN(Storage Area Network、以降SAN) Bootさせる場合のDiskless構成や、CシリーズにHBA(Host Bus Adapter、以降HBA)を追加してFC(Fiber Channel、以降FC) SANへ対応させる場合の構成など、より大規模な仮想環境へ対応させることが可能となるメーカテスト済みのリファレンス構成が公開されています。UC on UCS専用型番やリファレンス構成以外のUCSを用いることは許可されていません。

2)ソフトウェア:VMwre vSphere ESXi

ESXiバージョンへの対応は、テスト結果に応じてUCアプリケーションとそのバージョンごとに対応バージョンが指定されています。対応バージョンに関してはメーカーによるテストが完了次第、随時更新されてゆきます。現在のサポート状況を表1に示します。

表1.UCアプリケーションとVMware ESXiのバージョン対応

  • ※ 2011年10月時点における対応です

仮想化する際のベースポリシー

ESXiの機能として、CPU / メモリ / ディスクと言ったリソースを仮想マシン間で共有し、さらに物理リソースの上限を超えて割り当てを行うオーバーサブスクリプションを行うことも可能です。リソースの共有とオーバーサブスクリプションは、物理リソースを効率的に、かつ最大限に活用することが可能となるケースもあります。しかしながら、リアルタイム性が重視されるUCアプリケーションにおいては、このオーバーサブスクリプションが許可されていません。また、要件が異なるUC以外のアプリケーションがリソースを共有することは許可されておらず、これは単一のハードウェアはUCアプリケーションで占有される必要があることを示しています。各要件の詳細を以下に示します。

1)CPU

UCアプリケーションが要求するvCPUは物理的なCPUコアへ1:1でマッピングする必要があります。仮想マシンに割り当てたvCPUの数が、物理サーバに搭載されたCPUコアの数を超えてはいけません。
(Unity ConnectionはCPUコアを1つアイドル状態にしておく必要があるため、CPUコアを1つ追加して計算する必要があります。)

メモリ

仮想マシンに割り当てたvRAMの合計値が、物理サーバに搭載されたメモリの合計値を超えてはいけません。また、ESXi側の要件として必要となる2GBのメモリをオーバーヘッドとして考慮する必要があります。

ディスク

仮想マシンが持つvDiskの合計容量が、物理サーバに搭載されたディスクにおける論理ボリュームの容量を超えてはいけません。

それぞれのUCアプリケーションで規定された要件に反しない限り、これらの基本要件は順守する必要があります。最大2500ユーザまでの規模を想定した構成例を図6に示します。

図6.仮想化におけるリソースの設計例

UCのサイジングとリソースを決めるOVAテンプレート

UC環境のサイジングは利用する最大ユーザ数に応じてクラスが決められています。vCPU / vRAM / vDiskといったリソースの割り当てや、その他必要となる仮想マシンの構成要素についてはUCアプリケーションごとに提供されるOVA(Open Virtual Appliance、以降OVA)テンプレートにより規定されており、テンプレートを用いてデプロイされた仮想マシンは自動的に必要な要件を満たすように構成されます。ただし、デプロイする全ての仮想マシンが、サーバハードウェアの物理的なリソースを超えるかどうかについては自動的にチェックされないため、あらかじめ配分を考慮して仮想マシンの配置を検討しておく必要はあります。
UCアプリケーションごとに用意されているOVAテンプレートと、それに応じたリソースの構成を表2に示します。

表2.OVAテンプレートにて規定されたリソース要件

可用性を考慮した設計要素

システムの冗長構成に関する基本要件

仮想化環境において冗長構成を設計する際の考え方は、これまでのベアメタル環境における実装が基本となります。設定データや機能に対する冗長性はアプリケーションレイヤで実装されているため、下位のハードウェアレイヤで考慮する必要はありません。ただし、複数の仮想マシンを一台のサーバに配置することが可能なため、クラスター内での役割とそれぞれの役割に応じた冗長構成が、ハードウェア故障やネットワークトラブルに影響されない様に配置する必要があります。その要件を以下にまとめます。

  • 1)プライマリとバックアップの仮想マシンを、同一のハードウェア上に配置しないように構成します。
  • 2)各フェイルオーバーグループにおけるプライマリ仮想マシンを、異なるハードウェア上に配置することで処理を分散させます。
  • 3)ネットワークへの接続や、冗長化されたSANにおける仮想マシンの配置も、フェイルオーバーを考慮することが望ましいと言えます。

これらの冗長構成要件を考慮したCUCMクラスターの配置構成例を図7に示します。

図7.CUCM環境における冗長構成の例

CUCMはクラスター内のサーバが個々に役割を担うことにより、その機能ごとにフェイルオーバー構成を取りながらキャパシティの拡張を行います。図のクラスターは、コールプロセッシング、保留音ストリーミング、音声会議ブリッジ、TFTPの各サービスがそれぞれフェイルオーバーグループを形成しており、ハードウェアごとに負荷が分散される様に排他的にプライマリサーバを配置しています。これは配置デザインの基本をよりわかりやすく説明するための例となりますが、より複雑な設定・設計に基づいて全てのサービスを50:50で分散させる設計も可能です。なお、パブリッシャサーバに関しては、書き込み権限を持つマスターデータベースの機能を提供するものであり、クラスター内に1台しか配置できません。よって、マスターデータベースの冗長化をアプリケーションレイヤで対応することはできませんが、次に説明するESXiの各種機能により冗長性を提供することが可能となります。

VMware ESXiの機能による可用性と保守性の向上

VMware ESXiには仮想マシンの可用性を高めるための機能や、サーバハードウェアの保守・運用面で有益な機能が豊富に実装されています。UCアプリケーションにおいても、いくつかの機能を利用することができます。サポート状況はUCアプリケーションの種類によって異なり、表3のとおりとなります。

表3.UC on UCSでサポートされるESXiの機能

  • ※ 2011年10月時点における対応です

UCアプリケーションの可用性や保守性を向上させるいくつかの機能について説明します。

1)仮想マシンのコピー

サーバの追加、大幅な設定変更、バージョンアップ作業など、システムの大きな変更を行う際、トラブル発生時に元の環境へ戻すためにはバックアップデータのリストアや、アプリケーションの再インストールが必要となるケースがありました。インストールやリストアが伴う復旧作業には非常に多くの時間が必要であり、長時間のシステム停止を余儀なくされることもあります。仮想化された環境では、作業実施前の仮想マシンをコピーしておくことにより安全で迅速な復旧が可能となりました。ただし、仮想マシンをシャットダウンした状態でコピーする必要である点と、クラスター全体を復元した場合はデータベースを再同期するオペレーションが必要な場合がある点は注意してください。

2)vMotion / Storage vMotion

UCアプリケーションのほぼすべての機能は、アプリケーションとして冗長構成を組むことが可能な実装を有しています。また、HAやSRMによりフェイルオーバーした場合、仮想マシンは起動が完了するまではサービスの停止時間が発生します。高いリアルタイム性が要求されるUCアプリケーションにおいて、この停止時間の発生は致命的となります。例えばCUCMの場合、呼処理を担うコールプロセッシングサービスやメディアストリームを扱うサービスに対してはHAやSRMによるフェイルオーバーは適しません。一方、冗長構成が取れないパブリッシャサーバや重要性の低いTFTPサービスについては適用が可能です。特に、ベアメタル環境では冗長構成が取れなかったパブリッシャサーバに対しては非常に有効な手段であると言えます。なお、SRMによりサイト間でフェイルオーバーを行う場合、ネットワークアドレスが異なるとサーバのアドレスを手動にて再設定する必要があるため現実的ではありません。

まとめ

UC on UCSを導入する際に最も重要なポイントは、ガイドラインに則したキャパシティプランニングであると言えます。メーカーが提供しているガイドラインは十分なテスト結果に基づくものであり、UCアプリケーションをガイドに則して導入すれば仮想環境上で安定したシステムを構築することが可能です。その上で冗長性や拡張性を考慮した仮想マシン、サービスの配置、機能の選択と適用を行うことでシステムの可用性はより高まります。仮想化することによりハードウェアを集約することだけでは無く、可用性をより高め、拡張に柔軟性を与える点は、UCアプリケーションにおいて非常に大きなアドバンテージとなるため、UC on UCSは今後の主流になってくると言えます。なお、仮想化に関するガイドラインは頻繁に更新されているため、以下のサイトより最新の情報を確認する必要があります。

http://docwiki.Cisco.com/wiki/Unified_Communications_in_a_Virtualized_Environment

Webからのお問い合わせ、ご質問はこちらから
お問い合わせ窓口へ

イベント/レポート

pagetop