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
㼴㻞㻜㻜㻤㻌㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟㻘㻌㻵㼚㼏㻚㻌㻭㼘㼘㻌㼞㼕㼓㼔㼠㼟㻌㼞㼑㼟㼑㼞㼢㼑㼐㻚
㻯㼕㼟㼏㼛䚸㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟䚸 䛚䜘䜃 㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟 䝻䝂䛿䚸㻯㼕㼟㼏㼛㻌㻿㼥㼟㼠㼑㼙㼟㻘㻌㻵㼚㼏㻚 䜎䛯䛿䛭䛾㛵㐃఍♫䛾⡿ᅜ䛚䜘䜃䛭䛾௚䛾୍ᐃ䛾ᅜ䛻䛚䛡䜛Ⓩ㘓ၟᶆ䜎䛯䛿ၟᶆ䛷䛩䚹
ᮏ᭩㢮䜎䛯䛿䜴䜵䝤䝃䜲䝖䛻ᥖ㍕䛥䜜䛶䛔䜛䛭䛾௚䛾ၟᶆ䛿䛭䜜䛮䜜䛾ᶒ฼⪅䛾㈈⏘䛷䛩䚹
䛂䝟䞊䝖䝘䞊䛃䜎䛯䛿䛂㼜㼍㼞㼠㼚㼑㼞䛃䛸䛔䛖⏝ㄒ䛾౑⏝䛿 㻯㼕㼟㼏㼛 䛸௚♫䛸䛾㛫䛾䝟䞊䝖䝘䞊䝅䝑䝥㛵ಀ䜢ព࿡䛩䜛䜒䛾䛷䛿䛒䜚䜎䛫䜣䚹䠄㻜㻤㻜㻥㻾䠅
䛣䛾㈨ᩱ䛾グ㍕ෆᐜ䛿 㻞㻜㻜㻤 ᖺ 㻝㻜᭶⌧ᅾ䛾䜒䛾䛷䛩䚹
䛣䛾㈨ᩱ䛻グ㍕䛥䜜䛯௙ᵝ䛿ண࿌䛺䛟ኚ᭦䛩䜛ሙྜ䛜䛒䜚䜎䛩䚹
䝅䝇䝁䝅䝇䝔䝮䝈ྜྠ఍♫
䛈㻝㻜㻣䇲㻢㻞㻞㻣㻌ᮾி㒔 ༊㉥ᆏ㻥㻙㻣㻙㻝㻌䝭䝑䝗䝍䜴䞁䞉䝍䝽䞊䚷
㼔㼠㼠㼜㻦㻛㻛㼣㼣㼣㻚㼏㼕㼟㼏㼛㻚㼏㼛㼙㻛㼖㼜
䛚ၥ䛔ྜ䜟䛫ඛ䠖䝅䝇䝁㻌䝁䞁䝍䜽䝖䝉䞁䝍䞊
㻜㻝㻞㻜㻙㻜㻥㻞㻙㻞㻡㻡䠄䝣䝸䞊䝁䞊䝹䚸ᦠᖏ䞉㻼㻴㻿ྵ䜐䠅
㟁ヰཷ௜᫬㛫㻌㻦㻌ᖹ᪥㻌㻝㻜㻦㻜㻜䡚㻝㻞㻦㻜㻜䚸㻝㻟㻦㻜㻜䡚㻝㻣㻦㻜㻜
㼔㼠㼠㼜㻦㻛㻛㼣㼣㼣㻚㼏㼕㼟㼏㼛㻚㼏㼛㼙㻛㼖㼜㻛㼓㼛㻛㼏㼛㼚㼠㼍㼏㼠㼏㼑㼚㼠㼑㼞㻛䚷

JBS Ambient Office 自治体向けインターネット画面転送サービス

VX1000 - ベクター・ジャパン

Apple iOS デバイスの AnyConnect のエラー メッセージ

Cisco WebEx Event Center （PDF）

中・四国大学保健 看護分科会の皆様 今年も早 11 月中旬になり、窓の外

Cisco Nexus 3100 プラットフォーム スイッチ：パワフルなトップオブラック

Cisco Certifications

アナログ モデム WAN インターフェイス カード（WIC-1AM また は