オープンソースのバックアップツールの維持: 洞察など-Golang-php.cn

バックアップ戦略は解決された問題のように見えるかもしれませんが、システム管理者は、データを適切にバックアップする方法、データを保存する場所、さまざまなソフトウェア環境間でバックアッププロセスを標準化する方法についての疑問に頭を悩ませることがよくあります。 2011 年に、当社はクライアントの Web プロジェクトのバックアップを効率的に処理するカスタムバックアップスクリプトを開発しました。これらのスクリプトは長年にわたって役に立ち、必要に応じてストレージと外部リポジトリの両方にバックアップを保存しました。しかし、当社のソフトウェアエコシステムが成長し、多様化するにつれて、当社のスクリプトでは Redis や MySQL/PostgreSQL などの新しいテクノロジのサポートが不足し、不十分になってきました。スクリプトも煩雑になり、電子メールによるアラート以外の監視システムがなくなりました。

かつてはコンパクトだったスクリプトは、複雑で管理不可能なシステムに進化しました。さまざまな顧客向けにこれらのスクリプトを更新することは、特にカスタマイズされたバージョンを使用している場合に困難になりました。昨年の初めまでに、私たちはより最新のソリューションが必要であることに気づきました。

この記事では、nxs-backup の開発中に直面したすべての困難について説明し、経験と課題を共有します。あなたのプロジェクトでツールをテストし、その経験を共有することもできます。ぜひご意見をお待ちしております。さあ、始めましょう!

新しいシステムの要件をリストしました:

最も一般的に使用されるソフトウェアのバックアップデータ: (ファイル: 個別および増分、MySQL、PostgreSQL、MongoDB、Redis);
一般的なリポジトリにバックアップを保存: (FTP; SSH; SMB; NFS; WebDAV; S3);
バックアッププロセス中に問題が発生した場合にアラートを受信します。
バックアップを一元管理するための統合された構成ファイルを用意します。
外部モジュールを接続して新しいソフトウェアのサポートを追加します。
ダンプを収集するための追加オプションを指定します;
標準ツールを使用してバックアップを復元できる;
初期設定が簡単。これらの要件はすべて、約 5 年前の当社のニーズに基づいてリスト化されました。残念ながら、それらすべてが解放されたわけではありません。

私たちは、nxs-backup の最初のバージョンを作成する前からすでに存在していたオープンソースソリューションを検討しました。しかし、それらにはすべて欠点がありました。たとえば、Bacula は私たちにとって不要な機能で過負荷になっており、初期設定は - 多くの手動作業 (データベースバックアップのスクリプトの作成や検索など) のためかなり面倒な作業であり、コピーを回復するには特別なユーティリティを使用する必要があります。、など

私たちがツールを書き直すというアイデアを持っていたときに、同じ問題に直面したとしても不思議ではありません。 4 年間で何かが変わり、新しいツールがオンラインに登場する可能性はそれほど高くありませんでしたが、それでもまだです。

私たちは、これまで考慮されていなかったいくつかの新しいツールを研究しました。しかし、前述したように、これらも私たちには合わなかったのです。なぜなら、それらは私たちの要件を完全には満たしていなかったからです。

私たちは最終的に 2 つの重要な結論に達しました:

既存のソリューションはどれも私たちに完全には適していませんでした。
初めてソリューションを作成するのに十分な経験と熱意があったようです。そして、基本的にはそれをもう一度行うことができます。それが私たちがやったことです。

新しいバージョンを検討する前に、以前のバージョンと、なぜそれが私たちにとって十分ではなかったのかを見てみましょう。

古いバージョンは、MySQL、PostgreSQL、Redis、MongoDB などの DB、ファイルの個別および増分コピー、複数のリモートストレージ (S3、SMB、NFS、FTP、SSH、WebDAV) をサポートし、バックアップローテーション、ロギングなどの機能を備えていました。、電子メール通知、および外部モジュール。

ここで、私たちが懸念していた点について詳しく説明します。

Linux 上でソースファイルを再起動せずにバイナリファイルを実行します

時間の経過とともに、私たちが扱うシステムのリストは大幅に増加しました。現在、Arch、Suse、Alt などの標準の deb および rpm 互換ディストリビューション以外を使用するプロジェクトを提供しています。

最近のシステムでは、deb および rpm パッケージのみを収集し、サポートされているシステムバージョンのリストが限られていたため、nxs-backup を実行するのが困難でした。どこかでパッケージ全体を再抽出し、どこかでバイナリだけを取り出し、どこかでソースコードを実行するだけでした。

ソースを操作する必要があるため、古いバージョンでの作業はエンジニアにとって非常に不便でした。言うまでもなく、このようなモードでのインストールとアップデートにはさらに時間がかかります。 1 時間あたり 10 台のサーバーをセットアップする代わりに、1 台のサーバーに 1 時間を費やすだけで済みました。

私たちは、システム依存性のないバイナリを使用すると、どのディストリビューションでも実行でき、ライブラリのバージョンの違いやシステムのアーキテクチャの違いによる問題が発生しない方がはるかに優れていることを長い間知っていました。私たちはこのツールも同じであることを望みました。

nxs-backup で Docker イメージを最小化し、構成ファイルで ENV をサポートします

最近、非常に多くのプロジェクトがコンテナ化された環境で動作しています。これらのプロジェクトにはバックアップも必要なので、コンテナ内で nxs-backup を実行します。コンテナ化された環境では、イメージサイズを最小限に抑え、環境変数を操作できることが非常に重要です。

古いバージョンでは、環境変数を操作する機会が提供されませんでした。主な問題は、パスワードを構成に直接保存する必要があることでした。このため、パスワードのみを含む変数セットの代わりに、設定全体を変数に入れる必要があります。大規模な環境変数を編集するには、エンジニアの集中力がさらに必要となり、トラブルシューティングが少し難しくなります。

また、古いバージョンを使用する場合は、すでに大規模な Debian イメージを使用する必要があり、適切なバックアップのためにいくつかのライブラリとアプリケーションを追加する必要がありました。

イメージのスリムバージョンを使用した場合でも、最小サイズは約 250Mb でしたが、これは 1 つの小さなユーティリティとしてはかなりの量です。場合によっては、イメージがノードにプルされるまでの時間が原因で、コレクションの開始プロセスに影響を与えることがありました。 50 MB 以下の画像を取得したいと考えていました。

ヒューズなしでリモートストレージを操作する

コンテナ環境のもう 1 つの問題は、ヒューズを使用してリモートストレージをマウントすることです。

ホスト上でバックアップを実行している間も、これは許容されます。適切なパッケージをインストールし、カーネルでヒューズを有効にすると、機能するようになりました。

コンテナ内でヒューズが必要になると、事態は面白くなります。ホストシステムのコアに直接アクセスできる権限をアップグレードしない限り、問題は解決されず、セキュリティレベルが大幅に低下します。

すべての顧客がセキュリティポリシーを弱めることに同意するわけではないため、これは調整する必要があります。だからこそ、思い出したくないほどの膨大な回避策を講じなければならなかったのです。さらに、層を追加すると障害の可能性が高まり、マウントされたリソースの状態をさらに監視する必要があります。 API を直接使用してリモートストレージを操作する方が安全で安定しています。

メールだけでなくステータスの監視と通知の送信

今日、チームは日常業務で電子メールを使用することがますます少なくなってきています。グループチャットやグループ通話で問題について話し合う方がはるかに早いため、これは当然のことです。 Telegram、Slack、Mattermost、MS Teams、およびその他の同様の製品は、それによって広く配布されています。

さまざまなアラートを送信して通知してくれるボットもあります。そしてもちろん、私たちは、電子メールではなく、数百もの電子メールの中で、テレグラムのようなワークスペースでバックアップがクラッシュしたというレポートを確認したいと考えています。ちなみに、顧客の中には、Slack やその他のメッセンジャーで障害に関する情報を見たいと考えている人もいます。

さらに、ステータスを追跡し、リアルタイムで作業の詳細を確認できるようにしたいと長年望んでいます。これを行うには、アプリケーションの形式を変更して悪魔に変える必要があります。

パフォーマンスが不十分です

もう 1 つの急性の痛みは、特定のシナリオでのパフォーマンス不足でした。

クライアントの 1 つには、ほぼ 1 テラバイトの巨大なファイルダンプがあり、そのすべてはテキストや写真などの小さなファイルです。私たちはこのものの増分コピーを収集していますが、次の問題があります。コピーには 1 年に 1 回の時間がかかります。 3日です。そうですね、古いバージョンではそのボリュームを 1 日以内に消化することはできません。

状況を考慮すると、実際には特定の日付のデータを復元することができません。これはまったく好ましくありません。

当初、そのシンプルさと柔軟性を理由に、バックアップソリューションを Python で実装しました。しかし、需要が高まるにつれて、Python ベースのソリューションでは不十分になってきました。徹底的な議論の結果、いくつかの理由からシステムを Go で書き直すことにしました。

コンパイルと依存関係: Go の AOT コンパイラーは、依存関係のない汎用のバイナリを生成し、異なるシステム間でのデプロイメントを簡素化します。
パフォーマンス: Go 固有のマルチスレッド機能により、より優れたパフォーマンスが約束されました。
チームの専門知識: Python よりも Go の経験豊富な開発者が多かったです。

解決策を見つける

上記の問題はすべて、多かれ少なかれ、IT 部門に明らかな苦痛を与え、確かに重要な事柄に貴重な時間を費やすことになりましたが、これらのコストは回避できたはずです。さらに、特定の状況では、特定のリスクが事業主に生じました。これは、特定の日データが存在しない可能性が非常に低いですが、ゼロではありません。私たちは現状を受け入れることを拒否しました。

Nxs バックアップ 3.0

私たちの作業の結果、nxs-backup v 3.0 の新しいバージョンが作成され、最近 v3.8.0 にアップデートされました
新しいバージョンの主な機能:

すべてのストレージ設備とあらゆる種類のバックアップに対応するインターフェースを実装します。ジョブとストレージは、作業の実行中ではなく、開始時に初期化されます。
API 経由でリモートストレージを操作します。このために、さまざまなライブラリを使用します。
プロジェクトで使用している go-nxs-appctx ミニアプリケーションフレームワークのおかげで、構成で環境変数を使用します。
フック経由でログイベントを送信します。さまざまなレベルを構成し、必要なレベルのエラーまたはイベントのみを受信できます。
バックアップの期間だけでなく、特定のバックアップ数も指定します。
バックアップは、2.6 カーネル以降の Linux 上で簡単に実行できるようになりました。これにより、非標準システムでの作業がはるかに簡単になり、Docker イメージの構築がより速くなりました。イメージ自体は 23 MB に削減されました (追加の MySQL および SQL クライアントが含まれる);
Prometheus 互換形式でさまざまなメトリクスを収集、エクスポート、保存する機能。
ローカルディスク速度とリモートストレージのリソース消費を制限します。

構成とアプリケーションロジックの大部分を維持しようとしましたが、いくつかの変更が存在します。それらはすべて、前のバージョンの最適化と欠陥の修正に関連しています。

たとえば、リモートリポジトリへの接続パラメータを基本構成に組み込むことで、毎回異なる種類のバックアップに接続パラメータを規定する必要がなくなります。

以下はバックアップの基本構成の例です。これには、通知チャネル、リモートストレージ、ログ、ジョブリストなどの一般的な設定が含まれています。これはメール通知を使用した基本的なメイン設定です。デフォルトの方法としてメール通知を使用することを強くお勧めします。さらに多くの機能が必要な場合は、ドキュメントのリファレンスを参照してください。

server_name: wp-server
project_name: My Best Project

loglevel: info

notifications:
  mail:
    enabled: true
    smtp_server: smtp.gmail.com
    smtp_port: 465
    smtp_user: j.doe@gmail.com
    smtp_password: some5Tr0n9P@s5worD
    recipients:
      - j.doe@gmail.com
      - a.smith@mail.io
  webhooks: []
storage_connects: []
jobs: []
include_jobs_configs: [ "conf.d/*.conf" ]

ログイン後にコピー

落とし穴について一言

私たちは特定の課題に直面することを予想していました。そうでないと考えるのは愚かです。しかし、2 つの問題が最大の打撃を引き起こしました。

Image description

メモリリークまたは最適でないアルゴリズム

nxs-backup の以前のバージョンでも、ファイルアーカイブの独自の実装を使用していました。このソリューションのロジックは、バックアップの作成に外部ツールの使用を避けることであり、ファイルを操作することが可能な限り簡単なステップでした。

テストからわかるように、実際には、このソリューションは実行可能であることが証明されましたが、多数のファイルに対して特に効果的ではありませんでした。当時、私たちは Python の詳細については無視し、Go に切り替えたときに大きな違いが見られることを期待していました。

最終的に新しいバージョンの負荷テストに到達したとき、残念な結果が得られました。パフォーマンスの向上はなく、メモリ消費量は以前よりもさらに増加しました。私たちは解決策を探していました。このトピックについて多くの記事を読んだり調査したりしましたが、それらはすべて、«filepath.Walk» と «filepath.WalkDir» の使用が最良の選択肢であると述べています。これらのメソッドのパフォーマンスは、言語の新しいバージョンがリリースされると向上するだけです。

メモリ消費を最適化しようとして、増分コピーを作成するというミスさえ犯してしまいました。ちなみに、壊れたオプションの方が実際には効果的でした。明白な理由により、私たちはそれらを使用しませんでした。

最終的には、処理するファイルの数にすべて行き着きました。 1000万人をテストしました。ガベージコレクターは、この量の生成された変数をクリアできないようです。

最終的に、ここで時間を費やしすぎる可能性があることに気づき、実績のある真に効果的なソリューションである GNU tar を優先して実装を放棄することにしました。

後で、数千万のファイルを処理するためのより効率的なソリューションを思いついたときに、自己実装のアイデアに戻る可能性があります。

まったく異なる ftp

ftp を使用するときに別の問題が発生しました。同じリクエストに対してサーバーが異なると動作が異なることが判明しました。

そして、同じリクエストに対して通常の応答が返されるか、リクエストとは関係がないと思われるエラーが返されるか、あるいは期待したときにバグが発生しない場合は、非常に深刻な問題です。 .

そのため、ライブラリ「prasad83/goftp」の使用を諦め、より単純な「jlaffaye/ftp」を使用する必要がありました。前者は Selectel サーバーで正しく動作しなかったためです。エラーは、接続時に最初の接続で作業ディレクトリ内のファイルのリストを取得しようとして、上位ディレクトリへのアクセス権のエラーが発生したことです。「jlaffaye/ftp」では、よりシンプルでサーバーにリクエストを送信しないため、このような問題は存在しません。

次の問題は、リクエストがない場合に切断されることでした。すべてのサーバーがこのように動作するわけではありませんが、一部のサーバーはこのように動作します。そのため、リクエストの前に、コネクタが外れて再接続されていないかどうかを確認する必要がありました。

一番の要点は、サーバーからファイルを取得する際の問題、あるいは明確に言うと、存在しないファイルを取得しようとする試みでした。このようなファイルにアクセスしようとするとエラーが発生するサーバーもあれば、読み取り可能な有効な io.Reader インターフェイスオブジェクトを返すサーバーもありますが、バイトの空の部分が得られるだけです。

これらの状況はすべて経験的に発見されており、独自の側で処理する必要があります。

結論

最も重要なことは、古いバージョンの問題、つまりエンジニアの作業に影響を及ぼし、ビジネスに特定のリスクをもたらした問題を修正したことです。

次のような、前のバージョンからの未実現の「要望」がまだ残っています。