データセンター

クラウドフロント、並列高速処理に対応する Cisco UCS M シリーズ モジュラ サーバ

ホワイト ペーパー





クラウドフロント、並列高速処理に対応する Cisco UCS M シリーズ モジュラ サーバ



Steve McQuerry、Cisco UCS テクニカル マーケティング エンジニア、CCIE #6108

総じて、情報インフラが小型化、低価格化、高速化へと向かう中、サーバプラットフォームは一般に「小型化」の面で遅れを取っています。Cisco UCS® M シリーズ モジュラ サーバは、Cisco Unified Computing System™ の中核技術として実績のある、ファブリックベースの技術を生かして構成されています。この最新シリーズが提供するサーバプラットフォームにより、システム アーキテクトは、アプリケーションに合わせたサーバ能力の拡張、より進んだサーバ間のリソース共有化、Cisco UCS Manager を介した一括統合管理ができます。このホワイト ペーパーの目的は、クラウド規模のコンピューティングに関連するインフラストラクチャの動向を説明し、Cisco UCS M シリーズ プラットフォームの中核をなす技術、設計、および基本的な管理の考え方を紹介することです。


コア数やメモリ容量の多いサーバを中心とした構築は一般的には有効な方法ですが、大容量・大型化が常に良いとは限りません。1 つの方法だけで、どのような用途にも対応できるソリューションはありません。サーバ市場を見てみると、ベンダーは、ラック マウントとブレードという 2 つの基本的なタイプのサーバを提供しています。サーバ インフラストラクチャを構築する場合、選択可能なハードウェアは限られており、ハードウェアをサービス・アプリケーションに合わせる方法を見つける必要があります。アプリケーション種類の変化や展開規模の変化は、アプリケーション要件に合わせて、従来のサーバハードウェアからの選択・利用が最適とは言えなくなってきています。このような課題のため、サーバ ベンダーは、高密度コンピューティング プラットフォームとして知られる新しいタイプのコンピューティング システムを開発・提供しています。これらのプラットフォームは、一定のスペース内でより多くのサーバを利用できるようにすることで、特定の市場ニーズに対応します。Cisco UCS M シリーズ プラットフォームは、このアプリケーション要件に対応できるだけでなく、重複するコンポーネント・インフラストラクチャを最小限に抑え、ケーブル数を削減して、データセンター内のすべてのプラットフォームにおける統合管理を実現するユニファイド ファブリック アーキテクチャを提供します。

インフラストラクチャとアプリケーションの動向


コンピューティング プラットフォームがより強力になるにつれ、1 つのサーバ上で1つのベアメタル OS およびアプリケーション層を実行する方法は、コスト効率が良くないことが明らかになりました。これは、サーバの仮想化を促進する要因の 1 つでした。過去数年間で、データセンターは、ほとんど、または全く仮想化されていない状態から、95 % 以上のワークロードが仮想化された状態へと変化しました。仮想化には、コスト削減に加えて、ハード管理工数の削減やセルフサービス化の利点もあります。

このような動向から、ほとんどの CPU メーカーやサーバ ベンダーが仮想化アーキテクチャに対応するプラットフォームを提供しているのは当然といえます。しかし、データセンターとしての規模拡大およびクラウド コンピューティングにより、アプリケーション開発に新しい動向が出てきています。単一アプリケーションベースのシステム化と高度に構造化されたデータ蓄積の時代は過去のものになりつつあります。ネットワーク化された世界で生成される膨大なデータに対処するため、新しいクラスの分散アプリケーションが開発されています。これらは高度な分散処理の方式を取る事により、1 つのサーバ当り限定的な量のプロセッサ、メモリ、I/O しか必要としません。今日提供されている一般サーバサイズは、この分野では多くの場合過剰です。また、これらのアプリケーションは、複数の物理エンティティ間でワークロードを分散することができ、ハードウェア障害に対して高い回復力があります。図 1 は、これらのアプリケーション アーキテクチャの違いを比較しています。

図 1 企業と クラウド規模のアプリケーション アーキテクチャ

図 1 企業と クラウド規模のアプリケーション アーキテクチャ


ラック サーバのデザイン

図 2 に示すように、典型的な 1 ラックユニット(1RU)ラック サーバのデザインは、24 個の DIMM スロット、ハイエンド RAID 用の PCIe スロットとネットワーク インターフェイス、オンボードのストレージ コントローラとネットワーク インターフェイス、8 個の 2.5 インチ ディスクドライブ ベイ、冗長電源、冷却ファンなど、大量のリソース要求に対応するオプションを搭載できるようデザインされています。このデザインの目標は、できる限り多くのニーズを満たすことです。アプリケーションにとって、廉価なシステムが十分な場合は、廉価な CPU の1つ、少量のメモリ、オンボードのネットワークおよびストレージ コントローラが選択できます。よりハイエンドにする必要がある場合は、最大限のオプションを選択できます。ただし、どちらの構成でも、データセンターのラック内で使用されるサーバスペースは同じであり、電力と冷却はオプションを多く選択・搭載したサーバとして対応できる規模にする必要があります。また、これらのアプリケーションをサポートするために追加するサーバが増えれば増えるほど、必要なネットワークの量や購入するハード ドライブの数が増加します。さらに、サーバハードウェアを更新する場合には、ネットワーク インターフェイス、CPU、メモリ、ストレージ コントローラ、ハード ディスクなど、すべてのコンポーネントを交換することになります。

図 2 1RU ラック サーバ

図 2 1RU ラック サーバ


密度が最適化されたサーバ

サーバ ベンダーにとって共通のテーマは、サーバ自体はより小さなユニットレベルに縮小しながらも、標準的なデータセンターの幅に合ったシャーシ内にそのサーバを収容することです。このモジュラー化したサーバは、データセンター内のスペースを最適化できます。これはブレード シャーシに似ていますが、サーバ 1 台当りはより小規模で、統合型のインフラストラクチャと管理にはそれほど重点が置かれていません。これらのデバイスの目的は、電力と冷却、また場合によってはネットワークも、集約したシート メタル コンテナ(シャーシ)内に配置する小型化されたサーバ(カートリッジ)を搭載することです。一般的な例を図 3 に示します。

図 3 サーバの小型化

図 3 サーバの小型化


しかし、このサーバデザインをよく見てみると、多くの場合は 1RU サーバを必要最低限の装備にした構造であることがわかります。このような小型サーバは、一般に、シャーシ内に収容されるカートリッジと呼ばれます。各サーバ カートリッジには、個別のストレージ コントローラ、ネットワーク コントローラ、ブレード管理コントローラ、およびハード ドライブがあります。これらのリソースは、カートリッジ内のサーバ専用であり、シャーシ内の他のサーバが使用することはできません。サーバには独自のネットワークがあり、シャーシにアグリゲーション スイッチが用意されていない場合には、各サーバ毎にトップオブラック スイッチに接続する必要があります。また、通常、コスト削減のために、各サーバのネットワーク帯域幅やストレージ コントローラ機能には制限があります。この考え方は出発点としては有効ですが、台数の規模に対処できるようにサイズを小型化しているだけです。データセンター内でこれらのサーバを稼動させる場合には、導入、運用、ライフサイクル管理など、考慮すべき要素がほかにも多数あります。

サーバ コンポーネントの分解


Cisco UCS M シリーズ プラットフォームは、異なるアプローチを取っています。Cisco UCS M シリーズでは、統合型インフラストラクチャに基づき、実績あるシスコの専用集積回路(ASIC)の設計やテクノロジーを活用して、サーバ カートリッジからネットワーク コンポーネントやストレージ コンポーネントを分離し、シャーシ内のサーバに必要に応じて分配できる柔軟で構成可能なリソースとして提供します。また、これらの共有リソース化と合わせて、サーバ管理コントローラもオンボード コンポーネントに分離するので、個別に管理される別々のアドイン カードは必要ありません。UCS M シリーズのサーバモジュールは、シャーシ リソースとの接続に標準 PCIe を備えた、単なる CPU とメモリです。シャーシ内で共有されるコンポーネントは、電力、管理、冷却、ストレージ、およびネットワークになります。図 4 は、Cisco System Link Technology を使用しコンピュート(CPU・メモリ)部分と、ストレージおよびネットワーク コンポーネントの分解を示しています。

図 4 サーバコンポーネントの分解

図 4 サーバコンポーネントの分解


これらのリソースを共有する機能と共に、構成とパフォーマンスの柔軟性も実現しています。一般的なモジュラーサーバ設計による各サーバでのコスト削減の維持、およびネットワーク インターフェイス、管理機能、ストレージのコントローラの最小化に重点を置くものではなく、Cisco UCS M シリーズでは、RAID コントローラをシャーシ内に設置して、高度な RAID 機能とキャッシングを提供できるようにしています。また、ドライブ リソースをコンピューティング リソース間で必要に応じて分配することもできます。これにより、各サーバは、その特定のデバイス上のドライブに応じて制限されることも、ディスク自体を余剰に提供することもありません。また、ネットワーク構成の柔軟性も非常に高いです。各サーバが利用できるネットワーク インターフェイスの数、およびスループットは、アプリケーションのニーズに基づいてカスタマイズできます。ユーザがプログラムによって定義できるように、一元的なポリシーからこれらのサーバ インスタンスを、すべて標準の Cisco UCS Manager サービス プロファイルを通じて設定できます。また、この設定は物理ハードウェア独自アドレス等の属性から独立しており、インフラストラクチャのライフサイクル管理、保守、追加導入作業などが合理化できます。

リソース共有は、Cisco System Link Technology によりミッドプレーンを介してコンピューティング リソースを含むカートリッジと接続することで行われます。ネットワーク、管理、電力、冷却、およびストレージ コンポーネントは、サーバ ノードではなく、シャーシに含まれています。図 5 は、シャーシ内のコンピューティング ノードからの共有リソースの分割を示しています。

図 5 リソースの分割

図 5 リソースの分割


Cisco UCS M シリーズ リソースの分解を実現しているコア技術が、Cisco System Link Technology です。

Cisco System Link Technology


Cisco UCS プラットフォームは、リソースの柔軟性と拡張性を実現するユニファイドファブリックの概念を中心にデザインされています。Cisco UCS 統合型アーキテクチャの基盤は、Cisco ASIC を介して Cisco UCS 仮想インターフェイス カード(VIC)によって提供される機能です。VIC を支えるシスコのテクノロジーは、最新世代の ASIC で同時に複数のサーバに接続する複数の PCIe バスを提供できるように拡張されています。この第 3 世代の Cisco ASIC には、System Link Technology が搭載されています。このテクノロジーは、ローカル CPUに対して コンプレックスで使用するために仮想デバイスを PCIe ホスト インターフェイス上に作成して、PCIe バスを各サーバに拡張します。これは OS では、ローカル PCIe デバイスと見なされます。また、I/O トラフィックはホスト PCIe レーンを経由して ASIC に渡され、ローカル ストレージやネットワーク インターフェイスなど、適切な共有リソースにマッピングされます。

このテクノロジー全体は Cisco UCS の新機能ではありません。実際には、Cisco UCS アーキテクチャで提供される柔軟性なインフラストラクチャの中核となるものです。Cisco UCS に詳しい方は、VIC によって、ホスト OS に提供する適切なイーサネットまたはストレージ インターフェイスを構成できることを知っています。これらは、Cisco UCS Manager の概念では仮想ネットワーク インターフェイス カード(vNIC)と仮想ホスト バス アダプタ(vHBA)として知られています。OS からは、vNIC と vHBA は PCIe エンド デバイスと見なされ、物理 PCIe デバイスと同じように通信します。

Cisco UCS M シリーズ プラットフォームでは、vNIC 機能を引き続き提供しますが、さらに、System Link Technology により、仮想化された共有ローカル ストレージを使用して新しい機能が提供されます。図 6 は、どのように System Link Technology によって仮想ネットワーク インターフェイスと仮想ストレージ コントローラが I/O 用にシステムに提供されるかを示しています。

図 6 仮想 I/O デバイス

図 6 仮想 I/O デバイス


この仮想ストレージ コントローラは、シャーシ内の共有ストレージ コントローラとハード ドライブを介してサーバに提供される仮想ドライブへのアクセスを提供します。仮想ストレージ コントローラにより、SCSI NIC(sNIC)として知られる新しい PCIe デバイスが導入され、OS に提供されます。OS では、これらのデバイスをローカルに接続された SCSI デバイスと見なします。

仮想化された共有ローカル ストレージ


共有ローカル ストレージは、2 つの主要コンポーネントによって実現されます。サーバ レベルでは、仮想ストレージ コントローラである sNIC です。シャーシ レベルでは、物理ストレージ コントローラです。これらの 2 つのコンポーネントは緊密に統合されており、Cisco UCS Manager 管理構造内では論理ユニット番号(LUN)と呼ばれ、コントローラによって仮想ドライブとして参照される仮想ドライブを各サーバに提供します。仮想ドライブは、M シリーズ シャーシの物理ドライブ上に設定される RAID ドライブ グループから分割することができます。Cisco UCS Manager では、このストレージの一元化されたポリシーベースの作成とサービス プロファイルへのストレージのマッピングが可能です。これらのドライブ グループによって提供された仮想ドライブは、シャーシに設置されたサーバで使用できるようになります。図 7 は、共有ストレージ リソース内の複数のドライブ グループと仮想ドライブの構成を示しています。

図 7 Cisco UCS M シリーズでの仮想ドライブ

図 7 Cisco UCS M シリーズでの仮想ドライブ


この構成は、サービス プロファイル内のドライブ グループ ポリシーの導入から始まります。ドライブ グループは、ドライブ数、RAID タイプ、ストライピング、ライトバックの特性などを定義します。シャーシ内には、OS に提供する仮想ドライブの保護やパフォーマンスのニーズに応じて、単一または複数のドライブ グループを配置できます。この例では、Cisco UCS M シリーズ シャーシ内にある 4 つの利用可能なソリッド ステート ドライブ(SSD)を 2 つのドライブ グループに分割しています。1 つ目のドライブ グループは RAID 1 であり、ドライブ障害に対する保護が提供されます。このグループは、保護する必要があるブート ディスクやその他のデータに使用できます。2 つ目のドライブ グループは RAID 0 グループであり、仮想ドライブにおいて、容量と早い性能を提供します。この例では、このグループは、アプリケーションで必要とされるワークスペースにすることができます。ここで重要な点は、このシステムでは、保護のタイプや、サーバに提供されるデータの読み取り/書き込みの特性について柔軟性が実現されることです。

初期状態では、コントローラは最大 64 台の仮想ドライブの構成をサポートします。これらのドライブは、そのシャーシ内のサーバに提供します。サーバは、アプリケーションのニーズに基づいて、複数の仮想ドライブを使用して構成できます。仮想ドライブのインスタンス化と結びつけは、Cisco UCS Manager 内のサービス プロファイルの機能です。管理者は、サーバの作成時、仮想ドライブを作成してサーバに割り当てます。それには、そのサービス プロファイルのストレージ LUN を作成し、作成先となるドライブ グループを選択します。そのドライブ グループが存在し(または、Cisco UCS Manager プロセスで作成でき)、利用可能な容量をもった仮想ドライブは、シャーシ上に作成され、サービス プロファイルにリンクされます。仮想ドライブは、サービス プロファイルを使用して作成され、サーバに割り当てられると、そのサービス プロファイルにバインドされている物理サーバからのみアクセス可能となります。この割り当ては、共有ブロードキャスト メディアを介してではなく、ファブリック内の PCIe レーンのマッピングによってセグメント化が維持されます。

仮想ストレージ コントローラ


仮想ストレージ コントローラ、または sNIC は、OS が認識する PCIe デバイスです。図 8 に示すように、サーバから仮想ドライブへの SCSI コマンドの経路を提供するのがこのデバイスです。このコントローラは、OS にとって新しいデバイスであり、OS にロードされる sNIC ドライバを使用します。sNIC ドライバは、新しい PCIe デバイスのため、一部の OS 配布のドライバには含まれません。その場合、サーバ上でストレージ デバイスを認識するために、インストール時に sNIC ドライバをロードする必要があります。このドライバは、eNIC ドライバや fNIC ドライバのように、OS ベンダーによって認定され、最終的にコア OS インストール パッケージの一部として含まれる予定です。ドライバが存在する場合は、仮想ドライブは OS で認識され、RAID コントローラを介して接続された標準的なハード ドライブとして提供されます。このドライバでは、コントローラへの送信時に SCSI コマンド セットを変更せず、ストレージ コントローラを OS に提供する方法とコマンドをコントローラに送るための適切なフレーミングを提供します。

図 8 仮想ストレージ コントローラとしての sNIC

図 8 仮想ストレージ コントローラとしての sNIC


System Link Technology による完全なサーバの構築


Cisco UCS プラットフォームは、リソースの柔軟性と拡張性を実現するユニファイドファブリックの概念を中心に構築されています。このアーキテクチャの基盤は、仮想インターフェイス カード内の Cisco ASIC テクノロジーです。M シリーズ プラットフォームの土台は、この同じ革新的なテクノロジーに基づく第 3 世代の ASIC です。この ASIC により、OS に対してvNIC(イーサネット インターフェイス)と sNIC(ストレージ コントローラ)をサーバの専用 PCIe デバイスとして提供します。

System Link Technology は、OS に対する PCIe デバイスの提供に加えて、シャーシの特定のアップリンク ポートに vNIC をマッピングする方法を提供します。また、QoS(Quality of Service)ポリシー、レート制限ポリシー、および VLAN マッピングも提供します。sNIC については、シャーシ コントローラ ドライブ グループ上の仮想ドライブ リソースの特定サーバへのマッピングを提供します。これは、Cisco UCS M シリーズ サーバにおける柔軟なリソースの共有と構成を実現する、コアとなるテクノロジーです。

System Link Technology は、標準の PCIe 機能に基づいています。図 9 は、PCIe 接続の 3 つの主要コンポーネントを示しています。

図 9 Cisco System Link Technology の PCIe アーキテクチャ

図 9 Cisco System Link Technology の PCIe アーキテクチャ


まず、PCIe ルート コンプレックスはPCIe エンドポイントとなるストレージ コントローラに接続されます。次に、各サーバは、そのサーバの ASIC 上に作成される仮想 PCIe デバイス(vNIC と sNIC)のルート アクセスを提供する PCIe インフラストラクチャにホスト インターフェイスを介して接続されます。ホスト インターフェイスは、本システムの第 1 世代のサーバ向けに 2 つの PCIe Gen3 レーンで構成されています。System Link Technology と M シリーズ シャーシは柔軟性と耐久性を実現するように設計されているため、1 つのスロットで利用可能な PCIe レーンの数は変更も可能です。2 つの 40 Gbps アップリンクは vNIC のネットワーク接続を提供します。

この ASIC は PCIe シングル ルート I/O 仮想化(SR-IOV)に対応していますが、図 9 に示されているように、この機能はこれらのサーバ上では使用されていません。シスコのインターフェイス仮想化テクノロジーの鍵は、第 1 世代からそうであったように、vNIC と sNIC が、各サーバの PCIe ツリー上に作成される仮想機能(デバイス)ではなく、PCIe の物理機能(デバイス)として表されることです。これにより、OS では、各 vNIC を一意に構成可能および管理可能なイーサネット インターフェイスとして、また各ストレージ コントローラをインフラストラクチャ内のマッピングされた仮想ドライブと通信できるデバイスとして見なすことができます。対照的に、SR-IOV デバイスは物理機能(デバイス)内の仮想機能(デバイス)です。仮想機能は、すべての構成リソースに対する物理機能に依存しており、フル機能を備えたリソースではありません。また、SR-IOV デバイスには OS でのソフトウェア サポートも必要です。シスコの仮想化テクノロジーでは、sNIC と vNIC は、SR-IOV のサポートを必要としない完全に物理機能として構成可能かたちで OS に提供されます。

図 9 には明示されていませんが、System Link Technology には、RAID コントローラの共有リソースへのサーバ アクセスを提供する PCIe マルチルート I/O 仮想化(MR-IOV)が組み込まれていないことに注意する必要があります。

MR-IOV は、複数のホストのルート コンプレックスによる PCIe エンドポイント デバイスの共有を可能にする新しいテクノロジーです。System Link Technology では、sNIC とコントローラの両方が同じファブリックに含まれているため、このテクノロジーは必要ありません。ストレージ コントローラの観点からは、仮想ドライブへのすべての I/O 要求は単一のホストであるシステム ASIC より送られてきます。ASIC は、ASIC 内に存在する各 sNIC からの要求を変換し、コントローラによって提供された仮想ドライブにマッピングします。これは、コントローラまたは OS によるMR-IOV 機能のサポート要件は必要ないことを意味します。System Link Technology は、Cisco UCS M シリーズの基本的な構成要素であり、リソースを分解してシャーシ内のすべてのコンピューティング ノード(サーバ)で共有するためのシームレスな方法を提供します。

管理に関する考慮事項


これらの機能を実現するテクノロジーよりさらに重要なのは、サーバ エンティティの構成と管理を提供するポリシー駆動型の構造です。クラウド規模のアプリケーションには、非常に多数のサーバから構成される、異なるタイプの物理インフラストラクチャが必要です。数百、数千というサーバを扱う場合、それらのサーバの導入と運用は、システム アーキテクチャ全体の重要な要素となります。Cisco UCS M シリーズのサーバとシャーシの管理には、Cisco UCS Manager を使用します。Cisco UCS Manager では、基盤となるテクノロジーにより、サーバ コンポーネントの分解を可能にしてオープン XML API を使用したポリシーベースの管理を提供と、拡大する戦略的パートナーシップもとづくエコシステムへの対応、単一の Cisco UCS Manager ドメインでの 20 台の M シリーズ シャーシの構成と管理を提供します。Cisco UCS Manager は、Cisco UCS B シリーズ、C シリーズ、および M シリーズ サーバを管理するための共通プラットフォームです。図 10 は、さまざまな場所に分散した複数のドメインを一元管理できるツールが Cisco UCS Central Software によってどのように提供されるかを示しています。

図 10 規模に応じた Cisco UCS M シリーズの管理

図 10 規模に応じた Cisco UCS M シリーズの管理


まとめ


Cisco UCS M シリーズ サーバは、シャーシ内での共有リソース化を実現してクラウド規模のアプリケーションに対応するように構築された、新しいクラスの Cisco UCS サーバです。これにより、インフラストラクチャ アーキテクトは、アプリケーションによって必要とされる拡張性と柔軟性を確保しながら、適切な規模のサーバを提供できます。このシステムでは、特許取得済みで実績のあるシスコの ASIC テクノロジーを使用して、共有のネットワークおよびストレージ リソースをシャーシ内のすべてのコンピューティング要素に提供します。また、Cisco UCS の基盤である同じオープン XML API およびポリシーベースの管理インフラストラクチャを使用しています。根本的には、Cisco UCS M シリーズは、Cisco UCS プラットフォームの拡張であり、より一般的な既存の B シリーズ ブレードサーバおよび C シリーズ ラックサーバを補完するものです。Cisco UCS M シリーズは、仮想化技術を利用しなくても、より小さなコンピューティング ユニットを実現する、まったく新しい能力を提供します。

詳細情報


Cisco UCS M シリーズ サーバについての詳細をご覧ください。または、最寄りの代理店にお問い合わせください。Cisco Unified Computing System の管理についての詳細をご覧ください。Cisco Unified Computing System についての詳細をご覧ください。

著者について


Steve McQuerry(テクニカル マーケティング エンジニア、CCIE #6108)は、20 年以上 IT 業界に携わっています。この間、彼は、設計、運用、データセンター アーキテクチャなど、さまざまな分野で経験を積み、サーバ管理者、ネットワーク管理者、コンサルタント、インストラクター、著者などを務めてきました。Steve は、2005 年 1 月からシスコに勤務しており、データセンター テクノロジーを専門とするコンサルティング システム エンジニアおよびテクニカル ソリューション アーキテクトとして Enterprise Sales チームに所属しています。2011 年 5 月には、テクニカル マーケティング エンジニアとして UCS 事業部に参加しました。このグループ内では、プラットフォーム間での UCS アーキテクチャと管理を担当しており、特に UCS 管理ドメインでの M シリーズおよび C シリーズ プラットフォームの統合と運用に注力しています。シスコの従業員になる前は、シスコ認定インストラクターとして働いていました。また、ネットワークや認定資格に関する Cisco Press の書籍の著者でもあります。Steve は、イースタン ケンタッキー大学で工学物理学の学士号を取得しています。Twitter(@smcquerry)で Steve をフォローできます。