Ceph の運用と保守では、オープンソースの分散ストレージを制御する方法について説明します。

過去 2 年間、私の主な仕事は Hadoop テクノロジー スタックでしたが、最近 Ceph に触れる機会がありました。

[[236548]]

私にとって、もう一つの大規模分散ストレージソリューションを体験する機会を得られたことは、とても幸運なことだと思います。

したがって、ほぼ完全に異なる 2 つのストレージ システムである HDFS と Ceph の長所と短所、および適切なシナリオを比較することができます。

SRE の観点から見ると、分散ストレージ、特にオープンソースの分散ストレージは、営利企業にとって次のような問題を解決すると思います。

• ビジネスの成長によって生じる膨大なデータ ストレージのニーズを満たすスケーラビリティ。
• 商用ストレージよりも安価で、コストを大幅に削減します。
• 安定性、制御性、メンテナンス性に優れています。

簡単に言えば、目標は使いやすく、安価で、安定していることです。しかし、現実はそれほど良くないようです...

この記事では、私が信じているこの 3 つの基本的な価値観から始めて、Ceph の運用と保守に関する私の経験を分析し、HDFS などの集中型分散ストレージ システムと比較しながら、横断的に説明します。

スケーラビリティ

Ceph は CRUSH アルゴリズムに基づいており、中央ノードがないため、無限にスケーラブルであると主張しています。実際、Ceph は無限に拡張できますが、Ceph の無限拡張のプロセスは美しくありません。

まず、Ceph の書き込みプロセスを確認しましょう。Ceph に書き込まれる新しいオブジェクトは、PG レイヤーで事前定義されたクォータ ハッシュ シャードを通過し、次に PG を通過し、クラスター内のすべての物理マシンの OSD で構成されるハッシュを通過し、最後に物理ディスクに落ちます。

したがって、すべての Ceph オブジェクトは最初に固定数のバケット (PG) に事前ハッシュされ、次にクラスターの全体的な物理アーキテクチャ クラッシュマップに基づいて特定のマシン ディスクに配置されるように選択されます。

これは拡張にどのような影響を与えますか?

拡張粒度

拡張粒度の私の定義は、一度に拡張できるマシンの数です。

実際には、Ceph の容量拡張は「障害ドメイン」によって制約され、一度に拡張できる「障害ドメイン」は 1 つだけです。

障害ドメインはレプリカ分離レベルです。つまり、同じレプリカのデータが異なるディスク/マシン/ラック/コンピューター ルームに配置されます。障害ドメインの概念は、HDFS を含む多くのストレージ ソリューションに存在します。

Ceph が影響を受けるのはなぜですか? Ceph には集中型のメタデータ ノードがないため、データ配置戦略が影響を受けます。

データ配置戦略、つまり、データ レプリカがどのマシンとハード ディスクに配置されるか。

HDFS などの集中化では、各ファイルと各データ ブロックの保存場所が以下に記録されます。

この場所は頻繁に変更されません。新しいファイルが作成されたとき、バランサーが再バランスされたとき、ハード ドライブに障害が発生したとき、または中央ノードが損傷したハードウェア上のデータを再配置した場合にのみ変更されます。

Ceph は分散化されているため、Crushmap の変更に応じてデータを保持する PG の場所が変更されます。

新しいマシンとハードディスクが到着すると、影響を受ける PG の一部に対して新しい場所を計算する必要があります。コンシステント・ハッシュに基づくテクノロジーも、容量を拡張する際に同じ問題に直面します。

したがって、Ceph の拡張には PG の調整が必要です。この調整により、Ceph は「障害ドメイン」の影響を受けます。

たとえば、レプリカが 3 つある PG があります。 Ceph クラスターでは、外部に通常のサービスを提供するために、PG が少なくとも 2 つの完全なレプリカを持つ必要があるという構成になっています。

このデータ プールの障害ドメインがホストの場合、2 台のマシンが同時に拡張されると、一部の PG は 3 つのレプリカのうち 2 つを 2 台の新しいマシンにマップすることがあります。

これら両方のコピーは新しいコピーであり、完全かつ最新のデータが含まれていません。残りのコピーは、古いマシンに少なくとも 2 つの完全なコピーがあるという要件を満たすことができず、通常の読み取りおよび書き込みサービスを提供できません。

これにより、この PG 内のすべてのオブジェクトが外部サービスの提供を停止します。

もちろん、管理者は構成を下げて、データ プールの min_size を 1 に減らすことができます。ただし、この構成では、通常の状況でもディスク障害によりデータが失われる可能性があるため、通常はこのように設定されません。

では、容量を拡張する場合、一度に 1 台のマシンのみを拡張すれば安全でしょうか?

これにより、すべての PG の完全なコピーが古いマシン上に少なくとも 2 つ存在するようになります。しかし、1 台のマシンの容量を拡張したとしても、拡張中に古いマシンのハードディスクが故障し、PG の完全なコピーが再び 1 に減少するという極端な状況に直面することになります。

PG が機能しない場合でも、データの永続性は問題になりません。国内の AT クラウドのサービス信頼性は特に高くなく、3 9 や 4 9 の耐久性は達成されていません。

これら 2 つの大規模クラウドのオブジェクト ストレージが Ceph を使用しているかどうかはわかりませんが、オブジェクト ストレージが CRUSH アルゴリズムやコンシステント ハッシュなどの分散技術に基づいている限り、一部のデータが一時的に利用できなくなる状況に直面するはずです。

最も極端なケース、つまり、容量を拡張するときに、「障害ドメイン」としてマシンを追加するときに、当面ディスクの損傷がないと仮定します。では、拡張の粒度を改善する方法はあるのでしょうか?

解決策は、Ceph クラスターの計画を開始するときに、ラックなどのより大きなレベルの「障害ドメイン」を設定することです。

実際のラックの場合もあれば、存在しない場合でも論理ラックの場合もあります。このように、容量を拡張するときに、論理的な「フォールト トレランス ドメイン」を拡張することができ、1 台のマシンを拡張するという制限を打ち破り、少なくとも複数のマシンを含むラック全体を拡張することができます。

ヒント: ここでは、拡張の粒度が小さいことがなぜ悪いことなのかについては説明していません。多くの企業では、日々のデータの増加が 1 台のマシンのストレージ容量を上回る可能性があります。

こうなると、拡張速度が書き込み速度に追いつけないという困った状況に陥ってしまいます。これは、最初に適切に設計されておらず、後の段階で迅速な展開のために設定されているクラスターに多大な損害を与えます。

拡張中のクラッシュマップの変更

Ceph は、クラッシュマップに従って PG の物理的な場所を配置します。拡張が半分完了した時点でハードディスクに障害が発生すると、Ceph のクラッシュマップが変更され、Ceph は PG を再ハッシュし、多くの PG の場所が再計算されます。

運が悪ければ、機械の拡張が安定した状態に戻るまでに長い時間がかかる可能性があります。

この crushmap の変更によって発生する Ceph の再バランス調整は、容量を拡張するときだけでなく、ほぼいつでも大規模なストレージ クラスターにとって頭痛の種となります。

新しいクラスターが構築されると、ハードドライブは比較的新しいため、故障率は高くありません。ただし、2 ～ 3 年間稼働している大規模なストレージ クラスターでは、ディスク障害は実際には頻繁に発生します。 1,000 台のデバイスのクラスターでは、1 日に 2 ～ 3 回のディスク障害が発生するのは正常です。

クラッシュマップは頻繁に変更されるため、Ceph の不安定性に大きな影響を与えます。その結果、全体的な IO が減少する可能性があり (ディスク IO は繰り返しの再バランスによって占有されます)、一部のデータが一時的に使用できなくなる場合もあります。

したがって、一般的に、Ceph の拡張は少し不愉快です。 Ceph は無制限のスケーラビリティを提供しますが、拡張プロセスはスムーズではなく、完全に制御可能ではありません。

crushmap の設計は優れた分散化効果を実現しますが、クラスターが大きくなると不安定になる落とし穴も生じます。

メタデータが集中管理されている HDFS と異なり、容量拡張に関する制限はほとんどなく、自由に容量を拡張できます。古いデータの移行と再バランス調整は別のジョブで処理され、処理も非常に効率的です。

満杯のノードと空のノードをペアにして、古いノードから十分なデータを移動し、新しいマシンを埋めます。集中化されたメタデータは、スケーリングと再バランス調整に関しては実際に利点になります。

容量が一定レベルまで拡大したら、PGの数を調整する必要がある

上記の Ceph データ書き込みフローチャートに示されているように、Ceph オブジェクトの最小配置単位は PG であり、ハードディスク上に配置されます。理論的には、PG が大きいほど良いです。

これは、データ シャーディングがよりランダムになり、疑似ランダム性によって引き起こされる単一ディスク容量の過度の偏差の問題をよりうまくカバーできるためです。

しかし、実際には、PG の数は多ければ多いほど良いのです。 CPU、メモリ、ネットワークなどのハードウェアによって制限されます。そのため、PGの数を計画する際には、やみくもに増やすことはありません。一般コミュニティでも 200pg/osd が推奨されています。

現在、10 台のマシンがあり、それぞれにハード ディスクがあり、合計 10 台のディスク、1024 個の PG があり、PG がすべて単一のコピーであるとすると、各ディスクには 100 個の PG が保存されます。

この設定は現時点では非常に健全ですが、クラスターを 1,000 台のマシンに拡張すると、各ハード ディスクには PG が 1 つしか存在しなくなり、疑似ランダム性によって生じる不均衡が増幅されます。したがって、管理者は PG の数を調整するという問題に直面する必要があり、それが問題を引き起こします。

PG を調整するということは、基本的にクラスター全体が深刻な異常状態になることを意味します。調整された PG に関係するオブジェクトの約 50% を物理的に再配置する必要があり、これによりサービス品質が著しく低下します。

PG の調整は頻繁に行われるイベントではありませんが、大規模なストレージ システムでは、開発が進むにつれて、この大きなテストを受けることが避けられません。

商業用ストレージよりも安価

商用ストレージとの比較について話す場合、通常は EMC や IBM などのハードウェアおよびソフトウェア ストレージ ソリューション メーカー、または Aliyun や AWS などのクラウド ソリューションとの比較を指します。

独自のコンピューター ルームを構築すると、ハードウェアの単価は当然安くなりますが、次のような全体的なコストを考慮する必要があります。

• ハードウェアコスト
• 自立した運営・保守要員の費用
• サービス品質は平均から良好へと徐々に収束する

私は人的コストなどの形而上学的な問題については議論しません。この記事では、ハードウェア コストの観点から Ceph が興味深い点についてのみ説明します。

論理的に言えば、独自のコンピューター ルームを構築すれば、ハードウェア コストは間違いなく安くなるはずですが、ここで Ceph の何が特別なのでしょうか?問題は、クラスターの信頼性の高い利用です。

信頼性の高いクラスターの使用とは、クラスター全体の容量が一定のレベルに達すると、外部サービスを提供できなくなったり、高可用性サービスを維持できなくなったりすることを意味します。

たとえば、携帯電話のフラッシュメモリやコンピュータのハードドライブは、99% でも正常に動作しますか?もちろん、ローカルストレージだからです。クラウド ソリューションの場合、当然この問題は発生しません。

EMC の Isilon 分散ファイル システムなどの商用ストレージ ソリューションの場合、ストレージ容量は 98 ～ 99% に達しても外部サービスを提供できます。

HDFS の場合、95% 未満では、ストレージは外部サービスも適切に提供できます。 HDFS 上で実行されている Hadoop ジョブは、データをローカルに書き込むことができないため失敗します。

Ceph に関しては、この領域ではパフォーマンスがよくありません。経験上、クラスター全体の使用率が 70% に達すると、不安定な状態になる可能性があります。

これはなぜでしょうか?問題は、分散化によってもたらされるトレードオフにあります。

Ceph は分散型の分散ソリューションであり、オブジェクトのメタデータは各物理マシンに分散されます。したがって、すべてのオブジェクトは各ディスクに「疑似ランダムに」割り当てられます。

疑似ランダム性では、すべてのディスクの完全な均一な分散を保証することはできず、多くの大きなオブジェクトが同時に同じディスクに落ちる確率を減らすこともできません (PG のレイヤーを追加し、PG のレプリカを増やすと、ディスクのばらつきを減らすことができると理解しています)。そのため、平均よりも使用率が高いディスクが常に存在します。

クラスター全体の使用率が高くない場合は問題はありません。使用率が 70% に達すると、管理者の介入が必要になります。

大きな変動があるため、市場は 95% の赤線に触れる可能性があります。管理者は、容量が過剰なディスクの再重み付けを削減し始めます。

ただし、このディスク バッチの再重み付けが完了する前に一部のディスクがいっぱいになった場合、管理者は Ceph が安定した状態に達する前に、過剰に重み付けされたディスクを再度再重み付けする必要があります。

これにより、クラッシュマップに別の変更が加えられ、Ceph が安定した状態からさらに遠ざかることになります。容量拡張がタイムリーに行われなければ、状況はさらに悪化するでしょう。

さらに、以前のクラッシュマップの中間状態により、一部の PG が途中で移行されることもあります。これらの「不完全な」PG はすぐには削除されないため、すでに不足しているディスク領域にさらに負担がかかります。

ディスクがいっぱいになると Ceph が使用できなくなる理由について疑問に思う学生もいるかもしれません。 Ceph は実際にはこのように設計されています。新しいオブジェクトがいっぱいのディスクではなく空のディスクに置かれるかどうかを Ceph が保証できないため、ディスクがいっぱいのときに Ceph はサービスを拒否することを選択します。

同僚や業界の同業者に相談したところ、基本的にすべての Ceph クラスターは、使用率が 50% に達したら拡張の準備を始める必要があることがわかりました。

多数のマシンのストレージ リソースをアイドル状態のままにしておく必要があるため、これは実際には費用対効果が高くありません。そして、将来的にクラスターの規模が大きくなるほど、空室の影響が大きくなり、無駄なお金や電気が増えることになります。

多くの従来の集中型分散ストレージ システムでは、マスター ノードは書き込み時に比較的アイドル状態のマシンを書き込み用に選択できるため、一部のディスクがいっぱいになってクラスター全体が書き込みできなくなるという問題は発生しません。

このため、全体で 95% の書き込みを達成しながらも可用性を維持できます。

この効果のコストを実際に計算したわけではありませんが、少し不完全に見えます。

たとえば、50PB のストレージには 300 台の物理マシンが必要であると見積もった場合、すぐには使用できず、プラグインする必要のある物理マシンをさらに 200 ～ 300 台事前に購入する必要がありました。

したがって、Ceph は必ずしも安価ではなく、分散型ストレージはそれほど優れているわけではありません。

しかし、集中化の危険性は議論の余地のない問題であるように思われます (単一ポイントの問題、中央ノードのスケーラビリティの問題など)。そのため、分散化には特効薬はなく、トレードオフしかありません。

もう 1 つの方法は、プール全体に応じて Ceph クラスターを拡張することです。プールがいっぱいの場合は、プールを拡張せずに新しいプールを作成します。新しいオブジェクトは新しいプールにのみ書き込むことができ、古いプール内のオブジェクトは削除および読み取りが可能です。

一見すると、これは素晴らしいソリューションのように思えますが、よく考えてみると、フロントエンドで大きなハッシュを作成するために HDFS フェデレーションや MySQL がデータベースとテーブルをシャーディングするのと何ら変わらないように思えます。

これは「無限拡張」ではないため、フロント ルーティング レイヤーを記述する必要があります。

安定性、制御性、操作のしやすさ

この安定した良好な運用と保守は、基本的にチームのハードパワーに依存します。オープンソース ソフトウェアに関する知識と経験は、本当に大きな違いを生みます。

同時に、オープンソース コミュニティのドキュメントの品質も影響を受けます。 Ceph のオープンソース コミュニティは非常に優れています。 Red Hat が Ceph を買収して管理した後、Red Hat バージョンの Ceph ドキュメントが再編成され、より論理的に読めるようになったと思います。

社内に独自の運用・保守文書を蓄積しておくことも重要です。初心者のドライバーは、事故につながるようなミスを多く犯す可能性があります。しかし、企業としては、一度同じ落とし穴に陥った場合、二度と同じ過ちを繰り返さないように努めるべきです。

これにより、同社の技術蓄積管理、技術文書管理、中核人材の流出管理にいくつかの課題が生じています。

かつて、Ceph の運用と保守で難しい問題に遭遇したことがあります。つまり、Ceph クラスターが 80% に達すると、ディスクがいっぱいになることが多く、その場合は管理者が介入して、高すぎるディスクの再重み付けを下げる必要があります。

このディスクの使用量が減少する前に、さらに多くのディスクがいっぱいになり、管理者が介入して Reweight を再度調整する必要があります。それ以来、Ceph は安定した状態になったことがなく、管理者は常にクラスターを監視する必要があります。

これにより、膨大な O&M 投資が発生するため、O&M 担当者の士気に大きな損害を与えるため、このようなことは避けなければなりません。

では、調達プロセスを開始するために、早い段階で容量警告を与えるべきでしょうか?

しかし、そうすると、資源の浪費という問題に戻ってしまいます。さらに、Ceph オブジェクトには last_access_time などのメタデータがないため、Ceph オブジェクトのコールド/ホット分類には二次開発と追加作業が必要になります。

クラスターが大きくなると、ジャンクデータをどのようにクリーンアップするか、コールドデータをどのようにアーカイブするかについても、かなりの課題が生じます。

まとめ

Ceph には無限に拡張する機能がありますが、適切な初期計画が必要であり、拡張プロセスは完璧ではありません。

集中化とは、容量拡張の上限が単一のマスターノードの物理的な限界であり、無制限の容量拡張の理論的根拠が生まれることを意味します。しかし、実際に容量を拡大すると、サービス品質は大幅に制限されます。

Ceph はハードウェアを多少浪費するため、コスト計算にはさらに考慮する必要があります。

Ceph の分散型設計では、lastacesstime などの多くのメタデータが犠牲になるため、将来のデータ ガバナンスにプレッシャーがかかり、運用と保守、および二次開発のためにより強力なチームが必要になります。

運用・保守の経験を​​積み、運用・保守チームを構築することが、オープンソース分散ストレージを習得するための鍵となります。時間の経過とともに敵が強くなるにつれて、生産関係が生産性の要件に一致するように、対応する運用および保守チームもさらに改善する必要があります。

テクノロジー自体は良いものでも悪いものでもありません。さまざまな問題を解決するために、さまざまなテクノロジーが使用されます。しかし、さまざまなシナリオでは、テクノロジーは良いことにも悪いことにもなり得ます。

なぜなら、シナリオでは、解決すべき問題の位置付けと優先順位があり、優先順位に応じて最適なテクノロジーを確実に選択できるからです。