分散ストレージシステムの雪崩効果

1. 分散ストレージシステムの背景

レプリカは分散ストレージ システムの一般的な概念です。特定のサイズのデータ​​は、特定の冗長性戦略に従って保存され、ローカル障害が発生した場合でもシステムの可用性が確保されます。

レプリカ間の冗長性を複製する方法は多数ありますが、一般的に使用されるのは次の 2 つです。

• パイプライン: パイプライン (a->b->c) と同様に、データはパイプラインを通じてコピーされます。この方法はスループットが高くなりますが、ノードが遅いという問題があります。ノードが混雑すると、プロセス全体に影響が及びます。
• 配布: クライアント -> a クライアント -> b クライアント -> c。システム全体のスループットは低いが、低速ノードの問題はない

[[249877]]

冗長コピーの数については、この記事では一般的な 3 つのコピー ソリューションを選択します。

分散ストレージシステムには、一般的にレプリカを自動的に復元する機能があります。ローカル ストレージ ノードに障害が発生すると、他のノード (レプリカ レプリケーション プロトコルに応じて、データ レプリカのマスター ノードまたはクライアント ノード) が自動的にレプリカ修復を開始し、ダウンしたストレージ ノードのデータ コピーを他の正常なノードに復元します。軽微な停止の場合、クラスターのレプリカ自動修復戦略は正常に機能します。しかし、大規模ストレージ サービスの運用保守経験によれば、ディスク障害率が月あたり X パーセント、スイッチ障害率が月あたり X 千分の 1 の場合、1 年に数回のマシン停止につながる可能性があります。さらに、バッチ アップグレード プロセス中にアップグレード バグが発生した場合、クラスターはダウンタイム処理の要件に従ってレプリカを修復する必要があり、通常時間内に完了できるアップグレード時間が延長され、多数のダウンタイム イベントが発生しやすくなります。

2. 雪崩効果の発生

一定期間内に多数のダウンタイム イベントが発生すると、システムの大規模なレプリカ完了戦略がトリガーされる可能性が高くなります。現在の分散ストレージ システムの 2 つの特性により、この大規模なレプリカ完了戦略はシステム内で雪崩効果を引き起こしやすくなります。

a.クラスタ全体の空き容量は小さい: 通常、全体では 30% 以下、ローカル マシンでは 20% 以下、場合によっては 10% 以下

b.アプリケーションハイブリッド: 異なるアプリケーションを同じ物理/仮想マシンに展開して、ハードウェアリソースを最大限に活用します。

今年人気が高まった各種オンラインストレージやクラウドストレージサービスなどがその代表例です。大手企業は個人ストレージ容量を1Tに増やす競争をしているが、実は運用コストやメンテナンスコストでも競争している。既存のクラウド ストレージのほとんどは、増加するだけで減少することはなく、データの人気度や冷たさに基づいてデータを分類します (Facebook のデータ分類プロジェクトと同様)。クラウドストレージの総量は大きいですが、増加分は比較的小さいです。ストレージリソースと帯域幅リソースの無駄を削減するため、新しく作成されたファイルが元のストレージデータにすでに同じ md5 または sha1 署名を持っている場合は、既存のファイルとして扱われ、内部的にリンクされ、新しいファイルは作成されません。しかし、それでも、データ全体の量はまだ非常に大きいです。

現在、クラウドストレージ関連の事業は明確な収入源を持っておらず、サーバー1台あたり年間数万元のコストがかかります。運用コストを考慮して、バックエンドの分散ストレージ システムのアイドル率は非常に低くなっています。突然のバッチ停止により、多数のレプリカ修復が発生し、すでにストレージ クォータに近づいている他の残存マシンがいっぱいになり、マシンがダウンタイムまたは読み取り専用状態になる可能性があります。この状態が続くと、クラスター全体が崩壊し、システムが無効になる可能性があります。

3. 雪崩を防ぐ

このセクションでは、主にシステムの内部ロジック処理において、システム全体のアバランシェの発生を防ぐ方法について説明します。事故後の対応よりも予防​​の方が重要です。クラスタの状態を予測し、事前に最適化することも雪崩を防ぐ方向性となってきました。

以下に、実際に起こったいくつかのシナリオをご紹介します。

1. ラック間レプリカ選択アルゴリズムとマシンリソースおよびユーザーロジックの分離

現地修復：

ある日、運用保守スタッフは、クラスター内の数十台のマシンが瞬時に接続を失い、レプリカの修復をトリガーする役割を担うマスター制御ノードが異常なレプリカ修復を実行し始めたことを発見しました。多数のユーザーから、クラスターの速度が低下し、読み取りと書き込みが停止しているとの報告が始まりました。

現地対応:

優先解決策: レプリカ修復量が多すぎるため、クラスター全体が影響を受けます。

a.状況に対処したエンジニアは、迅速な判断を下し、gdb 内のレプリカを修復する条件を、元の 3 (replicas_num) ではなく、レプリカ数 < 2 に処理するように変更しました。これにより、マスター ノードはレプリカが 2 つ未満のファイルのみを修復できるようになり、失われていないファイルの冗長コピーが少なくとも 1 つ存在することが保証され、コピーが 1 つしかない場合に発生する可能性のあるハングアップによるファイルの損失を防ぐことができます。

b.この一連のマシンの切断の問題を緊急に解決し、スイッチの問題であることがわかりました。 abcd IP セグメントの c セグメント内のマシンのバッチに障害があります。ネットワーク チームにできるだけ早く修復するよう依頼してください。

紀元前レプリカ数が 2 以上に修復されると、Gdb はレプリカ不足の検出期間を変更し、検出時間を数十秒から 1 日に遅らせます。ネットワーク チームがスイッチの問題を解決するまで待ちます。

d.ネットワークが復元され、元のマシンがクラスターに再参加します。多数の 2 コピー ファイルが 3 コピーに戻され、一部の 3 コピーの失われたファイルも回復されました。

e.マスター制御ノードを通常のパラメータ設定状態に復元すると、システムは通常の修復を開始します。

改善策：

改善策を講じる前に、まずは今回のインシデントで明らかになったシステムの欠陥を分析してみましょう。

1) マスターパラメータはホットフィックスをサポートしておらず、Gdb オンラインプロセスのリスクが高すぎます。

2) 一定数の局所的なマシン障害がクラスター全体に影響を及ぼします (大規模なクラスターと比較すると、数十台のマシンは依然として局所的な障害と見なされます)。前述のように、障害発生率が 1 か月あたり数千分の 1 であるため、スイッチ障害によってストレージ システムがクラスターの影響を受ける可能性が常に存在します。

事例分析後の改善策：

1) マスターは、コアパラメータの熱変更をできるだけ早くサポートできるように、事前に熱変更機能のスケジュールをサポートします。

オンライン化後のホットモディフィケーションの効果は顕著であり、その後のいくつかのオンライン問題を回避しました。

2) データ レプリカ ストレージ ホスト マシンを選択するためのピックアップ アルゴリズムにクロス スイッチ (ラック) 戦略を追加し、ラック間でレプリカが選択されるようにします (または確実に選択します)。このアルゴリズムでは、少なくとも 1 つのレプリカが他の 2 つのレプリカとは異なるスイッチ (IP abcd のセグメント c) に配置されます。この対策は、新しいストレージ データ レプリカの選択と、レプリカ損失後のレプリカ完了戦略の両方に作用します。これにより、レプリカ ホストの選択におけるスイッチ障害によるシステムのデータ損失が防止され、レプリカ完了キュー/リストにある多数のレプリカ ノードが失われ、マスター ノードの負荷が増加するのを防ぐことができます。

3) 地域別に機械を隔離する機能が議題に上がっています。ユーザーの保存場所を地域ごとに論理的に分割する機能が検討されています。地域をまたいでピックアップアルゴリズムを追加することが議題に上がっています。

a) マシンは物理的な場所に応じて領域に分割され、ユーザーは領域に応じて論理的なストレージの場所に分割されます。これにより、ローカル障害が発生した場合に、クラスターはこれらのマシンに論理的に分割されているユーザーにのみ影響を与えることができます。

この場合、最悪のシナリオは、リージョンが使用できなくなり、リージョンの読み取りおよび書き込み権限を持つユーザーが影響を受けることです。 Pickup アルゴリズムのクロスリージョン設計により、他のコピーが他のリージョンに保存されるため、分割されたリージョンのユーザーは、1 つのリージョンが使用できなくなってもデータを失うことはありません。したがって、コア スイッチの障害によってリージョン内の数百台のマシンがダウンしたとしても、クラスターに大規模な影響は及ぼされません。

b) リージョンの信頼性の概念を追加し、マシンの安定性係数をレプリカ冗長アルゴリズムに組み込みます。

クラスターのサイズが一定レベルに達すると、マシンの安定性が異なるという問題が発生します (一般的に、同じバッチ内のマシンの安定性は一貫しています)。領域の安定性をマークすることで、データのコピーを選択するときに少なくとも 1 つのコピーを安定したコピーに強制することができ、すべてのコピーが失われる可能性を減らすことができます。

c) リージョン分割では、ユーザー操作応答時間 SLA、物理的なマシンの安定性、地理的な場所などの情報を総合的に考慮する必要があります。

適切な領域分割は、システムの安定性の向上、操作応答時間の改善、システムクラッシュの防止に役立ちます。洗練されたパーティション分割ルールにより全体的な安定性は向上しますが、システムの複雑さも増大します。この選択をどのように行うかは、読者が深く考えることに委ねられています。

2. クラスタフロー制御を実装する

分散ストレージ システムの特性に適合するフロー制御の普遍的な原則があります。 それは、どの操作も処理時間をあまり取らないようにすることです。ここでの「任意の操作」には、システム トラフィックが急増したときや、一定数のマシンがローカルでダウンしたときに実行される操作が含まれます。これらの操作を円滑かつ適切に処理することによってのみ、システム全体が影響を受けず、異常によってシステム全体が崩壊することもないことを保証できます。

現地修復：

1) シナリオ 1 ある日、運用保守担当者は、一定期間内にクラスターの書き込み操作が大幅に増加したことを発見しました。あるストレージノードを観察すると、書き込みだけでなくランダム書き込みも行われていることがわかります。一部の製品ラインでは全体的なスループットが低下しました。

2) シナリオ 2 大規模なクラスター ストレージ ユーザーは、業務を調整し、元のデータを変更し、大量のデータを削除する必要があります。

運用保守スタッフは、次のことを発見しました。クラスター全体が GC ガベージ コレクションの狂気の段階にあり、b.特にメタ情報の更新を伴う操作では、クラスターの応答速度が大幅に低下しました。

3) シナリオ 3 ある日、運用保守担当者は、クラスターの同時実行量が急増し、単一のユーザー xyz が大量の同時操作を実行していることに気付きました。当初のユーザー調査によれば、このユーザーにはこのような大規模な使用シナリオはないはずです。

このタイプのクラスターの特定の操作では、予期しない急増が多数発生しますが、ここでは繰り返しません。

現地対応:

1) 関係するユーザーにすぐに連絡を取り、操作の急増の理由を把握します。不当な急増にはすぐに対処する必要があります。

次のような不当な急増が見られました。

a.シナリオ 1: コードレビューにより、多数の操作でランダムな読み取りおよび書き込みの変更が実行されていることが判明しました。ランダム読み取りと書き込みを読み取りと変更 + 新しいファイルの書き込み + 古いファイルの削除に変換し、ランダム読み取りと書き込みを順次読み取りと書き込みに変換することをお勧めします。

b.シナリオ 3: 製品ラインのパフォーマンスがオンラインでテストされました。運用保守担当者は直ちに製品ラインに関連作業の停止を通知しました。すべてのパブリック クラスターは電子メールで繰り返し通知されており、パフォーマンス テストには使用できません。必要に応じて、関係者に連絡して、専用クラスターでパフォーマンス シナリオ テストを実施してください。

2) クラスタのあらゆる側面におけるフロー制御機構機能の設計と実装を推進し、オンラインで起動します。

改善策：

1) ユーザー操作フロー制御

a.ユーザー操作のフロー制御制限

これは、内部システム設計または外部ネットワーク フロー制御などを通じて実現でき、単一のユーザーがクラスター全体のリソースを過度に占有しないように、単一のユーザーに特定のフロー制御制限を課すことができます。

b.ストレージノード操作フロー制御

クラスターのリソース消費に応じて、高、中、低の 3 つのレイヤーに分けられます。各レイヤーは、トークンを掴むのと同様のデザインを実装します。各レイヤーのトークンの数は、クラスター練習後により適切な値に調整されます。これにより、特定の種類の操作がクラスターの負荷を過度に消費することが防止されます。特定の種類の操作が過度の負荷を消費すると、他の種類の操作の要求が遅延される可能性があり、その結果、タイムアウト後の再試行や小規模なクラッシュが発生し、それがクラスター全体に広がり、全体的なクラッシュを引き起こす可能性があります。

紀元前ガベージコレクション GC はフロー制御処理を別途実行します。分散ストレージ システムにおける削除操作の一般的な設計は、ユーザーの削除操作を受信すると、削除されたコンテンツのメタ情報がマークされて直接返され、その後、ポリシー制御と制限付き削除が実行され、大量の GC 操作によって単一のストレージ ノードのディスク処理能力が過度に消費されるのを防ぎます。クラスターの特性に応じて、具体的な電流制限戦略とトークン値の設定を実践し、最適な設定を取得する必要があります。

2) フロー制御ブラックリスト

ユーザーは人工的なシステムを使用してオンライン テストのシナリオを制限できますが、オンライン ユーザーのバグがオンライン テストの規模と同等の影響をもたらすシナリオを回避することはできません。このようなシナリオでは、通常、操作の数は短期間で現在の制限を大幅に超過します。

このようなシナリオでは、フロー制御ブラックリストを設定できます。ユーザーが短期間（例：1時間）内に設定された上限を大幅に超過した場合、そのユーザーはブラックリストに追加され、一時的に操作がブロックされます。外部監視により、緊急処理のために運用保守チームに通知されます。

3) ストレージノードの同時修復とレプリカフロー制御の作成

大量のデータコピー修復操作やコピー作成操作に速度制限がない場合、ストレージノードの帯域幅、CPU、メモリなどのリソースが占有され、通常の読み取りおよび書き込みサービスに影響を及ぼし、大きな遅延が発生します。大きな遅延が発生すると再試行がトリガーされ、クラスターのビジー状態が増加する可能性があります。

同じデータ ホスト プロセスでは、エントリ帯域幅が過度に占有されないように、また、そのような操作の過剰なパフォーマンスによってプロセスが他の多数の操作の遅延時間を増加させないように、同時レプリカ修復およびレプリカ作成の数を制限する必要があります。これは、分散レプリカ複製プロトコルを採用しているシステムにとって特に重要です。分散プロトコルには通常、低速ノード チェック メカニズムが備わっており、レプリカ フロー制御によってシステムのレイテンシがさらに増加し​​たり、低速ノードになる可能性が高くなったりすることはありません。低速ノードの可能性が高まると、低速ノードのチェック メカニズムにより、新しく作成されたファイルは作成時にコピーが不足する可能性があり、クラスターの状態が悪化します。

3. 早めに予測して行動する

1) ディスク障害を予測し、単一のディスクエラーを許容します。

シーン再現：

あるメーカーが製造した SSD ディスクのロットに問題がありました。クラスターが一定期間オンラインになった後、ローカルに多数の不良ディスクが発生しましたが、すべてのディスクが破損したわけではありません。当時は、単一ディスクのフォールト トレランス メカニズムは存在しませんでした。ディスクに障害が発生すると、マシン全体が使用できなくなり、障害が発生したディスクを持つすべてのマシンが使用できなくなります。クラスターは一定期間レプリカ修復状態になり、スループットに大きな影響が出ます。

改善策：

a)ハードディスクの状態を予測し、不良になる可能性のあるデータコピーを自動的に移行する

近年、ディスクの健全性状態を事前に予測する技術がますます成熟してきています。ディスクの健全性を予測し、ディスクの障害の可能性が高くなる前にデータを他のディスクに自動的に移行することは技術的に可能であり、これによりディスク障害がシステムの安定性に与える影響を軽減できます。

b)単一ハードディスクエラーに対するフォールトトレランス

ストレージ ノードは不良ディスクの例外処理をサポートします。単一のディスクに障害が発生した場合、プロセス全体がクラッシュするのではなく、単一のディスクの元のデータが自動的に他のディスクに移行/修復されます。プロセス全体がクラッシュすると、分散ストレージ システムでは他のディスク上のデータもコピーが欠落していると見なされるためです。ストレージ リソースが不足しているクラスターでこのようなクラッシュ イベントが発生すると、コピー修復プロセスに長い時間がかかります。既存の分散ストレージシステムにも、Taobao TFS と同様に、各ディスクが管理用のプロセスを起動し、起動されるプロセスの数はマシン全体にマウントされているディスクの数と同じです。

2) 既存のストレージ配分に基づいてバランスの展開を予測し、事前に負荷分散操作を実行します。

この種の戦略的設計はますます一般的になりつつあります。分散ストレージ クラスターがダウンした後の修復戦略により、クラスター内の一部のマシンは常にホットスポット マシンになる可能性があります。このようなマシンのホットスポットを予測し、一部のデータを事前に負荷が比較的低いマシンに移行することができます。

レプリカ選択戦略と同様に、負荷分散戦略では、複雑さと最適化の度合いの間でトレードオフが必要です。複雑なバランス調整戦略はクラスター負荷を軽減しますが、複雑さが増し、バグ率が高くなる問題も生じます。どのように選択するかは、分散ストレージ システムの設計者を悩ませる難しい問題です。

4つの安全モード

セーフティモードは、プロジェクト実践中に発生する分散ストレージシステムの雪崩を防ぐ強力な武器なので、特別に別セクションとして紹介しました 。基本的な考え方は、一定期間内にダウンタイムの数が予想される上限を超えた場合に、クラスターをセーフ モードにすることです。ポリシー構成と状況の重大度に応じて、クラスターはレプリカの修復を停止し、すべての操作が停止するまで読み取りと書き込みを停止します (一般的な戦略)。

マシン領域の概念がないシステムでは、セーフ モードによって適切な保護を提供できます。以前参加したプロジェクトで大規模な障害が発生しました。セーフ モードがないため、システムはレプリカ修復の通常処理を実行し、元々正常なストレージ ノードが機能しなくなり、その後雪崩が発生し、クラスター全体がレプリカ修復が異常終了する状態に陥りました。この状態以降は、発生したレプリカ修復によってメタデータ/実データが変更されるため、クラスター修復プロセスが困難になります。このインシデントの最終的な結果は、コールド バックアップ データからデータのコピーが復元されましたが、障害が発生した時点までのコールド バックアップのデータは失われました。

もちろん、セーフモードは完璧ではありません。 「期間」と「上限」をどのように設定するか、レプリカの修復をいつ停止するか、読み取りをいつ停止するか、書き込みをいつ停止するか、自動的に通常の状態に復元するか、手動介入によって復元するか、リージョン レベルでセキュリティ モードを十分に強力にする必要があるかなど、セキュリティ モードではこれらすべての問題を考慮する必要があり、このタイプの設計は一般に、クラスター設計の対象ユーザーと密接に関連しています。たとえば、ユーザーが低レイテンシでビジネスに敏感な場合は、読み取りと書き込みに影響しない小規模な障害を選択する可能性がありますが、高レイテンシで高スループットのクラスターでは、読み取りと書き込みの中断を受け入れることができます。

5つの考え

分散ストレージ システムの複雑さとスペースの制限のため、この記事では分析と説明のために限られた数の典型的なシナリオのみを選択します。実際の分散ストレージ システムは、これらのいくつかのケースよりもはるかに複雑で詳細です。自動化されたクラスター例外処理と導入の複雑さのバランスをとる方法、フロー制御をより適切に実装して低レイテンシ ユーザーの応答時間への影響を回避する方法、クラスターをロード バランシングに誘導してロード バランシングによって発生するクラスター リソースの過剰なオーバーヘッドを回避する方法など、実際の分散ストレージ システムの設計では、このような問題が絶え間なく発生します。あなたがデザイナーだったら、どのように選びますか？