Cisco Nexus 1000V スイッチ

Cisco UCS B シリーズおよび C シリーズの Cisco UCS Manager サーバ上での Cisco Nexus 1000V シリーズ スイッチの導入におけるベスト プラクティス

ホワイト ペーパー





Cisco UCS B シリーズおよび C シリーズの Cisco UCS Manager サーバ上での Cisco Nexus 1000V シリーズ スイッチの導入におけるベスト プラクティス



目次


概要
    対象読者
    用語
    推奨事項のまとめ
はじめに
Cisco Unified Computing System の共通設定
    Cisco Unified Computing System のスイッチング機能
    サービス プロファイル テンプレートとサービス プロファイル
    リンク ステータスと Cisco Discovery Protocol のネットワーク ポリシー
Cisco Nexus 1000V シリーズの共通設定
    Cisco Nexus 1000V Virtual Ethernet Module(VEM; 仮想イーサネット モジュール)の インストール
    MAC ピニング
    Cisco Nexus 1000V シリーズの冗長性メカニズム
    Cisco Nexus 1000V シリーズのロード バランシング
    ポート プロファイルによるアップリンク ポート選択の優先設定
Cisco Nexus 1000V シリーズでのデュアル 10GE アダプタ グループの使用例
    デュアル 10GE アダプタによるハイ アベイラビリティ
    サービス プロファイル テンプレートの設定
    運用
    パフォーマンスとフェールオーバー テスト
Cisco Nexus 1000V シリーズでのデュアル 10GE および 10G FCoE アダプタ グループの 使用例
    Emulex アダプタと QLogic アダプタによるハイ アベイラビリティ
    サービス プロファイル テンプレートの設定
    運用
    パフォーマンスとフェールオーバー テスト
Cisco Nexus 1000V シリーズでの Cisco UCS 仮想インターフェイス カードの使用例
    仮想インターフェイス カードによるハイ アベイラビリティ
    サービス プロファイル テンプレートの設定
    Cisco UCS M81KR VIC アダプタ上での信頼動作と非信頼動作
    運用
    パフォーマンスとフェールオーバー テスト
Cisco Unified Computing System 内での Cisco Nexus 1000V シリーズの仮想スイッチ モジュールの配置
    オプション 1:Cisco Nexus 1010 上で Cisco Unified Computing System の外部に配置された VSM
    オプション 2:Cisco Nexus 1000V シリーズ VEM 上で Cisco Unified Computing System の外部に配置された VSM
    オプション 3:VMware vSwitch 上で Cisco Unified Computing System の外部に配置された VSM
    オプション 4:VMware vSwitch 上で Cisco Unified Computing System の内部に配置された VSM
    このドキュメント内で使用されている Cisco Unified Computing System と Cisco Nexus 1000V シリーズのバージョン
まとめ
関連情報
付録 A:Cisco Unified Computing System 内での VMware ESX サーバの トラブルシューティング
    Cisco Unified Computing System 内の Cisco Nexus 1000V シリーズ スイッチの トラブルシューティングに使用する VMware ESX および ESXi のコマンド


概要


このドキュメントでは、Cisco Unified Computing System™ の上に Cisco Nexus® 1000V シリーズ スイッチ(VMware vSphere ハイパーバイザに組み込まれたソフトウェア スイッチ)を導入する際の設計ガイダンスとベスト プラクティスについて説明します。特に、Cisco Unified Computing System でサポートされる各種アダプタ タイプを使用した導入オプションに重点を置いています。Cisco Nexus 1000V シリーズの詳細な設定ドキュメントについては、Cisco® 製品と VMware 製品のそれぞれの設定ガイドを参照してください。製品設定ガイドへのリンクは、このドキュメントの「関連情報」セクションに示してあります。

対象読者

このドキュメントは、Cisco Unified Computing System 上の Cisco Nexus 1000V シリーズ スイッチを理解し、展開することに関心を持つサーバ管理者、ネットワーク管理者、およびインフラストラクチャ アーキテクトをお客様としてサポートするシスコ システム エンジニアを対象としています。VMware 環境内の Cisco Nexus 1000V シリーズ、VMware vNetwork 分散型スイッチング、およびイーサネット スイッチングの基本的な機能について全般的な知識があることを想定しています。また、Cisco UCS、サーバ I/O、仮想化、およびネットワーキングの各概念を理解していることも前提としています。

用語

このドキュメントでは、VMware ESX ハイパーバイザによって提供される仮想マシンの Network Interface Card(NIC; ネットワーク インターフェイス カード)を Virtual NIC(vNIC; 仮想 NIC)と呼びます。また、Cisco UCS Manager によって作成、管理される、サービス プロファイルが定義済みのインターフェイスを Virtual Interface(VIF; 仮想インターフェイス)と呼びます。Cisco Nexus 1000V シリーズは、IEEE 802 ワーキング グループで Virtual Ethernet Bridge(VEB; 仮想イーサネット ブリッジ)と呼ばれるものをシスコで実装したものです。

推奨事項のまとめ

このドキュメントでは、多くのお客様が UCS B シリーズと C シリーズ サーバ(UCSM によって管理された C シリーズ)上で Nexus 1000V を導入する際の技術的な推奨事項について詳細を説明します。ここでは、説明を開始する前に、要点のリストを示しておきます。

  • UCS ファブリック インターコネクトをエンド ホスト モードで設定します(デフォルト)。
  • 複製された設定を使用してサーバ プロファイルに 10GE アダプタを 2 つ設定します。
  • 作成した最初のアダプタを UCS ファブリック A に対して設定し、2 つ目のアダプタをファブリック B に対して設定します。
  • ESX ホストのサービス プロファイルに動的な vNIC ポリシーを設定しないでください。
  • 必要な VLAN をこれらのアダプタ ペア上ですべて送信し、ネイティブ管理 VLAN を定義します。
  • CDP パケットを Nexus 1000V へ送信するアダプタ ネットワーク コントロール ポリシーを UCS で設定します。
  • ホスト(Nexus 1000V)を信頼し、アダプタへ割り当てる QoS アダプタ クラスを設定します。
  • UCS サービス プロファイル内でアダプタに対してファブリック フェールオーバーを有効にしないでください。
  • UCS バージョン 1.3 以前では、Cisco UCS の MAC エージング タイマーを 14400 より大きい値に変更します。
  • スーパーバイザ機能用にスタンドアロンの Nexus 1010 アプライアンスを利用します。
  • MAC ACL を使用する必要がある場合は、後述の「Cisco Nexus 1000V シリーズの冗長性メカニズム」の説明に従ってください。
  • Nexus 1000V 上で、「channel-group auto mode on mac-pinning」を使用してアグリゲーション用のホスト VEM モジュール アダプタ ペアを設定します。
  • Nexus 1000V のコントロール トラフィック(コントロール/パケット/管理)を片方の UCS ファブリックに割り当てます。
  • Nexus 1000V のデータ トラフィック(仮想マシン ネットワーク)をピアの UCS ファブリックに割り当てます。
  • Nexus 1000V のすべてのコントロール VLAN と VM VLAN がアップストリーム スイッチから UCS に送信されるようにします。
  • Nexus 1000V のすべてのコントロール VLAN と VM VLAN が常に隣接アップストリーム スイッチ間で送信されるようにします。
  • アップストリーム スイッチ上で、UCS に向かうインターフェイスに対して「spanning-tree port type edge trunk」を設定します。

はじめに


Cisco Nexus 1000V シリーズ スイッチは、仮想マシン アクセス スイッチであり、Cisco NX-OS ソフトウェア オペレーティング システムを稼動している VMware vSphere 環境用のインテリジェントなソフトウェア スイッチの実装です。VMware ESX ハイパーバイザの内部で処理を行う Cisco Nexus 1000V シリーズは、Cisco VN-Link サーバ仮想化テクノロジーをサポートし、以下の特徴を備えています。

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

データセンターにサーバ仮想化を導入した場合、通常、仮想サーバは物理サーバとは異なる方法で管理されます。サーバ仮想化は特殊な導入として扱われるため、導入にかかる時間は長くなり、サーバ、ネットワーク、ストレージ、セキュリティの各管理者間のより緊密な連携が必要となります。Cisco Nexus 1000V シリーズを導入すると、一貫性のあるネットワーキング フィーチャ セットとインフラストラクチャを実現できます。さらに、仮想サーバは、専用の物理ネットワーク ポートに接続された物理サーバのものと同じネットワーク設定、セキュリティ ポリシー、診断ツール、および運用モデルを使用できます。サーバ管理者は、モバイル性のある仮想マシンを追跡して適切な接続を保つのに役立つ定義済みのネットワーク ポリシーを利用できます。それにより、仮想マシンの管理に集中するための貴重な時間を節約できます。この包括的な一連の機能により、サーバ仮想化の導入にかかる時間を短縮し、サーバ仮想化の利点を短期間で実現することが可能です(図 1)。

図 1 Cisco Nexus 1000V シリーズにより実現される、物理サーバの場合と同等な仮想化サーバ運用モデル

図 1 Cisco Nexus 1000V シリーズにより実現される、物理サーバの場合と同等な仮想化サーバ運用モデル
※画像をクリックすると、大きな画面で表示されますpopup_icon


Cisco Unified Computing System は、低遅延のユニファイド ネットワーク ファブリックをエンタープライズクラスの x86 サーバと統合することで、統合された 1 つの管理ドメインにすべてのリソースが属する、スケーラビリティの高い、統合型マルチシャーシ プラットフォームを実現します。単一のシステムで、40 台のシャーシ、320 台の計算ノード、数千台の仮想マシンにまで対応できます。

Cisco Unified Computing System は、より動的で俊敏性の高いデータセンターを実現できます。このデータセンターでは、サーバ ID(MAC アドレス、Worldwide Name(WWN)、ファームウェアと BIOS のリビジョン、ネットワークとストレージの接続プロファイルとポリシーなど)を動的にプロビジョニングしたり、システム内の任意の物理サーバへ移行したりすることが可能になります。Cisco Unified Computing System は、急速に変化する、今日のデータセンターのニーズに対応するために、ネットワーク リソースやストレージ リソースとのきわめて動的かつ緊密な統合を実現します。新しいコンピューティング リソースをジャストインタイム方式で導入することが可能であり、ハードウェアが到着する前に事前プロビジョニングすることもできます。従来の物理的な負荷と仮想的な負荷は、物理的な接続とは関係なく、リモート管理によって簡単にサーバ間を移動させることができます。Cisco Unified Computing System は、統合されたアーキテクチャによってアベイラビリティ、セキュリティ、俊敏性、およびパフォーマンスを向上させます(図 2)。

Cisco Unified Computing System の一部の機能は、Cisco Nexus 1000V シリーズ スイッチで提供される機能と似ていますが、対象となるアプリケーションと設計シナリオが異なっています。Cisco Unified Computing System では、物理マシンと仮想マシンに対してアダプタを直接提供できます(仮想マシン FEX テクノロジーを使用)。仮想マシンに対して提供される際は、Cisco Nexus 1000V シリーズでの利点の多くを Cisco VM-FEX テクノロジーによって再現できます。

図 2 Cisco Unified Computing System による、緊密な単一システムへのネットワーク リソース、コンピューティング リソース、および仮想化リソースの統合

図 2 Cisco Unified Computing System による、緊密な単一システムへのネットワーク リソース、コンピューティング リソース、および仮想化リソースの統合


Cisco Unified Computing System の共通設定


ここでは、Cisco Unified Computing System について、Cisco Nexus 1000V シリーズの設定と使用に深く関係する項目についていくつか説明します。ここで説明される設定は、アダプタ タイプに関係なく適用されます。

Cisco Unified Computing System のスイッチング機能

Cisco Unified Computing System では、複数のアダプタ タイプを提供します。これらは現在、機能によって 3 つのグループに分類できます。

  • デュアル 10 ギガビット イーサネット ポート アダプタ:
  • Cisco UCS 82598KR-CI Intel 82598 ベースの 10 ギガビット イーサネット アダプタ(メザニン)
  • Cisco UCS M61KR-I Intel 82599 ベースの 10 ギガビット イーサネット アダプタ(メザニン)
  • Cisco UCS M51KR-I Broadcom 57711 ベースの 10 ギガビット イーサネット アダプタ(メザニン)
  • Cisco UCS Intel-X520(PCIe)
  • Cisco UCS BCM 57711(PCIe)
  • デュアル 10 ギガビット イーサネット ポートおよびデュアル 10 ギガビット FCoE アダプタ:
  • Cisco UCS M71KR-Q QLogic 2642 ベースの 4G FCoE 統合型ネットワーク アダプタ(メザニン)
  • Cisco UCS M71KR-E Emulex LP21000 ベースの 4G FCoE CNA(メザニン)
  • Cisco UCS M72KR-Q Qlogic 8152 ベースの 10 ギガビット FCoE CNA(メザニン)
  • Cisco UCS M72KR-E Emulex OCe10102-F ベースの 10 ギガビット FCoE UCNA(メザニン)
  • Cisco UCS QLE 8152(PCIe)
  • Cisco UCS ELX OCe10102-F(PCIe)
  • ユーザ設定可能なイーサネット ポートと FCoE ポートを持つ仮想インターフェイス カード:
  • Cisco UCS M81KR 仮想インターフェイス カード(メザニン)
  • Cisco UCS P81E 仮想インターフェイス カード(PCIe)

これらのカードはそれぞれ、Cisco Unified Computing System のバックプレーンまたはファブリック インターコネクトに対する 10 ギガビット イーサネット接続のペアを装備しています。この接続ペアは IEEE 802.1 の Data Center Bridging(DCB; データセンター ブリッジング)機能をサポートしており、これらのアダプタ内での I/O 統合を強化しています。各メザニン アダプタ タイプでは、これらのバックプレーン ポートの片方が 10GBASE-KR 経由で A 側の I/O モジュールに接続され、さらに A 側のファブリック インターコネクトへと接続されます。10GBASE-KR とは、ミッドプレーンを介してアダプタのインターフェイス接続と要素のスイッチングを行うための銅線ミッドプレーン テクノロジーです。もう片方のメザニン接続は、10GBASE-KR 経由で B 側の I/O モジュールに接続され、さらに B 側のファブリック インターコネクトへと接続されます。この接続については、後に示す図 3 を参照してください。C シリーズの UCSM 統合型サーバの場合、片方のポートが A 側のファブリック インターコネクトに直接接続され、もう片方のポートは B 側のファブリック インターコネクトに接続されます。

Cisco UCS M71KR-E、M71KR-Q、M81KR、および P81E アダプタ タイプ内では、Cisco Unified Computing System により、ファブリック フェールオーバー機能を有効にできます。この機能を有効にすると、使用中のパス上で接続が失われたとき、Cisco Unified Computing System 内の冗長パスを通るようにトラフィックがリマッピングされます。Cisco Nexus 1000V シリーズをサポートするために使用するアダプタ タイプを決定する際、VMware ESX ホストに対して使用可能なインターフェイスの数は重要な要因となります。ここでは、高いレベルでのトレードオフをいくつか紹介します。

Cisco UCS M81KR および P81E では、必要に応じて、サービス コンソール VLAN、VMware VMkernel VLAN、仮想マシン データ VLAN、Cisco Nexus 1000V シリーズ VLAN などで使用される VIF と一致するように、複数の VIF を識別できます。これらのアダプタは、それぞれ個別のファブリック インターコネクトに接続されるように Cisco Unified Computing System 内で定義できます。また必要ならば、他方へのフェールオーバーも有効にできます。設定されたアダプタは、接続先の UCS ファブリックとともに、提供された順序で ESX または ESXi に割り当てできます。

Cisco UCS M71KR-E および M71KR-Q アダプタでは、最大で 2 つのアダプタが、ブレード上で稼動している VMware ESX ハイパーバイザに提供されます。これらのアダプタは、それぞれ個別のファブリック インターコネクトに接続されるように Cisco Unified Computing System 内で定義できます。また必要ならば、他方へのフェールオーバーも有効にできます。このファブリック フェールオーバーにより、仮想マシン データが Cisco Unified Computing System 内で片方のパスをデフォルトで使用できるモデルが実現可能になります。その他のすべての接続は、もう片方のパス上で行うことができます。後述の理由から、Nexus 1000V を使用する際に、この機能を使用することは推奨されません。これらのアダプタでは、ESX または ESXi に最初に提供されたアダプタが常に A 側の UCS ファブリックとなり、2 番目に提供されアダプタは B 側の UCS ファブリックとなります。

Cisco UCS 82598KR-CI、M51KR-I、M61KR-I、M72KR-Q、M72KR-E、Intel-X520、BCM 57711、QLE 8152、および ELX OCe10102-F アダプタでは、最大で 2 つのアダプタが、ブレード上で稼動している VMware ESX ハイパーバイザに提供されます。これらのインターフェイスでは、ファブリック フェールオーバーはサポートされていません。そのため、ハイアベイラビリティの要件が存在する場合は、サービス コンソールをこれらすべてのアダプタ タイプとともに Cisco Nexus 1000V シリーズ スイッチに移行する必要があります。ブレード上の VMware ESX の導入時に実際にこのインターフェイスを移行する方法については、このドキュメント内に後述されている個別のアダプタ セクションで説明しています。ユーザのサービス コンソールの移行方法の詳細については、Cisco Nexus 1000V シリーズのドキュメントを参照してください。これらのアダプタでは、ESX または ESXi に最初に提供されたアダプタが常に A 側の UCS ファブリックとなり、2 番目に提供されアダプタは B 側の UCS ファブリックとなります。

注: ユーザは、管理 VLAN、コントロール VLAN、およびパケット VLAN とともに、Cisco Nexus 1000V シリーズ スイッチ内の VMware サービス コンソール VLAN および VMkernel インターフェイス VLAN をシステム VLAN として割り当てる必要があります。

Cisco UCS 6100 シリーズ ファブリック インターコネクト内では、それらに接続したサーバ アダプタ間でローカルなレイヤ 2 スイッチングが実行されます。その他の通信を必要とするトラフィックは、アップリンクにあるデータセンター スイッチに送信されます。こうしたトラフィックの例には、外部ネットワーク、他の Cisco Unified Computing System インスタンス、他の VMware ノードなどへのレイヤ 3 通信があります。また、Cisco Unified Computing System 内に A 側でアクティブなサーバと B 側でアクティブなサーバが存在する場合のトラフィックもその一例です(A と B の間のデータ通信パスはアップストリーム スイッチを経由します)。管理者は、所定のサーバ アダプタまたは VIF が、トラフィック フローを制御するアップリンク ポイントとしてどのアップリンクまたはアップリンク チャネルを使用するかを定義できます。

Cisco UCS 6100 シリーズは、Cisco Unified Computing System 内のフローに関して 2 つの独立したモードで動作します。2 つのうち、一方はエンドホスト モードと呼ばれ、一般的です。もう一方はスイッチド モードと呼ばれます。スイッチド モードでは、ファブリック インターコネクトが通常のイーサネット ブリッジ デバイスとして動作します。このドキュメントでは、これらのモードの違いについては説明しません。なお、サーバ ブレード上の Cisco Nexus 1000V シリーズ スイッチは、ファブリック インターコネクトのモードとは無関係に動作します。VMware 環境で Cisco Nexus 1000V シリーズを稼動する場合は、トラフィック フローを予測可能にするのに役立つエンドホスト モードが推奨されます。

エンドホスト モード構成

エンドホスト モード構成(図 3)では、Cisco Nexus 1000V シリーズ インフラストラクチャ内でレイヤ 2 通信フローが発生すると、これらのフローは Cisco UCS 6100 シリーズ ファブリック インターコネクトに対してローカルになるか、アップストリーム データセンター スイッチを経由してさらにホップします。ここに Quality-of-Service(QoS)ポリシーを適用して、帯域幅を最小限に抑えられるようにすることが推奨されます。Cisco Nexus 1000V シリーズで推奨されるアクションは、6 の Class of Service(CoS; サービス クラス)を VMware サービス コンソール フローと VMkernel フローに割り当てることと、Cisco UCS 6100 シリーズ ファブリック インターコネクトの接続先のデータセンター スイッチ上でこれらの QoS マーキングを有効にすることです。QoS 値のマーキングは、あらゆるケースにおいて Cisco Nexus 1000V シリーズ スイッチ上で実行することも、Cisco Nexus 1000V シリーズ スイッチの有無に関係なく Cisco Unified Computing System 内の Cisco UCS M81KR または P81E 上において VIF 単位で実行することもできます。

図 3 Cisco Unified Computing System によるエンドホスト モード構成

図 3 Cisco Unified Computing System によるエンドホスト モード構成


このシナリオでは、Cisco UCS 6100 シリーズ ファブリック インターコネクトを冗長リンクでデータセンター デバイスのペアに接続することも推奨されます。データセンター デバイスのペアは、それぞれ独立したスイッチとするか、Cisco Virtual Switching System(VSS; 仮想スイッチング システム)または Cisco Virtual PortChannel(vPC; 仮想ポート チャネル)などの Multichassis EtherChannel(MCEC)を実現する何らかの方法によって結合します。比較のために、アップリンク スイッチ上の vPC 内の別のメンバーにハッシングする代わりに、アップリンク ポートへのトラフィックの再ピニングに頼った場合のトレードオフを後述のテスト結果セクションで示します。こうしたデータセンター エッジへの冗長アップリンクを使用した場合、Cisco Nexus 1000V シリーズ スイッチは、リンク障害の表示を受け取ると、トラフィックを自分自身にフェールオーバーします。システム アップリンク上で静的なピン グループを作成しないでください。そうすることで、デフォルトで Cisco UCS 6100 シリーズ ファブリック インターコネクトがトラフィックをアップリンクへ動的にピニングします。繰り返しになりますが、この構成は、Cisco Nexus 1000V シリーズ スイッチに対する要件を緩和し、アベイラビリティを向上させます。

エンドホスト モードを使用する際に留意すべきもう 1 つの重要な点として、各ファブリック インターコネクト上でブロードキャスト トラフィックとマルチキャスト トラフィックのリスニング ポートとして単一のポートが選択されるということがあります。したがって、すべてのアップリンク ポートが同じレイヤ 2 ドメインに接続されるようにします。同一のレイヤ 2 ドメインに接続されない場合は、ファブリック インターコネクト上でスイッチ モード動作が必要になります。

エンドホスト モードを使用する場合は、Cisco Unified Computing System が、アップリンク セグメントからの未知のユニキャスト トラフィックをリスニングしないということも覚えておく必要があります。Cisco Unified Computing System は、通常のデータ スイッチング ルールに従って、デフォルトの MAC アドレス エージング タイマー設定(バージョン 1.3 より前は 7200 秒、バージョン 1.3 以降は 14500 秒)を使用します。この時間が経過すると、ダイナミック MAC アドレス エントリはフラッシュされます。一方、アップストリーム デバイスにはまだ Address Resolution Protocol(ARP; アドレス解決プロトコル)エントリが残っている可能性があります。これらのデバイスはデフォルトで 14400 秒間キャッシュを保持できます(多くのシスコ製品での一般的な設定)。ここでは、バージョン 1.3 よりも前の UCS ソフトウェアを使用する場合は、図 4 に示すように、Cisco Unified Computing System の MAC アドレス エージング タイマーを変更することを推奨します。

図 4 ファブリック インターコネクト上で動的に学習された MAC アドレス エントリに対する MAC アドレス エージング タイマーの設定

図 4 ファブリック インターコネクト上で動的に学習された MAC アドレス エントリに対する MAC アドレス エージング タイマーの設定


また、お客様がアグリゲーション レイヤ内の同一ラインカード上の A 側から B 側への Cisco UCS 6100 シリーズ ファブリック インターコネクト リンクを統合することも推奨されます。この処置により、フローがファブリックを通過する必要がなくなるため、ユーザはそのデバイス上でのローカル スイッチングのパフォーマンスを活用して規模を拡大できるようになります。なお、チャネル バンドリングは Link Aggregation Control Protocol(LACP)によって実行され、Cisco UCS 6100 シリーズ ファブリック インターコネクトは LACP アクティブ モードで稼動しているようにネットワークから見えます。

さらに、Cisco Nexus 1000V シリーズには、管理 VLAN とデータ VLAN、およびコントロール VLAN とパケット VLAN という名前の特別な一組の VLAN が存在します。これらの VLAN すべてが、Cisco UCS 6100 シリーズ ファブリック インターコネクトの接続先となるデータセンター アグリゲーション スイッチ(Cisco Unified Computing System 外の関心のあるすべての他のホストも含む)間で使用できなければなりません。

スイッチ モード構成

スイッチ モード(図 5)を使用する場合、Cisco Nexus 1000V シリーズ インフラストラクチャ内のレイヤ 2 通信フローは、Cisco UCS 6100 シリーズ ファブリック インターコネクトに対してローカルにすることも、Cisco Unified Computing System 内のアップリンク経由にすることもできます。以下の理由から、この設計を使用することは推奨されません。

  • Virtual Switching System(VSS; 仮想スイッチング システム)設計または Virtual Port Channel(vPC)設計を使用すると、すべてのパスで Cisco UCS 6100 シリーズ ファブリック インターコネクトから転送することになります。
  • VSS や vPC を使用しないアグリゲーション スイッチ間にレイヤ 2 リンクが存在すると、ファブリック インターコネクトとアップストリーム デバイスの間にスパニングツリー ブロックが形成されます。
  • UCS 内でトラフィック エンジニアリング機能を活用するには、スパニング ツリーで転送パスを決定する必要があります。
  • レイヤ 2 ドメイン内のすべての MAC アドレスが UCS ファブリック インターコネクトのメモリ内に保存されるようになるため、レイヤ 2 ドメイン サイジング問題が発生します(エンド ホスト モードでは、登録済みの学習されたダウンストリーム MAC アドレスしか保存されません)。
  • 決定論的なトラフィック フェールオーバーおよびフェールバックの実現が困難になる可能性があります。
図 5 Cisco Unified Computing System によるスイッチ モード構成

図 5 Cisco Unified Computing System によるスイッチ モード構成


サーバからデフォルト ゲートウェイを検出するために、First-Hop Routing Protocol(FHRP)が使用されます。スイッチ モードでは、サーバからの物理ホップ数は 1 または 2 になります。

スイッチ モードにはここで指摘した制限があるため、UCS 上に Nexus 1000V を実装する際のベスト プラクティスとしてエンドホスト動作モードが一般に推奨されます。ただし、別々のレイヤ 2 ドメインが 1 つの UCS を共有する場合は除きます。

サービス プロファイル テンプレートとサービス プロファイル

Cisco Nexus 1000V シリーズの場合、Cisco UCS Manager 内でのサービス プロファイル テンプレートとサービス プロファイルの定義には、いくつかの一般的なベスト プラクティスが存在します。サービス プロファイル内で定義され使用されるアダプタは、それらの割り当て先ファブリックの空き状態に応じて使用可能になります。VMware ESX ハイパーバイザが利用できる定義は、サービス プロファイル内でアダプタが定義されている順序(どのアダプタがインターフェイス 0 やインターフェイス 1 であるか)に依存します。一般に、Cisco Unified Computing System の管理者が実行するアダプタ作成機能と VMware ESX ハイパーバイザのネットワーク割り当てとの間の対応関係を与えることが目的となります。この機能は、物理サーバにおいて、サーバ上の各 RJ-45 ポートがどのネットワークに接続しているかを決定し、サーバ上の対応するアダプタを識別する機能に似ています。したがって、サーバ PCI バス上でアダプタと VIF が異なる順序で割り当てられることがないように、共通のテンプレートからすべてのサービス プロファイルを呼び出すことがベスト プラクティスとして推奨されます。このプラクティスは、Cisco UCS M81KR と P81E の場合に特に重要です(これらをサービス プロファイル内で設定できる場合)。その他のアダプタ タイプでは、A 側のアダプタが、ESX または ESXi で検出される最初のアダプタになります。

管理者は、これと同じ方法で、共通のサーバに対して共通のアダプタ ファームウェアのベースラインを QoS、VLAN などの設定とともに維持できます。

リンク ステータスと Cisco Discovery Protocol のネットワーク ポリシー

Cisco Unified Computing System 内では、Cisco Unified Computing System からカスタマー データセンター ネットワークへのアップリンクを個別リンク、複数リンク、またはポート チャネルにすることができます。アップストリーム ネットワークへの個別リンクまたはリンクのグループやチャネルの最後に残ったメンバーで接続が失われたとき、この障害を知らせる信号がブレードおよびその上で稼動している Cisco Nexus 1000V シリーズの Virtual Ethernet Module(VEM; 仮想イーサネット モジュール)へ送信されるようにすることが推奨されます。この処置は、Cisco Unified Computing System ファブリックで(物理アダプタと仮想化されたアダプタのいずれであるかに関係なく)該当するアダプタへのリンクをダウンさせることにより実現できます。その後、まだ残っている正常なアダプタ上で接続を再確立するように、VEM 上のスイッチング ロジックが適用されます。

別の管理機能として、これらの物理アダプタや仮想アダプタ上で Cisco Discovery Protocol を有効にして、接続問題のトラブルシューティングに役立てることもできます。図 6 に、このポリシーを Cisco UCS Manager で設定する方法を示します。設定後、管理者は、このネットワーク コントロール ポリシーを、サービス プロファイルでアダプタを定義するときにアダプタへ割り当てることができます。なお、このネットワーク コントロール ポリシーに従ってアダプタを使用する Cisco Nexus 1000V シリーズ スイッチ(および仮想スイッチ)に対しては、常に MAC セキュリティ機能を「allow」に設定する必要があります。

図 6 Cisco Discovery Protocol 機能とアップリンク障害アクションに関するネットワーク コントロール ポリシーの設定

図 6 Cisco Discovery Protocol 機能とアップリンク障害アクションに関するネットワーク コントロール ポリシーの設定


Cisco Nexus 1000V シリーズの共通設定


ここでは、Cisco Nexus 1000V シリーズについて、Cisco Unified Computing System 内での使用に深く関係する項目についていくつか説明します。

Cisco Nexus 1000V Virtual Ethernet Module(VEM; 仮想イーサネット モジュール)のインストール

Nexus 1000V の導入に ESX ホストを追加する場合、基本作業として、選択した UCS ブレード上への VEM のインストールが含まれます。この作業は繰り返し行うことができます。そのため、繰り返しによる誤りが発生する可能性があります。お客様は VSM または http://www.cisco.com/web/JP/index.html から VEM ファイルを手動でホストにダウンロードし、「esxupdate …」コマンドを実行して VEM を手動でインストールできますが、その場合にはお客様が ESX バージョンとの互換性を確認する必要があります。

VMware は、所定のホストに正しい VEM モジュールをインストールし、正しいバージョニングを保証するこのようなプロセスを自動化できる VMware Update Manager(VUM)と呼ばれるサービスを提供しています。VUM を使用することにより、Nexus 1000V に新しいホストを追加する管理作業は、追加するホストを指定するという 1 回の操作ですむようになります。VUM は、ステージング(ホスト上にファイルを配置する)操作と修復(モジュールをインストールし、有効にする)操作を実行します。この場合、ユーザが追加の作業をしなくても、これらの UCS サーバは vCenter クラスタになります。このドキュメントでは VUM を設定する手順について説明しませんが、vCenter の [Update Manager] タブで次の作業を実行することが重要であることを記しておきます。

  • VUM の設定タブの選択
  • パッチ ダウンロード設定
  • パッチ ソースの追加
  • [Custom Patch Type] で次を入力:

http://hostupdate.vmware.com/software/VUM/PRODUCTION/csco-main-index.xml

MAC ピニング

Cisco NX-OS ソフトウェア リリース 4.1(2) 以降を実行している Cisco Nexus 1000V シリーズでは、Port Aggregation Protocol(PaGP; ポート集約プロトコル)や LACP などの双方向リンク集約プロトコルを実行しなくても、複数のアップリンク ポートを集約できます。この機能は、MAC ピニングと呼ばれ、Cisco Nexus 1000V シリーズ スイッチを Cisco Unified Computing System 上で稼動する場合はすべてのアダプタ タイプで使用することが推奨されます。設定については、このドキュメント内の各アダプタ グループのセクション内で説明します。

一般論として、Cisco Nexus 1000V シリーズの VEM は、正しい VLAN を通過させるアップリンク インターフェイスのグループにトラフィックを割り当てます。また、与えられた仮想マシンの vNIC をアップリンクのうちの 1 つに vNIC 単位で割り当てます。アップストリーム スイッチ(この場合、Cisco UCS 6100 シリーズ ファブリック インターコネクト)は、Cisco Nexus 1000V シリーズ スイッチ上の設定を認識せず、適切なブレード上の適切な MAC アドレスのみを検出します。リンクに障害が発生すると、トラフィックは、残りの正常なリンクにフェールオーバーしてこの停止の影響を軽減します。リンクの回復後、トラフィックは(安定性を確保するための適切な時間が経過した後に)元のリンクに戻ります。

Cisco Nexus 1000V シリーズの冗長性メカニズム

物理リンクに障害が発生すると、Cisco Nexus 1000V シリーズ スイッチは、残りの正常なリンクのアップストリームにパケットを送信して、これらの仮想マシンに到達するための新しいパスをアップストリーム スイッチに通知します。これらの通知は、Cisco UCS 6100 シリーズ ファブリック インターコネクトに送信されます。Cisco UCS 6100 シリーズ ファブリック インターコネクトは、自身の MAC アドレス テーブルを更新し、アップリンク ポート上で gratuitous ARP メッセージを送信します。それにより、データセンター ネットワークは新しいパスを認識できるようになります。お客様が MAC アドレス アクセス コントロール リスト(ACL)を実装して仮想マシンから単一デバイス(一般にデフォルト ゲートウェイ)に向かうレイヤ 2 トラフィックを制限する場合は、Cisco Nexus 1000V シリーズ スイッチからアップストリームの Cisco Unified Computing System に向かうパケットが適切にフェールオーバーできるように ACL を設定する必要があります。次の ACL では、ゲートウェイ エントリと、その後に続く Cisco Nexus 1000V シリーズの MAC アドレス通知パケット用エントリの例を示しています。

mac access-list JustExternalGateway
  10 permit any 0022.1991.7e08 0000.0000.0000
  20 permit any 0100.0ccd.cdcd 0000.0000.0000
  30 deny any any

Cisco Nexus 1000V シリーズのロード バランシング

Cisco Unified Computing System 内のトラフィック転送の基本的な特徴は、Cisco Unified Computing System 内のホスト(物理または仮想)の各インターフェイス上のトラフィックが 2 つの使用可能なファブリックのうち 1 つを通過し、障害発生時にはもう一方のファブリックへフェールオーバーできることです。Cisco Nexus 1000V シリーズは、ホストからネットワークへ向かうトラフィックに対して多数のきめ細かいロードバランシング メカニズムをサポートしていますが、Cisco Unified Computing System は、ポート ID と送信元 MAC アドレスのメカニズムのみをサポートしています。

ポート プロファイルによるアップリンク ポート選択の優先設定

Cisco Nexus 1000V シリーズのポート プロファイルでは、優先して使用するアップリンク パスを管理者が設定できます。設定したアップリンクに障害が発生すると、別のアップリンクが選択されます。この選択メカニズムでは、Virtual Ethernet(vEthernet; 仮想イーサネット)ポート プロファイル内にピニング ID を定義します。これは、VMware ESX サーバによって報告される Virtual Machine NIC(VMNIC; 仮想マシン NIC)を表します(vmnic0=0、vmnic1=1 など)。またユーザは、パケット VLAN とコントロール VLAN に使用するアップリンクも定義できます。このために、イーサネット ポート プロファイル(物理アップリンク アダプタ用のプロファイル)の下でピニング コントロール VLAN 番号とピニング パケット VLAN 番号を定義します。これらによって、複数のリンクが動作可能なときに優先されるリンクが決定されます。アクティブ リンク上でリンク障害が発生すると、Cisco Nexus 1000V シリーズ スイッチは、トラフィックを残りの正常なリンクへ移動します。この動作では、リンク ダウン通知ポリシーが使用されるようになっていることが必要です。つまり、フェールオーバーを実施できるように、Cisco Nexus 1000V シリーズ VEM にリンクの停止が通知されなければなりません。

ここでの重要な利点は、実稼動仮想マシン トラフィックを、アクセス、レポート、VMware vMotion 移行、バックアップなどの一部の管理動作から分離できることです。

Cisco Nexus 1000V シリーズでのデュアル 10GE アダプタ グループの使用例


デュアル 10GE アダプタによるハイ アベイラビリティ

デュアル 10GE アダプタでは、UCS 内の I/O モジュールに対して従来のイーサネット接続か VNTag 接続が実行されます。アダプタまたは I/O モジュールにおいて、システム QoS ポリシーが実施され、Virtual Network Tag(VNTag)フィールドが追加されます。このアダプタ タイプ上でネイティブに実行されるシスコのマイクロコードはありません。したがって、このアダプタにはファブリック フェールオーバー機能がなく、この使用例は、単体使用のシナリオになります(一組の vNIC で構成され、それぞれ A 側と B 側のファブリック インターコネクトに接続)。最初に検出されたアダプタ(ESX と ESXi では vmnic0)が A 側になり、その次に検出されたアダプタ(vmnic1)が B 側になります。もう 1 つ重要な点として、Cisco Unified Computing System から見て Fiber Channel over Ethernet(FCoE)がサポートされていないということがあります(ソフトウェア FCoE は OS レベル)。そのため、利用できる SAN ブート機能がありません。したがって、システムはローカル ディスクに頼る必要があります。このことは、お客様が物理ディスクをサービス プロファイルとともに移動できたとしても、Cisco Unified Computing System 内でのステートレスな使用例に影響を及ぼします。

Cisco Nexus 1000V シリーズ スイッチがこれらのアダプタに関する管理接続ビューを提供するために Cisco Discovery Protocol パケットを受信する場合は、Cisco UCS サービス プロファイル内の設定において、アダプタのペアが Cisco Discovery Protocol 情報を受信するようにネットワーク ポリシーで設定する必要があります。

VMware ESX ホスト内で仮想マシンのハイ アベイラビリティの目標を達成するために、Cisco Nexus 1000V シリーズ スイッチ上でアップリンク MAC ピニングを使用することが推奨されます。イーサネット タイプ(アップリンク)ポート プロファイル上で MAC ピニングを設定するには、管理者が Cisco Nexus 1000V シリーズのイーサネット ポート プロファイルに次のように入力する必要があります。

port-profile type ethernet Intel82599-uplink
  …
  channel-group auto mode on mac-pinning
  …

Cisco UCS アダプタに割り当てられる Cisco Nexus 1000V シリーズ アップリンク ポート プロファイルには説明的な名前を付けることが推奨されます。管理者が Cisco Nexus 1000V シリーズのイーサネット ポートを適切なアップリンク ポート グループにマッピングする際に、VMware vCenter でそれらの名前が表示されます。ここでは、Cisco Nexus 1000V シリーズの設定のうち重要な部分について示します。ここで使用された VLAN マッピングは次のとおりです。

  • VLAN 2:管理とコンソール
  • VLAN 3:VMware vMotion
  • VLAN 4:Cisco Nexus 1000V シリーズのコントロール VLAN
  • VLAN 5:Cisco Nexus 1000V シリーズのパケット VLAN
  • VLAN 6:仮想マシン データ ネットワーク 1

これらのマッピングは、このドキュメント全体を通して使用されます。重要な要件として、これらすべての VLAN が、Cisco UCS 6100 ファブリック インターコネクトからカスタマー データセンター内のアップストリーム スイッチまでの間で使用できるようにする必要があります(UCS から見てすべての VLAN がすべてのアップリンク上で使用できます)。多くの場合、これらの VLAN を使用するインターフェイスは、Cisco Unified Computing System 内で A 側か B 側のファブリック上に存在します。エンドホスト モードの場合、それらのファブリック間で通信するためのパスは、データセンター内のアクセス レイヤまたはアグリゲーション レイヤを経由します。前述の最初の 4 つの VLAN(管理、vMotion、N1k コントロール、および N1k パケット)は、アップリンク ポート プロファイル内でシステム VLAN として定義される必要があります。Cisco Nexus 1000V シリーズの設定のなかで関連する部分を次に示します。

<config-snippet>
port-profile type ethernet Intel82599-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 1-6
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 2-5
  state enabled

interface Ethernet3/1
  inherit port-profile Intel82599-uplink

interface Ethernet3/2
  inherit port-profile Intel82599-uplink
</config-snippet>

サービス プロファイル テンプレートの設定

Cisco Nexus 1000V シリーズ システムに含める VMware ESX インスタンスをホストするための Cisco デュアル ポート 10 GE アダプタ ベースのサービス プロファイルを作成する場合は、次のルールに従います。

ネットワーク管理者は、最初からそのアダプタ経由で Cisco Nexus 1000V シリーズ VEM に渡される VLAN を定義する必要があります。

ネットワーク管理者は、VMware ESX ホストに関する管理接続ビューが必要な場合は、Cisco Discovery Protocol 用のアダプタ ポリシーを設定する必要があります。

ネットワーク管理者は、Cisco Nexus 1000V シリーズ スイッチがマーキングしないトラフィックに対してデフォルトの QoS プロファイルを定義する必要があります。

図 7 に、サービス プロファイルの例を、関係するサービス プロファイル ネットワーキング設定とともに示します。

図 7 Cisco UCS デュアル 10GE アダプタ サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義

図 7 Cisco UCS デュアル 10GE アダプタ サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義
※画像をクリックすると、大きな画面で表示されますpopup_icon


運用

前述したように、設計にはトレードオフがあります。このデュアル ポート 10GE のグループ化では複数のアダプタをホストにマッピングすることはできないので、円滑な運用を実現するために、Cisco Nexus 1000V シリーズ スイッチの QoS 設定を利用する必要があります。このソリューションにより、ユーザは、ファブリックへのコンソール インターフェイス、カーネル インターフェイス、実稼動インターフェイスなどに対してプライマリ パスとバックアップ パスを定義できるようになります。この定義は、次のコードで優先インターフェイスを割り当てることにより行われます。

port-profile type vethernet vMotionNet
  …  
  pinning id 0
  …  

前述したように、ピニング ID のマッピングにより、各プロファイルで使用されるデータセンター ネットワークへのパスを制御できます。この例では、VMware vMotion トラフィックがアップリンクとして vmnic0 を使用する設計になっています。選択した vmnic が使用不可能な状態の場合、または適切なネットワークを伝送していない場合、プロファイルの要件を満たすことのできる別の vmnic が選択されます。

このグループ化内で、Cisco UCS 82598/82599 アダプタ タイプは、アダプタから仮想マシンにパケットをスイッチする CPU 処理を支援するため、および複数の送信キューを定義してデータ送信時のヘッドオブライン ブロッキングを低減するため、インテル Virtual Machine Device Queue(VMDq; バーチャル マシン デバイス キュー)テクノロジーを使用します。このドキュメントでは、これらの詳細について説明しません。詳細については、http://www.intel.com/network/connectivity/vtc_vmdq.htm [英語] にあるインテルのドキュメントを参照してください。

パフォーマンスとフェールオーバー テスト

基本的なパフォーマンス データと予測可能なフェールオーバー時間を確認するために、Cisco Nexus 1000V シリーズ スイッチの背後で稼動している仮想マシンから Cisco Unified Computing System の外部にあるホストに対して iPerf テストを実施しました。図 8 に、デュアル アダプタの使用例でのテスト トポロジを示します。

図 8 Cisco UCS デュアル 10GE メザニン上での Cisco Nexus 1000V シリーズ スイッチ

図 8 Cisco UCS デュアル 10GE メザニン上での Cisco Nexus 1000V シリーズ スイッチ
※画像をクリックすると、大きな画面で表示されますpopup_icon


図 8 には示されていませんが、ギガビット イーサネットで Cisco Nexus 5010 スイッチ A に接続されたトラフィック ターゲット サーバが存在します。

  • ベースラインの測定結果:
    • 一連の 90 秒間 iPerf フロー テストを実施しました。
    • 外部の単一ギガビット イーサネット ホストに対して、Cisco Unified Computing System 内の Cisco Nexus 1000V シリーズ VEM の背後にある単一仮想マシン上での双方向スループットは、490 Mbps でした。
    • すべての MAC アドレスを Cisco Nexus 1000V シリーズ スイッチ、Cisco Nexus 5010 スイッチ、および Cisco UCS 6120XP 20 ポート ファブリック インターコネクト上で確認できました。
    • B ファブリック側が、デフォルトでトラフィックをアクティブに転送していました。これにより、1 のピニング ID(または vmnic1、B ファブリック アダプタ)が確認されます。
    • Cisco UCS ブレード上の 3 つのスレッドが(スレッドは E5520 CPU のペア内に全部で 16 個存在)、テスト期間中に使用率を 30 パーセント付近に維持していました。
  • Cisco UCS 6120XP B から Cisco Nexus 5010 A へのリンク障害に関する測定結果(フローのアクティブなパス:Cisco Unified Computing System による別のアップリンクへの再ピニングが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • 障害発生時、MAC アドレスはまだ B ファブリックに残っていました。
    • このフローに対する Cisco Unified Computing System の再ピニング時間は 1.1 秒でした。
    • Cisco Nexus 1000V シリーズ スイッチは、リンクの停止を検出しませんでした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、再ピニング時間は 2.2 秒で測定されました。
    • Cisco Nexus 5010 スイッチを vPC 内で設定した場合、このリンク障害が発生したとき、ポート チャネルが残りの正常なメンバーをフローに対して選択しました(Cisco Unified Computing System による再ピニングは実施されませんでした)。このシナリオでのフェールオーバー時間は 0.09 秒、フェールバック時間は 0.03 秒でした。
  • Cisco 6120XP B から Cisco Nexus 5010 B へのリンク障害に関する測定結果(フローの現在のアクティブなパス:Cisco Nexus 1000V シリーズ スイッチによる VMNIC のフェールオーバーが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • フェールオーバー発生時、MAC アドレスは A ファブリック上に存在しました。
    • このフローのフェールオーバー時間は 2.5 秒でした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、フェールオーバー時間は 2.5 秒でした。
    • リンク回復時(テスト ベッドの復元)、Cisco Nexus 1000V シリーズ スイッチは、0.15 秒未満の時間でトラフィックを(ピニング ID のセットアップによる)優先ファブリックに戻しました。
    • 2 つ目のアップリンクが回復すると、Cisco Unified Computing System が元のパスへの再ピニングを実行しました。これには 1.03 秒の時間がかかりました。
    • Cisco Nexus 1000V シリーズの MAC ピニングにより、ハイ アベイラビリティが実現されました。

Cisco Nexus 1000V シリーズでのデュアル 10GE および 10G FCoE アダプタ グループの使用例


Emulex アダプタと QLogic アダプタによるハイ アベイラビリティ

Cisco Unified Computing System におけるハイ アベイラビリティの観点から言えば、Cisco UCS M71KR-E アダプタと M71KR-Q アダプタの間に違いはありません。また同様に、M72KR-E アダプタと M72KR-Q アダプタの間にも違いはありません。これらのアダプタの前者のペアは、Cisco Unified Computing System 内において、現在入手可能な PCI Express(PCIe)フォームファクタのカードとは異なる動作をします。Cisco UCS M71KR-E アダプタと M71KR-Q アダプタ(シスコの Application-Specific Integrated Circuit(ASIC; 特定用途向け集積回路)上に搭載)は、シスコによってメンテナンスされるファームウェアを実行します。それに対して、Emulex と QLogic を構成する初期バージョンの PCIe カードは、シスコ ファームウェアを自己メンテナンスします。そのため、いくつかの機能に違いがあります。

  • IEEE 802.1 データセンター ブリッジング モード
  • アダプタのフェールオーバー オプション

Cisco Unified Computing System 内の Cisco UCS M71KR-E アダプタと M71KR-Q アダプタは、Cisco UCS 6100 シリーズ ファブリック インターコネクトに対して、PCIe アダプタ上で I/O Consolidation(IOC; I/O 統合)と呼ばれるモードではなく、VNTag ベースの通信フローを実行します。この VNTag モードでは、追加のファブリック フェールオーバーモードが有効になります(このモードでは、アダプタが両方の Cisco UCS 6100 シリーズ ファブリック インターコネクトに登録されます)。一方のパスがアクティブパスとして使用され、もう一方のパスがバックアップ パスとして使用されます。

注: このドキュメントでは、VNTag の詳細について説明しません。このテクノロジーに関する詳細については、他のドキュメントを参照してください。

シスコのファームウェアは、M71KR-Q アダプタと M71KR-E アダプタの上で実行されますが、M72KR-Q アダプタと M72KR-E アダプタの上では実行されません。アダプタは、サーバ起動時にファブリック インターコネクトへの登録プロセスを実行します。このアダプタ タイプはそれぞれが通信エンドポイントとなります。また、VNTag メカニズムによってアダプタが一意に識別されるので、登録プロセスでは、Cisco Unified Computing System サービス プロファイルに定義されているとおりにアダプタの MAC アドレスが登録されます。これらのアダプタの背後にある送信元 MAC アドレスを持つ送信元トラフィックがファブリック インターコネクト上で検出されると(Cisco Nexus 1000V シリーズ VEM が VMware ESX サーバ上で稼動している場合など)、アクティブ リンクのファブリック インターコネクト上の MAC アドレス テーブルが動的に更新されます。この情報は、バックアップ ファブリック インターコネクトに複製されます。しかし、このドキュメントでは、このファブリック フェールオーバーを UCS 上で無効にすることを推奨します。

Cisco Nexus 1000V シリーズ スイッチがこのアダプタに関する管理接続ビューを表示するために Cisco Discovery Protocol パケットを受信する場合は、Cisco UCS デュアル 10GE およびデュアル 10G FCoE のサービス プロファイルの設定において、アダプタのペアが Cisco Discovery Protocol 情報を受信するようにネットワーク ポリシーで設定する必要があります。

このタイプのアダプタを使用した VMware ESX ホスト上で仮想マシンのハイ アベイラビリティの目標を達成するために、Cisco Nexus 1000V シリーズ スイッチ上でアップリンク MAC ピニングを使用することが推奨されます。イーサネット タイプ(アップリンク)ポート プロファイル上で MAC ピニングを設定するには、管理者が Cisco Nexus 1000V シリーズのイーサネット ポート プロファイルに次のように入力する必要があります。

port-profile type ethernet Qlogic-no-ha-uplink
    …
  channel-group auto mode on mac-pinning
  …

Cisco UCS サーバ アダプタに割り当てられる Cisco Nexus 1000V シリーズ アップリンク ポート プロファイルには説明的な名前を付けることが推奨されます。管理者が Cisco Nexus 1000V シリーズのイーサネット ポートを適切なアップリンク ポート グループにマッピングする際に、VMware vCenter でそれらの名前が表示されます。

Cisco Nexus 1000V シリーズの設定のなかで関連する部分を次に示します。

<config-snippet>
port-profile type ethernet Qlogic-no-ha-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 1-6
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 2-5
  state enabled

interface Ethernet5/1
  inherit port-profile Qlogic-no-ha-uplink

interface Ethernet5/2
  inherit port-profile Qlogic-no-ha-uplink
</config-snippet>

サービス プロファイル テンプレートの設定

Cisco Nexus 1000V シリーズ システムに含める VMware ESX インスタンスをホストするための Cisco UCS M71KR-E および M71KR-Q のサービス プロファイルを作成する場合は、次のルールに従います。

管理者は、最初からそのアダプタ経由で Cisco Nexus 1000V シリーズ VEM に渡される VLAN を定義する必要があります。

ネットワーク管理者は、ESX ホストに関する管理接続ビューが必要な場合は、Cisco Discovery Protocol 用のアダプタ ポリシーを設定する必要があります。

ネットワーク管理者は、Cisco Nexus 1000V シリーズ スイッチがマーキングしないトラフィックに対してデフォルトの QoS プロファイルを定義する必要があります。

図 9 に、サービス プロファイルの例を、関係するサービス プロファイル ネットワーキング設定とともに示します。

図 9 Cisco UCS デュアル 10GE および 10G FCoE サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義

図 9 Cisco UCS デュアル 10GE および 10G FCoE サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義
※画像をクリックすると、大きな画面で表示されますpopup_icon


運用

前述したように、設計にはいくつかのトレードオフがあります。複数のアダプタをホストにマッピングすることはできないので、円滑な運用を実現するために、Cisco Nexus 1000V シリーズ スイッチの QoS 設定を利用する必要があります。このソリューションにより、ユーザは、ファブリックへのコンソール インターフェイス、カーネル インターフェイス、実稼動インターフェイスなどに対してプライマリ パスとバックアップ パスを定義できるようになります。この定義は、Cisco UCS デュアル 10GE アダプタ ファミリの場合と同じ方法で優先インターフェイスを割り当てることにより行われます。

パフォーマンスとフェールオーバー テスト

基本的なパフォーマンス データと予測可能なフェールオーバー時間を確認するために、Cisco Nexus 1000V シリーズ スイッチの背後で稼動している仮想マシンから Cisco Unified Computing System の外部にあるホストに対して iPerf テストを実施しました。図 10 に、10GE および 10G FCoE アダプタによるテスト トポロジを示します。

図 10 Cisco UCS デュアル 10GE およびデュアル 10G FCoE メザニン上での Cisco Nexus 1000V シリーズ スイッチ

図 10 Cisco UCS デュアル 10GE およびデュアル 10G FCoE メザニン上での Cisco Nexus 1000V シリーズ スイッチ
※画像をクリックすると、大きな画面で表示されますpopup_icon


図 10 には示されていませんが、ギガビット イーサネットで Cisco Nexus 5010 スイッチ A に接続されたトラフィック ターゲット サーバが存在します。

  • ベースラインの測定結果:
    • 一連の 90 秒間 iPerf フロー テストを実施しました。
    • 外部の単一ギガビット イーサネット ホストに対して、Cisco Unified Computing System 内の Cisco Nexus 1000V シリーズ VEM の背後にある単一仮想マシン上での双方向スループットは、490 Mbps でした。
    • すべての MAC アドレスを Cisco Nexus 1000V シリーズ、Cisco Nexus 5010、および Cisco UCS 6120XP 上で確認できました。
    • B ファブリック側が、デフォルトでトラフィックをアクティブに転送していました。これにより、1 のピニング ID(または vmnic1、B ファブリック アダプタ)が確認されます。
    • Cisco UCS ブレード上の 3 つのスレッドが(スレッドは E5520 CPU のペア内に全部で 16 個存在)、テスト期間中に使用率を 30 パーセント付近に維持していました。
  • Cisco 6120XP B から Cisco Nexus 5010 A へのリンク障害に関する測定結果(フローのアクティブなパス:Cisco Unified Computing System による別のアップリンクへの再ピニングが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • 障害発生時、MAC アドレスはまだ B ファブリックに残っていました。
    • このフローに対する Cisco Unified Computing System の再ピニング時間は 1.16 秒でした。
    • Cisco Nexus 1000V シリーズ スイッチは、リンクの停止を検出しませんでした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、再ピニング時間は 2.3 秒で測定されました。
    • Cisco Nexus 5010 スイッチを vPC 内で設定した場合、このリンク障害が発生したとき、ポート チャネルが残りの正常なメンバーをフローに対して選択しました(Cisco Unified Computing System による再ピニングは実施されませんでした)。このシナリオでのフェールオーバー時間は 0.10 秒、フェールバック時間は 0.03 秒でした。
  • Cisco 6120XP B から Cisco Nexus 5010 B へのリンク障害に関する測定結果(フローの現在のアクティブなパス:Cisco Nexus 1000V シリーズ スイッチによる VMNIC のフェールオーバーが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • フェールオーバー発生時、MAC アドレスは A ファブリック上に存在しました。
    • このフローのフェールオーバー時間は 2.54 秒でした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、フェールオーバー時間は 2.5 秒でした。
    • リンク回復時(テスト ベッドの復元)、Cisco Nexus 1000V シリーズ スイッチは、0.15 秒未満の時間でトラフィックを(ピニング ID のセットアップによる)優先ファブリックに戻しました。
    • 2 つ目のアップリンクが回復すると、Cisco Unified Computing System が元のパスへの再ピニングを実行しました。これには 1.03 秒の時間がかかりました。
    • Cisco Nexus 1000V シリーズの MAC ピニングにより、ハイ アベイラビリティが実現されました。

Cisco Nexus 1000V シリーズでの Cisco UCS 仮想インターフェイス カードの使用例


仮想インターフェイス カードによるハイ アベイラビリティ

Cisco UCS M81KR アダプタと P81E アダプタは、それらを CPU と BIOS に対して複数のアダプタとして完全に表示および提供できるだけでなく、Cisco UCS 6100 シリーズ ファブリック インターコネクト上で異なるアダプタとして定義することもできるという点において、独自の方法で動作します。これらの定義は、Cisco UCS Manager サービス プロファイル内で管理および制御できます。このアダプタは、アダプタの運用のために、VNTag テクノロジーと、仮想インターフェイス コントロール プロトコルと呼ばれる追加プロトコルをフルに活用します。この VNTag モードでは、ファブリック フェールオーバー モードが有効になります(このモードでは、仮想アダプタが両方の Cisco UCS 6100 シリーズ ファブリック インターコネクトに登録されます)。一方のパスがアクティブパスとして使用され、もう一方のパスがバックアップ パスとして使用されます。ホストからは、Cisco Unified Computing System 内で A 側または B 側のいずれかにマッピングされる複数の 10 ギガビット イーサネット シスコ アダプタが検出されます。Cisco Unified Computing System の管理者は、これらのアダプタをファブリック フェールオーバー モードで実行することもできますが、その場合には、ハイ アベイラビリティがホスト上ではなく、ファブリック内で管理されることになります。

Cisco UCS M71KR ASIC の場合と同様に、このアダプタ上ではシスコのマイクロコードが実行されます。また、アダプタは、サーバ起動時にファブリック インターコネクトへの登録プロセスを実行します。前述したように、Cisco UCS VIC は、一対の独立したモードで動作することができます。静的 VIF モードでは、管理者がすべてのサーバ インターフェイスを作成し、メンテナンスします。このモードでは、管理者によって定義されたアダプタはそれぞれがエンドポイントになります。また、VNTag メカニズムによってアダプタが一意に識別されるので、登録プロセスでは、アダプタのユニキャスト MAC アドレスが登録されます。Cisco UCS VIC アダプタの背後にある送信元 MAC アドレスを持つ送信元トラフィックがファブリック インターコネクト上で検出されると、アクティブ リンクのファブリック インターコネクト上の MAC アドレス テーブルが動的に更新されます。この情報は、バックアップ ファブリック インターコネクトに複製されます。

Cisco UCS M81KR または P81E の動的 VIF モードは、もう 1 つの動作モデルを提供します。このモデルでは、各仮想インターフェイスの作成、削除、メンテナンスが、クラスタ内で仮想マシンが動作しているときに VMware vCenter の通信パスを介して行われます。このモデルの目的は、これらのアダプタの調整と提供が仮想マシンに対して直接行われるようにすることで、Virtual Switch(vSwitch; 仮想スイッチ)、Distributed Virtual Switch(DVS; 分散仮想スイッチ)、または Cisco Nexus 1000V シリーズがクラスタ内で移行される際にポートグループの一貫性を維持するための追加の管理オーバーヘッドが発生しないようにすることです。このモードは、VM-FEX と呼ばれ、Cisco UCS M81KR アダプタと P81E アダプタ上でのみ稼動します。またホストは、Cisco Nexus 1000V シリーズ内でブレードになることはできません。このドキュメントは Cisco Nexus 1000V シリーズと Cisco Unified Computing System の相互作用に重点を置いているため、これらのモードの詳細についてここでは説明しません。

このドキュメントにとって重要なのは、サービス プロファイルに動的 vNIC 定義が含まれていると、インストール済みの Nexus 1000V VEM モジュールが、VN-Link をハードウェアでサポートするモードに切り替わり、従来の Nexus 1000V とは異なる動作になるということです。

Cisco Nexus 1000V シリーズ スイッチがこのアダプタに関する管理接続ビューを表示するために Cisco Discovery Protocol パケットを受信する場合は、Cisco UCS VIC サービス プロファイルの設定において、アダプタのペアが Cisco Discovery Protocol 情報を受信するようにネットワーク ポリシーで設定する必要があります。

Cisco UCS M81KR を使用した VMware ESX ホスト上で仮想マシンのハイ アベイラビリティの目標を達成するために、アップリンク MAC ピニングを使用することが推奨されます。イーサネット タイプ(アップリンク)ポート プロファイル上で MAC ピニングを設定するには、管理者が Cisco Nexus 1000V シリーズのイーサネット ポート プロファイルに次のように入力する必要があります。

port-profile type ethernet VIC-vm-data6-no-ha-uplink
  …
  channel-group auto mode on mac-pinning
  …

Cisco UCS VIC に割り当てられる Cisco Nexus 1000V シリーズ アップリンク ポート プロファイルには説明的な名前を付けることが推奨されます。管理者が Cisco Nexus 1000V シリーズのイーサネット ポートを適切なアップリンク ポート グループにマッピングする際に、VMware VCenter でそれらの名前が表示されます。

Cisco Nexus 1000V シリーズの設定のなかで関連する部分を次に示します。

<config-snippet>
port-profile type ethernet VIC-n1k-aipc-no-ha-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 4-5
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 4-5
  state enabled
port-profile type ethernet VIC-vm-data6-no-ha-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 1,6
  channel-group auto mode on mac-pinning
  no shutdown
  state enabled
port-profile type ethernet VIC-vmk-sc-no-ha-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 2-3
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 2-3
  state enabled
interface Ethernet4/1
  inherit port-profile VIC-n1k-aipc-no-ha-uplink 
interface Ethernet4/2
  inherit port-profile VIC-n1k-aipc-no-ha-uplink 
interface Ethernet4/3
  inherit port-profile VIC-vm-data6-no-ha-uplink 
interface Ethernet4/4
  inherit port-profile VIC-vm-data6-no-ha-uplink 
interface Ethernet4/5
  inherit port-profile VIC-vmk-sc-no-ha-uplink 
interface Ethernet4/6
  inherit port-profile VIC-vmk-sc-no-ha-uplink 
</config-snippet>

Cisco UCS M81KR および P81E 上での Cisco Nexus 1000V シリーズ スイッチには明らかな利点が 1 つあります。それは、ネットワークの特定領域へのアップリンクに独自のインターフェイスを定義できることです。それにより、仮想マシンの実稼動トラフィックが通常通過する場所に向かう代替リンク上で VMware VMkernel トラフィックを制限したり、通過させたりできます。他に、Cisco Nexus 1000V シリーズ スイッチを、同一ブレード上の通常の vSwitch または Virtual Distributed Switch(vDS)とともに実行できるという利点もあります。一般に、その単純さから 10GE インターフェイスのペアをそのまま実行することが推奨されます。しかしこの例では、この機能を紹介するために 3 つのペアに分割します。

サービス プロファイル テンプレートの設定

Cisco Nexus 1000V シリーズ システムに含める VMware ESX インスタンスをホストするための Cisco UCS VIC サービス プロファイルを作成する場合は、次のルールに従います。

ネットワーク管理者は、最初からそのアダプタ経由で Cisco Nexus 1000V シリーズ VEM に渡される VLAN を定義する必要があります。

ネットワーク管理者は、VMware ESX ホストに関する管理接続ビューが必要な場合は、Cisco Discovery Protocol 用のアダプタ ポリシーを設定する必要があります。

ネットワーク管理者は、Cisco Nexus 1000V スイッチがマーキングしないトラフィックに対してデフォルトの QoS プロファイルを定義する必要があります。

図 11 に、サービス プロファイルの例を、関係するサービス プロファイル ネットワーキング設定とともに示します。

図 11 Cisco UCS M81KR サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義の 3 つのペア

図 11 Cisco UCS M81KR サービス プロファイル:Cisco Nexus 1000V シリーズ用の vNIC 定義の 3 つのペア
※画像をクリックすると、大きな画面で表示されますpopup_icon


Cisco UCS M81KR VIC アダプタ上での信頼動作と非信頼動作

Cisco UCS M81KR に対応したサーバのサービス プロファイル内では、管理者が信頼できる動作モードを有効にすることも無効にすることもできます。信頼できる動作モードは、Cisco Nexus 1000V シリーズ スイッチがトラフィックをマーキングし、ファブリック全体で QoS ID が使用され遵守されると想定している場合に使用することが推奨されます。

図 12 に、このモードの設定方法を示します。

図 12 Cisco UCS M81KR のレート制限および QoS 信頼セクション

図 12 Cisco UCS M81KR のレート制限および QoS 信頼セクション


ここでメインとなるのは [Host Control] の選択項目です。この項目では、アダプタ単位で QoS マーキングを課すように、あるいはサーバ OS または Cisco Nexus 1000V シリーズによって設定されるマーキングを使用するように、アダプタを設定できます。ここでの重要な注意点は、信頼できるモード([Host Control] = [Full])を選択すると、物理的な VIC 全体でこのモードが使用され、このアダプタ上の他のすべての vNIC インスタンス化も信頼されるようになるということです。このモデルは、Cisco UCS M71KR、M72KR、およびデュアル 10GE アダプタと動作がよく似ています(QoS の観点において)。信頼できるモードでは、Cisco UCS M81KR VIC インターフェイスがアダプタの QoS プロファイルに基づいて適切な QoS マーキングを常に設定します。管理者が [Host Control] の選択項目を変更した場合は、この機能が正しく動作するために、VMware ESX サービス プロファイルを再起動する必要があります。ここは、ESX サーバ内の vmnic の帯域幅を設定できる場所でもあります(1 Mbps きざみ)。

運用

前述したように、設計にはいくつかのトレードオフがあります。Cisco Nexus 1000V シリーズによる CoS マーキングは、VIC の [Host Control] が [Full] に設定された場合にのみ使用されます。[Host Control] を [None] に選択した場合、ユーザは複数のアダプタを選択してそれらをホスト上に定義できます。その後、円滑な運用を実現するために、Cisco Unified Computing System 内で各アダプタにシステム QoS 設定をマッピングする必要があります。このソリューションにより、ユーザは、ファブリックへのコンソール インターフェイス、カーネル インターフェイス、実稼動インターフェイスなどに対してプライマリ パスとバックアップ パスを定義できるようになります。

Cisco UCS VIC は、VEM へのサービス コンソールの移行を不要にできるほどの十分な数のインターフェイスをサポートできます。移行が必要になっても、これらの追加アダプタを VMware の統合型ソフトウェア スイッチで使用できるからです。

パフォーマンスとフェールオーバー テスト

基本的なパフォーマンス データと予測可能なフェールオーバー時間を確認するために、Cisco Nexus 1000V シリーズ スイッチの背後で稼動している仮想マシンから Cisco Unified Computing System の外部にあるホストに対して iPerf テストを実施しました。図 13 に、テスト トポロジを示します。

図 13 Cisco UCS M81KR 上の Cisco Nexus 1000V シリーズ スイッチ

図 13 Cisco UCS M81KR 上の Cisco Nexus 1000V シリーズ スイッチ
※画像をクリックすると、大きな画面で表示されますpopup_icon


図 13 には示されていませんが、ギガビット イーサネットで Cisco Nexus 5010 スイッチ A に接続されたトラフィック ターゲット サーバが存在します。

  • ベースラインの測定結果:
    • 一連の 90 秒間 iPerf フロー テストを実施しました。
    • 外部の単一ギガビット イーサネット ホストに対して、Cisco Unified Computing System 内の Cisco Nexus 1000V シリーズ VEM の背後にある単一仮想マシン上での双方向スループットは、490 Mbps でした。
    • すべての MAC アドレスを Cisco Nexus 1000V シリーズ、Cisco Nexus 5010、および Cisco UCS 6120XP 上で確認できました。
    • A ファブリック側が、デフォルトでトラフィックをアクティブに転送していました。これにより、1 のピニング ID(または vmnic1、このプロファイル内の A ファブリック アダプタ)が確認されます。
    • Cisco UCS ブレード上の 3 つのスレッドが(スレッドは E5520 CPU のペア内に全部で 16 個存在)、テスト期間中に使用率を 30 パーセント付近に維持していました。
  • Cisco 6120XP B から Cisco Nexus 5010 A へのリンク障害に関する測定結果(フローのアクティブなパス:Cisco Unified Computing System による別のアップリンクへの再ピニングが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • 障害発生時、MAC アドレスはまだ A ファブリックに残っていました。
    • このフローに対する Cisco Unified Computing System の再ピニング時間は 1.15 秒でした。
    • Cisco Nexus 1000V シリーズ スイッチは、リンクの停止を検出しませんでした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、再ピニング時間は 2.2 秒で測定されました。
    • Cisco Nexus 5010 スイッチを vPC 内で設定した場合、このリンク障害が発生したとき、ポート チャネルが残りの正常なメンバーをフローに対して選択しました(Cisco Unified Computing System による再ピニングは実施されませんでした)。このシナリオでのフェールオーバー時間は 0.12 秒、フェールバック時間は 0.04 秒でした。
  • Cisco 6120XP B から Cisco Nexus 5010 B へのリンク障害に関する測定結果(フローの現在のアクティブなパス:Cisco Nexus 1000V シリーズによる VMNIC のフェールオーバーが発生):
    • 90 秒間の iPerf 単方向(仮想マシンから外部ホスト)フロー テストを実施しました。
    • フェールオーバー発生時、MAC アドレスは A ファブリック上に存在しました。
    • このフローのフェールオーバー時間は 2.6 秒でした。
    • これと同じテストを反対方向(外部ホストから仮想マシン)で実施した場合、フェールオーバー時間は 2.6 秒でした。
    • リンク回復時(テスト ベッドの復元)、Cisco Nexus 1000V シリーズ スイッチは、0.15 秒未満の時間でトラフィックを(ピニング ID のセットアップによる)優先ファブリックに戻しました。
    • 2 つ目のアップリンクが回復すると、Cisco Unified Computing System が元のパスへの再ピニングを実行しました。これには 1.0 秒の時間がかかりました。
    • Cisco Nexus 1000V シリーズの MAC ピニングにより、ハイ アベイラビリティが実現されました。

Cisco Unified Computing System 内での Cisco Nexus 1000V シリーズの仮想スイッチ モジュールの配置


ここでは、Cisco Unified Computing System に対する Virtual Supervisor Module(VSM; 仮想スーパーバイザ モジュール)の相対配置と物理イーサネット インターフェイスの数に関する推奨事項を説明します。これらのオプションは、Cisco Unified Computing System 環境におけるお客様の推奨される使用順で示されています。

オプション 1:Cisco Nexus 1010 上で Cisco Unified Computing System の外部に配置された VSM

このシナリオでは、既存の非仮想化環境とまったく同じ方法で仮想環境の管理動作が実現されます。Nexus 1010 上に複数の VSM インスタンスを導入することで、複数の vCenter データセンターをサポートできます。

オプション 2:Cisco Nexus 1000V シリーズ VEM 上で Cisco Unified Computing System の外部に配置された VSM

このモデルにより、仮想インフラストラクチャの中央集中型管理が可能になります。また、非常に高い安定性が得られることも実証されています。

オプション 3:VMware vSwitch 上で Cisco Unified Computing System の外部に配置された VSM

このモデルは、管理対象デバイスが分離され、Cisco Nexus 1010 Virtual Services Appliance のアプライアンス モデルへの移行に適しています。このオプションでは、VSM デバイスと VEM デバイスの間のネットワーキング リンクの管理と運用のモデルが問題となる可能性があります。

オプション 4:VMware vSwitch 上で Cisco Unified Computing System の内部に配置された VSM

このモデルもテスト導入で高い安定性を示しました。このオプションでは、VSM デバイスと VEM デバイスの間のネットワーキング リンクの管理と運用のモデル、および Cisco Unified Computing System 内での二重のスイッチング インフラストラクチャの構築が問題となる可能性があります。

このドキュメント内で使用されている Cisco Unified Computing System と Cisco Nexus 1000V シリーズのバージョン

このテストに使用された Cisco Unified Computing System ソフトウェアのバージョンは 1.4(1m) です。このテストに使用された Cisco Nexus 1000V シリーズ ソフトウェアのバージョンは 1000v.4.0.4.SV1.3a です。

まとめ


Cisco Unified Computing System 内で Cisco Nexus 1000V シリーズを使用する場合は、前述の理由から、常にアダプタ ファブリック フェールオーバーなしで使用し、ハッシングを Cisco Nexus 1000V シリーズの MAC ピニング機能にまかせます。このことは、VN-Link がハードウェアで使用される動的 VIF ポリシーなしで Cisco UCS VIC を使用するシナリオでも推奨されます。

関連情報


Cisco Nexus 1000V シリーズの詳細については、
www.cisco.com/jp/go/nexus1000/ を参照してください。

Cisco Unified Computing System の詳細については、
www.cisco.com/jp/go/unifiedcomputing/ を参照してください。

仮想イーサネット ブリッジングに対する IEEE の取り組みについては、
http://www.ieee802.org/1/pages/dcbridges.html [英語] を参照してください。

Intel VMDq テクノロジーの詳細については、
http://www.intel.com/network/connectivity/vtc_vmdq.htm [英語] を参照してください。


付録 A:Cisco Unified Computing System 内での VMware ESX サーバのトラブルシューティング


Cisco Unified Computing System 環境内で Cisco Nexus 1000V シリーズを使用する場合、システムが VMware ESX サーバとの通信を失い、それ以上動作できなくなると、トラブルシューティングが必要になります。この状況を解決するための最初のステップは、VMware ESX を稼動しているブレード内でコンソール ポートへの接続を直接トラブルシューティングすることです。Cisco Unified Computing System では、サービス プロファイルがブレード上にインスタンス化されると、そのブレードに対して KVM コンソール セッションを開くためのオプションが提供されます。このオプションは、リモート KVM コンソール操作を実行したり、管理者のマシンからメディアを直接共有したりする Java プラグインを起動します。図 14 のような画面が表示されます。KVM コンソールから、Alt を押した状態で F1 を押してログイン画面を開きます。この画面を使用して、VMware ESX に直接ログインできます。

図 14 VMware ESX を稼動している Cisco UCS ブレードに対する KVM コンソール

図 14 VMware ESX を稼動している Cisco UCS ブレードに対する KVM コンソール
※画像をクリックすると、大きな画面で表示されますpopup_icon


トラブルシューティングが一般によく行われる状況の 1 つとして、インストール中に VMware ESX ホスト サービス コンソールまたは VMware VMkernel インターフェイスを Cisco Nexus 1000V シリーズへ移行する際に発生するエラーがあります。この場合には Cisco Nexus 1000V シリーズのシステム VLAN の使用も役立ちますが、このドキュメントでは回復メカニズムについて説明します。回復の手順は、vswif インターフェイスが接続されている DVS 上のポートをリスト表示し、DVS から vswif を削除し、サービス コンソール ポート グループを再び vSwitch に追加し、vswif インターフェイスをそのポート グループに追加します。この手順に使用するコマンドは、次のセクションで示します。

Cisco Unified Computing System 内の Cisco Nexus 1000V シリーズ スイッチのトラブルシューティングに使用する VMware ESX および ESXi のコマンド

サービス コンソール OS を搭載した VMware ESX では、/usr/sbin ディレクトリにこれらのコマンドがインストールされています。サービス コンソールのログイン プロンプトを表示するには Alt を押した状態で F1 を押し、プロンプトを終了するには Alt を押した状態で F11 を押します。回復作業のために誤った設定の Cisco UCS ブレードにアクセスするには、サーバ ビューの下にある KVM 項目をクリックします。この手順では、KVM の IP アドレスのセットアップと割り当てが完了していることを前提にしています。

VMware ESXi では、VMware ESX の場合と同様の esxcfg-vswitch 機能がすべて提供されます。VMware ESXi にはサービス コンソール OS が存在しないので、Alt+F2 キーと Alt+F1 キーの押下によって、VMware ESXi コマンド ラインにアクセスしたり、そこから復帰したりします(ローカル テクニカル サポート モードが有効になっている必要があります)。ここに示されているすべての esxcfg-vswif コマンドは、esxcfg-vmknic に置き換えられつつあります。個々の詳細は必要に応じて最新のものに変更してください。

最も一般的な目的:ホストの新しい管理 I/F の回復(ESXi と同様)

esxcfg-vswitch -l | more (vmnic0 と vswif0 の DV ポート ID、および DVS 名を探します)

esxcfg-vswitch -Q vmnic0 -V [vmnic0 port#] DVS_NAME

esxcfg-vswitch -L vmnic0 vSwitch0

esxcfg-vswitch -A “Service Console” vSwitch0

esxcfg-vswitch -p “Service Console” -v 2 vSwitch0 (VLAN2 上に配置する例)

esxcfg-vswif -d vswif0 -P [vswif0 port#] -V DVS_NAME

esxcfg-vswif -a vswif0 -p “Service Console” -i 10.1.1.10 -n 255.255.255.0

VEM のインスタンスを ESX サーバ上で管理する場合:

     vem-remove -d		現在インストールされている VEM を削除します。

     esxupdate -bundle=ftp://Administrator:password@FTP_IP/VEM_Path/VEM410-201007311.zip update	   
            FTP サーバから VEM をダウンロードしてインストールします。

DVS 拡張を vCenter から削除する場合:

http://IP-of-vCenter/mob

[content] -> [extensions]

引用符を付けずに拡張を削除します。

現在の設定に関する情報を一覧表示する場合:

esxcfg-vswif -l 現在の vswif の設定に関する情報を一覧表示します。

esxcfg-vswitch -l 現在の vswitch と DVS の設定に関する情報を一覧表示します。

esxcfg-vmknic -l 現在の vmk の設定に関する情報を一覧表示します。

vSwitch の存在を管理する場合:

esxcfg-vswitch -a vSwitch0 vSwitch0 という名前の vSwitch をサーバに追加します。

esxcfg-vswitch -d vSwitch0 vSwitch0 という名前の vSwitch をサーバから削除します。

vSwitch の MTU を管理する場合:

esxcfg-vswitch -m 9000 vSwitch0 vswitch と基盤 vmnic 上にジャンボ フレームを設定します。

vSwitch 上のポートグループを管理する場合:

esxcfg-vswitch -A “Service Console” vSwitch0

Service Console という名前のポートグループを vSwitch0 に追加します。

esxcfg-vswitch -D “Service Console” vSwitch0

Service Console という名前のポートグループを vSwitch0 から削除します。

vSwitch 上のポートグループに VLAN メンバシップを割り当てる場合:

esxcfg-vswitch -p “Service Console” -v 102 vSwitch0

vSwitch0 上で Service Console という名前のポートグループをユーザ VLAN 102 に設定します。

ESX から検出できる有効な NIC を表示する場合:

esxcfg-nics -l vmnic とそのプロパティ(MTU など)を一覧表示します。

DVS または N1k からのアップリンクを管理する場合:

最初に、リスト コマンド(このセクション内の最初のコマンド)を実行して、既存のアップリンク(vmnic0、vmnic1 など)のポート番号を取得します。このポート番号は、port# の形式で表します。

esxcfg-vswitch -Q vmnic0 -V [port#] myN1kDVS

myN1kDVS という名前の DVS から vmnic0 アップリンクを削除します。

esxcfg-vswitch -P vmnic0 -V [port#] myN1kDVS

myN1kDVS という名前の DVS に vmnic0 アップリンクを追加します。

vmnic アップリンクを DVS に再び追加する場合は、コマンド ラインからではなく、vCenter からこの作業を実行することを推奨します。

vSwitch へのアップリンクを管理する場合:

esxcfg-vswitch -L vmnic0 vSwitch0

vSwitch0 へのアップリンクとして vmnic0 を追加します。

esxcfg-vswitch -U vmnic0 vSwitch0

vSwitch0 へのアップリンクとして vmnic0 を削除します。vSwitch から vmnic を削除する場合は、vSwitch から N1k DVS に移行する際に、コマンド ラインからではなく、vCenter からこの作業を実行することを推奨します。

ESX サーバ ポート グループから vmk を削除する場合:

esxcfg-vmknic -d -p “port_group”

vSwitch 上のポートグループから vmk を削除します。

esxcfg-vmknic -d -v xxx -s myN1kDVS

Nexus1000V 上のポートグループから vmk を削除します。

ESX サーバ ポート グループから vswif を削除する場合:

esxcfg-vswif -d vswif0

vswif を削除します。

esxcfg-vswif -d vswif0 -p “Service Console” -P xxx -V myN1kDVS

Nexus1000V 上のポートグループから vswif を削除します。これは、エラーが発生した状況において一般に実施される作業であり、Nexus 1000V への移行時に ESX サーバへの接続が失われます。ポートグループを vSwitch0 に追加してから、vswif を追加する必要があります。

ESX サーバへ vswif を追加する場合:

esxcfg-vswif -a vswif0 -p “Service Console” -i 10.1.1.10 -n 255.255.255.0

IP 10.1.1.10/24 の vswif0 をポートグループ Service Console に追加します。

esxcfg-vswif -a vswif0 -p “Service Console” -i 10.1.1.10 -n 255.255.255.0 -P [port#]-V myN1kDVS

IP 10.1.1.10/24 の vswif0 を、DVS myN1kDVS 上のポート port# へのポートグループ Service Console に追加します。port# には、通常、esxcfg-vswitch -l コマンドで DVS 設定を一覧表示したときの有効なポート番号のリストの最後に表示される未使用のエントリが使用されます。

ESX サーバへ vmk を追加する場合:

esxcfg-vmknic -a -i 10.1.3.10 -n 255.255.255.0 -m 9000 “VMkernel”

IP 10.1.3.10/24 の vmk を、ジャンボ フレームを設定して vSwitch に追加します。

esxcfg-vmknic -a -i 10.1.3.10 -n 255.255.255.0 -m 9000 -s myN1kDVS

IP 10.1.3.10/24 の vmk を、ジャンボ フレームを設定して DVS に追加します。

ESX サーバ上の vmk にジャンボ フレームを設定する場合:

esxcfg-vmknic -m 9000 -v xxx -s myN1kDVS

ESX サーバのデフォルト ゲートウェイを管理する場合:

vCenter GUI 上ではこの変更を直接実行できますが、CLI 上では、/etc/sysconfig/network ファイルを編集してから、vswif のデフォルト ゲートウェイを更新する必要があります。このファイルは次のようになります。

NETWORKING=yes

HOSTNAME=ESXServerBlade4.cisco.com

GATEWAY=10.1.1.1

このファイルを保存した後、ESX サーバを再起動して変更を反映させる必要があります。

トラブルシューティング コマンド VMkernel インターフェイスから ping テストする場合:

esxcfg-route -l VMKernel ネットワーク上のルートを取得します。

esxcfg-vmknic -l vmk インターフェイス上のパラメータと MTU を確認します。

vmkping -s pkt_size -f X.X.X.X パケット サイズとフラグメント不可を指定して VMKernel ネットワーク上の IP を ping します。

ESX ホスト上の VEM インストレーションをテストする場合:

vmkload_mod -l | grep vem 適切な VEM がロードされている(それらのモジュールが返される)ことを確認します。