この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章の内容は、次のとおりです。
Cisco Unified Computing System(Cisco UCS)は、アクセス レイヤ ネットワーキングとサーバを融合します。 この高性能次世代サーバ システムは、作業負荷に対する敏捷性およびスケーラビリティの高いデータセンターを実現します。
ハードウェア コンポーネントおよびソフトウェア コンポーネントは、1 つの統合ネットワーク アダプタ上に複数のタイプのデータセンター トラフィックを通過させる、シスコのユニファイド ファブリックをサポートします。
Cisco UCS のアーキテクチャを単純化することにより、必要なデバイスの数を削減し、スイッチング リソースを中央に集中させることができます。 シャーシ内部でのスイッチングを止めると、ネットワーク アクセス レイヤのフラグメンテーションが大きく減少します。
Cisco UCS は、ラック、またはラックのグループでシスコのユニファイド ファブリックを実装し、10 ギガビット シスコ データセンター イーサネット リンクおよび Fibre Channel over Ethernet(FCoE)リンク経由でイーサネットおよびファイバ チャネル プロトコルをサポートします。
この徹底的な単純化により、スイッチ、ケーブル、アダプタ、および管理ポイントの最高 3 分の 2 が削減されます。 Cisco UCS ドメイン内のデバイスはすべて、1 つの管理ドメインの下にとどまり、冗長コンポーネントの使用中、ハイ アベイラビリティを保ちます。
Cisco UCS の管理およびデータ プレーンはハイ アベイラビリティおよび冗長アクセス レイヤ ファブリック インターコネクトのために設計されています。 さらに、Cisco UCS は、データ レプリケーションやアプリケーションレベルのクラスタ処理テクノロジーなど、データセンターに対する既存のハイ アベイラビリティおよびディザスタ リカバリ ソリューションをサポートします。
単一の Cisco UCS ドメインは複数のシャーシおよびそのサーバをサポートします。これらはすべて 1 つの Cisco UCS Manager を通じて管理されます。 スケーラビリティの詳細については、シスコの担当者にお問い合わせください。
Cisco UCS ドメインでは、データセンターのコンピューティング リソースを、急速に変化するビジネス要件にすばやく合せることができます。 この柔軟性を組み込むかどうかは、ステートレス コンピューティング機能の完全な実装が選択されているかどうかによって決定されます。
必要に応じて、サーバやその他のシステム リソースのプールを適用し、作業負荷の変動への対応、新しいアプリケーションのサポート、既存のソフトウェアおよびビジネス サービスの拡張、スケジュール済みのダウンタイムおよび予定されていないダウンタイムの両方への適応を行うことができます。 サーバの ID は、最小のダウンタイムで、追加のネットワーク設定を行わずにサーバからサーバへ移動できるモバイル サービス プロファイルに抽象化することができます。
このレベルの柔軟性により、サーバの ID を変更したり、サーバ、Local Area Network(LAN; ローカル エリア ネットワーク)、または Storage Area Network(SAN)を再設定したりせずに、すばやく、簡単にサーバの容量を拡張することができます。 メンテナンス ウィンドウでは、次の操作をすばやく行うことができます。
Cisco UCS は VM-FEX テクノロジーを実装するために最適化されています。 このテクノロジーは、より優れたポリシーベースの設定とセキュリティ、会社の運用モデルとの適合、VMware の VMotion への順応など、サーバ仮想化に対してより優れたサポートを実現します。
ユニファイド ファブリックを使用すると、単一の Data Center Ethernet(DCE; データセンター イーサネット)ネットワーク上で複数の種類のデータセンター トラフィックを行き来させることができます。 さまざまな一連のホスト バス アダプタ(HBA)およびネットワーク インターフェイス カード(NIC)をサーバに搭載させる代わりに、ユニファイド ファブリックは統合された単一のネットワーク アダプタを使用します。 このタイプのアダプタは、LAN および SAN のトラフィックを同一のケーブルで運ぶことができます。
Cisco UCS は、Fibre Channel over Ethernet(FCoE)を使用して、ファブリック インターコネクトとサーバ間をつなぐ同一の物理イーサネット接続でファイバ チャネルおよびイーサネットのトラフィックを運びます。 この接続はサーバ上の統合されたネットワーク アダプタで終端し、ユニファイド ファブリックはファブリック インターコネクトのアップリンク ポートで終端します。 コア ネットワークでは、LAN および SAN のトラフィックは分かれたままです。 Cisco UCS では、データセンター全体でユニファイド ファブリックを実装する必要はありません。
統合されたネットワーク アダプタは、オペレーティング システムに対してイーサネット インターフェイスおよびファイバ チャネル インターフェイスを提示します。 サーバ側では、標準のファイバ チャネル HBA を確認しているため、オペレーティング システムは FCoE のカプセル化を認識していません。
ファブリック インターコネクトでは、サーバ側イーサネット ポートでイーサネットおよびファイバ チャネルのトラフィックを受信します。 (フレームを区別する Ethertype を使用する)ファブリック インターコネクトは、2 つのトラフィックの種類に分かれます。 イーサネット フレームおよびファイバ チャネル フレームは、それぞれのアップリンク インターフェイスにスイッチされます。
Cisco UCS は、Fibre Channel over Ethernet(FCoE)標準プロトコルを使用して、ファイバ チャネルを提供します。 上部のファイバ チャネル レイヤは同じであるため、ファイバ チャネル動作モデルが維持されます。 FCoE ネットワーク管理と設定は、ネイティブのファイバ チャネル ネットワークと同様です。
FCoE は、物理イーサネット リンク上のファイバ チャネル トラフィックをカプセル化します。 FCoE は専用のイーサタイプ 0x8906 を使用して、イーサネット上でカプセル化されるため、FCoE トラフィックと標準イーサネット トラフィックは同じリンク上で処理できます。 FCoE は ANSI T11 標準委員会によって標準化されています。
ファイバ チャネル トラフィックには、ロスレス トランスポート層が必要です。 ネイティブ ファイバ チャネルが使用するバッファ間クレジット システムの代わりに、FCoE はイーサネット リンクを使用して、ロスレス サービスを実装します。
ファブリック インターコネクト上のイーサネット リンクは、2 つのメカニズムを使用して、FCoE トラフィックのロスレス トランスポートを保証します。
IEEE 802.3x リンクレベル フロー制御では、輻輳の発生している受信側からエンドポイントに対して、少しの間、データの送信を一時停止するように信号を送ることができます。 このリンクレベル フロー制御では、リンク上のすべてのトラフィックが一時停止します。
送受信方向は個別に設定できます。 デフォルトでは、リンクレベル フロー制御は両方向でディセーブルです。
各イーサネット インターフェイスで、ファブリック インターコネクトは、プライオリティ フロー制御、またはリンクレベル フロー制御のいずれかをイネーブルにできます。両方をイネーブルにはできません。
プライオリティ フロー制御(PFC)機能は、イーサネット リンク上の特定のトラフィック クラスにポーズ機能を適用します。 たとえば、PFC は FCoE トラフィックにロスレス サービスを、標準イーサネット トラフィックにベストエフォート サービスを提供します。 PFC は、(IEEE 802.1p トラフィック クラスを使用して)特定のイーサネット トラフィック クラスに、さまざまなレベルのサービスを提供することができます。
PFC は、IEEE 802.1p の CoS 値に基づき、ポーズを適用するかどうかを判断します。 ファブリック インターコネクトは、PFC をイネーブルにするときに、特定の CoS 値を持つパケットにポーズ機能を適用するように、接続されたアダプタを設定します。
デフォルトでは、ファブリック インターコネクトは、PFC 機能をイネーブルにするかどうかのネゴシエーションを行います。 ネゴシエーションに成功すると、PFC がイネーブルにされますが、リンクレベル フロー制御は(設定値に関係なく)ディセーブルのままです。 PFC ネゴシエーションに失敗した場合は、PFC をインターフェイスで強制的にイネーブルにするか、IEEE 802.x リンクレベル フロー制御をイネーブルにできます。
サービス プロファイルは、Cisco UCS の中心概念です。 各サービス プロファイルにより具体的な目的のサービスが提供されるため、関連付けられたサーバ ハードウェアでホスティングされるアプリケーションをサポートするために必要な設定が確実にハードウェアに設定されます。
サービス プロファイルには、サーバ ハードウェア、インターフェイス、ファブリック接続、およびサーバとネットワークの ID に関する設定情報が保持されます。 この情報は、Cisco UCS Manager を使って管理できる形式で保存されています。 すべてのサービス プロファイルは一元的に管理され、ファブリック インターコネクト上のデータベースに格納されます。
各サーバは、サービス プロファイルと関連付けられる必要があります。
各サーバは、いつの時点においても 1 つのサービス プロファイルだけに関連付けることができます。 同様に、各サービス プロファイルは一度に 1 つのサーバだけに関連付けることができます。
サービス プロファイルをサーバと関連付けると、サーバではオペレーティング システムとアプリケーションをインストールする準備が整います。サーバの設定はサービス プロファイルで確認することができます。 サービス プロファイルとのアソシエーションを形成しているサーバで不具合が発生しても、サービス プロファイルが自動的に別のサーバにフェールオーバーすることはありません。
サーバからサービス プロファイルの関連付けが解除されると、サーバの ID および接続の情報は工場出荷時のデフォルトにリセットされます。
各サービス プロファイルは、このサーバについて、Cisco UCS インフラストラクチャを経由して外部ネットワークに接続する LAN および SAN ネットワーク接続を指定します。 Cisco UCS サーバおよびその他のコンポーネントについて、ネットワーク接続を手動で設定する必要はありません。 すべてのネットワーク設定は、サービス プロファイルを通じて行われます。
サービス プロファイルをサーバに関連付けると、サービス プロファイルの情報を使用して Cisco UCS 内部ファブリックが設定されます。 このプロファイルが以前に別のサーバと関連付けられていた場合、ネットワーク インフラストラクチャが再構成され、新しいサーバに対して同じネットワーク接続がサポートされます。
サービス プロファイルはリソース プールとポリシーを利用して、サーバと接続設定を操作できます。
サービス プロファイルがサーバに関連付けられているときには、プロファイルのデータに応じて次のコンポーネントが設定されます。
これらのコンポーネントを直接設定する必要はありません。
製造元がサーバ ハードウェアに記録したネットワーク ID およびデバイス ID を使用できます。あるいは、関連付けられたサービス プロファイルで指定した ID を直接または MAC、WWN、UUID などの ID プール経由で使用できます。
次の例は、サービス プロファイルに含めることができる設定情報の方法を示しています。
次のように、サービス プロファイルで設定できるサーバ操作機能があります。
vNIC は物理ネットワーク アダプタで設定される仮想化されたネットワーク インターフェイスであり、サーバのオペレーティング システムに物理 NIC として表示されます。 システムのアダプタの種類によって、作成できる vNIC の数は異なります。 たとえば、統合ネットワーク アダプタには NIC が 2 つあります。つまり、アダプタごとに最大 2 つの vNIC を作成できます。
vNIC はイーサネット上で通信し、LAN トラフィックを処理します。 少なくとも、各 vNIC には名前、ファブリック接続、ネットワーク接続を設定する必要があります。
vHBA とは、物理ネットワーク アダプタ上に設定される仮想化されたホスト バス アダプタのことで、サーバのオペレーティング システムには物理 HBA に見えます。 システムのアダプタの種類に応じて作成できる vHBA の数が決まります。 たとえば、統合ネットワーク アダプタには HBA が 2 つあります。つまり、アダプタごとに最大 2 つの vHBA を作成できます。 他方、ネットワーク インターフェイス カードには HBA がありません。これは、アダプタで vHBA を作成できないことを意味します。
vHBA は FCoE 上で通信し、SAN トラフィックを処理します。 少なくとも、各 vHBA には名前とファブリック接続を設定する必要があります。
このタイプのサービス プロファイルにより、柔軟性と制御性が最大化されます。 このプロファイルを使用すると、関連付けの時点でサーバにある ID の値を上書きし、Cisco UCS Manager のリソース プールとポリシー設定を使用して管理タスクの一部を自動化できます。
このサービス プロファイルとサーバの関連付けを解除して、このプロファイルを別のサーバに関連付けることができます。 この再アソシエーションは手動で行うこともできますし、自動サーバ プール ポリシーを通じて行うこともできます。 新しいサーバのハードウェアが持つ UUID や MAC アドレスなどの工場出荷時の設定は、サービス プロファイルの設定で上書きされます。 その結果、サーバでの変更はネットワークには透過的に行われます。 新しいサーバの使用を開始するために、ネットワークでコンポーネントやアプリケーションを再設定する必要はありません。
このプロファイルにより、次のようなリソース プールやポリシーを通じて、システム リソースを利用し、管理できるようになります。
MAC アドレスのプール、WWN アドレス、UUID などの仮想 ID 情報
イーサネットおよびファイバ チャネル アダプタ プロファイル ポリシー
ファームウェア パッケージ ポリシー
オペレーティング システム ブート順序ポリシー
サービス プロファイルに電源管理ポリシー、サーバ プールの資格ポリシー、または個々のハードウェア設定を必要とする別のポリシーが含まれている場合、プロファイルは、Cisco UCS ドメインで、任意のタイプのサーバを使用できます。
これらのサービス プロファイルは、ラックマウント サーバまたはブレード サーバと関連付けることができます。 サービス プロファイルを移行する機能は、サービス プロファイルの移行の制限を選択するかどうかにより異なります。
(注) |
移行を制限しない場合は、既存のサービス プロファイルを移行する前に、Cisco UCS Manager による新規サーバに対する互換性チェックは実行されません。 両方のサーバのハードウェアが類似していない場合、アソシエーションが失敗することがあります。 |
このハードウェアベースのサービス プロファイルは使用も作成も簡単です。 このプロファイルは、サーバのデフォルト値を使用して、ラックマウント型サーバの管理を模倣します。 このプロファイルは特定のサーバに結び付けられており、別のサーバへの移動または移行はできません。
このサービス プロファイルを使用するために、プールや設定ポリシーを作成する必要はありません。
このサービス プロファイルは、アソシエーション時に存在する次のような ID 情報および設定情報を継承し、適用します。
このプロファイルをサーバに関連付ける前に、製造元でサーバのハードウェアに設定された値が変更された場合、このサービス プロファイルを通じて継承されたサーバの ID および設定情報は、この値とは異なる可能性があります。
サービス プロファイル テンプレートにより、同一の基本パラメータ(vNIC および vHBA の数など)や、同じプールから取得された ID 情報が含まれる複数のサービス プロファイルを迅速に作成できます。
ヒント |
既存のサービス プロファイルに類似した値が含まれるサービス プロファイルが 1 つだけ必要な場合は、Cisco UCS Manager GUI でサービス プロファイルのクローニングが可能です。 |
たとえば、サーバをホスト データベース ソフトウェアに設定するために同様の値が含まれた複数のサービス プロファイルが必要な場合は、手作業でも既存のサービス プロファイルからでもサービス プロファイル テンプレートを作成できます。 次に、このテンプレートを使用してサービス プロファイルを作成します。
Cisco UCS は、次のタイプのサービス プロファイル テンプレートをサポートします。
初期テンプレートから作成されたサービス プロファイルはテンプレートのプロパティをすべて継承します。 しかし、プロファイルの作成後は、テンプレートへの接続が失われます。 このテンプレートから作成された 1 つ以上のプロファイルを変更する必要がある場合は、これらのプロファイルを個別に変更する必要があります。
アップデート テンプレートから作成されたサービス プロファイルでは、テンプレートのすべてのプロパティが継承され、テンプレートへのつながりが保持されます。 テンプレートの何らかの変更があると、テンプレートから作成されたサービス プロファイルは自動的にアップデートされます。
ポリシーは、ある特定の状況で、Cisco UCS コンポーネントがどのように動作するかを決定します。 大半のポリシーで複数のインスタンスを作成することができます。 たとえば、サーバに応じて、PXE ブート、SAN ブート、ローカル ストレージからのブートを使い分けられるように、異なるブート ポリシーが必要になる場合があります。
ポリシーにより、システム内で機能を区別することができます。 対象事象のエキスパートは、その対象事象を専門としない他者により作成されたサービス プロファイルで使用されるポリシーを定義できます。 たとえば、LAN アドミニストレータは、そのシステムのアダプタ ポリシー、および Quality Of Service ポリシーを作成できます。 次に、LAN 管理に関する対象事項の専門知識が限られているか、あるいはまったく欠けている他者により作成されたサービス プロファイルで、これらのポリシーを使用できます。
Cisco UCS Manager では、下記の 2 つのタイプのポリシーを作成して使用できます。
プールは、システムで使用できる ID のコレクション、物理リソース、または論理リソースです。 すべてのプールは、サービス プロファイルの柔軟性を高め、ユーザがシステム リソースを中央で集中管理できるようにします。
プールを使用して、未設定のサーバや、使用可能なサーバ ID 情報の範囲を、データセンターにとって意味のあるグループに分割することができます。 たとえば、類似する特性を持つ未設定のサーバのプールを作成して、このプールをサービス プロファイルにインクルードした場合、ポリシーを使用して、このサービス プロファイルと使用可能な未設定のサーバとのアソシエーションを形成することができます。
MAC アドレスなどの ID 情報をプールした場合、特定のアプリケーションをホストするサーバに範囲をあらかじめ割り当てることができます。 たとえば、すべてのデータベース サーバを、同じ範囲の MAC アドレス、UUID、および WWN 内に設定できます。
[Domain Pools] は Cisco UCS ドメインにローカルに定義され、その Cisco UCS ドメインでのみ使用できます。
[Global Pools] は Cisco UCS Central に定義され、Cisco UCS ドメイン間で共有できます。 Cisco UCS ドメインが Cisco UCS Central に登録されている場合、[Global Pools] を Cisco UCS Manager に割り当てることができます。
オーバーサブスクリプションは、同じファブリック インターコネクト ポートに複数のネットワーク デバイスが接続されているときに発生します。 ポートが短時間でも最高速度で実行されることはほとんどないため、これにより、ファブリック インターコネクトの使用が最適化されます。 その結果、オーバーサブスクリプションが正しく設定されていれば、使用されていない帯域幅を活用できるようになります。 しかし、オーバーサブスクリプションの設定に間違いがあると、帯域幅のコンテンションが起こり、オーバーサブスクライブ ポートを使用しているすべてのサービスで Quality Of Service が低下します。
たとえば、4 つのサーバが 1 つのアップリンク ポートを共有していて、これらのサーバがすべて、このアップリンク ポートで使用できる帯域幅よりも大きい累積率でデータを送信しようとした場合に、オーバーサブスクリプションが発生します。
Cisco UCS ドメインでのオーバーサブスクリプションの設定に影響を与える可能性のある要因は次のとおりです。
この比率はパフォーマンスに影響を与えるため、システム内のサーバに面したポートの数と、アップリンク ポートの数を知っている必要があります。 たとえば、使用しているシステムに、サーバと通信できるポートが 20 個あるときに、ネットワークと通信できるポートが 2 つだけの場合、このアップリンク ポートはオーバーサブスクライブされます。 この状況では、サーバにより作成されるトラフィックの量もパフォーマンスに影響を与えます。
Cisco UCS ファブリック インターコネクトと LAN の上位層の間にさらにアップリンク ポートを追加して、帯域幅を増やすことができます。 Cisco UCS では、すべてのサーバと NIC が確実に LAN にアクセスできるようにするために、ファブリック インターコネクト 1 つにつき、少なくとも 1 つのアップリンク ポートが必要です。 LAN アップリンクの数は、すべての Cisco UCS サーバで使用される帯域幅の合計により決定されます。
6100 シリーズ ファブリック インターコネクトでは、ファイバ チャネル アップリンク ポートは拡張スロットのみで使用できます。 使用可能なファイバ チャネル アップリンクの数を増やすには、拡張スロットを追加する必要があります。 イーサネット アップリンク ポートは、固定スロットと拡張スロットに存在できます。
Cisco UCS Manager バージョン 2.0 以降を実行する 6200 シリーズ ファブリック インターコネクトでは、イーサネット アップリンク ポートとファイバ チャネル アップリンク ポートの両方を、ベース モジュールに加え、拡張ジュール上にも設定できます。
たとえば、2 つの Cisco UCS 5100 シリーズ シャーシに、ハーフ幅の Cisco UCS B200-M1 サーバが最大限に入っている場合、サーバの数は 16 台です。 ファブリック インターコネクト 1 つあたり LAN アップリンクが 1 つのクラスタ設定では、これら 16 台のサーバは 20GbE の LAN 帯域幅を共有します。 より大きい容量が必要である場合、ファブリック インターコネクトからさらにアップリンクを追加する必要があります。 クラスタ設定では、アップリンクを対称設定にすることを推奨します。 この例で、ファブリック インターコネクト 1 つにつき使用されるアップリンクの数が 4 つである場合、16 台のサーバが 80GB の帯域幅を共有することになるため、各サーバの容量は約 5GB になります。 Cisco UCS ファブリック インターコネクトで複数のアップリンクが使用されている場合、この容量を最大限有効活用するために、ネットワーク設計チームはポート チャネルの使用を検討する必要があります。
使用するアップリンク ポートの数とケーブルの本数を増やすことにより、I/O モジュールとファブリック インターコネクトの間の帯域幅を増やすことができます。 Cisco UCS では、I/O モジュールと Cisco UCS 6100 シリーズ ファブリック インターコネクトを接続するために、ケーブルを 1 本、2 本、または 4 本使用できます。 2208 I/O モジュールと 6248 ファブリック インターコネクトを接続する場合、最大 8 本のケーブルを使用できます。 ケーブルの本数により、アクティブ アップリンク ポートの数、およびオーバーサブスクリプションの比率が決定されます。
各サーバで使用可能なオーバーサブスクライブされていない帯域幅の量は、使用する I/O モジュール数と、それらの I/O モジュールをファブリック インターコネクトに接続するために使用するケーブル数によって異なります。 別の I/O モジュールを設置すると、サーバに追加の帯域幅と冗長性が提供されます。 設計のこのレベルの柔軟性により、80 Gbps(それぞれ 4 つのリンクを持つ 2 つの I/O モジュール)から 10 Gbps(1 つのリンクを持つ 1 つの I/O)までの任意の帯域幅をシャーシに提供できます。
シャーシに 80 Gbps を提供する場合、Cisco UCS ドメインの各ハーフ幅サーバが、オーバーサブスクライブされていない設定で最大 10 Gbps に達し、2:1 オーバーサブスクリプションで最大 20 Gbps 使用できます。
ファブリック インターコネクト ポートに対する最適なオーバーサブスクリプション率を概算する場合は、次のガイドラインを考慮してください。
コストとパフォーマンスの優先順位付けは、データセンターによってそれぞれ異なり、オーバーサブスクリプションの設定に直接影響します。 オーバーサブスクリプションにおけるハードウェアの使用方法を計画する場合は、このスライダでデータセンターが位置する場所を知る必要があります。 たとえば、データセンターでコストよりもパフォーマンスを重視する場合は、オーバーサブスクリプションを最小限に抑えることができます。 しかし、ほとんどのデータセンターでは、コストは大きい影響を与える要因であるため、オーバーサブスクリプションは慎重に計画する必要があります。
各サーバで実際に使用されると予想される帯域幅の概算値は、ファブリック インターコネクト ポートへの各サーバの割り当て、およびその結果からポートのオーバーサブスクリプション率を決定するときに重要です。 オーバーサブスクリプションでは、サーバにより消費されるトラフィックの平均値(単位は GB)、設定された帯域幅に対する使用された帯域幅の比率、および帯域幅の使用が上昇する時間を考慮する必要があります。
ネットワーク タイプは、アップリンク ポート上のトラフィックだけに関係します。これは、Cisco UCS 以外のところには、FCoE が存在しないからです。 その他のデータセンター ネットワークは、LAN と SAN トラフィックを区別するだけです。 したがって、ファブリック インターコネクト ポートのオーバーサブスクリプションの概算を行う場合、ネットワーク タイプを考慮する必要はありません。
Cisco UCS でのピン接続は、アップリンク ポートだけに関係します。 イーサネット トラフィック、または FCoE トラフィックをあるサーバから、特定のアップリンク イーサネット ポート、またはアップリンク FC ポートにピン接続することができます。
物理サーバと仮想サーバの両方の NIC および HBA をアップリンク ポートにピン接続する場合、ファブリック インターコネクトからユニファイド ファブリックを制御できるようにします。 この制御により、アップリンク ポートの帯域幅の利用がさらに最適化されます。
Cisco UCS は、ピン グループを使用して、どの NIC、vNIC、HBA、vHBA をアップリンク ポートにピン接続するかを管理します。 サーバにピン接続を設定するには、ピン グループを直接的に割り当てるか、ピン グループを vNIC ポリシーに入れてから、サーバに割り当てられたサービス プロファイルにその vNIC ポリシーを追加します。 サーバ上の vNIC または vHBA からのトラフィックはすべて、I/O モジュールを通って、同じアップリンク ポートに進みます。
サーバ トラフィックはすべて、I/O モジュールを経由して、ファブリック インターコネクトのサーバ ポートへ進みます。 このトラフィックがどのようにピン接続されるかは、シャーシに設定されるリンクの数によって決まります。
ピン接続により、どのサーバ トラフィックが、ファブリック インターコネクトのどのサーバ ポートに進むかが決まります。 このピン接続は固定されています。 変更できません。 したがって、シャーシに対する帯域幅の適切な割り当てを決定する場合、サーバの位置を考慮する必要があります。
(注) |
サーバをスロットに割り当てる前に、ポートからリンクへの割り当てを見直す必要があります。 ケーブルで接続するポートは I/O モジュールのポート 1 およびポート 2 である必要はありません。 ファブリック インターコネクトと I/O モジュールの間のリンク数を変更した場合、トラフィックを再ルーティングするには、シャーシを再認識する必要があります。 |
ポート番号はすべて、この I/O モジュールのファブリック インターコネクト側ポートを参照します。
(注) |
サーバのアダプタがアダプタのポート チャネルをサポートし、それらのチャネルに応じて設定されている場合、次の表に示すように、ポート チャネルは同じリンクにピン接続されます。 シャーシの I/O モジュールがファブック ポート チャネルをサポートし、それらのチャネルに応じて設定されている場合、サーバ スロットは個々のリンクでなくファブリック ポート チャネルにピン接続されます。 |
シャーシのリンク | リンク 1/ファブリック ポート チャネル | リンク 2 | リンク 3 | リンク 4 | リンク 5 | リンク 6 | リンク 7 | リンク 8 |
---|---|---|---|---|---|---|---|---|
1 リンク |
すべてのサーバ スロット |
なし |
なし |
なし |
なし |
なし |
なし |
なし |
2 リンク |
サーバ スロット 1、3、5、および 7 |
サーバ スロット 2、4、6、および 8 |
なし |
なし |
なし |
なし |
なし |
なし |
4 リンク |
サーバ スロット 1 および 5 |
サーバ スロット 2 および 6 |
サーバ スロット 3 および 7 |
サーバ スロット 4 および 8 |
なし |
なし |
なし |
なし |
8 リンク |
サーバ スロット 1 |
サーバ スロット 2 |
サーバ スロット 3 |
サーバ スロット 4 |
サーバ スロット 5 |
サーバ スロット 6 |
サーバ スロット 7 |
サーバ スロット 8 |
ファブリック ポート チャネル |
すべてのサーバ スロット |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
シャーシに I/O モジュールが 2 つある場合、片方の I/O モジュールからのトラフィックは、ファブリック インターコネクトの 1 つに進み、もう 1 つの I/O モジュールからのトラフィックは、2 つめのファブリック インターコネクトに進みます。 1 つのファブリック インターコネクトに 2 つの I/O モジュールを接続できません。
vNIC で設定されたファブリック インターコネクト | サーバ トラフィック パス |
---|---|
A |
サーバ トラフィックはファブリック インターコネクト A に向かいます。 A に不具合が生じた場合、サーバ トラフィックは B にフェールオーバーしません。 |
B |
すべてのサーバ トラフィックはファブリック インターコネクト B に向かいます。 B に不具合が生じた場合、サーバ トラフィックは A にフェールオーバーしません。 |
A-B |
すべてのサーバ トラフィックはファブリック インターコネクト A に向かいます。 A に不具合が生じた場合、サーバ トラフィックは B にフェールオーバーします。 |
B-A |
すべてのサーバ トラフィックはファブリック インターコネクト B に向かいます。 B に不具合が生じた場合、サーバ トラフィックは A にフェールオーバーします。 |
ピン グループおよびアップリンク ポートに対するピン接続における最適な設定を判断する場合、サーバについて予想される帯域幅使用状況を考慮します。 システムに含まれるサーバの一部が大量の帯域幅を使用することがわかっている場合は、必ず、これらのサーバを別のアップリンク ポートにピン接続してください。
Cisco UCS は、Quality Of Service を実装するために、次の方法を提供しています。
Cisco UCS では、Cisco UCS ドメイン内のすべてのトラフィックを処理するために、Data Center Ethernet(DCE)が使用されます。 イーサネットに対するこの業界標準の機能拡張では、イーサネットの帯域幅が 8 つの仮想レーンに分割されています。 内部システムと管理トラフィック用に 2 つの仮想レーンが予約されています。 それ以外の 6 つの仮想レーンの Quality of Service を設定できます。 Cisco UCS ドメイン全体にわたり、これら 6 つの仮想レーンで DCE 帯域幅がどのように割り当てられるかは、システム クラスによって決定されます。
各システム クラスでは、特定のトラフィック タイプのために、帯域幅の特定セグメントが予約されています。 これにより、オーバーサブスクライブされたシステムでも、ある程度のトラフィック管理ができるようになります。 たとえば、ファイバ チャネル プライオリティ システム クラスを設定して、FCoE トラフィックに割り当てられる DCE 帯域幅の割合を決定することができます。
次の表は、設定可能なシステム クラスをまとめたものです。
システム クラス |
説明 |
---|---|
Platinum Gold Silver Bronze |
サービス プロファイルの QoS ポリシーにインクルードできる設定可能なシステム クラスのセット。 各システム クラスはトラフィック レーンを 1 つ管理します。 これらのシステム クラスのプロパティはすべて、カスタム設定やポリシーを割り当てるために使用できます。 |
Best Effort |
ベーシック イーサネット トラフィックのために予約されたレーンに対する Quality Of Service を設定するシステム クラス。 このシステム クラスのプロパティの中にはあらかじめ設定されていて、変更できないものもあります。 たとえば、このクラスには、必要に応じて、データ パケットのドロップを許可するドロップ ポリシーがあります。 このシステム クラスをディセーブルにはできません。 |
ファイバ チャネル |
Fibre Channel over Ethernet トラフィックのために予約されたレーンに対する Quality Of Service を設定するシステム クラス。 このシステム クラスのプロパティの中にはあらかじめ設定されていて、変更できないものもあります。 たとえば、このクラスには、データ パケットが絶対にドロップされないことを保証するドロップなしポリシーがあります。 このシステム クラスをディセーブルにはできません。 |
Quality Of Service(QoS)ポリシーは、vNIC または vHBA に向けた発信トラフィックにシステム クラスを割り当てます。 このシステム クラスにより、このトラフィックに対する Quality Of Service が決定されます。 一部のアダプタでは、発信トラフィックでバーストやレートなど追加の制御を指定することもできます。
vNIC ポリシー、または vHBA ポリシーに QoS ポリシーをインクルードし、その後、このポリシーをサービス プロファイルにインクルードして、vNIC または vHBA を設定する必要があります。
フロー制御ポリシーは、ポートの受信バッファがいっぱいになったときに、Cisco UCS ドメインのアップリンク イーサネット ポートが IEEE 802.3x ポーズ フレームを送信および受信するかどうかを決定します。 これらのポーズ フレームは、バッファがクリアされるまでの数ミリ秒間、送信側ポートからのデータの送信を停止するように要求します。
LAN ポートとアップリンク イーサネット ポートの間でフロー制御が行われるようにするには、両方のポートで、対応する受信および送信フロー制御パラメータをイネーブルにする必要があります。 Cisco UCS では、これらのパラメータはフロー制御ポリシーによって設定されます。
送信機能をイネーブルにした場合、受信パケット レートが高くなりすぎたときに、アップリンク イーサネット ポートはネットワーク ポートにポーズ要求を送信します。 ポーズは数ミリ秒有効になった後、通常のレベルにリセットされます。 受信機能をイネーブルにした場合、アップリンク イーサネット ポートは、ネットワーク ポートからのポーズ要求すべてに従います。 ネットワーク ポートがポーズ要求をキャンセルするまで、すべてのトラフィックはこのアップリンク ポートで停止します。
ポートにフロー制御ポリシーを割り当てているため、このポリシーを変更すると同時に、ポーズ フレームやいっぱいになっている受信バッファに対するポートの反応も変わります。
各 Cisco UCS ドメインには、すべての機能に対して許可されます。 システムの設定方法に応じて、既存の環境への統合を簡単にするために、一部の機能をオプトインするか、これらをオプトアウトするかを決定することができます。 プロセスの変化が起こった場合、システム設定を変更して、オプトイン機能の 1 つまたは両方を加えることができます。
オプトイン機能は次のとおりです。
ステートレス コンピューティングにより、サービス プロファイルを使用して、あるサーバの固有情報を同じ Cisco UCS ドメイン内の別のサーバに適用できます。 サーバの固有情報には、サーバを認識し、Cisco UCS ドメイン内で一意にするための要素が含まれます。 これらの要素のいずれかを変更すると、サーバはブート ステータスのアクセス、使用、実現ができなくなります。
サーバの固有情報を構成する要素は次のとおりです。
ステートレス コンピューティングは、高度に柔軟なサーバを使ったダイナミックなサーバ環境を作成します。 Cisco UCS ドメインの各物理サーバは、それにサービス プロファイルを関連付けるまで匿名のままで、サーバの ID はサービス プロファイルに設定されます。 このサーバでのビジネス サービスが必要なくなったら、このサーバをシャットダウンし、サービス プロファイルのアソシエーションを解除してから、同じ物理サーバについて異なる ID を作成するために別のサービス プロファイルとのアソシエーションを形成します。 この「新しい」サーバは、別のビジネス サービスをホストできます。
ステートレス状態の柔軟性をフルに活用するためには、サーバのオプション ローカル ディスクはスワップ用スペースまたは一時スペースだけに使用し、オペレーティング システムやアプリケーション データの保存には使用しないでください。
Cisco UCS ドメインのすべての物理サーバに対して、ステートレス コンピューティングを完全に実装するように選択することも、ステートレス サーバを使用しないことを選択することもできます。また、これら 2 種類を混在させることも可能です。
Cisco UCS ドメイン内の各物理サーバは、サービス プロファイルによって定義されます。 どのようなサーバでも、あるアプリケーションのセットをホストするために使用しているときに、データセンターの必要に応じて、別のアプリケーションやビジネス サービスのセットに割り当てなおすことができます。
Cisco UCS ドメインで定義されているポリシーやリソースのプールをポイントするサービス プロファイルを作成します。 サーバ プール、World Wide Name(WWN; ワールド ワイド名)プール、および MAC プールにより、未割り当てのリソースはすべて、必要に応じて使用できることが保証されます。 たとえば、物理サーバに障害が発生した場合、別のサーバにすぐにサービス プロファイルを割り当てることができます。 サービス プロファイルは、WWN や MAC アドレスを含め、オリジナルのサーバと同じ ID を新しいサーバに与えるため、データセンター インフラストラクチャの残りの部分では、この新しいサーバとオリジナルのサーバは同じものと認識されます。LAN や SAN で設定を変更する必要はありません。
Cisco UCS ドメイン内の各サーバは、従来のラックマウント型サーバとして扱われます。
ハードウェアに書き込まれた ID 情報を継承するサービス プロファイルを作成し、これらのプロファイルを使用して、サーバに対する LAN または SAN 接続を設定します。 ただし、サーバ ハードウェアに障害が発生した場合、新しいサーバにサービス プロファイルを割り当てることはできません。
マルチテナント機能を使用すると、Cisco UCS ドメインの大規模な物理インフラストラクチャを、組織と呼ばれる論理エンティティに分割することができます。 その結果、各組織に専用の物理インフラストラクチャを設けなくても各組織を論理的に分離できます。
マルチテナント環境では、関連する組織を通じて、各テナントに一意のリソースを割り当てられます。 これらのリソースには、各種のポリシー、プール、および Quality of Service 定義などがあります。 また、すべてのユーザがすべての組織にアクセスできるようにする必要がない場合は、ロケールを実装して、組織ごとにユーザ権限やロールを割り当てたり、制限したりすることもできます。
マルチテナント環境をセットアップする場合、すべての組織は階層的になります。 最上位の組織は常にルートです。 ルートに作成したポリシーおよびプールはシステム全体にわたるもので、このシステムに含まれるすべての組織で使用できます。 しかし、他の組織で作成されたポリシーやプールが使用できるのは、同じ階層でそれより上にある組織だけです。 たとえば、あるシステムに Finance と HR という組織があり、これらは同じ階層に存在しないとします。この場合、Finance は HR 組織にあるポリシーは一切使用できず、また、HR は Finance 組織にあるポリシーには一切アクセスできません。 しかし、Finance と HR は両方とも、ルート組織にあるポリシーやプールを使用できます。
マルチテナント環境に組織を作成する場合、各組織、または同じ階層のサブ組織に次のうち 1 つ以上をセットアップすることもできます。
各 Cisco UCS ドメインは複数の異なる組織に分割されます。 マルチテナント機能の実装で作成される組織のタイプは、企業のビジネス ニーズによって異なります。 たとえば、次の単位を表す組織があげられます。
管理が認可されている組織だけにユーザがアクセスできるように、ロケールを作成することができます。
Cisco UCS ドメインは、ルート組織にすべてのデータが入った単一の論理エンティティのままです。 すべてのポリシーおよびリソース プールは Cisco UCS ドメイン内の任意のサーバに割り当てることができます。
仮想化により、分離して実行する同じ物理マシン上で隣り合わせの複数の仮想マシン(VM)を作成することができます。
各仮想マシンは、仮想ハードウェア(メモリ、CPU、NIC)の独自のセットを持ち、その上でオペレーティング システムと十分に設定されたアプリケーションがロードされます。 オペレーティング システムは、実際の物理ハードウェア コンポーネントに関係なく、一貫性があり正常なハードウェア一式を認識します。
仮想マシンでは、物理サーバ間でのプロビジョニングおよび移動を迅速に行うために、ハードウェアとソフトウェアの両方が単一のファイルにカプセル化されます。 仮想マシンは 1 つの物理サーバから別のサーバへ数秒で移動することができ、メンテナンスのためのダウンタイムを必要とせず、途切れることのない作業負荷を集約します。
仮想ハードウェアは、多数のサーバ(それぞれのサーバは独立した仮想マシン内で実行する)を単一の物理サーバ上で実行できるようにします。 仮想化の利点は、コンピューティング リソースをより適切に使用でき、サーバ密度を高め、サーバの移行をスムーズに行えることです。
仮想サーバの実装は、1 つの物理サーバのゲストとして実行される 1 つまたは複数の VM で構成されます。 ゲスト VM は、ハイパーバイザまたは仮想コンピュータ マネージャ(VMM)と呼ばれるソフトウェア レイヤによってホストおよび管理されます。 通常、ハイパーバイザは各 VM への仮想ネットワーク インターフェイスを示し、VM から他のローカル VM、または別のインターフェイスを介した外部ネットワークへのトラフィックのレイヤ 2 スイッチングを実行します。
Cisco Virtual Interface Card(VIC)アダプタと連動して、Cisco Virtual Machine Fabric Extender(VM-FEX)はファブリック インターコネクトの外部ハードウェアベース スイッチング用のハイパーバイザによって VM トラフィックのソフトウェアベースのスイッチングをバイパスします。 この方法は、サーバの CPU 負荷を軽減し、高速スイッチングを行い、ローカルおよびリモートのトラフィックに豊富なネットワーク管理機能セットを適用します。
VM-FEX は、各 VM インターフェイスに仮想 Peripheral Component Interconnect Express(PCIe)デバイスとスイッチ上の仮想ポートを提供することで、IEEE 802.1Qbh ポート エクステンダ アーキテクチャを VM に拡張します。 このソリューションにより、VM インターフェイスで正確なレート制限を行い、Quality of Service(QoS)が確保されます。
ネットワーク インターフェイス カード(NIC)と統合ネットワーク アダプタによって、標準的な VMware のサーバにインストールされた ESX との統合による仮想環境と、VC から実行されるすべての仮想マシンの管理がサポートされます。
サービス プロファイルを実装すると、1 つのサーバから別のサーバに、サーバの識別情報を簡単に移動できるようになります。 新規サーバをイメージ化すると、ESX はそのサーバを元のサーバのように扱います。
これらのアダプタは、同一サーバ上の仮想マシン間における標準の通信手段を実装します。 ESX ホストが複数の仮想マシンを含む場合、すべての通信はサーバ上の仮想スイッチを通過させる必要があります。
システムでネイティブな VMware ドライバを使用する場合、仮想スイッチはネットワーク管理者のドメインには参加せず、どのネットワーク ポリシーの制約も受けません。 結果として、たとえば、ネットワークの QoS ポリシーは、仮想スイッチを通って VM1 から VM2 に流れるどのデータ パケットにも適用されません。
Nexus 1000 などの別の仮想スイッチがシステムに含まれている場合、その仮想スイッチは、ネットワーク管理者がそのスイッチ上で設定したネットワーク ポリシーに従います。
Cisco VIC アダプタ(Cisco UCS M81KR 仮想インターフェイス カードなど)は、単一 OS の導入と VM ベースの導入の両方に対応するように設計された統合型ネットワーク アダプタ(CNA)です。 VIC アダプタは静的または動的な仮想化インターフェイスをサポートし、最大 128 個の仮想ネットワーク インターフェイス カード(vNIC)を含みます。
VIC アダプタは、VM-FEX をサポートし、仮想マシン インターフェイスを対象に送受信されるトラフィックのハードウェア ベース スイッチングを提供します。
目次
- Cisco Unified Computing System の概要
- Cisco Unified Computing System について
- ユニファイド ファブリック
- Fibre Channel over Ethernet
- リンクレベル フロー制御
- プライオリティ フロー制御
- サーバのアーキテクチャおよび接続性
- サービス プロファイルの概要
- サービス プロファイルによるネットワーク接続
- サービス プロファイルによる設定
- サーバ ID を上書きするサービス プロファイル
- サーバ ID を継承するサービス プロファイル
- サービス プロファイル テンプレート
- ポリシー
- プール
- トラフィック管理
- オーバーサブスクリプション
- オーバーサブスクリプションにおける検討事項
- オーバーサブスクリプションの概算に関するガイドライン
- ピン接続
- サーバ トラフィックのサーバ ポートへのピン接続
- ピン接続に関するガイドライン
- Quality of Service
- システム クラス
- Quality Of Service ポリシー
- フロー制御ポリシー
- オプトイン機能
- ステートレス コンピューティング
- マルチテナント機能
- Cisco UCS の仮想化
- 仮想化の概要
- Cisco Virtual Machine Fabric Extender の概要
- ネットワーク インターフェイス カードと統合ネットワーク アダプタを使用した仮想化
- 仮想インターフェイス カード アダプタでの仮想化
この章の内容は、次のとおりです。
Cisco Unified Computing System について
Cisco Unified Computing System(Cisco UCS)は、アクセス レイヤ ネットワーキングとサーバを融合します。 この高性能次世代サーバ システムは、作業負荷に対する敏捷性およびスケーラビリティの高いデータセンターを実現します。
ハードウェア コンポーネントおよびソフトウェア コンポーネントは、1 つの統合ネットワーク アダプタ上に複数のタイプのデータセンター トラフィックを通過させる、シスコのユニファイド ファブリックをサポートします。
アーキテクチャの単純化
Cisco UCS のアーキテクチャを単純化することにより、必要なデバイスの数を削減し、スイッチング リソースを中央に集中させることができます。 シャーシ内部でのスイッチングを止めると、ネットワーク アクセス レイヤのフラグメンテーションが大きく減少します。
Cisco UCS は、ラック、またはラックのグループでシスコのユニファイド ファブリックを実装し、10 ギガビット シスコ データセンター イーサネット リンクおよび Fibre Channel over Ethernet(FCoE)リンク経由でイーサネットおよびファイバ チャネル プロトコルをサポートします。
この徹底的な単純化により、スイッチ、ケーブル、アダプタ、および管理ポイントの最高 3 分の 2 が削減されます。 Cisco UCS ドメイン内のデバイスはすべて、1 つの管理ドメインの下にとどまり、冗長コンポーネントの使用中、ハイ アベイラビリティを保ちます。
ハイ アベイラビリティ
Cisco UCS の管理およびデータ プレーンはハイ アベイラビリティおよび冗長アクセス レイヤ ファブリック インターコネクトのために設計されています。 さらに、Cisco UCS は、データ レプリケーションやアプリケーションレベルのクラスタ処理テクノロジーなど、データセンターに対する既存のハイ アベイラビリティおよびディザスタ リカバリ ソリューションをサポートします。
拡張性
単一の Cisco UCS ドメインは複数のシャーシおよびそのサーバをサポートします。これらはすべて 1 つの Cisco UCS Manager を通じて管理されます。 スケーラビリティの詳細については、シスコの担当者にお問い合わせください。
柔軟性
Cisco UCS ドメインでは、データセンターのコンピューティング リソースを、急速に変化するビジネス要件にすばやく合せることができます。 この柔軟性を組み込むかどうかは、ステートレス コンピューティング機能の完全な実装が選択されているかどうかによって決定されます。
必要に応じて、サーバやその他のシステム リソースのプールを適用し、作業負荷の変動への対応、新しいアプリケーションのサポート、既存のソフトウェアおよびビジネス サービスの拡張、スケジュール済みのダウンタイムおよび予定されていないダウンタイムの両方への適応を行うことができます。 サーバの ID は、最小のダウンタイムで、追加のネットワーク設定を行わずにサーバからサーバへ移動できるモバイル サービス プロファイルに抽象化することができます。
このレベルの柔軟性により、サーバの ID を変更したり、サーバ、Local Area Network(LAN; ローカル エリア ネットワーク)、または Storage Area Network(SAN)を再設定したりせずに、すばやく、簡単にサーバの容量を拡張することができます。 メンテナンス ウィンドウでは、次の操作をすばやく行うことができます。
ユニファイド ファブリック
ユニファイド ファブリックを使用すると、単一の Data Center Ethernet(DCE; データセンター イーサネット)ネットワーク上で複数の種類のデータセンター トラフィックを行き来させることができます。 さまざまな一連のホスト バス アダプタ(HBA)およびネットワーク インターフェイス カード(NIC)をサーバに搭載させる代わりに、ユニファイド ファブリックは統合された単一のネットワーク アダプタを使用します。 このタイプのアダプタは、LAN および SAN のトラフィックを同一のケーブルで運ぶことができます。
Cisco UCS は、Fibre Channel over Ethernet(FCoE)を使用して、ファブリック インターコネクトとサーバ間をつなぐ同一の物理イーサネット接続でファイバ チャネルおよびイーサネットのトラフィックを運びます。 この接続はサーバ上の統合されたネットワーク アダプタで終端し、ユニファイド ファブリックはファブリック インターコネクトのアップリンク ポートで終端します。 コア ネットワークでは、LAN および SAN のトラフィックは分かれたままです。 Cisco UCS では、データセンター全体でユニファイド ファブリックを実装する必要はありません。
統合されたネットワーク アダプタは、オペレーティング システムに対してイーサネット インターフェイスおよびファイバ チャネル インターフェイスを提示します。 サーバ側では、標準のファイバ チャネル HBA を確認しているため、オペレーティング システムは FCoE のカプセル化を認識していません。
ファブリック インターコネクトでは、サーバ側イーサネット ポートでイーサネットおよびファイバ チャネルのトラフィックを受信します。 (フレームを区別する Ethertype を使用する)ファブリック インターコネクトは、2 つのトラフィックの種類に分かれます。 イーサネット フレームおよびファイバ チャネル フレームは、それぞれのアップリンク インターフェイスにスイッチされます。
Fibre Channel over Ethernet
Cisco UCS は、Fibre Channel over Ethernet(FCoE)標準プロトコルを使用して、ファイバ チャネルを提供します。 上部のファイバ チャネル レイヤは同じであるため、ファイバ チャネル動作モデルが維持されます。 FCoE ネットワーク管理と設定は、ネイティブのファイバ チャネル ネットワークと同様です。
FCoE は、物理イーサネット リンク上のファイバ チャネル トラフィックをカプセル化します。 FCoE は専用のイーサタイプ 0x8906 を使用して、イーサネット上でカプセル化されるため、FCoE トラフィックと標準イーサネット トラフィックは同じリンク上で処理できます。 FCoE は ANSI T11 標準委員会によって標準化されています。
ファイバ チャネル トラフィックには、ロスレス トランスポート層が必要です。 ネイティブ ファイバ チャネルが使用するバッファ間クレジット システムの代わりに、FCoE はイーサネット リンクを使用して、ロスレス サービスを実装します。
ファブリック インターコネクト上のイーサネット リンクは、2 つのメカニズムを使用して、FCoE トラフィックのロスレス トランスポートを保証します。
リンクレベル フロー制御
IEEE 802.3x リンクレベル フロー制御では、輻輳の発生している受信側からエンドポイントに対して、少しの間、データの送信を一時停止するように信号を送ることができます。 このリンクレベル フロー制御では、リンク上のすべてのトラフィックが一時停止します。
送受信方向は個別に設定できます。 デフォルトでは、リンクレベル フロー制御は両方向でディセーブルです。
各イーサネット インターフェイスで、ファブリック インターコネクトは、プライオリティ フロー制御、またはリンクレベル フロー制御のいずれかをイネーブルにできます。両方をイネーブルにはできません。
プライオリティ フロー制御
プライオリティ フロー制御(PFC)機能は、イーサネット リンク上の特定のトラフィック クラスにポーズ機能を適用します。 たとえば、PFC は FCoE トラフィックにロスレス サービスを、標準イーサネット トラフィックにベストエフォート サービスを提供します。 PFC は、(IEEE 802.1p トラフィック クラスを使用して)特定のイーサネット トラフィック クラスに、さまざまなレベルのサービスを提供することができます。
PFC は、IEEE 802.1p の CoS 値に基づき、ポーズを適用するかどうかを判断します。 ファブリック インターコネクトは、PFC をイネーブルにするときに、特定の CoS 値を持つパケットにポーズ機能を適用するように、接続されたアダプタを設定します。
デフォルトでは、ファブリック インターコネクトは、PFC 機能をイネーブルにするかどうかのネゴシエーションを行います。 ネゴシエーションに成功すると、PFC がイネーブルにされますが、リンクレベル フロー制御は(設定値に関係なく)ディセーブルのままです。 PFC ネゴシエーションに失敗した場合は、PFC をインターフェイスで強制的にイネーブルにするか、IEEE 802.x リンクレベル フロー制御をイネーブルにできます。
サーバのアーキテクチャおよび接続性
サービス プロファイルの概要
サービス プロファイルは、Cisco UCS の中心概念です。 各サービス プロファイルにより具体的な目的のサービスが提供されるため、関連付けられたサーバ ハードウェアでホスティングされるアプリケーションをサポートするために必要な設定が確実にハードウェアに設定されます。
サービス プロファイルには、サーバ ハードウェア、インターフェイス、ファブリック接続、およびサーバとネットワークの ID に関する設定情報が保持されます。 この情報は、Cisco UCS Manager を使って管理できる形式で保存されています。 すべてのサービス プロファイルは一元的に管理され、ファブリック インターコネクト上のデータベースに格納されます。
各サーバは、サービス プロファイルと関連付けられる必要があります。
重要:各サーバは、いつの時点においても 1 つのサービス プロファイルだけに関連付けることができます。 同様に、各サービス プロファイルは一度に 1 つのサーバだけに関連付けることができます。
サービス プロファイルをサーバと関連付けると、サーバではオペレーティング システムとアプリケーションをインストールする準備が整います。サーバの設定はサービス プロファイルで確認することができます。 サービス プロファイルとのアソシエーションを形成しているサーバで不具合が発生しても、サービス プロファイルが自動的に別のサーバにフェールオーバーすることはありません。
サーバからサービス プロファイルの関連付けが解除されると、サーバの ID および接続の情報は工場出荷時のデフォルトにリセットされます。
- サービス プロファイルによるネットワーク接続
- サービス プロファイルによる設定
- サーバ ID を上書きするサービス プロファイル
- サーバ ID を継承するサービス プロファイル
- サービス プロファイル テンプレート
サービス プロファイルによるネットワーク接続
各サービス プロファイルは、このサーバについて、Cisco UCS インフラストラクチャを経由して外部ネットワークに接続する LAN および SAN ネットワーク接続を指定します。 Cisco UCS サーバおよびその他のコンポーネントについて、ネットワーク接続を手動で設定する必要はありません。 すべてのネットワーク設定は、サービス プロファイルを通じて行われます。
サービス プロファイルをサーバに関連付けると、サービス プロファイルの情報を使用して Cisco UCS 内部ファブリックが設定されます。 このプロファイルが以前に別のサーバと関連付けられていた場合、ネットワーク インフラストラクチャが再構成され、新しいサーバに対して同じネットワーク接続がサポートされます。
サービス プロファイルによる設定
サービス プロファイルで設定されたハードウェア コンポーネント
サービス プロファイルがサーバに関連付けられているときには、プロファイルのデータに応じて次のコンポーネントが設定されます。
これらのコンポーネントを直接設定する必要はありません。
サービス プロファイルによるサーバ ID 管理
製造元がサーバ ハードウェアに記録したネットワーク ID およびデバイス ID を使用できます。あるいは、関連付けられたサービス プロファイルで指定した ID を直接または MAC、WWN、UUID などの ID プール経由で使用できます。
次の例は、サービス プロファイルに含めることができる設定情報の方法を示しています。
サービス プロファイルによる vNIC 設定
vNIC は物理ネットワーク アダプタで設定される仮想化されたネットワーク インターフェイスであり、サーバのオペレーティング システムに物理 NIC として表示されます。 システムのアダプタの種類によって、作成できる vNIC の数は異なります。 たとえば、統合ネットワーク アダプタには NIC が 2 つあります。つまり、アダプタごとに最大 2 つの vNIC を作成できます。
vNIC はイーサネット上で通信し、LAN トラフィックを処理します。 少なくとも、各 vNIC には名前、ファブリック接続、ネットワーク接続を設定する必要があります。
サービス プロファイルによる vHBA 設定
vHBA とは、物理ネットワーク アダプタ上に設定される仮想化されたホスト バス アダプタのことで、サーバのオペレーティング システムには物理 HBA に見えます。 システムのアダプタの種類に応じて作成できる vHBA の数が決まります。 たとえば、統合ネットワーク アダプタには HBA が 2 つあります。つまり、アダプタごとに最大 2 つの vHBA を作成できます。 他方、ネットワーク インターフェイス カードには HBA がありません。これは、アダプタで vHBA を作成できないことを意味します。
vHBA は FCoE 上で通信し、SAN トラフィックを処理します。 少なくとも、各 vHBA には名前とファブリック接続を設定する必要があります。
サーバ ID を上書きするサービス プロファイル
このタイプのサービス プロファイルにより、柔軟性と制御性が最大化されます。 このプロファイルを使用すると、関連付けの時点でサーバにある ID の値を上書きし、Cisco UCS Manager のリソース プールとポリシー設定を使用して管理タスクの一部を自動化できます。
このサービス プロファイルとサーバの関連付けを解除して、このプロファイルを別のサーバに関連付けることができます。 この再アソシエーションは手動で行うこともできますし、自動サーバ プール ポリシーを通じて行うこともできます。 新しいサーバのハードウェアが持つ UUID や MAC アドレスなどの工場出荷時の設定は、サービス プロファイルの設定で上書きされます。 その結果、サーバでの変更はネットワークには透過的に行われます。 新しいサーバの使用を開始するために、ネットワークでコンポーネントやアプリケーションを再設定する必要はありません。
このプロファイルにより、次のようなリソース プールやポリシーを通じて、システム リソースを利用し、管理できるようになります。
MAC アドレスのプール、WWN アドレス、UUID などの仮想 ID 情報
イーサネットおよびファイバ チャネル アダプタ プロファイル ポリシー
ファームウェア パッケージ ポリシー
オペレーティング システム ブート順序ポリシー
サービス プロファイルに電源管理ポリシー、サーバ プールの資格ポリシー、または個々のハードウェア設定を必要とする別のポリシーが含まれている場合、プロファイルは、Cisco UCS ドメインで、任意のタイプのサーバを使用できます。
これらのサービス プロファイルは、ラックマウント サーバまたはブレード サーバと関連付けることができます。 サービス プロファイルを移行する機能は、サービス プロファイルの移行の制限を選択するかどうかにより異なります。
(注)
移行を制限しない場合は、既存のサービス プロファイルを移行する前に、Cisco UCS Manager による新規サーバに対する互換性チェックは実行されません。 両方のサーバのハードウェアが類似していない場合、アソシエーションが失敗することがあります。
サーバ ID を継承するサービス プロファイル
このハードウェアベースのサービス プロファイルは使用も作成も簡単です。 このプロファイルは、サーバのデフォルト値を使用して、ラックマウント型サーバの管理を模倣します。 このプロファイルは特定のサーバに結び付けられており、別のサーバへの移動または移行はできません。
このサービス プロファイルを使用するために、プールや設定ポリシーを作成する必要はありません。
このサービス プロファイルは、アソシエーション時に存在する次のような ID 情報および設定情報を継承し、適用します。
重要:このプロファイルをサーバに関連付ける前に、製造元でサーバのハードウェアに設定された値が変更された場合、このサービス プロファイルを通じて継承されたサーバの ID および設定情報は、この値とは異なる可能性があります。
サービス プロファイル テンプレート
サービス プロファイル テンプレートにより、同一の基本パラメータ(vNIC および vHBA の数など)や、同じプールから取得された ID 情報が含まれる複数のサービス プロファイルを迅速に作成できます。
ヒント
既存のサービス プロファイルに類似した値が含まれるサービス プロファイルが 1 つだけ必要な場合は、Cisco UCS Manager GUI でサービス プロファイルのクローニングが可能です。
たとえば、サーバをホスト データベース ソフトウェアに設定するために同様の値が含まれた複数のサービス プロファイルが必要な場合は、手作業でも既存のサービス プロファイルからでもサービス プロファイル テンプレートを作成できます。 次に、このテンプレートを使用してサービス プロファイルを作成します。
Cisco UCS は、次のタイプのサービス プロファイル テンプレートをサポートします。
- 初期テンプレート
初期テンプレートから作成されたサービス プロファイルはテンプレートのプロパティをすべて継承します。 しかし、プロファイルの作成後は、テンプレートへの接続が失われます。 このテンプレートから作成された 1 つ以上のプロファイルを変更する必要がある場合は、これらのプロファイルを個別に変更する必要があります。
- アップデート テンプレート
アップデート テンプレートから作成されたサービス プロファイルでは、テンプレートのすべてのプロパティが継承され、テンプレートへのつながりが保持されます。 テンプレートの何らかの変更があると、テンプレートから作成されたサービス プロファイルは自動的にアップデートされます。
ポリシー
ポリシーは、ある特定の状況で、Cisco UCS コンポーネントがどのように動作するかを決定します。 大半のポリシーで複数のインスタンスを作成することができます。 たとえば、サーバに応じて、PXE ブート、SAN ブート、ローカル ストレージからのブートを使い分けられるように、異なるブート ポリシーが必要になる場合があります。
ポリシーにより、システム内で機能を区別することができます。 対象事象のエキスパートは、その対象事象を専門としない他者により作成されたサービス プロファイルで使用されるポリシーを定義できます。 たとえば、LAN アドミニストレータは、そのシステムのアダプタ ポリシー、および Quality Of Service ポリシーを作成できます。 次に、LAN 管理に関する対象事項の専門知識が限られているか、あるいはまったく欠けている他者により作成されたサービス プロファイルで、これらのポリシーを使用できます。
Cisco UCS Manager では、下記の 2 つのタイプのポリシーを作成して使用できます。
プール
プールは、システムで使用できる ID のコレクション、物理リソース、または論理リソースです。 すべてのプールは、サービス プロファイルの柔軟性を高め、ユーザがシステム リソースを中央で集中管理できるようにします。
プールを使用して、未設定のサーバや、使用可能なサーバ ID 情報の範囲を、データセンターにとって意味のあるグループに分割することができます。 たとえば、類似する特性を持つ未設定のサーバのプールを作成して、このプールをサービス プロファイルにインクルードした場合、ポリシーを使用して、このサービス プロファイルと使用可能な未設定のサーバとのアソシエーションを形成することができます。
MAC アドレスなどの ID 情報をプールした場合、特定のアプリケーションをホストするサーバに範囲をあらかじめ割り当てることができます。 たとえば、すべてのデータベース サーバを、同じ範囲の MAC アドレス、UUID、および WWN 内に設定できます。
トラフィック管理
オーバーサブスクリプション
オーバーサブスクリプションは、同じファブリック インターコネクト ポートに複数のネットワーク デバイスが接続されているときに発生します。 ポートが短時間でも最高速度で実行されることはほとんどないため、これにより、ファブリック インターコネクトの使用が最適化されます。 その結果、オーバーサブスクリプションが正しく設定されていれば、使用されていない帯域幅を活用できるようになります。 しかし、オーバーサブスクリプションの設定に間違いがあると、帯域幅のコンテンションが起こり、オーバーサブスクライブ ポートを使用しているすべてのサービスで Quality Of Service が低下します。
たとえば、4 つのサーバが 1 つのアップリンク ポートを共有していて、これらのサーバがすべて、このアップリンク ポートで使用できる帯域幅よりも大きい累積率でデータを送信しようとした場合に、オーバーサブスクリプションが発生します。
オーバーサブスクリプションにおける検討事項
Cisco UCS ドメインでのオーバーサブスクリプションの設定に影響を与える可能性のある要因は次のとおりです。
アップリンク ポートに対するサーバに面したポートの比率
この比率はパフォーマンスに影響を与えるため、システム内のサーバに面したポートの数と、アップリンク ポートの数を知っている必要があります。 たとえば、使用しているシステムに、サーバと通信できるポートが 20 個あるときに、ネットワークと通信できるポートが 2 つだけの場合、このアップリンク ポートはオーバーサブスクライブされます。 この状況では、サーバにより作成されるトラフィックの量もパフォーマンスに影響を与えます。
ファブリック インターコネクトからネットワークへのアップリンク ポートの数
Cisco UCS ファブリック インターコネクトと LAN の上位層の間にさらにアップリンク ポートを追加して、帯域幅を増やすことができます。 Cisco UCS では、すべてのサーバと NIC が確実に LAN にアクセスできるようにするために、ファブリック インターコネクト 1 つにつき、少なくとも 1 つのアップリンク ポートが必要です。 LAN アップリンクの数は、すべての Cisco UCS サーバで使用される帯域幅の合計により決定されます。
6100 シリーズ ファブリック インターコネクトでは、ファイバ チャネル アップリンク ポートは拡張スロットのみで使用できます。 使用可能なファイバ チャネル アップリンクの数を増やすには、拡張スロットを追加する必要があります。 イーサネット アップリンク ポートは、固定スロットと拡張スロットに存在できます。
Cisco UCS Manager バージョン 2.0 以降を実行する 6200 シリーズ ファブリック インターコネクトでは、イーサネット アップリンク ポートとファイバ チャネル アップリンク ポートの両方を、ベース モジュールに加え、拡張ジュール上にも設定できます。
たとえば、2 つの Cisco UCS 5100 シリーズ シャーシに、ハーフ幅の Cisco UCS B200-M1 サーバが最大限に入っている場合、サーバの数は 16 台です。 ファブリック インターコネクト 1 つあたり LAN アップリンクが 1 つのクラスタ設定では、これら 16 台のサーバは 20GbE の LAN 帯域幅を共有します。 より大きい容量が必要である場合、ファブリック インターコネクトからさらにアップリンクを追加する必要があります。 クラスタ設定では、アップリンクを対称設定にすることを推奨します。 この例で、ファブリック インターコネクト 1 つにつき使用されるアップリンクの数が 4 つである場合、16 台のサーバが 80GB の帯域幅を共有することになるため、各サーバの容量は約 5GB になります。 Cisco UCS ファブリック インターコネクトで複数のアップリンクが使用されている場合、この容量を最大限有効活用するために、ネットワーク設計チームはポート チャネルの使用を検討する必要があります。
I/O モジュールからファブリック インターコネクトへのアップリンク ポートの数
使用するアップリンク ポートの数とケーブルの本数を増やすことにより、I/O モジュールとファブリック インターコネクトの間の帯域幅を増やすことができます。 Cisco UCS では、I/O モジュールと Cisco UCS 6100 シリーズ ファブリック インターコネクトを接続するために、ケーブルを 1 本、2 本、または 4 本使用できます。 2208 I/O モジュールと 6248 ファブリック インターコネクトを接続する場合、最大 8 本のケーブルを使用できます。 ケーブルの本数により、アクティブ アップリンク ポートの数、およびオーバーサブスクリプションの比率が決定されます。
サーバからファブリック インターコネクトへのアクティブ リンクの数
各サーバで使用可能なオーバーサブスクライブされていない帯域幅の量は、使用する I/O モジュール数と、それらの I/O モジュールをファブリック インターコネクトに接続するために使用するケーブル数によって異なります。 別の I/O モジュールを設置すると、サーバに追加の帯域幅と冗長性が提供されます。 設計のこのレベルの柔軟性により、80 Gbps(それぞれ 4 つのリンクを持つ 2 つの I/O モジュール)から 10 Gbps(1 つのリンクを持つ 1 つの I/O)までの任意の帯域幅をシャーシに提供できます。
シャーシに 80 Gbps を提供する場合、Cisco UCS ドメインの各ハーフ幅サーバが、オーバーサブスクライブされていない設定で最大 10 Gbps に達し、2:1 オーバーサブスクリプションで最大 20 Gbps 使用できます。
オーバーサブスクリプションの概算に関するガイドライン
ファブリック インターコネクト ポートに対する最適なオーバーサブスクリプション率を概算する場合は、次のガイドラインを考慮してください。
コスト/パフォーマンス スライダ
コストとパフォーマンスの優先順位付けは、データセンターによってそれぞれ異なり、オーバーサブスクリプションの設定に直接影響します。 オーバーサブスクリプションにおけるハードウェアの使用方法を計画する場合は、このスライダでデータセンターが位置する場所を知る必要があります。 たとえば、データセンターでコストよりもパフォーマンスを重視する場合は、オーバーサブスクリプションを最小限に抑えることができます。 しかし、ほとんどのデータセンターでは、コストは大きい影響を与える要因であるため、オーバーサブスクリプションは慎重に計画する必要があります。
ピン接続
Cisco UCS でのピン接続は、アップリンク ポートだけに関係します。 イーサネット トラフィック、または FCoE トラフィックをあるサーバから、特定のアップリンク イーサネット ポート、またはアップリンク FC ポートにピン接続することができます。
物理サーバと仮想サーバの両方の NIC および HBA をアップリンク ポートにピン接続する場合、ファブリック インターコネクトからユニファイド ファブリックを制御できるようにします。 この制御により、アップリンク ポートの帯域幅の利用がさらに最適化されます。
Cisco UCS は、ピン グループを使用して、どの NIC、vNIC、HBA、vHBA をアップリンク ポートにピン接続するかを管理します。 サーバにピン接続を設定するには、ピン グループを直接的に割り当てるか、ピン グループを vNIC ポリシーに入れてから、サーバに割り当てられたサービス プロファイルにその vNIC ポリシーを追加します。 サーバ上の vNIC または vHBA からのトラフィックはすべて、I/O モジュールを通って、同じアップリンク ポートに進みます。
サーバ トラフィックのサーバ ポートへのピン接続
サーバ トラフィックはすべて、I/O モジュールを経由して、ファブリック インターコネクトのサーバ ポートへ進みます。 このトラフィックがどのようにピン接続されるかは、シャーシに設定されるリンクの数によって決まります。
ピン接続により、どのサーバ トラフィックが、ファブリック インターコネクトのどのサーバ ポートに進むかが決まります。 このピン接続は固定されています。 変更できません。 したがって、シャーシに対する帯域幅の適切な割り当てを決定する場合、サーバの位置を考慮する必要があります。
(注)
サーバをスロットに割り当てる前に、ポートからリンクへの割り当てを見直す必要があります。 ケーブルで接続するポートは I/O モジュールのポート 1 およびポート 2 である必要はありません。 ファブリック インターコネクトと I/O モジュールの間のリンク数を変更した場合、トラフィックを再ルーティングするには、シャーシを再認識する必要があります。
ポート番号はすべて、この I/O モジュールのファブリック インターコネクト側ポートを参照します。
1 つの I/O モジュールを持つシャーシ(ファブリック ポート チャネルの場合は設定されません)
(注)
サーバのアダプタがアダプタのポート チャネルをサポートし、それらのチャネルに応じて設定されている場合、次の表に示すように、ポート チャネルは同じリンクにピン接続されます。 シャーシの I/O モジュールがファブック ポート チャネルをサポートし、それらのチャネルに応じて設定されている場合、サーバ スロットは個々のリンクでなくファブリック ポート チャネルにピン接続されます。
シャーシのリンク リンク 1/ファブリック ポート チャネル リンク 2 リンク 3 リンク 4 リンク 5 リンク 6 リンク 7 リンク 8 1 リンク
すべてのサーバ スロット
なし
なし
なし
なし
なし
なし
なし
2 リンク
サーバ スロット 1、3、5、および 7
サーバ スロット 2、4、6、および 8
なし
なし
なし
なし
なし
なし
4 リンク
サーバ スロット 1 および 5
サーバ スロット 2 および 6
サーバ スロット 3 および 7
サーバ スロット 4 および 8
なし
なし
なし
なし
8 リンク
サーバ スロット 1
サーバ スロット 2
サーバ スロット 3
サーバ スロット 4
サーバ スロット 5
サーバ スロット 6
サーバ スロット 7
サーバ スロット 8
ファブリック ポート チャネル
すべてのサーバ スロット
N/A
N/A
N/A
N/A
N/A
N/A
N/A
I/O モジュールを 2 つ持つシャーシ
シャーシに I/O モジュールが 2 つある場合、片方の I/O モジュールからのトラフィックは、ファブリック インターコネクトの 1 つに進み、もう 1 つの I/O モジュールからのトラフィックは、2 つめのファブリック インターコネクトに進みます。 1 つのファブリック インターコネクトに 2 つの I/O モジュールを接続できません。
vNIC で設定されたファブリック インターコネクト サーバ トラフィック パス A
サーバ トラフィックはファブリック インターコネクト A に向かいます。 A に不具合が生じた場合、サーバ トラフィックは B にフェールオーバーしません。
B
すべてのサーバ トラフィックはファブリック インターコネクト B に向かいます。 B に不具合が生じた場合、サーバ トラフィックは A にフェールオーバーしません。
A-B
すべてのサーバ トラフィックはファブリック インターコネクト A に向かいます。 A に不具合が生じた場合、サーバ トラフィックは B にフェールオーバーします。
B-A
すべてのサーバ トラフィックはファブリック インターコネクト B に向かいます。 B に不具合が生じた場合、サーバ トラフィックは A にフェールオーバーします。
Quality of Service
Cisco UCS は、Quality Of Service を実装するために、次の方法を提供しています。
システム クラス
Cisco UCS では、Cisco UCS ドメイン内のすべてのトラフィックを処理するために、Data Center Ethernet(DCE)が使用されます。 イーサネットに対するこの業界標準の機能拡張では、イーサネットの帯域幅が 8 つの仮想レーンに分割されています。 内部システムと管理トラフィック用に 2 つの仮想レーンが予約されています。 それ以外の 6 つの仮想レーンの Quality of Service を設定できます。 Cisco UCS ドメイン全体にわたり、これら 6 つの仮想レーンで DCE 帯域幅がどのように割り当てられるかは、システム クラスによって決定されます。
各システム クラスでは、特定のトラフィック タイプのために、帯域幅の特定セグメントが予約されています。 これにより、オーバーサブスクライブされたシステムでも、ある程度のトラフィック管理ができるようになります。 たとえば、ファイバ チャネル プライオリティ システム クラスを設定して、FCoE トラフィックに割り当てられる DCE 帯域幅の割合を決定することができます。
次の表は、設定可能なシステム クラスをまとめたものです。
表 1 システム クラス システム クラス
説明
Platinum
Gold
Silver
Bronze
サービス プロファイルの QoS ポリシーにインクルードできる設定可能なシステム クラスのセット。 各システム クラスはトラフィック レーンを 1 つ管理します。
これらのシステム クラスのプロパティはすべて、カスタム設定やポリシーを割り当てるために使用できます。
Best Effort
ベーシック イーサネット トラフィックのために予約されたレーンに対する Quality Of Service を設定するシステム クラス。
このシステム クラスのプロパティの中にはあらかじめ設定されていて、変更できないものもあります。 たとえば、このクラスには、必要に応じて、データ パケットのドロップを許可するドロップ ポリシーがあります。 このシステム クラスをディセーブルにはできません。
ファイバ チャネル
Fibre Channel over Ethernet トラフィックのために予約されたレーンに対する Quality Of Service を設定するシステム クラス。
このシステム クラスのプロパティの中にはあらかじめ設定されていて、変更できないものもあります。 たとえば、このクラスには、データ パケットが絶対にドロップされないことを保証するドロップなしポリシーがあります。 このシステム クラスをディセーブルにはできません。
Quality Of Service ポリシー
Quality Of Service(QoS)ポリシーは、vNIC または vHBA に向けた発信トラフィックにシステム クラスを割り当てます。 このシステム クラスにより、このトラフィックに対する Quality Of Service が決定されます。 一部のアダプタでは、発信トラフィックでバーストやレートなど追加の制御を指定することもできます。
vNIC ポリシー、または vHBA ポリシーに QoS ポリシーをインクルードし、その後、このポリシーをサービス プロファイルにインクルードして、vNIC または vHBA を設定する必要があります。
フロー制御ポリシー
フロー制御ポリシーは、ポートの受信バッファがいっぱいになったときに、Cisco UCS ドメインのアップリンク イーサネット ポートが IEEE 802.3x ポーズ フレームを送信および受信するかどうかを決定します。 これらのポーズ フレームは、バッファがクリアされるまでの数ミリ秒間、送信側ポートからのデータの送信を停止するように要求します。
LAN ポートとアップリンク イーサネット ポートの間でフロー制御が行われるようにするには、両方のポートで、対応する受信および送信フロー制御パラメータをイネーブルにする必要があります。 Cisco UCS では、これらのパラメータはフロー制御ポリシーによって設定されます。
送信機能をイネーブルにした場合、受信パケット レートが高くなりすぎたときに、アップリンク イーサネット ポートはネットワーク ポートにポーズ要求を送信します。 ポーズは数ミリ秒有効になった後、通常のレベルにリセットされます。 受信機能をイネーブルにした場合、アップリンク イーサネット ポートは、ネットワーク ポートからのポーズ要求すべてに従います。 ネットワーク ポートがポーズ要求をキャンセルするまで、すべてのトラフィックはこのアップリンク ポートで停止します。
ポートにフロー制御ポリシーを割り当てているため、このポリシーを変更すると同時に、ポーズ フレームやいっぱいになっている受信バッファに対するポートの反応も変わります。
オプトイン機能
各 Cisco UCS ドメインには、すべての機能に対して許可されます。 システムの設定方法に応じて、既存の環境への統合を簡単にするために、一部の機能をオプトインするか、これらをオプトアウトするかを決定することができます。 プロセスの変化が起こった場合、システム設定を変更して、オプトイン機能の 1 つまたは両方を加えることができます。
オプトイン機能は次のとおりです。
ステートレス コンピューティング
ステートレス コンピューティングにより、サービス プロファイルを使用して、あるサーバの固有情報を同じ Cisco UCS ドメイン内の別のサーバに適用できます。 サーバの固有情報には、サーバを認識し、Cisco UCS ドメイン内で一意にするための要素が含まれます。 これらの要素のいずれかを変更すると、サーバはブート ステータスのアクセス、使用、実現ができなくなります。
サーバの固有情報を構成する要素は次のとおりです。
ステートレス コンピューティングは、高度に柔軟なサーバを使ったダイナミックなサーバ環境を作成します。 Cisco UCS ドメインの各物理サーバは、それにサービス プロファイルを関連付けるまで匿名のままで、サーバの ID はサービス プロファイルに設定されます。 このサーバでのビジネス サービスが必要なくなったら、このサーバをシャットダウンし、サービス プロファイルのアソシエーションを解除してから、同じ物理サーバについて異なる ID を作成するために別のサービス プロファイルとのアソシエーションを形成します。 この「新しい」サーバは、別のビジネス サービスをホストできます。
ステートレス状態の柔軟性をフルに活用するためには、サーバのオプション ローカル ディスクはスワップ用スペースまたは一時スペースだけに使用し、オペレーティング システムやアプリケーション データの保存には使用しないでください。
Cisco UCS ドメインのすべての物理サーバに対して、ステートレス コンピューティングを完全に実装するように選択することも、ステートレス サーバを使用しないことを選択することもできます。また、これら 2 種類を混在させることも可能です。
ステーレス コンピューティングをオプトインする場合
Cisco UCS ドメイン内の各物理サーバは、サービス プロファイルによって定義されます。 どのようなサーバでも、あるアプリケーションのセットをホストするために使用しているときに、データセンターの必要に応じて、別のアプリケーションやビジネス サービスのセットに割り当てなおすことができます。
Cisco UCS ドメインで定義されているポリシーやリソースのプールをポイントするサービス プロファイルを作成します。 サーバ プール、World Wide Name(WWN; ワールド ワイド名)プール、および MAC プールにより、未割り当てのリソースはすべて、必要に応じて使用できることが保証されます。 たとえば、物理サーバに障害が発生した場合、別のサーバにすぐにサービス プロファイルを割り当てることができます。 サービス プロファイルは、WWN や MAC アドレスを含め、オリジナルのサーバと同じ ID を新しいサーバに与えるため、データセンター インフラストラクチャの残りの部分では、この新しいサーバとオリジナルのサーバは同じものと認識されます。LAN や SAN で設定を変更する必要はありません。
マルチテナント機能
マルチテナント機能を使用すると、Cisco UCS ドメインの大規模な物理インフラストラクチャを、組織と呼ばれる論理エンティティに分割することができます。 その結果、各組織に専用の物理インフラストラクチャを設けなくても各組織を論理的に分離できます。
マルチテナント環境では、関連する組織を通じて、各テナントに一意のリソースを割り当てられます。 これらのリソースには、各種のポリシー、プール、および Quality of Service 定義などがあります。 また、すべてのユーザがすべての組織にアクセスできるようにする必要がない場合は、ロケールを実装して、組織ごとにユーザ権限やロールを割り当てたり、制限したりすることもできます。
マルチテナント環境をセットアップする場合、すべての組織は階層的になります。 最上位の組織は常にルートです。 ルートに作成したポリシーおよびプールはシステム全体にわたるもので、このシステムに含まれるすべての組織で使用できます。 しかし、他の組織で作成されたポリシーやプールが使用できるのは、同じ階層でそれより上にある組織だけです。 たとえば、あるシステムに Finance と HR という組織があり、これらは同じ階層に存在しないとします。この場合、Finance は HR 組織にあるポリシーは一切使用できず、また、HR は Finance 組織にあるポリシーには一切アクセスできません。 しかし、Finance と HR は両方とも、ルート組織にあるポリシーやプールを使用できます。
マルチテナント環境に組織を作成する場合、各組織、または同じ階層のサブ組織に次のうち 1 つ以上をセットアップすることもできます。
Cisco UCS の仮想化
- 仮想化の概要
- Cisco Virtual Machine Fabric Extender の概要
- ネットワーク インターフェイス カードと統合ネットワーク アダプタを使用した仮想化
- 仮想インターフェイス カード アダプタでの仮想化
仮想化の概要
仮想化により、分離して実行する同じ物理マシン上で隣り合わせの複数の仮想マシン(VM)を作成することができます。
各仮想マシンは、仮想ハードウェア(メモリ、CPU、NIC)の独自のセットを持ち、その上でオペレーティング システムと十分に設定されたアプリケーションがロードされます。 オペレーティング システムは、実際の物理ハードウェア コンポーネントに関係なく、一貫性があり正常なハードウェア一式を認識します。
仮想マシンでは、物理サーバ間でのプロビジョニングおよび移動を迅速に行うために、ハードウェアとソフトウェアの両方が単一のファイルにカプセル化されます。 仮想マシンは 1 つの物理サーバから別のサーバへ数秒で移動することができ、メンテナンスのためのダウンタイムを必要とせず、途切れることのない作業負荷を集約します。
仮想ハードウェアは、多数のサーバ(それぞれのサーバは独立した仮想マシン内で実行する)を単一の物理サーバ上で実行できるようにします。 仮想化の利点は、コンピューティング リソースをより適切に使用でき、サーバ密度を高め、サーバの移行をスムーズに行えることです。
Cisco Virtual Machine Fabric Extender の概要
仮想サーバの実装は、1 つの物理サーバのゲストとして実行される 1 つまたは複数の VM で構成されます。 ゲスト VM は、ハイパーバイザまたは仮想コンピュータ マネージャ(VMM)と呼ばれるソフトウェア レイヤによってホストおよび管理されます。 通常、ハイパーバイザは各 VM への仮想ネットワーク インターフェイスを示し、VM から他のローカル VM、または別のインターフェイスを介した外部ネットワークへのトラフィックのレイヤ 2 スイッチングを実行します。
Cisco Virtual Interface Card(VIC)アダプタと連動して、Cisco Virtual Machine Fabric Extender(VM-FEX)はファブリック インターコネクトの外部ハードウェアベース スイッチング用のハイパーバイザによって VM トラフィックのソフトウェアベースのスイッチングをバイパスします。 この方法は、サーバの CPU 負荷を軽減し、高速スイッチングを行い、ローカルおよびリモートのトラフィックに豊富なネットワーク管理機能セットを適用します。
VM-FEX は、各 VM インターフェイスに仮想 Peripheral Component Interconnect Express(PCIe)デバイスとスイッチ上の仮想ポートを提供することで、IEEE 802.1Qbh ポート エクステンダ アーキテクチャを VM に拡張します。 このソリューションにより、VM インターフェイスで正確なレート制限を行い、Quality of Service(QoS)が確保されます。
ネットワーク インターフェイス カードと統合ネットワーク アダプタを使用した仮想化
ネットワーク インターフェイス カード(NIC)と統合ネットワーク アダプタによって、標準的な VMware のサーバにインストールされた ESX との統合による仮想環境と、VC から実行されるすべての仮想マシンの管理がサポートされます。
仮想マシンのポータビリティ
サービス プロファイルを実装すると、1 つのサーバから別のサーバに、サーバの識別情報を簡単に移動できるようになります。 新規サーバをイメージ化すると、ESX はそのサーバを元のサーバのように扱います。
同一サーバ上の仮想マシン間の通信
これらのアダプタは、同一サーバ上の仮想マシン間における標準の通信手段を実装します。 ESX ホストが複数の仮想マシンを含む場合、すべての通信はサーバ上の仮想スイッチを通過させる必要があります。
システムでネイティブな VMware ドライバを使用する場合、仮想スイッチはネットワーク管理者のドメインには参加せず、どのネットワーク ポリシーの制約も受けません。 結果として、たとえば、ネットワークの QoS ポリシーは、仮想スイッチを通って VM1 から VM2 に流れるどのデータ パケットにも適用されません。
Nexus 1000 などの別の仮想スイッチがシステムに含まれている場合、その仮想スイッチは、ネットワーク管理者がそのスイッチ上で設定したネットワーク ポリシーに従います。