Cisco UCS Manager

Cisco UCS Manager の設定 一般的な手法とクイック スタート ガイド

ホワイト ペーパー





Cisco UCS Manager の設定
一般的な手法とクイック スタート ガイド



Cisco Unified Computing System の概要


2009 年 6 月に Cisco Unified Computing System™(Cisco UCS™)が発表され、データセンターとサーバ管理に新しいパラダイムが生まれました。今日、Cisco UCS は 1 万社を超えるお客様に使用されています。パラダイムはすでに多くの方に知っていただくことができ、多くのお客様が、初めてあるいはシステム更新する際に導入する製品として Cisco UCS を選択されています。このガイドは、Cisco UCS の重要事項と一般的な手法について簡単にまとめたものです。また、Cisco UCS の基本的価値観の基盤となっている、ステートレスサーバ SAN ブート環境でスムーズに作業する方法についても取り上げます。このガイドでは、ユーティリティ コンピューティング モデルまたはクラウド コンピューティング モデルをサポートするために、Cisco UCS 管理モデル内の概念や要素を数多く紹介しています。これらは、データセンターの運営者がデータセンターの自動化を推進し、その応答性と効率を向上させるのに役立つと考えられます。

このホワイト ペーパーの末尾には、接続と初期設定を簡潔にまとめた「Cisco UCS クイックスタート ガイド」を収録しています。

Cisco UCS の設計目標

Cisco UCS は、管理および運用制御性を向上させ、データセンター環境を改善するために設計されました。目標は、管理ポイントを減らしながら、多数の論理および物理両方のコンピューティング リソースに対する管理の拡張性と範囲を広げることです。まとめると、次のようになります。

  • 管理ポイントの削減
  • 管理制御性の向上

もう 1 つの設計目標は、ハードウェア状態の抽象化を使用した可用性の向上です。サービス プロファイルにより、Cisco UCS におけるステートレスなユーティリティ コンピューティング モデルの基盤が形成されます。何年もにわたり、MAC アドレスと World Wide Port Name(WWPN)識別子の仮想化は業界全体で進化を遂げてきました。しかし、UCS では、論理的に定義できるサービス プロファイルにおいて、これらの情報に加えて、アダプタおよび BIOS バージョンのハードウェア レイヤと、最下層の BIOS および CPU 設定が含めるように拡張することで、この進化をさらに押し進めています。

物理および論理サーバ両方のプロビジョニング時間の削減も、主要な設計目標の 1 つです。

Cisco UCS は、サーバ ドメイン コントローラとして見なすことができます。従来のブレード シャーシでは 1 つのシャーシに搭載可能な範囲の最大 16 台程度のブレード サーバ ドメイン コントローラとしての役割を果たしますが、Cisco UCS では、多数の物理シャーシを(ラックサーバも)含めることができ、1 つの大きな仮想シャーシとして、同様のコントローラを提供します。これは、従来の設定および管理ポイントを個別のシャーシから取り除き、その設定情報をアクセス層で展開させることで実現しています。このアクセス層は UCSM インスタンスまたはドメインを定義するクラスタ化された Cisco ファブリック インターコネクト(FI)のペアであり、Cisco UCS Manager(UCSM)はこの層に組み込まれた状態で動作します。シャーシには状態や設定、またはシャーシを中心とした管理ポイントがないので、管理ポイントを増やさずに、ドメインを多数のシャーシに拡張することができます。管理と設定は、シャーシ レベルではなく、ドメイン レベルで行われます。

Cisco UCS 自体では提供されないもの(他ソフトウェア、ソリューションなどと連携が必要なもの)。

  • サーバ プロビジョニングそのものの提供フレームワーク
  • サービス オーケストレーションやワークフロー エンジン
  • SAN や LAN デバイスの上位接続デバイス自体の管理
  • 仮想マシンの管理
  • ドメイン のペア(東サイト・西サイトなど別ドメイン)に対する一括・透過的な管理

(なお、これらの機能の一部は今後の UCS Manager で強化される項目があります)

Cisco UCS Manager の初期設定


Cisco UCS の初期設定は、シリアル コンソールから行います。はじめに、ウィザードに従って標準的な質問(ホスト名、IP アドレス、ネットマスク、デフォルト ゲートウェイなど)に答えていきます。

標準的な手順


標準的な手順は次のとおりです。

  • 最初にすべての配線を行います。これには、FI の 「L1」および「L2」ポートを使い A 側と B 側をつないでクラスタを形成することも含みます。
  • 管理サブネットの 3 つの IP アドレスを割り当てます。各ファブリック インターコネクトに 1 つずつ割り当て、残りの 1 つは、Cisco UCS Manager インスタンスを定義して管理を有効にする仮想 IP インターフェイスに割り当てます。このとき、どの FI がプライマリ1 デバイスとして機能するかは関係ありません。
  • 「-A」および「-B」の文字がホスト名の末尾に自動的・暗黙的に追加されます(明示的に指定することはできません)。

設定の多くは「A」側で行います。「クラスタ設定」が検出されると、「B」側のインターコネクト設定は(「A」側の設定から)合理一括化されます。

この最初のセットアップ ウィザードを実行後は、ブラウザで UCS 管理 IP アドレスを指定することにより、UCSM GUI からすべてを簡単に管理することができます。

以降のセクションでは、一般的な管理・設定操作の前に実行すべきステップを説明します。

シャーシ検出ポリシーの設定

シャーシ検出ポリシーでは、I/O モジュール(IOM)と FI の間の最小接続数を指定します。この値は明示的に設定する必要があります。この値は [Equipment] タブで設定します。[Equipment] を選択してから [Policies] > [Global Policies] の順に選択し、図 1 のようにポリシーを設定します。

図 1 シャーシ検出ポリシー

図 1 シャーシ検出ポリシー


サーバとアップリンク ポートの有効化

FI はネットワーク アクセス デバイスをまとめています。FI には、シャーシ IOM へ向かう下位方向接続と、コア LAN または SAN へ向かう上位方向接続があります。シャーシ IOM へ向かう下位方向のポートは「サーバ ポート」として設定され、コア LAN へ向かう上位方向のポートは「アップリンク ポート」として設定されます。図 2 に示すように、FI を選択し、必要なポートを右クリックすることによって、ポートを設定して有効にすることができます。

図 2 ファブリック インターコネクト ポートの設定と有効化

図 2 ファブリック インターコネクト ポートの設定と有効化


主な利点の 1 つは、サーバ プロビジョニングにかかる時間が削減できます。シャーシを追加する場合、ラックへの搭載・固定、配線が完了すると、サーバ ポートが設定され、Cisco UCS Manager は自動的に後から追加された機器のインベントリと詳細な検出を実施するので、手動の操作は必要ありません。新たに接続されたシャーシの数にかかわらず、検出プロセスで同時にすべてのシャーシを検出し、[Equipment] タブの情報ツリーに物理リソースを配置するまで約 10 分で終了します。

管理 IP アドレス プールの作成

Cisco UCS は、ブレードごとにアウトオブバンド(外部)アクセス(リモートのキーボード、ビデオ、マウス(KVM)および リモートの CD、DVD、USB アクセス)を提供します。このアクセスは、各ブレードの Baseboard Management Controller(BMC) に対応するカット スルー インターフェイスの IP アドレス プールを関連付けることによって可能になります。一般的に、これらのアドレスは UCS Manager の IP アドレスと同じ管理サブネットで設定されます。このプールは、[Admin] タブで管理 IP プールを選択することによって作成されます。これらのアドレスとブレードの結び付けは自動的に行われ、手動の操作は必要ありません。

ホスト ファームウェア パッケージの作成(ベスト プラクティス)

Cisco UCS では、最下層の BIOS およびアダプタ ファームウェアを「ホスト ファームウェア パッケージ」というグループにまとめて、このグループを論理サーバ(サービス プロファイル)と関連付けることができます。このモデルは、従来のサーバ モデルから大きな変化を遂げています。BIOS とアダプタ ファームウェアのバージョンは、論理サーバ(サーバ プロファイル)定義の一部として指定および関連付けられるプロパティとなります。このモデルは、他で説明されている「ステートレス サーバ」モデルとは異なります。いわゆる他の「ステートレス サーバ」モデルは、UCS ほどの詳細レベルまで抽象化されておらず、物理サーバの BIOS およびアダプタ ファームウェアのバージョンを制御できません。さらに、UCS のホスト ファームウェア パッケージはUCSM ファームウェアのバージョンと構造的に連携をとる必要がないため、ファームウェアバージョンと同期させる必要がありません。2

ベスト プラクティスとしては、初期設定およびセットアップ(または、UCSM のファームウェア アップグレード)で、UCSM バージョンに対応した、ホスト ファームウェア パッケージを作成することです。

Cisco UCS Manager には、すべての主要なハードウェア コンポーネントのファームウェア バージョンを、迅速かつ簡単にレポートする機能があります。図 3 に示すように、[Equipment] タブの [Equipment] を選択してから、[Firmware Management] > [Installed Firmware] の順に選択します。一般には、IOM、FI、および UCS Manager は同じバージョンである必要があります。アダプタ カード、BIOS、および Cisco® Integrated Management Controller(CIMC)のバージョンは、通常、関連するサービス プロファイルのホスト ファームウェア パッケージによって決まります。

図 3 すべての主要なハードウェア コンポーネントのファームウェアに関するレポート

図 3 すべての主要なハードウェア コンポーネントのファームウェアに関するレポート


この時点で、すべてのハードウェアが物理的機器として使用できるようになっているはずです。しかし、Cisco UCS の真の力は、アプリケーションレベルのサーバ(サービス プロファイル)を作成して設定し、物理ハードウェアにそれらを「関連付ける」方法にあると言えます。

ステートレス サーバを使用したクラウド コンピューティングのための機能


動的なクラウド コンピューティング モデルの構築を必要とするデータセンターのために、Cisco UCS はステートレス サーバ環境をサポートするインフラストラクチャを提供しています。ステートレス サーバは、従来のハードウェア識別子(World Wide Node Names(WWNN)、World Wide Port Name(WWPN)、MAC アドレスなど)をサービス プロファイル識別情報の重要な一部分として保持しながら、物理サーバまたはブレード上で動作する論理サーバ(OS およびアプリケーション イメージ)となります(図 4)。

図 4 Cisco UCS の論理的構成要素

図 4 Cisco UCS の論理的構成要素


サービス プロファイルの基盤は、プールやポリシーといった論理的構成要素であり、これらを要素化して再利用することができます。さらに、仮想ネットワーク インターフェイス カード(vNIC)および仮想ホスト バス アダプタ(vHBA)テンプレートは、高位レベルのサービス プロファイル テンプレートとして参照させることができます。サーバ プロビジョニングにかかる時間を短縮するために、このサービス プロファイル テンプレートを使用することで、インスタンス化する実際のサービス プロファイルを迅速に作成できます(これらのインスタンス化されたサービス プロファイルは、実際の物理サーバおよびブレードに自動的に関連付けるようにすることも可能です)。

これらの内部での構成要素は、すべて合理化および標準化されます。高位のオブジェクト(vNIC など)は、低位レベル オブジェクト(プールやポリシーなど)を参照することによって作成できます。この標準化されたデータ モデルによって再利用が促進され、共通オブジェクトを重複して存在させる必要がなくなります。

プール


プールは、ハードウェア リソースを一意に識別するための基本構成要素です。UCS 管理モデルの基盤として、プールはサービス プロファイルを任意のブレードに関連付けることができ、アップストリーム LAN または SAN に対しては同一の ID とプレゼンテーションを提供します。ベスト プラクティスの一部として使用されるプールは次の 3 セットです。

  • WWNN および WWPN プール:サーバ上のファイバ チャネル リソースに一意の ID を提供(ファイバ チャネル ノードおよびポート)
  • MAC アドレス プール:ネットワーク インターフェイス ポートに一意の ID を提供
  • UUID プール:シリアル番号またはサービス タグに類似した ID を提供。特に VMware によって使用される。

GUI でこれらのプールはすべて編成できる機能をもっており、UUID プールは [Server] タブから、WWNN および WWPN プールは [SAN] タブから、MAC アドレス プールは [LAN] タブから管理します。

ベスト プラクティス:マルチドメイン管理

Cisco UCS 管理ドメインは、他の UCSM ドメインや、Cisco UCS サーバ以外のサーバと共存させることが可能であり、すべてのドメインは、一意となるハードウェア識別子とプールの独自のセットを所有できます。LAN または SAN で主要となる重複した WWN や MAC アドレスを使用することは、管理者およびオペレータにとって問題の原因となります。そのため、ベスト プラクティスでは、集中化させた単一のカタログまたは一意となる ID(MAC アドレス、WWNN、WWPN、および UUID)のしくみをとります。このようなスキームは、各 Cisco UCS やその他の管理ドメインよりも上位の、中央レベルで定義および管理する必要があります。ベスト プラクティスでは、WWNN、WWPN、MAC アドレス、および UUID レンジの上位バイトに一意のドメイン ID を組み込みます(たとえば 00:25:B5:03:XX:YY の場合、00:25:B5 は Cisco UCS を、:03 はドメイン 3 を指します)。

ベスト プラクティス:プール

標準的な方法として、プールを定義して使用します。次のことを確認してください。

  • サービス プロファイルの作成時に UUID プールが参照される
  • vNIC の作成時に MAC アドレス プールが参照される
  • サービス プロファイルの作成時に WWNN プールが参照される
  • vHBA の作成時に WWPN プールが参照される

同様に、対応するテンプレート オブジェクト(vNIC、vHBA、およびサービス プロファイル)を作成する際にも、プールを参照する必要があります。

プール管理の検討時には、トレードオフが存在します。多くの環境では、それぞれのデフォルト プールを設定して使用することが最も単純であり、十分な結果が得られます。この方法を使用すると、設定や管理が必要なオブジェクト数が少なくなります。別の方法としては、オペレータはテナントまたはアプリケーションごとに異なるプールを設定・使用することもできます。この方法は、より明確な ID 管理と、テナントやアプリケーションなどのより詳細なトラフィック モニタリングが可能になります。

ポリシー


ポリシーはルールを適用するための主要なメカニズムであり、一貫性と再現性の確保に役立ちます。包括的なポリシー セットを定義して使用することにより、一貫性、制御性、予測可能性を高め、自動化を促進できます。通常使用すべき、最も一般的なポリシーを次に挙げます。

起動(ブート)ポリシー

起動ポリシーは、サーバの起動方法を決定するものであり、ブート デバイス、方法、起動順序を指定します。

従来の SAN ブートを使用する場合、SAN ブートを実行する各サーバ毎に手動で設定する必要があります。一般的には、SAN ブートを100 台のサーバで使用する場合、100 台のサーバに対して手動で個別に設定する必要があります。Cisco UCS では、この扱いにくいモデルが一変します。UCS で必要な設定は、SAN ブートを使用するサーバの数にかかわらず、SAN ブート イメージを提供するストレージ アレイの数に応じた設定だけです。1 つのストレージ アレイの WWPN を含む、単一の起動ポリシーは、任意の数のサーバが参照し、再利用することができます。追加の手動設定は必要ありません。

Cisco UCS の基本的な価値を SAN ブートでより多く活かすことができます。したがって、起動ポリシーにおいてSAN ブートを使用することは、非常に強く推奨されるベスト プラクティスです。

推奨されるプラクティス:起動ポリシー

  • 緊急時の備えやリカバリ モードでの起動のため、起動順の一番目は CD-ROM とする
  • SAN ブートの場合、ブート LUN を提供するストレージ アレイごとに、異なる起動ポリシーを定義する。
  • ネットワーク ブートの場合、起動順は SAN ブートまたはローカル ブート、最後に vNIC デバイスを定義する。

ホスト ファームウェア ポリシー

すでに説明したように、BIOS、アダプタ ROM、またはローカル ディスク コントローラの認定バージョンあるいは代表的なバージョンを論理サービス プロファイルと関連付けるには、ホスト ファームウェア ポリシーを使用します。ベスト プラクティスは、一般的な Cisco UCS Manager ソフトウェア リリースと一致する最新パッケージに基づいて 1 つのポリシーを作成し、作成するすべてのサービス プロファイルとテンプレートについて、ホスト ファームウェア パッケージを参照することです。このベスト プラクティスは、サーバの最下層のファームウェアにおけるバージョンの一貫性を確保します。ただし他のブレード上のサービス プロファイルが関連付け直されることがあり物理サーバ エラーが発生することがあります。

ローカル ディスク ポリシー

ローカル ディスク ポリシーは、ブレード上のローカル ディスクの設定方法を指定します。ベスト プラクティスは、SAN ブート環境ではローカル ストレージを指定しないことにより、サービス プロファイルの関連付けを行う際に問題が発生するのを防ぎます(インストール時にはローカル ディスクがホスト OS としての役割を果たすことがあります)。さらに確実に問題を避けるために、ブレード(特に OS インストール時に使用されたブレード)からローカル ディスクを完全に削除または除外することもできます。

スクラブ(終了破棄の時)ポリシー

スクラブ ポリシーは、サービス プロファイルの分離時に、ローカル ディスクと BIOS に対して行われる処理を決定するものです。デフォルトのポリシーはスクラブなしです。特にサービス プロバイダー、マルチテナントのお客様、ローカル ディスクへのネットワーク インストールが使用されている環境では、ローカル ディスクをスクラブするようにポリシーを設定するのがベスト プラクティスです。

BIOS ポリシー

BIOS ポリシーは、起動時のコンソールを使用してアクセス可能な、非常に特殊な CPU 設定の制御が有効になります。VMware および仮想環境において、CPU サポートに依存するインテル バーチャライゼーション テクノロジーの対応ポリシーを作成することが可能で、サーバプロビジョニングにおける手動操作は必要ありません。同様に、インテル ターボ ブースト またはハイパースレッディングの影響を受けるアプリケーションでは、図 2 に示すように、専用の BIOS ポリシーを参照・適応させることができます。

図 5 BIOS ポリシー

図 5 BIOS ポリシー


分離


Cisco UCS は、以下のオブジェクトに関する分離要件に対応します。

  • VLAN:ネットワークベースの分離機能を提供する。VLAN は上位接続 LAN スイッチ上に作成され、使用可能を宣言します(UCS は VLAN を作成しません)。宣言された VLAN は、vNIC または vNIC テンプレートが作成された場合に参照させることができます。
  • VSAN:対応するストレージベースの分離機能を提供する。VSAN は上位接続 SAN スイッチ上に作成され、使用可能を宣言します(UCS は VSAN を作成しません)。vHBA または vHBA テンプレートを作成した場合に、宣言された VSAN を参照させることができます。VLAN とは異なり、vHBA は単一の VSAN のみと関連付けることができます。
  • ピン グループ:ネットワークおよびストレージ トラフィックの特定の上位接続 インターフェイスに対し、分離機能を提供する。ピン グループを定義したら、所定の vNIC または vHBA(またはテンプレート)のターゲット データ パスとして参照させ、所定の vNIC または vHBA と関連付けられているすべてのトラフィックが、規定の物理アップリンク ポートに分離されるようにします。

テンプレート


Cisco UCS Manager はプライマリ オブジェクト(vNIC、vHBA、およびサービス プロファイル)のテンプレートを提供することにより、再利用と迅速な導入を容易にします。

ベスト プラクティス:テンプレート

  • 適切なレベルの制御と定義のために、サービス プロファイル テンプレートの作成時、GUI のエキスパート モードを使用する。
  • テンプレートを作成する際は、以前に定義した下位のプールおよびポリシーを活用する。

vNIC および vHBA テンプレート

vNIC および vHBA リソースは、常に特定の FI(A 側または B 側のファブリック インターコネクト)と関連付けられます。一般的なサービス プロファイルには、少なくとも 2 つの vNIC と 2 つの vHBA(各側に 1 バウンド)が含まれています。vNIC(または vHBA)テンプレートを使用すると、MAC アドレス プール(または WWPN プール)の関連付けとファブリック ID の両方をカプセル化することができます。

ベスト プラクティス:vNIC および vHBA テンプレート

再利用可能な vNIC および vHBA テンプレートを作成します。これらのテンプレートでは、名前の末尾に fc0-A などを付与することや、広く受け入れられている規則(A 側に偶数のインターフェイス、B 側に奇数のインターフェイス、など)を使用して行われます。

図 6 に示すように、vNIC テンプレートは、VLAN マッピングなどの重要なセキュリティ定義を含むアプリケーション固有のネットワーク プロファイルとして見なす必要があります。

図 6 vNIC テンプレート

図 6 vNIC テンプレート


可用性のオプション

ネットワークの可用性は、次のいずれかによって提供されます。

  • [Enable Failover] を選択する。これにより、ハードウェア アダプタ レベルでの可用性が提供され、一方のファブリック(FI または IOM)のみがダウンしても、サービスは中断されません。
  • ネットワーク インターフェイス カード(NIC)のチーミングまたは NIC ボンディングを使用する。これにより、ホスト OS レベルの可用性が提供されます。

ストレージの可用性は、ホスト側のマルチパス化によってのみ提供されます。ハードウェア フェールオーバーは vHBA のオプションではありません。

ベスト プラクティス:ネットワークの可用性

ネットワークの可用性を向上させるには、ハードウェア フェールオーバーまたは NIC チーミング(またはボンディング)を使用しますが、両者を同時に使用することはできません。

vNIC および vHBA テンプレートを定義したら、図 7 に示すように、エキスパート モードから [Use LAN Connectivity Template] または [Use SAN Connectivity Template] を選択することにより、サービス プロファイルの作成で参照できます。

図 7 LAN 接続テンプレート

図 7 LAN 接続テンプレート


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

サービス プロファイル テンプレートは、すべて下位の要素(プール、ポリシー、vNIC および vHBA テンプレート)を連携させる手段を提供します。サービス プロファイル テンプレートを作成すると、容易かつ迅速にインスタンス化し、サーバ プロビジョニングを実施することができます。

Cisco UCS には「Initial(初期)」(デフォルト)および「Updating(更新)」の 2 タイプのテンプレートがあります。テンプレートが作成され、サービス プロファイルがインスタンス化されると、テンプレートのタイプがその後の更新動作と機能に影響を与えます。サービス プロファイルに対して特定のローカル変更が必要な場合、「初期」テンプレートから作成されたサービス プロファイルは、そのテンプレートからアンバインドする必要があります。また、初期テンプレートに対する変更は新たにインスタンス化されたサービス プロファイルのみに反映されます(過去にインスタンス化されたサービス プロファイルには反映されません)。

更新テンプレート:使用には注意が必要

更新テンプレートは、テンプレートとインスタンス化されたオブジェクト(vNIC、vHBA、またはサービス プロファイル)の関係を保持するという、非常に強力な機能を提供します。この機能の目的は、一貫性を確保し、規模に応じて設定変更を伝播します。例として

  • 多数のサーバに対し、ホスト ファームウェア パッケージのバージョン(BIOS を含む)を更新する
  • VMware ESX クラスタ内のすべてのサーバに新しい VLAN をマップする

ただし、更新テンプレートを使用して変更を反映すると、BIOS ポリシーやホスト ファームウェア パッケージに対する更新などのサービスが中断される場合があります。このようなサービスの中断は、ユーザの確認や予定されたメンテナンス ウィンドウに基づいて有効になるメンテナンス ポリシーを使用して、スケジュールすることができます。それでも、更新テンプレートを使用する際には最大の注意を払う必要があります。更新テンプレートは、予定されたメンテナンス期間中のかなりの時間を節約することができます。ただし、通常動作時に意図せず更新が発生すると、莫大な被害が発生します。

サービス プロファイル テンプレートは、物理的な接続の制約にとらわれることなく、所定のサービスまたはアプリケーションのすべてのサービス レベルの属性をカプセル化および形式化するのに最適です。

ベスト プラクティス:サービス プロファイル テンプレート

サービス プロファイル テンプレートは、アプリケーション、サービス、またはオペレーティング システムのクラスまたはタイプの定義として使用します。

SAN のインストールおよび起動に関する重要事項


Cisco UCS の中心的価値の 1 つであるステートレスサーバ モデルは、SAN ブートに基づいています。ローカル ディスクから起動する場合、サーバ イメージのモビリティは実現されません。高い信頼性をもち、一貫した、繰り返し利用可能な SAN ブート環境を準備するには、いくつかの考慮事項があります。一般的なベスト プラクティスを以下に紹介します。

可用性を高めるための起動ポリシーの設定

図 8 に示すように、起動ポリシーは、プライマリおよびセカンダリ vHBA と、プライマリおよびセカンダリ ストレージ パスからの起動を可能にします。

図 8 起動ポリシー

図 8 起動ポリシー


サービス プロファイル WWPN に注目

サービス プロファイルの WWPN は、SAN スイッチ(ゾーン分割)および SAN ストレージ アレイ(LUN マスキング)の両方を統合するために最も大切な要素です。図 9 は、WWPN プール要素と、それに対応するサービス プロファイルの間のマッピングを示しています。

図 9 WWPN プール要素とサービス プロファイルのマッピング

図 9 WWPN プール要素とサービス プロファイルのマッピング


注目点は物理サーバとの関連付けには依存していない点です。実際、事前設定のプロビジョニングはよく使用される方法であり、対応する物理サーバが指定する前に、SAN インフラストラクチャ(ゾーン分割と LUN マスキング)をすべて設定することができます。

単一イニシエータ ゾーン分割の使用(オープン ゾーンを使用しない)

すべてのストレージ アレイ ポートと vHBA WWPN が同一 VSAN 上にあり、同じゾーンに配置されていることを確認します。ベスト プラクティスでは、単一イニシエータ ゾーン分割を使用します。 すべての vHBA WWPN とストレージ アレイ ポートを、1 つのオープン ゾーンに配置してはいけません。

ファイバ チャネル スイッチのネーム サーバを使用した接続の確認

サーバ プロファイルとブレードを関連付けた後は、SAN ネーム サーバから、Cisco UCS FI と SAN が適切な接続状態かどうか確認できます。Cisco Nexus® および Cisco MDS 9000 ファミリ スイッチでは、コマンドライン インターフェイス(CLI)の show flogi database コマンドを使用して実行します。ファイバ チャネル ファブリックにログインしているすべてのポートが表示されます。必要な vHBA および WWPN がテーブルに表示されない場合は、UCSM 設定の問題が考えられます(たとえば、サービス プロファイルが適切に関連付けられなかった、必要な vHBA または WWPN がサービス プロファイルによって参照されなかった、FI および SAN スイッチが正しく配線されなかった、など)。

異種ストレージ アレイ タイプの混在の回避

ストレージ アレイが正確な LUN マッピングを提供できず、どの LUN 番号をホストに提示するかを指定できない場合には特に、SAN ブート環境でストレージ アレイ タイプを混在させると問題が発生する可能性があります。一般的に、サーバは LUN 0 から起動します。複数のストレージ アレイが複数の LUN 0 のインスタンスを示す場合、結果は解決できなくなります。

うまくいかない場合

SAN ブートの問題を解決するには、通常、SAN スイッチ、ストレージ アレイ、サーバの 3 つの関係する要素すべてを診断する必要があります。一般的な役立つテクニックを次に示します。

  • ブート時診断を表示するには、BIOS ポリシーの Quiet Boot を無効にする。
  • アップストリーム SAN スイッチが有効になっており、NPIV に設定されていることを確認する。
  • OS インストール時に、ブレードからローカル ディスクを削除または除外する。

表 1 一般的な SAN ブートの問題

状況 考えられる問題の原因
vHBA またはストレージ アレイがファイバ チャネルのネーム サーバに存在しない
  • 物理的な配線が誤っている。
  • FI 上のポートまたは SAN スイッチが有効になっていない。
vHBA はネーム サーバで確認できるが、ストレージ アレイからは確認できない
  • ゾーンまたは VSAN の設定に誤りがある。
  • ストレージ アレイの配線が適切でないか、ゾーンまたは VSAN における設定が誤っている。
ストレージ アレイは vHBA オプションの ROM から確認できるが、LUN は EMC の「LUNZ」として表示されない LUN マスキングがストレージ アレイに設定されていない。
vHBA またはホストは Clariion デバイス上に登録済みとして表示されるが、同じ WWPN を持つその他のホストはログイン済みとして表示される マルチパス環境では、すべてのパスが EMC アレイに明示的に登録されている必要がある。3
SAN のインストールは正しく行われたが、システムが起動しない
  • ローカル ディスクがブレードに搭載されている。
  • インストール時に、ホストのマルチパス ドライバが必要になることがある。


イメージとプロビジョニング


Cisco UCS は、イメージを利用するサーバに対し、仮想メディア(KVM コンソールから)およびネットワーク インストールの 2 つのメカニズムを提供します。ネットワークを介したインストールがベスト プラクティスです。この場合、インストールの管理は自動化でき、データを 10 ギガビット イーサネット接続によって転送できるからです。仮想メディアによるインストールの場合、インストールは 1 ギガビット イーサネット管理インターフェイスを介して手動で行います。

仮想メディアを使用した一部のバージョンの Microsoft Windows のインストールでは、ISO インストール イメージとストレージ/ネットワーク デバイス ドライバの間で、手動によるマッピングおよびアンマッピングが必要になる場合があります。ディスクのフォーマット時にエラーが発生した場合には、元の ISO インストール イメージを再マッピングします。

複数の類似サーバに対してブート LUN を提供するには、最初に「ゴールデン イメージ」のブート LUN を作成し、次に LUN やボリューム クローニングなどのインテリジェント ストレージ アレイ機能を使用して、ブート イメージを複製する方法が最適です。

注: クローニングされた LUN は、Linux と Microsoft Windows でうまく機能しますが、VMware では機能しません。

IP アドレスの割り当ては Dynamic Host Configuration Protocol(DHCP)サーバによって中央で管理し、ホスト名はドメイン ネーム システム(DNS)の逆引きの結果に基づいて設定するのが最適です。

Microsoft Windows のアクティベーションは、ボリューム ライセンスを介して管理するのが最も適しています。

アドバンスド トピック


サーバ プール

サーバ プールは、物理ブレードを異なるグループに分類および分離するための手段を提供します。グループ分けの基準は、管理者にゆだねられます。グループ分けの基準として使用されるのは、物理サーバの機能(CPU 速度、メモリ サイズ、ローカル ディスクを使用するかどうか、など)、論理的な事業部門(マーケティング、財務など)、特定の顧客、特定の地域などです。サーバ プールは、各ブレードから手動で作成するか、サーバ プール ポリシー条件を介して自動的に設定されます。サーバ プールを定義したら、個別のサービス プロファイルまたはサービス プロファイル テンプレートと関連付けることができます。

必要に応じて、アプリケーション用のハードウェアベースのサービス レベル合意を提供および適用する方法として、認定されたサーバ プールとともにサービス プロファイル テンプレートを使用することができます。

プール ポリシー条件とプール ポリシー

プール ポリシー条件とプール ポリシーは、サーバ プールと連携して機能します。プール ポリシー条件は、ブレードを異なるセットまたはクラスに分けるために使用します。一般的な条件には、次のものがあります。

  • メモリ サイズ
  • CPU ソケットまたはコアの数
  • ブレードのモデルまたはタイプ
  • 物理シャーシまたはスロット
  • パワー グループ

プール ポリシーは、プール ポリシー条件とサーバ プールの間に「relational join(関係結合)」を形成します。プール ポリシーを作成するとすぐにサーバ プールを設定でき、新たに検出されたブレードは各サーバ プールへ自動的に保存されます。各ブレードは、複数の重複するサーバ プールに同時に存在することができます。

ベスト プラクティスでは、プール ポリシー条件と、一緒に使用するプール ポリシーには同じ名前を付けます(任意でサーバ プールにも同じ名前を使用)。

構成のバックアップ

Cisco UCS の構成は簡単にバックアップを取ることができ、GUI または自動スクリプトを介して定期的にバックアップを取る必要があります。

バックアップには 4 つのタイプがあり、表 2 ではそれらのタイプについてまとめています。

表 2 構成バックアップのタイプ

タイプ 形式 説明 サイズ
Full State フル ステート バイナリ ディザスタ リカバリの一環として、システム全体を復元する際に使用 およそ 1 〜 10 MB
System Configuration システム構成 XML ロール、Call Home、コミュニケーション サービス、分散仮想スイッチなど およそ 100 〜 500 KB
Logical Configuration 論理構成 XML サービス プロファイル、VLAN、VSAN、プール、ポリシー、テンプレートなど およそ 100 〜 500 KB
All Configuration すべての構成 XML 論理構成とシステム構成の両方 およそ 200 〜 1000 KB


「Logical Configuration」および「All Configuration」タイプのバックアップの場合、ID の保護機能を使用して、実際の MAC アドレス、WWN、および UUID 値を保護します。この機能を使用しないと、バックアップは論理プール名を参照します。

「ゴールド イメージ」をサーバ レベルで使用する場合と似た方法で、「ゴールド構成」をドメイン レベルで使用できます。この方法では、UCS ドメイン テンプレートとしての役割を果たす標準構成の構築が必要であり、ID を保護せずに「すべての構成」タイプのバックアップを実行します。複数の UCS ドメインが存在する環境では、ゴールド構成は連続するドメインとしてインポートされることがあります。ID プールでは、すべてのドメインで同じ名前が使用されますが、衝突を回避するためにドメイン固有の値が設定されます。この方法により、複数ドメインにまたがる一般的なオブジェクト(ポリシー、サービス プロファイル、テンプレートなど)の標準化が可能になります。

ベスト プラクティス:ID

  • 所定の復元(同じサイトまたはドメイン、あるいは正確なリカバリ サイトまたはドメイン)のために各ドメインをバックアップする場合には、ID の保護機能を使用する。
  • 「ゴールド UCSM ドメイン」テンプレートの作成時には ID の保護機能を使用しない。

パワー(電力)グループとパワー コントロール(電力制御)ポリシー

パワー グループとパワー コントロール ポリシーは連携して機能し、電力制限しきい値を超えないように働きかけ、任意の電力しきい値に近づいた場合には処理負荷の適切な優先順位付けが行われます。パワー グループは、同じテーブルタップ、同じ物理ラック上、または共通の電源経路を共有するラック セット上のすべてのシャーシなど、共通の電力制限の依存関係がある複数シャーシで定義できます。

パワー グループのパワー キャップ(電力上限)値は、超過できない電力の上限しきい値となります。パワー コントロール ポリシーはサービス プロファイル(またはテンプレート)から参照され、複数の処理負荷の間での優先順位付けや相対的な重み付けが提供できます。所定のパワー グループが電力上限値に達すると、電力上限しきい値を超過しないようにするために、そのグループ内のすべてのサーバの電力消費(およびパフォーマンス)が相対的な重み付けに応じて減らされます。優先順位の低いサーバは、優先順位の高いサーバよりも減少幅が大きくなります。上限設定のないパワー コントロール ポリシーを参照する場合には、そのサーバには電力上限機能が適用されません。

組織

「Organizations(組織)」を使用して管理サブドメインを作成することにより、管理者はリソースを論理的に分割したり、より効率的に管理の規模を拡大したり、マルチテナントをサポートすることができます。

組織は階層的に構成され、ルートがデフォルトの最上位レベルになります。作成される下位組織には、その管理の範囲内に、対応するプール、ポリシー、およびテンプレート セットが存在します。

階層的な組織の管理には、継承と上書きという 2 つの重要なプロパティが適用されます。継承では、階層の親レベル(ルート レベルなど)に定義されたプール、ポリシー、およびテンプレートは、階層内の下位の子組織内にあるオブジェクト(ルートの下の下位組織内にあるサービス プロファイルなど)によって使用および継承されます。上書きプロパティでは、ローカルの組織管理者に独立性が与えられます。子組織内のプール、ポリシー、およびテンプレートに対し、ローカルで変更または上書きが行われ、その他の子や親には共有や確認をすることはできません。

ID プールはローカルの組織レベルで管理できます。ベスト プラクティスは、ルート レベルにおいてのみ管理し、データセンターのサイト全体のカタログと密接に連携を取りながら作成された UUID、MAC アドレス、WWNN、および WWPN プールの単一セットを使用することです。

モニタリング

Cisco UCS は syslog や Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)といった標準的なヘルス チェックおよびモニタリング方法のセットと、関連 MIB4get および fault traps のみ利用可、set は利用不可)を提供します。UCS モニタリングのベスト プラクティスは、SCOM5、OpenView、または BPPM6 など、すでに使い慣れ、よく理解している既存の方法やフレームワークを使用することです。

ライトウェイト(軽量 )ディレクトリ アクセス プロトコル(LDAP)

Cisco UCS は、LDAP や Active Directory などの既存の認証フレームワークと透過的に統合するように設計されています。基本設定については十分に解説されたドキュメントがありますが7、留意すべきベスト プラクティスを次に挙げます。

  • Active Directory と Cisco UCS の間で一致するロール名を保持する。
  • 非拘束(バインド)管理ユーザ アカウントに対し、失効しないパスワードを使用する(定期的にグループ メンバーシップを確認する)。
  • 追加するものに対してすべての LDAP プロバイダーでテストまたは確認する。

Cisco Fabric Extender Link(FEX-Link)、Data Center VM-FEX、および VN-Tag


Cisco FEX-Link は、シスコの提供するネットワーク イノベーションの基盤となるものです。Cisco Nexus アーキテクチャ8によって裏付けられるように、追加の管理や管理オーバーヘッドを増加することなく、ネットワークの設定、管理、モニタリングの規模を拡大します。ファブリック エクステンダの追加により、ネットワーク ポートは増加されますが、単一の制御スイッチを介して集中化した管理はそのまま保持されます。

このファブリック エクステンダ モデルが Cisco UCS に組み込まれています。FI の内部スイッチング回路は、基本的に Nexus 50009 のものと同じです。また、シャーシ内の IOM の内部回路は、基本的に Nexus 200010 のものと同じです。このアーキテクチャにより、管理オーバーヘッドを増やさずにシャーシを Cisco UCS ドメインに追加することができます。

また、仮想化を広く取り入れ、システムとファブリックを統合することにより、管理性の問題が深刻化する可能性があります。統合により、物理ポートの数は減少しますが、仮想エンドポイントに対しては、設定、管理、モニタリングなど、詳細な制御が必要なことには変わりはありません。

Cisco FEX-Link は、仮想ネットワーク エンドポイントあるいは「仮想ポート」に対応するフローのコンテキストを保持する新しい業界標準タグ11を挿入することにより、ネットワーク トランスポート層でこの問題を解決しました。この方法により、単一の物理ポートに対して、多数の個別の(仮想)ネットワーク インターフェイスにサービスを提供できるように拡張させます(NPIV がファイバ チャネル ポートを使って問題を解決する方法に似ています)。Cisco FEX-Link は、ネットワーク エンドポイントが物理サーバのネットワーク ポートまたは仮想マシンの仮想ネットワーク ポートかどうかに依存せずに、管理の観点から同等にネットワーク エンドポイントに対応します。

Cisco FEX-Link の主な利点は次のとおりです。

  • ネットワーク ポリシーの設定が、セントラルの制御スイッチによって集中管理される。
  • ネットワーク ポリシーの設定は、エンドポイントが物理ポートであるか仮想ポートであるかにかかわらず、同等に適用される。

Cisco VM-FEX12 は FEX-Link モデルを仮想化領域にまで拡張します。ネットワークの管理、設定、およびモニタリングは集中的に管理されますが、ハイパーバイザに「仮想ファブリック エクステンダ」が組み込まれます。VM-FEX は、Cisco Nexus 1000V シリーズ スイッチの場合はソフトウェアに組み込まれており、Cisco UCS 仮想インターフェイス カード(VIC)の場合はハードウェアに組み込まれています。

仮想化では、一般にすべての仮想マシン ネットワーク トラフィックはハイパーバイザのホストを介してプロキシされ、仮想マシンが VMware vMotion または DRS などを使用してホストからホストへ動的に移行すると、すべての仮想マシンのネットワーク コンテキストは失われます。VM-FEX では、ネットワーク管理者は、各仮想ネットワーク インターフェイスの仮想マシンごとに、コンテキストとアフィニティを保持することができます。仮想マシンのネットワーキング トラフィックは、ハイパーバイザのホストではなく、仮想マシン自体に関連付けられている仮想イーサネット ポートに接続されます。ネットワーク管理者は、ハイパーバイザではなくこの仮想ポートを通してポリシーを適用し、セキュリティを設定し、各仮想マシンの vNIC のトラフィックを詳細にモニタリングすることができます。

物理から仮想へ移行するサーバの例を考えてみましょう。ネットワークの観点から見ると、目標は、展開が物理マシンまたは仮想マシンのいずれであっても、VLAN ベースの分割と QoS ベースの SLA など、同一のネットワーク構成とポリシーを提供することです。図 10 の GUI は、vNIC テンプレートの作成方法を示しています。

図 10 vNIC テンプレートの作成ウィザード

図 10 vNIC テンプレートの作成ウィザード


[Target] ボックスには、物理マシンや仮想マシンの境界を超えて一貫したネットワーク ポリシーを設定するという、Cisco UCS モデルの重要な機能の 1 つが表示されています。関連付けられているすべての VLAN および QoS ポリシーとともに、EXCH-e0 ネットワーク プロファイルが作成されると、[Target] ボックスの設定により、このネットワーク ポリシーを物理マシン([Adapter])または仮想マシン([VM])、あるいはその両方に適用することができます。物理マシン([Adapter])はサービス プロファイルに適用されます。ただし、ターゲットとして [VM] を選択すると、この vNIC テンプレートは図 11 の [VM] タブに示されているようにネットワーク ポート プロファイルとなり、分散仮想スイッチに適用およびエクスポートすることができます。

図 11 ポート プロファイル

図 11 ポート プロファイル


例として VMware を挙げ、次のような構成を想定します。

  • Cisco UCS Manager および VMware vCenter Server(VCS)インスタンスの両方が、適切なセキュリティ ハンドシェイクを実行している。
  • VMware VCS インスタンス上に分散仮想スイッチが構成されている。
  • UCSM を使用してポート プロファイルが作成およびエクスポートされている。

図 12 に示すように、ポート プロファイルは VMware VCS のネットワーク ポート プロファイルとして表示されます。

図 12 VMware ネットワーク ポート プロファイル

図 12 VMware ネットワーク ポート プロファイル


サーバおよびネットワーキングの管理の役割に対して、分離と標準化が促進されます。仮想マシンの管理者は仮想マシンを設定するだけで済み、ネットワーク管理者のような作業は要求されなくなります。ネットワーク管理者はネットワーク ポリシー(EXCH-e0 など)の作成を担当し、仮想マシンの管理者は、図 13 に示すように、適切に規定されたネットワーク ポート ポリシーを使用するだけです。

図 13 VM に対するネットワーク ポート ポリシーの関連付け

図 13 VM に対するネットワーク ポート ポリシーの関連付け


仮想マシンを立ち上げ、ネットワーク トラフィックの受け渡しが開始されると、仮想ポートですべてのトラフィックが伝送されます。トラフィックは、ホストベースの仮想スイッチによってローカルでスイッチングされるのではなく、VM-FEX が提供する仮想リンクによってハイパーバイザをバイパスし、物理スイッチ層(FI など)でスイッチングされます。

仮想イーサネット ポートは、VM が稼働しているホストには関係なく、VM の仮想ネットワーク ポートに関連付けられているすべてのトラフィックに対して一貫したネットワーク コンテキストを提供します。すべての VM ネットワーク トラフィックには業界標準の VN-Tag が付けられ、ローカル ホストベースのスイッチングは回避されます。次にネットワーク管理者は、図 14 に示すように VM が異なるホスト間を移動する場合でも、ネットワーク フローの管理、モニタリング、状態、および統計情報の一貫した永続的なビューを保持できます。

図 14 ネットワーク フローの管理、モニタリング、状態、および統計情報のビュー

図 14 ネットワーク フローの管理、モニタリング、状態、および統計情報のビュー


ネットワーク アクティビティのコンテキストを管理するために、UCSM によって示される vNIC 仮想ポート番号は、VCS によって示される仮想ポート番号と簡単に関連付けることができます。

図 15 コンテキストとしての vNIC 仮想ポート

図 15 コンテキストとしての vNIC 仮想ポート


この例は VMware に基づくものですが、VM-FEX は完全にハイパーバイザから独立した革新的な転送を実現します。VM-FEX の機能は、Red Hat Linux 6.1 の KVM13 でもサポートされ、Microsoft Windows 2012 の Microsoft Hyper-V14 でもサポート予定です。

Cisco FEX-Link および VN-Tag ポート拡張機能は、Cisco UCS の基盤の一部です。データセンターのオペレータの多くが、物理サーバと仮想マシンのさまざまな管理方法に頭を悩ませていますが、Cisco FEX-Link では、物理マシンと仮想マシンで同一の方法を使ってネットワーク トラフィックを管理、設定、モニタリングできる統一の理想的な環境が提供されます。

ベスト プラクティス:ネットワーク ポリシーの設定

仮想マシンまたは物理マシンの境界や、物理接続の制約に基づくのではなく、要件による分割とセキュリティおよび SLA に基づいて、ネットワーク ポリシーを設定します。

XML ベースの API を使用したアクセス


管理者は、通常の場合 GUI を通して Cisco UCS に習熟していきますが、Cisco UCS Manager は単なる GUI ではありません。Cisco UCS Manager は、クラスタ化されペア構成されたファブリック インターコネクトにおいて、Cisco NX-OS の特権ゲストとして実行される管理エンジンです。

Cisco UCS Manager にアクセスする唯一の方法は、オープンな公開・文書化された XML ベースの API15 を使用することです。実際、Cisco Unified Computing System において、実際に管理する物理オブジェクトより先んじて、マネージド オブジェクト モデルと XML API が最初の要素としてデザインされました。

管理対象オブジェクト モデルの本質に関する重要な情報は、構成バックアップのコンテンツを表示するだけで確認できます。

図 15 コンテキストとしての vNIC 仮想ポート

(以降つづく)

バックアップは階層型 XML データベースに似ており、Cisco UCS Manager の本質の多くを理解できます。GUI を使用すると、これらすべてのオブジェクトと属性はさまざまなタブやビューで表現されます。

GUI でさえ XML API を使用しないとアクセスできません。それを確認するには、診断トレースにより API コールと応答を調べます。

[------------- Sending Request to Server ------------
 <configConfMos
 inHierarchical="true">
  <inConfigs>
 <pair key="org-root/ls-EXCH-2">
  <lsServer
  agentPolicyName=""
  biosProfileName=""
  bootPolicyName="SAN-Boot"
  descr=""
  dn="org-root/ls-EXCH-2"
 (…)
  </lsServer>
 </pair>
  </inConfigs>
 </configConfMos>
-----------------------------------------------------]
[---------- Received Response from Server -----------
HTML Headers:
  Response: HTTP/1.1 200 OK
  Date: Fri, 06 Jan 2012 04:16:57 GMT
  Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/FIPS
  Content-Length: 3385
  Connection: close
  Content-Type: application/soap+xml
[----------debugBuffer----------------]
 <configConfMos cookie="[hidden]" response="yes"> <outConfigs> <
pair key="org-root/ls-EXCH-2"> <lsServer agentPolicyName="" assignState="
unassigned" assocState="unassociated" biosProfileName="" bootPolicyName="SAN-Bo
ot" childAction="deleteNonPresent" configQualifier="" configState="not-applied"
 descr="" dn="org-root/ls-EXCH-2" dynamicConPolicyName="" extIPState="none" flt
Aggr="0" fsmDescr="" (…)
intId="975398" modified="1970-01-01T00:00:00.000" name="" oldPnDn="" operState=
"untriggered" rn="ack" scheduler="" status="created"/> </lsServer> &l
t;/pair> </outConfigs> </configConfMos>

アクティブな GUI セッションから取得したこのトレースから、Cisco UCS の設定、管理、モニタリングに関するすべての要素は、HTTP または HTTPS を介して実行できるという重要な点を確認することができます。Cisco UCS 環境のすべての要素を制御するアクセス パスは、独自のものではありません。

XML API は中心的存在で非常に重要であり、統合を容易にするための次のような数多くのツールやユーティリティが開発されました。

  • 「Visore」は管理対象オブジェクト用のオブジェクト ブラウザで、http://<UCSM-IP アドレス>/visore.html に記載のサポート対象ブラウザからアクセスできます。Visore ブラウザでは、ランタイム スキーマへの読み取り専用アクセスが可能であり、オブジェクト、クラス、および属性の XML API ネイティブ名が表示されます。Visore では、実際の名前と、オブジェクト階層内のオブジェクト間の関係を確認することができます。
  • 「goUCS」はソフトウェア開発キット(SDK)に似ており、XML API アクセスを介したアクセスを実現します。goUCS16 では、任意のアクティビティ(導入、モニタリングなど)の XML API ベースの自動化スクリプトを容易に作成することができます。goUCS は XML を Cisco UCS Manager に入力するための単純なフレームワークを提供します。管理者はカスタマイズされたパラメータ方式のスクリプトとラッパーを作成し、goUCS スクリプト ライブラリを簡単に拡張できます。
  • UCSPE は Cisco UCS Manager Platform Emulator (UCSプラットフォーム エミュレータ)17 であり、VMware Player およびワークステーション製品を介して仮想マシンとして動作します。UCSPE は、実際の物理ハードウェアの管理およびモニタリングを除く(ただし、エミュレータは事前構成やカスタマイズしたハードウェアをシミュレートして)、Cisco UCS Manager の全機能を提供します。UCSPE は Cisco UCS Manager および XML API のアクティブなインスタンスをエクスポートします。これによって GUI を実際の Cisco UCS インタンスではなく、UCSPE のインスタンスに接続して機能させることができます。goUCS で作成したカスタム XML API コードやスクリプトを、スクリプトの開発およびデバッグの一環として UCSPE 下で実行することもできます。

まとめ


Cisco UCS Manager は、設定およびポリシーに関する強力なオプションを数多く提供します。これらのオプションの多くは、コンピューティング、ネットワーク、およびストレージ アクセスに適用されるビジネス ルールを正式化する際に非常に役立ちます。Cisco UCS ドメインのサイズが拡大し、ドメイン数が増加した場合に備えて、Cisco UCS Manager は、規模の拡大、ポリシーベースの自動化、簡素化された管理をサポートする多数の主要な機能を提供します。

究極的なベスト プラクティスは、UCS Manager 自身の精練さを生かし、UCSM GUI を使用しないことです。ポリシーベースの自動化がベスト プラクティスとなります。データセンターの設計者、オペレータ、および管理者には、より優れた自動化につながる道を模索されることを推奨します。一般的なガイドラインは次のとおりです。

  • 反復的な運用業務に対処する。XML API を使用して、これらの一般的な業務に対応するパラメータ化されたスクリプトを作成する方法が考えられます。
  • データセンターの自動化の領域において、シスコとそのパートナー エコシステムが過去に行ったインテグレーション サービスを利用する。
  • ビジネス サービスで導入モデルを推進すべきであり、その逆ではない。Cisco UCS を使用して、ポリシー、サービス定義、および SLA を捕えてください。Cisco UCS を導入するからといって、データセンターの運営方法を変える必要はありません。もちろん、「より単純な」、「より簡単な」、「より応答性の高い」データセンターに「変える」のは歓迎されることです。

著者について


Jeff Silberman はデータセンター アーキテクトであり、UCS テクニカル マーケティング チームの初期メンバーです。彼は過去 12 年間にサーバおよび I/O の仮想化に取り組んできました。彼は画期的な『UCS Best Practice/Quickstart Guide』および『UCS Deep Dive Methodology』を執筆しました。シスコでは、数百ものお客様の概念実証の管理、製品のレビューとデモ、UCS に関する技術的な「ディープ ダイブ」を担当してきました。シスコによる Topspin の買収をきっかけに、シスコ社員となりました。Topspin では最大級の HPC 導入を担当し、中でも Sandia Thunderbird 4,400 ノード クラスタは 2005 年 11 月に上位 500 展開において初登場第 4 位を獲得しました。Topspin に入社する前は、NetApp の先進製品開発グループに数年間在籍し、Oracle®/NetApp 環境向けに業界初のユニファイド ファブリック ソリューションを展開しました。

付録:Cisco UCS クイック スタート ガイド


Cisco UCS システムをシンプルかつより早く稼働させるために、このクイック スタート ガイドにてステップをご紹介します。システムを使用できるようにするための必要最小限の手順を記載しています。

  1. L1 および L2 ポートに配線し、2 つの FI を接続します。
  2. 管理サブネットの 3 つの IP アドレスを各 FI および「仮想 IP」ごとに割り当てます。
  3. [Serial Console connection] でホスト名、IP アドレス、ゲートウェイなどを設定します。
  4. FEX->FI 接続の数(1、2、または 4)に対するシャーシ検出ポリシーを設定します。
  5. サーバ ポート、アップリンク ポート、FC ポートを設定および有効にします。
  6. 管理 IP アドレス プールを作成します(通常は UCS Manager 管理 IP と同じサブネット)。
  7. 最新の UCS ソフトウェア バンドルのパッケージを使用して、「ホスト ファームウェア ポリシー」を作成します。
  8. UUID プール、MAC プール、WWNN プール、WWPN プールを作成します(または、対応する「デフォルト」プールを設定します)。
  9. SAN ブートの場合、ストレージ アレイ ブート ターゲットごとに一意の「ブート ポリシー」を作成します。
  10. VNIC テンプレート(eth0-A、eth1-B)を作成します。これらは上記の MAC プールから取得され、それぞれファブリック A およびファブリック B と関連付けられています。
  11. VHBA テンプレート(fc0-A、fc1-B)を作成します。これらは上記の WWPN プールから取得され、それぞれファブリック A およびファブリック B と関連付けられています。
  12. サービス プロファイル テンプレートを作成します。これらは前の手順で設定されたプール、ポリシー、テンプレートから適宜取得されます。
  13. テンプレートからサービス プロファイルをインスタンス化し、サービス プロファイルを所定のブレードに関連付けます。または、サービス プロファイル テンプレートが特定のサーバ プールと関連付けられるように設定します。
  14. PXE サーバを設定するか、ブート可能な ISO イメージを仮想メディア CD-ROM ドライブにマップして、OS のインストールを開始します。



1 Cisco UCS Manager コントロール プレーンは「プライマリ」および「セカンダリ」として動作します。データ プレーンは両方の FI で常にアクティブ/アクティブです。
2 製品のリリース ノートで指示されている場合がありますので、詳細はそちらも参照ください。
3 NetApp アレイではマルチパス登録は自動で行われます。
4 ftp://ftp.cisco.com/pub/mibs/supportlists/ucs/ucs-manager-supportlist.html [英語]
5 http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/scom/quick/start/guide/ucsMPQS.html [英語]
6 http://www.cisco.com/jp/go/bmc/
7 http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/sample_configurations/
UCSM_1_4_LDAP_with_AD/b_Sample_Configuration_LDAP_with_AD.html
[英語]
8 Cisco Nexus 5000 および Nexus 7000 シリーズ スイッチ、Cisco Nexus 2000 シリーズ ファブリック エクステンダ。
9 Cisco Nexus 5000 シリーズ スイッチ
10 Cisco Nexus 2000 シリーズ ファブリック エクステンダ
11 VN-Tag:http://standards.ieee.org/regauth/ethertype/eth.txt [英語]
12 Cisco データセンター仮想マシン ファブリック エクステンダ
13 http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/vm_fex/kvm/gui/config_guide/GUI_KVM_VM-FEX_UCSM_Configuration_Guide_chapter4.html [英語]
14 http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns955/ns963/solution_overview_c22-687087.html [英語]
15 http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/api/ucs_api_book.html [英語]
16 http://developer.cisco.com/web/unifiedcomputing/goucs/ [英語]
17 http://developer.cisco.com/web/unifiedcomputing/ucsemulatordownload [英語]