NetApp Tech OnTap
Cisco、VMware、NetAppの協業によるマルチテナント環境の強化
エンドツーエンドのサービス品質

共有インフラの構築には常に、多少なりともやっかいな課題がともないます。一般的な企業のデータセンター設計を見ると、重要なアプリケーションに対して、専用のインフラか、あるいは共有環境であれば、必要をはるかに上回る性能を割り当てられているケースが目に付きます。どちらのアプローチでも、リソースが十分に活用されず、IT予算の浪費につながります。

問題は、通常より高い負荷がかかった場合に、サーバ、ネットワーク、ストレージなどのインフラ・コンポーネントが、どのように影響を受けるのか予測がつかない点にあります。あるリソースがボトルネックになって、重要なアプリケーションのパフォーマンスが不意に低下する危険性があるとしたら、ボトルネックの原因をすばやく特定するには、どうすればいいでしょうか。

クラウド・コンピューティングへの関心が高まりつつある現在、マルチテナント環境(すべてのリソースが共有されるインフラ)のあらゆる側面について理解することが、従来にも増して重要になっています。実際、セキュリティやQuality of Service(QoS:サービス品質)の問題に不安があるために、クラウド・インフラの構築やクラウド・サービスの契約に二の足を踏んでいる企業が少なくありません。

CiscoはVMwareおよびNetAppと協力し、セキュア・マルチテナント・デザイン・アーキテクチャの設計とテストに取り組んできました。セキュア・マルチテナントの重要な要素としては、以下の4つをあげることができます。

  • セキュアな分離:どんな状況下でも、他のテナントの仮想マシン(VM)、ネットワーク、ストレージ・リソースにアクセスできないようにしなければなりません。それぞれのテナントが、安全に分離されている必要があります。
  • サービス保証:通常の運用時だけでなく、障害が発生したときや、一部のテナントで異常な負荷が発生したときにも、サーバ、ネットワーク、ストレージの各パフォーマンスがテナント別に分離され、保証される必要があります。
  • 可用性:障害が発生しても、必要なサーバ、ネットワーク、ストレージの各リソースの可用性を確保できるインフラでなければなりません。
  • 管理:すべてのリソースの迅速なプロビジョニング、管理、監視といった機能は必要不可欠です。

この記事では、マルチテナントに関するこれらの重要要素を達成するために、3社が共同で開発した独自のアーキテクチャについてご紹介します。2番目の目標である「サービス保証」については、特に詳しく説明します。

最近リリースされたデザイン・ガイドでは、3社のテクノロジを結集して上記4つの要素を実現したCisco Validated Designについて、詳しく解説しています。Tech OnTap今月号の関連記事では、このアーキテクチャのひとつの要素であるNetApp® MultiStore®について、詳しく解説しています。

アーキテクチャの概要

図1は、このアーキテクチャのブロック図です。主要なソフトウェアおよびハードウェア・コンポーネントによって、すべてのレイヤでセキュリティ、QoS、可用性、管理のしやすさを実現するように設計されています。

図1)エンドツーエンドのブロック図

図1)エンドツーエンドのブロック図

サーバ・レイヤ

サーバ・レイヤでは、VMware® vSphere™およびvCenter™ Serverソフトウェアによって強力なサーバ仮想化環境が提供され、仮想マシンで動作する複数のゲストOSにサーバ・リソースを動的に割り当てることができます。

サーバ・レイヤ内のセキュリティは、VMware vShield Zonesによって提供されます。vShield ZonesはvSphere 4.0にバンドルされた集中管理方式のステートフルな分散型ファイアウォールであり、ESXホストの近接性と仮想ネットワークの可視性を利用してセキュリティ・ゾーンを作成します。vShield ZonesはVMware vCenterに統合され、vNIC、ポート・グループ、クラスタ、VLANなどの仮想インベントリ情報を利用して、ファイアウォール・ルールの管理とトラストゾーンのプロビジョニングを簡易化します。この新しい手法でセキュリティ・ポリシーを作成すると、VMotion™の際にもその情報がVMに付随します。この手法はIPアドレスの変更やネットワーク番号の付け替えに対しても完全に透過的です。

Cisco Unified Computing System™(UCS)は、サーバ・リソース、サーバ・ネットワーク・アクセス、ストレージ・アクセス、仮想化を1つのシステムに統合した、次世代データセンター・プラットフォームです。UCSは低遅延かつロスレスの10ギガビット・イーサネット・ネットワーク・ファブリックを、エンタープライズクラスのx86アーキテクチャ・サーバに統合します。この拡張性に優れた統合型のマルチシャーシ・プラットフォーム・システムでは、すべてのリソースが統一された管理ドメインを共有します。

ネットワーク・レイヤ

ネットワーク・レイヤは、サーバ・レイヤとストレージ・レイヤ間のセキュアなネットワーク接続のほか、外部ネットワークおよびクライアントへの接続を提供します。主要なコンポーネントは次のとおりです。

  • Cisco Nexus 7000:外部ネットワークへのイーサネット(LAN)接続を提供します。
  • Cisco Nexus 5000:FCストレージおよびCisco 7000を接続します。
  • Cisco Nexus 1000V:VMwareカーネル内で動作するソフトウェア・スイッチです。サーバとネットワーク環境との間で緊密な統合を実現するCisco VN-Linkサービスを提供し、ライブ・マイグレーション時に仮想マシンに付随するポリシーの移動を実現します。
  • Cisco MDS 9124:SAN接続を提供するファイバ・チャネル・スイッチであり、UCS上で動作するVMware ESXのSANブートを可能にします。

ストレージ・レイヤ

ストレージ・レイヤは、SAN接続(SANブート用)とNFS接続(VMware環境の動作用)を同時に提供できるNetAppユニファイド・ストレージ・システムで構成されます。NetAppストレージは、稼働するアプリケーションの特殊なストレージ・ニーズにも対応できます。イーサネット上でVMware環境を運用することで、コスト削減につながる非常に管理しやすい環境が実現されます。

NetApp MultiStoreソフトウェアは、物理的に分かれたストレージ・アレイに匹敵するレベルのセキュリティと分離機能を、共有ストレージに提供します。MultiStoreを使用すると、1つのストレージ・システム上で完全に分離された複数の論理パーティションを作成できるため、機密性を損なわずにストレージを共有することが可能になります。ストレージ・システム間で個々のストレージ・コンテナを独立して、かつ透過的に移動することができます。

テナントのプロビジョニング

このアーキテクチャを使用してプロビジョニングを行うと、テナントには次のものが提供されます。

  • 1つ以上の仮想マシンまたは仮想アプリケーション
  • 1つ以上の仮想ストレージ・コントローラ(vFilerユニット)
  • これらのリソースを相互接続してアクセスする、1つ以上のVLAN

これらの構成要素を組み合わせて、論理パーティションが形成されます。このパーティションの境界を、テナントが侵害することはできません。私たちの目標は、セキュリティに加えて、あるテナント・パーティションで発生したアクティビティが、他のテナント・パーティションでのアクティビティに、間接的にも干渉しないようにすることです。

エンドツーエンドQoS

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

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

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

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

サーバネットワークストレージ
  • 拡張可能な予約
  • ダイナミック・リソース・スケジューラ
  • UCS QoSシステム・クラスによるリソースの予約と制限
  • QoS─キューイング
  • QoS─帯域幅制御
  • QoS─レート・リミット
  • FlexShare®
  • ストレージ・リザベーション
  • シン・プロビジョニング

表1)QoSメカニズム

サーバ・レイヤ

サーバ仮想化レベルでは、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やマルチテナントのその他の重要原則については、最近リリースされたデザイン・ガイドで詳しく解説されています。このガイドでは、本アーキテクチャの要素に関する詳しい説明のほか、適切な構成のための推奨事項が記載されています。


David A. ChapaChris Naddeo氏
Cisco Systems UCS担当テクニカル・マーケティング・エンジニア

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


関連情報