【テクニカルレポート】Cisco、VMware、NetAppの協業によるマルチテナント環境の強化エンドツーエンドのサービス品質～後編

エンタープライズソフトウェア・サービス

2010年8月14日（土） 18時00分

■エンドツーエンドQoS

　エンドツーエンドQoSという問題に正面から取り組んでいるプロジェクトはほとんどありません。一般には1つのレイヤだけでQoSメカニズムを有効化することによって、関連するダウンストリームまたはアップストリーム・レイヤも制御されると期待するケースがほとんどです。残念ながら、サーバ、ネットワーク、I／Oのどのリソースを集中的に使用するかは、アプリケーションの特性によって異なります。単純にI／Oを制限しても、CPUを集中的に使用するアプリケーションに対して、CPU利用率をコントロールする効果はほとんどありません。3つのレイヤのすべてに適切なメカニズムがなければ、QoSを完全に保証するのは不可能です。私たちチームの目標は、それを可能にするシステムの設計でした。

　AmazonやGoogleなどの企業では、何百人もの開発者が何年も費やして自社開発した独自のソフトウェアを利用して、マルチテナントすなわち「クラウド」を提供しています。私たちのアプローチは、Cisco、NetApp、VMwareの3社が市販するテクノロジを利用して、同じような結果を達成するものです。

　私たちがすべてのレイヤに適用した設計原則の1つは、リソースが利用されていないときは、重要度の高いアプリケーションに対して、必要に応じて空いているリソースの利用を認めることです。これにより、アプリケーションに予想外の負荷がかかっても対応することができます。ただし、競合が起こっているときは、すべてのテナントに、契約で定められたレベルのサービスを保証しなければなりません。

　もう1つの設計原則は、可能な限りアプリケーションに合わせた形でサービス・クラスを設定して、その値をポリシー定義にマッピングし、各レイヤ固有の性質に従って、すべてのレイヤにポリシーを均一に適用することです。QoSを実現するために、私たちは各レイヤでそれぞれ3つのメカニズムを使用しています。

■サーバ・レイヤ

　サーバ仮想化レベルでは、VMware vSphereによって、特にCPUとメモリ・リソースの公平な使用を保証する、多くの機能が提供されます。vSphereリソース・プールは、柔軟性に優れたリソース管理のための論理的な抽象概念です。リソース・プールを階層構造にグループ化し、使用可能なCPUとメモリを階層的にパーティショニングすることができます。リソース・プールの属性（予約、リミット、共有、拡張可能な予約）を適切に設定することで、非常にきめ細かい制御を実現し、リソースをめぐって競合が発生したときは、特定のテナントを他のテナントよりも優先させることが可能になります。

　VMware Distributed Resource Scheduler（DRS）を使用すると、複数のVMwareサーバを含むクラスタを作成できます。DRSは、すべてのリソース・プールの利用状況を継続的に監視し、空いているリソースを仮想マシン間でインテリジェントに配分します。また、クラスタ・レベルで完全に自動化可能で、インフラとテナント仮想マシンの負荷を、クラスタ内のすべてのESXサーバ間で均等に分散することができます。

　ハードウェア・レベルでは、Cisco UCSがData Center Ethernet（DCE）を使用してCisco UCSシステム内のすべてのトラフィックを処理します。この業界標準のイーサネット拡張機能は、イーサネット・パイプの帯域幅を8本の仮想レーンに分割します。Cisco UCSシステム全体で、これらの仮想レーンに含まれるDCE帯域幅をどのように配分するかは、システム・クラスによって決定されます。システム・クラスごとに、帯域幅の特定のセグメントが、特定のトラフィック・タイプ用に予約されます。これにより、システムがオーバーサブスクライブ状態になっても、一定レベルのトラフィック管理が提供されます。

■ネットワーク・レイヤ

　ネットワーク・レベルでは、トラフィックはNexus 1000Vが指定し、UCSシステムが監視するサービス・クラスに従ってセグメント化されます。安定したパフォーマンスを確保するために、以下の2つのメカニズムがあります。

・キューイング：ネットワーキング・デバイスで、クラス分けの基準に基づいたパケット配信のスケジューリングが可能になります。優先的に配信すべきパケットを区別できるため、オーバーサブスクライブが発生したとき、応答時間の観点で重要なアプリケーションを差別化できるようになります。すべてのサービス・クラスに指定された帯域幅を完全に使いきった場合にのみ、キューイングが実行されます。

・帯域幅コントロール：特定のトラフィック・クラスが帯域幅を占有することのないよう、ネットワーク・デバイスでキューごとに適切な量のバッファを使用します。これにより、別のキューで残りのトラフィック・クラスのニーズを適切に処理できます。キューイングは優先的に配信されるパケットを決定するのに対し、帯域幅コントロールはキューごとに送信可能なデータの量を決定します。このように、帯域幅コントロールはキューイングと連携して動作します。

　トラフィック・パターンに予想外の変化があった場合、その変化にソフト的に対処する（サービス・コミットメントに即した範囲でアプリケーションのバースト／一時的な違反を認める）か、またはハード・ポリシーによって対処する（余剰トラフィックを廃棄する、または送信レートの上限を設定する）ように、一連のポリシー・コントロールを設定できます。この機能を利用して、サービス・レベルを定義することも可能です。たとえば、比較的緊急度の低いサービスを一定のトラフィック・レベルで維持したり、最低サービス・レベルのトラフィックに対する上限を設定したりして、上位テナントのサービスに影響を与えないようにすることが可能です。

　ポリシングやレート・リミットも、保護レベルの定義に使用できます。これらの機能をネットワーク・エッジにできるだけ近い場所に適用すれば、ネットワークへ入るトラフィックを止めることができます。この設計ではNexus 1000Vを使用して、次の3種類のトラフィックに対するポリシングおよびレート・リミット機能を実行します。

・VMotion：VMwareは従来から、VMotionトラフィックには専用のギガビット・インターフェイスを使用するよう推奨しています。この設計では、VMotionトラフィックはルーティングされないVMkernel専用のポートを利用します。各ブレード・サーバからのVMotionトラフィックは、従来の環境を反映して1Gbpsで維持されます。このリミットは必要に応じて加減できますが、より重要なトラフィックに影響が出るような設定にすべきではありません。

・トランザクション・サービスとストレージ・サービスの差別化：マルチテナント設計では、サービスの差別化を実現するためさまざまな手法を採用します。たとえば、最も重要なサービスには「priority」キューを使用します。廃棄するわけにはいかないけれども、ある程度の遅延があっても構わないトラフィックには「no-drop」を使用します。レート・リミットは、アプリケーションまたはサービス・クラスごとに上限を定めた固定レート・サービスに使用します。

・管理：管理VLANには、トラフィックの上限を1Gbpsとするレート・リミットを設定します。

■ストレージ・レイヤ

　前述したように、NetApp MultiStoreソフトウェアは、マルチテナント環境における安全な分離を実現します（MultiStoreについては今月号の関連記事で詳しく解説されています）。

　ストレージ・レイヤにおけるQoSは、ストレージ・システムのキャッシュとCPU利用率を制御すること、およびワークロードが適切な数のスピンドルに分散されるようにすることで実現します。NetAppは、ワークロードの優先順位付けを制御する目的でFlexShareを開発しました。FlexShareを使用すると、ストレージ・ボリュームまたはMultiStore構成内のvFilerユニットごとに、3つのパラメータを個別に調整し、特定のテナント・パーティションを他より優先することが可能になります（FlexShareについては、Tech OnTapの過去の記事で詳しく解説されています）。MultiStoreもFlexShareも、NetApp Data ONTAPオペレーティング環境で長年にわたって使われてきた実績があります。

　NetAppシン・プロビジョニングを使用すると、一定レベルの「ストレージ・オンデマンド」がテナントに提供されます。物理容量が共有リソースとして扱われ、必要量だけが消費されます。マルチテナント構成でリソースのシン・プロビジョニングを導入する場合は、ボリュームの自動拡張（autogrow）、Snapshotの自動削除（autodelete）、およびフラクショナル・リザーブに関するポリシーを設定する必要があります。ボリュームの自動拡張を使用すると、あらかじめ定義済みのしきい値まで、ボリュームが一定の増分で拡張されます。Snapshotの自動削除は、ボリュームが満杯に近付いたとき、最も古いSnapshotコピーを自動的に削除する方式です。フラクショナル・リザーブを使用すると、関連するデータの重要性に基づいて、スペース・リザベーションの割合を変更することができます。

　これらの機能を同時に使用すれば、重要なテナントに対して、共有プールのスペースを予約することによって、必要に応じたボリュームの拡張を優先的に行うことができます。逆に、下位のテナントについては、ストレージの追加要求に対応するため、別途管理者による設定変更が必要になります。

■まとめ

　Cisco、VMware、NetAppは、必要なセキュリティを提供するだけでなく、QoS、可用性、高度な管理機能を備えた、セキュアなマルチテナント・クラウド・アーキテクチャの定義とテストに共同で取り組んできました。

　この記事では、QoSに対するエンドツーエンド・アプローチをご紹介しました。QoSやマルチテナントのその他の重要原則については、最近リリースされたデザイン・ガイドで詳しく解説されています。このガイドでは、本アーキテクチャの要素に関する詳しい説明のほか、適切な構成のための推奨事項が記載されています。

Chris Naddeo氏

Cisco Systems UCS担当テクニカル・マーケティング・エンジニア

Chris氏はCiscoに入社して以来、Cisco Unified Computing System（UCS）の顧客環境への導入と最適なストレージ・アーキテクチャの設計に取り組んでいます。Chris氏はストレージ業界でさまざまな経験を重ねており、NetAppでOracleおよびData ONTAP GX担当コンサルティングSEとして1年、VeritasでVeritasストレージ・ソフトウェアのプロダクト・マネージャとして9年、それぞれ活躍した経歴があります。

※同記事はネットアップ（NetApp）の発行する「Tech OnTap」の転載記事である

《RBB TODAY》

【テクニカルレポート】Cisco、VMware、NetAppの協業によるマルチテナント環境の強化エンドツーエンドのサービス品質～後編

関連ニュース

特集

Tech OnTap（テックオンタップ）

テクニカルレポート

ヴイエムウェア（VMware）

環境・エコロジー

シスコシステムズ

ネットアップ（NetApp）

エンタープライズトピックス