Comments
Transcript
Cisco Virtualized Multiservice Data Center 2.3 設計ガイド
Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 最終更新日：2013 年 4 月 4 日 【注意】シスコ製品をご使用になる前に、安全上の注意 （www.cisco.com/jp/go/safety_warning/）をご確認ください。 本書は、米国シスコ発行ドキュメントの参考和訳です。リンク情報 につきましては、日本語版掲載時点で、英語版にアップデートがあ り、リンク先のページが移動 / 変更されている場合がありますこと をご了承ください。 あくまでも参考和訳となりますので、正式な内容については米国サ イトのドキュメントを参照ください。 また、契約等の記述については、弊社販売パートナー、または、弊 社担当者にご確認ください。 CCDE, CCENT, CCSI, Cisco Eos, Cisco Explorer, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco TrustSec, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or website are the property of their respective owners.The use of the word partner does not imply a partnership relationship between Cisco and any other company.(1002R) 対象製品のソフトウェア ライセンスおよび限定保証は、製品に添付された『Information Packet』に記載されています。添付されていない場合には、代理店にご連絡ください。 The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system.All rights reserved.Copyright © 1981, Regents of the University of California. ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコおよび これら各社は、商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保証をはじめ とする、明示されたまたは黙示された一切の保証の責任を負わないものとします。 いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接 的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものとします。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド © 2013 Cisco Systems, Inc. All rights reserved. CONTENTS はじめに vii 概要 vii 対象読者 viii マニュアルの構成 関連資料 viii ix Cisco Validated Designs について ix CHAPTER 1 設計の概要 概要 1-1 1-1 クラウド データセンター 1-3 階層型ネットワーク アーキテクチャ 1-3 VMDC レイヤ 1-4 モジュラ ビルディング ブロック 1-6 Pod 1-6 特殊用途の Pod 1-7 統合コンピューティングおよびストレージ（ICS）スタック 1-8 SAN アーキテクチャ 1-8 コンピューティング アーキテクチャ マルチテナント アーキテクチャ テナント モデル 1-10 1-11 1-11 VMDC 2.3 で導入された新しいテナント モデル 1-12 クラウド サービス 1-13 差別化サービス 1-13 サービスの階層化 CHAPTER 2 設計の詳細 1-14 2-1 ソリューションのアーキテクチャ 物理トポロジ 2-2 論理トポロジ 2-3 2-1 Pod および ICS 2-4 統合コンピューティングおよびストレージ（ICS）スタック 2-4 Pod のレイアウト 2-5 ソリューションのコンポーネント セキュアなテナントの分離 2-6 2-8 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド iii Contents ネットワークの分離 2-8 コンピューティングの分離 ストレージの分離 2-8 2-9 アプリケーション層の分離 2-9 Virtual Security Gateway 2-12 境界のセキュリティ 2-14 DMZ ゾーン 2-17 VMDC 2.3 のコンテナ 2-18 ハイ アベイラビリティ 2-22 冗長ネットワーク設計 2-22 L2 の冗長性 2-23 仮想ポート チャネル 2-23 Multi-Chassis EtherChannel 2-24 MAC-pinning 2-24 L3 の冗長性 2-24 HSRP 2-24 BGP 2-24 コンピューティングの冗長性 2-25 UCS エンドホスト モード 2-25 Nexus 1000V および MAC-pinning 2-27 アクティブ / スタンバイ冗長構成 2-27 クラスタ内のハイ アベイラビリティ その他の考慮事項 ストレージの冗長性 2-27 2-28 ハードウェアとノードの冗長性 リンクの冗長性 サービスの冗長性 2-27 2-28 2-28 2-28 ASA 2-28 ACE 2-29 サービス保証 2-30 トラフィックの分類とマーキング 2-31 キューイング、スケジューリング、およびドロップ ポリシングとシェーピング 拡張性に関する考慮事項 2-33 2-34 2-35 L2 の拡張性 2-35 L3 の拡張性 2-36 リソースのオーバーサブスクリプション 2-37 ネットワークのオーバーサブスクリプション 2-37 コンピューティングのオーバーサブスクリプション Cisco Virtualized Multiservice Data Center 2.3 設計ガイド iv 2-38 Contents VM あたりの帯域幅 2-39 ストレージのオーバーサブスクリプション 2-40 DC の拡張性 2-40 VMDC 2.3 の拡張性 2-41 GLOSSARY Cisco Virtualized Multiservice Data Center 2.3 設計ガイド v Contents Cisco Virtualized Multiservice Data Center 2.3 設計ガイド vi はじめに Cisco® Virtualized Multiservice Data Center（VMDC）ソリューションは、プライベート クラウド サービスを導入する企業や、仮想プライベート サービスおよびパブリック クラウド サービスを構築す るサービス プロバイダーに対して設計と実装のガイダンスを提供します。Cisco VMDC は、クラウド コンピューティング エコシステムを構成するシスコおよびサードパーティのさまざまな製品を統合す るソリューションです。 このマニュアルに掲載されているスクリーンショットなどの資料は説明のためのみに使用され、 VMAX（EMC Corporation）、NetApp FAS3240（NetApp）、vSphere（VMware Inc.）についても同様 に、ここに記載されている他のすべてのマークおよび名称は、各社の商標である可能性があります。 「パートナー」または「パートナーシップ」という用語の使用は、シスコと他社との法的なパートナー 関係を意味するものではありません。 概要 クラウド コンピューティングへの関心はここ数年で飛躍的に伸びています。パブリックかプライベー トかを問わず、クラウド コンピューティングはクラウド プロバイダーにとってビジネス プロセスと運 用プロセスに変革をもたらすソリューションです。カスタマーによる市場への参入および市場投入まで の時間（TTM）の合理化、改革の推進、コストの効率化、オンデマンドでリソースをスケーリングす る能力を実現します。 シスコの VMDC システムはエンドツーエンドのアーキテクチャを定義しており、IaaS のようなクラウ ドベースの新しいサービス モデルのための仮想化マルチテナント対応データセンターへの移行または 構築を行う組織が参照することが可能です。 構造的アプローチという視点から、このシステムでは次のような基盤に基づいて構築を行います。 • セキュアなマルチテナント機能： マルチレイヤ アプローチにおける従来のセキュリティ ベスト プ ラクティスを活用し、テナント独自のリソースを含む共有の物理インフラストラクチャおよびその 論理構造の安全性を確保しながら、仮想マシン（VM）レベルでセキュリティ ポリシーおよびポリ シーのモビリティを提供する新しいテクノロジーを採用することで、高度に仮想化されたマルチテ ナント環境でもビジネスおよび規制上のポリシーを継続的に実施することができます。 • モジュール化： Pod ベースのモジュラ設計方式により、予定外の成長に伴うリスクを軽減します。 この方式では、予測可能な物理特性およびコスト特性の観点から管理可能な拡張単位を定義し、 サービス展開プロセスの簡素化を行う事で、迅速な Time-To-Market（TTM; 市場投入までの時間） を実現します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド vii はじめに • ハイ アベイラビリティ： プラットフォーム、ネットワーク、ハードウェアおよびソフトウェア コ ンポーネント レベルで復元力のあるキャリアクラスのアベイラビリティを構築することで、サー ビスに影響するインシデントが発生する確率とその時間を最小限に抑えることができます。これに よって、プライベート IT およびパブリック クラウド管理者は、問題への対処よりも、収益を上げ るためのサポートに専念できます。 • 差別化サービスのサポート： サービスの使用例を中心とした論理モデルを定義することで、システ ム定義に対してサービス指向のフレームワークが構築されるため、テナントの要求を満たすように リソースを適用し、調整することができます。 • サービス オーケストレーション： クラウドベースの運用モデルでは、動的なアプリケーションと 解放されたリソースの再利用が重要な要素となります。そのため、基礎となるテナント固有のリ ソースおよびサービスを的確に抽象化して表す能力が、自動化されたサービスのオーケストレー ションとその実施の基本的な要件です。これは、VMDC アーキテクチャを通じて、ネットワーク コンテナの定義を継続的に発展させていきます。そしてこの定義は、社内ミドルウェアやパート ナーの管理ソリューションで利用が可能になっていきます。 対象読者 このマニュアルは、システム アーキテクト、ネットワーク設計者、システム エンジニア、フィールド コンサルタント、高度なサービスのスペシャリスト、およびパブリック / プライベート クラウド デー タセンターのインフラストラクチャの導入方法を理解しようと考えているカスタマーを対象に執筆され ていますが、このような方々に限定されるわけではありません。また、この設計ガイドは、IP プロト コル、QoS、DiffServ およびハイ アベイラビリティ（HA）の基本的な概念を十分理解している方を対 象としています。さらに、一般的なシステム要件を理解していることと、企業やサービス プロバイ ダーのネットワークおよびデータセンター アーキテクチャの知識を持つことが前提となります。 マニュアルの構成 このマニュアルの構成は、表 1 に示すとおりです。 表 1 マニュアルの構成 トピック 説明 第 1 章「設計の概要」 このソリューションの概要について説明しま す。 第 2 章「設計の詳細」 このソリューションの設計について詳しく説明 します。 用語集 このマニュアルで使用されている略語の一覧を 示します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド viii はじめに 関連資料 VMDC 設計では、IaaS を導入する基盤として一般的なシスコ データセンター設計のベスト プラク ティスに従うことが推奨されます。そのような基盤に関する説明については、次に示す Cisco Validated Design（CVD）のドキュメントをご覧ください。 • Cisco Virtualized Multi-Tenant Data Center ソリューション 2.0 • VMDC 2.0 ソリューション ホワイト ペーパー • これまでにリリースされた VMDC System Release • データセンター設計：Data Center Interconnect • データセンター設計：IP ネットワーク インフラストラクチャ • データセンター サービス パターン • Data Center Interconnect • データセンターにおけるセキュリティおよび仮想化 • Vblock インフラストラクチャ ソリューション シスコ アドバンスド サービスが提供する Cloud Enablement Services と各パートナーでは、お客様に IT 投資のビジネス価値をより早く実現していただけるようお手伝いをしております。このようなイン テリジェント サービスは、当社が持つネットワーキングとセキュリティの専門知識、アーキテクチャ アプローチ、パートナーの幅広いエコシステムに支えられているため、セキュアでアジャイルな高度に 自動化されたクラウド インフラストラクチャを構築することができます。 Cisco Validated Designs について Cisco Validated Design プログラムは、お客様による信頼性の高い、確実かつ速やかな展開を容易にす るために、デザイン、テスト、および文書化されたシステムおよびソリューションで構成されていま す。詳細については、http://www.cisco.com/go/validateddesigns にアクセスしてください。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド ix はじめに Cisco Virtualized Multiservice Data Center 2.3 設計ガイド x C H A P T E R 1 設計の概要 この章では、Virtualized Multiservice Data Center (VMDC) ソリューションの概要について説明しま す。この章の内容は、次のとおりです。 • 概要 • クラウド データセンター • マルチテナント アーキテクチャ • クラウド サービス 概要 クラウドは、拡張性や効率性、柔軟性の高いサービスを提供します。このようなサービスは、インター ネットまたはイントラネット経由でオンデマンドにアクセスされます。クラウドでは、コンピューティ ング、ストレージ、ネットワークの各ハードウェアが抽象化され、サービスとして配信されます。エン ド ユーザは、基盤となるテクノロジーを管理したり意識したりすることなく、サービスによって提供 される機能とメリットを享受できます。クラウドの導入モデルは従来の導入モデルとは異なり、データ センター (DC) をリソースの共通のファブリックとして取り扱うことができます。各リソースは、一部 だけを動的に割り当てることができます。また、使用されなくなったら割り当てを解除できます。 VMDC ソリューションは、Infrastructure as a Service（IaaS）クラウドの導入に対応したシスコのリ ファレンス アーキテクチャです。このアーキテクチャは、Pod と呼ばれるリソースの構成ブロックで 構成された一連のモジュラ DC コンポーネントを中心として設計されています。また、各 Pod は、 ネットワーク、ストレージ、コンピューティングの共有リソース プールで構成されています。これら の各コンポーネントは仮想化され、複数のテナントによって安全に使用されます。各クラウドのテナン トは、独自の物理リソース セットを持っているかのように利用できます。クラウドの DC 内でリソー スをプロビジョニングするワークフローは、クラウド サービス オーケストレーション ツールによって 自動化されます。 VMDC ソリューションは、プライベート クラウドを構築する企業とパブリック クラウドを構築する サービス プロバイダーを対象としています。パブリック クラウドの場合、テナントは通常リモートに 配置され、独自の DC リソースがある場合には他のリソースと一緒にローカルに配置されます。プライ ベート クラウドの場合、テナントは IT DC と論理的に分離されて別テナントと一緒にローカルに配置 されるか、（物理的に分離された）別の場所に配置されます。 VMDC システムは Cisco Unified Computing System (UCS)、Nexus 1000V 仮想スイッチ、Multilayer Director Switch (MDS) ストレージ スイッチ、SAN および NAS ストレージ アレイ、Catalyst 6500 Data Center Service Node（DSN）に接続する Nexus 7000 アグリゲーション（スイッチングおよび ルーティング）レイヤおよび Nexus 5000 アクセス（スイッチング）レイヤ、Adaptive Security Appliance (ASA)、Application Control Engine(ACE) 方式の Layer 4（L4）- Layer 7（L7）サービス レイヤ、ASR 9000 および 1000 WAN ルータを中心として構築されます。クラウド オーケストレー Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-1 第1章 設計の概要 概要 ションは BMC Cloud Lifecycle Management (CLM) スイートにより提供され、クラウド保証は Zenoss Cloud Service Assurance (CSA) スイートにより提供されます。図 1-1 は、VMDC ソリューションの機 能要素を示したものです。 図 1-1 （注） VMDC システムの概要 Data Center Interconnect (DCI)、クラウド オーケストレーション、クラウド保証については、このマ ニュアルでは説明しません。これらの要素については、Cisco.com Design Zone の『Cisco VMDC Documentation』を参照してください。 VMDC ソリューションには複数のバージョンがあり、フェーズごとに新しいプラットフォームやバー ジョン、テクノロジーがサポートされます。以前にリリースされた VMDC 2.2 および VMDC 3.0 の各 ソリューションでは、クラウド DC 内でテナントをセグメント化するためにエンドツーエンドの VRF-Lite を使用します。VMDC 2.2 ソリューションでは、Nexus DC ファブリックで仮想ポートチャ ネル（vPC）ベースの Layer 2（L2）設計を使用し、VMDC 3.0 ソリューションでは、Nexus DC ファ ブリックで FabricPath ベースの L2 設計を使用します。 （注） 以前のバージョンの VMDC ソリューションについては、次のマニュアルを参照してください。 Cisco VMDC 2.2 Design Guide Cisco VMDC 3.0 Design Guide このマニュアルでは、VMDC 2.3 ベースの DC に固有の設計上の考慮事項に重点を置いて説明します。 VMDC 2.3 ソリューションは、Cloud Ready Infrastructure（CRI）に対応した Service Provider Cloud Smart Solutions Standard Offer の基盤を形成します。VMDC 2.3 アーキテクチャは VMDC 2.2 アーキ テクチャに基づいていますが、いくつかの設計変更が加えられています。VMDC 2.2 ソリューション と比較した VMDC 2.3 ソリューションの主な変更点は、次に示すとおりです。 • VMDC 2.2 は、高密度のサーバおよび VM に対応できる設計となっており、6 個の Pod で最大 3,000 台のサーバと 70,000 台の VM に対応可能です。 • VMDC 2.3 は、中小規模のサーバおよび VM の密度に対応できる設計となっており、4 個の Pod で最大 768 台のサーバと 24,000 台の VM に対応可能です。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-2 第1章 設計の概要 クラウド データセンター • VMDC 2.3 の設計では、より高いテナント密度を実現できるように VMDC 2.2 の設計から最適化 されており、4 個の Pod で最大 2,000 のテナントに対応できます。 • DC WAN ルータ（MPLS-PE）として Cisco ASR 9000 の代わりに Cisco ASR 1000 を使用します。 • VMDC 2.3 は DC Core Nexus 7000 のレイヤを使用しません。 • VMDC 2.3 は、M1/M2 ラインカードを装備した Nexus 7018 ではなく、F2 ラインカードを装備し た Nexus 7004 をアグリゲーション レイヤとして使用します。 • VMDC 2.3 は Catalyst 6500 DSN を使用しません。サービスは、Nexus 7000 アグリゲーション レ イヤに直接接続する ASA および ACE アプライアンスによって提供されます。 • VMDC 2.3 には、Expanded Gold、Silver、および Bronze の各コンテナに対応する最適化された テナント モデルが含まれます。 • VMDC 2.3 には、インターネットベースのクラウド アクセスに対応した新しい Copper コンテナが 含まれます。 クラウド データセンター VMDC ベースのクラウド DC は、ネットワーク、ストレージ、コンピューティングの各リソースで構 成されています。通常、各データセンターは相互接続されており、WAN、IP/Next Generation Network（NGN）、またはパブリック インターネットへのアクセスを提供します。DC には、マルチテ ナント機能やマルチサービスが備えられているだけでなく、管理機能、オーケストレーション（クラウ ド ポータル、サービス カタログ、ワークフローの自動化）、保証といった管理要素も含まれます。 ここでは、クラウド DC の次の項目について説明します。 • 階層型ネットワーク アーキテクチャ • VMDC レイヤ • モジュラ ビルディング ブロック • SAN アーキテクチャ • コンピューティング アーキテクチャ 階層型ネットワーク アーキテクチャ 一般的な DC 設計は、従来のマルチレイヤ階層型ネットワーク モデルに基づいています。通常、この ようなモデルは次に示す 3 レイヤの階層を実装しています。 1. 高度な冗長性と帯域幅キャパシティを特徴とし、アベイラビリティとパフォーマンスを向上させる ために最適化された DC コア レイヤ。コア レイヤは DC WAN エッジ ルータに接続します。 2. 高度な高帯域幅のポート密度キャパシティを特徴とし、アクセス レイヤ スイッチに対するトラ フィックの分散とリンクのファンアウト機能に合わせて最適化された DC アグリゲーション レイ ヤ。機能的には、アグリゲーション レイヤのノードは L2/L3 境界として動作するのが一般的です。 コア レイヤには複数のアグリゲーション レイヤが接続できるため、DC 内の密度および水平方向 トラフィックの増加に対応できます。 3. DC アクセス レイヤはホストをインフラストラクチャに接続する役割を果たし、通常は L2 （VLAN）でネットワーク アクセスを提供します。 以前の VMDC 2.2 アーキテクチャでは、DC 内でこのような 3 レイヤの階層設計を使用していました が、VMDC 2.3 アーキテクチャでは主に次のことを目的としています。 1. テナントの規模を拡大する Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-3 第1章 設計の概要 クラウド データセンター 2. ソリューションのコストを削減する 3. パブリックまたは仮想プライベート クラウドを利用する中小規模企業（SMB）を対象として、テ ナントごとに必要な VM 数を少なくする（通常 1 テナントあたり VLAN 数が 1、VM 数が 4 ～ 5） 4. 1 つのテナントに必要な VM 密度と水平方向の帯域幅を少なくする このような要件に基づき、VMDC 2.3 アーキテクチャは、コア レイヤを排除することで最適化されて います。コア レイヤは、プラットフォームでのコントロール プレーン（ボーダー ゲートウェイ プロト コル（BGP）と仮想ルーティングおよび転送（VRF））の制限により、コストを増加させ、テナントの 拡張性を減少させるためです。また、ほとんどのテナントはアグリゲーション レイヤ（1 テナントあた りの VM 数および VLAN 数が少ない）に含まれているため、複数のアグリゲーション レイヤ間のルー ティング機能を提供するコア レイヤが必要ありません。この機能は、WAN エッジ ルータが代わりに 提供できます（必要な場合）。 図 1-2 は、階層型モデルの 2 つのレイヤを示したものです。 図 1-2 VMDC 2.3 の 2 レイヤ階層型モデル このような階層型モデルの利点としては、拡張性、復元力、パフォーマンス、メンテナンス性、管理性 などが挙げられます。階層型設計は構造化されたアプローチでインフラストラクチャを構築するため、 比較的容易にモジュール単位で拡張できます。各レベルの冗長なノードとリンクによってシングル ポ イント障害が発生しないようにする一方で、リンク アグリゲーションは、アグリゲーション レイヤお よびコア レイヤから最適な帯域幅とパフォーマンスが得られるように設計できます。また、各レイヤ 内のデバイスも同様に機能します。この一貫性によって、トラブルシューティングと設定が簡素化され ます。そのため、低い運用コストで容易にメンテナンスが行えます。 VMDC レイヤ 図 1-3 は、VMDC アーキテクチャ内の機能レイヤを示したものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-4 第1章 設計の概要 クラウド データセンター 図 1-3 VMDC データセンター内の機能レイヤ ネットワーク レイヤには、DC と企業全体のエリアまたはプロバイダーの IP/NGN バックボーンとの境 界線、さらにはパブリック インターネットとの境界線を形成する WAN/PE ルータが含まれます。この ような境界線ノードは、L3 ルーティング機能に特化したものになる場合もありますが、L2 が L3 サー ビス間だけでなくデータセンター間も相互接続する場合は、本質的にマルチサービス型となります。 VMDC リファレンス システム アーキテクチャ内で検証された WAN/PE ルータとしては、Cisco CRS-1、Cisco ASR 9000、ASR 1000、Cisco 7600、および Cisco Catalyst 6500 の各プラットフォーム が挙げられます。また、ネットワーク レイヤには、前述したスイッチング ノードの 2 レイヤ階層が含 まれます。VMDC リファレンス アーキテクチャでは、インフラストラクチャのこの部分は、アグリ ゲーション ノードとして動作する Nexus 7000 システムと、アクセス ノードとして動作する Nexus 5000 システムで構成されます。このようなシステムでは、現在のスケール要件と将来予想されるス ケール要件に対応するために必要なアグリゲーション レベルやアクセス密度に合わせて、ポート容量 と帯域幅を微調整することができます。VMDC 2.3 アーキテクチャでは、ASR 1000 が WAN/PE ルー タとして使用され、Nexus 7004 がアグリゲーション デバイスとして使用されます。また、Nexus 5548 はアクセス デバイスとして使用されます。 サービス レイヤは、ファイアウォール、サーバ ロード バランサ、SSL オフロード、侵入防御、ネット ワーク分析などのネットワーク サービスおよびセキュリティ サービスで構成されています。従来の DC サービス レイヤとクラウド DC サービス レイヤの間には明白な違いがあり、クラウドの場合は、 ソリューション セットがテナント単位で L4 から L7 サービスの適用をサポートしている必要がありま す。これは、物理リソースの論理的抽象化によって実現します。集中型サービスが最も有用なのは、複 数のテナント（プライベート クラウドの場合はワークグループ）にわたって広範囲にポリシーを適用 する場合です。このレイヤは、リモート アクセスの IPsec または SSL VPN のターミネーション ポイン トとして機能します。VMDC リファレンス アーキテクチャでは、Catalyst 6500 DSN がファイア ウォールとサーバ ロードバランシングの各サービスをサービス モジュールのフォーム ファクタ（つま り、ACE30 と ASASM のサービス モジュール）で提供します。また、これらのサービスをアプライア ンスのフォーム ファクタで提供することもできます。VMDC 2.3 アーキテクチャでは、フットプリン Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-5 第1章 設計の概要 クラウド データセンター トとコストを抑えるために、ASA および ACE の各アプライアンスがサービス レイヤとして機能しま す。具体的には、ASA 5585-X60 がファイアウォール サービスに、ASA 5555X が IPsec/SSL VPN リ モート アクセスに、ACE 4710 がサーバ ロード バランシング（SLB）に使用されています。 コンピューティング レイヤは、複数のサブシステムで構成されています。1 番目は、L2 ネットワーク を複数の物理コンピューティング システムに拡張できる仮想アクセス スイッチング レイヤです。この 仮想アクセス スイッチング レイヤは、L2 ネットワークを物理サーバ内の個々の VM に論理的に拡張 することから、特に重要です。豊富な機能を持つ Cisco Nexus 1000V は、アーキテクチャ内でこの役 割を果たします。必要とされるソフトウェア機能（Quality Of Service（QoS）やセキュリティ ポリ シー）や規模のレベルによっては、ハードウェア ベースの代替品として Nexus 1000V ではなく Cisco UCS VM-FEX を使用できます。2 番目のサブシステムは、仮想（つまり vApp ベースの）サービスで す。このようなサービスとして、セキュリティ、ロード バランシング、最適化の各サービスが挙げら れます。インフラストラクチャのこの層に実装されるサービスは、より集約されたサービス アプリ ケーションを補完するものであり、特定のテナントやワーク グループとそのアプリケーションまたは VM に単独で直接適用できます。VMDC 2.3 アーキテクチャ内で検証された特定の vApp ベースのサー ビスとしては、テナントの仮想データセンター（vDC）または仮想プライベート データセンター （VPDC）内にセキュリティ ポリシーのエンフォースメント ポイントを提供する Cisco Virtual Security Gateway（VSG）などが挙げられます。コンピューティング レイヤの 3 番目のサブシステムは、コン ピューティング リソースです。このようなリソースとして、物理サーバや、コンピューティング仮想 化機能を提供するハイパーバイザ ソフトウェアとそれによって有効化された VM が挙げられます。ま た、冗長 6200 ファブリック インターコネクト搭載の UCS、UCS 5108 ブレード シャーシ、および B シリーズ ブレードまたは C シリーズ ラックマウント サーバも、VMDC リファレンス アーキテクチャ で使用されるコンピューティング リソースを構成します。 ストレージ レイヤはストレージ リソースを提供します。データ ストアは、SAN（ブロック ベース） または NAS（ファイルベース）のストレージ システムに配置されます。SAN スイッチング ノード （MDS）では、冗長ファイバ チャネル（FC）（または Fibre Channel over Ethernet（FCoE））リンクを 介して複数の SAN ストレージ アレイをコンピューティング リソースに相互接続することで、復元力 のレベルを高めています。VMDC アーキテクチャは EMC と NetApp の両方のストレージ アレイで検 証済みです。また、その他のストレージ ベンダーでも動作します。 管理レイヤは、マルチテナント インフラストラクチャを管理するために必要なハードウェアおよびソ フトウェアのリソースで構成されています。このようなリソースとして、ドメイン要素管理システムや 上位レベルのサービス オーケストレーション システムなどが挙げられます。現在 VMDC 内で検証済 みのドメイン管理システムとしては、UCS Manager、VMware vCenter、vCloud Director（コンピュー ティング リソースの割り当て用）、EMC Unified Infrastructure Manager (UIM) および Cisco Fabric Manager（ストレージ管理用）、Cisco Virtual Supervisor Module（VSM）および Virtual Network Management Center（VNMC）（仮想アクセスおよび仮想サービス管理用）などが挙げられます。リ ソース間サービス オーケストレーション機能などの自動化されたサービス プロビジョニングは BMC の CLM システムにより提供されますが、サービス保証は Zenoss CSA により提供されます。これらの 管理システムは通常、本番環境と管理システムの間で障害ドメインを分離するために、別のマネージメ ント Pod でホストされます。 モジュラ ビルディング ブロック Pod これまでの VMDC リファレンス アーキテクチャでは、「Pod」と呼ばれるリソース コンテナが定義さ れていました。これはクラウド DC におけるモジュール化の基盤として機能します。Pod の概念によ り、ネットワーク、コンピューティング、ストレージの各リソースが同種のモジュラ ユニットとして 機能するため、環境面の要件、物理的および論理的な側面の要件、アプリケーション レベルの要件に 一貫した方法で対処することができます。Pod は、クラウド DC を構造化された形式で「増築」する場 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-6 第1章 設計の概要 クラウド データセンター 合のブループリントとして機能します。Pod 内のリソース使用率が、事前に設定されたしきい値（70 ～ 80%）に達した場合は、単に新しい Pod を配置するという考え方です。サービスの実施およびオー ケストレーションの観点では、Pod は個別のリソース管理ドメインを表します。 図 1-4 Pod の概念 Pod の概念は単にフレームワークとして機能するものであり、設計者が特定の環境やパフォーマンスの 特性に合わせて独自のバリエーションを定義するのが一般的です。図 1-4 に示すように、Pod はさまざ まなモジュール化のレベルで定義できるため、成長に伴う増加量が異なる場合でもサポートできます。 ただし、VMDC リファレンス アーキテクチャでは、汎用ユーティリティのコンピューティング Pod が コンピューティング レイヤおよびストレージ レイヤから L2/L3 の境界として機能するアグリゲーショ ン ノードの L2 ポートまで拡張し、さらにはネットワーク サービス レイヤまでのコンポーネントとそ こに含まれるコンポーネントまで拡張します。したがって、クラウド DC 内で 1 組のアグリゲーション ノードがサポートできる Pod 数を決定するうえで、アグリゲーション ノードのポートと MAC アドレ スのキャパシティが重要な要素になります。 特殊用途の Pod 汎用の同種のコンピューティング Pod を構築し、ビジネスやセキュリティ ポリシーの要件を満たすよ うに論理セグメンテーション オーバーレイを適用するうえで大きな前提となるのは、リソースの使用 率を最大化することです。ただし、運用の簡易化、特別なパフォーマンス チューニング、特別なセ キュリティ目標の達成といった目的のために、コンピューティング ノードの一部を汎用 Pod から物理 的に切り離し、専用のアプリケーション固有の Pod に置くという特殊な要件が発生する場合もありま す。VMDC アーキテクチャは、特殊用途向け Pod の構築を可能にする柔軟性を備えています。これが 管理用 Pod の概念です。 バックエンドの管理コンピューティング ノードは汎用コンピューティング Pod 内に配置でき、本番ホ ストから論理的に分離され、ファイアウォールで保護されます。この方法は、小規模な環境、あまり複 雑ではない環境、または合理化された環境では優れた選択肢となりますが、大規模な環境では、バック エンド管理サーバ（ベア メタルおよび仮想化）専用の Pod を個別に用意することが推奨されます。実 際、VMDC 2.x の各リリースには、テスト目的のシステムにアクセス Pod が別途組み込まれており、 バックエンドのインフラストラクチャ管理だけを目的としてサーバが機能します。このオプションの利 点として、安定性が低下した場合、または障害が発生した場合に、隔離されたトラブルシューティング ドメインを作成できることなどが挙げられます。アーキテクチャの柔軟性により、論理的な分離やファ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-7 第1章 設計の概要 クラウド データセンター イアウォールの設置が可能となるだけでなく、専用のファイアウォール（物理的または vApp 形式の） を管理コンテナの境界に配置することも可能です。実際には、ディレクトリ サービスに関連付けられ たロール ベース アクセス コントロール（RBAC）を適用して、ユーザ アクセスを分類および制限した り、組織での職務に応じて制御権限を変更したりします。 統合コンピューティングおよびストレージ（ICS）スタック そのほかに VMDC のクラウド DC 内でモジュール化の潜在的な単位を表すものとして、統合コン ピューティングおよびストレージ（ICS）スタックが挙げられます。これは、Pod 内のサブコンポーネ ントを表します。ICS は、事前に統合されたストレージ、コンピューティング、ネットワークの各リ ソースで構成された集合体であり、1 組のアクセス スイッチング ノード上の L2 ポートまでが含まれま す。図 1-5 は、Pod 内での ICS の場所を示したものです。この様に、Pod のキャパシティの範囲内にお いて、ビルディング ブロックのように ICS 単位で拡張可能です。 図 1-5 ICS の概念 現在のところシスコでは、エコシステム パートナーと協力することで 2 つの ICS オプション（Vblock と FlexPod）をサポートしています。Vblock は、UCS および EMC ストレージ システムで構成されて おり、価格、パフォーマンス、スケールの各要件を満たせるように複数の組み合わせで提供されます。 同様に、FlexPod も UCS のコンピューティング リソースとの組み合わせですが、NetApp ストレージ システムが適用されます。FlexPod は、特定のワークロード要件を満たすように設計され、さまざまな サイズで提供されています。VMDC リファレンス アーキテクチャ自体は、他のサード パーティ ベン ダーのストレージを含め、一般的なコンピューティングとストレージの組み合わせに対応します。ただ し、ICS が持つビジネス上のメリットは、事前統合によって、アプリケーションのパフォーマンス要件 を満たすために計算処理能力とストレージの 1 秒間あたりのストレージ IO 性能（IOPS）のバランスを 取るために推測設計をする作業を省略できます。 SAN アーキテクチャ VMDC 2.3 の SAN アーキテクチャは以前（2.x）の設計から変更されていません。拡張性、高可用性、 トラフィック分離に関する現在のベスト プラクティスのガイドラインに従っています。このアーキテ クチャの設計で重要となる側面は次のとおりです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-8 第1章 設計の概要 クラウド データセンター • LAN および SAN のケーブル接続コストの最適化および削減のために Cisco Data Center Unified Fabric を利用する • マルチレベルの冗長性（リンク、ポート、ファブリック、ダイレクタ、Redundant Array of Independent Disks（RAID））による高可用性 • ファブリックの分離（複数ファブリック、Virtual SAN（VSAN））によるリスクの軽減 • N ポート仮想化（NPV) や N ポート ID 仮想化（NPIV）といった仮想化技術と、ゾーン分割および 論理ユニット番号（LUN）マスキングを組み合わせたデータストアの分離 このマニュアルで説明する階層型の Pod ベースのインフラストラクチャ モデルは、ストレージに対し て 2 つの接続ポイントを持つことが想定されています。これは、Pod 内またはアグリゲーション ノー ド上にあるため、分散型または集中型となります。実際には、ある導入方法に対してどのオプションが 最も適しているのかは、アプリケーションの特性と、データストアへのアクセスに伴うインタラクショ ンとして予測されるトラフィック パターンによって異なります。企業では多くの場合、具体的なアプ リケーション要件と使用パターンを満たすために両方のオプションを使用します。これまで、VMDC の検証作業として重視されていたのは、ストレージを分散型の Pod ベースのリソースとして考慮する ことでした。これは、階層的なクラウド型の DC モデルでは、パフォーマンスとトラフィック フロー の最適化の点で、データストアのリソースをできるだけテナントのホストおよび vApp の近くに配置し たほうが効率的であるという前提に基づいています。この状況では、インフラストラクチャに FC スト レージ コンポーネントを接続する方法は 2 通りあります。1 番目の方法は Nexus 5000 経由で接続する ICS モデルに従ったもので、2 番目の方法は UCS ファブリック インターコネクトでの接続を提供する 方法です。両方の方法を図 1-6 に示します。 図 1-6 FC SAN の接続オプション いずれの場合も、シスコのユニファイド ファブリック機能をコンバージド（統合型）ネットワーク ア ダプタ（CNA）と組み合わせて利用することで「SAN 対応」サーバを提供しています。また、UCS ファブリック インターコネクトの N ポート バーチャライザまたは Nexus 5000 トップオブラック （ToR）スイッチにより、集約された各ホストがファブリックおよび SAN システムへのアップリンクを 介して一意に識別され、管理されるようにしています。SAN システムの現在の最大処理能力を引き出 し、それによって SAN コンポーネントとそのネットワーク インフラストラクチャへの接続ポイント間 で発生する帯域幅の不足（潜在的なボトルネック）を解消するために、（冗長な）各 Nexus 5000 また は UCS ファブリック インターコネクトから MDS SAN スイッチまでを接続するのに複数の FC リンク が使用されています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-9 第1章 設計の概要 クラウド データセンター 図 1-6 は非常に単純な SAN スイッチング トポロジを示していますが、より大きな SAN ポートのス イッチング キャパシティが必要な場合は、アーキテクチャではより複雑な 2 層コアエッジの SAN トポ ロジをサポートしている（かつそれらが検証済みである）ことに注意してください。これについては、 『VMDC 2.0 Compact Pod Implementation Guide』で説明されています。また、より全般的な説明につ いては、シスコ SAN スイッチングのベスト プラクティスに関する各ガイド （http://www.cisco.com/en/US/prod/collateral/ps4159/ps6409/ps5990/white_paper_C11-515630.html） を参照してください。 コンピューティング アーキテクチャ VMDC のコンピューティング アーキテクチャは、高度なサーバ仮想化という前提に基づいています。 これは、DC の統合、クラウド モデルの基礎となる動的なリソース割り当ての要件、設備投資 （CapEx）を削減しながら運用効率を最大限に高めるというニーズから生まれました。このアーキテク チャは、以下の 3 つの重要な要素に基づいています。 1. ハイパーバイザベースの仮想化。以前のシステム リリースと同様に、このリリースでも VMware の vSphere が重要な役割を果たしており、CPU、メモリ、およびネットワークを複数の仮想ソフ トウェア コンテナへのタッチ ポイントとして考え、サーバ環境を論理的に抽象化することにより、 物理サーバ上での VM の作成を可能にしています。 2. Unified Computing System （UCS）。UCS は、ネットワーク、サーバおよび I/O リソースを単一 の集中型のシステムに統合することで、復元力が高く低遅延のユニファイド ファブリックを提供 します。これにより、無損失の 10 ギガビット イーサネットと FCoE 機能を x-86 サーバ アーキテ クチャに統合します。UCS は、I/O リソースとサーバの特性、設定および接続を抽象化し、動的な プログラム可能性を促進する、ステートレスなコンピューティング環境を提供します。ハードウェ アの状態を抽象化すると、サーバ ハードウェア間でアプリケーションやオペレーティング システ ムを移動しやすくなります。 3. Nexus 1000V。Nexus 1000V は VMware の分散仮想スイッチ（DVS）に相当します。ただし、機 能はさらに豊富であり、ネットワークの可視性、QoS およびセキュリティ ポリシーを VM レベル の細かさまで拡張するソフトウェア ベースの VN-Link テクノロジーが組み込まれています。 このシステム リリースでは、コンピューティングの仮想化オペレーティング システムとして VMware の vSphere 5.0 を使用します。vSphere 5.0 で利用可能な新機能の完全なリストはオンラインで入手で きます。システムで活用される基本的な vSphere 機能としては、主に SAN から起動される ESXi、 Auto Deploy、VMware High Availability（VMware HA）、分散リソース スケジューラ（DRS）などが 挙げられます。 仮想化コンピューティング アーキテクチャの基礎となるのは、クラスタの概念です。クラスタは、リ ソース プール、仮想マシン、およびデータストアが関連付けられた複数のホストで構成されています。 コンピューティング ドメイン マネージャとして vCenter と組み合わせて動作させることで、HA や DRS といった vSphere のより高度な機能が、クラスタ リソースの管理を中心に構築されています。 HA 機能や DRS 機能を使用する場合、vSphere は最大 32 台のサーバのクラスタ サイズをサポートしま す。ただし一般的には、コンピューティング環境の規模が大きくなり、仮想化（VM、ネットワーク イ ンターフェイス、ポート）の要件が高くなるほど、パフォーマンスと仮想インターフェイス ポートの スケールを最適化するために、小さいクラスタ サイズを使用することが推奨されます。したがって、 大規模な VMDC の導入では、クラスタ サイズは 8 台のサーバに制限されます。小規模な導入では、16 台または 32 台のクラスタ サイズを使用できます。VMDC 2.2 リリースでは、3 つのコンピューティン グ プロファイル（Gold、Silver、Bronze）が作成され、それぞれ Large、Medium、Small のワーク ロード タイプを表します。Gold は 1 vCPU/ コアと 16G の RAM、Silver は .5 vCPU/ コアと 8G の RAM、Bronze は .25 vCPU/ コアと 4G の RAM を備えています。 VMDC 2.3 のアーキテクチャは Vblock および FlexPod で動作しますが、システムは FlexPod で検証さ れています。UCS ベースの FlexPod に集約されたスタックには次の特性があります。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-10 第1章 設計の概要 マルチテナント アーキテクチャ • アーキテクチャは複数の UCS 5100 シリーズ シャーシ（5108）で構成されており、それぞれ 8 台 （ハーフ幅）のサーバ ブレードに搭載されています。 • 各サーバには 2 つの 10GigE インターフェイスが装備されており、内部 UCS ファブリックの冗長 な A 側と B 側に接続されます。 • UCS は、シャーシごとに 2 個の 2208XP シリーズ ファブリック エクステンダと、Pod ごとに 2 個 の 6248 シリーズ ファブリック インターコネクトを搭載した完全に冗長なシステムです。 • 内部的には、ファブリック エクステンダごとに 4 個のアップリンクがデュアル ファブリック イン ターコネクトにトラフィックを送信し、システムがサーバごとに可能な最大帯域幅を実現できるよ うにします。つまり、UCS ファブリック内のサーバ間のトラフィックでは、サーバごとに 10GigE の帯域幅を持つことになります。 • 各 UCS 6248 ファブリック インターコネクトは、冗長な 10GigE EtherChannel 接続によって、ア クセス スイッチ（Nexus 5548）に集約されます。プロビジョニングされるアップリンク数はトラ フィック エンジニアリングの要件によって異なります。たとえば、内部ファブリック帯域幅とア グリゲーション帯域幅とのオーバーサブスクリプション率が 8:1 の 8 シャーシ システムを提供する には、合計 80G（8x10G）のアップリンク帯域幅容量を UCS システムごとに提供する必要があり ます。 • FC 接続の場合、Nexus 5548 の 8 つのポートが、NetApp FAS ストレージ アレイに対する 8Gig の FC 直接接続を提供します。IOPS を最大化するには、Nexus 5548 から FAS へのアグリゲーション リンク帯域幅をストレージ コントローラの処理能力に一致させる必要があります。 • Nexus 1000V は仮想アクセス スイッチング レイヤとして動作し、VM ごとのポリシーとポリシー のモビリティを提供します。 マルチテナント アーキテクチャ コンピューティング リソースおよびストレージ リソースを仮想化すると、組織エンティティでの共有 が可能になります。一方、VMDC リファレンス アーキテクチャの中心的な概念である仮想化マルチテ ナント機能とは、共有された仮想のコンピューティング リソース、ストレージ リソース、ネットワー ク リソースの論理的な分離を示します。つまり、「境界のある」共有または区分化された（コンパート メントを持つ）共有です。テナントとは、ある程度の親和性を共有するユーザ コミュニティです。た とえば、企業では事業単位、部門、ワークグループなどが該当します。ビジネス要件や規制ポリシーに よっては、テナントの「コンパートメント」は、物理的な境界、組織の境界、さらには企業間にまで拡 大する可能性があります。テナントのコンテナは、全体がプライベート クラウド内に収まっている場 合もありますが、テナントの企業からパブリック クラウド内のプロバイダーの設備にまで拡張される 場合もあります。VMDC アーキテクチャは、セキュアなデータ パス分離と階層型セキュリティ モデル の組み合わせ（従来のセキュリティのベスト プラクティスを活用し、仮想化されたマルチテナント環 境に合わせて更新します）によって、このようなテナントの使用事例すべてに対応しています。 テナント モデル 以前の VMDC リリースでは、5 種類のテナント モデルまたはコンテナが提示されていました。これら のモデルの概要と論理的な情報は、図 1-7 に示すとおりです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-11 第1章 設計の概要 マルチテナント アーキテクチャ 図 1-7 既存の VMDC テナント モデル 最初の 3 つのモデルは基礎的で単純な一連のテナント コンテナを提供し、各レベルの階層形式のネッ トワーク サービスと組み合わせて運用されていました。これらは、それぞれ Bronze、Silver、Gold と いう名称です。この中で最も注目すべきコンテナは、Bronze および Gold の 2 つです。Bronze は最も 基礎的に見えますが、その単純さにより適用範囲が拡大します。このコンテナは本質的に単一のテナン トであると思われがちですが、実際には Bronze コンテナは、同種の要件（同じような作業負荷特性、 QoS、またはセキュリティポリシー）を持つ複数テナントをサポートする目的で使用できます。同様 に、同じアプリケーションセットをまとめたコミュニティとしても Bronze コンテナを活用できます。 ファイアウォールとサーバのロード バランサの両方のサービスが適用された Gold コンテナは、より高 度なセキュリティとアベイラビリティが想定されています。また、Silver コンテナと同様、複数の VLAN によって N 階層型アプリケーション向けの論理的なセグメント化をサポートします。このコン テナの考え方は、これらのテナント コンテナをさまざまな組み合わせで結合して、必要に応じてより 複雑なシナリオに対応できるようにするというものです。 4 番目のコンテナ タイプ（Palladium）は、単純なマルチセグメント コンテナから、物理的な共有イン フラストラクチャ上に構築される vDC に近づけることが出来るようにテナント モデルを発展させてい ます。Palladium コンテナは、フロントエンドとバックエンドに分かれた一連のゾーンを持っていま す。各ゾーンには、それぞれ異なるネットワーク サービスのセットを適用できるため、従来の物理機 器のみで構成していたゾーニング モデルと同様のサービスを利用できることになります。 5 番目のコンテナ タイプ（Expanded Gold コンテナ）は vDC の概念をさらに発展させたものであり、 保護されたフロントエンドとバックエンドのゾーンをさらに拡大させながら、パブリック アクセス （インターネットまたは非武装地帯（DMZ））または共有（キャンパス / 組織間）アクセスをプライベー ト アクセスから分離します。また、セキュアなリモート IPsec または SSL VPN アクセスも含まれてい ます。この場合、「プライベート」とは vDC がプライベート エンタープライズ WAN またはプライ ベート MPLS VPN を介したパブリック クラウド プロバイダーの IP/NGN を経由してルーティングさ れることを意味します。パブリック クラウドのシナリオでは、このタイプの vDC が L2 または L3 MPLS VPN によってテナント企業にリンクされている場合、一般的に VPDC と呼ばれます。MPLS VPN は多くの場合、ハイブリッド管理されているクラウド サービスへの伝送手段として、パブリック クラウド プロバイダーによって使用されます。このようなサービスとして、IP アドレッシング、セ キュリティ（ファイアウォール設置、管理された DMZ ゾーニング、セキュアなリモート VPN アクセ ス）、およびサーバの復元ソリューションが挙げられます。 VMDC 2.3 で導入された新しいテナント モデル VMDC 2.3 には、新しいテナント モデルとして Copper コンテナが追加されています。このテナント モデルは VMDC クラウドの導入においてより高いテナント スケールを提供するように設計されてお り、クラウド リソースへのインターネットベースのアクセスに適しています。Copper コンテナは 1 つ の VLAN と少数の VM をクラウドで必要とする SMB を対象としています。このようなお客様は分離 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-12 第1章 設計の概要 クラウド サービス とセキュリティを必要としていますが、クラウドで独自の仮想ファイアウォール コンテキストを使用 するために高い料金を支払うことは望んでいないのが一般的です。Copper コンテナでは、共通のファ イアウォールを各テナント間で共有することにより、こうしたニーズに対応します。このような環境で は、各テナントが各自の VLAN および VRF インスタンスを取得し、共有ファイアウォールの背後で分 離を行います。 図 1-8 新しい VMDC 2.3 Copper テナント モデル クラウド サービス VMDC リファレンス アーキテクチャの中心となるもう 1 つの概念は、差別化サービス階層という考え 方です。端的に言えば、テナントはネットワークのスループット、コンピューティング処理、ストレー ジ パフォーマンス、データストアのプライバシーの特性に関してそれぞれ独自の要件を持っている可 能性があり、マルチテナントを正しく導入することによって、このようなニーズに対応できる必要があ ります。 差別化サービス 定義上、クラウドベースのモデルでは、コンピューティング、ストレージ、およびネットワーク イン フラストラクチャが「サービスとして」抽象化され、提供されます。特定のニーズに合わせてワーク ロード特性やアプリケーション パフォーマンスを調整するために、クラウドの管理者には、差別化 サービス階層を提供し、テナントのプライバシーとサービス レベル契約（SLA）の目標を満たせるよ うに、以下のようなさまざまな方法が用意されています。 • 階層型ワークロード定義。クラウド対応のインフラストラクチャを構築するコツは、サポートする 必要があるアプリケーション セットを分類し、それらを基本的なワークロード特性へと抽出する ことです。このようなことが適切に理解されていれば、多くの場合は標準のサービス プロファイ ルのセットによって対処が可能です。たとえば、ICS に適用される特性としては、VM 属性（CPU 率、メモリ、および関連するストレージ容量）、ストレージ属性（RAID レベル、ディスク タイプ と速度、および保護メカニズム）、アプリケーション階層化のさまざまなレベルでのサポートなど が挙げられます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-13 第1章 設計の概要 クラウド サービス • アベイラビリティのメカニズム。アベイラビリティのメカニズムは、通信要件を満たす目的で、イ ンフラストラクチャのさまざまなレイヤに適用できます。たとえば、vSphere クラスタ内では、 サーバ障害が発生した場合でも、最適なリソース割り当てを行うために DRS および vMotion また は耐障害性（FT）を使用することができます。同様に SAN の場合は、スナップショット、クロー ニング、バックアップ アーカイブなどのデータ保護メカニズムが、さまざまな種類の障害状況に おけるデータストアの整合性の維持に役立っています。また、SLB、暗号化、高度なルーティン グ、冗長性などのネットワーク サービスを導入することで、アベイラビリティの目標達成にさら に役立ちます。共有ドメイン（ICS、Pod、または全 DC レベル）が大きくなるほど、階層の特定 のレイヤで使用されるアベイラビリティ メカニズムへの影響も大きくなります。通常はこれらに よって余分なコストがかかるため、広い範囲を対象としたアベイラビリティの技法がテナント コ ミュニティ全体での最小ターゲット要件を満たせることが目標となります。 • セキュアな分離。マルチテナント環境では、セキュアにテナントのトラフィックを包含し、分離す る機能が基本的な要件となります。これは、特定のテナントのプライバシーが侵犯された場合にテ ナントのリソースを保護し、リスクの軽減を行うことで実現します。アベイラビリティと同様に、 必要とされるインフラストラクチャの保護とセキュリティ ゾーン分割ポリシーをテナントごとに 実装するために、分離メカニズムは複数レイヤ方式で適用されます。実際には、各技術は物理的お よび論理的な分離メカニズムの 2 種類のカテゴリに分類されますが、VMDC 分析では主に論理的 なメカニズムに重点が置かれます。このような技術には、さまざまな L2 および L3 のメカニズム が含まれます。たとえば、アクセス コントロール メカニズム（RBAC およびディレクトリ サービ ス、IPsec または SSL VPN）やパケット フィルタリングおよびファイアウォールの各ポリシーと 組み合わせた複数の vNIC（特定の制御またはデータ トラフィック用）、802.1q VLAN、MPLS VRF の各インスタンス、および VSAN などです。 • サービス保証メカニズム。サービス保証はアベイラビリティと QoS ポリシーの機能です。QoS ポ リシーを実装することで、輻輳時のサービス階層ごとに、1 テナントあたりのトラフィック フロー の分類と処理が可能になります。 • 管理。テナントごとのリソースとサービスをサービス カタログの形式で表す能力は、自動化され たサービス実施とサービス保証の各機能を提供する上での前提条件となります。つまり IaaS モデ ルに基づいて運用するうえで、きわめて重要な「Day 1」と「Day 2」の管理タスクにとって不可 欠な要件です。サービス カタログとは、実質的には基盤となるクラウド リソースの最上位レベル の抽象化です。このようなリソースをサービス カタログに沿ったポリシー ベースのテナント モデ ルとして正確に表現できるかどうかは、標準化されたインターフェイス（API、MIB など）を介し たドメイン要素マネージャまたはミドルウェア管理レイヤとの直接的なやり取りに依存します。ミ ドルウェア レイヤがインテリジェントであれば、テナント モデルを理解し、テナント単位でリ ソースを確保したり解放したりするために管理フレームワークの上位レベルで行う必要のある作業 が少なくなります。 サービスの階層化 以前の VMDC のリリースは、テナント ネットワーク サービス階層の 3 つの基本カテゴリ（Bronze、 Silver、Gold）に基づいてモデル化されています。これらのカテゴリは、ファイアウォール設置、サー バ ロード バランシング、SSL オフロード、および QoS ポリシー（サービスの 3 つのデータ クラス） に従って表現され、それぞれが特定のコンピューティング属性、関連するストレージ特性、ビジネス継 続サービスの 3 種類のワークロード モデルと組み合わされています。図 1-9 は、各モデルの高レベルの 概念図であり、ビジネス要件やアプリケーション要件に合わせて各リソースとサービスを組み合わせて 適用できるさまざまな方法を階層形式で示しています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-14 第1章 設計の概要 クラウド サービス 図 1-9 VMDC サービス階層 VMDC 2.3 ではこのような定義が拡大され、Gold サービス階層の拡張として「Expanded Gold」とい うプレミアム層が作られています。このプレミアム層は、制御や差別化されたデータ トラフィック ク ラスに加え、低遅延の Voice over IP（VoIP）およびマルチメディア（動画）トラフィックに対応した SLA を実現するための QoS フレームワークが利用できます。VMDC 2.3 では、SMB の「Copper」階 層も導入されています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-15 第1章 クラウド サービス Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 1-16 設計の概要 C H A P T E R 2 設計の詳細 Virtualized Multiservice Data Center（VMDC）2.3 リリースは、VMDC 2.2 でも採用されたエンド ツーエンドの Virtual Routing and Forwarding (VRF)-Lite、Nexus 7000 の仮想ポート チャネル（vPC） ベースの設計方法を継承しながら、物理トポロジ / プラットフォームおよびテナント モデルを最適化す ることでテナントの拡張性を実現しています。この章では、VMDC 2.3 ソリューションの設計の詳細 について説明します。この章の内容は、次のとおりです。 • ソリューションのアーキテクチャ • Pod および ICS • ソリューションのコンポーネント • セキュアなテナントの分離 • VMDC 2.3 のコンテナ • ハイ アベイラビリティ • サービス保証 • 拡張性に関する考慮事項 • VMDC 2.3 の拡張性 ソリューションのアーキテクチャ VMDC 2.3 システムのリリースでは、VMDC 2.0 および 2.2 で定義されたエンドツーエンド アーキテ クチャを利用しています。このマニュアルでは、ハイ アベイラビリティでモジュラ形式の拡張の基本 原則を再確認し、テナントのスケーラビリティ、テナントの隔離、セキュリティの各分野についてシス テムの機能拡張の概要を説明し、マルチメディおよびコラボレーション アプリケーションに対応した QoS（Quality of Service）フレームワークについて説明します。 VMDC 2.3 システムのアーキテクチャは、VMDC 2.2 に基づいています。VMDC 2.2 では、データセ ンター（DC）内の VRF ボーダー ゲートウェイ プロトコル（BGP）ごとにエンドツーエンドの VRF-Lite を使用します。VMDC 2.2 では、WAN/PE レイヤ（ASR 9000）、コア レイヤ（Nexus 7010）、アグリゲーション レイヤ（Nexus 7018）、およびサービスレイヤ（サービス モジュールが搭載 された Catalyst 6500）で構成された階層型の L3 設計を定義しています。 VMDC 2.3 では、ソリューション全体のコストを削減し、拡張性を（Nexus 7000 での BGP ピアリン グの削減により）高めるために、次の点が変更されています。 • WAN/PE レイヤとして ASR 1000 を使用 • DC コア レイヤを排除 • アグリゲーション デバイスとして Nexus 7004 を使用 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-1 第2章 設計の詳細 ソリューションのアーキテクチャ • 低価格の F2 ラインカードを Nexus 7004 で使用 • Catalyst 6500 Data Center Service Node（DSN）の代わりに、適応型セキュリティ アプライアンス （ASA）およびアプリケーション コントロール エンジン（ACE）アプライアンスを使用して、 Nexus 7004 アグリゲーション レイヤに直接接続 物理トポロジ 図 2-1 は、物理トポロジの観点から VMDC 2.3 のシステム アーキテクチャを示したものです。このシ ステムは、Pod に配置された Nexus 7004 アグリゲーション ノードのペアに接続する 1 ～ 3 基の統合コ ンピューティングおよびストレージ（ICS）スタックから構成されています。また各 ICS は、1 ～ 8 基 の Unified Computing System（UCS）ブレード システム、UCS 6248 ファブリック インターコネクト （FI）のペア、および Nexus 5548UP アクセス スイッチのペアで構成されています。VMDC 2.3 データ センターには 1 ～ 4 個の Pod を配置することが可能です。ASR 1006 WAN/MPLS ルータに接続する Nexus 7004 アグリゲーション ノードは、これらの Pod に配置されます。サービスは、Nexus 7004 ア グリゲーション ノードに接続するセキュリティ アプライアンスから提供されます。テナントごとの ファイアウォール サービスは、ASA 5585-X60 のファイアウォール コンテキストにより提供されます。 サーバ ロード バランシング（SLB）サービスは、ACE 4710 アプライアンスによって提供されます。 リモート アクセス VPN（IPsec および SSL）は、ASA 5555X アプライアンスによって提供されます。 コンピューティング セキュリティは、Nexus 1000V 仮想スイッチに接続された仮想セキュリティ ゲー トウェイ（VSG）によって提供されます。 図 2-1 VMDC 2.3 の物理トポロジ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-2 第2章 設計の詳細 ソリューションのアーキテクチャ 論理トポロジ 図 2-2 は、論理トポロジの観点から VMDC 2.3 のシステム アーキテクチャを示したものです。境界部 分でファイアウォール サービスを提供するために（ASA 5585-X60 上に）L3 ファイアウォール コンテ キストを挿入する必要がある場合、Nexus 7004 のアグリゲーション ノードは、テナントごとにノース バウンド VRF およびサウス バウンド VRF のインスタンスに論理的に分割されます。これは、Gold テ （Nexus でのリソースの節約 ナントにのみ適用されます。Silver および Bronze のテナントについては、 および全体的なソリューションのスケーラビリティを高めるため）Nexus 7004 の VRF インスタンスは 1 つになります。 図 2-2 VMDC 2.3 の論理トポロジ VMDC 2.3 の設計は、次の点で VMDC 2.2 と比較することができます。 • 次の点を除き VMDC 2.2 とほぼ同様です。 – アグリゲーション レイヤの Nexus 7004 が Nexus 7018 に変更されている – コア レイヤがない – 6500 DSN がない • VMDC 2.3 では、テナントの拡張性が向上しています。VMDC 2.2 では、Pod あたり 150 テナン トおよびデータセンターあたり 150 テナントをサポートしていましたが、VMDC 2.3 では Pod あ たり 250 ～ 500 テナント、およびデータセンターあたり 1,000 ～ 2,000 テナントをサポートするこ とができます。 • VM の拡張性については（Nexus 7000 シャーシのポート密度が低く、Nexus 7000 ラインカードの MAC スケールが低いため）、縮小しています。VMDC 2.2 では、Pod あたり 12,000 の仮想マシン およびデータセンターあたり 72,000 の仮想マシンをサポートしていましたが、VMDC 2.3 では Pod あたり 6,000 の仮想マシンおよびデータセンターあたり 24,000 の仮想マシンをサポートしま す。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-3 第2章 設計の詳細 Pod および ICS • サービスは 6500 DSN のモジュールではなく、Nexus 7004 に接続されたアプライアンスが提供し ます。 • ACE 4710 が SLB（4G）を提供し、ASA 5585-X60 がファイアウォール（20G マルチプロトコル） を提供します。また、ASA 5555X が RA-VPN サービス（750 MB）を提供します。 • テナント モデルは、VMDC 2.2 との整合性が維持されています。 • VMDC 2.3 では、Expanded Gold、Silver、および Bronze のネットワーク コンテナが提供されま す。 • VMDC 2.3 では、テナントのスケールを拡大し、中小規模企業（SMB）のお客様の要件満たすた めに、新たに Copper コンテナが導入されています。 • 以前の VMDC のリリースと同様、VMDC 2.3 システムでは VCE Vblock、シスコと NetApp の FlexPod、またはその他の ICS のスタックをサポートしており、動作させることができますが、 VMDC 2.3 システムは FlexPod でのみ検証されています。以前の VMDC のリリースは、Vblock で検証されていました。 Pod および ICS 統合コンピューティングおよびストレージ（ICS）スタック VMDC 2.3 システム アーキテクチャの統合コンピューティングおよびストレージ（ICS）スタック レ イヤで重要な設計上のポイントは、主に次の点です。 • FlexPod は、UCS シャーシ 8 台、6248UP FI 2 台、Nexus 5548UP 2 台、および B200 M3 が 64 ブ レードで構成されています。 • 仮想マシンのサイジングおよびディストリビューションは、アプリケーション要件によって決定し ます。平均すると、UCS シャーシごとに 250 の VM（ブレードあたり 31.5）に設定されています。 • FlexPod あたりの最大 VM 数は 2,000 です。 • Pod あたり 3 つの FlexPod であるため、合計 VM 数は 6,000 になります。 • 各 Flexpod には NetApp ストレージ アレイ (FAS6000/6200) が、NetApp の 7-mode に設定されて 搭載されています。 • VM あたり 2 個の vNIC とすると、合計で 12,000 個の vNIC になります。 • ESX クラスタは 8 台の UCS ブレードで構成されています。 • FlexPod あたり 2 台の Nexus 1000V スイッチであるため、Pod あたり 6 台になります。 図 2-3 は、VMDC 2.3 システムの ICS（FlexPod）トポロジおよびポート密度 / 接続の概要を示したも のです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-4 第2章 設計の詳細 Pod および ICS 図 2-3 VMDC 2.3 の ICS Pod のレイアウト 図 2-4 は、VMDC 2.3 システムの Pod 内のネットワーク トポロジ、ポート密度 / 接続およびサービス アプライアンスの接続について概要を示したものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-5 第2章 設計の詳細 ソリューションのコンポーネント 第 2 章 設計の詳細 図 2-4 VMDC 2.3 の Pod - ネットワークおよびサービスのトポロジ ソリューションのコンポーネント VMDC 2.3 ソリューションは、複数のシスコおよびサードパーティのハードウェア コンポーネントと ソフトウェアのコンポーネントから構成されています。VMDC 2.3 ソリューションの一部として検証 済みのコンポーネントは、表 2-1 に示すとおりです。 表 2-1 VMDC 2.3 ソリューションのコンポーネント 製品 説明 ハードウェア ソフトウェア Cisco ASR 1000 WAN（MPLS-PE） ASR 1006 RP-2、 ESP-40、SIP-40、 SPA-10GE-V2 IOS XE 3.7.1S Nexus 7004 Sup-2 、 N7K-F248-12 NX-OS 6.1(3) ルータ Cisco Nexus 7000 Cisco ACE ASA 5555-X DC の集約 アプリケーション コン ACE 4710-MOD-K9 トロール エンジン （サーバ ロード バラン サ） IPSec および SSL VPN リモート アクセ ス Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-6 ASA 5555-X A 5(2.1) 9.0.1 第2章 設計の詳細 ソリューションのコンポーネント 表 2-1 VMDC 2.3 ソリューションのコンポーネント （続き） ASA 5585-X 適応型セキュリティ ア ASA 5585-X60 プライアンス（ファイ （SSP60 搭載） アウォール サービス） Cisco Nexus 5548 統合型コンピューティ ング / ストレージ ス イッチ Cisco UCS 2.0(4b) コンピューティング シ UCS 5108 ブレード シャーシ、UCS 6248 ステム FI、B200-M2 および M3 サーバ ブレード、 Cisco VIC 1240、VIC 1280、M81KR アダプ タ Cisco Nexus 1010 仮想サービス アプライ アンス NX-OS 4.2(1)SP1(5.1) Cisco Nexus 1000V 分散仮想スイッチ NX-OS Nexus 5548UP 9.0.1 NX-OS 5.2(1)N1(2) 4.2(1)SV2(1.1) Cisco VSG 4.2(1)VSG1(4.1) Nexus 1000V 仮想セ キュリティ ゲートウェ イ Cisco VNMC 仮想ネットワーク管理 センター NetApp FAS SAN ストレージ アレ イ （注） 2.0(3f) FAS6040（実環境用 Pod）FAS3240（管理 用 Pod） ONTAP 8.1.1 VMware vSphere ESXi ハイパーバイザ VMware vSphere 仮想化マネージャ vCenter 5.0.0 Build 804277 VMware vSphere Auto Deploy 5.0.0.3392 5.0.0 Build 821926 VMDC 2.3 ソリューションは、IPSec および SSL VPN リモート アクセスに対応した ASA 55555-X で 検証されています。パフォーマンスとスループットを高めるために、SSP-60 搭載の ASA 5585-X を使 用することもできます。 （注） VMDC 2.3 のコンピューティング Pod では、NetApp FAS6040 は実環境の（データ）VM をホストす るために SAN ストレージ アレイとして使用されます。VMDC 2.3 の管理用 Pod では、管理 VM （VMware Virtual Center、Nexus 1000V VSM 、VNMC、テスト ツール、BMC Cloud Lifecycle Manager（CLM）オーケストレーション スイートなどの管理アプリケーション）をホストするために NetApp FAS3240 が使用されます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-7 第2章 設計の詳細 セキュアなテナントの分離 セキュアなテナントの分離 これまでは、テナントに対して専用のインフラストラクチャを導入していました。共有された共通イン フラストラクチャに複数のテナントを導入することで、低コストでリソース使用率を最適化できます が、エンドツーエンドのパスの分離を保障し、テナントのセキュリティ要件を満たすためのセキュアな テナント分離に対応する設計が必要です。設計時に次の点を考慮することで、セキュアなテナントの分 離とパスの分離が実現します。 • ネットワークの分離 • コンピューティングの分離 • ストレージの分離 • アプリケーション層の分離 • 境界のセキュリティ • DMZ ゾーン ネットワークの分離 専用のインフラストラクチャと同レベルのテナントの分離を提供しながらマルチテナント機能をサポー トするというニーズに対応するために、VMDC リファレンス アーキテクチャでは、共有インフラスト ラクチャを論理的に複数の（テナントごとの）仮想ネットワークに分割するパスの分離方法を利用しま す。この方法はデータパスおよびデバイスの仮想化の両方に依存し、インフラストラクチャの複数の階 層レイヤ全体にエンドツーエンドで実装されています。また、次の各技術が含まれています。 • ネットワーク L3 の分離（コア / アグリゲーション レイヤ）。コア レイヤおよびアグリゲーション レイヤで実装される VRF-Lite は、テナントごとに個別のルーティング テーブルおよび転送テーブ ルを使用することで、L3 におけるテナントごとの分離を実現します。これにより、明示的に許可 していない限り、データセンター内でテナント間（サーバ間）のトラフィックは許可されません。 分離されたインスタンスのルーティングと転送のもう 1 つのメリットは、重複する IP アドレスが サポートされることです。これは、パブリック クラウドや統合、または企業でのプライベートな 利用で IP アドレッシングの移行を伴う場合に必要となります。 • ネットワーク L2 の分離（アクセス、仮想アクセス レイヤ）。VLAN ID および 802.1q タグにより、 L2 ドメイン（より一般的には、インフラストラクチャ全体にわたる共有リンク間）におけるテナ ント トラフィックの分離と識別が実現します。 • ネットワーク サービスの分離（サービス コア、コンピューティング レイヤ）。物理アプライアン スまたはサービス モジュールのフォーム ファクタでは、専用のコンテキストまたはゾーンにより、 仮想化されたセキュリティ、ロード バランシング、NAT、および SSL オフロード サービスの各手 法が提供され、VLAN レベルの粒度でテナントごとに固有のポリシーを適用することができます。 同様に、専用の仮想アプライアンス（vApp 形式）は VM レベルの粒度でインフラストラクチャの コンピューティング レイヤ内でテナントごとに固有のサービスを提供します。 コンピューティングの分離 これまで、セキュリティ ポリシーは物理サーバ レベルで実装されていましたが、サーバの仮想化とモ ビリティにより新しいセキュリティ上の課題や問題が発生しています。実際には、このような問題に対 処するため、ポリシーは VM レベルで実装する必要があります。また、ホストからホストに移行する 際に VM を追跡できる必要があります。 インフラストラクチャのコンピューティング レイヤでは、次の技術を使用してテナントごとのトラ フィック分離を実現しています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-8 第2章 設計の詳細 セキュアなテナントの分離 • vNIC。高度に仮想化されたデータセンターでは、物理 NIC ではなく複数の vNIC を使用してトラ フィック分離を実現しています。たとえば VMDC 2.X では、バック エンドの管理トラフィックか ら本番（データ）トラフィックを論理的に分離するために、複数の vNIC が使用されています。こ れは Cisco UCS 仮想インターフェイス カード（この場合 VIC M81KR）で実現されます。これに より仮想アダプタを作成し、ハイパーバイザ内で一意な VM および VMkernal インターフェイス にマッピングすることができます。 • VLAN。VLAN は、Nexus 1000V 仮想アクセス スイッチ ドメインを含め、インフラストラクチャ のコンピューティング層内で L2 ドメイン間の論理的な分離を実現します。 • ポート プロファイル。シスコの VN-Link テクノロジーと組み合わせることで、ポート プロファイ ルは VLAN および VM（vNIC）レベルの粒度でテナントのトラフィックを分離し、セキュリティ ポリシーを適用する手段を提供します。ポート プロファイルは、仮想アクセス スイッチ ドメイン で実装され、vCenter のポート グループにマッピングされます。これにより、VMotion イベント によるポリシーのモビリティを提供します。 ストレージの分離 VMDC リファレンス アーキテクチャでは、共有インフラストラクチャのストレージ ドメイン内での VM データ ストアの分離を次のように実現します。 • クラスタ ファイル システム管理。vSphere ハイパーバイザのクラスタ ファイル システム管理で は、VM ごとに固有の VM ディスク（VMDK）を作成し、複数の VM が Virtual Machine File System（VMFS）ボリューム内の同じ VMDK サブ ディレクトリにアクセスできないようにする ため、あるテナントの VMDK を他のテナントから分離します。 • VSAN および FC ゾーン分割。VSAN および FC ゾーン分割によって共有 SAN ファブリックをよ り小さな論理ドメインにセグメント化することで、物理ホスト レベルの粒度で分離を行います。 • LUN マスキング。論理ユニット番号（LUN）マスキングによって、共有 SAN の特定のホストへ のストレージ LUN アクセスを制限する認証プロセスを作成します。この技術を FC ゾーン分割と Cisco MDS SAN スイッチ システムに実装された VSAN と組み合わせることで、ストレージ アレ イ内で SAN スイッチ ポートから物理ディスクおよび仮想メディアに、効果的にテナント データ ストアの分離を進めます。 • vFiler。vFiler は NetApp NAS システムでサポートされ、NFS データ ストアを論理的に分離しま す。vFiler は IP アドレス（IPspace）に関連付けられます。802.1q VLAN および ACL ベースのセ キュリティ ポリシーの適用と組み合わせて使用し、共有インフラストラクチャ全体で、特定のテ ナントまたはテナント グループの NFS データ ストアへのアクセスを制限します。 アプリケーション層の分離 多くのアプリケーションは、Web、アプリケーション、およびデータベースの各層で構成された 3 階層 の機能モデルに従っています。Web 層のサーバは、公開されたアプリケーションの「フロントエンド」 プレゼンテーション サービスを提供しますが、アプリケーション層およびデータベース層のサーバは、 ミドルウェアおよびバックエンド処理コンポーネントとして機能します。この機能分割により、Web 層のサーバは、ユーザ コミュニティの範囲に比例して脆弱性のレベルが増し、悪意のある攻撃の対象 となりやすくなると一般的に考えられています。企業のプライベート クラウドやパブリック クラウド 内の企業の VPDC だけでなく、パブリック インターネットでアクセスできるように開発されたアプリ ケーションは広い範囲に対応するため、重大なセキュリティ上の懸念事項となります。 アプリケーション層の分離は、次のような複数の方法で実施します。 1. ネットワーク中心の方法。この方法では、L2 ドメイン内で VLAN を使用し、各層のサーバを論理 的に分離する必要があります（図 2-5 の左側参照）。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-9 第2章 設計の詳細 セキュアなテナントの分離 2. サーバ中心の方法。この方法は、個別の VM vNIC をデイジー チェーン サーバ層と一緒に使用す ることで実施します（図 2-5 の右側参照）。 図 2-5 VLAN および vNIC のアプリケーション層の分離 それぞれの方法には利点と欠点があるため、どちらの方法を採用するのかは、具体的な導入の特性と運 用上の問題に応じて決定します。アーキテクチャの観点から、ネットワーク サービスのアプリケー ションは重要な要素です。サーバ中心の方法は、vApp ベースの仮想化サービスの挿入に適していま す。シスコの場合は、Nexus 1000V vPath のパワーを活用して、インフラストラクチャの仮想アクセス スイッチ レベルでトラフィック フローを分類し、より効果的にリダイレクトしています。ネットワー ク中心の方法が適しているのは、階層のサービス コア レイヤで interVLAN フローのルーティングを使 用して、インフラストラクチャのコンピューティング層以外から一部またはすべてのサービスを適用す る設計です。管理の観点から、IT エグゼクティブがネットワークおよびサーバ運用者の専門知識につ いて検討する場合は、中央集中型または分散化が進んだテナント セグメンテーションまたはサービス アプリケーション モデルをサポートするために必要となる利用可能な管理ソリューションについても 併せて考慮する必要があります。 ネットワーク中心の方法は、従来どおりのアプローチです。現在のところ、適用するサービスのすべて が vApp 形式で利用できるわけではないため、ネットワーク中心のモデルからハイブリッド サービス アプリケーションへ移行する傾向にあります。この場合、あるサービスはサービス コアからより集中 的に適用され、またあるサービスはインフラストラクチャのコンピューティング レイヤ内部から適用 されます。これは特にセキュリティ サービスという点で理にかなっており、運用プロセスとビジネス ポリシーの適用の観点から、一部を集約してより厳格に制御しながらその他を分散させることにより、 階層的にポリシー実施を導入する場合に必要です。この傾向により、セキュリティ ポリシーの実施に 対してハイブリッド アプローチの採用が推進されています。 アプリケーションの分離を考慮する場合は、各層のサーバ間で必要とされる通信が最小限に抑えられる ことを前提に、まず各階層を厳格に分割することに着手するのが一般的です。このやり方は、ファイア ウォールを使用して各層で分離を適用する際も推奨される場合があります（図 2-6 を参照）。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-10 第2章 設計の詳細 セキュアなテナントの分離 図 2-6 3 階層のファイアウォールの例 このアプローチは、理論としては合理的に見えますが、実際には単純すぎるということがすぐに分かる はずです。問題の 1 つは、アプリケーションが複雑で、必ずしも厳格な階層トラフィック フロー パ ターンに従っていない点です。たとえば一部のアプリケーションがデータベース中心の方法で機能する ように作成され、データベース コアからミドルウェア（アプリケーション）、さらにはプレゼンテー ション（Web）層へと続く通信フローを持つのに対し、別のアプリケーションはミドルウェア レイヤ を利用するように作られている場合などです。特に企業において共通して発生する別の問題として、一 部のアプリケーション フローが、組織の境界を越えて、もしくはサイト間で、プライベート クラウド テナントまたはワークグループのコンテナの外部に拡張する必要がある点です。最後に、アプリケー ション層自体がデータセンター間、またはエンタープライズ キャンパス間（プライベートの場合）で 論理的または物理的に分散される場合がある点です。この結果、ポリシーのエンフォースメント ポイ ントが不必要かつ不適切に急増し、送信元から宛先までのエンドツーエンドのパス上で、トラフィック が不必要に複数のファイアウォールを通過する可能性があります。 ハイブリッドな 2 階層のファイアウォール モデル（図 2-7）では、VMDC アーキテクチャは従来のセ キュリティのベスト プラクティスに従った多層防御を可能にしながら、物理的で仮想化されたインフ ラストラクチャでのファイアウォールの急増を軽減するシンプルなフレームワークを提供します。前述 したとおり、このフレームワークの利点は階層型のポリシーの定義が可能な点で、テナント コンテナ の外側の境界においては厳密かつ詳細に適用し、テナント コンテナ内では緩やかで粒度の荒い適用が 可能です。また、このフレームワークでは、ポリシーの実施も物理から仮想に適切に移行されるため、 クラウドの管理者は既存のインベントリと専門知識を活用することができます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-11 第2章 設計の詳細 セキュアなテナントの分離 図 2-7 VMDC 2 層ハイブリッド テナントのファイアウォール モデル Virtual Security Gateway Virtual Security Gateway（VSG）は 今回初めて VMDC リファレンスアーキテクチャに採用された製 品です。VMDC アーキテクチャでは、テナント間の通信（許可されている場合）はアグリゲーション レイヤでのルーティングを介して確立されますが、図 2-8 では、VSG 仮想セキュリティ アプライアン スがテナント内部の第 2 層のファイアウォールとして機能し、アプリケーション層内部とアプリケー ション層間の通信、およびクライアントからサーバへの通信をフィルタリングする方法を示していま す。VSG は Nexus 1000V 分散仮想スイッチ（DVS）と密接に統合されており、1000V 仮想イーサ ネット モジュール（VEM）内に埋め込まれた仮想ネットワーク サービス パス（vPath）テクノロジー を使用します。Nexus 1000V 内の vPath の機能は、スイッチング ロジックをホストに直接オフロード し、高性能でシームレスな他の仮想アプライアンスとの対話と、アプライアンスの障害に備えた復元力 を提供します。パケットの大部分がハイパーバイザにオフロードされ、高速パスで処理されるため、パ フォーマンスが大幅に向上します。さらに、Cisco Nexus 1000V vPath はテナントを認識し、テナント 内および複数のテナント間におけるセキュリティ ポリシーの導入を実現します。 VSG のマルチテナント サポートは、階層型ポリシー モデル（図 2-8）に依存します。このモデルで は、各テナントを 3 つのサブ レベルに割り振ります。通常これらは、仮想データセンター（vDC）、 vApp、および階層レベルと呼ばれます。セキュリティ ルールおよびポリシー定義は、階層の任意のポ イントで設定できます。これらのルールは、エンフォースメント ポイント以降（図 2-8 のテナント レ ベル）にあるすべての VM に適用されます。Root レベルのポリシーやプールは、システム全体に適用 され、すべての組織で使用可能になります。VMDC などのマルチテナント システムでは、適切なテナ ントの分離とポリシー制御を実施するために、VSG の一意のインスタンスを各テナントに対して展開 する必要があります。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-12 第2章 設計の詳細 セキュアなテナントの分離 図 2-8 VSG の階層型ポリシー モデル VSG の階層型ポリシーの分類は、より複雑なポリシー ルール セットに対して利用可能ですが、すべて のポリシー レベルを使用する必要はありません。たとえば、VMDC システムのリファレンス モデルで は、VSG ポリシー モデルによりサブ テナントが可能ですが、一般的に各テナント コンテナは、それ ぞれ複数のアプリケーション層を持つ単一の vDC として想定され、アプリケーションの複数カテゴリ をサポートする必要があります。図 2-9 は、特定のアプリケーション カテゴリ（この場合は SharePoint）の例を使用してこのマッピングを示したものです。実装では、不必要な複雑性がなく、セ キュリティ ポリシー プロファイルの要件を満たす実用的でシンプルなアプローチに従う必要がありま す。 図 2-9 VMDC のテナントにマッピングされている VSG ポリシー プロファイル階層 VSG のアクセス制御は、伝送制御プロトコル（TCP）/ ユーザ データグラム プロトコル（UDP）ポー ト、VM、またはカスタム属性に基づいて、パケットの送信元と宛先間のネットワーク トラフィックに 対して適用できます。これにより、シンプルなレガシーのステートフル パケット フィルタリング ファ イアウォールよりもはるかにコンテキストに適合したポリシー定義が実現されます。クラウドベースの インフラストラクチャは動的な環境です。このような環境でアプリケーションを分離した場合、Nexus 1000V DVS にポリシーのエンフォースメントを移動することで、VM があるハイパーバイザから論理 DVS 境界内の別のハイパーバイザに移動した場合に、ポリシー ゾーンがその VM を自動的に追跡する ようになります。これが、VSG の主なメリットといえます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-13 第2章 設計の詳細 セキュアなテナントの分離 本マニュアルの執筆時点では、Nexus 1000V VSG リリース 1.5 は、送信元 / 宛先フィルタリングにつ いて次のポリシー属性をサポートしています。 • src.net.ip-address • src.net.port • dst.net.ip-address • dst.net.port • net.ip-address • net.port net.protocol • net.ethertype • src.vm.name • dst.vm.name • vm.name • src.vm.host-name • dst.vm.host-name • vm.host-name • src.vm.os-fullname • dst.vm.os-fullname • vm.os-fullname • src.vm.vapp-name • dst.vm.vapp-name • vm.vapp-name • src.vm.cluster-name • dst.vm.cluster-name • vm.cluster.name • src.vm.inventory-path • dst.vm.inventory-path • vm.inventory-path • src.vm.portprofile-name • dst.vm.portprofile-name • vm.portprofile-name • src.vm.custom.xxx • dst.vm.custom.xxx • vm.custom.xxx 境界のセキュリティ 従来のセキュリティ モデルでは、ユーザ コミュニティまたはゾーンの信頼できる区間と信頼できない 区間の定義された境界でポリシーのエンフォースメントを適用することがベスト プラクティスとされ ていました。セキュリティ ゾーンは、共通のポリシー属性を共有するコンピューティング、ネット Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-14 第2章 設計の詳細 セキュアなテナントの分離 ワーク、およびストレージ リソースの論理構造で構成されています。この構造内の共通属性を利用し て、そのゾーン内のすべてのリソースに適用されるセキュリティ ポリシーを作成できる場合もありま すが、高度に仮想化されたシステムでは、どこに境界が存在するか定義が難しい場合があります。これ は、特にマルチテナントで使用する場合にあてはまります。このシステム リリースでは、パブリック またはプライベートのクラウドのインフラストラクチャで、エンタープライズ クラスのテナントのセ キュリティを維持するため欠かせない 3 つの境界が定義されています。 1. フロントエンド テナントの境界。信頼が低いゾーンとクラウド内のテナント vDC の内部との境界 です。 2. （VDC 内部）バックエンド テナントの境界。テナントのフロントエンド サーバとバックエンド サーバ間の境界です。 3. バックエンド管理の境界。テナントの「本番」サーバとバックエンドのインフラストラクチャ管理 サーバ間の境界です。 これらの境界間には、次のゾーンが定義されています。 1. パブリック / 共有。このゾーンは、パブリック インターネット、エンタープライズ キャンパス、ま たはリモート アクセス VPN（図 2-10 では図示されていません）をソースとするより広範囲の外 部クライアントからテナント vDC に入る手段を提供します。これは、（テナントの vDC 内に比べ て）信頼度が低いまたは無いゾーンです。このゾーンは、潜在的に一般 / 共有インフラストラク チャの非武装地帯（DMZ）を保持することに注意してください。 2. プライベート。プライベート ゾーンはクラウドのバックボーン（つまりプライベート WAN のバッ クボーンまたは公共のプロバイダー IP/NGN）経由でテナント vDC に入る方法を提供します。後 者の場合、クライアントが通常はパブリック IP/NGN 経由でプライベート L2 または L3 MPLS VPN を利用し、アクセスすることが予期されます。 3. テナントの DMZ。このゾーンはテナントごとの DMZ を提供します（企業またはパブリック プロ バイダーのインフラストラクチャの一般的な DMZ と対比されます）。すべてのテナントの vDC が DMZ ゾーンを備えているわけではありません。 4. テナントのフロントエンド（Web）。これは、フロントエンド アプリケーションのプレゼンテー ション サーバの配置に適した一般的なフロントエンド サーバ ゾーンを提供します。 5. テナントのバックエンド。最低でも、アプリケーションおよびデータベース サーバ用の 2 つの ゾーンで構成されます。必要に応じて、複数のタイプのアプリケーションや、その他のアプリケー ションまたはポリシー固有の目的に対応できるように追加することも可能です。 6. バックエンド管理。このゾーンは、インフラストラクチャの管理に使用するバックエンド サーバ で構成されます。各サーバは、管理スタック ソリューションの要件に応じて、仮想またはベアメ タル サーバのいずれかになります。 図 2-10 と図 2-11 は、共有された仮想および物理インフラストラクチャ上に、このモデルが論理的にど のようにオーバーレイされるのかを示したものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-15 第2章 設計の詳細 セキュアなテナントの分離 図 2-10 テナントの境界とゾーン 図 2-11 インフラストラクチャ管理ゾーン 図 2-11 では、管理 vNIC の個別のセットにより、テナント VM を「デュアルホーム接続」できます。 この場合、 「本番」環境およびバックエンドのインフラストラクチャ管理の Nexus 1000V の各インスタ ンスにあるポート プロファイルを使用します。また、ポリシーのエンフォースメントを拡張するため に、管理コンテナで複数の VSG を使用することもできます。このフレームワークでは、次のようなさ まざまなオプションに柔軟に対応できます。 • プロバイダー（インフラストラクチャ）の DMZ（図 2-11 には図示されていません）。 • 追加の信頼されていないゾーンおよびネストされたゾーン。リモート VPN とインターネットまた はキャンパス アクセス用に、単一の共有パブリック ゾーンではなく、信頼されていないゾーンを さらに分割することができます。パブリック プロバイダーのコンテキストに該当する使用例では、 独立系ソフトウェア ベンダー（ISV）へのアクセス用の個別のゾーンまたはテナントごとの専用パ ブリック アクセス ゾーンが提供されます。 • ネストしたフロント / バックエンド ゾーン。たとえば、DMZ サーバやより一般的なアプリケー ションのプレゼンテーション サーバ用に、単一のフロントエンド テナントのゾーン内で異なるポ リシー ルール セットを持つ、2 つのネストされたゾーンが存在する場合があります。同様に、ネ ストされたバックエンド ゾーンでは、「開発テスト」用のバックエンド サーバから「本番」用の サーバを容易に分離できます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-16 第2章 設計の詳細 セキュアなテナントの分離 • 従来のセキュリティ ベスト プラクティスへの適応。たとえば、ロールベースのインフラストラク チャまたはサーバ /VM のアクセス制御（RBAC）は、Lightweight Directory Access Protocol （LDAP）または RADIUS ディレクトリに関連付けられています。このシステムまたはリリースで は RBAC に重点は置かれていませんが、基本的なセキュリティ要件です。異なるアクセス ポリ シーを適用できるロール カテゴリ（テナント ユーザ、テナント管理者、管理ユーザなど）の定義 が前提条件となります。 DMZ ゾーン 非武装地帯（DMZ）は、プライベートな「内部」ネットワークと外部のパブリック ネットワーク間の 「中立ゾーン」として挿入される小さなネットワークです。DMZ の役割は、外部ユーザがプライベー ト データのあるサーバに直接アクセスするのを防ぐことです。多くの場合、DMZ 内に配置されたサー バは、Web サイトやパブリック ネットワーク上でアクセス可能な他の企業へのアクセスに使用するプ ライベート ネットワーク内で、ユーザからの要求を代理することによって境界のファイアウォール セ キュリティを向上させます。プロキシ サーバは、パブリック ネットワーク上でこれらの要求に対する セッションを開始しますが、プライベート ネットワークに戻るセッションを開始することはできませ ん。ここでは、要求されたパケットの転送のみ可能です。では、DMZ ゾーンは、どのようにクラウド 上のテナント vDC に挿入されるのでしょうか。DMZ ゾーンの配置には、2 種類の基本モデルを使用し ます。図 2-12 で示すように、モデル 1 では、DMZ ゾーンが内外のゾーンと同じネットワーク機器に 接続されています。モデル 2 では、DMZ がフロントエンドとバックエンドのファイアウォール間の中 継ゾーンに配置されています。従来から、モデル 2 のほうがわずかに安全性が高く、ファイアウォール は 1 つよりも 2 つの方が良いと考えられていました。これは、多重防護による対策であり、ファイア ウォールの外側にあるフロントエンドが誤って設定されている場合でも、2 番目のファイアウォールの セキュリティ対策によって保護が提供されます。VMDC 2.3 リリースで拡張された vDC/VPDC のテナ ント モデルに組み込まれているのは、この 2 番目の配置オプションです。 図 2-12 DMZ の配置オプション このシステムでは、テナント vDC 内の DMZ のアプリケーションを重視していますが、通常はインフ ラストラクチャの共有部分にも DMZ が存在します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-17 第2章 設計の詳細 VMDC 2.3 のコンテナ 図 2-13 は、VMDC 2.3 の設計が持つ階層型セキュリティ モデルと多重防護の側面について示したもの です。Expanded Gold コンテナには 2 つのゾーンがあり、それぞれが独自のフロントエンドの境界ファ イアウォール（ASA）とバックエンドのコンピューティング ファイアウォール（VSG）を持ちます。 図 2-13 DMZ およびプライベート ゾーンを持つ VMDC 2.3 の階層型セキュリティ VMDC 2.3 のコンテナ VMDC 2.3 のテナント モデル（ネットワーク コンテナ）は、これまでの VMDC 2.2 フェーズで規定さ れていたものとの整合性を保ちながら、DC プラットフォームでのリソース消費を抑え、より高いテナ ントの拡張性を実現するために最適化されています。テナントの拡張性を向上させる目的でテナント モデルに加えられた最適化としては、次のようなものが挙げられます。 • 基本サービスと VLAN 1 つおよび VM 4 ～ 5 つを必要とするテナント用に、新しく Copper コンテ ナが定義されています。一般的にこのコンテナは、パブリック クラウドのワークロードを減らす ことを検討している SMB のお客様が対象となります。このような Copper コンテナのクラウド リ ソースは、インターネット経由でのみアクセスできます。インターネットからのアクセスにグロー バル ルーティング テーブルを使用し、各テナントの保護に共有ファイアウォールを使用するため、 このコンテナでは、ファイアウォール コンテキストと、ASR 1000 PE および Nexus 7004 アグリ ゲーション ノード上の VRF/BGP リソースの消費が少なくなります。 • VRF の分離は、各テナントのタイプで必須です。 • コア レイヤおよび 6500 DSN が排除されています。 • 拡張性を高めるためにテナントが最適化されており、Pod あたり 500 テナント、DC あたり 2,000 テナントを実現しています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-18 第2章 設計の詳細 VMDC 2.3 のコンテナ • Catalyst 6500 DSN が使用されていないため、Silver モデルおよび Bronze モデルが簡素化され、 リソースの消費が少なくなっています。Silver コンテナおよび Bronze コンテナでは、Nexus 7004 アグリゲーション レイヤから、ノース バウンドおよびサウス バウンドの VRF インスタンスがな くなりました。これにより、Nexus 7004 の VRF および VLAN リソースが節約されます。 • 設計を簡素化し、ホットスタンバイ ルータ プロトコル（HSRP）と Nexus 7004 上の VLAN のリ ソース消費量を少なくするために、ACE がワンアーム モードで使用され、ServerVLAN レイヤに 移動されています。VM がリターン トラフィックを ACE に返すように、送信元 NAT が ACE 上で 利用されています。 • Silver コンテナでは最適化された ACE ワンアーム モデルが使用されていますが、システムは Silver および Gold コンテナのロード バランシング フローおよび非ロード バランシング フローを 引き続き実行できます。システムは垂直方向または水平方向のトラフィックのロード バランシン グを（VLAN 上で）実行できます。VM は、引き続きデフォルト ゲートウェイとして Nexus 7000 を使用します。 • Gold コンテナは新しい Silver コンテナとの整合性が保たれるように調整されているため、VMDC 2.3 で配置された Silver テナントは簡単に Gold テナントに変換できるようになりました。 VMDC 2.3 システム アーキテクチャのサービス レイヤのキー アスペクトとしては、次のようなものが 挙げられます。 • 物理的に Nexus 7004 アグリゲーション ノードに接続する ASA および ACE アプライアンス • 最上部と最下部の VRF インスタンス間に物理的に配置された ASA（Gold の場合） • 最下部の VRF インスタンスの下に配置された ACE • ファイアウォール用の ASA 5585-X（250 コンテキストをサポート） • リモート アクセス IPsec/SSL VPN 用の ASA 5555（スループット要件が低いため） • SLB 用の ACE 4710 • サーバ VLAN と同じ VLAN に移行したワンアーム モードの ACE 以下の図は、VMDC 2.3 システム用に定義された各テナント モデルを示したものです。 図 2-14 VMDC 2.3 Expanded Gold コンテナ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-19 第2章 VMDC 2.3 のコンテナ 図 2-15 VMDC 2.3 Gold コンテナ 図 2-16 VMDC 2.3 Silver コンテナ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-20 設計の詳細 第2章 設計の詳細 VMDC 2.3 のコンテナ 図 2-17 VMDC 2.3 Bronze コンテナ 図 2-18 VMDC 2.3 Copper コンテナ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-21 第2章 設計の詳細 ハイ アベイラビリティ ハイ アベイラビリティ クラウドベースのサービス展開を成功に導くためには、特にサービス保証または SLA 保証を達成する 必要があり、インフラストラクチャの高い可用性（ハイアベイラビリティ）は欠くことのできない重要 な基礎技術になります。したがって、VMDC リファレンス アーキテクチャは、単一障害点を排除し、 インフラストラクチャの可用性が最も高くなるよう設計されていますが、復元力にはコストと複雑性の 増加がつきものです。この取り組みを継続的に達成するためには、多元的な観点から復元のための機能 を設計し検証していくことです。このため、アーキテクトやエンジニアに対して特定のビジネス サー ビス目標や技術要件を満たすためにどのソリューションが適しているかを判断できるような情報を提供 することが重要になります。 ここでは、次のトピックについて説明します。 • 冗長ネットワーク設計 • L2 の冗長性 • L3 の冗長性 • コンピューティングの冗長性 • ストレージの冗長性 • サービスの冗長性 冗長ネットワーク設計 VMDC 2.0 および VMDC 2.2 で説明したように、リファレンス アーキテクチャでは、インフラストラ クチャの HA 設計 に階層型のアプローチを採用しています。図 2-19 は、復元メカニズムがインフラス トラクチャの各レベルでどのように使用されているのかを示したものです。このような要素として、次 のものが挙げられます。 • 冗長リンク、ノードおよびパス、エンドツーエンド • コア レイヤ。冗長 L3 パス、リンクおよびノード、冗長スーパーバイザ • サービス コア（図示されていません）。冗長ノード、冗長データおよびコントロール プレーン、冗 長スーパーバイザ、リンクおよびパス • アグリゲーション レイヤ。冗長デフォルト ゲートウェイ（Nexus 7000 アグリゲーション ノード）、 冗長スーパーバイザ、冗長リンクおよび L3 パス • アクセス レイヤ。冗長ノード、スーパーバイザ、リンク • コンピューティング レイヤ。UCS - 冗長ファブリックおよびコントロール プレーン、クラスタ内 HA • 仮想アクセス。冗長転送パス（CNA） • ストレージ。冗長 SAN スイッチング システム（図示されていません）、冗長コントローラ、RAID • 管理サーバ（図示されていません）。クラスタ内 HA、管理サーバ間のクラスタリングまたはミ ラーリング、vCenter Server のハートビート、スナップショットおよびクローニング Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-22 第2章 設計の詳細 ハイ アベイラビリティ 図 2-19 階層型 HA モデル L2 の冗長性 VMDC リファレンス アーキテクチャでは、インフラストラクチャのさまざまなポイントで最適なマル チパス機能を提供するために、L2 の冗長性メカニズムを使用しています。このメカニズムは、仮想 ポート チャネル（vPC）、Multi-Chassis EtherChannel（MEC）、および MAC-pinning で構成されてい ます。 仮想ポート チャネル シスコが開発した革新的技術である vPC は、ポートチャネル テクノロジー（IEEE 802.3ad）をベース にしており、PortChannel 接続デバイスと参加スイッチのペア間で複数のリンクの使用を可能にしま す。2 台のスイッチが vPC ピアのエンドポイントとして機能し、デバイスからは単一の論理エンティ ティのように見えます。トラフィックはすべてのリンクに転送され、ロード バランスされますが、1 つ の論理パスに束ねられるためループは発生せず、スパニングツリーのループを回避する必要はありませ ん。パスで構成された複数のアクティブ リンクにより、一般的に vPC はスパニングツリー プロトコル （STP）プロセスに比べて高速なリンク障害の回復を実現します。この処理には、L2 トポロジの再学習 を伴います。ロード バランシングの利点とハードウェア ノードの冗長性およびポートチャネルのルー プ管理を組み合わせることで、vPC は最適なリンク帯域幅使用率を実現します。このような理由から、 リファレンス アーキテクチャでは可能な限り vPC を活用することが推奨されます。具体的には、これ までと同様に今回のリリースでは、Nexus 7000 アグリゲーション レイヤと、Nexus 5000 アクセス ノードまたは UCS 6100 ファブリック I/O モジュール間の L3/L2 の境界の下に vPC が展開されていま す。繰り返しになりますが、前回のリリース同様、設定ミスがあった場合のループを回避するため、イ ンフラストラクチャの L2 部分で STP をイネーブルにすることが推奨されます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-23 第2章 設計の詳細 ハイ アベイラビリティ Multi-Chassis EtherChannel ポートチャネル テクノロジーに基づくその他のシスコのイノベーションとしては、マルチシャーシ EtherChannel（MEC）が挙げられます。MEC は、スイッチの 2 台のシャーシにまたがるポートチャネ ルとなっています。この場合は、インフラストラクチャのサービスコアの DSN として適用されます。 PortChannel 接続デバイスは、MEC を標準ポートチャネルとして認識します。vPC と同様に、MEC は 複数のリンクおよび冗長ハードウェア ノードにまたがり、最適なリンク帯域幅使用率を実現します。 MEC はインフラストラクチャのアグリゲーション レイヤにある Nexus 7000 ノードとサービス コア レ イヤの DSN の間に復元力のあるルーティング パスを提供します。 MAC-pinning UCS 内では、VMNIC はアップリンク パスに動的または静的にピン接続されます。リファレンス アー キテクチャでは、システム全体できめ細かいロード バランシングおよび冗長性を実現するために、 Nexus 1000V と MAC-pinning が組み合わせて使用されています。MAC-pinning は、通知パケットを 使用してこの処理を実行します。リンク障害の発生時は、宛先の VM に到達するために必要な新しい パスのアップストリーム スイッチに通知します。この通知は UCS 6100 シリーズ ファブリック イン ターコネクトに送信され、DC アクセス レイヤ ネットワークが新しいパスを学習できるように、MAC アドレス テーブルを更新し、アップリンク ポートに Gratuitous Address Resolution Protocol（GARP） メッセージを送信します。 L3 の冗長性 HSRP ホットスタンバイ ルータ プロトコル（HSRP）はファースト ホップ冗長プロトコル（FHRP）であり、 冗長なデフォルト ゲートウェイの作成を可能にします。HSRP では、IP アドレスおよび MAC（L2） アドレスを共有することで、複数のルータが 1 つの「仮想」ルータとして動作できます。仮想ルータ グループのメンバは常にステータス メッセージを交換し、あるルータが予定されたまたは予定外の理 由によって稼働しなくなった場合に、別のルータがルーティング処理を請け負うことができます。仮想 ルータ グループでスタンバイ ルータへのフェールオーバーが発生しても、同じ IP アドレスおよび MAC アドレスに IP パケットを転送し続けるため、ホストに対して透過的です。HSRP は見かけ上 「アクティブ / スタンバイ」状態の vPC と上手く相互運用するように拡張されているため、仮想ルータ の MAC アドレスに転送されるパケットがアクティブおよびスタンバイの HSRP ピアによってローカ ルとして受け入れられますが、応答はアクティブな HSRP ピアからのみ送信されます。デフォルト ゲートウェイの冗長性を提供するために、HSRP はインフラストラクチャのアグリゲーション レイヤ 内で Nexus 7000 ノード上（つまり Nexus 7000 アグリゲーション スイッチの SVI インターフェイス上 に L3 終端を持つすべての VLAN）に配置されています。 BGP L3 IP ルーティング プロトコルは VMDC モデルのアグリゲーション レイヤおよびエッジ レイヤで必要 です。さまざまなリリースを通して、VMDC ソリューションは Open Shortest Path First（OSPF）プロ トコルおよび BGP プロトコルの両方で検証されてきました。このリリースでは、BGP は DC 内でエン ドツーエンドで使用されています。BGP は、インフラストラクチャの L3 部分で IP 接続を確立して維 持するために使用されます。この場合は、外部ボーダー ゲートウェイ プロトコル（eBGP）は、ノー ドまたはリンク パスに障害が発生した場合に備えて冗長 L3 パスに再ルーティングして、定義された各 自律システム（WAN およびアグリゲーション レイヤ）間のルートをアドバタイズします。Internal Border Gateway Protocol（iBGP）を含む Interior Gateway Protocol（IGP）ではループバック イン ターフェイスのアドレッシングの使用が一般的であり、OSPF については、リンクに障害が発生して Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-24 第2章 設計の詳細 ハイ アベイラビリティ も、アクティブなリンクでトラフィックを復元しながら、ルーティングされたパスの TCP セッション が維持されます。ピア インターフェイスが直接接続されている場合、ループバック インターフェイス は eBGP シナリオには適用されませんが、直接接続されていないインターフェイスでピアリングが必 要な場合は、追加設定によって使用できます。このシナリオでは eBGP マルチホップを使用するほう が一般的で、外部ピアリング インターフェイスが直接接続されていない場合は、常に IGP または静的 ルートと組み合わせて使用する必要があります。 デフォルトでは、AS から利用可能な外部の等コスト パスが複数存在する場合、BGP は 1 つの最良パ スを選択します。VMDC 2.3 ソリューションでは、これは正常な状態で使用可能なインフラストラク チャの帯域幅の半分の使用率になります。使用可能な帯域幅を最大限に活用するため、トラフィックは 冗長パス上でロード バランスされます。2 つの eBGP ピア間のパラレル パスでは、トラフィックの ロード バランシングを行うために、eBGP マルチホップ（および eBGP ピアの到達可能性を伝達する IGP または静的ルート）とともにループバック インターフェイスを使用できます。VMDC ソリュー ションの場合、エッジおよびアグリゲーション DC ルータ間の冗長 eBGP パスにおいて、トラフィック の識別とロード バランスを行うためにコミュニティ ストリングを使用します。 システムで利用されている L3 の復元力をさらに最適化する手段として、Cisco Nonstop Forwarding （NSF）、Nonstop Routing（NSR）、LDP 同期、および MPLS グレースフル リスタートなどが挙げられ ます。一般的に、L3 高速コンバージェンスの調整には、hello タイマーとホールド タイマーおよび ルート アグリゲーションの調整をする BGP グレースフル リスタートなどが使用されます。 コンピューティングの冗長性 インフラストラクチャのコンピューティング レイヤの冗長性をイネーブルにするには、次の機能の活 用が推奨されます。 • UCS エンドホスト（EH）モード • Nexus 1000V および MAC-pinning（前述） • アクティブ / スタンバイ モードでの冗長 VSM および VSG • VMware HA（クラスタ内） UCS エンドホスト モード UCS は、冗長電源、ファブリック（つまりデータ プレーン）、コントロール プレーン、I/O を持つ高度 な冗長アーキテクチャを提供します（図 2-20 を参照）。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-25 第2章 設計の詳細 ハイ アベイラビリティ 図 2-20 UCS インフラストラクチャのこのコンピューティング レイヤでは、VMNIC が UCS ファブリック アップリ ンクに動的または静的にピン接続されます。これらのアップリンクはアクセス レイヤ スイッチング シ ステムに接続し、ネットワークに対する冗長性を提供します。VMDC ソリューションでは、UCS ファ ブリック インターコネクトのアップリンクはエンドホスト（EH）モードで動作します。このモードで は、アップリンクはファブリックの他の部分に接続するサーバ ポートと見なされます。この機能がイ ネーブルの場合、STP は無効になり、アップリンク間の切り替えは許可されません。このモードはデ フォルトであり、アップストリーム デバイスが L2 スイッチングの場合に推奨される設定です。EH モードの主な利点は次のとおりです。 • すべてのアップリンクが使用されます。 • アップリンクは複数のアップストリーム スイッチに接続できます。 • スパニングツリーは必要ありません。 • コントロール プレーンが専有されないため、高い拡張性がもたらされます。 • アップリンクでの MAC ラーニングを行いません。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-26 第2章 設計の詳細 ハイ アベイラビリティ Nexus 1000V および MAC-pinning UCS は、2 系統の冗長内部ファブリックのうちの 1 つで、特定のホスト インターフェイスのトラ フィックをロード バランスします。デフォルトでは、ファブリックが失敗した場合、トラフィックは 自動的に利用可能なファブリックにフェールオーバーしますが、UCS はポート ID、および送信元 MAC アドレスベースのロードバランシングのメカニズムのみサポートします。前述したように Nexus 1000V は、より細かいロードバランシング方式と冗長性を実現するために MAC-pinning 機能を使用し ます。VMNIC は、ポート プロファイル定義を使用して、アップリンク パスにピン接続できます。 ポート プロファイルを使用すると、使用する優先アップリンク パスを管理者が定義できます。これら のアップリンクが失敗した場合、別のアップリンクが動的に選択されます。 アクティブ / スタンバイ冗長構成 ハイ アベイラビリティを実現するために、Nexus 1000V シリーズ VSM はペアで配置し、一方の VSM をプライマリ、もう一方をセカンダリ モジュールとして定義する必要があります。2 つの VSM はアク ティブ / スタンバイペアとして動作し、ハイ アベイラビリティのスイッチ管理を提供する物理シャーシ のスーパーバイザと同様に機能します。Nexus 1000V シリーズ VSM はデータ パスにないため、VSM の電源が両方とも落ちた場合でも、仮想イーサネット モジュール（VEM）は影響を受けず、トラ フィックの転送を続行します。 VSG の冗長性は VSM の冗長性と同様に設定されます。つまり、冗長 VSM と同様に、冗長 VSG は 2 台の物理ホストに分けて設置する必要があります。一方をプライマリ VSG として定義し、もう一方を セカンダリ VSG として定義することで、アクティブ / スタンバイの HA モードで動作します。VSM の 場合と同様に、DRS、VMware HA、VMware FT は、冗長 VSG の VM に対して無効にする必要があ ります。各サーバ上の VSM を維持するために、VMware ESXi のアンチアフィニティ機能を使用でき ます。 クラスタ内のハイ アベイラビリティ VMDC アーキテクチャでは、内部クラスタの復元性を実現するため、VMware HA の使用が指定され ています。VMware FT のようにクラスタ内のプライマリおよびセカンダリ VM 間で 1:1 のフェール オーバーをするのと異なり、VMware HA では単一のクラスタ内で 1:N のフェールオーバーを実現しま す。このモデルでは、エージェントが各サーバ上で実行され、クラスタ内の指定されたプライマリ サーバとのハートビート交換を維持することで状態を示します。これらのプライマリ ホストが状態を 維持し、フェールオーバーを開始します。サーバの障害時はハートビートが失われ、そのサーバに関連 するすべての VM はクラスタ プールの別の使用可能なサーバ上で自動的に再起動します。VMware HA の前提条件は、HA プール内のすべてのサーバがストレージを共有し、仮想ファイルがプール内の すべてのホストで使用できることです。FC SAN の場合、プール内のすべてのアダプタは同じゾーン内 にある必要があります。 VNMC の冗長性は、冗長 VNMC の VM が存在する ESXi クラスタの作成を前提として、VMware の HA 機能により実現されます。一般的に、このテクノロジーはバックエンド管理アプリケーションを実 行している VM に適用されます。 その他の考慮事項 このリリースでは重視されていませんが、復元力をさらに高めるためのベスト プラクティスとして、 アプリケーション レベルのクラスタリングの使用や、スナップショットまたはクローン作成および定 期的なデータベースのバックアップなど、定期的な VM とホストのバックアップ メカニズムが挙げら れます。このような方法はすべて、特にバックエンド管理ホストと VM に対して HA を実現する場合 に適用されます。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-27 第2章 設計の詳細 ハイ アベイラビリティ メンテナンス操作やサイト間のビジネス継続性を促進するには、必要に応じて VMware の Site Recovery Manager などのスクリプト動作を実行するツールまたはユーティリティを使用して、VM グ ループの自動ディザスタ リカバリ計画を作成します。この方法については、VMDC 2.0 およびデータ センター相互接続のシステム マニュアルで説明します。 ストレージの冗長性 ストレージ レイヤでは、HA 設計はインフラストラクチャの他のレイヤで実装されている HA モデルと の整合性が保たれており、物理的な冗長性およびパスの冗長性で構成されています。 ハードウェアとノードの冗長性 VMDC アーキテクチャは SAN の HA のベスト プラクティスを活用しており、ホストから SAN までの I/O パスの各デバイスで完全なハードウェア冗長性が規定されています。ハードウェア冗長性という点 では、まず、サーバのホストごとのデュアルポート アダプタから始まり、ホストからの冗長パスは 2 台の Nexus 5000 SAN スイッチ、そして階層型の RAID 保護機能を持つ冗長 SAN アレイまで至りま す。 リンクの冗長性 Nexus 5000 からの複数の個別ユーザ FC リンクはそれぞれ SAN ファブリックに接続され、各リンクの VSAN メンバーシップは UCS で明示的に設定されます。FC（NP）ポート リンク障害が発生すると、 影響を受けているホストは使用可能なポートを使用してラウンドロビン方式で再ログインします。FC ポートチャネルのサポート（利用可能な場合）とは、ポートチャネルの冗長リンクが、リンク障害の発 生時にアクティブ / アクティブ フェールオーバーのサポートを提供することを意味します。オプション で VMware または SAN のストレージ ベンダーのマルチパス ソフトウェアを使用して、使用可能なリ ンク帯域幅の使用率を最適化し、複数のアクティブ ホスト アダプタ ポートおよびリンク間のロード バ ランシングを強化して、サービスの中断を最小限に抑えることができます。 サービスの冗長性 前述したように、インフラストラクチャのサービス レイヤでは、シングル ポイント障害が発生しない ように冗長性が包括的に導入されています。これには、物理的（ハードウェア、リンク）および論理的 （パス、コントロール プレーン）な冗長性が含まれます。 ASA このシステムリリースでは、セキュアな VPN リモート アクセスとテナントごとに境界ファイアウォー ルを設置する目的で 2 組の冗長 ASA アプライアンスが利用されています。ASA の 8.4.1 リリースで は、複数の重要な HA 機能のサポートが導入されており、ダイナミック ルーティング プロトコルを使 用した 802.3ad EtherChannel とステートフル フェールオーバーによって、vPC または VSS がイネーブ ルになっているインフラストラクチャでの ASA のアベイラビリティが大幅に向上しています。このリ リースでは、ASA システムは最大 48 個の EtherChannel の設定をサポートしています。各チャネル グ ループは最大 8 個のアクティブ インターフェイスで構成されています。アクティブ / スタンバイおよび アクティブ / アクティブの 2 つのフェールオーバー モードがサポートされています。冗長 ASA がアク ティブ / スタンバイ フェールオーバー モードで設定されている場合、2 つの EtherChannel は、それぞ れ VSS（図 2-22 にあるように、ASA あたり 1 つ）の該当するアップストリーム スイッチで設定する 必要があります。これに対し、アクティブ / アクティブ モードでは、VSS ペアでスイッチごとに必要 な EtherChannel は 1 つだけです。現時点では、アクティブ / アクティブ フェールオーバーは ASA がマ Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-28 第2章 設計の詳細 ハイ アベイラビリティ ルチコンテキスト モードの場合に限りサポートされています。マルチコンテキスト モードでは、仮想 コンテキストを ASA で設定して複数の論理ファイアウォールに分割し、それぞれが個別のインター フェイスとポリシーをサポートするようにします。そのため、このリリースでは、ファイアウォールの 設置に使用されている ASA だけがアクティブ / アクティブ フェールオーバーに設定されます（図 2-21 の右側参照）。このシナリオで推奨されるベスト プラクティスとして、フェールオーバー設定において インターフェイス モニタリングと短いポーリング時間をイネーブルにし、リンク障害の発生時に、 ポートチャネルを通過するトラフィックの優れた復元力と高速コンバージェンスを実現することが挙げ られます。 図 2-21 ASA 冗長モード このシナリオは、Nexus 7000 アグリゲーション ノードへの直接的な冗長接続を実現するために vPC 環 境でも機能します。この場合、vPC では冗長 Nexus 7000 シリーズ デバイスとそれぞれの冗長 ASA 間 で L2 ポートチャネルを作成することができます。この概念は、2 台の Nexus 7000 ノードが異なる制 御プレーンおよびフォワーディング プレーンを持つ独立したスイッチである点で、VSS とは多少異な ります。これは VMDC 2.3 システムで ASA の冗長性を実現するために使用されるメカニズムです。 図 2-22 Nexus 7000 による ASA の冗長性 ACE ASA と同様に、冗長性を提供するために、2 台の ACE アプライアンスが vPC モードで Nexus 7004 ア グリゲーション レイヤに接続されています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-29 第2章 設計の詳細 サービス保証 サービス保証 一般的にサービス保証は、一連のサービス レベル管理プロセスとして定義されており、製品または サービスが、お客様またはクライアントの要件に合わせてカスタマイズされたパフォーマンス目標を達 成できることを保証します。このようなプロセスには、トラフィック フローの制御、主要なパフォー マンス指標のモニタリングと管理による問題の予防的な診断が含まれ、サービス品質を維持し、サービ スを迅速に復元します。サービス保証の背景にある基本的な目標は、顧客満足度を最大化することで す。 このうち、ネットワーク サービスの保証は、トラフィック エンジニアリング、パフォーマンス モニタ リング、およびエンドツーエンドのシステム アベイラビリティなど広範囲にわたりますが、VMDC 2.3 リリースでは、差別化サービス レベル契約または Quality of Service（QoS）の提供で重要となる サービス保証の特定の要素に重点を置いています。 VMDC 2.3 では、次の目標を定めて QoS フレームワークが定義されています。 • ネットワークの制御、ネットワーク サービス、ネットワーク管理トラフィックの各クラスに対す る継続的サポート。VMware vMotion やサービス コンソールなどのインフラストラクチャ管理フ ローを含め、ネットワークが不安定または CPU 使用率が高い場合の管理操作のメンテンナンスに 不可欠なミッション クリティカルなカテゴリに分類されます。 • 3 つのデータ サービス層に対する継続的サポート（従来のすべての VMDC システムのリリースと 同様です）。サービス レベル契約の観点では、差別化された帯域幅（B1、B2、B3）とアベイラビ リティの 2 つの基準で特徴付けられます。 – プライベートまたはパブリックにホストされたクラウド環境では、3 つのユーティリティ コン ピューティング サービス層として捉えることができます（Gold、Silver、Bronze/Copper）。 – パブリックのハイブリッドなクラウド間環境では、ビジネスに不可欠な（契約内、契約外） サービス レベル契約に関連する Gold および Silver クラスの高度な一連のエンドツーエンドの サービス レイヤの一部です。 • マルチメディアやホストされたコラボレーション トラフィック フローに対するサポート。サービ ス レベル契約の観点では、この新しいマルチメディア サービス レイヤ（VoIP ベアラおよびビデオ 会議）の低遅延トラフィック クラスは、帯域幅、遅延、アベイラビリティの 3 つの基準によって 特徴付けられます。必要なトラフィック フローは次のとおりです。 – Cisco WebEx のインタラクティブなコラボレーションに対応する新しいデータ帯域幅クラス – VoIP ベアラ トラフィック – VoIP コール制御 – ビデオ会議 – ビデオ ストリーミング（予定） • アドミッション制御のサポート（予定）。QoS はアドミッション制御の前提条件であり、将来的に クラウドが拡大した場合に適用されます。 • ハイブリッドなパブリック / プライベート ドメイン全体で QoS をサポートします。 • QoS の目的上、Copper 層のテナントのトラフィックは、Bronze 層のテナントのトラフィックと同 様に分類および処理されます。 これまで、各 VMDC のシステム リリースは、使用状況と対象者に応じて、従来のシスコ エンタープ ライズ / キャンパス QoS モデルまたはシスコ サービス プロバイダー IP/NGN QoS モデルのいずれかに 従っていました。これらのモデルは、トラフィックの分類とマーキングの点で多少異なり、パブリック からプライベート QoS ドメインへのエンドツーエンドのサービス レベル契約をサポートするニーズに 基づき、サービス プロバイダー モデルのほうが若干複雑です（図 2-23 を参照）。上記の目的を考慮し て、このリリースで説明されている QoS フレームワークは IP/NGN QoS モデルに対応しています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-30 第2章 設計の詳細 サービス保証 ハイブリッドの前提条件として、従来はパブリック プロバイダーの場合に限られていた要件が追加さ れることになります。すなわち、将来的なクラウド サービス レベル契約の発展に伴い、プライベート クラウド間のネットワーキングの場合にも適用される可能性があります。これは、QoS 透過性に必要 です。RFC3270 に記載されているように、QoS 透過性により、パブリック プロバイダーは IP パケッ トの DiffServ コード ポイント（DSCP）のフィールドにリマークを設定することなく、企業のトラ フィックに優先順位を付けて、独自のマーキング スキームを使用することができます。これにより、 宛先ネットワークに配信される QoS マーキングは、トラフィックが IP/NGN ドメインに入るときに受 信するマーキングに対応します。 適用されるすべてのサービス レベル契約は各ドメインにわたってコミットされるため、パブリック プ ロバイダーのエンドツーエンドのサービス レベル契約は、IP/NGN とパブリック プロバイダー DC の ドメイン サービス レベル契約を組み合わせたものになります。パブリック プロバイダー DC の QoS ド メイン内では、サービス レベル契約を EC の端から端までコミットする必要があります。（DC に入る） PE のサウスバウンドでは、実際には IP/NGN SLA に従い、テナントごと、クラスごとに SLA が存在 することになります。また、Nexus 1000V のノースバウンドでは、VNIC ごと、VM ごと（または任 意でクラスごと、VNIC ごと、VM ごと）の SLA となります。このモデルでは DC 側（PE および Nexus 1000V）だけでテナントごとの設定が必要なので、インフラストラクチャのコア / アグリゲー ション / アクセス レイヤでのテナントごとの QoS 要件が無いのが理想的です。 図 2-23 ハイブリッドなエンドツーエンド QoS ドメイン VMDC 2.3 で定義された QoS フレームワークは、ポイントツークラウド サービスの「ホース」モデル に従います。これは、VPN QoS のポイントツーマルチポイント（P2MP）リソースのプロビジョニン グ モデルを定義し、エッジ条件で調整の入力の確定率と出力の確定率で指定されます。このモデルで は、ノードがネットワーク（テナントの集約）から受信したトラフィックの合計量と、ネットワークに 入ってくるトラフィックの合計量に重点を置いています。VMDC アーキテクチャに関しては、ホース モデルは、パブリック プロバイダー PE（このリリースでは ASR 1000 の DC PE）でエッジ QoS 実装 に直接適用されます。この使用例としては、P2MP の VPLS ベースのトランスポート サービス（ハイ ブリッド DCI 使用例）や、より一般的な VPDC サービス（MPLS の L2 または L3 VPN がクラウド間 の転送を提供する）などが挙げられます。 差別化サービスを提供するために、このリリースでは次の QoS 機能を利用します。 • トラフィックの分類とマーキング • 輻輳管理および回避（キューイング、スケジューリングおよびドロップ） • トラフィックの調整（シェーピングおよびポリシング） トラフィックの分類とマーキング 分類とマーキングにより、QoS が有効なネットワークでは、ソース パケット ヘッダー（L2 802.1p CoS および DSCP 情報）に基づいてトラフィック タイプを識別し、ネットワーク内でパケット通過 ノードとして適切に処理するために、これらのトラフィック タイプに特定のマークを付けることがで Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-31 第2章 設計の詳細 サービス保証 きます。マーキング（色付け）とは、トラフィックを後から簡単に識別できるように、簡単な分類技術 を使用して、DSCP、MPLS、EXP、またはイーサネット L2 サービス クラス（CoS）フィールドの値 を設定するプロセスです。条件付きマーキングは契約内（適合）または契約外（超過）トラフィックを 指定するために使用されます。 以前のリリースと同様に、VMDC 2.3 で考慮されるトラフィックサービス目標は、次の 3 つの大きな カテゴリのサポートとして引き継がれています。 1. インフラストラクチャ 2. テナントのサービス クラス（3 つのデータと 2 つのマルチメディア プライオリティ） 3. ストレージ 図 2-24 は、DSCP マーキングおよび Per-Hop Behavior（PHB）の指定によって特徴付けられる必須の トラフィック クラスを詳細に分類したものです。これは、VMDC およびホストされたコラボレーショ ンの検証済みリファレンス アーキテクチャについてまとめたものであり、8 クラスの IP/NGN モデル に合わせたものです。 図 2-24 VMDC 2.3 のトラフィック クラス（8 クラスのリファレンス） 一般的なベスト プラクティスは、ネットワーク設計を簡素化するために、ソースエンドのシステムま たは可能な限りトラフィック ソースに近い場所でトラフィックをマーク付けすることですが、エンド システムがマーキングを行えない場合または信頼されていない場合は、ネットワークへの入口でマーク することができます。このリリースで定義された QoS フレームワークでは、プロバイダー DC は単一 の QoS ドメインを表し、Nexus 1000V が「サウス バウンド」のアクセス エッジを、ASR 1000 が 「ノース バウンド」の DC PE/WAN エッジを形成します。これらの QoS ドメイン エッジのデバイスが トラフィックをマークし、これらのマーキングが DC インフラストラクチャ内のノードに信頼されま す。つまり、エッジ デバイスから受信したマーキングに基づいた簡単な分類を使用します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-32 第2章 設計の詳細 サービス保証 キューイング、スケジューリング、およびドロップ ルータまたはスイッチでは、パケットのスケジューラはポリシーを適用して、どのパケットからキュー を削除して次に送信するか、そしていつそれを行うかを決定します。スケジューラは、さまざまな順序 でキューを処理します。最もよく使用される順序は、次のとおりです。 • ファーストイン ファーストアウト（FIFO） • プライオリティ スケジューリング（別名プライオリティ キューイング） • 重み付けした帯域幅 このリリースでは、クラスベース均等化キューイング / 低遅延キューイング（CBWFQ/LLQ）と呼ばれ る重み付けされた帯域幅の一種が、DC QoS ドメインのサウス バウンドの端にある Nexus 1000V で使 用されます。ASR 1000 の「ノース バウンド」の DC WAN エッジでは、重み付け帯域割り当てをデー タ トラフィック クラスの残りのタイプに行う間、プライオリティ トラフィックの遅延とジッターを区 切るためにプライオリティ キューイング（PQ）/CBWFQ が使用されます。 キューイング メカニズムはキューの先頭を管理しますが、輻輳回避メカニズムはキューの末尾を管理 します。キューの深度は長さが制限されているため、キューの深度を構築する際にパケットをドロップ して輻輳回避するために、ドロップ アルゴリズムが使用されます。一般的にデータ トラフィック クラ スに対しては、重み付けテール ドロップ（多くの場合、VoIP またはビデオ トラフィック）または重み 付けランダム早期検出（WRED）の 2 つのアルゴリズムが使用されます。このリリースでは、契約内 データ トラフィック（ゴールド、CoS 値 2）の前に契約外データ トラフィック（CoS 値 1）をドロッ プし、輻輳発生時に Bronze/Copper/Standard のトラフィック（CoS 値 0）をドロップするために WRED が使用されています。 エンドツーエンドの QoS アーキテクチャの定義の課題の 1 つが、QoS ドメイン内のすべてのノードが 常に実施されるわけではないことです。クラウド DC の QoS ドメイン内では、4 個の内部ファブリッ クのキュー（Nexus 7000）に対して VEM（Nexus 1000V）あたり 16 個のキューをサポートするシス テムからすべて実行します。つまり、トラフィック クラスは、8 つ未満のキューをサポートするシステ ムでマージする必要があります。HCS リファレンス モデルまたは標準の NGN リファレンスとの整合 性を保つため、VMDC 2.2 のリファレンス アーキテクチャのクラウド DC QoS ドメインに適用される キュー マッピングのクラスを図 2-25 に示します。 図 2-25 キュー マッピングに対する VMDC クラス Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-33 第2章 設計の詳細 サービス保証 ポリシングとシェーピング ポリシングおよびシェーピングは、トラフィック ストリームで最大帯域幅使用率を適用する手法です。 ポリシングは契約外のトラフィックをドロップして効果的にこれを実施しますが、シェーピングは契約 外のトラフィックを遅延させることでこれを実現します。 このリリースでは、データのレート制限およびプライオリティ トラフィック クラスの等級分けを行う ためにクラウド DC QoS ドメインの内部およびエッジでポリシングが使用されています。ASR 1000 の DC PE、階層型 QoS（HQoS）は、クラウド DC への出力で実装されています。これはシェーピングお よびポリシングの組み合わせであり、L2 トラフィックはクラスごとのアグリゲーション（ポート）レ ベルでシェーピングされますが、ポリシングはテナントごとの集約を適用するために使用されます。 QoS ポリシーの影響を分析する検証で使用されるサンプル帯域幅ポートの予約率は図 2-26 に示すとお りです。 図 2-26 サンプル帯域予約（ポートのパーセンテージ） 図 2-27 は、このエンドツーエンドの SLA フレームワークの詳細な概要を示したものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-34 第2章 設計の詳細 拡張性に関する考慮事項 図 2-27 エンドツーエンドの SLA フレームワーク 拡張性に関する考慮事項 クラウドのインフラストラクチャを拡大および拡張する能力は、環境から物理的および論理的容量ま で、さまざまな要素が関係します。また、考慮事項は技術な範囲を超え、管理に関する領域にも及びま す。 • L2 の拡張性 • L3 の拡張性 • リソースのオーバーサブスクリプション • DC の拡張性 L2 の拡張性 L2 ドメイン内では、次の要素が拡張性に影響します。 • VM 密度。各サーバ ブレードで利用できる VM 数は、ワークロードの種類、CPU およびメモリ要 件によって異なります。必要なコンピューティング能力やメモリ容量は、ワークロードの種類に よって異なります。たとえば、Web ブラウザやオフィス スイートなどのアプリケーションを使用 するデスクトップ仮想化で必要とされるコンピューティング能力とメモリ容量は、データベース インスタンスや VoIP、ビデオ サービスなどを実行するサーバに比べて少なくなります。同様に、 オンデマンドで優れたコンピューティング能力とメモリ リソースを提供し、動作するアプリケー ションを問わない Communications as a Service （CaaS）では、単に CPU コアあたりの VM 数だ けで特徴付けられ、メモリ オプションのパッケージ バンドルが提供されます。CPU コアあたりの VM 数は、VM へのアクセスを提供するために必要なネットワーク インターフェイス（仮想）数 を割り出す際の重要な要因です。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-35 第2章 設計の詳細 拡張性に関する考慮事項 • VM あたりの VMNIC 数。各 VM インスタンスには、2 つ以上の vNIC が必要です。多くの場合、 異なる種類のイーサネット セグメントへの接続を処理するために複数の vNIC が必要とされ、 ESX ホスト自体にもネットワーク インターフェイス（つまり管理制御インターフェイス）が必要 です。 • MAC アドレスの容量。VM あたりの VM 数および vNIC 数によって、L2 ドメイン内のスイッチ に対する MAC テーブルのサイズ要件が生じます。通常、これらはソフトウェアではなくハード ウェアで実装されます。そのため、ハードウェア アップグレードが可能でない限り、単一の L2 ド メインの範囲に上限が設定されます。VMDC システムのリファレンス アーキテクチャでは、Pod 内で必要な MAC アドレスの総数は、（Pod あたりのサーバ ブレード数）x（コア / ブレード数）x （VM/ コア数 = 1、2、4）x（MAC/VM 数 = 4）という式に基づいて計算されます。 • クラスタの規模。クラスタ サイズはディメンション数（サーバ、VM、および論理ストレージ I/O）によって制限されます。 • ARP テーブル サイズ • VLAN 数。VLAN は L2 ドメイン内で論理セグメンテーションを提供し、VM の接続を拡張し、 アプリケーション層の分離とマルチテナントの分離を提供します。インフラストラクチャの L2 お よび L3 部分のあらゆるプラットフォームには、一定数の VLAN が割り当てられています。これ は、テナントのコンテナを設計する場合考慮する必要があります。 • ポートのキャパシティ。ネットワーク レイヤでは、ハードウェア ポートの密度も物理的な割り当 て量となります。同様に、この考慮事項は、仮想アクセス エッジ スイッチの論理イーサネット キャパシティを基準としたコンピューティング レイヤにも適用されます。 • 論理的障害ドメイン。L2 ドメインは単一の論理的な障害ドメインです。管理の観点から、影響を 受ける一連のリソースが非常に大きな場合は、各タイプの障害からのどのくらいの期間で復旧でき るかが運用上の考慮事項となります。 • L2 コントロール プレーン。L2 アクセス / アグリゲーション レイヤを構築する場合は、L2 コント ロール プレーンは拡張性に関する問題に対処できるように設計する必要があります。スパニング ツリー ルートの配置は、ネットワーク障害へ対処するための冗長パスの提供と同様に、リンク サービスへの最適なパスを判断する際に重要です。 L3 の拡張性 L3 ドメインの拡張性は、次の要因により異なります。 • BGP ピアリング。ピアリングはエッジ、コアおよびアグリゲーション レイヤの間で実行されま す。エッジ レイヤは IP/MPLS VPN および VRF のインターネット トラフィックを終了し、このレ イヤで SSL/IPsec の終了を適用します。トラフィックは VRF-Lite を経由してコア レイヤに送られ ます。BGP ピアリングは、エッジ レイヤにトラフィックを送信するデータセンター数に応じて分 散されます。同様に、コア レイヤにトラフィックを送信する Pod 数に応じて、レイヤが下層にな るほど BGP ピアリングの規模が小さくなります。 • HRSP インターフェイス。サービス、コア、エッジ、アグリゲーションの各レイヤ間の L3 冗長パ スを仮想化し、提供するために使用されます。 • VRF インスタンス。VRF インスタンスはテナントのネットワーク コンテナの定義に使用できま す。VRF インスタンスの拡張性は、これらのネットワーク コンテナのサイズによって異なります。 • ルーティング テーブルとコンバージェンス。個々のテナントのルーティング テーブルはそれほど 大きくありませんが、DC 内で障害状態が発生すると、VRF（テナント）はルーティング テーブル のコンバージェンスに対する課題となります。 • サービス。サービスは、NAT およびサーバのロード バランシングで IP アドレス プールを使用し ます。サービスはコンテキストを使用して、テナントの分離を提供します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-36 第2章 設計の詳細 拡張性に関する考慮事項 リソースのオーバーサブスクリプション リソース使用率の効率性を高めることは、ハードウェア リソースのオーバーサブスクリプションを促 進するうえで重要です。これによりサービス レベル契約を維持しながら、設備投資（CAPEX）の削減 が促進されます。 ネットワークのオーバーサブスクリプション ネットワークのオーバーサブスクリプション率がどのくらいであればパフォーマンス要件を満たせるの かを検討するため、ネットワーク アーキテクトは、論理および物理トポロジ内で想定されるトラ フィック フローを考慮する必要があります。多層アプリケーションのフローにより、トラフィックの 中でサーバ ファームからアグリゲーション レイヤに渡されない部分が作り出されます。この場合、こ のような部分はサーバ間で直接やり取りされます。アプリケーション固有の考慮事項は、スイッチ レ イヤ間のアップリンクの使用率に影響を及ぼす可能性があります。たとえば、アプリケーションの複数 の層に属するサーバが同じ UCS ファブリック内の同じ VLAN にある場合、そのトラフィック フロー は UCS 6140 のペアに対してローカルであり、アグリゲーション レイヤへのアップリンク帯域幅を消 費しません。 トラフィック フローの種類と考慮事項は次のとおりです。 • 同じ UCS ファブリックのサーバ間 L2 通信。送信元と宛先が同じ UCS ファブリックに属する UCS 6140 ペア内に存在するため、トラフィックはファブリック内に留まります。このようなフ ローの場合、10 Gb の帯域幅がプロビジョニングされます。 • 異なる UCS ファブリック間のサーバ間 L2 通信。図 2-28 に示すように、UCS 6140（ファブリッ ク インターコネクト）とアグリゲーション レイヤ スイッチの間で EH イーサネット モードを使用 する必要があります。この設定により、複数のサーバの存在がアグリゲーション レイヤに対して 透過的であることが保証されます。UCS 6140 が EH モードでが設定されている場合、これらの ファブリックに属するすべての仮想サーバの情報を転送し、これらのファブリックで発生するフ ローのローカル スイッチングを実施しますが、フローの宛先が UCS 6140 の別のペアである場合、 そのトラフィックはアクセス レイヤ スイッチに送信され、最終的には適切な UCS 6140 によって サーバに転送されます。 • サーバ間 L3 通信。可能であれば、アプリケーションの複数の層を同じ UCS ファブリック内に保 持することが推奨されます。これは、トラフィック パターンが予測可能になるためです。ただし、 2 つの層が同じ UCS ファブリックにあるものの、異なる VLAN にある場合は、アプリケーション 層間でのルーティングが必要です。このルーティングにより、アグリゲーション レイヤに対する トラフィック フローの出入りが発生し、サブネット間で移動します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-37 第2章 設計の詳細 拡張性に関する考慮事項 図 2-28 UCS システムでのトラフィック フロー 実際には、ネットワークのオーバーサブスクリプション比はインフラストラクチャの階層レベルやの用 途に応じて 4:1 から 8:1 までの範囲で使用されます。この VMDC 2.x のリファレンス設計では、サーバ 間のトラフィックに対するネットワーク オーバーサブスクリプション比 8:1 が一般的なコンピュー ティングの導入で検討されます。この概念は、図 2-28 に示すとおりです。UCS シャーシは、それぞれ 帯域幅 40 GB（10 GB x 4）で UCS 6140 に接続されています。8 シャーシをすべて接続すると、各 UCS 6140 では帯域幅 320 GB が集約されます。各 UCS 6140 の 4 つの 10 GB アップリンクからポー トチャネルが形成されるため、どちらの vPC トランクも 40 GB 以上の帯域幅でアクセス レイヤへの転 送を行います。この設定では、すべてのリンクがアクティブな場合、アクセス レイヤでの比率 320 GB/40 GB、オーバーサブスクリプション比 8:1 が定義されます。 同様に、すべてのリンクがアクティブな場合は、アグリゲーション レイヤでのオーバーサブスクリプ ション比 8:1 がプロビジョニングされます。アグリゲーション レイヤでのオーバーサブスクリプショ ンは、Pod から出ることが予期されるトラフィックの量によって異なります。また、外部クライアント がサーバにアクセスするフローも存在します。このようなトラフィックは UCS 6140 に到達するために アクセス レイヤ スイッチを通過する必要があります。 クライアントとサーバ間を通過するトラフィック量は、WAN リンクの帯域幅によって制限されます。 メトロ環境では、企業は WAN 接続の帯域幅を 10 ～ 20 GB の間でプロビジョニングしますが、距離が 長いほど高帯域接続のコストがかかります。したがって、WAN リンクの帯域幅はエンドツーエンドの スループットを制限する要因になります。 コンピューティングのオーバーサブスクリプション サーバ仮想化では、VM あたりのプロセッサとメモリのキャパシティの割合を割り当てます。プロセッ サのキャパシティは、仮想 CPU（vCPU）として割り当てられ、プロセッサの周波数の一部が割り当て られます。一般的には、vCPU はブレード コアと同一視されます。簡単に表すと、コンピューティン Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-38 第2章 設計の詳細 拡張性に関する考慮事項 グのオーバーサブスクリプションは、サーバまたはブレードあたりの VM あたりの vCore 数の比率と 考えることができます。また、VM 数の観点からは、ブレードあたりのメモリの GB 数あたりの VM 数と考えることができます。もちろん、実環境のアプリケーション ワークロードには、処理、メモリ、 ストレージ要件についてそれぞれ明確な論理占有率が存在します。このため、IOPS パフォーマンスに 関する考慮事項を含む ICS スタックの分析は、トラフィック ストリームを生成する特定のアプリケー ションで実際に実施されますが、インフラストラクチャのモデリングを目的として、IOPS パフォーマ ンスがテスト条件でない場合は、変化するワークロード サイズの平均を表すプロファイルの作成が有 用です。VMDC インフラストラクチャのモデリングでは、次の特性を持つ 3 つのワークロード プロ ファイルが利用されています。 • Large（20%）：1 vCore/VM（1:1） • Medium（30%）：5 vCore/VM（2:1） • Small（50%）：25 vCore/VM（4:1） 旧式の Cisco UCS B シリーズ ブレード サーバは 2 つのソケットを備えており、それぞれが 4 ～ 8 個の コアをサポートします。Xeon 5570 プロセッサが搭載された B シリーズ ブレード サーバは、ソケット あたり 4 コア、つまり合計 8 コアをサポートします。最新の B シリーズ ブレード サーバは、ブレード あたり 12 コアをサポートします。8 シャーシのシステムでは、システムあたり 64 ブレード x 12 コア、 つまり 768 コアを備えています。上記のようにワークロードを分散することにより、それぞれ 8 シャーシ システムあたり 2,148 VM、または 8 シャーシの 8 つの UCS システムあたり 17,208 VM に 均等化されます。 図 2-29 ワークロード プロファイルによる分散のサンプル VM あたりの帯域幅 図 2-28 と図 2-29 で示されるように、20/30/50 に分散される Large/Medium/Small のワークロード タ イプでコア : VM 比率が 1:1、1:2、1:4 の場合、平均でブレードあたりの VM 数が 22、UCS あたりの VM 数が 1,432 、Pod あたりの VM 数が最大 11,472 となります。12 コア ブレードの場合は、ブレード あたりの VM 数が 34、UCS あたりの VM 数が 2,148、Pod あたりの VM 数が最大 17,208 VM です。 VM あたりのネットワーク帯域幅は次のとおりです。 UCS 6140 はそれぞれ 8 個のアップリンクをサポートします。したがって、各 UCS システムは VM あ たり 80GB/1432 = 56MB の帯域幅をサポートできます。オーバーサブスクリプションでは、アグリ ゲーション、コア、エッジの各レイヤの VM 帯域幅ごとにプルーニングが行われます。コア レイヤは 1:1 のロードバランシング（L2 および L3）を実施します。したがって、各 UCS 内の VM ごとに 80GB/1432 = 56MB の帯域幅が提供されます。サーバ数 512 の場合の最大 Pod サイズを想定すると、 これは 8 コアの場合で VM あたり約 7MB（80GB/11472）または 12 コアの場合で VM あたり約 5MB （80GB/17208）に相当します。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-39 第2章 設計の詳細 拡張性に関する考慮事項 ストレージのオーバーサブスクリプション 共有ストレージ環境では、オーバーサブスクリプションによって利用可能なストレージを最適化して利 用するための方法としてシン プロビジョニングが用意されています。この方法では、事前にすべての ブロックを割り当てる従来の方法とは異なり、データのブロックからオンデマンドで割り当てます。こ の方法により、使用されていない領域がほとんどなくなるため、ストレージ容量の大きなプールが個々 のサーバに割り当てられていても使われていない（書き込みがされていない）ままになっている従来の ストレージの割り当て方式で発生する使用率の低さが回避されます。このモデルでは、シン プロビ ジョニングされたストレージのプールは、同種のワークロード プロファイルを持つ vApp のグループ に割り当てることができます。使用率はプール単位で監視および管理されます。 このシステムのストレージの帯域幅は、次のように算出できます。 各 UCS 6140 から MDS には、4 x 4GB のリンクが存在します（VCE の Type 2 Vblock と一致します）。 各 ESX ブレードから各ファブリックへの均等なラウンドロビン ロードバランシングが行われると仮定 した場合、SAN の帯域幅は 32G です。各 UCS システム内では、80GB（160GB/2 ）の FCoE が MDS ファブリック上の 32GB にマップされます。VMAX では、8 個の FA ポートが合計（両方のファブ リック）32GB の帯域幅で使用されます。IOPS の EMC 数は FA ポートあたり約 11,000 程です。8 つ のポートを使用すると、IOPS の合計は 88,000 になります。UCS システムで考えると 88,000/1,432 で、VM あたり 61 IOPS となります。サーバ数 512 の場合の最大 Pod サイズを想定すると、8 コアの 場合で VM あたり 88,000/11,472 で 8 つの IOPS に提供され、12 コアの場合で VM あたり 5 つの IOPS に提供されます。もちろん VM あたりのイーサネットおよび FC の帯域幅を増加させるために、さらに FC およびイーサネット ポートを追加できます。 DC の拡張性 大規模な Pod に基づく DC の拡張性は、次の要因によって決まります。 • アグリゲーション レイヤでの MAC アドレスのサポート。Nexus 7000 プラットフォームは最大 128,000 個の MAC アドレスをサポートします。たとえば、Small、Medium、Large のワークロー ドが混合する分散のモデリングを検討する場合、理論上 11,472 のワークロードが各 Large Pod で 有効です。これは、8 コア ブレードの場合で VM 数 11,472 に、または 12 コアの B200 シリーズ ブレードでは 17,208 のワークロードに置き換えられます。各 VM データおよび管理ネットワーク では、ESX ホスト自身の NIC 同様、固有の MAC アドレスを持つ個別の vNIC が必要です。 VMDC ソリューションでは、VM あたり 4 個の MAC アドレスを想定しています。これは、Large Pod あたり 45,888（または 68,832）個の MAC アドレスとなります。Pod 内のスケールを最適化 するため、Pod 間での VLAN の共有は、アプリケーションのモビリティなどの特定の場合を除き 一般的には推奨されません。MAC アドレスのフラッドは、トランク ポートで VLAN をフィルタ リングをすることで停止します。 • 10G ポートの密度。導入したアプリケーションで許容されるネットワークのオーバーサブスクリ プション比を提供しながら、どのくらいの Pod を追加できるのかは、アクセス / アグリゲーション レイヤのプラットフォームでサポートされる 10G ポートの合計数によって決まります。たとえば、 物理ポート密度の観点から（M1 シリーズ ラインカードに基づく）、Nexus 7018 は理論的には 6 つ の Large Pod のサポートが可能であり、それぞれ 512 ブレードに相当します。 • コントロール プレーンの拡張性。コントロール プレーンの拡張性は、テナントを識別するために 使用するカプセルおよび使用中の L2 プロトコル（HSRP および STP）の種類と、ルートのプロト コル選択によって異なります。VRF-Lite が使用されている場合、アグリゲーション レイヤ デバイ スに導入された各テナントの VRF では、隣接ルータのルーティングの隣接関係を維持する必要が あります。このようなルーティング隣接関係では、hello パケットやルーティング アップデートと いったルーティング制御トラフィックを保守、交換できなければならず、CPU サイクルを消費し ます。そのため、コントロール プレーンの拡張性は、サポートできる VRF インスタンス（または テナント）の数を決定する重要な要素となります。この設計では、150 テナントとなっています。 Large Pod 設計に基づいた DC は、ワークロードの種類によって最小 256 テナント、ワークロード Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-40 第2章 設計の詳細 VMDC 2.3 の拡張性 の範囲 8,192 以上を提供します。これは、既存のコア レイヤに Large Pod を追加することで拡張で きます。今後、インフラストラクチャの中核となる LSP および Inter-AS のアプリケーションによ り、このモデルのさらなる拡張が可能になります。 VMDC 2.3 の拡張性 VMDC 2.3 プラットフォームおよび設計の拡張性で主要な要素となるものは、以下に示すとおりです。 • ASR 1006 は 12 個の 10G インフラストラクチャを持つことができます。 • ASR 1000 にはアップストリーム用のポート 2 つ、およびダウンストリーム Pod ごとに 2 つのポー トが用意されています。 • ASR 1006 を使用すると、VMDC 2.3 では 4 つの Pod を構築できます。 • NX-OS 6.1 を備えた Nexus 7000 には、VRF インスタンスが 1,000、HSRP が 1,000、BGP ピアが 1,000、VLAN が 4,000 というのコントロール プレーンのスケール制限があります（NX-OS 6.2 で はこれらの数が大幅に増加します）。 • このような制限に基づき、VMDC 2.3 では、Pod ごとに 125 個の Expanded Gold コンテナ、200 個の Gold コンテナ、300 個の Silver コンテナ、300 個の Bronze コンテナ、または 500 個の Copper コンテナを利用できます。 • 混合テナント モデルを使用した場合、VMDC 2.3 では Pod あたり最大 500 個のテナント（10 個の 拡張 Expanded Gold コンテナ、20 個の Silver コンテナ、220 個の Bronze コンテナ、250 個の Copper コンテナ）をサポートできます。 • VMDC 2.3 では 4 つの Pod を使用することで、VMDC 2.3 DC で 2,000 個の混在テナントに拡張 することができます。 • F2 ラインカードを備えた Nexus 7004 は、最大 16,000 個の MAC アドレスをサポートできます （これは F2 ラインカードの制限です）。スイッチやサービス アプライアンスなどのために 2,000 個 の MAC アドレスを確保した場合でも、VM 用に最大 12,000 個の MAC アドレスを使用できます。 VM あたり 2 つの vNIC を前提とすると、VMDC 2.3 では Pod あたり最大 6,000 個の VM までサ ポートできます。 • これは FlexPod または ICS あたり 2,000 個の VM に相当します（Pod あたり 3 個の ICS スタッ ク）。 上記の要素に基づき、VMDC 2.3 システムのスケールアウト モデルを図 2-30 と図 2-31 に示します。 これは、Pod の拡張および DC の拡張という視点で示したものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-41 第2章 設計の詳細 VMDC 2.3 の拡張性 図 2-30 VMDC 2.3 の拡張された Pod 図 2-31 VMDC 2.3 の拡張された DC VMDC 2.3 システムは、Pod 内の ICS スタック、さらには DC 内の Pod というように、水平方向にス ケールアウトすることができます。このスケールアウト モデルは、10 個の Expanded Gold コンテナ、 20 個の Silver コンテナ、220 個の Bronze コンテナ、および 250 個の SMB コンテナで構成された混合 テナントで構築されています。これには、Pod あたり 2 つの ASA 5585-X40、4 つの ACE 4710、およ び 2 つの ASA 5555-X が必要です。また、Pod あたり 3 つの FlexPod（24 台の UCS シャーシ、192 台 の UCS ブレード）、および DC あたり 4 つの Pod を含みます。この設計では、Pod あたり 500 個の混 合テナント、6,000 個の混合 VM、そして DC あたり 2,000 個の混合テナント、24,000 個の混合 VM を 想定しています。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-42 第2章 設計の詳細 VMDC 2.3 の拡張性 図 2-30 は、VMDC 2.3 システムの ICS（FlexPod）トポロジおよびポート密度 / 接続の概要を示したも のです。 図 2-32 VMDC 2.3 の統合コンピューティングおよびストレージ（ICS）スタック 表 2-2 は、VMDC 2.3 ソリューションにおける各テナントのコンテナ タイプ別に拡張性をまとめたも のです。 表 2-2 VMDC 2.3 のテナントの拡張性 テナント モデル Pod あたりの DC のスケール（DC あた スケール り 4 つの Pod） すべての Expanded Gold コン テナ 125 すべての Gold コンテナ 200 500 800 1 すべての Silver コンテナ 300 すべての Bronze コンテナ 300 1,200 すべての Copper コンテナ 500 2,000 500 2,000 混合コンテナ 2 1,200 1. Pod ごとに ASA または ACE アプライアンスの複数のペアが必要です。 2. 混合 = Expanded Gold コンテナ 10、Silver コンテナ 20、Bronze コンテナ 220、 Copper コンテナ 250 表 2-3 は、VMDC 2.3 ソリューションにおけるコンピューティングの拡張性をまとめたものです。 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-43 第2章 設計の詳細 VMDC 2.3 の拡張性 表 2-3 Pod および DC における VMDC 2.3 のコンピューティングの拡張性 VM あたり1 ICS Pod DC VM 2,000 6,000 24,000 CPU 128 384 1,536 コア 1,024 3,072 1,288 0.512 GHz 2,969.6 8,908.8 35,635.2 1.48 GB 12,288 36,864 147,456 6.14 2 1. 実際の VM のサイジングと分散の比率は SPCSS FlexPod と VM のサイジング定義で決定されます。 2. 拡張された各 ICS では VM 数 2,000 を想定しています。 （注） 拡張された ICS = UCS ブレード数 64、拡張された Pod = ブレード数 192、拡張された DC = ブレード 数 768 UCS B200 M2 ブレードには、それぞれ 2 個の 2.90 GHz E5-2690 CPU、248GB の DDR3-1600 MHz RDIMM、1 個の VIC 1240 MLOM を持つものと想定します。 表 2-4 は、Expanded Gold コンテナが 10、Silver コンテナが 20、Bronze コンテナが 220、Copper コ ンテナが 250 の混合テナント モデルを想定し、VMDC 2.3 ソリューションに基づいてスケールアウト した DC でのリソース消費量についてまとめたものです。 表 2-4 拡張された DC での VMDC 2.3 のリソース消費量 DC あたり（4 つ の Pod） Nexus 7004 VRF Pod あたり 520 2,080 Nexus 7004 VLAN / HSRP 860 3,440 Nexus 7004 BGP 750 3,000 Nexus 7004 MAC 14,000 56,000 ASR 9000 VRF 250 1,000 ASR 9000 サブインターフェイ 250 1,000 リソース ス ASR 9000 BGP 500 Cisco Virtualized Multiservice Data Center 2.3 設計ガイド 2-44 200 GLOSSARY A ACE Application Control Engine（アプリケーション コントロール エンジン）（シスコ） ACL Access Control List（アクセス コントロール リスト） ARP Address Resolution Protocol（アドレス解決プロトコル） ASA Adaptive Security Appliance（適応型セキュリティ アプライアンス）（シスコ） ASR Aggregation Services Router（アグリゲーション サービス ルータ）（シスコ） B BFD Bidirectional Forwarding Detection（双方向フォワーディング検出） BGP Border Gateway Protocol（ボーダー ゲートウェイ プロトコル） C CaaS Communications as a Service（サービスとしてのコミュニケーション） CAPEX Capital Expense（設備投資） CBWFQ Class-Based Weighted Fair Queuing（クラスベース均等化キューイング）（QoS） CNA Converged Network Adapter（統合型ネットワーク アダプタ） CoS Class of Service（サービス クラス） CPU Central Processing Unit（中央処理装置） CRI Cloud Ready Infrastructure（クラウド対応のインフラストラクチャ） D DC Data Center（データセンター） DC-PE Data Center Provider Edge （データセンター プロバイダー エッジ） Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-1 Glossary DMZ Demilitarized Zone（非武装ゾーン） DRS Distributed Resource Scheduling（分散リソース スケジューリング） DSCP Differentiated Services Code Point（差別化サービス コード ポイント） DSN Data Center Service Node（データセンター サービス ノード） DVS Distributed Virtual Switch（分散仮想スイッチ） E eBGP External Border Gateway Protocol（外部ボーダー ゲートウェイ プロトコル） EH End-host (mode)（エンドホスト モード） F FC Fibre Channel（ファイバ チャネル） FCoE Fibre Channel over Ethernet FEX Fabric Extender（ファブリック エクステンダ） FIFO First In First Out（ファーストイン ファーストアウト） FT Fault Tolerance（耐障害性） FWSM Firewall Services Module（ファイアウォール サービス モジュール）（シスコ） G GEM Gigabit Ethernet Module（ギガビット イーサネット モジュール） H HA High Availability（ハイ アベイラビリティ） HQoS Hierarchical QoS（階層型 QoS） HSRP Hot Standby Router Protocol（ホット スタンバイ ルータ プロトコル） Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-2 Glossary I IaaS Infrastructure as a Service（サービスとしてのインフラストラクチャ） iBGP Internal Border Gateway Protocol（内部ボーダー ゲートウェイ プロトコル） ICS Integrated Compute and Storage（統合コンピューティングおよびストレージ） IGP Interior Gateway Protocol（内部ゲートウェイ プロトコル） IOPS Input/output operations per second（1 秒当たりの入出力処理） IPSec IP security（IP セキュリティ） ISV Independent Software Vendor（独立系ソフトウェア ベンダー） L L2 Layer 2 L3 Layer 3 L4 Layer 4 L7 Layer 7 LACP Link Aggregation Control Protocol （リンク アグリゲーション制御プロトコル） LAN Local Area Network（ローカル エリア ネットワーク） LDAP Lightweight Directory Access Protocol（ライトウェイト ディレクトリ アクセス プロトコル） LDP Label Distribution Protocol（ラベル配布プロトコル） LLQ Low Latency Queuing（低遅延キューイング） LUN Logical Unit Number（論理ユニット番号） M MAC Media Access Control（メディア アクセス コントロール） MDS Multilayer Director Switch（マルチレイヤ ディレクタ スイッチ） MEC Multi-Chassis EtherChannel MPLS Multiprotocol Label Switching（マルチプロトコル ラベル スイッチング） Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-3 Glossary N NAS Network Attached Storage（ネットワーク接続型ストレージ） NAT Network Address Translation（ネットワーク アドレス変換） NFS Network File System（ネットワーク ファイル システム） NGN Next Generation Network（次世代ネットワーク） NPIV N-Port Identifier Virtualization（N ポート ID 仮想化） NPV N-Port Virtualization（N ポート バーチャライゼーション） NSF Nonstop Forwarding（ノンストップ フォワーディング）（シスコ） NSR Nonstop Routing（ノンストップ ルーティング）（シスコ） O OPEX Operating Expense（運用コスト） OSPF Open Shortest Path First（オープン ショーテスト パス ファースト） P P2MP Point-to-Multipoint（ポイントツーマルチポイント） PE Provider Edge（プロバイダー エッジ） PHB Per-Hop Behavior Pod Point of Delivery（Pod）。基本的なインフラストラクチャ モジュールであり、予測可能なインフラス トラクチャの特性および常に決まった機能を持つ、物理的で反復可能な構造です。Pod はデータセン ター コンポーネントのモジュラ ユニットを識別します。また、Pod によって、ネットワーク、コン ピューティングおよびストレージの各リソースを段階的に追加できるようになります。 PQ Priority Queuing（プライオリティ キューイング） Q QoS Quality of Service Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-4 Glossary R RAID Redundant Array of Independent Disks RBAC Role-based Access Control（ロールベース アクセス コントロール） S SAN Storage Area Network（ストレージ エリア ネットワーク） SLA Service Level Agreement（サービス レベル契約） SLB Server Load Balancing（サーバ ロード バランシング） SMB Small/Medium Business（中小規模企業） SSL Secure Sockets Layer STP Spanning Tree Protocol（スパニングツリー プロトコル） SVI Switched Virtual Interface（スイッチ仮想インターフェイス） T TCP Transmission Control Protocol（伝送制御プロトコル） ToR Top-of-Rack（トップオブラック） TTM Time to Market（市場投入までの時間） U UCS Unified Computing System（シスコ） UDP User Datagram Protocol（ユーザ データグラム プロトコル） UIM Unified Infrastructure Manager（EMC） V vCPU Virtual CPU（仮想 CPU） vDC Virtual Data Center（仮想データセンター） VEM Virtual Ethernet Module（仮想イーサネット モジュール） Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-5 Glossary vHBA Virtual Host Bus Adapter（仮想ホスト バス アダプタ） VIC Virtual Interface Card（仮想インターフェイス カード） VLAN Virtual LAN（仮想 LAN） VM Virtual Machine（仮想マシン） VMDC Virtualized Multiservice Data Center（仮想マルチサービス データセンター）（シスコ） VMDK Virtual Machine Disk（仮想マシン ディスク） VMFS Virtual Machine File System（仮想マシンのファイル システム） VMNIC VM Network Interface Card（VM ネットワーク インターフェイス カード） vNIC Virtual Network Interface Card（仮想ネットワーク インターフェイス カード） VMotion Virtual Motion VNMC Virtual Network Management Center （仮想ネットワーク管理センター）（シスコ） VoIP Voice over IP vPC Virtual Port-channel（仮想ポート チャネル） VPDC Virtual Private Data Center（仮想プライベート データセンター） VRF Virtual Routing and Forwarding（仮想ルーティングおよびフォワーディング） VSAN Virtual SAN（仮想 SAN） VSG Virtual Security Gateway（仮想セキュリティ ゲートウェイ）（シスコ） vSLB Virtual Server Load Balancer（仮想サーバ ロード バランサ）（シスコ） VSM Virtual Supervisor Module（仮想スーパーバイザ モジュール）（シスコ） VSS Virtual Switch System（仮想スイッチ システム）（シスコ） W WAN Wide Area Network（ワイドエリア ネットワーク） WRED Weighted Random Early Detection（重み付けランダム早期検出） Cisco Virtualized Multiservice Data Center 2.3 設計ガイド GL-6 㼴㻞㻜㻜㻤㻌㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟㻘㻌㻵㼚㼏㻚㻌㻭㼘㼘㻌㼞㼕㼓㼔㼠㼟㻌㼞㼑㼟㼑㼞㼢㼑㼐㻚 㻯㼕㼟㼏㼛䚸㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟䚸 䛚䜘䜃 㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟 䝻䝂䛿䚸㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟㻘㻌㻵㼚㼏㻚 䜎䛯䛿䛭䛾㛵㐃♫䛾⡿ᅜ䛚䜘䜃䛭䛾䛾୍ᐃ䛾ᅜ䛻䛚䛡䜛Ⓩ㘓ၟᶆ䜎䛯䛿ၟᶆ䛷䛩䚹 ᮏ᭩㢮䜎䛯䛿䜴䜵䝤䝃䜲䝖䛻ᥖ㍕䛥䜜䛶䛔䜛䛭䛾䛾ၟᶆ䛿䛭䜜䛮䜜䛾ᶒ⪅䛾㈈⏘䛷䛩䚹 䛂䝟䞊䝖䝘䞊䛃䜎䛯䛿䛂㼜㼍㼞㼠㼚㼑㼞䛃䛸䛔䛖⏝ㄒ䛾⏝䛿 㻯㼕㼟㼏㼛 䛸♫䛸䛾㛫䛾䝟䞊䝖䝘䞊䝅䝑䝥㛵ಀ䜢ព䛩䜛䜒䛾䛷䛿䛒䜚䜎䛫䜣䚹䠄㻜㻤㻜㻥㻾䠅 䛣䛾㈨ᩱ䛾グ㍕ෆᐜ䛿 㻞㻜㻜㻤 ᖺ 㻝㻜᭶⌧ᅾ䛾䜒䛾䛷䛩䚹 䛣䛾㈨ᩱ䛻グ㍕䛥䜜䛯ᵝ䛿ண࿌䛺䛟ኚ᭦䛩䜛ሙྜ䛜䛒䜚䜎䛩䚹 䝅䝇䝁䝅䝇䝔䝮䝈ྜྠ♫ 䛈㻝㻜㻣䇲㻢㻞㻞㻣㻌ᮾி㒔 ༊㉥ᆏ㻥㻙㻣㻙㻝㻌䝭䝑䝗䝍䜴䞁䞉䝍䝽䞊䚷 㼔㼠㼠㼜㻦㻛㻛㼣㼣㼣㻚㼏㼕㼟㼏㼛㻚㼏㼛㼙㻛㼖㼜 䛚ၥ䛔ྜ䜟䛫ඛ䠖䝅䝇䝁㻌䝁䞁䝍䜽䝖䝉䞁䝍䞊 㻜㻝㻞㻜㻙㻜㻥㻞㻙㻞㻡㻡䠄䝣䝸䞊䝁䞊䝹䚸ᦠᖏ䞉㻼㻴㻿ྵ䜐䠅 㟁ヰཷ㛫㻌㻦㻌ᖹ᪥㻌㻝㻜㻦㻜㻜䡚㻝㻞㻦㻜㻜䚸㻝㻟㻦㻜㻜䡚㻝㻣㻦㻜㻜 㼔㼠㼠㼜㻦㻛㻛㼣㼣㼣㻚㼏㼕㼟㼏㼛㻚㼏㼛㼙㻛㼖㼜㻛㼓㼛㻛㼏㼛㼚㼠㼍㼏㼠㼏㼑㼚㼠㼑㼞㻛䚷