プライベート・クラウド・データ・センターをまとめる作業は、一からスポーツ・カーを組み立てるようなものです。適切なエンジン、部品、機材を選び、道路やドライバーが求める性能ニーズを満たさなければなりません。ハードウェアとソフトウェアのイノベーションにより、ITアーキテクトは、役に立たない中古車ではなくランボルギーニのような性能を発揮するデータ・センターを構築することが可能になりました。
オンプレミスのプライベート・クラウドは、常に監視、管理、保守が必要です。ドライバの交換やオーバープロビジョニングなどの運用コストは、あっという間に増えていきます。これによりデータ・センターの総所有コスト (TCO) は跳ね上がり、会社の利益を食いつぶしてしまいます。特にキャプチャ、生成、活用されるデータ量は、年々飛躍的に増大しています。
こうした問題こそ、Seagateの言う「コンポーザビリティのメガトレンド」が現在進んでいる理由です。最新のコンポーザブル・データ・センターでは、ばらばらに分散されていながら、最適なタイプのファブリックおよび帯域幅と相互につながっているコンポーネントを使って、各プライベート・クラウド・サーバーを構成することができます。こうしたコンポーザビリティによって、さまざまなアプリケーションやデータ・ワークフローのデータを柔軟に管理し、アクセスすることが可能になります。
ITアーキテクトは、オンプレミスのプライベート・クラウド・ソリューションを使用するか、サードパーティがホストするパブリック/プライベート・クラウドを利用するかを決定しなければなりません。パブリック・クラウドは、複数の顧客がコンピューティング・サービスを共有し、外部のデータ・センターでホストされるものです。サードパーティのクラウド・プロバイダは、同じく外部でホストされるものの、サービスの共有は行われないホステッド・プライベート・クラウドも提供しています。
プライベートのオンプレミス・クラウドは、企業独自のデータ・センターが管理・維持を行い、他の企業とはサービスの共有を行わないものです。オンプレミスのプライベート・クラウドを利用することの主なメリットには、高い安心感、柔軟性、性能の向上があります。ユーザーは、画一的なアプローチではなく、リソースやサービスをカスタマイズして、ハードウェアをソフトウェアの要件に合わせることが可能になります。また、サーバーのセキュリティ、拡張性、構成を自由にコントロールすることができます。
アプリケーションの要求の増減に合わせて、コンポーネントとサーバーは互いに連動しながら作業負荷を調整します。ITアーキテクトは、さまざまなメーカーの幅広いハードウェアやコンポーネントを使って、データ・センターを構築できるようになりました。実際に従来のデータ・センターのインフラストラクチャをばらばらに解体しています。シャーシを解体したら、取り付けたリソースをより効率的に利用できるようにデータ・センターを再構築します。ITアーキテクトはコストを追加して不要なハードウェアを購入する必要がなく、ダウンタイムなしで簡単にコンポーネントを交換できます。
プライベート・クラウドにおけるデータ・センターの分散化（分散）とコンポーザビリティ（構成可能性）は、従来のネットワーク・アーキテクチャからパワフルで要求の厳しいシステムを機能させることができる現在のダイナミックなインフラストラクチャへと進化しました。コンポーザブルな分散化には、低レイテンシー、セキュリティやデータ管理の強化などのメリットがあります。
従来型データ・センターの限界
データの飛躍的な増加、ソフトウェア・アプリケーションの複雑化によって、従来型のITアーキテクチャは限界に達しています。中央処理装置 (CPU)、ダイナミック・アクセス・メモリ装置 (DRAM)、ストレージ・クラス・メモリ装置 (SCM)、グラフィック処理装置 (GPU)、ソリッド・ステート・ディスク装置 (SSD)、ハードディスク・ドライブ (HDD) は、データ・センターを構成する重要なコンポーネントです。これらのコンポーネントは通常、1つのボックスまたはサーバーにまとめて格納され、データ・センター構築の基礎としての役割を果たします。このような従来型のエンタープライズ・クラウド・アーキテクチャでは、HDDなどの各コンポーネントはサーバーの他の部分に直接接続されます。
データ・センターは元々、1つのボックス当たり1つのアプリケーションという枠組みの下で運用されていました。それが、アプリケーションが1台のサーバーで提供できるストレージやデータ処理機能を超えてしまい、ITアーキテクトは複数のサーバーをクラスタごとにグループ化し、リソースのプールとして利用できるようにし始めたのです。IBM、EMC、NetApp、そしてSeagate所有のDot Hillチームなどの独自のソリューションが、こうしたプール化サーバー・リソースを作る業界の最初の動きをリードしました。
データ・センターの規模はその後さらに拡大し、アプリケーションにより多くのストレージ、帯域幅、あるいはCPUパワー、追加サーバー、あるいはノードが必要になったら、クラスタに追加できるようになったことで、ソフトウェア・アプリケーションの複雑化に合わせてニーズを満たすことができるようになりました。プール化リソースのクラスタ・モデルは、現在コンバージドおよびハイパーコンバージド・エンタープライズ・クラウド・インフラストラクチャとして知られているものを形成します。これは、VMwareなどのエンタープライズ・ハイパーバイザー・アプリケーションを使用します。
ノード・クラスタは、初期のクラウドではその目的を果たしていましたが、オーバープロビジョニングになりがちです。これは、ITアーキテクトが追加サーバーを購入し、そこに必要以上のリソース、つまり使用されないリソースが含まれている場合に発生します。クラスタ・アプローチには、十分なストレージ容量や処理能力などのメリットがあるものの、サーバー内に使用されていないリソースがあるのは非効率的です。とは言っても、ソフトウェア・アプリケーションの要求に合わせて、データ・センターが特定のリソースやワークロードだけを動的に拡大できるようにする方法はなかったため、ITアーキテクトはオーバープロビジョニングに頼るしかありませんでした。コストの増大は、オーバープロビジョニングから派生する当然の副産物です。
ITアーキテクトにとって、「どのハードウェア・コンポーネントを使ってサーバーを構成できるか」という点に関しても制限がありました。各サーバーまたはクラスタのハードウェアは、互換性のために一社のメーカーから購入しなければなりませんでした。また、さまざまなメーカーのハードウェアの通信と連携をサポートするオープン・アプリケーション・プログラミング・インターフェイス (API) もありませんでした。例えばアーキテクトがCPUを別のメーカーのもっと高速なものに替えたくても、互換性の問題で実現できないということがよくありました。異なるメーカーのハードウェアが互いに通信し、連携することができなかったのです。
しかし、従来型データ・インフラストラクチャの足かせとなっているのは、互換性の問題だけではありません。収集、保存、分析の対象となるデータの量が膨大であるという点も問題です。ビッグデータの爆発的増加は、従来型のプライベート・クラウド・クラスタのストレージをいっぱいにしてしまっているだけでなく、データ処理の問題も生み出しています。各CPUは、他のアプリケーションとリソースを共有するためにローカル・データの処理に忙しすぎて、全体的なリソースがデータ・センターの非効率性を増幅する要因になっています。
例えば、複雑な人工知能 (AI) アプリケーションでは、大量のデータを短時間で処理する能力が必要になります。AIアプリケーションがクラスタ化されたデータ・センターを活用している場合、データの収集や処理に問題が起こる傾向が高くなります。また、アプリケーションがより高い処理能力を必要とする場合、追加の作業負荷を別のクラスタに移行させる手段がありません。レイテンシー、すなわちデバイス間のデータ転送の遅れもまた、問題の1つです。
例えば、同じデータ・センターに2つのサーバー・クラスタがあり、そのうちの1つに過度の負担がかかっており、もう1つはあまり使用されていないとします。この過度の負担がかかっているほうのクラスタを使っているアプリケーションは、速度が落ちたり、性能の問題が発生したりする可能性がありますが、これはあまり使用されていないオーバープロビジョニングされているほうのクラスタを統合することで簡単に解決できる問題です。しかし、アプリケーションが利用できるリソース・プールは、そのアプリケーション専用の1つのクラスタに限定されてしまいます。これこそ、ITアーキテクトがデータ・センターをもっと効率的な方法で構成するための方法を探し続けている理由です。
こうしたプロプライエタリの時代は、終わりを迎えようとしています。最先端のソフトウェア・アプリケーションでは、従来のクラスタ化されたデータ・センターよりも高い処理能力やストレージ能力が求められます。またITアーキテクトは、デバイス間の通信を可能にするオープンAPIがないことで、使用できるハードウェアに関して制限を抱えています。ITアーキテクトが前進するためには、最新のアプリケーションがプライベート・クラウド・アーキテクチャにどのように影響し、コンポーザビリティが従来のITインフラストラクチャが抱える問題の克服にいかに役立つかをより深く理解する必要があります。
アプリケーションがプライベート・クラウド・データ・センターに与える影響
コンポーザビリティのメガトレンドを後押ししている最大の要因に、ソフトウェア・アプリケーションの要求があります。AIやビジネス分析などのソフトウェアでは、各アプリケーション固有のニーズに合わせた複雑なハードウェア要件が求められます。これにより、ストレージと処理のリソース・プールの間で過酷な競争が生まれます。
先ほど述べたとおり、従来型のデータ・センターは今や限界に達しており、さまざまなアプリに求められる処理能力がクラスタ化モデルの限界を超えてしまうことも日常的に起こっています。さらにアプリケーションの要件は常に進化しており、すぐに変わってしまいます。例えば、新しいバージョンのビジネスアプリで古いバージョンの2倍のストレージと処理能力が必要になることがあります。それが専用クラスタの限界を超えてしまうと、さらにハードウェアを追加で購入しなければならなくなります。ソフトウェアの進化が、従来型のクラスタ化データ・センターに負担をかけているのです。
コンポーザビリティによって、アプリケーションは専用クラスタ以外のリソース・プールにアクセスできるようになり、オーバープロビジョニングされているサーバーの処理能力やその他のリソースを活用できるようになります。各アプリケーションのコストのニーズに合わせて、各CPU、GPU、またはストレージ・ノードを個別に拡張することができます。
処理要求が高まることで、従来型データ・センター・ファブリック内でも問題が発生します。データ・センター・ファブリックは、さまざまなノードやクラスタをつなぐものです。理想的なのは、最新のソフトウェア・アプリケーションのニーズを満たすコンポーザブルファブリックが柔軟なファブリックを生み出し、このファブリックがすぐに構成可能な状態になり、アプリケーションの処理ニーズの高まりに合わせて、インフラストラクチャとリソースを動的にプロビジョニングするという状態を実現することです。目標は、高度なアプリケーションが高速処理だけでなく、アプリケーションが最適なスピードで実行されるようにリアルタイムの処理を行えるようにすることです。
コンポーザビリティと分散化は、最先端のソフトウェア・アプリケーションの要求を満たすために欠かせないものです。従来型のクラスタ化アーキテクチャでは単純にタスクを果たすことができず、AIのような高度なアプリケーションが適切に機能するように十分なスピードで情報がイーサネット・ファブリック上を移動することができません。サーバー・ボックス内のコンポーネントを分散させて、APIプロトコルと通信するための手段を提供することで、データ・センターはコスト効率の高い形で複雑なアプリに対応できるようになります。
プライベート・クラウド・アーキテクチャの分散化がもたらすメリット
プライベート・クラウド・データ・センターの分散化は、従来型のサーバー・ボックス・モデルとはまったく違う方法を意味します。CPU、GPU、全ティアのメモリ、SSD、HDDストレージなどのリソース・コンポーネントをすべて分散させて、適切なファブリック内で自由に再構成することができます。その後、物理サーバー内のコンポーネント構成ではなく、アプリケーションのニーズに合わせてこれらのリソースを活用することができます。ネットワーク・ファブリック上でアクセスできるものはすべて、分散させて後から再構成することができます。
例えば、アプリケーションが使用するストレージ・リソース・プールが、データ・センター内のばらばらの場所にある10台のサーバー・ラックのHDDで構成されているとします。アプリケーションが現在使用しているストレージよりもさらに多くのストレージを必要とした場合、1台のHDDがスペースのある別のHDDと通信して、データをシームレスに転送することができます。アプリケーションの要求が高まった際に処理作業負荷を動的にシフトすることもできます。逆にアプリの要求が下がったときは、ストレージと処理を可能な限りエネルギー効率の高い形で再割り当てし、コストのかかるオーバープロビジョニングを削減、あるいは排除することができます。
これは、ひとつのサーバー・ラックに縛られているJBOD（ディスクの束）とはまったく違います。JBODは、アプリケーションがいつでも呼び出すことができるプールに進化したことで、データ・センター・リソースの割り当てが、よりインテリジェントな形で行われるようになりました。アーキテクトはその後、互いに通信できる規格化された外付けストレージに目を向け始めました。
また、分散化によって、規格化されたインターフェイス・モニタリングが登場し、ITアーキテクトはコンポーザブル・データ・センター全体を管理することができるようになっています。SSD、HDD、CPU、あるいはファブリック・コンポーネントなど、要件ベースのハードウェアの選択は、従来型データ・センターの分散化とコンポーザブルなデータ・センターの構築への第一歩です。アーキテクトは依然として、シームレスな統合やデータ・センターを管理するための単一のユーザー・インターフェイスを実現するために、RedfishやSwordfishなどの正確なオープンAPIプロトコルを必要としています。オープンAPIは、異なる言語を使用するハードウェアやソフトウェアがコミュニケーションを取り、連携することを可能にします。
データ・センターがアプリケーションの構成を決めるのではなく、アプリケーションがデータ・センターの構成を決めるようにしたことで実現したのが、ソフトウェア・デファインド・ネットワーキング (SDN) やソフトウェア・デファインド・ストレージ (SDS) です。SDNとSDSの次なる進化が、ハイパーコンポーズド・データ・センターです。これにより、プライベート・クラウド・アーキテクチャは、Amazon Web Services (AWS) やMicrosoft Azureなどの一部のハイパースケーラーと同等になる可能性があります。ハイパースケーラーとは、大規模な処理能力やストレージの拡大を行うことができる大手データ・センター・プロバイダのことです。データ・センターのネットワークのバックボーンであるイーサネット・ファブリックをカスタマイズして、低レイテンシーHDDデバイスやSSDデバイスと一緒に実行することも可能です。こうしたカスタマイズによって、アプリケーションが低レイテンシー・ファブリックの分散されたリソース・プールを使用できるようになるため、データ・トラフィックや処理の遅れが低減します。
RedfishやSwordfishなどのオープンAPIプロトコルは、すべての分散したコンポーネントを上手く連動させるために欠かせないものです。Seagateには、デバイス間の操作性を促進する特定クラスのデータ・センター製品用として維持している独自のレガシーREST APIがあります。かつて、デバイスの交換、インストール、統合には数週間もの時間がかかりました。APIプロトコルによって、データ・センター・アーキテクトは、アラカルトのプラグアンドプレイのアプローチでハードウェアを調達することができます。異なるメーカーの新しいデバイスを驚くほど短時間でインストールして、機能させることができます。
データ・センターの分散化によって可能になるのが、コンポーザビリティです。アーキテクトはソフトウェア・アプリケーションのニーズに合わせてハードウェア・デバイスを選んだら、未来のコンポーズド・データ・センターを構築、運用、最適化できるようになります。
プライベート・クラウドに最適な最新コンポーザブル・データ・センターの効率性
データ・センターのコンポーザビリティは、分散したすべてのコンポーネントをつなげるだけでなく、データ・センターのコスト効率や性能に関連する重要業績評価指標 (KPI) の向上にも役立ちます。従来型のデータ・センターでは、オーバープロビジョニングが予算に負担をかける最大の要因のひとつでした。データ・センターがオーバープロビジョニングされている際、サーバーとリソースはコストがかかっているのに、使用されていない状態になります。つまり、ITアーキテクトはあまり使用されていないリソース・ブールにお金を払っていることになり、それらのハードディスク・ドライブはプロビジョニングされていないことになります。
プロビジョニングされていないリソースは、使用されていないために帰るべき家のない「孤立したプール」になります。これには、CPU、GPU、フィールド・プログラマブル・ゲート・アレイ (FPGA)、ダイナミック・ランダム・アクセス・メモリ (DRAM)、SSD、HDD、またはストレージ・クラス・メモリ (SCM) が含まれます。こうしたビルディング・ブロックが動的に構成され、APIを通じてアプリケーション専用のハードウェアが作られます。
このように、コンポーザブルなオープン・ソース・データ・センター・アーキテクチャが実現する前は、プライベート・クラウドは一社のベンダーのハードウェアを使って構成するのが当たり前でした。物理的に接続されたデータ・センターは初期費用がかかり、ベンダー固有のアーキテクチャに縛られるため、どんどんコストが高くなります。
パブリック・クラウド・アーキテクチャの一部として、コンポーザビリティのトレンドが人気を集め始めました。AWSやMicrosoft Azureなどがその例です。プライベート・クラウドの展開においても同じようなアプローチを取って、ベンダー・ロックインを避け、複数のベンダーのデバイスを使ってデータ・センターを構築することで、コストを削減することができます。
これにより、IT管理者はストレージに予算をかけて、保存データから洞察や価値を引き出すことができるようになります。
企業は、サードパーティのストレージ・ソリューションを使って、それをデータ・センターに取り入れ、オープン・ソースAPIとシームレスに統合することができます。ITアーキテクトがあるメーカーのSSDが欲しいけれど、データ・センターが別のメーカーのコンポーネントで構成されているというような場合でも、ほぼ問題なくデータ・センターにそのSSDを配置することができます。APIが、すべてのコンポーネントが上手く連携するようにしてくれます。データ・センター管理者は例えば、テレメトリーを介してコンポーネントがどのようにコミュニケーションを取るのかにこだわる必要がなくなり、データ・センターの構成に現在使用されていないベンダーの部品を取り入れる際のコストやストレスを軽減することができます。
プール化または共有化メモリのもう1つの重要な利点は、アプリケーションにノード障害が起こっても、このノードの影響を受ける仮想マシンやコンテナ・クラスタの状態を混乱させることなく切り抜けられる点です。他のノードが仮想マシンのメモリの最新状態を独自のメモリ・スペースにコピーする（プール化メモリ・アーキテクチャの場合）か、あるいは超低レイテンシー・ファブリックでポインタのリダイレクションによるゼロコピー・プロセスを使用して、障害が発生したノードが中断した時点からシームレスに続行する（共有化メモリ・アーキテクチャの場合）かのいずれかの方法をとることができます。これは、信頼性と可用性を向上させるデータ・センターのシームレスなフォールト・トレランス機能の大きな進歩であると考えることができます。
コンポーザブル・アーキテクチャでは、複数のソースからデータの収集や処理をすばやく行い、全体的により効率的な形でインストールされたリソースを活用することもできます。コンポーザブル・データソース・アーキテクチャには通常、物理センサー、データ・シミュレーション、ユーザー生成情報、テレメトリー情報が含まれます。データ・センター管理者は、わずか数分でリソースをまとめて、すぐにアプリケーション間で共有できるようにすることができます。
すべてのリソースが表示される一括ビュー
コンテナ化されたオーケストレーション・クライアントを使ったコンポーザブル・アーキテクチャなら、プライベート・クラウド・データ・センターのオーケストレーションと管理も簡単になります。1つのインターフェイスで、すべてのハードウェアの分散、構成、監視を行うことができます。データ・センター管理者は、どのリソース・プールが使用されているかをリアルタイムで明確に把握し、オーバープロビジョニングがないかを確認することができます。多くの場合、管理は標準ソフトウェアを使って行います。これは独自ソースかオープン・ソースのいずれかになります。
オープン・ソースのコンテナ化環境への新しいソフトウェア・アプリケーションの展開は、ストレージ・リソースを自由に購入して配置できるため、さらに柔軟になります。例えば、データ・センター・アーキテクトは、コストのかかるフラッシュ・ストレージ階層をオーバープロビジョニングする必要がなくなります。これは、物理的な場所に関係なく、必要に応じてアプリケーションの作業負荷を既存のSSDリソースにシフトできるからです。これにより、オーバープロビジョニングを避け、未加工のストレージ容量の増加など、他の目的のために使用できる物理スペースの無駄遣いを避けることができます。
未加工データの飛躍的増加によって、未加工のストレージ容量を拡大する必要性がさらに高まっています。さらに企業は、さらに多くのデータから多くの価値や実用的な洞察を得て、収益を上げるための新しいチャンスを手に入れようと模索しています。何よりも重要なことは、ITアーキテクトが大量のデータを収集、保存、転送できるインフラストラクチャを設計できるという点です。コンピューティング・ハードウェアのレイアウトの効率が高いということは、現代のビッグデータ環境に必要な未加工の大容量ストレージのためのスペースがあるということです。
必要に応じてあらゆるCPUやストレージ・プールを他のデバイスにつなげることができるコンポーザブル・データ・センターがソリューションとなります。他のすべてのデバイスはCSI、Redfish、Swordfishを使って、ソフトウェア・エンジンによって調整される管理ネットワークに接続します。他のすべてのデータ・センターのビルディング・ブロックは、ソフトウェアAPIを通してアプリケーション専用になるように動的に構成することができます。
コスト、性能、効率性
データ・センターにおける分散化とコンポーザビリティのトレンドは、コスト、性能、効率性によって促進されています。CPUがデータ・センターの中心にあり、他のデバイスがすべて同じ箱の中に閉じ込められていた時代はもう終わりです。プライベート・クラウドのアーキテクトは、用途や具体的なニーズに応じて、最適なデバイス、ハードウェア、ソフトウェアを選べるようになりました。
従来型のコンテナ化されたクラスタ・データ・センターは複雑なアプリの使用を可能にしましたが、現代のソフトウェアは非常に高性能であるため、より動的なアーキテクチャが必要になっています。将来、超低レイテンシー・インターフェイスによって、コンポーザブルなGPU、FPGA、メモリが実現するはずです。
コンポーザビリティとは、処理作業負荷がリアルタイムで分散され、使用されていないデバイスと負担を共有し、孤立したデータ・プールを排除することです。その結果、迅速に作業負荷を処理し、低コストで運用できるデータ・センターを実現する見事に構成されたプライベート・クラウド・インフラストラクチャを手に入れることができます。分散化とコンポーザビリティにより、ITアーキテクトは要求の厳しいソフトウェア・アプリケーションのニーズに対応することができます。コンポーザブル・データ・センターは、単なるコンポーネントの寄せ集めではなく、ひとつのデータ・センターとして優れた機能を発揮します。
