Huawei Dorado V6: 四川省の暑さ

今年のモスクワの夏は、正直言ってあまり良くなかった。 始まりが早すぎて、誰もがそれに反応する時間がなく、すでに34月末には終わっていました。 そのため、ファーウェイが私を中国のRnDセンターのある成都に招待したとき、日陰で+6度の天気予報を見て、すぐに同意しました。 結局のところ、私はもう同じ年齢ではないので、少し骨を温める必要があります。 ただし、成都が実際に位置する四川省は辛い食べ物が大好きなことで有名なので、骨だけでなく内臓も温めることができたことに注意したいと思います。 しかし、それでも、これは旅行に関するブログではないので、旅行の主な目的である新しいストレージ システムである Huawei Dorado VXNUMX に戻りましょう。 この記事は、あなたを過去から少し揺さぶります。なぜなら... 公式発表前に書かれたものですが、リリース後にのみ公開されました。 そこで、今日はファーウェイが私たちのために用意してくれた興味深くておいしいものすべてを詳しく見ていきます。

新ラインには5モデルがラインナップされる。 3000V6 を除くすべてのモデルには、SAS と NVMe の 2.5 つのバージョンがあります。 この選択により、このシステムで使用できるディスクのインターフェイス、バックエンド ポート、およびシステムにインストールできるディスク ドライブの数が決まります。 NVMe には、従来の 36 インチ SAS SSD よりも薄く、最大 XNUMX 個まで搭載できるパームサイズの SSD が使用されます。 新しいラインはオール フラッシュであり、ディスクを使用した構成はありません。

パームNVMe SSD

私の意見では、Dorado 8000 と 18000 が最も興味深いモデルのように見えますが、ファーウェイはこれらをハイエンド システムとして位置づけており、ファーウェイの価格設定方針のおかげで、これらのミッドレンジ モデルを競合セグメントと対比させています。 今日のレビューで焦点を当てるのはこれらのモデルです。 設計上の特徴により、ジュニア デュアル コントローラー システムは、Dorado 8000 や 18000 とは若干異なるアーキテクチャを備えているため、今日説明するすべてがジュニア モデルに当てはまるわけではないことにすぐに注意してください。

新しいシステムの主な特徴の XNUMX つは、社内で開発された複数のチップの使用であり、それぞれのチップにより、コントローラーの中央プロセッサからの論理負荷を分散し、さまざまなコンポーネントに機能を追加できます。

新しいシステムの中心となるのは、ARMテクノロジーに基づいて開発され、ファーウェイが独自に製造したKunpeng 920プロセッサです。 モデルに応じて、各コントローラーに搭載されているコアの数、周波数、プロセッサの数が異なります。
Huawei Dorado V6 8000 – 2CPU、64 コア
Huawei Dorado V6 18000 – 4CPU、48 コア

ファーウェイはこのプロセッサをARMアーキテクチャに基づいて開発しており、私の知る限り、当初は一部のV8000モデルで既にそうであったように、古いDorado 18000および5モデルにのみこのプロセッサを搭載する予定でしたが、制裁によりこの考えは調整されました。 もちろん、ARMは制裁発動中にファーウェイへの協力を拒否することについても話していたが、ここでの状況はインテルの場合とは異なる。 ファーウェイはこれらのチップを独自に製造しており、いかなる制裁もこのプロセスを止めることはできません。 ARMとの関係を断つことは、新たな開発へのアクセスを失う恐れがあるだけです。 性能に関しては、独自のテストを実施した後にのみ判断可能となります。 Dorado 18000 システムから 1M IOPS が問題なく除去される様子を見てきましたが、ラック内で自分の手で再現するまでは信じられません。 しかし、コントローラーには本当に大きな力があります。 古いモデルには 4 つのコントローラーが搭載されており、それぞれに 4 つのプロセッサーが搭載されており、合計 768 コアになります。

ただし、コアについては後ほど、新しいシステムのアーキテクチャを検討するときに説明しますが、ここではシステムにインストールされている別のチップに戻りましょう。 このチップは非常に興味深いソリューションのように見えます アセンド310 （私が理解している限り、最近一般公開された Ascend 910 の弟です）。 そのタスクは、システムに入るデータ ブロックを分析して読み取りヒット率を高めることです。 仕事でどのように機能するかを言うのは難しいです。 現在では、特定のテンプレートに従ってのみ動作し、インテリジェント モードで学習する機能はありません。 インテリジェント モードの登場は、おそらく来年初めの将来のファームウェアで約束されています。

建築の話に移りましょう。 ファーウェイは、コンポーネントを接続するためのフルメッシュアプ​​ローチを実装する独自のスマートマトリックステクノロジーの開発を続けてきました。 ただし、V5 ではこれがコントローラーからディスクへのアクセスのみであった場合、現在ではすべてのコントローラーがバックエンドとフロントエンドの両方のすべてのポートにアクセスできるようになります。

新しいマイクロサービス アーキテクチャのおかげで、LUN が 4 つしかない場合でも、すべてのコントローラー間の負荷分散も可能になります。 このアレイ シリーズの OS は、単にフラッシュ ドライブの使用のために最適化されたものではなく、ゼロから開発されました。 すべてのコントローラが同じポートにアクセスできるため、コントローラの障害または再起動が発生した場合でも、ホストはストレージ システムへの単一のパスを失うことはなく、パスの切り替えはストレージ システム レベルで実行されます。 ただし、ホスト上で UltraPath を使用することは必ずしも必要ではありません。 システムの設置時のもう 8 つの「節約」は、必要なリンクの数が少なくなることです。 また、2 つのコントローラーに対する「古典的な」アプローチでは、2 つの工場から XNUMX つのリンクが必要になる場合、Huawei の場合は XNUMX つでも十分です (XNUMX つのリンクのスループットの十分性についてはここでは話していません)。

前のバージョンと同様に、ミラーリングを備えたグローバル キャッシュが使用されます。 これにより、可用性に影響を与えることなく、最大 3 つのコントローラを同時に失うか、または XNUMX つのコントローラを連続して失うことができます。 ただし、デモスタンドで XNUMX つの障害が発生した場合、残りの XNUMX つのコントローラー間の完全な負荷分散が確認されなかったことは注目に値します。 障害が発生したコントローラーの負荷は、残りのコントローラーの XNUMX つによって完全に引き継がれました。 このため、この構成ではシステムをより長く動作させる必要がある可能性があります。 いずれにせよ、私自身のテストを使用してこれをさらに詳しく確認します。
ファーウェイは新しいシステムをエンドツーエンドのNVMeシステムと位置付けていますが、現時点ではNVMeOFはフロントエンドではまだサポートされておらず、FC、iSCSI、またはNFSのみがサポートされています。 他の機能と同様に、この機能の終了時または次の機能の開始時に、RoCE のサポートが約束されます。

シェルフは RoCE を使用してコントローラにも接続されますが、これに関連する欠点が XNUMX つあります。それは、SAS の場合のように、シェルフの「ループバック」接続が存在しないことです。 私の意見では、かなり大規模なシステムを計画している場合、これは依然としてかなり大きな欠点です。 実際のところ、すべてのシェルフは直列に接続されており、そのうちの XNUMX つのシェルフに障害が発生すると、その後に続く他のすべてのシェルフに完全にアクセスできなくなります。 この場合、フォールト トレランスを確保するには、すべてのシェルフをコントローラーに接続する必要があり、システム内で必要なバックエンド ポートの数が増加します。

そしてもう XNUMX つ言及する価値があるのは、無停止更新 (NDU) です。 上で述べたように、ファーウェイは新しい Dorado ラインの OS を操作するためのコンテナ アプローチを実装しました。これにより、コントローラを完全に再起動することなく、サービスを更新して再起動することができます。 一部の更新にはカーネル更新が含まれることをすぐに言及する価値があります。この場合、更新中にコントローラーの従来の再起動が必要になる場合がありますが、常に必要であるわけではありません。 これにより、この操作が本稼働システムに与える影響が軽減されます。

当社の兵器庫では、アレイの大部分が NetApp 製です。 したがって、私がかなり頻繁に作業しなければならないシステムと少し比較してみると、非常に論理的になると思います。 これは、誰が優れていて誰が劣っているのか、またはどちらのアーキテクチャが有利であるかを判断するものではありません。 私は、同じ問題を解決するための異なるベンダーによる XNUMX つの異なるアプローチを、熱狂的にならずに冷静に比較してみます。 はい、もちろん、この場合、Huawei システムを「理論」で検討します。また、将来のファームウェア バージョンで実装される予定の点についても別途記載します。 現時点で私が感じている利点は次のとおりです。

1. サポートされている NVMe ドライブの数。 NetApp には現在 288 個があり、Huawei にはモデルに応じて 1600 ～ 6400 個あります。 同時に、ファーウェイの最大使用可能容量は、NetApp システムと同様に 32PBe です (より正確には、31.64PBe)。 これは、同じボリュームのドライブ (最大 15Tb) がサポートされているにもかかわらずです。 ファーウェイはこの事実を次のように説明している：彼らにはより大きなスタンドを組み立てる機会がなかった。 理論上、量の制限はありませんが、この事実をまだテストできていないだけです。 ただし、ここで注目すべき点は、今日のフラッシュ ドライブの機能が非常に高く、NVMe システムの場合、トップエンドの 24 コントローラ システムを利用するには 2 台のドライブで十分であるという事実に直面しています。 したがって、システム内のディスクの数をさらに増やすと、パフォーマンスが向上しないだけでなく、IOPS/Tb 比にも悪影響を及ぼします。 もちろん、4 コントローラー システム 8000 および 16000 がどれだけのドライブを処理できるかを見る価値はあります。 Kunpeng 920 の機能と可能性はまだ完全には明らかではありません。
2. NetApp システムの所有者としての Lun の存在。 それらの。 月で操作を実行できるのは XNUMX つのコントローラーだけであり、XNUMX つ目のコントローラーはそれ自体を介して IO を渡すだけです。 それとは対照的に、Huawei システムには所有者がなく、データ ブロックの操作 (圧縮、重複排除) はどのコントローラーでも実行でき、ディスクに書き込むこともできます。
3. コントローラの 5 つに障害が発生しても、ポートはドロップされません。 一部の人にとって、この瞬間は非常に危機的であるように見えます。 肝心なのは、ストレージ システム内の切り替えはホスト側よりも高速に行われる必要があるということです。 同じ NetApp の場合、実際にコントローラーを引き出してパスを切り替えるときに約 XNUMX 秒のフリーズが発生した場合、Huawei に切り替えてもまだ練習する必要があります。
4. アップデート時にコントローラーを再起動する必要はありません。 NetApps の新しいバージョンとファームウェア ブランチがかなり頻繁にリリースされるため、このことが特に心配になり始めました。 はい、Huawei の一部のアップデートでは再起動が必要になりますが、すべてではありません。
5. NetApp コントローラ 4 個の価格で Huawei コントローラ XNUMX 個を購入できます。 上で述べたように、ファーウェイの価格政策のおかげで、ファーウェイはハイエンドモデルでミッドレンジと競合できます。
6. シェルフ コントローラおよびポート カードには、システム効率の向上を目的とした追加チップが存在します。

一般的な短所と懸念事項:

1. シェルフをコントローラーに直接接続するか、すべてのシェルフをコントローラーに接続するために多数のバックエンド ポートが必要になります。
2. ARM アーキテクチャと多数のチップの存在 - どれだけ効率的に動作するのか、またパフォーマンスは十分なのか?

ほとんどの懸念や恐れは、新しいラインを個人的にテストすることで払拭できます。 リリース後すぐにモスクワに登場し、自分のテスト用にすぐに入手できるほどの数が揃うことを願っています。 これまでのところ、一般的に同社のアプローチは興味深いものであり、新しいラインは競合他社と比較して非常に優れていると言えます。 最終的な実装では多くの疑問が生じます。 年末だけ、そしておそらく 2020 年だけ、多くのことが見られるでしょう。

出所： habr.com