これが方法です!Timewebバックアップの進化:rsyncからZFSへ

Timewebチームが10年間にわたって移動したパス、つまりrsync、LVM、DRBDからZFSまでを簡単に説明しようとしました。この記事は、サーバーのスケーラブルなインフラストラクチャに携わっていて、バックアップを作成する予定であり、システムのスムーズな運用に関心がある人に役立ちます。



画像



話しましょう:



  • rsync(リモート同期)
  • DRBD(分散複製ブロックデバイス)
  • DRBD LVM
  • DRBD + ThinLVM
  • ZFS (Zettabyte File System)


rsync . .



rsync(リモート同期)は、厳密に言えば、バックアップに関するものではありません。これは、トラフィックを最小限に抑えながら、2つの場所でファイルとディレクトリを同期できるようにするプログラムです。同期は、ローカルフォルダーとリモートサーバーの両方に対して実行できます。



Rsyncはバックアップによく使用されます。このユーティリティは、サイトが単純で、クライアントが大幅に少ないときに使用しました。



Rsyncはかなり良い仕事をしましたが、ここでの最大の問題は速度です。プログラムは非常に遅く、システムに多くの負荷をかけます。そして、データの増加に伴い、それはさらに長く機能し始めます。



Rsyncはバックアップテクノロジとして使用できますが、データ量はごくわずかです。



LVM(論理ボリュームマネージャー)-論理ボリュームマネージャー



もちろん、より少ない負荷でより高速にバックアップを作成したかったので、LVMを試すことにしました。LVMでは、内線4を使用してもスナップショットを作成できます。このようにして、LVMスナップショットを使用してバックアップを作成できます。



私たちはこの技術を長い間使用していませんでした。バックアップはrsyncよりも高速でしたが、常にいっぱいでした。変更をコピーしたかっただけなので、DRBDに切り替えました。



DRBD



DRBDを使用すると、あるサーバーから別のサーバーにデータを同期できます。さらに、すべてのデータではなく、変更のみが同期されます。これにより、プロセスが大幅にスピードアップします。



そして、ストアの側では、LVMを使用してスナップショットを撮ることができます。このようなシステムは非常に長い間存在しており、現在、新しいシステムに移行する時間がまだない一部のサーバーに存在しています。



画像



ただし、この方法でも欠点があります。DRBDは、同期中にディスクサブシステム大きな負荷をかけます..。これは、サーバーの実行速度が低下することを意味します。その結果、バックアップは主要なサービス、つまりユーザーサイトの作業を妨害しました。私たちは夜にバックアップを作成しようとさえしましたが、時には彼らは単に一晩で完了する時間がなかったのです。私は別のバックアップを操作しなければなりませんでした。たとえば、今日、サーバーの一部が実行されてから、別の部分が実行されています。チェッカーボードパターンでバックアップを配布しました。



さらに、DRBDはネットワーク速度に大きく依存し、バックアップの実行元と実行元のサーバーのパフォーマンスに影響を与えます。新しい解決策を模索する必要があります!



薄いLVM



この時点で、ビジネスは30日間のバックアップを作成するタスクを設定し、thinLVMに切り替えることにしました。これは主な問題を解決しませんでした!シンスナップショットをサポートするために、このような高性能のファイルシステムが必要になるとは思っていませんでした。この経験は完全に失敗し、通常のシックLVMスナップショットを採用することを諦めました。



ThinLVMは、実際には私たちの目的のために設計されたものではありません。もともとは小型のラップトップとカメラを対象としていますが、ホスティングは対象としていません。



検索を続けます...



ZFSを試すことにしました。



ZFS



ZFSは、多くの機能が組み込まれたまともなファイルシステムです。 LVMにインストールし、DRBDデバイスを接続し、ZFSを使用することで、ext 4で実現されることは、デフォルトです。ファイルシステム自体は非常に信頼性があります。コピーオンライト機能についても言及する必要があります。このテクノロジーを使用すると、データを非常に慎重に処理できます。



ZFSを使用すると、ストアにコピーできるスナップショットを作成したり、バックアップを自動化したりできます。何も発明する必要はありません!



ZFSへの移行は非常に慎重でした。まず、数か月間テストするだけのスタンドを作成しました。特に、機器、電源、ネットワーク、ディスクの満杯の問題を再現しようとしました。徹底的なテストを通じて、ボトルネックを見つけることができました。



ZFSの問題は、ディスクがいっぱいであることです。空きスペースを確保することで、この問題を解決することができました。ディスクがいっぱいになると、サーバーをアンロードしてスペースをクリーンアップするための対策が講じられます。



テスト後、徐々に新しいサーバーを導入し、古いサーバーをZFSに転送し始めました。バックアップに関する問題はもうありません!1時間ごとにバックアップする場合でも、30日または60日のバックアップを作成できます。いずれの場合も、サーバーに過度の負荷がかかることはありません。



以下の表のすべてのデータを収集して、さまざまなテクノロジーを使用したバックアップを比較しました。



画像



画像



画像



画像



次に何が起こったのですか?



ZFSをOpenZFS2.0.0のバージョン2にアップグレードする計画があります 2021年に。12月上旬のリリースで発表されたすべてのチップを使用して移行を準備しています。



これが方法です!



これが私たちが自分たちのために選んだ道です!同様の問題を解決していますか?コメントであなたの経験を共有していただければ幸いです!この記事がお役に立てば幸いです。突然、Linuxの組み込みユーティリティを使用してバックアップを作成するタスクに直面した場合、私たちのストーリーが適切な解決策を見つけるのに役立ちます。



All Articles