Cisco Nexus 1000V スイッチ

Cisco Nexus 1000V シリーズ スイッチ導入ガイド

ホワイトペーパー





Cisco Nexus 1000V シリーズ スイッチ導入ガイド



概要


このドキュメントでは、VMware vSphere 4.0 を使用した Cisco Nexus™ 1000V シリーズ スイッチの展開に関する設計と設定のガイダンスを提供します。詳細な設定ドキュメントについては、Cisco® 製品と VMware 製品のそれぞれの設定ガイドを参照してください。製品設定ガイドへのリンクは、このドキュメントの「関連情報」セクションに示してあります。

対象読者


このドキュメントは、シスコ データセンター環境内の VMware vSphere 4.0 ホストを理解し、展開することに関心を持つネットワーク設計者、ネットワーク エンジニア、仮想化管理者、およびサーバ管理者を対象としています。

イントロダクション


Cisco Nexus 1000V シリーズ スイッチは、仮想マシン アクセス スイッチであり、Cisco NX-OS ソフトウェア オペレーティング システムを稼動している VMware vSphere 環境用のインテリジェントなソフトウェア スイッチの実装です。VMware ESX ハイパーバイザの内部で動作することにより、Cisco Nexus 1000V シリーズは、次の機能を提供する Cisco VN-Link サーバ仮想化テクノロジーをサポートします。

  • ポリシーベースの仮想マシン接続
  • モビリティのある仮想マシンのセキュリティとネットワーク ポリシー
  • サーバ仮想化とネットワーキング チームのための中断のない運用モデル

サーバ仮想化をデータセンター内で展開する場合、一般に、仮想サーバは物理サーバと同じ方法では管理されません。サーバ仮想化は、サーバ、ネットワーク、ストレージ、セキュリティの管理者間でのより高度な調整を必要とする特別な展開として扱われるため、展開にかかる時間が長くなります。Cisco Nexus 1000V シリーズでは、仮想マシン アクセス レイヤからデータセンター ネットワーク インフラストラクチャのコアまですべてに一貫したネットワーキング フィーチャ セットとプロビジョニング プロセスを使用できます。さらに、仮想サーバは、専用の物理ネットワーク ポートに接続された物理サーバのものと同じネットワーク設定、セキュリティ ポリシー、診断ツール、および運用モデルを使用できます。仮想化管理者は、モバイル性のある仮想マシンを追跡して適切な接続を保つのに役立つ定義済みのネットワーク ポリシーを利用できます。それにより、仮想マシンの管理に集中するための貴重な時間を節約できます。こうした包括的な一連の機能は、サーバ仮想化を迅速に展開し、その恩恵を短期間で得るのに役立ちます。

VMware との緊密な協力関係の下で開発されたので、Cisco Nexus 1000V シリーズは、VMware vSphere、vCenter、ESX、ESXi、および他の多くの VMware vSphere 機能と互換性のあることが VMware によって認定されています。Cisco Nexus 1000V シリーズを使用して、サーバ仮想化インフラストラクチャの完全性について心配せずに仮想マシン接続を管理できます。

Cisco Nexus 1000V シリーズのコンポーネント

Cisco Nexus 1000V シリーズは、VMware vSphere 内の仮想スイッチと置き換わることにより、仮想サーバ環境内でレイヤ 2 スイッチングの高度なネットワーキング機能と一般的なネットワーク管理モデルを提供します。Cisco Nexus 1000V シリーズは、VMware vCenter Server で定義されたとおりにデータセンターを管理します。データセンター内の各サーバは、Cisco Nexus 1000V シリーズ内の 1 つのライン カードとして表現され、物理的なシスコ スイッチ内のライン カードと同じように管理できます。

Cisco Nexus 1000V シリーズの実装は、次の 2 つの主要なコンポーネントからなります。

  • Virtual Supervisor Module(VSM)
  • Virtual Ethernet Module(VEM)

これら 2 つのコンポーネントが組み合わさって Cisco Nexus 1000V シリーズを構成し、VSM によって管理プレーンが、VEM によってデータ プレーンが提供されます。

ネットワーク ポリシー

Cisco Nexus 1000V シリーズの独自の側面として、ネットワーク ポリシーの定義と展開の方法があります。今日では一般に、ネットワーク管理者は、スイッチ上の各インターフェイスを 1 つずつ設定します。つまり、シスコ スイッチでは、コンフィギュレーション モードを開始し、インターフェイスの設定を定義する一連のスイッチ コマンドを適用することになります。

設定は、同じスイッチ、または同じタイプのサーバに接続されている複数のスイッチ上で、複数のインターフェイスに手作業で適用される場合があります。このような管理モデルでは、サーバ管理者は、サーバがオンラインになるたびにネットワーク管理者がネットワークを再設定してくれることを当てにしなければなりません。この手順では、新しいサーバを展開するときに望ましくない遅れが生じる可能性があります。

VMware 環境では、サーバ管理者は、VMware 仮想スイッチ(vSwitch)とポート グループ機能を使用して、ネットワーク ポリシーがアップストリームの物理スイッチ上に設定されたポリシーと一致するように設定する必要があります。この要件により、仮想アクセス レイヤ スイッチの設定(データセンター内の最初のネットワーク ホップ)でのネットワーク管理者への依存性が解消され、新しい仮想マシンの追加は適切な定義済みのポート グループを選択するだけでできるようになります。このアプローチでは、ポリシー適用やトラブルシューティングなどの運用上とセキュリティ上の課題が生じますが、新しい仮想マシンを展開するときの遅れの多くに対処できます(物理インフラストラクチャを設定しません)。

Cisco Nexus 1000V シリーズは、新しい類似した仮想マシンがインフラストラクチャに追加されるときに、仮想化管理者またはサーバ管理者が使用できるネットワーク ポリシーをネットワーク管理者が定義する理想的なモデルを提供します。Cisco Nexus 1000V シリーズ上で定義されたポリシーは、新しい仮想マシンが特定のネットワーク ポリシーにアクセスする必要があるときにサーバ管理者が使用または再使用できるように VMware vCenter Server にエクスポートされます。この概念は、ポート プロファイルと呼ばれる機能を使用して Cisco Nexus 1000V シリーズ上に実装されます。ポート プロファイル機能を備えた Cisco Nexus 1000V シリーズでは、仮想化管理者が VMware ESX ホスト上に vSwitch やポート グループの設定を作成、維持する必要はありません。

ポート プロファイルでは、独自のコラボレーション モデルが作成されるため、物理ネットワーク インフラストラクチャ内でネットワークの再構成が実行されるのを待たずに新しい仮想マシンをプロビジョニングする自主性がサーバ管理者に与えられます。ネットワーク管理者の場合、Cisco Nexus 1000V シリーズのフィーチャ セットと既存のシスコの物理スイッチと同じ構文でポート プロファイルを定義する機能の組み合わせが、個々のスイッチ ポートを管理する負担をかけずに一貫したポリシーを確実に適用する役に立ちます。Cisco Nexus 1000V シリーズのソリューションは、ネットワーク チームに対して一貫したネットワーク管理、診断、およびトラブルシューティングのインターフェイスも提供します。それにより、仮想ネットワーク インフラストラクチャを物理インフラストラクチャと同様に管理することができます。

Cisco Nexus 1000V シリーズの動作原理


ここでは、Cisco Nexus 1000V シリーズの主要な概念とコンポーネント、およびコンポーネント間のインタラクションについて説明します。

VMware ネットワーキングの概要

Cisco Nexus 1000V シリーズを理解するには、VMware ネットワーキング モデルの基本を先に理解しておく必要があります。VMware ネットワーキングは、さまざまなタイプの Virtual Network Interface Card(vNIC; 仮想ネットワーク インターフェイス カード)、ホスト上の物理 NIC、およびそれらを相互接続する仮想スイッチで構成されます。

各仮想マシンには、1 つ以上の vNIC が装備されます。これらの vNIC は、仮想スイッチ(Cisco Nexus 1000V シリーズなど)に接続されて、仮想マシンにネットワーク接続を提供します。ゲスト OS は、vNIC を物理 NIC と認識します。VMware は、いくつかの普及している NIC タイプ(vlance と Intel e1000)をエミュレートできます。したがって、ゲスト OS は標準デバイス ドライバをこれらの vNIC に使用できます。または、VMware vmxnet インターフェイス タイプを使用することもできます。このインターフェイス タイプでは、ゲスト OS 上に VMware ドライバが必要です。

VMware ESX を稼動しているホストは、vswif と呼ばれる仮想管理ポートを備えています。このポートは、サービス コンソール インターフェイスとも呼ばれます。このインターフェイスは、VMware vCenter Server と通信するため、VMware vSphere Client でボックスを直接管理するため、あるいは Secure Shell(SSH; セキュア シェル)を使用してホストの Command-Line Interface(CLI; コマンドライン インターフェイス)にログインするために使用されます。VMware ESXi ホストは、サービス コンソール OS を持たないため、vswif インターフェイスを使用しません。

各ホストは、virtual machine kernel NIC(vmknic)と呼ばれる仮想ポートも 1 つ以上備えています。これらは、Small Computer Systems Interface over IP(iSCSI)と Network File System(NFS; ネットワーク ファイル システム)のアクセス用に VMware ESX で使用され、VMware VMotion でも使用されます。VMware ESXi システム上では、vmknic は、VMware vCenter Server との通信にも使用されます。

VMware ESX ホスト上の物理 NIC(Virtual Machine NIC(VMNIC; 仮想マシン NIC)と呼ばれます)は、物理ネットワーク インフラストラクチャへのアップリンクとして使用されます。

仮想と物理の NIC は、仮想スイッチによってすべて接続されます。VMware は、2 種類の仮想スイッチを提供します。標準の vSwitch は、ホストごとに個別に作成されます。VMware vNetwork Distributed Switch(vDS)は、物理ホストの集合に対して一貫した仮想スイッチを提供します。Cisco Nexus 1000V シリーズは、vDS の一種として実装されます。

各 vNIC は、標準 vSwitch または vDS にポート グループを介して接続されます。各ポート グループは、特定の vSwitch または vDS に属し、VMNIC、vswif、または vmknic が使用する 1 つの VLAN または VLAN の集合を指定します。ポート グループは、レート制限やポート セキュリティなどの他のネットワーク属性を指定します。仮想マシンは、仮想マシンの生成プロセス時、または仮想マシン プロパティを後で編集することにより、ポート グループに割り当てられます(図 1)。

図 1 VMware vSwitch ネットワーク設定

図 1 VMware vSwitch ネットワーク設定
※画像をクリックすると、大きな画面で表示されますpopup_icon


システム概要

Cisco Nexus 1000V シリーズは、VMware ESX または ESXi 4.0 を稼動している複数のホスト間にわたって広がるソフトウェアベースのスイッチです。Virtual Supervisor Module(VSM)と Virtual Ethernet Module(VEM)の 2 つのコンポーネントで構成されます。VSM は、ペアで展開され、スイッチのスーパーバイザとして機能します。VEM は、1 つまたは複数で展開され、スイッチ内のライン カードと同様の動作をします。

VSM は、VEM とは別に搭載できる仮想アプライアンスです。つまり、VSM は VEM が搭載されていない VMware ESX サーバ上で稼動できます。VEM は、各 VMware ESX サーバに搭載されることで、パケット フォワーディング機能を提供します。VSM のペアと複数の VEM により、単一の Cisco Nexus 1000V シリーズ スイッチが形成されます。これは、ネットワーク管理者からは単一のモジュラ スイッチに見えます。

Cisco Nexus 1000V シリーズ スイッチの各インスタンスは、VMware vCenter Server 内で vNetwork Distributed Switch(vDS)として表されます。vDS は、単一の仮想スイッチが複数の VMware ESX ホストにまたがって存在することを可能にする VMware の概念です。Cisco Nexus 1000V シリーズは、VMware VIM API を使用して VSM と VMware vCenter Server の間にリンクを確立することにより、VMware vCenter Server 内に作成されます。

VMware の管理階層は、データセンターとクラスタの 2 つの主要な要素に分けられます。データセンターには、ホスト、仮想マシン、ネットワーク スイッチ(Cisco Nexus 1000V シリーズを含む)など、VMware 展開のすべてのコンポーネントが含まれます。

注: VMware ESX ホストには、VEM を 1 つだけ搭載できます。

VMware データセンター内で、ユーザは 1 つ以上のクラスタを作成できます。クラスタとは、CPU とメモリのリソース プールを形成するホストと仮想マシンのグループのことです。クラスタ内の仮想マシンは、同じクラスタ内であれば、任意のホスト上で稼動することや、任意のホストに移動することができます。ホストと仮想マシンは、クラスタに含まれていなくてもかまいません。データセンター内に単独で存在することもできます。

仮想シャーシ

Cisco Nexus 1000V シリーズは、仮想シャーシ モデルを使用して、VSM のペアとそれらに関連付けられた VEM を表します。シスコのシャーシに基づくプラットフォームと同様に、Cisco Nexus 1000V シリーズの仮想シャーシは、スロットとモジュール(あるいはライン カード)がそれ自体と関連付けられます。VSM は、仮想シャーシ内のスロット番号 1 と 2 に常に関連付けられます。VEM は、それぞれに対応するホストが Cisco Nexus 1000V シリーズ スイッチに追加されたときの順序に基づいてスロット 3 〜 66 に連続して割り当てられます。

ネットワーク ポリシーの管理

ソフトウェアベースの仮想スイッチングの登場により、新しいデータセンター管理の課題が生じています。従来の管理モデルでは、サーバ管理者が OS とアプリケーションを管理し、ネットワーク管理者がスイッチとそれに関連付けられるポリシーを管理することが求められます。サーバとスイッチの間のリンク(通常はカテゴリ 5 ケーブル)が、管理ロール間の明確な境界となっています。Cisco Nexus 1000V シリーズの管理モデルでは、同じ 1 つのハードウェア(VMware ESX ホスト)の設定を保守しているサーバ管理者とネットワーク管理者の間のコラボレーションが要求されます。

サーバ管理者とネットワーク管理者は、別々の責任を持つ別々のエンティティです。Cisco Nexus 1000V シリーズは、この区別を維持し、管理者ごとに別々のロールを与えます。管理者間のコラボレーションは必要ですが、Cisco Nexus 1000V シリーズは、サーバ管理者とネットワーク管理者が高いレベルの自主性を持てるように設計されています。

Cisco Nexus 1000V シリーズは、VMware でネットワーク プロビジョニングを単純化するポート プロファイルと呼ばれる機能を提供します。ポート プロファイルは、サーバ管理者とネットワーク管理者の間に仮想的な境界を作成します。ポート プロファイルは、ネットワーク管理者によって定義されるネットワーク ポリシーであり、VMware vCenter Server にエクスポートされます。VMware vCenter Server 内では、ポート プロファイルは、従来の VMware ポート グループと同じ場所にある VMware ポート グループになります。サーバ管理者は、このポート プロファイルを、VMware で定義されるポート グループと同じ方法で自由に使用できます。

Switch# show port-profile name Basic-VM
port-profile Basic-VM
  config attributes:
    switchport mode access
    switchport access vlan 53
    no shutdown

新しい仮想マシンをプロビジョニングする場合、サーバ管理者は適切なポート プロファイルを選択します。Cisco Nexus 1000V シリーズは、ポート プロファイルで定義されたポリシーに基づいて新しいスイッチ ポートを作成します。サーバ管理者は、類似した仮想マシンをプロビジョニングするために、必要に応じてポート ファイルを再使用できます。

ポート プロファイルは、サーバ内の物理 NIC を設定するために使用することもできます。これらのポート プロファイル(アップリンク ポート プロファイルと呼ばれます)は、VMware ESX ホスト上の VEM のインストレーションの一部として物理 NIC に割り当てられます。

ポリシーのモビリティ


ポート プロファイルによって適用されたネットワーク ポリシーは、仮想マシンがサーバ間を移動したか、停止したか、ハイバネートしたか、再始動したかどうかにかかわらず、仮想マシンをそのライフサイクル全体にわたって追跡します。ポリシーの移行に加えて、Cisco Nexus 1000V シリーズは、ポート カウンタやフロー統計情報など、仮想マシンのネットワーク状態も移動します。Cisco NetFlow や Encapsulated Remote Switched Port Analyzer(ERSPAN)などのトラフィック モニタリング アクティビティに参加している仮想マシンは、VMotion の動作によって中断されずにこれらのアクティビティを続けることができます。

インストール

Cisco Nexus 1000V シリーズのインストールは、このドキュメントの対象範囲外です。ここでは、考え方を完全にするために、インストールの概要について説明します。インストールに関するガイダンスと詳細な手順については、Cisco Nexus 1000V シリーズ スイッチのインストレーション ガイドを参照してください。

1. ネットワーク管理者は、VSM をインストールし、1 つ以上のアップリンク ポート プロファイルを定義します。

2. サーバ管理者は、標準的な Web ブラウザを使用して Cisco Nexus 1000V シリーズ プラグインを VSM からダウンロードし、それを VMware vCenter Server にインストールします。

3. ネットワーク管理者は、VSM と VMware vCenter Server の間にリンクを作成します。この手順により、Cisco Nexus 1000V シリーズのインスタンスが VMware vCenter Server 内に作成されます。

4. サーバ管理者は、VMware vSphere Client を使用し、アップリンク ポート プロファイルを適切な物理 NIC に割り当てて、VMware ESX ホストを Cisco Nexus 1000V シリーズに追加します。

5. ネットワーク管理者は、仮想マシンと他の仮想インターフェイスで使用される 1 つ以上のポート プロファイルを定義します。

これで、Cisco Nexus 1000V シリーズのインストールは完了です。サーバ管理者は、ポート プロファイルを仮想マシンに割り当て、ゲスト OS への接続の提供を開始できます。

Virtual Supervisor Module(VSM)

VSM は、Cisco Nexus 1000V シリーズの管理プレーン機能を提供します。Cisco Nexus 7000 シリーズ スイッチのスーパーバイザ モジュールと非常によく似ている VSM は、ネットワーク管理者用の単一の管理ポイントであり、複数の VEM にまたがって設定と機能を調整できます。

従来のシスコ スイッチ(管理プレーンがハードウェアに組み込まれている)とは異なり、VSM は、仮想マシンとして展開されます。Cisco NX-OS ソフトウェア(Cisco Nexus オペレーティング システム)を稼動して、Cisco Nexus 1000V シリーズ VSM は他の仮想マシン(Linux や Microsoft Windows を稼動している仮想マシンなど)と同様の方法で、ISO ファイルまたは Open Virtualization Format(OVF)テンプレートのいずれかを使用してインストールされます。

VSM の仮想マシンの要件は、他のより一般的なゲスト オペレーティング システムとほぼ同じです。高レベルでは、VSM は、単一の仮想 CPU、2 GB の専用 RAM、および 3 つの仮想ネットワーク アダプタを必要とします(これらの仮想ネットワーク アダプタに関する詳細については、このドキュメント内で後述します)。

Cisco Nexus 1000V シリーズは、物理シャーシ内のデュアル スーパーバイザと非常によく似た VSM ハイ アベイラビリティ展開モデルを必要とします。これら 2 つの VSM は、アクティブ/スタンバイ設定で展開され、最初の VSM はプライマリ ロールで機能し、もう 1 つの VSM はセカンダリ ロールで機能します。プライマリ VSM が故障すると、セカンダリ VSM が引き継ぎます。

クロスバー ベースのモジュラ スイッチング プラットフォームとは異なり、VSM は、データ パス内に存在しないことに注意してください。一般データ パケットは、VSM へ転送されて処理されるのではなく、VEM によって直接スイッチされます。このドキュメント内で後述する 2 つの固有のケースでは、コントロール トラフィックが VSM によって処理されて、すべての VEM にわたって調整されます。

Cisco NX-OS ソフトウェア

Cisco NX-OS ソフトウェアは、モジュール性、復元性、サービサビリティを基盤として構築された、データセンター クラスのオペレーティング システムです。実績のある Cisco MDS 9000 SAN-OS ソフトウェアを基に開発された Cisco NX-OS は、継続的なアベイラビリティの確保に役立ち、ミッションクリティカルなデータセンター環境の標準を確立します。自己修復機能を備え、高度にモジュール化された Cisco NX-OS は、ゼロインパクト運用を現実化し、きわめて柔軟な運用を可能にします。データセンターの要件に特化した Cisco NX-OS は、現在および将来のデータセンターで要求されるイーサネットとストレージのネットワーキングの要件を満たす、堅牢な機能を豊富に備えています。Cisco IOS® ソフトウェアと同じ CLI を持つ Cisco NX-OS は、主要なネットワーキング標準およびシスコが持つ真のデータセンター クラスの革新的技術を実装した、最先端の OS です。

VSM ネットワーキング

VSM は、3 つの vNIC を必要とする仮想マシンです。各 vNIC は固有の機能を備えており、それらすべてが Cisco Nexus 1000V シリーズの運用に必要なものです。VSM 仮想マシン プロパティを定義するために、vNIC は、Intel e1000 ネットワーク ドライバが必要です(図 2)。

e1000 ネットワーク ドライバは、仮想マシン定義が構築されるときにデフォルトのドライバではない可能性があります。また、e1000 ドライバは、仮想マシンを定義するときに選択するオペレーティング システムによっては使用できない場合があることにも注意してください。このドライバは、仮想マシンとともに保存される仮想マシン コンフィギュレーション ファイル内で手作業で変更できます。オペレーティング システムに「Other Linux 64-bit」を選択することにより、e1000 ドライバの選択が可能になり、デフォルトのドライバとして e1000 ドライバが設定されます。

図 2 正しい仮想スーパーバイザ モジュール ネットワーキング設定

図 2 正しい仮想スーパーバイザ モジュール ネットワーキング設定
※画像をクリックすると、大きな画面で表示されますpopup_icon


注: VSM の詳細なインストール手順については、Cisco Nexus 1000V シリーズ スイッチのインストレーション ガイドを参照してください。

コントロール インターフェイス


コントロール インターフェイスは、VEM と通信するために使用されるレイヤ 2 インターフェイスです。このインターフェイスにより、VSM と VEM の間で交換されなければならない設定データだけでなく、ハートビートなどの低レベルのコントロール パケットも処理されます。コントロール インターフェイスは、自身を介して送信されるトラフィックの性質から、Cisco Nexus 1000V シリーズのソリューションにおいて最も重要なインターフェイスになっています。

コントロール インターフェイスは、常に VSM 上で最初のインターフェイスであり、一般に仮想マシン ネットワーク プロパティ内で [Network Adapter 1] というラベルが付けられます。

管理インターフェイス


管理インターフェイスは、シスコ スイッチ上で mgmt0 ポートとなるインターフェイスです。他のシスコ スイッチの管理インターフェイスと同様に、IP アドレスは mgmt0 に割り当てられます。管理インターフェイスは、VSM と VEM の間のデータ交換には使用されませんが、VSM と VMware vCenter Server の間の接続を確立し、維持するために使用されます。

管理インターフェイスは、常に VSM 上で 2 番めのインターフェイスであり、一般に仮想マシン ネットワーク プロパティ内で [Network Adapter 2] というラベルが付けられます。

パケット インターフェイス


パケット インターフェイスは、Cisco Nexus 1000V シリーズ スイッチ全体にわたって調整されなければならないネットワーク パケットを伝送するために使用されるレイヤ 2 インターフェイスです。このインターフェイスは、シスコ検出プロトコルと Internet Group Management Protocol(IGMP; インターネット グループ管理プロトコル)の 2 種類のコントロール パケット用にだけ使用されます。

パケット インターフェイスは、常に VSM 上で 3 番めのインターフェイスであり、一般に仮想マシン ネットワーク プロパティ内で [Network Adapter 3] というラベルが付けられます。

VSM と VMware vCenter の間の通信

VSM は、ポート プロファイルを伝達するためだけでなく VMware vCenter Server 内の Cisco Nexus 1000V シリーズの定義を保守するためにも使用される VMware vCenter Server とのリンクを維持します。

サーバ管理者とネットワーク管理者は、両者とも Cisco Nexus 1000V シリーズと VMware vCenter Server の間のリンクの確立に関与します。最初に、サーバ管理者が Cisco Nexus 1000V シリーズ VMware vCenter Server プラグイン(このドキュメント内で後述します)をインストールします。プラグインがインストールされた後は、ネットワーク管理者が svs 接続を定義できます。svs 接続により、VSM と VMware vCenter Server の間のリンクを定義します。この接続には、次のパラメータが含まれます。

  • VMware vCenter Server の IP アドレス
  • 通信プロトコル(常に VMware VIM over HTTPS)
  • VMware ESX ホストが存在する VMware データセンターの名前

接続が定義された後、ネットワーク管理者はその接続をイネーブルにします。これにより、リンクが確立され、VMware vCenter Server 内に Cisco Nexus 1000V シリーズのインスタンスが作成されます。各 VSM には、特定の VSM を VMware vCenter Server にバインドするために使用される固有の拡張キーが保持されています。

VMware vCenter Server 内に Cisco Nexus 1000V シリーズを作成する処理のなかで、VSM は、VEM のインストールに必要な重要情報(不透明データと呼ばれます)だけでなく、すでに定義されているすべてのポート プロファイルを伝達します。不透明データは、インストール後に VSM と通信するために必要な限られた設定詳細情報を VEM に提供します。

VSM は、すべての設定情報について信頼できるコンテナであると見なされます。VSM と VMware vCenter Server の間の接続が中断された場合、VSM は、そのリンクが回復されたときに、通信が中断されていた間に行われたすべての設定変更を VMware vCenter Server に確実に伝達する役に立ちます。

VSM と VMware vCenter Server の間の接続が確立した後、そのリンクは、主に新しいポート プロファイル、および既存のものに対するすべての変更を伝達するために使用されます。

Cisco Nexus 1000V シリーズ の VMware vCenter Server 拡張


VMware vCenter Server は、サードパーティ製の管理プラグインを使用できる拡張可能なアプリケーションです。したがって、外部アプリケーションにより、VMware vCenter Server、およびそのコンパニオン GUI である VMware vSphere Client の機能を拡張できます。Cisco Nexus 1000V シリーズは、VMware vCenter Server 拡張を使用して、Cisco Nexus 1000V シリーズとその主要なコンポーネントを VMware vSphere Client 内で適切に表示します。

Cisco Nexus 1000V シリーズ拡張は、Web ブラウザを使用して VSM の管理 IP アドレスからダウンロードされる小さい XML ファイル(cisco_nexus_1000v_extension.xml)です。このプラグインがインストールされなければ、VSM は VMware vCenter Server へのリンクを確立できません(図 3)。

図 3 XML 拡張ファイルのダウンロード

図 3 XML 拡張ファイルのダウンロード
※画像をクリックすると、大きな画面で表示されますpopup_icon


不透明データ


不透明データとは、VSM によって保守され、VSM と VMware vCenter Server の間のリンクが確立されたときに VMware vCenter Server に伝達される Cisco Nexus 1000V シリーズの設定パラメータの集まりです。不透明データには、VEM のインストール時に各 VEM が VSM との接続を確立するために必要な設定詳細情報が含まれます。

特に、不透明データには次のものが含まれます。

  • スイッチ ドメイン ID
  • スイッチ名
  • コントロールとパケットの VLAN ID
  • システム ポート プロファイル

最初のインストール後または VMware ESX ホストのリブート時に、新しい VEM がオンラインになると、その VEM は基本的にプログラムされていないライン カードになります。正しく設定されるには、VEM が VSM と通信する必要があります。VMware vCenter Server は、不透明データを VEM に自動的に送信します。VEM はそれを使用して VSM との通信を確立し、適切な設定データをダウンロードします。

Virtual Ethernet Module(VEM)

VEM は、モジュラ スイッチング プラットフォーム内のライン カードと非常によく似たネットワーク接続とフォワーディング機能を Cisco Nexus 1000V シリーズに提供します。単一シャーシ内での複数のライン カードとは異なり、各 VEM は、フォワーディングの観点から、それぞれ独立したスイッチとして動作します。

VEM は、VMware ESX と緊密に統合されています。VEM は、各 VMware ESX ホスト上にカーネル コンポーネントとしてインストールされます。これは、一般に仮想マシンとしてインストールされるほとんどの VMware 用サードパーティ製ネットワーキング サービスと対照的です。

VSM の場合とは異なり、VEM のリソースは管理されず、動的です。VEM のストレージ設置面積は一定ですが(約 6.4 MB のディスク スペース)、VMware ESX ホスト上の RAM 使用率は、Cisco Nexus 1000V シリーズの展開の設定とスケールに基づいて変化します。一般的な設定の場合、各 VEM では、10 〜 50 MB の RAM が必要になると予測できます。すべての機能をオンにし、それらの設計限界まで使用した、最大にスケールされたソリューションのハードリミットは 150 MB です。

Cisco Nexus 1000V シリーズの各インスタンスは、2 つの VSM と 1 つ以上の VEM から構成されます。一対の VSM でサポートされる VEM の最大数は 64 です。

スイッチ ポート インターフェイス

Cisco Nexus 1000V シリーズは、内部接続と外部接続に使用される複数のスイッチ ポート タイプ(仮想イーサネット(vEth)、イーサネット(Eth)、および PortChannel(Po))をサポートしています。Cisco Nexus 1000V シリーズの環境内で最も一般的なポート タイプは、仮想イーサネット インターフェイスと呼ばれる新しい概念です。このインターフェイス タイプは、仮想マシンの NIC に接続されたスイッチ ポート、または vswif や vmknic インターフェイスなどの特化されたインターフェイス タイプへの接続を表します。

vEth インターフェイスは、他のインターフェイス タイプと差別化されるいくつかの特性を備えています。vEth インターフェイスは仮想であり、そのため関連する物理コンポーネントを持たないという明らかな事実に加えて、このインターフェイスの名前付け規則は独特のものになっています。従来のシスコ インターフェイスとは異なり、vEth インターフェイスの名前は、ポートが関連付けられているモジュールを示しません。従来の物理スイッチ ポートが GigX/Y として表されるのに対し(X はモジュール番号、Y はモジュール上のポート場合)、vEth インターフェイスは vEthY で表されます。この独自の表記法は、関連する仮想マシンの場所とは無関係にインターフェイス名を同じに保つことにより、VMotion と透過的に連携することを目的としています。

vEth インターフェイスを独特のものにする 2 つめの特性は、その過渡的な性質です。与えられた vEth インターフェイスは、それに接続された仮想マシンの状態に応じて現れたり消えたりします。仮想マシンの vNIC は vEth インターフェイスへ静的にマッピングされます。新しい仮想マシンが作成された場合、vEth インターフェイスも仮想マシンの vNIC ごとに作成されます。vEth インターフェイスは、仮想マシンが存在するかぎり存在し続けます。仮想マシンが一時的にダウンすると(ゲスト OS がシャットダウンすると)、vEth インターフェイスは非アクティブな状態で残りますが、その特定の仮想マシンにバインドされたままになります。仮想マシンが削除されると、vEth インターフェイスは、新しくプロビジョニングされた仮想マシンへの接続に使用できるようになります。

Cisco Nexus 1000V シリーズには、VMware ESX ホスト内の VMNIC(物理 NIC)と関係付けられた 2 つのインターフェイス タイプが含まれます。イーサネット(または Eth)インターフェイスは、Cisco Nexus 1000V シリーズで VMNIC に対応するものです。Eth インターフェイスは、Cisco IOS ソフトウェアの慣例に従った「Gig」や「Fast」などの速度ではなく、Cisco NX-OS の名前付け規則「Eth」を使用して標準のシスコのインターフェイスの表記法(EthX/Y)で表現されます。これらの Eth インターフェイスは、モジュール固有であり、環境内でほとんど静的になるように設計されています。

PortChannel は、Cisco Nexus 1000V シリーズでサポートされる第 3 のインターフェイス タイプです。PortChannel は、同じ VEM 上の複数の Eth インターフェイスを集約したものです。

注: PortChannel は、デフォルトでは作成されません。そのため、明示的に定義する必要があります。

スイッチ フォワーディング

いろいろな意味で、Cisco Nexus 1000V シリーズ スイッチは、物理イーサネット スイッチに似ています。パケット フォワーディングの場合、Cisco Nexus 1000V シリーズは、他のイーサネット スイッチが適用するのと同じ手法を使用し、パケットが転送される場所を決定するために使用される、MAC アドレスからポートにマッピングするテーブルを維持します。

Cisco Nexus 1000V シリーズは、他のモジュラ スイッチとは少し異なる方法でフォワーディング テーブルを維持します。中央集中型フォワーディング エンジンを備えた物理スイッチとは異なり、各 VEM は独立したフォワーディング テーブルを維持します。異なる VEM 上のフォワーディング テーブル間で同期は行われません。また、ある VEM 上のポートから別の VEM 上のポートへフォワーディングするという概念は存在しません。VEM に対してローカルではないデバイス宛てのパケットは、外部ネットワークに転送されます。これにより、パケットは、他の VEM へ次々と転送される可能性があります。

MAC アドレス ラーニング


集中管理されたスイッチ内のこの分散フォワーディング モデルは、Cisco Nexus 1000V シリーズが MAC アドレス ラーニングを処理する方法によって説明されます。MAC アドレスは、静的または動的な方法のいずれかにより、単一の Cisco Nexus 1000V シリーズ スイッチ内で複数回学習できます。スタティック エントリは、VEM 上で稼動している仮想マシンに対して自動的に生成されます。これらのエントリは、タイムアウトしません。VEM 上で稼動していないデバイスの場合、VEM は、サーバ内の物理 NIC によって MAC アドレスを動的に学習できます。

各 VEM は、別々の MAC アドレス テーブルを維持します。したがって、単一の Cisco Nexus 1000V シリーズ スイッチは、与えられた MAC アドレスを VEM ごとに 1 つとして複数回学習する可能性があります。たとえば、ある VEM が仮想マシンをホスティングしていると、その VEM 上でその仮想マシンの MAC アドレスが静的に学習されます。同じ Cisco Nexus 1000V シリーズ スイッチ内の別の VEM は、この仮想マシンの MAC アドレスを動的に学習します。したがって、Cisco NX-OS CLI 内では、この仮想マシンの MAC アドレスが、ダイナミック エントリとスタティック エントリの 2 回表示されることになります。

ループ防止


Cisco Nexus 1000V シリーズを差別化するもう 1 つの特性は、スパニング ツリー プロトコルを稼動しないことです。これは、他のイーサネット スイッチとは大きく異なっていて、壊滅的なネットワーク ループを発生させる可能性があるように見えますが、実際には Cisco Nexus 1000V シリーズでは、スパニング ツリー プロトコルを必要としない単純かつ効果的なループ防止戦略が実装されます。

Cisco Nexus 1000V シリーズは、スパニング ツリー プロトコルに関与しないため、Bridge Protocol Data Unit(BPDU; ブリッジ プロトコル データ ユニット)パケットに応答せず、それらを生成することもありません。Cisco Nexus 1000V シリーズ スイッチで受信された BPDU パケットは、廃棄されます。

Cisco Nexus 1000V シリーズは、単純な手法を使用してループを防止します。物理イーサネット スイッチと同様に、Cisco Nexus 1000V シリーズは、発信元と宛先の MAC アドレス ルックアップを実行して、フォワーディング決定を行います。VEM は、ループ防止ロジックをイーサネット インターフェイス上のすべての着信パケットに適用します。このロジックは、発生する可能性のあるループを識別するために使用されます。物理イーサネット インターフェイス上のすべての入力パケットは、宛先 MAC アドレスが VEM に対して内部であることを保証するために検査されます。宛先 MAC アドレスが外部の場合、Cisco Nexus 1000V シリーズはそのパケットを廃棄して、物理ネットワークへのループ バックを防ぎます。

注: Cisco Nexus 1000V シリーズは、VEM とファーストホップ アクセス スイッチの間のループをスパニング ツリー プロトコルを使用しないで防止します。しかし、この機能は、スパニング ツリー プロトコルをすべてのアクセス スイッチ上でディセーブルにするわけではありません。スパニング ツリー プロトコルは、アクセス スイッチが物理トポロジ内の他の場所でループを防止するためにまだ必要です。

VEM と VSM の間の通信

VSM と同様に、各 VEM は、コントロール インターフェイスとパケット インターフェイスを備えています。これらのインターフェイスは、管理されておらず、エンド ユーザは直接設定できません。VEM は、VMware vCenter Server が提供する不透明データを使用して、コントロール インターフェイスとパケット インターフェイスを正しい VLAN で設定します。その後、VEM は正しいアップリンク ポート プロファイルをコントロール インターフェイスとパケット インターフェイスに適用して、VSM との通信を確立します。

VSM が VEM を認識した後、新しいモジュールが Cisco Nexus 1000V シリーズ スイッチの仮想シャーシに仮想的に挿入されます。VSM CLI は、物理シャーシの場合とほぼ同様に、新しいモジュールの電源が投入されたことをネットワーク管理者に通知します。

モジュール割り当てはシーケンシャルです。つまり、VEM は 3 〜 66 の中で使用可能な最も小さいモジュール番号に割り当てられます。VEM が初めてオンラインになったとき、VSM はモジュール番号を割り当て、VMware ESX サーバの固有のユーザ ID(UUID)を使用してそのモジュールを追跡します。それにより、VMware ESX ホストが何らかの理由で接続を失うか電源が切れても、そのホストが再びオンラインになったときに、VEM がそのモジュール番号を保持していることが保証されます。

VSM は、それに関連付けられた VEM とのハートビートを維持します。このハートビートは、2 秒間隔で送信されます。VSM は、応答を 8 秒以内に受信しないと、VEM が仮想シャーシから取り外されたと見なします。VEM は、接続の問題が原因で応答していない場合は、それの最新の既知の良好なステートでパケットをスイッチングし続けます。稼動中の VEM と VSM の間で通信が復元されると、VEM が再プログラミングされるので、ネットワーク トラフィックにわずかな時間(1 〜 15 秒)の停止が生じます。

VSM と VEM の間のすべての通信は、128 ビット アルゴリズムを使用して暗号化されます。

ドメイン ID


物理イーサネット スイッチは、一般に、ネットワーク管理者から見えない内部ネットワークを使用してデータ プレーンとコントロール プレーンの間でコントロール情報を伝達します(シスコ スイッチは Ethernet Out-of-Band Channel(EoBC)と呼ばれる内部ネットワークを使用します)。この内部ネットワークは、設計で切り離されています。Cisco Nexus 1000V シリーズの場合、VSM と VEM の間のコントロール パケットは、物理ネットワークを通過します。可能性は低いですが考えられるシナリオとして、VEM が、まったく異なる Cisco Nexus 1000V シリーズを管理している VSM からコントロール パケットを受信する場合があります。仮にこの VEM がそのようなパケット(たとえば、インターフェイスを再設定する要求)に応答したとしても、この VEM が期待されるパケットを送信することはありません。このようなシナリオを回避するために、Cisco Nexus 1000V シリーズは、ドメイン ID と呼ばれるソリューションを実装します。

ドメイン ID は、Cisco Nexus 1000V シリーズのパラメータであり、VSM と VEM を互いに関係しているものとして識別するために使用されます。Cisco Nexus 1000V シリーズのドメイン ID は、VSM が最初にインストールされたときに定義され、VMware vCenter Server に送信される不透明データの一部になります。

VSM から関連する VEM に送信される各コマンドには、このドメイン ID がタグ付けされます。VSM と VEM が同じドメイン ID を共有している場合、VEM は VSM からの要求とコマンドを受け入れ、応答します。VEM が適切なドメイン ID でタグ付けされていないコマンドまたは設定要求を受信すると、その要求は無視されます。同様に、VSM が誤ったドメイン ID でタグ付けされた VEM からのパケットを受信すると、そのパケットは無視されます。

パケット インターフェイス通信


パケット インターフェイスは、選択されたパケットを VEM と VSM の間で送信するために使用されます。このインターフェイスは、シスコ検出プロトコルと IGMP の 2 種類のコントロール パケットにだけ使用されます。

VSM は、Cisco NX-OS CLI によって、統合されたシスコ検出プロトコル ビューをネットワーク管理者に提供します。VEM はシスコ検出プロトコル パケットを受信すると、そのパケットを VSM へ再送信するので、VSM はそのパケットを解析し、シスコ検出プロトコルのエントリを CLI に表示できます。

パケット インターフェイスは、IGMP を複数の VEM にわたって調整するためにも使用されます。たとえば、VEM が IGMP 加入要求を受信した場合、その要求は VSM へ送信されます。これにより、その要求は、スイッチ内のすべての VEM にわたって調整されます。

ポート プロファイル

ポート プロファイルは、ネットワーク ポリシーを定義し、スイッチ インターフェイスに適用するために使用される主要なメカニズムです。ポート プロファイルは、完全なネットワーク ポリシーを作成するために組み合わされたインターフェイスレベルの設定コマンドの集合です。

ポート プロファイルは、VSM 上で作成され、VMware VIM API を使用して VMware vCenter Server に VMware ポート グループとして伝達されます。伝達後、ポート プロファイルは、VMware vSphere Client 内で表示され、仮想マシンの vNIC に適用できるようになります。

サーバ管理者が新しい仮想マシンをプロビジョニングするとき、ネットワーク設定に関連したダイアログ ボックスが表示されます。このダイアログ ボックスは、Cisco Nexus 1000V シリーズが存在しているかどうかに関係なく一貫しています。つまり、新しい仮想マシンをプロビジョニングするためのワークフローは、Cisco Nexus 1000V シリーズが使用されても変化しません。サーバ管理者は、ポート プロファイルを選択して仮想マシンの各 vNIC に適用します。

新しくプロビジョニングされた仮想マシンの電源が投入されると、その仮想マシンに含まれる vNIC ごとに vEth インターフェイスが Cisco Nexus 1000V シリーズ上に作成されます。vEth は、選択されたポート プロファイル内の定義を継承します。

ポート プロファイルの概念は新しいものですが、ポート プロファイル内の設定には、従来のスイッチ上のスイッチ ポートを管理するために使用されるのと同じシスコの構文が使用されます。ネットワーク管理者は、スイッチ コンフィギュレーション モードで新しいポート プロファイルを定義します。その後、ネットワーク管理者は、必要なインターフェイス設定コマンドを適用します。ポート プロファイルには、イネーブルと VMware ポート グループがマークされます。ポート プロファイルをイネーブルにし、VMware ポート グループとして定義するこの手順により、ポート プロファイルは VMware vCenter Server に伝達され、数秒以内にサーバ管理者が使用できるようになります。

ライブ ポリシー変更

ポート プロファイルは、静的なエンティティではありません。ネットワークの変化の必要性に応じて変更できる動的なポリシーです。アクティブなポート プロファイルに対する変更は、そのプロファイルを使用している各スイッチ ポートに適用されます。ポート プロファイルのこの機能は、新しいネットワーク ポリシーを適用するとき、または既存のポリシーを変更するときに非常に有用です。

アップリンク プロファイル

ポート プロファイルは、vEth の設定を管理するためだけに使用されるのではありません。VMware ESX ホスト内の物理 NIC を管理するためにも使用されます。ポート プロファイルが定義される場合、ネットワーク管理者は、そのプロファイルが vEth インターフェイスと物理 NIC のいずれを管理するために使用されるかを決定します。デフォルトでは、ポート プロファイルは、vEth の管理のために使用されると見なされます。

物理 NIC 上で使用するためのポート プロファイルを定義するには、ネットワーク管理者が機能アップリンク オプションをプロファイルに適用する必要があります。このオプションが使用されると、ポート プロファイルは、サーバ管理者だけが VMware ESX サーバ内の物理 NIC に適用できるようになります。

アップリンク ポート プロファイルは、VMware ESX ホストが Cisco Nexus 1000V シリーズに最初に追加されるときに、物理 NIC に適用されます。サーバ管理者には、VEM に関連付けられる物理 NIC とその物理 NIC に関連付けられる特定のアップリンク ポート プロファイルを選択できるダイアログ ボックスが提供されます。さらに、サーバ管理者は、ホストがスイッチに追加された後に VEM へ追加されるインターフェイスにも、アップリンク ポート プロファイルを適用できます。

システム VLAN


システム VLAN は、ポート プロファイル内に追加できるオプションのパラメータで定義されます。このパラメータが使用されると、ポート プロファイルは、Cisco Nexus 1000V シリーズの不透明データに含まれる特別なシステム ポート プロファイルになります。システム ポート プロファイルを使用し、定義されたシステム VLAN のいずれかに属するインターフェイスは、VEM が VSM と通信しない場合であっても、VMware ESX のブートアップ時に自動的にイネーブルになります。VMware ESX ホストがブートし、VSM と通信できない場合は、この動作により、重要なホスト機能の使用がイネーブルになります。

コントロール VLAN とパケット VLAN は、システム VLAN として定義する必要があります。他の VLAN もシステム VLAN として定義すると(vswif や vmknic インターフェイスに使用される VLAN など)有用な場合があります。一般的な仮想マシンのデータに使用される VLAN は、システム VLAN として定義すべきではありません。

Cisco Nexus 1000V シリーズ ネットワーク設計


ここでは、Cisco Nexus 1000V シリーズの物理アクセス レイヤへの接続に関連した設計に関する考慮事項について説明します。

ネットワーク設計の考慮事項

Cisco Nexus 1000V シリーズを展開する場合は、複数の設計に関する考慮事項に対処しなければなりません。基本的なレベルでは、Cisco Nexus 1000V シリーズを物理アクセス レイヤに接続するときに使用される設計方針は、2 つの物理スイッチを互いに接続するときに使用されるものと似ています。いくつかの設計考慮事項は、Cisco Nexus 1000V シリーズ特有のものです。各 VEM は、多くの場合、2 つのアクセス レイヤ スイッチに接続されます。デュアル アクセス スイッチ設計は、このセクションの焦点です。

設計目標

Cisco Nexus 1000V シリーズのネットワーク設計には、2 つの主要な目標があります。1 つめは、ハイ アベイラビリティを実現するようにネットワークを設計することです。実際には、そのような設計により、可能なかぎりシングル ポイント障害を制限します。VMware ESX は、サーバ管理者が仮想マシンのアベイラビリティを確保するのに役立つ堅牢な機能を提供します。ネットワーク アベイラビリティについては、Cisco Nexus 1000V シリーズで実現します。アベイラビリティは、通常、各 VEM と物理ネットワークの間の冗長リンクによって強化され、ネットワークがリンクや物理スイッチの障害から回復できるようにします。

2 つめの設計目標は、VMware トラフィック パターンの特異性と仮想マシンのパフォーマンス要件を考慮することです。各 VMware ESX ホストは、数種類のトラフィックを生成し、受信します。これらのトラフィックはそれぞれ独自の特性を持っています。ネットワーク管理者は、トラフィックを優先順位付けして、スイッチのアップタイム、アプリケーションのパフォーマンス、および適切な VMware 機能を保証する必要があります。

トラフィック分類

任意のネットワーク内でのトラフィック タイプの分類は、簡単には達成できません。VMware 環境では、トラフィックが、仮想化されるアプリケーションのタイプに基づいて変化します。ただし、いくつかのトラフィック タイプは識別でき、一般的な優先順位付けを適用できます。一般的な VMware 展開でのトラフィックの一般分類は次のとおりです。

  • コントロール トラフィック:コントロール トラフィックは、Cisco Nexus 1000V シリーズによって生成され、VSM と VEM の間だけでなく、プライマリとセカンダリの VSM 間でも交換されます。ごくわずかな帯域幅(10 KBps 未満)しか必要としませんが、絶対的な優先順位を要求します。コントロール トラフィックは、Cisco Nexus 1000V シリーズの機能が適切に働くために不可欠であり、とても重要です。コントロール トラフィックは、Cisco Nexus 1000V シリーズのネットワークの中で最も重要なトラフィックであると見なす必要があります。
  • 仮想マシン データ トラフィック:データ トラフィックは、仮想マシンで送受信されるすべてのトラフィックを一般化したものです。VMware ESX ホスト内では、これが主要なトラフィック タイプです。明らかに、データ トラフィックは高い優先順位を必要とします。VSM 管理インターフェイスは、このカテゴリの範囲内になります。
  • VMware ESX 管理トラフィック:VMware vCenter Server では、VMware ESX ホストの監視と設定を行うために VMware ESX 管理インターフェイスへのアクセスが必要です。管理トラフィックは、一般に小さい帯域幅しか必要としませんが、高優先順位のトラフィックとして処理する必要があります。
  • VMware VMmotion トラフィック:VMware VMotion トラフィックは常に発生するわけではありません。つまり、ほとんどの時間、VMware VMotion は帯域幅を使用しません。VMware VMotion が開始されると、通常、10 〜 60 秒の間にわたってデータのバーストが発生します。VMware VMotion は、帯域幅依存ではありません。このタイプのトラフィックがライン レートより小さい帯域幅に直面すると、使用可能な帯域幅の大きさに基づいて仮想マシンの移動イベントの持続期間が長くなります。機能としてのその人気の高さにもかかわらず、VMware VMotion トラフィックは、一般に、他のトラフィック タイプに対して中程度の優先順位と見なすことができます。
  • パケット トラフィック:パケット トラフィックは、選択されたパケットを VSM に転送して処理するために使用されます。パケット インターフェイスに必要な帯域幅はきわめて小さく、その使用は非常に断続的です。シスコ検出プロトコルと IGMP の機能を無効にすると、パケット トラフィックはまったく存在しなくなります。このインターフェイスの重要性は、IGMP の使用と直接的に係わっています。IGMP を展開しなければ、このインターフェイスはシスコ検出プロトコルにだけ使用されます。これは、重要なスイッチ機能とは見なされません。

VLAN の一貫性

物理インフラストラクチャ上で適切に VLAN を設定することは、Cisco Nexus 1000V シリーズを確実に正しく機能させるために重要です。物理スイッチ上に定義される VLAN には普遍的な効果があります。つまり、VLAN 10 内で設定されたスイッチ上のすべてのポートは同じ VLAN 内に存在します。同じスイッチ上に ID が 10 の VLAN が 2 つ存在することは概念上ありえません。Cisco Nexus 1000V シリーズに対しても同じことが言えますが、スイッチ アーキテクチャは、物理スイッチ設定が正しいものであることに依存して、この一貫性を確保します。

複数 VEM は、VEM 間接続のために物理イーサネット スイッチを必要とします。各 VEM は、Cisco Nexus 1000V シリーズ上に定義されるすべての VLAN に対して一貫した接続が必要です。したがって、Cisco Nexus 1000V シリーズ上に定義されるすべての VLAN は、各 VEM に接続されるすべてのアップストリーム スイッチ上でも定義されなければなりません。

各 VLAN は、IEEE 802.1q トランキングを使用して各 VEM へトランク接続される必要があります。必須ではありませんが、各 VEM にアップリンク ポート プロファイルを一貫して適用すべきです。

トラフィックの分離


従来の VMware ネットワーク設計では、VMware ESX ホストにトランク接続される VLAN を最低 3 つ必要とします。これらの VLAN は、仮想マシン データ、VMware ESX サービス コンソール、および VMkernel(VMware VMotion)用に使用され、オプションとして、IP ベースのストレージまたは追加の仮想マシン接続用に使用される VLAN があります。Cisco Nexus 1000V シリーズでは、コントロール インターフェイスとパケット インターフェイスをサポートするための追加の VLAN が必要です。

コントロール インターフェイスとパケット インターフェイスは、これら 2 つのインターフェイスが同じ VLAN を共有することを妨げる設定要件や CLI の強制がないとしても、別々の VLAN 上に展開すべきです。別々の VLAN 上への展開は、いくつかの理由から推奨されます。

コントロール インターフェイスは、パケット インターフェイスよりはるかに通信の頻度が高く、ブロードキャストに基づいたものになっています。これら 2 つのインターフェイスが同じ VLAN 上に存在した場合、パケット インターフェイスは不必要なブロードキャスト トラフィックを受信することになります。また、パケット インターフェイスも重要ではありますが、全体的なシステムの機能にとってはコントロール インターフェイスの方がはるかに重要です。コントロール インターフェイスを外部の影響から隔離しておくことにより、システムの動作の信頼性を確保する役に立ちます。

複数の Cisco Nexus 1000V シリーズ スイッチの間では、それぞれのコントロール インターフェイスとパケット インターフェイスに同じ VLAN を共有できますが、理想としては、Cisco Nexus 1000V シリーズごとに別々の VLAN を用意します。複数の Cisco Nexus 1000V シリーズ スイッチの間で同じコントロール VLAN とパケット VLAN が共有される場合は、ドメイン ID の一意性が保証されるように注意してください。

アップストリーム スイッチ接続

Nexus 1000V は、標準に基づいたイーサネットをサポートする任意のアップストリーム スイッチ(任意のシスコ スイッチと他のベンダー製のスイッチ)と接続でき、追加の機能がアップストリーム スイッチ上に存在しなくても適切に機能します。Cisco Nexus 1000V シリーズのソリューションの設計作業のほとんどは、適切なアップストリーム スイッチ接続に重点が置かれています。Cisco Nexus 1000V シリーズ スイッチを物理スイッチに接続することは、2 台の物理スイッチを互いに接続することとは異なります。

Cisco Nexus 1000V シリーズ スイッチは、標準アップリンクを使用する方法と PortChannel を使用する方法の 2 とおりの方法で物理インフラストラクチャに接続できます。

個々のアップリンク


標準アップリンクとは、VEM から物理スイッチへの PortChannel のメンバーではないアップリンクです。複数の標準アップリンク リンク間でロード バランシングする機能およびハイ アベイラビリティ特性は提供されません。標準アップリンクが故障しても、それを引き継ぐセカンダリ リンクは存在しません。2 つの標準アップリンクを定義して同じ VLAN を保持すると、その環境内でループが発生するリスクがあるため、そのような構成はサポートされていません。Cisco NX-OS は、そのような状態が生じると、警告を発します。

いくつかのシナリオでは、単一の標準アップリンクが使用されます。たとえば、単一の NIC しか装備していない VMware ESX ホストの場合が該当します。もう 1 つの考えられるシナリオとして、専用バックアップ ネットワークに接続される単一の NIC など、ハイ アベイラビリティを必要としないセカンダリ ネットワークに接続されるホストがあります。しかし、ほとんどのデータセンター ネットワークの要件では、標準アップリンクは、あるとしても、Cisco Nexus 1000V シリーズの設計で使用されることはめったにありません。

PortChannel


Cisco Nexus 1000V シリーズは、標準 PortChannel と virtual PortChannel Host Mode(vPC-HM)の 2 つのモードをサポートする PortChannel メカニズムを実装します。どのモードでも、PortChannel は標準 PortChannel CLI コンストラクトを使用して管理されますが、各モードの動作は異なったものになります。

Cisco Nexus 1000V シリーズ上の標準 PortChannel は、他のシスコ スイッチ上の EtherChannel と同じように動作し、Link Aggregation Control Protocol(LACP)をサポートします。標準 PortChannel では、PortChannel 内のすべてのアップリンクがアップストリーム スイッチ上の同じ EtherChannel 内になければなりません。

標準 PortChannel は、クラスタ化された 2 台以上の物理スイッチに分散できます。クラスタ化スイッチング テクノロジーの例には、Catalyst® 6500 Virtual Switching System 1440、Cisco Nexus 7000 シリーズ スイッチ上の virtual PortChannel、および Cisco Catalyst Blade Switch 3120 for HP などがあります。クラスタ化されたスイッチは、単一のスイッチとして機能し、結果としてそれらにまたがる EtherChannel が作成されます。このクラスタリングは、Cisco Nexus 1000V シリーズに対して透過的です。

Virtual Port Channel Host Mode


ほとんどのアクセス レイヤ スイッチがクラスタリング テクノロジーをサポートしていないのにもかかわらず、ほとんどの Cisco Nexus 1000V シリーズの設計では、複数のスイッチにまたがる PortChannel を必要とします。こうしたスイッチ間の分散を可能にするために、vPC-HM で PortChannel を使用できます。vPC-HM では、PortChannel がサブグループに分割されます。各サブグループは、1 台のアップストリーム物理スイッチへの 1 つ以上のアップリンクを表します。

注: vPC-HM が使用される場合、Cisco Nexus 1000V シリーズは、2 つのサブグループ 0 と 1 だけをサポートします。

PortChannel 内で同じ物理スイッチに接続さているリンクは、アップストリーム スイッチから受信されるシスコ検出プロトコル パケットを使用することにより、自動的に同じサブグループにまとめられます。あるいは、インターフェイスレベルの設定を使用して、インターフェイスを特定のサブグループに手作業で割り当てることもできます。

vPC-HM が使用されると、VEM 上の各 vEth インターフェイスは、ラウンドロビン メカニズムを使用して 2 つのサブグループのどちらかにマッピングされます。vEth インターフェイスからのすべてのトラフィックは、割り当てられたサブグループを使用します。ただし、割り当てられたサブグループが使用不可能な場合、vEth インターフェイスは、もう一方のサブグループにフェイルオーバーします。最初に割り当てられたサブグループが再び使用可能になると、トラフィックは元の場所に戻ります。次に、各 vEth インターフェイスからのトラフィックは、それに割り当てられたサブグループ内で、設定されたハッシング アルゴリズムに基づいてハッシュが計算されます。

vPC-HM は、ほとんどの Cisco Nexus 1000V シリーズの展開で推奨される方法です。

ロード バランシング


Cisco Nexus 1000V シリーズは、PortChannel 内の物理インターフェイス間でトラフィックをロードバランシングする 17 種類のハッシング アルゴリズムを提供しています。これらのアルゴリズムは、発信元ベース ハッシングとフローベース ハッシングの 2 つのカテゴリに分けられます。

使用されるハッシング アルゴリズムは、使用可能な設定オプションに影響を与え、アクセス レイヤ スイッチ上での設定変更が必要になる場合もあるので、慎重に選択してください。Cisco Nexus 1000V シリーズで使用されるデフォルトのハッシング アルゴリズムは、発信元 MAC アドレス ハッシング(発信元ベース ハッシュ)です。

発信元ベース ハッシング


発信元ベース ハッシング アルゴリズムは、PortChannel 内のリンクの数に関係なく、MAC アドレスが PortChannel 内の単一リンクにだけ送信されることを保証するのに役立ちます。発信元ベース ハッシングを使用する場合でも、アップストリーム スイッチは VEM と接続するときに EtherChannel を使用する必要があります。

発信元ベース ハッシングでは、次の条件下で MAC アドレスが PortChannel 内のインターフェイス間を移動する可能性があります。

  • 仮想マシンが新しい VMware ESX または ESXi ホストに移動する(VMware VMotion、VMware High Availability など)。
  • PortChannel リンクに障害が発生し、ハッシングが再計算される。
  • リンクが PortChannel 追加され、ハッシングしなおされる。

次の Cisco Nexus 1000V シリーズのアルゴリズムは、発信元ベース ハッシュに分類できます。

  • 仮想ポート ID
  • 発信元 MAC アドレス
  • VLAN
  • 発信元 IP アドレス

フローベース ハッシング


フローベース ハッシングでは、単一 MAC アドレスからのトラフィックを PortChannel 内の複数のリンクに同時に分配できます。フローベースのハッシュを選択すると、仮想マシンが使用できる帯域幅が増加し、より細かいロード バランシングを適用することにより、PortChannel 内のアップリンクの利用率が向上する可能性があります。

フローベース ハッシング アルゴリズムには、次のハッシュを使用するアルゴリズムがあります。

  • パケット宛先
  • レイヤ 4 ポート
  • 発信元アドレス、宛先アドレス、およびレイヤ 4 ポートの組み合わせ

コントロール インターフェイスの優先順位付け


コントロール インターフェイスは、VSM と VEM の間の重要なリンクです。コントロール インターフェイスは、Cisco Nexus 1000V シリーズの実装の中で最も重要なインターフェイスです。両方の VSM 上と各 VEM 上のコントロール インターフェイスには、最低限の帯域幅を与えるよう特に注意が必要です。各コントロール インターフェイスは、秒あたり最低で 10 KB の帯域幅が必要になると予測されます。ネットワーク トラフィックの拡張バースト(VMware VMotion イベントなど)によって、コントロール インターフェイスの帯域幅が不足することもあります。

スパニング ツリー プロトコル


スパニング ツリー プロトコルは、ネットワーク ツリーを構築しようとするときに、各インターフェイス上で一連のステートを経由します。スパニング ツリー プロトコルがコンバージする必要がある場合、この過程によって各インターフェイスでダウンタイムが発生します。この過程は、Cisco Nexus 1000V シリーズに接続されるポートには不要です。スイッチ ポート上で PortFast 機能を使用することにより、シスコ スイッチは、スパニング ツリー プロトコル ステートの進行を抑制し、フォワーディング ステートへ直接移行できます。PortFast は、インターフェイスごとに設定されるものであり、VEM に接続されたインターフェイス上でイネーブルにする必要があります。

VSM 設計

VSM は、他の仮想マシンと同じように展開される標準的な仮想マシンです。従わなければならない固有の設計考慮事項はありません。

仮想マシン設計


Cisco Nexus 1000V シリーズの VSM 仮想マシンには、展開に関していくつかの基本的な考慮事項があります。アクティブ/スタンバイ ペアの各 VSM は、別々の VMware ESX ホスト上で稼動する必要があります。この要件により、どちらかの VMware ESX サーバが故障した場合のハイ アベイラビリティが確保されます。また、VMware ESX の anti-affinity オプションを使用して、VSM を別々のサーバ上に保持することもできます。このオプションでは、VSM が最終的に同じサーバ上になることは禁止されません。anti-affinity は、VMware Distributed Resource Scheduler(DRS)が仮想マシンを新しいマシンに移行することを禁止します。VMware High Availability によって VSM が最終的に同じホスト上になると、VMware DRS は、5 つ星の推奨を発行して、どちらかの VSM を移動します。

VSM 仮想マシンに対して CPU と メモリが保証される必要があります。つまり、各仮想マシンに必要な 2 GB のメモリが、他の仮想マシンと共有されてはなりません。さらに、最低 1 GHz の CPU 機能が各 VSM 仮想マシンに対して確保される必要があります。

VSM 上の mgmt0 インターフェイスは、必ずしも独自の VLAN を必要としません。実際、VMware vCenter Server が属しているのと同じ VLAN を使用するだけの場合もあります。VSM 管理 VLAN は、他の仮想マシン データ VLAN とまったく違いはありません。別の方法として、ネットワーク管理者は、ネットワーク デバイス管理用に専用の VLAN を指定することもできます。

隣接関係


VSM と VEM のコントロール インターフェイスとパケット インターフェイスはレイヤ 2 インターフェイスです。これらは、IP ベースの通信をサポートしません。VSM から各 VEM へのレイヤ 2 隣接関係が必要です。また、レイヤ 2 隣接関係は、ハイ アベイラビリティ ペアとして設定された VSM 間で維持されなければなりません。

遅延


VSM が VEM と通信するために使用されるコントロール プロトコルは、Cisco MDS 9000 ファミリや Cisco Nexus 7000 シリーズ シャーシなどのシスコ モジュール シャーシで使用されるものと似ています。このプロトコルは、ネットワーク コンテンションが発生する可能性のない、緊密に制御された、パケット ロスのない、低遅延のレイヤ 2 ネットワークで動作するように設計されました。Cisco Nexus 1000V シリーズの実装の場合、このプロトコルは、データセンター ネットワーク上で稼動します。

このコントロール プロトコルは、Cisco Nexus 1000V シリーズ向けに、データセンター ネットワークのざまざまなパフォーマンス特性を考慮するように修正されていますが、設計上の制限が存在します。Cisco Nexus 1000V シリーズは、単一のデータセンター内で稼動するように設計されました。Cisco Nexus 1000V シリーズでは、VSM と VEM の間で長いデータセンター間距離はサポートされません。

一般的なガイドラインとして、VSM と VEM の間のラウンドトリップ遅延は、50 ミリ秒未満にする必要があります。

従来のシスコ ネットワーク

ここでは、従来のアクセス レイヤ設計での Cisco Nexus 1000V シリーズの展開に関するさまざまなシナリオについて説明します。ここでの「従来」とは、2 台の独立したアクセス レイヤ スイッチに接続される複数の NIC を備えた VMware ESX ホストを意味しています。

2 NIC 設計例

2 つの NIC を備えるホストは、VMware ESX を展開するとき、特にブレードと 10 Gbps 接続ホストの場合にきわめて一般的です。この設計は、ほとんど設定の変化する余地がないため、Cisco Nexus 1000V シリーズの観点からすれば最も単純なものでもあります。

この設計では、2 台のアクセス スイッチに接続され、vPC-HM で設定された単一の PortChannel に両方の NIC が含まれます(図 4)。単一のアップリンク プロファイルが両方の NIC に適用されます。ロード バランシングは変化しますが、そのために発信元ベース ハッシング アルゴリズムが必要です。VLAN ハッシングと発信元 MAC アドレス ハッシングが記述されますが、発信元 MAC アドレス ハッシングが推奨される方法です。

この設計で VLAN ハッシングを使用すると、1 Gbps NIC 上でのロード バランシングが望ましくない結果になる可能性があります。2 つの 1 Gbps NIC を使用した場合、データ VLAN と VMware VMotion VLAN が同じアップリンク ポートにハッシュされる可能性が生じます。VMware VMotion が開始されると、すべての仮想マシンが、VMware VMotion セッションと同じ帯域幅を求めて競合することになります。10 Gbps NIC では、使用可能な帯域幅が大きいため、この影響は無視できるほど小さいです。

より望ましい設定では(特に 1 Gbps ホストの場合)、発信元 MAC アドレス ハッシングを使用することにより、仮想マシンの負荷を両方のアップリンクに分散します。この設定では、VMware VMotion の開始時に、帯域幅の要求が競合する仮想マシンの数が減少します。

図 4 vPC-HM を使用した単一 PortChannel による 2 NIC

図 4 vPC-HM を使用した単一 PortChannel による 2 NIC
※画像をクリックすると、大きな画面で表示されますpopup_icon


4 NIC 設計例

4 NIC 設計では、データ トラフィックが他のすべてのトラフィック タイプと分けられることで、柔軟性が向上します。この設計では、2 つの PortChannel が vPC-HM で使用されます。各 PortChannel の構成には、各アクセス スイッチへのリンクが 1 つずつ含まれます。この場合も、発信元ベース ハッシングが必要です。図 5 は、この設定の例を示しています。vPC-HM を使用した 2 つの PortChannel であり、それぞれが両方のアクセス スイッチへのリンクを備えています。各 vPC-HM サブグループは、単一リンクで構成されます。アクセス スイッチ上で EtherChannel を稼動する必要はありません。

図 5 vPC-HM を使用した 2 つの PortChannel による 4 NIC

図 5 vPC-HM を使用した 2 つの PortChannel による 4 NIC
※画像をクリックすると、大きな画面で表示されますpopup_icon


この設計の主な利点は、VMware VMotion が仮想マシン データ トラフィックに影響を与えないことです。PortChannel 1 はすべての仮想マシン データを伝送します。PortChannel 2 は VMware VMotion、サービス コンソール、およびコントロールとパケットの VLAN を伝送します。

単一 PortChannel による代替


別の方法として、複数 PortChannel を使用せずに 4 NIC ソリューションを設計することもできます。単一の vPC-HM ベースの PortChannel を使用して、仮想マシンの負荷を可能なかぎり多くの NIC に分散できます。

この設計の利点は、仮想マシン データ トラフィックに対して 4 つすべての NIC を使用できること、およびフローベース ハッシングをサポートできることです。欠点として、当然のことながら、VMware VMotion トラフィックが再びデータ トラフィックと混じりあうことで、帯域幅の要求が競合する可能性があります。図 6 は、vPC-HM を使用した単一 PortChannel 内の 4 つの NIC による設計を示しています。フローベース ハッシングを使用する場合、各アップストリーム スイッチは、EtherChannel で設定される必要があります(図を参照)。発信元ベース ハッシングを使用する場合、アップストリーム スイッチは EtherChannel を稼動する必要はありません。

図 6 vPC-HM を使用した 1 つの PortChannel による 4 NIC

図 6 vPC-HM を使用した 1 つの PortChannel による 4 NIC
※画像をクリックすると、大きな画面で表示されますpopup_icon


6 NIC 設計例

6 つ以上の NIC では、フローベース ハッシングを使用する柔軟性を提供しながら、データ トラフィックと他のトラフィック タイプの分離も維持できます。この設計では、4 NIC 設計と同じように、2 つの独立した PortChannel を vPC-HM で使用します。ここで異なるのは、最初の PortChannel が、仮想マシン データ トラフィック専用の 4 つの NIC で構成されることです。2 つめの PortChannel は、残りの 2 つの NIC で構成されます。これらは、VMware VMotion トラフィック、サービス コンソール、およびコントロールとパケットの VLAN 用に使用されます。

この設定では、発信元ベースとフローベースのいずれのハッシングも使用できます。図 7 は、フローベース ハッシングによる 6 NIC の例を示しています。PortChannel 1 は、vPC-HM であり、各アクセス スイッチに対して 2 つの NIC で構成されます。これらのアクセス スイッチは、EtherChannel で構成されます。PortChannel 1 の各サブグループは、2 つの NIC で構成されます。PortChannel 2 も vPC-HM であり、VMware VMotion、サービス コンソール、およびコントロールとパケットの VLAN に対して専用の 2 つの NIC で構成されます。

図 7 vPC-HM を使用した 2 つの PortChannel による 6 NIC

図 7 vPC-HM を使用した 2 つの PortChannel による 6 NIC
※画像をクリックすると、大きな画面で表示されますpopup_icon


4 NIC 設計の場合と同様に、6 つすべての NIC が含まれている単一の PortChannel を vPC-HM で使用することもできます。6 NIC でこの設計を実装することは、理想的とは言えません。フローベース ハッシングが選択されると、各サブグループと、各自のアクセス スイッチ上の関連する EtherChannel 内で、ハッシングされるリンクの数が奇数になる可能性があります。そのため、最適状態に及ばない負荷分散になる可能性があります。

関連情報


Cisco Nexus 1000V シリーズの詳細については、次の URL を参照してください。