組織がハードウェアおよびソフトウェア インフラストラクチャのオプションを評価する場合、新興のハイパーコンバージド インフラストラクチャ カテゴリを選択するか、厳選したベンダーを使用して独自のソリューションを構築するかを決定する必要があります。前者の選択肢を大きく推進するのは、「喉を絞めて窒息させる」という議論です。この議論は何度も聞かれ、主張されてきましたが、それには十分な理由があります。多くの場合、後者のオプションを選択した企業は、インフラストラクチャがダウンしたときに指差しゲームをしているベンダーと取引することになります。ハイパーコンバージド インフラストラクチャの真の価値は、導入の容易さ、一元管理、システムの高度な最適化にあります。言い換えれば、インフラストラクチャを簡素化および合理化し、管理者がより重要なことに再びエネルギーを集中できるようにすることです。ハイパーコンバージドを検討する場合、パフォーマンスは一般に低レベルの懸念事項となります。
組織がハードウェアおよびソフトウェア インフラストラクチャのオプションを評価する場合、新興のハイパーコンバージド インフラストラクチャ カテゴリを選択するか、厳選したベンダーを使用して独自のソリューションを構築するかを決定する必要があります。前者の選択肢を大きく推進するのは、「喉を絞めて窒息させる」という議論です。この議論は何度も聞かれ、主張されてきましたが、それには十分な理由があります。多くの場合、後者のオプションを選択した企業は、インフラストラクチャがダウンしたときに指差しゲームをしているベンダーと取引することになります。ハイパーコンバージド インフラストラクチャの真の価値は、導入の容易さ、一元管理、システムの高度な最適化にあります。言い換えれば、インフラストラクチャを簡素化および合理化し、管理者がより重要なことに再びエネルギーを集中できるようにすることです。ハイパーコンバージドを検討する場合、パフォーマンスは一般に低レベルの懸念事項となります。
シンプルなインフラストラクチャというこのアイデアはどのようにして実現されるのでしょうか?この単純化を理解するには、近年のインフラストラクチャの進化について考える必要があります。従来、エンジニアはデータセンターの異種コンポーネントを個別の部品として管理してきました。これは、IT スタッフにとっては少々悪夢のような結果になります。各コンポーネントがどのように連携して機能するか（または機能しないか）を理解する技術者を維持する必要があります。この非効率なアプローチは、認定ガイド、相互運用性マトリックス、そして大きな頭痛の種のようなものを引き起こしました。
統合インフラストラクチャの目標は、互換性の問題を最小限に抑え、コンポーネントを単一のフォーム ファクタに統合して集中管理し、最終的に物事をシンプルにすることです。統合インフラストラクチャにはさまざまな形やサイズがありますが、通常は 4 つのプールに分類できます。
| リファレンスアーキテクチャ | 統合された製品 | ハイパーコンバージェンス | ラックスケール | |
|---|---|---|---|---|
| 特性 | 柔軟、事前定義されたオプション、認定済み、自己構築型 | ベンダーロックイン、単一サポート構造、構築済み | シンプル、ソフトウェア層、集約されたリソース | 柔軟、プール化および細分化されたリソース、モジュール式 |
| 例 | VSPEX、FlexPod | Vblock、Exadata | EVO: RAIL、Nutanix、SimpliVity、HP ConvergedSystem |
リファレンス アーキテクチャでは、誰かが事前に準備作業を行うことで、複雑な条件と相互運用性をすべて方程式から取り除きました。これは本質的に、実証済みの構成を構築するために従うことができる青写真です。各コンポーネントは依然として個別に管理する必要がありますが、インフラストラクチャの構築で最も困難な部分は誰かが行っているため、これは素晴らしいことです。
コンバージド製品には、汎用ビルドと目的ビルドという 2 つのサブタイプがあります。いずれにせよ、管理者はベンダーによって事前に構築された完全なシステムを使用しています。 Vblock は最もよく知られた一般用途のコンバージド インフラストラクチャの 1 つですが、Exadata のような目的構築製品もこのカテゴリにうまく適合します。一般に、オプションは「どのくらい」と「どのくらいの速さ」に制限されており、これは各企業に固有です。
コンバージド インフラストラクチャにとってやや新しいのは、ソフトウェアを使用して個々のコンポーネントのすべてを単一の管理インターフェイスにマスクするハイパー コンバージェンス スペースです。これらは適切に拡張できますが、一般にコンピューティングとストレージを個別に拡張することはできません。
これでラックスケールは残ります。ここでは、細分化されたリソースの合計がさまざまなソースから取得され、一緒にプールされます。 Rackscale を使用すると、管理者は寄せ集められたホワイトボックス サーバーから企業のストレージをすべて取得し、それらを 1 つのプールとしてチェーン化できます。これは、サーバーとストレージ コンポーネントが一致する必要がないため、ハイパーコンバージェンスとは異なります。
インフラストラクチャの統合の鍵はシンプルさであり、それを達成する方法は無数にあります。ますます多くのベンダーがインフラストラクチャに参入しようとしているため、インフラストラクチャ分野では興味深い時期となることは間違いありません。大規模なストレージ アレイにはすでにハイパーバイザーが組み込まれているため、従来のエンタープライズ ストレージ アレイ上でネイティブ アプリケーションを実行できるようになるのは時間の問題かもしれません。
著者について
Mark May は、オハイオ州シンシナティのストレージ エンジニアです。彼は 15 年以上、エンタープライズ ストレージとバックアップの分野で働いてきました。彼は EMC 選出者、Cisco Champion であり、熱心な技術者です。自由な時間には、変化し続けるストレージ業界の詳細を他の人が理解できるように支援することが好きです。彼はオンラインのさまざまな場所で見つけることができますが、最も可能性が高いのは XNUMX つです。 個人のブログ とツイッター @cincystorage.
この話を話し合う
