分散ストレージの運用と保守の方法についてお話ししましょう

序文

最近、分散ストレージに多くの時間を費やしてきましたが、これ以上時間を費やしたくないので、この記事で最終的なまとめをしたいと思います。

分散ストレージに向き合う場合、顧客側と運用・保守側の2つの視点があります。お客様は神様なので、神様の運用を語るのではなく、運用保守側のシステム構築に注力しています。

実際、すべてのシステム構築は 2 つの次元に分割する必要があります。 1 つは顧客ディメンションであり、顧客エクスペリエンスに重点を置き、さまざまなカスタマイズされた出力を提供します。もう 1 つは、基盤となる運用と保守に重点を置いた運用と保守の側面です。日々のさまざまな監視データや操作は、コマンドライン操作ではなく、すべて白い画面を使用して実行する必要があります。プラットフォームレベルを使用すると誤操作を防ぐことができます。システムがほとんどの責任を引き受け、運用および保守担当者が毎日それらのくだらないコマンドとパラメータを覚える必要がなくなるため、低レベルの操作が削減され、脳に他の事柄について考える余裕が生まれます。 。 。たとえば、夕暮れ時の青い空と白い昼間を見てください。 。 。 。

[[227132]]

分散ストレージ運用保守システムの構築

分散アーキテクチャは一般的に次のようになります。

分散システムには、主に複数のオブジェクトが存在します。

運用保守オブジェクト: 1 つはマスター、つまり制御ノード オブジェクトであり、主にメタデータの保存、統計関連情報の提供、および外部への統一された API の提供に使用されます。もう 1 つは、主にデータを保存するために使用される作業ノード オブジェクトである chunkserver です。

マスターに関連するアクションは、マスター ノードのクエリ、マスター ノードの切り替え、メタデータのバックアップ、回復用のチェックポイント ファイルの生成、同期用の操作ログの生成、マスター起動パラメータの変更、マスター プロセスの再起動です。

chunkserver に関連するアクションは、chunkserver リストのクエリ、合計スペース サイズ、残りのスペース サイズ、ディスク ステータス、プロセス ステータスの表示、chunkserver プロセス パラメータの変更、chunkserver プロセスの再起動、容量の拡張と縮小です。

クライアント側オブジェクト: 1 つはディレクトリで、もう 1 つはファイルです。ここで行われる主なアクションは、ディレクトリの表示、ファイルの表示、シャード数の表示、シャード数の設定、シャード数の確認、シャード例外の処理、ユーザーの論理スペース使用量の設定、物理スペース使用量、ディレクトリ ファイルの移行、リサイクル ポリシーの設定、およびファイルのレプリカ数の設定です。

アクションの説明と、それが必要な理由は次のとおりです。

1. マスターノードは 3 つあります。これは主に、マスターの選択に Paxos アルゴリズムが使用されるためです。なぜマスターが必要なのでしょうか?サービスの高可用性を提供し、パーティションを防ぐために 3 つのノードを使用します。

2. チェックポイント ファイルを生成する必要があるのはなぜですか?マスターが大量のメタデータを保存する場合、このデータはすべてディスクに配置されます。サーバーがクラッシュした場合、プロセスの開始時にすべてのデータがメモリにロードされます。これは時間的に受け入れられません。したがって、クラッシュ回復やプロセス回復を容易にするために、チェックポイント ファイルが定期的に生成されます。

3. 操作ログはなぜ必要なのでしょうか?操作ログは主に 3 つのマスター ノード上に存在し、すべて同じデータを使用します。マスターが他のスレーブと同期する場合、操作ログが同期に使用されます。

4. チェックポイント ファイルと操作ログをすぐに生成する必要があるのはなぜですか?通常、チェックポイントは定期的に生成されます。パラメータをアップグレードまたは変更する場合は、データの一貫性を確保して、起動時にすぐに生成し、起動時間を短縮できるようにする必要があります。

5. chunkserver のディスク容量を表示する必要があるのはなぜですか? Chunkserver は主にストレージとして使用されるので、ディスクの残り容量と合計容量を表示する必要があります。これも分散ストレージの主な機能です。

6. chunkserver プロセスのパラメータを変更して、chunkserver プロセスを再起動するときにサーバー上の関連パラメータを手動で変更する必要がないようにする。

7. 容量の拡張と縮小をワンクリックで操作できるため、操作とメンテナンスの複雑さが大幅に軽減されます。

8. シャーディングの異常を処理する必要があるのはなぜですか?異常な状況では、シャードの数が少なくなったり、シャードがまったくなかったり、期待値に達しなかったりすることがあります。したがって、シャーディングの異常を処理する必要があります。これは主にデータのセキュリティを確保するためです。 。 。この操作を実行するときは、レプリカの自動削除および追加メカニズムを使用できます。つまり、ファイルのシャードの数を変更し、古いバージョンのシャードを削除して、シャードの数を目的の状態に増やすことができます。

9. 分散ファイルシステムでは、データの削除は戦略的です。一般的にはごみ箱が設定されます。データが削除されると、ごみ箱に追加され、1 ～ 2 日間保持されます。復元されていない場合は、データが削除される可能性があることを意味します。定期的にデータをクリーンアップするタスクがスケジュールされるため、回復および削除戦略が必要になります。

10. ファイルのレプリカの数を設定します。これは最も基本的な機能です。分散ストレージの信頼性と可用性を保証する唯一のものはシャードの数であり、通常は 3 です。

上記の内容を全て読んでも、分散運用保守システムを構築できない場合は、私に言うことはありません。オブジェクトとアクションは存在し、残りはコードです。 。 。

風が来るのを待ちます。 。 。 。

チャット中。 。 。

分散ストレージは風のようなものです。風がどこに落ちるかはわかりませんし、どのノードのどのチャンクに保存されているかがわからない場合もあります。 。 。実際、見つけることができますよ、ハハ。

データの信頼性を確保するために分散システムが使用され、シャーディングが唯一の手段です。どのように保存しても、実際にはディスク上に保存されます。どのように実行するかに関係なく、SSD ディスクまたは SATA ディスクに保存します。

分散ストレージの可用性は、それがどれだけ利用可能であるかに関係なく、最終的には Linux システムで使用されます。どのように保存されるかに関係なく、オペレーティング システムによって提供されるファイル システムが使用されます。つまり、分散ストレージ、分散ファイル、分散テーブル、分散キー値のいずれであっても、それらはすべて ext3 に存在するということですか? ext4 ファイルシステム内。 。 。 。そこで疑問になるのが、保存するときにまずメモリに書き込まれ、その後書き込み成功がクライアントに返されるということです。 。 。この時点でサーバーがクラッシュした場合、データは失われますか? ? ?

データが失われても問題ありませんが、失われないようにすることはできますか?もちろんできますよ。 。 。オペレーティング システム レベルでスワップとキャッシュを無効にするだけで、信頼性を高める代わりにパフォーマンスが多少犠牲になります。

分散ストレージを使用する場合、SSD または SATA を使用して最適化できますか?それは確かに可能です。オペレーティング システム レベルでは、atime や diratime などのさまざまなメタデータが常に保存されます。ただし、分散システムでは、パフォーマンスを向上させるためにそれらを保存する必要はありません。マウント時にこれらのパラメータを追加するだけです。 。

これを最適化と呼ぶのでしょうか? ? ?はい、いくつかのパラメータを設定するだけで、最適化と見なすことができます。 。 。したがって、ソースコードを変更して適応させることはできません。 。 。いくつかのパラメータを追加することは最適化と考えることができます。 。 。それはちょっと面白い行動ですけどね。 。多くの人がこの最適化は素晴らしいと考えています。 。 。 。穏やかに微笑んでください。 。 。言葉がない。 。 。

時々、いくつかの操作が非常にクールだと感じます。なぜなら、運用および保守プラットフォームを構築するときには、さまざまなテスト データ、さまざまな TPS、さまざまな QPS、さまざまな http レイテンシだけでなく、 。 。これを実行するにはいくつかの手順が必要です。 。 。たとえば、容量を拡張したい場合は、3 回クリックして 3 回入力すると拡張が完了します。 。 。制御可能なリスク、制御可能なアップグレード。 。 。 。これはまだ素晴らしいです。 。 。

冪等性なしで一意性を実現するにはどうすればよいでしょうか? ? ?分散システムを使用すると、タイムアウトが発生することがよくあります。このようなタイムアウトに対しては、どうすればよいでしょうか? ? ?ビジネスの世界では、保管システムは信頼性が高く、返却が成功すれば成功、返却が失敗すれば失敗であると一般的に考えられています。ただし、サーバーがデータを正常に処理したが、クライアントがタイムアウトして応答を受信しなかった場合の対処法については考慮されていません。 。 。 。ビジネスシリアル番号の一意性。このビジネスのシリアル番号を照会し、レコードを照会して成功または失敗を取得します。履歴条件に基づいてのみ照会できます。 。 。

ふと、分散ストレージには、データを分割する動作、つまりリバランスがあることを思い出しました。たとえば、この操作は非常にハイエンドな感じがします。 。 。容量を拡張する場合、新しく起動したマシンはデータを移行する必要があります。たとえば、DHT アルゴリズムを使用する場合、隣接するデータを新しい上限マシンに移行してから、再バランスを実行する必要があります。このときデータ量が多すぎると、分散ストレージ全体の IO 容量に影響する可能性があります。したがって、再バランス調整を行うときは、フローを制限する、つまり移行速度（20M/S または 100M.S など）を制限するための手動操作が必要です。評価は主に帯域幅に依存します。 。 。お尻が頭を左右させないでください。 。 。

突然前回の失敗を思い出しました。クライアントはストレージへの書き込みを試みましたが、失敗しました。ビジネスからエラーが報告されました。確認したところ、クライアント応答コードは 5XXX で、内部エラーであることがわかりました。ログを確認したところ、パーティションが見つからないことがわかりました。 。 。最初はサーバーがダウンしている可能性があると判断されましたが、それはあり得ません。 。 。プロセスが再開されます。 。 。あり得ない、警察は来なかった。 。 。その後、サーバー内で再バランス操作が実行されたと考えられます。 。 。しかし最終的に、すべてのリバランスは手動で行う必要があり、自動リバランス操作はオフになっていることがわかりました。その後、対応する時点をチェックして見つけました。 。 。対応するチャンクサーバー上のプロセスが再起動されました。 。 。 。次に、なぜ再起動したのか確認したところ、プロセスがメモリを使いすぎており、cgroup がプロセスが使用するメモリを制限したため、プロセスが強制終了したことがわかりました。その後、私はプロセスを監視して、この馬鹿が死んだことを確認したので、もう一度開始しました。 。 。何も起こらなかったふりをします。 。 。そして 1 分以内に、パチッ、パチッというエラー メッセージが表示されます。 。 。 。質問は、chunkserver プロセスを開始するのに 1 分かかるかどうかです。 。 。すると、再び疑問が生じます。フロントエンドの nginx または lvs は、プロセスが 15 秒間ハングしていることを検出します。プロセスを引き上げます。 15 秒と仮定すると、チェック間隔は 15 秒となり、45 秒より長くなります。さまざまな遅延を追加し、サーバーの負荷を考慮すると、ほぼ 1 分になります。 。 。 。つまり、このような問題です。 。 。上司の判断？ログチェック?これは楽しいトラブルシューティングです。 。 。 。

ただクソだ.............さて、この投稿はたった1時間で終わるから、時間を無駄にしすぎるのはよくない