ハイパーコンバージド ソリューション AERODISK vAIR。 基礎となるのはARDFSファイルシステムです

Habr読者の皆さん、こんにちは。 この記事から、私たちが開発したハイパーコンバージド システム AERODISK vAIR について説明するシリーズを開始します。 当初は最初の記事ですべてを伝えたかったのですが、システムが非常に複雑なので、ゾウを分割して食べます。

システムの作成の歴史から話を始め、vAIR の基礎である ARDFS ファイル システムについて詳しく説明し、ロシア市場におけるこのソリューションの位置づけについても少しお話しましょう。

今後の記事では、さまざまなアーキテクチャ コンポーネント (クラスター、ハイパーバイザー、ロード バランサー、監視システムなど)、構成プロセスについて詳しく説明し、ライセンスの問題を提起し、クラッシュ テストを個別に示し、もちろん負荷テストについても書きます。サイズ感。 また、vAIR のコミュニティ バージョンについては別の記事を書く予定です。

Aerodisk はストレージ システムに関する話ですか? あるいは、そもそもなぜハイパーコンバージェンスを始めたのでしょうか?

当初、独自のハイパーコンバージェンスを作成するというアイデアは 2010 年頃に思いつきました。 当時、Aerodisk も同様のソリューション (商用ボックス型ハイパーコンバージド システム) も市場には存在していませんでした。 私たちのタスクは次のとおりでした。イーサネット プロトコルを介した相互接続によって結合されたローカル ディスクを備えた一連のサーバーから、拡張ストレージを作成し、そこで仮想マシンとソフトウェア ネットワークを起動する必要がありました。 これらはすべて、ストレージ システムなしで実装する必要がありました (ストレージ システムとそのハードウェアを購入する資金がなく、独自のストレージ システムをまだ発明していなかったためです)。

私たちは多くのオープンソース ソリューションを試し、最終的にこの問題を解決しましたが、その解決策は非常に複雑で、再現するのが困難でした。 しかも、この解決策は「効果はあるのか？」というカテゴリーにありました。 触らないでください！ したがって、その問題を解決した後、私たちは仕事の結果を本格的な製品に変換するというアイデアをさらに発展させませんでした。

あの事件の後、私たちはこの考えから遠ざかりましたが、この問題は完全に解決可能であり、そのような解決策の利点は明白以上であるという感覚を依然として持っていました。 その後にリリースされた外国企業のHCI製品は、この感覚を裏付けるものに過ぎませんでした。

そのため、2016 年半ばに、本格的な製品の作成の一環としてこの作業に戻りました。 当時、私たちはまだ投資家との関係を持っていなかったので、自分自身でそれほど大したお金ではない開発スタンドを購入する必要がありました。 Avito で中古のサーバーとスイッチを集めたので、本題に取り掛かりました。

初期の主なタスクは、単純ではありますが独自のファイル システムを作成することでした。このファイル システムは、イーサネット経由の相互接続で接続されている n 番目のクラスタ ノード上に仮想ブロックの形式でデータを自動的かつ均等に分散できます。 同時に、FS は適切かつ容易に拡張でき、隣接するシステムから独立している必要があります。 vAIR からは「単なる保管施設」として疎外されることになります。

最初の vAIR コンセプト

私たちは、すでに豊富なプロジェクト経験があったため、ストレッチ ストレージ (ceph、gluster、gluster など) を整理するための既製のオープンソース ソリューションの使用を意図的に放棄し、独自の開発を優先しました。 もちろん、これらのソリューション自体は優れており、Aerodisk に取り組む前に、これらのソリューションと複数の統合プロジェクトを実装しました。 しかし、XNUMX 人の顧客向けに特定のタスクを実装し、スタッフをトレーニングし、おそらく大手ベンダーのサポートを購入することと、さまざまなタスクに使用される簡単に複製できる製品を作成することはまったく別のことです。ベンダーは私たち自身のことさえ知らないかもしれません。 XNUMX 番目の目的については、既存のオープンソース製品は適していなかったので、分散ファイル システムを自分たちで作成することにしました。
XNUMX 年後、数人の開発者 (vAIR での作業と従来の Engine ストレージ システムでの作業を組み合わせた) が一定の成果を達成しました。

2018 年までに、私たちは単純なファイル システムを作成し、それに必要なハードウェアを追加しました。 このシステムは、内部相互接続を介してさまざまなサーバーの物理 (ローカル) ディスクを XNUMX つのフラット プールに結合し、それらを仮想ブロックに「分割」し、その仮想ブロックからさまざまな程度のフォールト トレランスを持つブロック デバイスを作成し、その上に仮想デバイスが作成されました。 KVM ハイパーバイザー カーを使用して実行されます。

ファイル システムの名前についてはあまり気にせず、簡潔に ARDFS と呼びました (これが何を表しているか推測してください))

このプロトタイプは見栄えが良く (もちろん、視覚的にはそうではありません。視覚的なデザインはまだありませんでした)、パフォーマンスとスケーリングの点で良好な結果を示しました。 最初の実際の結果が得られた後、私たちはこのプロジェクトを開始し、本格的な開発環境と vAIR のみを扱う別のチームを組織しました。

ちょうどその時点で、ソリューションの全体的なアーキテクチャは成熟していましたが、まだ大きな変更は受けていません。

ARDFS ファイル システムの詳細

ARDFS は vAIR の基盤であり、クラスター全体に分散されたフォールト トレラントなデータ ストレージを提供します。 ARDFS の特徴の XNUMX つ (ただし、それだけではありません) は、メタデータと管理に追加の専用サーバーを使用しないことです。 これは元々、ソリューションの構成を簡素化し、その信頼性を高めるために考案されました。

収納構造

クラスターのすべてのノード内で、ARDFS は利用可能なすべてのディスク領域から論理プールを編成します。 プールはまだデータやフォーマットされたスペースではなく、単なるマークアップであることを理解することが重要です。 vAIR がインストールされているノードは、クラスターに追加されると、共有 ARDFS プールに自動的に追加され、ディスク リソースがクラスター全体で自動的に共有されます (将来のデータ ストレージに使用できるようになります)。 このアプローチにより、すでに実行中のシステムに重大な影響を与えることなく、その場でノードを追加および削除できます。 それらの。 このシステムは、必要に応じてクラスター内のノードを追加または削除することで、「ブリック単位で」拡張するのが非常に簡単です。

仮想ディスク (仮想マシンのストレージ オブジェクト) は ARDFS プールの最上位に追加され、サイズが 4 MB の仮想ブロックから構築されます。 仮想ディスクはデータを直接保存します。 フォールト トレランス スキームも仮想ディスク レベルで設定されます。

すでにご想像のとおり、ディスク サブシステムのフォールト トレランスには、RAID (独立ディスクの冗長アレイ) の概念は使用せず、RAIN (独立ノードの冗長アレイ) を使用します。 それらの。 フォールト トレランスは、ディスクではなくノードに基づいて測定、自動化、および管理されます。 もちろん、ディスクもストレージ オブジェクトであり、他のものと同様に監視されており、ローカル ハードウェア RAID の構築を含むすべての標準操作を実行できますが、クラスターは特にノード上で動作します。

本当に RAID が必要な状況 (たとえば、小規模クラスターでの複数の障害をサポートするシナリオ) では、ローカル RAID コントローラーを使用し、その上に拡張ストレージと RAIN アーキテクチャを構築することを妨げるものはありません。 このシナリオは実際に行われており、弊社によってサポートされているため、vAIR を使用するための一般的なシナリオに関する記事で説明します。

ストレージフォールトトレランススキーム

vAIR の仮想ディスクには XNUMX つのフォールト トレランス スキームが存在します。

1) レプリケーション ファクター、または単にレプリケーション - このフォールト トレランスの方法は、棒とロープのように簡単です。 同期レプリケーションは、係数 2 (クラスターごとに 2 コピー) または 3 (それぞれ 3 コピー) でノード間で実行されます。 RF-2 では、仮想ディスクはクラスタ内の 3 つのノードの障害に耐えることができますが、有効なボリュームの半分を「消費」します。RF-2 はクラスタ内の 2 つのノードの障害に耐えますが、有効なボリュームの 3/1 を予約します。ニーズに合わせた便利なボリューム。 このスキームは RAID-2 に非常に似ています。つまり、RF-XNUMX で構成された仮想ディスクはクラスター内の XNUMX つのノードの障害に対して耐性があります。 この場合、データには問題がなく、I/O も停止しません。 障害が発生したノードがサービスに戻ると、自動データ回復/同期が開始されます。

以下に、通常モードと障害状況における RF-2 および RF-3 データの分布の例を示します。

8 MB の一意の (有用な) デ​​ータの容量を持つ仮想マシンがあり、4 つの vAIR ノードで実行されます。 実際にはこのような小さなボリュームが存在する可能性は低いことは明らかですが、ARDFS 操作のロジックを反映するスキームとしては、この例が最も理解しやすいです。 AB は、一意の仮想マシン データを含む 4MB の仮想ブロックです。 RF-2 は、これらのブロック A1+A2 および B1+B2 の 1 つのコピーをそれぞれ作成します。 これらのブロックはノード間で「レイアウト」され、同じノード上の同じデータの交差を回避します。つまり、コピー A2 がコピー A1 と同じノード上に配置されることはありません。 B2、BXNUMXも同様です。

ノードの 3 つ (たとえば、B1 のコピーを含むノード No. 2) に障害が発生した場合、このコピーは、そのコピー (つまり、BXNUMX のコピー) が存在しないノード上で自動的にアクティブ化されます。

したがって、仮想ディスク (およびそれに応じて VM) は、RF-2 方式の XNUMX つのノードに障害が発生しても簡単に生き残ることができます。

レプリケーション スキームはシンプルで信頼性が高いものの、使用可能なスペースが足りないという RAID1 と同じ問題に悩まされています。

２）上記の問題を解決するために、消失符号化または消失符号化（「冗長符号化」、「消失符号化」または「冗長符号」とも呼ばれる）が存在する。 EC は、レプリケーションと比較してディスク領域のオーバーヘッドを低く抑えながら、高いデータ可用性を提供する冗長スキームです。 このメカニズムの動作原理は、RAID 2、5、6P と似ています。

エンコードの際、EC プロセスは、EC スキームに応じて、仮想ブロック (デフォルトでは 4MB) をいくつかの小さな「データ チャンク」に分割します (たとえば、2+1 スキームでは、各 4MB ブロックが 2 つの 2MB チャンクに分割されます)。 次に、このプロセスでは、以前に分割された部分の XNUMX つ以下の「データ チャンク」に対する「パリティ チャンク」が生成されます。 デコード時に、EC はクラスター全体で「生き残った」データを読み取ることによって、欠落しているチャンクを生成します。

たとえば、2 つのクラスタ ノードに実装された 1 + 4 EC スキームの仮想ディスクは、RF-2 と同様にクラスタ内の 2 つのノードの障害に容易に耐えることができます。 この場合、オーバーヘッドコストは低くなり、特に、RF-2 の有効容量係数は 2 であり、EC 1+1,5 の場合は XNUMX になります。

もう少し簡単に説明すると、本質は、仮想ブロックを2～8個（なぜ2～8個なのかは後述）の「個」に分割し、それらの個数に対して、同様のボリュームのパリティの「個」を計算するということです。

その結果、データとパリティはクラスターのすべてのノードに均等に分散されます。 同時に、レプリケーションと同様に、ARDFS は、同一のデータ (データのコピーとそのパリティ) が同じノードに保存されないように、データをノード間で自動的に分散し、データ損失の可能性を排除します。データとそのパリティは、障害が発生した XNUMX つのストレージ ノード上に突然存在することになります。

以下は、同じ 8 MB の仮想マシンと 4 つのノードを使用した例ですが、EC 2+1 スキームを使用しています。

ブロック A と B は、それぞれ 2 MB の 2 つの部分 (1+1 なので 2 つ)、つまり A1+A2 と B1+B2 に分割されます。 レプリカとは異なり、A4 は A2 のコピーではなく、ブロック B と同様に 2 つの部分に分割された仮想ブロック A です。合計で 4MB のセットが 2 つ得られ、それぞれに 2 MB の部分が 2 つ含まれます。 次に、これらの各セットについて、パリティが XNUMX 個 (つまり XNUMX MB) 未満のボリュームで計算され、追加の + XNUMX 個のパリティ (AP および BP) が得られます。 合計で XNUMX×XNUMX データ + XNUMX×XNUMX パリティがあります。

次に、データがパリティと交差しないように、ピースがノード間で「レイアウト」されます。 それらの。 A1 と A2 は AP と同じノード上にはありません。

1 つのノード (たとえば、2 番目のノード) に障害が発生した場合、障害が発生したブロック B1 は、ノード No.XNUMX に保存されている BP パリティから自動的に復元され、ノード No.XNUMX が存在するノードでアクティブ化されます。 Bパリティなし、つまりBPの一部。 この例では、ノード No.XNUMX です。

読者は次のような疑問を抱いていると思います。

「あなたが説明したことはすべて、競合他社とオープンソース ソリューションの両方で長い間実装されてきました。ARDFS での EC の実装との違いは何ですか?」

そして、ARDFS の興味深い機能も登場します。

柔軟性を重視したイレージャコーディング

当初、私たちはかなり柔軟な EC X+Y スキームを提供しました。ここで、X は 2 ～ 8 の数値に等しく、Y は 1 ～ 8 の数値に等しいですが、常に X 以下です。このスキームは提供されています。柔軟性のために。 仮想ブロックを分割するデータ数（Ｘ）を増やすと、オーバーヘッドコストを削減でき、つまり使用可能な領域を増やすことができる。
パリティ チャンク (Y) の数を増やすと、仮想ディスクの信頼性が高まります。 Y 値が大きいほど、クラスター内のより多くのノードが失敗する可能性があります。 もちろん、パリティ ボリュームを増やすと使用可能な容量は減りますが、これは信頼性の代償となります。

EC 回路に対する性能の依存性はほぼ直接的であり、「個数」が増えるほど性能は低下しますが、ここではもちろんバランスの取れた見方が必要です。

このアプローチにより、管理者は最大限の柔軟性を持って拡張ストレージを構成できます。 ARDFS プール内では、任意のフォールト トレランス スキームとその組み合わせを使用できます。これも非常に便利だと私たちは考えています。

以下は、いくつかの (すべてではない) RF スキームと EC スキームを比較した表です。

この表は、クラスタ内で同時に最大 8 ノードの損失を許容する最も「テリ」な組み合わせである EC 7+7 でさえ、標準レプリケーションよりも使用可能なスペースの「消費」が少なく (1,875 対 2)、保護が 7 倍優れていることを示しています。そのため、この保護メカニズムはより複雑ではありますが、ディスク容量が限られている状況で最大限の信頼性を確保する必要がある状況ではより魅力的になります。 同時に、X または Y に「プラス」を加えると、パフォーマンスのオーバーヘッドが追加されることを理解する必要があります。そのため、信頼性、節約、パフォーマンスの間の三角形の中で、非常に慎重に選択する必要があります。 このため、イレイジャー コーディングのサイジングについては別の記事で説明します。

ファイルシステムの信頼性と自律性

ARDFS はクラスターのすべてのノードでローカルに実行され、専用のイーサネット インターフェイスを介した独自の手段を使用してノードを同期します。 重要な点は、ARDFS がデータだけでなく、ストレージに関連するメタデータも独自に同期することです。 ARDFS に取り組んでいる間、私たちは多くの既存のソリューションを同時に調査しました。その結果、多くのソリューションは外部分散 DBMS を使用してファイル システム メタを同期していることがわかりました。これも同期に使用しますが、構成のみであり、FS メタデータは同期しません (このサブシステムおよび他の関連サブシステムについて)次の記事で)。

外部 DBMS を使用して FS メタデータを同期することは、もちろん有効なソリューションですが、その場合、ARDFS に保存されているデータの整合性は、外部 DBMS とその動作 (そして、率直に言って、これは気まぐれな女性です) に依存します。私たちの意見は悪いです。 なぜ？ FS メタデータが破損すると、FS データ自体も「別れ」を告げられる可能性があるため、より複雑ではあるが信頼性の高い方法を採用することにしました。

私たちは ARDFS 用のメタデータ同期サブシステムを独自に作成し、隣接するサブシステムから完全に独立して動作します。 それらの。 他のサブシステムは ARDFS データを破損できません。 私たちの意見では、これが最も信頼性が高く正しい方法ですが、これが実際にそうなのかどうかは時間が経てば分かるでしょう。 さらに、このアプローチには追加の利点もあります。 ARDFS は、拡張ストレージとして vAIR とは独立して使用でき、将来の製品では必ず使用する予定です。

その結果、ARDFS の開発により、容量を節約するか、パフォーマンスをすべて犠牲にするか、またはパフォーマンス要件を軽減しながらもリーズナブルなコストで超信頼性の高いストレージを作成するかの選択肢を提供する、柔軟で信頼性の高いファイル システムを入手しました。

シンプルなライセンス ポリシーと柔軟な配信モデル (将来的には、vAIR はノードごとにライセンスが付与され、ソフトウェアまたはソフトウェア パッケージとして配信されます) と併せて、さまざまな顧客の要件に合わせてソリューションを非常に正確に調整することが可能になります。このバランスを簡単に維持できます。

誰がこの奇跡を必要としているでしょうか？

一方で、ハイパーコンバージェンスの分野で本格的なソリューションを提供するプレーヤーがすでに市場に存在しており、これが私たちが実際に向かっているところであると言えます。 この言葉は真実であるように思えますが、...

一方で、私たちが現場に出て顧客とコミュニケーションをとると、私たちもパートナーも、それがまったく当てはまらないことに気づきます。 ハイパーコンバージェンスには多くの課題があり、人々がそのようなソリューションの存在を単に知らなかった場所もあれば、高価に思えた場所もあり、代替ソリューションのテストが失敗した場所もあり、制裁のために購入を一切禁止している場所もあります。 一般に、畑は耕されていないことが判明したので、未使用の土壌を育てに行きました）））。

ストレージ システムが GCS よりも優れているのはどのような場合ですか?

市場と連携していると、ストレージ システムでクラシックなスキームを使用する方がよいのはどのような場合なのか、ハイパーコンバージェントを使用するのはどのような場合なのか、とよく尋ねられます。 GCS を製造している多くの企業 (特に、自社のポートフォリオにストレージ システムを含まない企業) は、「ストレージ システムは時代遅れになりつつあり、ハイパーコンバージドのみになりつつあります。」と言っています。 これは大胆な発言ですが、現実を完全に反映しているわけではありません。

実際、ストレージ市場は確かにハイパーコンバージェンスや同様のソリューションに向かって進んでいますが、常に「しかし」があります。

まず、ストレージ システムを備えた古典的なスキームに従って構築されたデータ センターと IT インフラストラクチャは簡単に再構築できないため、そのようなインフラストラクチャの最新化と完成は依然として 5 ～ 7 年間の遺産となっています。

第二に、現在構築されているインフラストラクチャの大部分 (ロシア連邦を意味します) は、ストレージ システムを使用した古典的なスキームに従って構築されています。これは、人々がハイパーコンバージェンスについて知らないからではなく、ハイパーコンバージェンス市場が新しく、ソリューションや標準はまだ確立されておらず、IT 担当者はまだ訓練されておらず、経験もほとんどありませんが、今ここでデータ センターを構築する必要があります。 そして、この傾向はさらに 3 ～ 5 年間続くでしょう (その後、別の遺産が残ります。ポイント 1 を参照)。

第三に、書き込みごとに 2 ミリ秒の追加の小さな遅延 (もちろんローカル キャッシュを除く) という純粋に技術的な制限があり、これが分散ストレージのコストとなります。

そうですね、ディスク サブシステムの垂直方向のスケーリングを好む大規模な物理サーバーの使用を忘れないでください。

ストレージ システムが GCS よりも適切に動作する、必要かつ一般的なタスクが数多くあります。 もちろん、製品ポートフォリオにストレージ システムを含まないメーカーは私たちの意見に同意しないでしょうが、私たちは合理的に議論する準備ができています。 もちろん、私たちは両製品の開発者として、将来の出版物のいずれかでストレージ システムと GCS を確実に比較し、どのような条件下でどちらが優れているかを明確に示します。

そして、ハイパーコンバージド ソリューションがストレージ システムよりもうまく機能するのはどこでしょうか?

上記の点に基づいて、次の XNUMX つの明らかな結論を導き出すことができます。

1. どの製品でも一貫して発生する、録音時の追加 2 ミリ秒のレイテンシ (合成製品については話していません。合成製品ではナノ秒が表示される可能性があります) が重要ではない場合、ハイパーコンバージェントが適しています。
2. 大規模な物理サーバーからの負荷を多数の小規模な仮想サーバーに変換してノード間で分散できる場合、そこでもハイパーコンバージェンスがうまく機能します。
3. 水平方向のスケーリングが垂直方向のスケーリングよりも優先される場合、GCS はそこでも問題なく機能します。

これらの解決策とは何でしょうか?

1. すべての標準インフラストラクチャ サービス (ディレクトリ サービス、メール、EDMS、ファイル サーバー、小規模または中規模の ERP および BI システムなど)。 私たちはこれを「ジェネラル・コンピューティング」と呼んでいます。
2. クラウド プロバイダーのインフラストラクチャでは、クライアントのために多数の仮想マシンを迅速かつ標準化して水平方向に拡張し、簡単に「カット」する必要があります。
3. 仮想デスクトップ インフラストラクチャ (VDI)。多数の小規模なユーザー仮想マシンが実行され、均一なクラスター内で静かに「浮遊」します。
4. ブランチ ネットワーク。各ブランチには、15 ～ 20 台の仮想マシンからなる標準的でフォールト トレラントな低コストのインフラストラクチャが必要です。
5. あらゆる分散コンピューティング (ビッグ データ サービスなど)。 負荷がかかるのは「深さ」ではなく「幅」です。
6. 多少の遅延が追加されても許容されるテスト環境。ただし、テストであるため予算の制限があります。

現時点では、これらのタスクのために AERODISK vAIR を作成し、それに焦点を当てています (これまでのところ成功しています)。 おそらくこれはすぐに変わるでしょう、なぜなら... 世界は静止していません。

だから... ...

これで大規模な記事シリーズの最初の部分が完了しました。次の記事では、ソリューションのアーキテクチャと使用されるコンポーネントについて説明します。

質問、提案、建設的な議論を歓迎します。

出所： habr.com