UCS の大規模な展開には、Cisco UCS Central が必要です。シスコには、300 以上の登録済み UCS ドメインと 6,000 台以上のサーバがあります。シスコ IT による社内分析は、Cisco UCS Central を利用することで、運用機器のワークロードを約 1 人/年節約できることを示しています。シスコは、Cisco UCS Central を使用して、すべての UCS ドメインを管理します。

シスコでは、1 つのインスタンスで最大 10,000 台のサーバをサポートするために、最新リリースの Cisco UCS Central をテストしました。このタイプのスケーリングのため、HTML-5 のユーザ インターフェイス（UI）が全面的に再設計されました。HTML-5 UI は、スケーリング時の UCS ドメインとサーバの管理により適した設計になりました。古い Flash ベースの UI は、大規模な環境で使用すると、パフォーマンスの問題がありました。

大規模な展開では、効率的なドメイン グループの階層を利用することが重要です。大規模な環境には、国中または世界中に分散したすべての UCS ドメインを含めることができます。ドメイン グループには、異なるタイム ゾーン、DNS サーバ、ユーザ認証、ドメイン コントローラ、リモート FTP サーバが含まれる場合があります。効率的なドメイン グループの階層により、ファームウェアのアップグレードと管理にさらにきめ細かいアプローチを適用できます。

多くの UCS ドメインのバックアップ ジョブのスケジュールを個別に管理しようとすると、手間がかかり、ミスも生じやすくなります。Cisco UCS Central を使用することで、このタスクが簡素化されます。バックアップ（fullstate.bin）、構成のエクスポート（allconfig.xml）、および特定のリモート コピー FTP サーバにカスタム スケジュールを定義して、これらのバックアップが適切に保護されるようにします。

内部の LDAP サーバで UCS ドメインの LDAP 統合を使用している場合、これらの詳細な設定を複製することも、手間がかかり、ミスが生じやすくなります。Cisco UCS Central はこのタスクを非常に簡単にします。ドメイン グループの階層型ポリシーの一部として LDAP を設定します。必要に応じて、幅広くまたは詳細にポリシーを定義できます。

（注）	Cisco UCS Central は、単一のポリシーとして LDAP ポリシーを扱います。階層のあるレベルでグループ マッピングを定義し、より下位のレベルで LDAP プロバイダーを定義するなど、ポリシーのさまざまなコンポーネントを分解することはできません。

ポリシーは、地理的なドメイン グループに登録されている UCS ドメイン グループに適用可能なドメイン グループの階層の上位に配置できます。また、Infrastructure & Catalog Firmware をより詳細な下位のサブドメイン グループ構造に配置することもできます。

最終的に、自分および組織にとって最適な設定がベスト プラクティスとなります。常にシンプルなアプローチを選択し、サブドメイン グループ構造を変更または拡張できます。ドメイン グループ構造の変更は、組織の構造を変更するよりも容易です。組織構造の変更は、環境に破壊的影響をもたらす変更になる傾向があります。

図 1. 大規模な UCS Central 環境：設定例

計画された大規模なグリーンフィールドの展開では、最初から Cisco UCS Central を導入し、グローバル ポリシーとオブジェクト インフラストラクチャを適切に設計することが推奨されます。Cisco UCS Central 内ですべてをグローバルに作成することで、時間とコストが節約でき、スケーリングがはるかに容易になります。また、日常業務を担当するときの時間も節約できます。

Cisco UCS Central は、UCS ドメインの初期セットアップ時に Cisco UCS Central と Cisco UCS Manager 間に存在していたギャップを埋めます。Cisco UCS Central に、機器ポリシー、ユニファイド ポート設定、ポート ロール、およびポート チャネル設定を定義する機能が含まれるようになりました。

ドメイン グループの階層の計画に加えて、組織の階層を考慮してから、最終的なアーキテクチャを展開します。これにはグローバル ID プール、ポリシー、VLAN、VSAN、テンプレート、およびサービス プロファイルの計画が含まれます。インテリジェントに組織の境界を作成する機能は、マルチテナントにメリットをもたらし、環境に必要なグローバル サービス プロファイル テンプレートの数も削減できる可能性があります。

VLAN および VSAN エイリアシング、ID 範囲アクセス コントロール ポリシーなどのその他の高度な機能も、管理するグローバル サービス プロファイル テンプレートの数の削減をサポートします。いくつでも必要なだけ管理することができますが、管理をシンプルにすれば運用コストも常に削減されます。

Cisco UCS Manager と Cisco UCS Central の大規模なアーキテクチャには、数百または数千のサービス プロファイルが含まれている場合があります。そのため、UCS Central への移行には、慎重な計画と計算が必要です。オブジェクト リポジトリを Cisco UCS Central に移行して、ローカル サービス プロファイルをグローバル サービス プロファイルに変換する場合には注意を払います。グローバル インフラストラクチャを構築して、すべての UCS ドメイン内のローカル インフラストラクチャをミラーします。

ローカル サービス プロファイルをグローバル サービス プロファイルに変換するのは破壊的であることを思い出してください。しかし、1 つのインターフェイスですべてをグローバルに管理して、複数の UCS ドメイン間でワークロードのモビリティが得られる利便性は、欠点を補って余りあります。

大規模なブラウンフィールドのクライアントによっては、オブジェクト リポジトリを移動し、ゆっくり時間をかけてローカル サービス プロファイルを変換することを選択しています。これは将来のメンテナンスの時間帯を利用して、順番に Cisco UCS Central に移行します。ホスト ファームウェア、コントローラ ファームウェア、BIOS、ネットワーク アダプタ、CIMC、およびストレージ コントローラをアップグレードすることは、すべて破壊的なアクションです。ホストには、正常にシャット ダウンして、更新を実行するブレード サーバにサービス プロファイルを登録するためのメンテナンスの時間帯が必要です。この間に、既存のローカル サービス プロファイルを新しいグローバル サービス プロファイルと置き換えることができます。

その他のブラウンフィールドのクライアントは、ブラウンフィールド環境とグリーンフィールド環境を並行して運用するモデルを採用しています。これは、既存の UCS インフラストラクチャがブラウンフィールドとして残っていることを意味します。これはそれぞれの Cisco UCS Manager ドメイン内でローカルに管理され、一方で環境内の新しいものはすべて Cisco UCS Central からグローバル オブジェクトとして展開されます。

ネットワークが進化し、ローカル インフラストラクチャがサポート終了に達したら、環境のさらに多くのものをグローバルに変換します。ローカル サービス プロファイルを保持する場合でも、サービス プロファイルまたはテンプレート内でローカルからグローバルに切り替えることで、グローバル サービス プロファイルを使用します。これにより、ポリシーの数が減り、Cisco UCS Central 内の 1 つの場所からサービスが提供されます。「ブラウンフィールド：ローカル サービス プロファイルを使用したグローバル ID およびポリシーへのアクセス」を参照してください。

PowerTool による自動化と XML-API によるスクリプトで、変換処理が非常に簡単になります。「ブラウンフィールドのローカル サービス プロファイルからグローバル サービス プロファイルへの移行」を参照してください。