技術的に詳細な紹介は本家におまかせし、こちらでは今後も「そもそも」的な部分を小粒に書いていきたいと思います。別にOfficialなBlogでも仕事でもないですし！
Ciscoのサーバ製品 "Cisco UCS" には、ブレードサーバのBシリーズとラックマウントサーバのCシリーズがあります*1。
以前、サーバ仮想化によってインフラは群体として扱われるモノとなっていく、と書きましたが、まさにこの言葉はUnifiedという言葉で、流行というか流れになってきていると思います。…そして、製品として冠にそのUnifiedという単語を含むUCSをUnifiedたらしめている存在が、UCS Managerです。
UCS ManagerはブレードサーバのBシリーズでは必須、ラックマウントサーバのCシリーズでは必須ではありませんが、あるとないとではだいぶ管理性が違ってきます。
ところで二つの側面があるので最初は分かりづらいかと思うのですが、UCS Managerは物理的にはFabric Interconnectと呼ばれる、見た目はNexus 5000シリーズと同じ様な見た目(色違い)の筐体内に搭載されているフラッシュデバイスに導入されている管理機能です。
Bシリーズサーバを納めるためのシャーシであるUCS 5108には、他社のブレードサーバシャーシに搭載されているような、いわゆる管理モジュールは搭載されていません。1/19に「Fabric Extender (FEX) って？」というエントリーを書きましたが、ブレードシャーシには電源やファンといったインフラモジュールを除けば、ブレードサーバ自体以外にはシャーシ搭載型のFEXが背面に搭載されているだけです。以前のエントリーでも書いたとおり、FEX自体は独立して管理するものではありませんので、徹底的にブレードシャーシの中で個別に管理しなければならないような要素が存在しないように作り込まれています。
また、インフラ管理機能がサーバとしてではなく、仮想アプライアンスのような形でもなく、Fabric Interconnectに搭載されるカタチで提供されているという点は考えてみると、なかなか理にかなっていると思います。管理対象となるサーバや、その上で動作する仮想アプライアンスのようなカタチであると、管理上入れ子状態となってしまうというか、やはり「管理する側と管理される側は切り離されているべき」でしょう(Fabric Interconnect自身も管理対象ではあるわけですが…設定を変化させる対象という意味ではFabric InterconnectとUCS Manager間の接続こそが最も失ってはいけない接続であるといえるわけで、であれば同居していることは最適な構成といえます)。
サーバからも、ブレードシャーシからも管理機能が切り離されているため、管理範囲はブレードシャーシ単位に制限されることもありませんし、Fabric Interconnectに接続していればラックマウント型のサーバであってもブレードサーバとまったく同じように管理することができます。ブレードシャーシを超えて統合された管理性が提供され、サーバ、Fabric Extender (FEX)、Virtual Interface Card (VIC)とVIC連携によるAdapter FEX / VM FEXなどがすべてまとめて管理できる*2ため、システム実行環境を組み替えたりする際に、サーバ、LAN、SANなどをバラバラに構成変更するような手間がない点はとても便利ですし実用的な仕組みといえます。
さらに、今後システムがよりUnifiedとなっていくためにはインフラのレイヤーとより上位のレイヤーが統合的に連携できる仕組みが必要となっていきますが、UCSの場合はすでにUCS Managerによってインフラ範囲が統合管理された状態となっているため、連携の仕組みも作りやすいといえるでしょう。
現在、UCS ManagerはJavaアプリケーションのカタチでインターフェイスが提供されていますが、これはあくまでもUCS Managerを管理操作するためのインターフェイス実装でしかありません。実体はAPIとなっていますし、このインターフェイスからも裏では単にUCS Managerに対してAPIによる制御が行われています。一元化された上でさらにAPI化されているため、アプリケーションやミドルウェア、オーケストレーターなどからの制御もよりシンプルに、明確なかたちで実装しやすくなっているかと思います。
前回も〆に書きましたが、こうしたちょっとした点の実装が、大きな違いとなっていくのではないでしょうか(^_^;)！
