管理者の手を使わない = ハイパーコンバージェンス?

これはサーバー ハードウェアの分野ではよくある誤解です。 実際には、ハイパーコンバージド ソリューション (すべてが XNUMX つにまとめられている場合) が多くのことに必要です。 歴史的に、最初のアーキテクチャは Amazon と Google によってそのサービスのために開発されました。 そこで考えられたのは、それぞれが独自のディスクを持つ同一のノードからコンピューティング ファームを作成することでした。 これらすべては、システムを形成するソフトウェア (ハイパーバイザー) によって統合され、仮想マシンに分割されました。 主な目標は、XNUMX つのノードを保守するための労力を最小限に抑え、拡張する際の問題を最小限に抑えることです。同じサーバーをさらに XNUMX 台か XNUMX 台購入して、それらを近くに接続するだけです。 実際には、これらは個別のケースであり、より多くの場合、より少数のノードとわずかに異なるアーキテクチャについて話します。

ただし、スケーリングと管理が驚くほど簡単であるという利点は変わりません。 欠点は、タスクごとにリソースの消費方法が異なり、ある場所では大量のローカル ディスクが存在し、別の場所では RAM が少ないなどとなり、タスクの種類が異なるとリソース使用率が低下することです。

セットアップを簡単にするために、10 ～ 15% 多く支払うことになります。 これがタイトルの神話のきっかけとなったものです。 私たちは、このテクノロジーをどこに最適に適用できるかを長い時間をかけて探し、それを見つけました。 実際のところ、シスコは独自のストレージ システムを持っていませんでしたが、完全なサーバー市場を望んでいました。 そして彼らは、ノード上にローカル ストレージを備えたソリューションである Cisco Hyperflex を作成しました。

そして、これがバックアップ データ センター (災害復旧) にとって非常に優れたソリューションであることが突然判明しました。 その理由と方法を今から説明します。 そしてクラスターテストをお見せします。

必要な場所に

ハイパーコンバージェンスとは次のとおりです。

1. ディスクをコンピューティング ノードに転送します。
2. ストレージ サブシステムと仮想化サブシステムの完全な統合。
3. ネットワークサブシステムとの転送/統合。

この組み合わせにより、多くのストレージ システム機能を仮想化レベルで、すべて XNUMX つの制御ウィンドウから実装できます。

当社では、冗長データセンターを設計するプロジェクトの需要が高く、すぐに使えるレプリケーション オプション (メトロクラスターまで) が多数あるため、ハイパーコンバージド ソリューションが選択されることがよくあります。

バックアップ データ センターの場合、通常、都市の反対側、または完全に別の都市にあるリモート施設のことを指します。 これにより、メイン データ センターの部分的または完全な障害が発生した場合に、重要なシステムを復元できます。 販売データは常にそこで複製され、この複製はアプリケーション レベルまたはブロック デバイス (ストレージ) レベルで行うことができます。

したがって、ここではシステムの設計とテストについて説明し、その後、貯蓄データを使用した実際のアプリケーション シナリオについていくつか説明します。

テスト

私たちのインスタンスは 10 台のサーバーで構成されており、各サーバーには 960 GB の SSD ドライブが XNUMX 台あります。 書き込み操作をキャッシュし、サービス仮想マシンを保存するための専用ディスクがあります。 ソリューション自体は XNUMX 番目のバージョンです。 XNUMX つ目は率直に言って (レビューから判断すると) 粗雑で、XNUMX つ目は湿っぽく、XNUMX つ目はすでに非常に安定しています。これは一般向けのベータ テスト終了後のリリースと言えます。 テスト中は何も問題は見られず、すべてが時計のように機能しました。

v4 での変更点たくさんのバグが修正されました。

当初、このプラットフォームは VMware ESXi ハイパーバイザーでのみ動作し、少数のノードをサポートしていました。 また、展開プロセスが必ずしも正常に終了するとは限らず、一部の手順をやり直す必要があり、古いバージョンからの更新で問題が発生し、GUI のデータが常に正しく表示されるわけではありませんでした (ただし、パフォーマンス グラフの表示にはまだ満足していません)。 )、仮想化とのインターフェースで問題が発生することがありました。

現在、幼少期の問題はすべて解決されており、HyperFlex は ESXi と Hyper-V の両方を処理できるほか、次のことが可能です。

1. ストレッチクラスターを作成します。
2. ファブリック インターコネクトを使用せずに、XNUMX ～ XNUMX ノードでオフィス用のクラスターを作成します (サーバーのみを購入します)。
3. 外部ストレージ システムを操作する機能。
4. コンテナとKubernetesのサポート。
5. アベイラビリティーゾーンの作成。
6. 組み込み機能が満足できない場合は、VMware SRM との統合。

このアーキテクチャは主な競合他社のソリューションとあまり変わりませんが、競合他社は自転車を作成したわけではありません。 すべて VMware または Hyper-V 仮想化プラットフォーム上で実行されます。 ハードウェアは独自の Cisco UCS サーバーでホストされます。 初期設定の比較的複雑さ、多くのボタン、テンプレートと依存関係の重要なシステムを理由にこのプラットフォームを嫌う人もいますが、禅を学び、そのアイデアに触発され、もう必要としない人もいます。他のサーバーと連携するため。

このソリューションはもともと VMware 用に作成され、より多くの機能を備えているため、VMware 向けのソリューションを検討します。Hyper-V は、競合他社に遅れをとらず、市場の期待に応えるために途中で追加されました。

ディスクがいっぱいのサーバーのクラスターがあります。 データ ストレージ用のディスク (好みやニーズに応じて SSD または HDD) があり、キャッシュ用に XNUMX つの SSD ディスクがあります。 データストアにデータを書き込む場合、データはキャッシュ層 (専用 SSD ディスクとサービス VM の RAM) に保存されます。 並行して、データのブロックがクラスター内のノードに送信されます (ノードの数はクラスターのレプリケーション係数によって異なります)。 すべてのノードから記録の成功が確認された後、記録の確認がハイパーバイザーに送信され、次に VM に送信されます。 記録されたデータはバックグラウンドで重複排除され、圧縮されてストレージ ディスクに書き込まれます。 同時に、大きなブロックが常にストレージ ディスクに順次書き込まれるため、ストレージ ディスクの負荷が軽減されます。

重複排除と圧縮は常に有効であり、無効にすることはできません。 データはストレージ ディスクまたは RAM キャッシュから直接読み取られます。 ハイブリッド構成が使用されている場合、読み取りも SSD にキャッシュされます。

データは仮想マシンの現在の場所に関連付けられておらず、ノード間で均等に分散されます。 このアプローチにより、すべてのディスクとネットワーク インターフェイスを均等にロードできます。 明らかな欠点があります。ローカルでのデータの可用性が保証されていないため、読み取りレイテンシーを可能な限り短縮することができません。 しかし、これは得られる利益に比べれば小さな犠牲だと思います。 さらに、ネットワーク遅延は、実際には全体的な結果に影響を与えないような値に達しています。

各ストレージ ノード上に作成される特別なサービス VM Cisco HyperFlex データ プラットフォーム コントローラは、ディスク サブシステムの動作ロジック全体を担当します。 サービス VM 構成では、72 つの vCPU と 28 GB の RAM が割り当てられましたが、これはそれほど少ないことではありません。 ホスト自体には 512 個の物理コアと XNUMX GB の RAM があることを思い出してください。

サービス VM は、SAS コントローラーを VM に転送することにより、物理ディスクに直接アクセスできます。 ハイパーバイザーとの通信は、I/O 操作をインターセプトする特別なモジュール IOVisor と、ハイパーバイザー API にコマンドを送信できるエージェントを使用して行われます。 エージェントは、HyperFlex スナップショットとクローンを操作する責任があります。

ディスク リソースは、NFS または SMB 共有としてハイパーバイザーにマウントされます (ハイパーバイザーの種類に応じて、どちらがどこにあるか推測してください)。 そして内部では、これは分散ファイル システムであり、シン ボリュームの割り当て、圧縮と重複排除、リダイレクト オン ライト テクノロジを使用したスナップショット、同期/非同期レプリケーションなどの本格的なストレージ システムの機能を追加できます。

サービス VM は、HyperFlex サブシステムの WEB 管理インターフェイスへのアクセスを提供します。 vCenter との統合があり、ほとんどの日常的なタスクは vCenter から実行できますが、たとえば、すでに高速な HTML5 インターフェイスに切り替えている場合、または本格的な Flash クライアントを使用している場合は、データストアを別の Web カメラから切り出す方が便利です。完全に統合されています。 サービス Web カメラでは、システムのパフォーマンスと詳細なステータスを表示できます。

クラスターには別のタイプのノード、コンピューティング ノードがあります。 これらは、ディスクが組み込まれていないラック サーバーまたはブレード サーバーです。 これらのサーバーは、ディスクを備えたサーバーにデータが保存されている VM を実行できます。 データ アクセスの観点からは、アーキテクチャにはデータの物理的な場所からの抽象化が含まれるため、ノードのタイプ間に違いはありません。 コンピューティング ノードとストレージ ノードの最大比率は 2:1 です。

コンピューティング ノードを使用すると、クラスター リソースを拡張する際の柔軟性が向上します。CPU/RAM のみが必要な場合は、ディスクを備えた追加のノードを購入する必要がありません。 さらに、ブレード ケージを追加して、サーバーのラック配置を節約できます。

その結果、次の機能を備えたハイパーコンバージド プラットフォームが完成しました。

• クラスター内の最大 64 ノード (最大 32 ストレージ ノード)。
• クラスター内のノードの最小数は XNUMX です (Edge クラスターの場合は XNUMX)。
• データ冗長性メカニズム: レプリケーション ファクター 2 および 3 によるミラーリング。
• メトロクラスター。
• 別の HyperFlex クラスタへの非同期 VM レプリケーション。
• VM をリモート データ センターに切り替えるオーケストレーション。
• Redirect-on-Write テクノロジーを使用したネイティブ スナップショット。
• レプリケーション係数 1 で重複排除なしで最大 3 PB の使用可能なスペース。 複製係数 2 は、本格的な販売では選択できないため、考慮しません。

もう XNUMX つの大きな利点は、管理と導入が容易なことです。 UCS サーバのセットアップの複雑さはすべて、Cisco エンジニアが用意した専用の VM によって処理されます。

テストベンチ構成:

• 管理クラスタおよびネットワーク コンポーネントとして Cisco UCS ファブリック インターコネクト 2UP 6248 台（イーサネット 48G/FC 10G モードで動作する 16 ポート）。
• 240 台の Cisco UCS HXAF4 MXNUMX サーバー。

サーバーの特徴:

CPU

2 x インテル® Xeon® E5-2690 v4

RAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/デュアルランク/x4/1.2v

ネットワーク

UCSC-MLOM-CSC-02 (VIC 1227)。 2 10G イーサネットポート

ストレージHBA

Cisco 12G モジュラ SAS パススルー コントローラ

ストレージディスク

1 x SSD Intel S3520 120 GB、1 x SSD Samsung MZ-IES800D、10 x SSD Samsung PM863a 960 GB

その他の構成オプション選択したハードウェアに加えて、現在次のオプションが利用可能です。

• HXAF240c M5。
• Intel Silver 4110 から Intel Platinum I8260Y までの XNUMX つまたは XNUMX つの CPU。 第二世代も利用可能。
• 24 個のメモリ スロット、16 GB RDIMM 2600 から 128 GB LRDIMM 2933 まで。
• 6 ～ 23 のデータ ディスク、XNUMX つのキャッシュ ディスク、XNUMX つのシステム ディスク、および XNUMX つのブート ディスク。

容量ドライブ

• HX-SD960G61X-EV 960GB 2.5 インチ エンタープライズ バリュー 6G SATA SSD (1X 耐久性) SAS 960 GB。
• HX-SD38T61X-EV 3.8TB 2.5 インチ エンタープライズ バリュー 6G SATA SSD (1X 耐久性) SAS 3.8 TB。
• ドライブのキャッシュ
• HX-NVMEXPB-I375 375GB 2.5 インチ Intel Optane ドライブ、優れたパフォーマンスと耐久性。
• HX-NVMEHW-H1600* 1.6TB 2.5 インチ エンタープライズ性能NVMe SSD (3X 耐久性) NVMe 1.6 TB。
• HX-SD400G12TX-EP 400GB 2.5インチ エントリー性能12G SAS SSD (10X 耐久性) SAS 400 GB。
• HX-SD800GBENK9** 800GB 2.5インチ エントリー性能12G SAS SED SSD (10X 耐久性) SAS 800 GB。
• HX-SD16T123X-EP 1.6TB 2.5 インチ エンタープライズ パフォーマンス 12G SAS SSD (3 倍の耐久性)。

システム/ログドライブ

• HX-SD240GM1X-EV 240GB 2.5 インチ エンタープライズ バリュー 6G SATA SSD (アップグレードが必要)。

ブートドライブ

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB。

40G、25G、または 10G イーサネット ポート経由でネットワークに接続します。

FI は、HX-FI-6332 (40G)、HX-FI-6332-16UP (40G)、HX-FI-6454 (40G/100G) です。

テスト自体

ディスク サブシステムをテストするために、HCIBench 2.2.1 を使用しました。 これは、複数の仮想マシンからの負荷の作成を自動化できる無料のユーティリティです。 負荷自体は通常の fio によって生成されます。

私たちのクラスターは 3 つのノードで構成され、レプリケーション ファクター XNUMX、すべてのディスクがフラッシュです。

テストのために、XNUMX つのデータストアと XNUMX つの仮想マシンを作成しました。 書き込みテストでは、キャッシュ ディスクがいっぱいではないと想定されます。

テスト結果は次のとおりです。

100% 読み取り 100% ランダム

0% 読み取り 100% ランダム

ブロック/キューの深さ

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 ミリ秒 213804 IOPS

0,84 ミリ秒 303540 IOPS

1,36ms 374348 IOPS

2.47 ミリ秒 414116 IOPS

4,86ms 420180 IOPS

2,22 ミリ秒 57408 IOPS

3,09 ミリ秒 82744 IOPS

5,02ミリ秒 101824 IPOS

8,75 ミリ秒 116912 IOPS

17,2 ミリ秒 118592 IOPS

8K

0,67 ミリ秒 188416 IOPS

0,93 ミリ秒 273280 IOPS

1,7 ミリ秒 299932 IOPS

2,72 ミリ秒 376,484 IOPS

5,47 ミリ秒 373,176 IOPS

3,1 ミリ秒 41148 IOPS

4,7 ミリ秒 54396 IOPS

7,09 ミリ秒 72192 IOPS

12,77 ミリ秒 80132 IOPS

16K

0,77 ミリ秒 164116 IOPS

1,12 ミリ秒 228328 IOPS

1,9 ミリ秒 268140 IOPS

3,96 ミリ秒 258480 IOPS

3,8 ミリ秒 33640 IOPS

6,97 ミリ秒 36696 IOPS

11,35 ミリ秒 45060 IOPS

32K

1,07 ミリ秒 119292 IOPS

1,79 ミリ秒 142888 IOPS

3,56 ミリ秒 143760 IOPS

7,17 ミリ秒 17810 IOPS

11,96 ミリ秒 21396 IOPS

64K

1,84 ミリ秒 69440 IOPS

3,6 ミリ秒 71008 IOPS

7,26 ミリ秒 70404 IOPS

11,37 ミリ秒 11248 IOPS

太字は、その後生産性が向上せず、場合によっては劣化が見られる場合の値を示します。 これは、ネットワーク/コントローラー/ディスクのパフォーマンスによって制限されるためです。

• シーケンシャル読み取り 4432 MB/秒。
• シーケンシャル書き込み804MB/秒。
• XNUMX つのコントローラーに障害が発生した場合 (仮想マシンまたはホストの障害)、パフォーマンスは XNUMX 倍低下します。
• ストレージ ディスクに障害が発生した場合、ドローダウンは 1/3 になります。 ディスクの再構築には、各コントローラーのリソースの 5% が消費されます。

小さなブロックでは、コントローラー (仮想マシン) のパフォーマンスによって制限され、その CPU は 100% で負荷され、ブロックが増加すると、ポートの帯域幅によって制限されます。 AllFlash システムの可能性を最大限に引き出すには、10 Gbps では十分ではありません。 残念ながら、提供されたデモ スタンドのパラメータでは 40 Gbit/s での動作をテストすることはできません。

テストとアーキテクチャの研究からの私の印象では、すべてのホスト間にデータを配置するアルゴリズムのおかげで、スケーラブルで予測可能なパフォーマンスが得られますが、ローカル ディスクからより多くのデータを絞り出すことができるため、これは読み取り時の制限でもあります。ここでは、より生産性の高いネットワークを節約できる可能性があります。たとえば、40 Gbit/s の FI が利用可能です。

また、キャッシュと重複排除用に XNUMX つのディスクが制限となる可能性がありますが、実際、このテストベッドでは XNUMX つの SSD ディスクに書き込むことができます。 キャッシュ ドライブの数を増やして違いを確認できれば素晴らしいと思います。

実際の使用

バックアップ データ センターを組織するには、次の XNUMX つのアプローチを使用できます (バックアップをリモート サイトに配置することは考慮していません)。

1. アクティブパッシブ。 すべてのアプリケーションはメイン データ センターでホストされます。 レプリケーションは同期または非同期です。 メイン データ センターに障害が発生した場合は、バックアップ データ センターをアクティブにする必要があります。 これは手動/スクリプト/オーケストレーション アプリケーションで実行できます。 ここでは、レプリケーション頻度に応じた RPO が得られますが、RTO は管理者の反応とスキル、および切り替え計画の開発/デバッグの品質に依存します。
2. アクティブ-アクティブ。 この場合、同期レプリケーションのみが行われ、データ センターの可用性は、厳密に 0 番目のサイトに配置されたクォーラム/アービタによって決定されます。 RPO = 0、RTO は XNUMX (アプリケーションが許可する場合)、または仮想化クラスター内のノードのフェイルオーバー時間に達する可能性があります。 仮想化レベルでは、アクティブ/アクティブ ストレージを必要とするストレッチ (メトロ) クラスターが作成されます。

通常、クライアントがメイン データ センターにクラシック ストレージ システムを備えたアーキテクチャをすでに実装していることがわかるため、レプリケーション用に別のストレージ システムを設計します。 前述したように、Cisco HyperFlex は、非同期レプリケーションと拡張仮想化クラスタの作成を提供します。 同時に、高価なレプリケーション機能や XNUMX つのストレージ システム上のアクティブ/アクティブ データ アクセスを備えたミッドレンジ レベル以上の専用ストレージ システムも必要ありません。

シナリオ1： 当社にはプライマリ データ センターとバックアップ データ センター、VMware vSphere 上の仮想化プラットフォームがあります。 すべての本稼働システムはメイン データ センターに配置され、仮想マシンのレプリケーションはハイパーバイザー レベルで実行されます。これにより、バックアップ データ センターで VM がオンのままになることが回避されます。 組み込みツールを使用してデータベースと特別なアプリケーションを複製し、VM をオンにしたままにします。 メイン データ センターに障害が発生した場合は、バックアップ データ センターでシステムを起動します。 仮想マシンは約 100 台あると考えられます。 プライマリ データ センターが稼働している間、スタンバイ データ センターはテスト環境や、プライマリ データ センターが切り替わった場合にシャットダウンされる可能性のあるその他のシステムを実行できます。 双方向レプリケーションを使用することも可能です。 ハードウェアの観点からは何も変わりません。

クラシック アーキテクチャの場合、各データ センターに、ファイバー チャネル経由でアクセスできるハイブリッド ストレージ システム、階層化、重複排除、圧縮 (ただしオンラインではない)、各サイトに 8 台のサーバー、2 台のファイバー チャネル スイッチ、および 10G イーサネットを設置します。 クラシック アーキテクチャでのレプリケーションとスイッチングの管理には、VMware ツール (レプリケーション + SRM) またはサードパーティ ツールを使用できます。これらのツールは、もう少し安価で、場合によってはより便利です。

図にその図を示します。

Cisco HyperFlex を使用すると、次のアーキテクチャが得られます。

HyperFlex の場合、大規模な CPU/RAM リソースを備えたサーバーを使用しました。 リソースの一部は HyperFlex コントローラ VM に送られます。CPU とメモリに関しては、Cisco と連携せずに残りの VM のリソースを保証するために、HyperFlex 構成を少し再構成しました。 しかし、ファイバー チャネル スイッチを放棄することができ、各サーバーにイーサネット ポートは必要なくなり、ローカル トラフィックは FI 内でスイッチングされます。

その結果、各データセンターの構成は次のようになりました。

サーバー

8 x 1U サーバー (384 GB RAM、2 x Intel Gold 6132、FC HBA)

8 x HX240C-M5L (512 GB RAM、2 x Intel Gold 6150、3,2 GB SSD、10 x 6 TB NL-SAS)

SHD

FCフロントエンドを備えたハイブリッドストレージシステム（20TB SSD、130TB NL-SAS）

-

LAN

2 x イーサネット スイッチ 10G 12 ポート

-

SAN

2 x FC スイッチ 32/16Gb 24 ポート

2×Cisco UCS FI 6332

ライセンス

VMware Ent Plus

VMスイッチングのレプリケーションおよび/またはオーケストレーション

VMware Ent Plus

Hyperflex のレプリケーション ソフトウェア ライセンスは、すぐに使用できるものなので提供しませんでした。

クラシカルな建築に関しては、高品質で安価なメーカーとしての地位を確立しているベンダーを選びました。 どちらのオプションでも、特定のソリューションに標準割引を適用した結果、実際の価格が表示されました。

Cisco HyperFlex ソリューションは 13% 安価であることが判明しました。

シナリオ2： XNUMX つのアクティブなデータセンターの作成。 このシナリオでは、VMware 上でストレッチ クラスターを設計しています。

クラシック アーキテクチャは、仮想化サーバー、SAN (FC プロトコル)、およびそれらの間のボリュームに読み書きできる XNUMX つのストレージ システムで構成されます。 各ストレージ システムには、有効なストレージ容量が割り当てられています。

HyperFlex では、両方のサイトに同じ数のノードを持つストレッチ クラスターを作成するだけです。 この場合、2+2 のレプリケーション係数が使用されます。

結果は次の構成になります。

古典建築

ハイパーフレックス

サーバー

16 x 1U サーバー (384 GB RAM、2 x Intel Gold 6132、FC HBA、2 x 10G NIC)

16 x HX240C-M5L (512 GB RAM、2 x Intel Gold 6132、1,6 TB NVMe、12 x 3,8 TB SSD、VIC 1387)

SHD

2 x AllFlash ストレージ システム (150 TB SSD)

-

LAN

4 x イーサネット スイッチ 10G 24 ポート

-

SAN

4 x FC スイッチ 32/16Gb 24 ポート

4×Cisco UCS FI 6332

ライセンス

VMware Ent Plus

VMware Ent Plus

すべての計算では、ネットワーク インフラストラクチャ、データ センターのコストなどは考慮していません。これらは、従来のアーキテクチャでも HyperFlex ソリューションでも同じです。

コストの点では、HyperFlex の方が 5% 高価であることが判明しました。 ここで注目していただきたいのは、構成ではメモリ コントローラー チャネルを均等に埋めたため、CPU/RAM リソースに関しては Cisco に偏りがあったということです。 コストはわずかに高くなりますが、桁違いではありません。これは、ハイパーコンバージェンスが必ずしも「金持ちのためのおもちゃ」ではなく、データセンターを構築する標準的なアプローチと競合できることを明確に示しています。 これは、Cisco UCS サーバとそれに対応するインフラストラクチャをすでに持っている人にとっても興味深いかもしれません。

利点としては、SAN とストレージ システムの管理コストがかからないこと、オンライン圧縮と重複排除、サポートの単一のエントリ ポイント (仮想化、サーバー、これらはストレージ システムでもあります)、スペースの節約 (ただし、すべてのシナリオでというわけではありません)、操作の簡素化。

サポートに関しては、ここでは Cisco という XNUMX つのベンダーからサポートを受けられます。 Cisco UCS サーバの使用経験から判断すると、これは気に入っています。HyperFlex で開く必要がなく、すべてが同じように機能しました。 エンジニアは迅速に対応し、典型的な問題だけでなく、複雑なエッジケースも解決できます。 時々、私は彼らに「これは可能ですか？ねじ込みますか？」と質問します。 または、「ここで何かを設定しましたが、機能しません。 ヘルプ！" - 彼らはそこで必要なガイドを辛抱強く見つけて正しいアクションを指摘しますが、「私たちはハードウェアの問題を解決するだけです」とは答えません。

リファレンス

• 仕様
• 仮想データセンター
• 机の引き出しの中にあるデータセンター
• 私のメール - [メール保護]

出所： habr.com