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

ホワイトペーパー
Cisco UCS Manager の設定
一般的な手法とクイックスタートガイド
目次
Cisco Unified Computing System の概要 .................................................................................................... 3
Cisco UCS の設計目標 ............................................................................................................................... 3
Cisco UCS 自体では提供されないもの（他ソフトウェア、ソリューションなどと連携が必要なもの）。 .................. 3
Cisco UCS Manager の初期設定 ................................................................................................................... 4
標準的な手順 ................................................................................................................................................... 4
シャーシ検出ポリシーの設定 ........................................................................................................................ 4
サーバとアップリンクポートの有効化 ............................................................................................................ 5
管理 IP アドレスプールの作成 ..................................................................................................................... 5
ホストファームウェアパッケージの作成（ベストプラクティス）......................................................................... 5
ステートレスサーバを使用したクラウドコンピューティングのための機能 ............................................................ 6
プール .............................................................................................................................................................. 7
ポリシー ........................................................................................................................................................... 8
起動（ブート）ポリシー ................................................................................................................................... 8
ホストファームウェアポリシー ...................................................................................................................... 9
ローカルディスクポリシー............................................................................................................................ 9
スクラブ（終了破棄の時）ポリシー ................................................................................................................. 9
BIOS ポリシー ............................................................................................................................................. 9
分離 ............................................................................................................................................................... 10
テンプレート .................................................................................................................................................... 10
vNIC および vHBA テンプレート ................................................................................................................. 11
可用性のオプション .................................................................................................................................... 12
サービスプロファイルテンプレート ............................................................................................................. 13
更新テンプレート：使用には注意が必要 ...................................................................................................... 13
SAN のインストールおよび起動に関する重要事項 .......................................................................................... 14
可用性を高めるための起動ポリシーの設定 ................................................................................................ 14
サービスプロファイル WWPN に注目 ........................................................................................................ 14
単一イニシエータゾーン分割の使用（オープンゾーンを使用しない） ............................................................ 15
ファイバチャネルスイッチのネームサーバを使用した接続の確認 .............................................................. 15
異種ストレージアレイタイプの混在の回避 ................................................................................................. 16
うまくいかない場合..................................................................................................................................... 16
イメージとプロビジョニング .............................................................................................................................. 16
アドバンスドトピック ...................................................................................................................................... 17
サーバプール ........................................................................................................................................... 17
プールポリシー条件とプールポリシー........................................................................................................ 17
構成のバックアップ .................................................................................................................................... 17
パワー（電力）グループとパワーコントロール（電力制御）ポリシー ............................................................... 18
組織 .......................................................................................................................................................... 18
モニタリング ............................................................................................................................................... 19
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 1 of 30
ライトウェイト（軽量）ディレクトリアクセスプロトコル（LDAP） ....................................................................... 19
Cisco Fabric Extender Link（FEX-Link）、Data Center VM-FEX、および VN-Tag ...................................... 19
XML ベースの API を使用したアクセス ........................................................................................................... 26
まとめ ............................................................................................................................................................ 28
著者について ................................................................................................................................................. 28
付録：Cisco UCS クイックスタートガイド ........................................................................................................ 29
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 2 of 30
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 で強化される項目があります）
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 3 of 30
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
シャーシ検出ポリシー
Cisco UCS Manager コントロールプレーンは「プライマリ」および「セカンダリ」として動作します。データプレーンは両方の FI で
常にアクティブ/アクティブです。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 4 of 30
サーバとアップリンクポートの有効化
FI はネットワークアクセスデバイスをまとめています。FI には、シャーシ IOM へ向かう下位方向接続と、コア LAN
または SAN へ向かう上位方向接続があります。シャーシ IOM へ向かう下位方向のポートは「サーバポート」として
設定され、コア LAN へ向かう上位方向のポートは「アップリンクポート」として設定されます。図 2 に示すように、FI
を選択し、必要なポートを右クリックすることによって、ポートを設定して有効にすることができます。
図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 バージョンに対応した、ホストファームウェアパッケージを作成することです。
2
製品のリリースノートで指示されている場合がありますので、詳細はそちらも参照ください。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 5 of 30
Cisco UCS Manager には、すべての主要なハードウェアコンポーネントのファームウェアバージョンを、迅速かつ
簡単にレポートする機能があります。図 3 に示すように、[Equipment] タブの [Equipment] を選択してから、
[Firmware Management] > [Installed Firmware] の順に選択します。一般には、IOM、FI、および UCS Manager
®
は同じバージョンである必要があります。アダプタカード、BIOS、および Cisco Integrated Management
Controller（CIMC）のバージョンは、通常、関連するサービスプロファイルのホストファームウェアパッケージによっ
て決まります。
図3
すべての主要なハードウェアコンポーネントのファームウェアに関するレポート
この時点で、すべてのハードウェアが物理的機器として使用できるようになっているはずです。しかし、Cisco UCS
の真の力は、アプリケーションレベルのサーバ（サービスプロファイル）を作成して設定し、物理ハードウェアにそれ
らを「関連付ける」方法にあると言えます。
ステートレスサーバを使用したクラウドコンピューティングのための機能
動的なクラウドコンピューティングモデルの構築を必要とするデータセンターのために、Cisco UCS はステートレス
サーバ環境をサポートするインフラストラクチャを提供しています。ステートレスサーバは、従来のハードウェア識別
子（World Wide Node Names（WWNN）、World Wide Port Name（WWPN）、MAC アドレスなど）をサービスプロ
ファイル識別情報の重要な一部分として保持しながら、物理サーバまたはブレード上で動作する論理サーバ（OS
およびアプリケーションイメージ）となります（図 4）。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 6 of 30
図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] タブから管理します。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 7 of 30
ベストプラクティス：マルチドメイン管理
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 デバイスを定義する。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 8 of 30
ホストファームウェアポリシー
すでに説明したように、BIOS、アダプタ ROM、またはローカルディスクコントローラの認定バージョンあるいは代表
的なバージョンを論理サービスプロファイルと関連付けるには、ホストファームウェアポリシーを使用します。ベスト
プラクティスは、一般的な Cisco UCS Manager ソフトウェアリリースと一致する最新パッケージに基づいて 1 つの
ポリシーを作成し、作成するすべてのサービスプロファイルとテンプレートについて、ホストファームウェアパッケー
ジを参照することです。このベストプラクティスは、サーバの最下層のファームウェアにおけるバージョンの一貫性を
確保します。ただし他のブレード上のサービスプロファイルが関連付け直されることがあり物理サーバエラーが発
生することがあります。
ローカルディスクポリシー
ローカルディスクポリシーは、ブレード上のローカルディスクの設定方法を指定します。ベストプラクティスは、
SAN ブート環境ではローカルストレージを指定しないことにより、サービスプロファイルの関連付けを行う際に問題
が発生するのを防ぎます（インストール時にはローカルディスクがホスト OS としての役割を果たすことがあります）。
さらに確実に問題を避けるために、ブレード（特に OS インストール時に使用されたブレード）からローカルディスク
を完全に削除または除外することもできます。
スクラブ（終了破棄の時）ポリシー
スクラブポリシーは、サービスプロファイルの分離時に、ローカルディスクと BIOS に対して行われる処理を決定
するものです。デフォルトのポリシーはスクラブなしです。特にサービスプロバイダー、マルチテナントのお客様、
ローカルディスクへのネットワークインストールが使用されている環境では、ローカルディスクをスクラブするように
ポリシーを設定するのがベストプラクティスです。
BIOS ポリシー
BIOS ポリシーは、起動時のコンソールを使用してアクセス可能な、非常に特殊な CPU 設定の制御が有効になり
ます。VMware および仮想環境において、CPU サポートに依存するインテルバーチャライゼーションテクノロジー
の対応ポリシーを作成することが可能で、サーバプロビジョニングにおける手動操作は必要ありません。同様に、イ
ンテルターボブーストまたはハイパースレッディングの影響を受けるアプリケーションでは、図 2 に示すように、専
用の BIOS ポリシーを参照・適応させることができます。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 9 of 30
図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、およびサービスプロファイル）のテンプレートを提供
することにより、再利用と迅速な導入を容易にします。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 10 of 30
ベストプラクティス：テンプレート
●
適切なレベルの制御と定義のために、サービスプロファイルテンプレートの作成時、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 マッピングなどの重要なセキュリティ定義を含むアプリケーション
固有のネットワークプロファイルとして見なす必要があります。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 11 of 30
図6
vNIC テンプレート
可用性のオプション
ネットワークの可用性は、次のいずれかによって提供されます。
●
[Enable Failover] を選択する。これにより、ハードウェアアダプタレベルでの可用性が提供され、一方の
ファブリック（FI または IOM）のみがダウンしても、サービスは中断されません。
●
ネットワークインターフェイスカード（NIC）のチーミングまたは NIC ボンディングを使用する。これにより、ホ
スト OS レベルの可用性が提供されます。
ストレージの可用性は、ホスト側のマルチパス化によってのみ提供されます。ハードウェアフェールオーバーは
vHBA のオプションではありません。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 12 of 30
ベストプラクティス：ネットワークの可用性
ネットワークの可用性を向上させるには、ハードウェアフェールオーバーまたは NIC チーミング（またはボンディン
グ）を使用しますが、両者を同時に使用することはできません。
vNIC および vHBA テンプレートを定義したら、図 7 に示すように、エキスパートモードから [Use LAN
Connectivity Template] または [Use SAN Connectivity Template] を選択することにより、サービスプロファイル
の作成で参照できます。
図7
LAN 接続テンプレート
サービスプロファイルテンプレート
サービスプロファイルテンプレートは、すべて下位の要素（プール、ポリシー、vNIC および vHBA テンプレート）を
連携させる手段を提供します。サービスプロファイルテンプレートを作成すると、容易かつ迅速にインスタンス化し、
サーバプロビジョニングを実施することができます。
Cisco UCS には「Initial（初期）」（デフォルト）および「Updating（更新)」の 2 タイプのテンプレートがあります。テンプ
レートが作成され、サービスプロファイルがインスタンス化されると、テンプレートのタイプがその後の更新動作と機
能に影響を与えます。サービスプロファイルに対して特定のローカル変更が必要な場合、「初期」テンプレートから
作成されたサービスプロファイルは、そのテンプレートからアンバインドする必要があります。また、初期テンプレー
トに対する変更は新たにインスタンス化されたサービスプロファイルのみに反映されます（過去にインスタンス化さ
れたサービスプロファイルには反映されません）。
更新テンプレート：使用には注意が必要
更新テンプレートは、テンプレートとインスタンス化されたオブジェクト（vNIC、vHBA、またはサービスプロファイル）
の関係を保持するという、非常に強力な機能を提供します。この機能の目的は、一貫性を確保し、規模に応じて設
定変更を伝播します。例として
●
多数のサーバに対し、ホストファームウェアパッケージのバージョン（BIOS を含む）を更新する
●
VMware ESX クラスタ内のすべてのサーバに新しい VLAN をマップする
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 13 of 30
ただし、更新テンプレートを使用して変更を反映すると、BIOS ポリシーやホストファームウェアパッケージに対する
更新などのサービスが中断される場合があります。このようなサービスの中断は、ユーザの確認や予定されたメン
テナンスウィンドウに基づいて有効になるメンテナンスポリシーを使用して、スケジュールすることができます。それ
でも、更新テンプレートを使用する際には最大の注意を払う必要があります。更新テンプレートは、予定されたメンテ
ナンス期間中のかなりの時間を節約することができます。ただし、通常動作時に意図せず更新が発生すると、莫大
な被害が発生します。
サービスプロファイルテンプレートは、物理的な接続の制約にとらわれることなく、所定のサービスまたはアプリ
ケーションのすべてのサービスレベルの属性をカプセル化および形式化するのに最適です。
ベストプラクティス：サービスプロファイルテンプレート
サービスプロファイルテンプレートは、アプリケーション、サービス、またはオペレーティングシステムのクラスまた
はタイプの定義として使用します。
SAN のインストールおよび起動に関する重要事項
Cisco UCS の中心的価値の 1 つであるステートレスサーバモデルは、SAN ブートに基づいています。ローカル
ディスクから起動する場合、サーバイメージのモビリティは実現されません。高い信頼性をもち、一貫した、繰り返し
利用可能な SAN ブート環境を準備するには、いくつかの考慮事項があります。一般的なベストプラクティスを以下
に紹介します。
可用性を高めるための起動ポリシーの設定
図 8 に示すように、起動ポリシーは、プライマリおよびセカンダリ vHBA と、プライマリおよびセカンダリストレージ
パスからの起動を可能にします。
図8
起動ポリシー
サービスプロファイル WWPN に注目
サービスプロファイルの WWPN は、SAN スイッチ（ゾーン分割）および SAN ストレージアレイ（LUN マスキング）
の両方を統合するために最も大切な要素です。図 9 は、WWPN プール要素と、それに対応するサービスプロファ
イルの間のマッピングを示しています。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 14 of 30
図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 スイッチが正しく配線されなかった、
など）。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 15 of 30
異種ストレージアレイタイプの混在の回避
ストレージアレイが正確な 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）の逆引きの結果に基づいて設定するのが最適です。
3
NetApp アレイではマルチパス登録は自動で行われます。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 16 of 30
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 値を保護します。この機能を使用しないと、バックアップは論理プール名を
参照します。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 17 of 30
「ゴールドイメージ」をサーバレベルで使用する場合と似た方法で、「ゴールド構成」をドメインレベルで使用できま
す。この方法では、UCS ドメインテンプレートとしての役割を果たす標準構成の構築が必要であり、ID を保護せず
に「すべての構成」タイプのバックアップを実行します。複数の UCS ドメインが存在する環境では、ゴールド構成は
連続するドメインとしてインポートされることがあります。ID プールでは、すべてのドメインで同じ名前が使用されま
すが、衝突を回避するためにドメイン固有の値が設定されます。この方法により、複数ドメインにまたがる一般的な
オブジェクト（ポリシー、サービスプロファイル、テンプレートなど）の標準化が可能になります。
ベストプラクティス：ID
●
所定の復元（同じサイトまたはドメイン、あるいは正確なリカバリサイトまたはドメイン）のために各ドメインを
バックアップする場合には、ID の保護機能を使用する。
●
「ゴールド UCSM ドメイン」テンプレートの作成時には ID の保護機能を使用しない。
パワー（電力）グループとパワーコントロール（電力制御）ポリシー
パワーグループとパワーコントロールポリシーは連携して機能し、電力制限しきい値を超えないように働きかけ、
任意の電力しきい値に近づいた場合には処理負荷の適切な優先順位付けが行われます。パワーグループは、同
じテーブルタップ、同じ物理ラック上、または共通の電源経路を共有するラックセット上のすべてのシャーシなど、共
通の電力制限の依存関係がある複数シャーシで定義できます。
パワーグループのパワーキャップ（電力上限）値は、超過できない電力の上限しきい値となります。パワーコント
ロールポリシーはサービスプロファイル（またはテンプレート）から参照され、複数の処理負荷の間での優先順位付
けや相対的な重み付けが提供できます。所定のパワーグループが電力上限値に達すると、電力上限しきい値を超
過しないようにするために、そのグループ内のすべてのサーバの電力消費（およびパフォーマンス）が相対的な重
み付けに応じて減らされます。優先順位の低いサーバは、優先順位の高いサーバよりも減少幅が大きくなります。
上限設定のないパワーコントロールポリシーを参照する場合には、そのサーバには電力上限機能が適用されませ
ん。
組織
「Organizations（組織）」を使用して管理サブドメインを作成することにより、管理者はリソースを論理的に分割したり、
より効率的に管理の規模を拡大したり、マルチテナントをサポートすることができます。
組織は階層的に構成され、ルートがデフォルトの最上位レベルになります。作成される下位組織には、その管理の
範囲内に、対応するプール、ポリシー、およびテンプレートセットが存在します。
階層的な組織の管理には、継承と上書きという 2 つの重要なプロパティが適用されます。継承では、階層の親レベ
ル（ルートレベルなど）に定義されたプール、ポリシー、およびテンプレートは、階層内の下位の子組織内にあるオ
ブジェクト（ルートの下の下位組織内にあるサービスプロファイルなど）によって使用および継承されます。上書きプ
ロパティでは、ローカルの組織管理者に独立性が与えられます。子組織内のプール、ポリシー、およびテンプレート
に対し、ローカルで変更または上書きが行われ、その他の子や親には共有や確認をすることはできません。
ID プールはローカルの組織レベルで管理できます。ベストプラクティスは、ルートレベルにおいてのみ管理し、デー
タセンターのサイト全体のカタログと密接に連携を取りながら作成された UUID、MAC アドレス、WWNN、および
WWPN プールの単一セットを使用することです。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 18 of 30
モニタリング
Cisco UCS は syslog や Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）と
いった標準的なヘルスチェックおよびモニタリング方法のセットと、関連 MIB4（get および 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
は、ネットワークエンドポイントが物理サーバのネットワークポートまたは仮想マシンの仮想ネットワークポートかど
うかに依存せずに、管理の観点から同等にネットワークエンドポイントに対応します。
●
ネットワークポリシーの設定が、セントラルの制御スイッチによって集中管理される。
●
ネットワークポリシーの設定は、エンドポイントが物理ポートであるか仮想ポートであるかにかかわらず、同
等に適用される。
4
ftp://ftp.cisco.com/pub/mibs/supportlists/ucs/ucs-manager-supportlist.html [英語]
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_Sam
ple_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 [英語]
5
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 19 of 30
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 テンプレートの作成方法を示しています。
12
Cisco データセンター仮想マシンファブリックエクステンダ
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 20 of 30
図 10
vNIC テンプレートの作成ウィザード
[Target] ボックスには、物理マシンや仮想マシンの境界を超えて一貫したネットワークポリシーを設定するという、
Cisco UCS モデルの重要な機能の 1 つが表示されています。関連付けられているすべての VLAN および QoS
ポリシーとともに、EXCH-e0 ネットワークプロファイルが作成されると、[Target] ボックスの設定により、このネット
ワークポリシーを物理マシン（[Adapter]）または仮想マシン（[VM]）、あるいはその両方に適用することができます。
物理マシン（[Adapter]）はサービスプロファイルに適用されます。ただし、ターゲットとして [VM] を選択すると、この
vNIC テンプレートは図 11 の [VM] タブに示されているようにネットワークポートプロファイルとなり、分散仮想ス
イッチに適用およびエクスポートすることができます。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 21 of 30
図 11
ポートプロファイル
例として VMware を挙げ、次のような構成を想定します。
●
Cisco UCS Manager および VMware vCenter Server（VCS）インスタンスの両方が、適切なセキュリティ
ハンドシェイクを実行している。
●
VMware VCS インスタンス上に分散仮想スイッチが構成されている。
●
UCSM を使用してポートプロファイルが作成およびエクスポートされている。
図 12 に示すように、ポートプロファイルは VMware VCS のネットワークポートプロファイルとして表示されます。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 22 of 30
図 12
VMware ネットワークポートプロファイル
サーバおよびネットワーキングの管理の役割に対して、分離と標準化が促進されます。仮想マシンの管理者は仮想
マシンを設定するだけで済み、ネットワーク管理者のような作業は要求されなくなります。ネットワーク管理者はネッ
トワークポリシー（EXCH-e0 など）の作成を担当し、仮想マシンの管理者は、図 13 に示すように、適切に規定され
たネットワークポートポリシーを使用するだけです。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 23 of 30
図 13
VM に対するネットワークポートポリシーの関連付け
仮想マシンを立ち上げ、ネットワークトラフィックの受け渡しが開始されると、仮想ポートですべてのトラフィックが伝
送されます。トラフィックは、ホストベースの仮想スイッチによってローカルでスイッチングされるのではなく、VM-FEX
が提供する仮想リンクによってハイパーバイザをバイパスし、物理スイッチ層（FI など）でスイッチングされます。
仮想イーサネットポートは、VM が稼働しているホストには関係なく、VM の仮想ネットワークポートに関連付けられ
ているすべてのトラフィックに対して一貫したネットワークコンテキストを提供します。すべての VM ネットワークトラ
フィックには業界標準の VN-Tag が付けられ、ローカルホストベースのスイッチングは回避されます。次にネット
ワーク管理者は、図 14 に示すように VM が異なるホスト間を移動する場合でも、ネットワークフローの管理、モニ
タリング、状態、および統計情報の一貫した永続的なビューを保持できます。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 24 of 30
図 14
ネットワークフローの管理、モニタリング、状態、および統計情報のビュー
ネットワークアクティビティのコンテキストを管理するために、UCSM によって示される vNIC 仮想ポート番号は、
VCS によって示される仮想ポート番号と簡単に関連付けることができます。
図 15
コンテキストとしての vNIC 仮想ポート
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 25 of 30
この例は 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 が最初の要素としてデザインされました。
管理対象オブジェクトモデルの本質に関する重要な情報は、構成バックアップのコンテンツを表示するだけで確認
できます。
（以降つづく）
13
http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/vm_fex/kvm/gui/config_guide/GUI_KVM_VMFEX_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 [英語]
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 26 of 30
バックアップは階層型 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-Boot" childAction="deleteNonPresent" configQualifier=""
configState="not-applied" descr="" dn="org-root/ls-EXCH-2"
dynamicConPolicyName="" extIPState="none" fltAggr="0" fsmDescr="" (…)
intId="975398" modified="1970-01-01T00:00:00.000" name="" oldPnDn=""
operState="untriggered" rn="ack" scheduler="" status="created"/> </lsServer>
</pair> </outConfigs> </configConfMos>
アクティブな GUI セッションから取得したこのトレースから、Cisco UCS の設定、管理、モニタリングに関するすべて
の要素は、HTTP または HTTPS を介して実行できるという重要な点を確認することができます。Cisco UCS 環境
のすべての要素を制御するアクセスパスは、独自のものではありません。
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 27 of 30
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 に関する技術的な「ディープダイブ」を担当してきました。シスコ
16
17
http://developer.cisco.com/web/unifiedcomputing/goucs/ [英語]
http://developer.cisco.com/web/unifiedcomputing/ucsemulatordownload [英語]
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 28 of 30
による 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 の
インストールを開始します。
.
All contents are Copyright © 1992–2012 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information.
Page 29 of 30
©2012 Cisco Systems, Inc. All rights reserved.
Cisco、Cisco Systems、およびCisco Systemsロゴは、Cisco Systems, Inc.またはその関連会社の米国およびその他の一定の国における登録商標または商標です。
本書類またはウェブサイトに掲載されているその他の商標はそれぞれの権利者の財産です。
「パートナー」または「partner」という用語の使用はCiscoと他社との間のパートナーシップ関係を意味するものではありません。（0809R）
この資料に記載された仕様は予告なく変更する場合があります。
お問い合わせ先
シスコシステムズ合同会社
12.08
〒107-6227 東京都港区赤坂9-7-1 ミッドタウン・タワー
http://www.cisco.com/jp
お問い合わせ先：シスココンタクトセンター
0120-092-255（フリーコール、携帯・PHS含む）
電話受付時間 : 平日10:00～12:00、13:00～17:00
http://www.cisco.com/jp/go/contactcenter/

Download Report