導入

少し前に、私はフェールオーバー クラスターを開発するタスクを与えられました。 PostgreSQLは、XNUMX つの都市内で光ファイバーで接続された複数のデータセンターで運用されており、XNUMX つのデータセンターの障害 (停電など) に耐えることができます。 フォールトトレランスを担うソフトウェアとして私が選んだのは、 ペースメーカーこれは、フェールオーバー クラスターを作成するための RedHat の公式ソリューションだからです。 RedHat がサポートを提供しており、このソリューションがユニバーサル (モジュール式) であるため、これは優れています。 その助けを借りて、標準モジュールを使用するか、特定のニーズに合わせてモジュールを作成することで、PostgreSQL だけでなく他のサービスのフォールト トレランスを確保することも可能になります。

この決定により、フェイルオーバー クラスターのフォールト トレラント性はどの程度になるのかという当然の疑問が生じました。 これを調査するために、クラスター ノード上のさまざまな障害をシミュレートし、サービスが復元されるのを待機し、障害が発生したノードを回復して、ループでテストを続行するテスト ベンチを開発しました。 このプロジェクトはもともと hapgsql という名前でしたが、時間が経つにつれて、母音が XNUMX つしかない名前に飽きてしまいました。 そこで、フォールト トレラント データベース (およびそれらを指すフロート IP) を呼び出すようにしました。 クロガン (すべての重要な器官が複製されているコンピューター ゲームのキャラクター)、ノード、クラスター、およびプロジェクト自体は トゥチャンカ （クローガンが住む惑星）。

今では経営陣が許可しました MITライセンスに基づいてプロジェクトをオープンソースコミュニティに公開する。 README は間もなく英語に翻訳される予定です (主な利用者は Pacemaker および PostgreSQL 開発者であることが予想されるため)。この記事の形で古いロシア語版の README を (部分的に) 提示することにしました。

クラスターは仮想マシン上にデプロイされます VirtualBox。 合計 12 台の仮想マシン (合計 36GiB) がデプロイされ、4 つのフォールト トレラント クラスター (さまざまなオプション) を形成します。 最初の XNUMX つのクラスターは、異なるデータセンターにある XNUMX つの PostgreSQL サーバーと、XNUMX つの共通サーバーで構成されます。 目撃者 c クォーラムデバイス (第 XNUMX のデータ センターの安価な仮想マシンでホストされている)、不確実性を解決します。 50％/ 50％、いずれかの政党に投票します。 XNUMX つのデータセンターの XNUMX 番目のクラスター: マスター XNUMX つ、スレーブ XNUMX つ、なし クォーラムデバイス。 XNUMX 番目のクラスターは XNUMX 台の PostgreSQL サーバー (データ センターごとに XNUMX 台) で構成されます。XNUMX 台はマスター、残りはレプリカで、また 目撃者 c クォーラムデバイス。 XNUMX つ目は、XNUMX 台のサーバーまたは XNUMX つのデータセンターの障害に耐えることができます。 このソリューションは、必要に応じて、より多くのレプリカに拡張できます。

正確な時間サービス ntpd フォールト トレランスのために再構成もされていますが、メソッド自体が使用されています ntpd (オーファンモード）。 共有サーバー 目撃者 は中央の NTP サーバーとして機能し、その時間をすべてのクラスターに分散することで、すべてのサーバーを相互に同期させます。 もし 目撃者 障害が発生するか分離されると、(クラスター内の) クラスター サーバーの XNUMX つが時間を分散し始めます。 補助キャッシュ HTTPプロキシ にも引き上げられました 目撃者, その助けを借りて、他の仮想マシンは Yum リポジトリにアクセスできるようになります。 実際には、正確な時刻やプロキシなどのサービスは専用サーバーでホストされる可能性が高くなりますが、ブースではそれらは 目撃者 仮想マシンの数とスペースを節約するためだけに使用します。

バージョン

v0. VirtualBox 7 上の CentOS 11 および PostgreSQL 6.1 で動作します。

クラスター構造

すべてのクラスターは複数のデータセンターに配置され、XNUMX つのフラット ネットワークに結合されるように設計されており、単一データセンターの障害やネットワーク分離に耐える必要があります。 それが理由です 不可能 からの保護に使用する スプリットブレイン と呼ばれる標準的なペースメーカー技術 ストーニス (他のノードの頭を撃ち抜く) または フェンシング。 その本質は、クラスター内のノードが、一部のノードに問題がある、応答していない、または正しく動作していないのではないかと疑い始めた場合、IPMI や UPS コントロール カードなどの「外部」デバイスを通じて強制的にノードをオフにすることです。 。 ただし、これは、単一の障害が発生した場合でも、IPMI または UPS サーバーが動作し続ける場合にのみ機能します。 ここでは、データセンター全体に障害が発生した場合 (たとえば、電源喪失など)、さらに壊滅的な障害から保護することを計画しています。 そして、そのような拒否では、すべてが ストニス-デバイス (IPMI、UPS など) も機能しません。

代わりに、システムはクォーラムの考えに基づいています。 すべてのノードには音声があり、全ノードの半分以上を認識できるノードのみが機能します。 この「半分＋１」の量を 定足数。 クォーラムに達しない場合、ノードはネットワークが分離されていると判断し、リソースをオフにする必要があります。 これがそれです スプリットブレイン保護。 この動作を担当するソフトウェアが機能しない場合は、たとえば IPMI に基づくウォッチドッグが機能する必要があります。

ノードの数が偶数の場合 (XNUMX つのデータセンター内のクラスター)、いわゆる不確実性が生じる可能性があります。 50％/ 50％ (半分半分) ネットワーク分離によりクラスターがちょうど半分に分割される場合。 したがって、偶数のノードの場合は、次のように追加します。 クォーラムデバイス は、50 番目のデータ センターにある最も安価な仮想マシン上で起動できる、要求の厳しいデーモンです。 彼はセグメントの 50 つ (彼が見たセグメント) に投票し、それによって XNUMX%/XNUMX% の不確実性を解決します。 クォーラムデバイスが起動されるサーバーに名前を付けました 目撃者 (repmgr の用語、気に入りました)。

リソースは、障害のあるサーバーから正常なサーバーへ、またはシステム管理者の指示によって、場所から場所へ移動できます。 クライアントが必要なリソースがどこにあるのか (どこに接続すればよいのか) を把握できるように、 フローティングIP (フロートIP）。 これらは、Pacemaker がノード間を移動できる IP です (すべてがフラット ネットワーク上にあります)。 それぞれはリソース (サービス) を象徴しており、このサービス (この場合はデータベース) にアクセスするために接続する必要がある場所に配置されます。

Tuchanka1 (圧縮を伴う回路)

構造

考えたのは、負荷の低い小規模なデータベースが多数あるため、読み取り専用トランザクション用に専用のスレーブ サーバーをホット スタンバイ モードで維持するのは採算が合わないということでした (そのようなリソースの無駄遣いは必要ありません)。

各データセンターには XNUMX 台のサーバーがあります。 各サーバーには XNUMX つの PostgreSQL インスタンスがあります (PostgreSQL の用語ではクラスターと呼ばれますが、混乱を避けるために (他のデータベースから類推して) インスタンスと呼び、Pacemaker クラスターのみをクラスターと呼びます)。 XNUMX つのインスタンスはマスター モードで動作し、そのインスタンスのみがサービスを提供します (フロート IP のみがそれにつながります)。 XNUMX 番目のインスタンスは XNUMX 番目のデータセンターのスレーブとして機能し、マスターに障害が発生した場合にのみサービスを提供します。 ほとんどの場合、XNUMX つのインスタンスのうち XNUMX つのインスタンス (マスター) だけがサービスを提供 (リクエストの実行) するため、すべてのサーバー リソースはマスター用に最適化されます (メモリはshared_buffers キャッシュなどに割り当てられます)。また、データ センターの XNUMX つで障害が発生した場合に備えて、（ファイル システム キャッシュによる次善の動作ではあるものの）十分なリソースも備えています。 スレーブは、クラスターの通常の動作中はサービスを提供しません (読み取り専用リクエストを実行しません)。そのため、同じマシン上のマスターとのリソースの争奪は発生しません。

XNUMX つのノードの場合、同期レプリケーションではスレーブの障害がマスターの停止につながるため、フォールト トレランスは非同期レプリケーションでのみ可能です。

証人不履行

証人不履行 (クォーラムデバイス) Tuchanka1 クラスターについてのみ検討しますが、他のすべてについても同じ話になります。 監視が失敗した場合、クラスター構造は何も変化せず、すべてが以前と同じように動作し続けます。 ただし、クォーラムは 2 つのうち 3 つになるため、その後の障害はクラスターにとって致命的になります。 まだ早急に修正する必要があります。

Tuchanka1 の拒否

Tuchanka1 のデータセンターの XNUMX つに障害が発生しました。 この場合 目撃者 は、XNUMX 番目のデータセンターの XNUMX 番目のノードに投票します。 そこでは、以前のスレーブがマスターに変わり、その結果、両方のマスターが同じサーバー上で動作し、両方のフロート IP がそれらを指すようになります。

トゥチャンカ2 (クラシック)

構造

2 つのノードの古典的なスキーム。 マスターは 2 つで動作し、スレーブは 1 つ目で動作します。 どちらもリクエストを実行できるため (スレーブは読み取り専用)、どちらも float IP によってポイントされます。kroganXNUMX がマスター、kroganXNUMXsXNUMX がスレーブです。 マスターとスレーブの両方にフォールト トレランスがあります。

XNUMX つのノードの場合、同期レプリケーションではスレーブの障害がマスターの停止につながるため、フォールト トレランスは非同期レプリケーションでのみ可能です。

Tuchanka2 の拒否

いずれかのデータセンターに障害が発生した場合 目撃者 XNUMX番目に投票します。 唯一稼働しているデータセンターではマスターが起動され、マスターとスレーブの両方のフロート IP がそれを指します。 もちろん、マスターおよびスレーブのフロート IP からのすべての接続とリクエストを同時に受け入れるのに十分なリソース (接続制限など) があるようにインスタンスを構成する必要があります。 つまり、通常の動作中は、十分な制限値が確保されている必要があります。

Tuchanka4 (多くの奴隷)

構造

すでに別の極端さ。 大量の読み取り専用リクエストを受け取るデータベースがあります (高負荷サイトの典型的なケース)。 Tuchanka4 は、そのようなリクエストを処理するために XNUMX つ以上のスレーブが存在する可能性がある状況ですが、それでも多すぎるわけではありません。 スレーブの数が非常に多い場合は、階層レプリケーション システムを発明する必要があります。 最小のケース (図) では、XNUMX つのデータ センターのそれぞれに XNUMX つのサーバーがあり、それぞれに PostgreSQL インスタンスがあります。

このスキームのもう XNUMX つの特徴は、すでに XNUMX つの同期レプリケーションを構成できることです。 可能であれば、マスターと同じデータセンター内のレプリカではなく、別のデータセンターに複製するように構成されています。 マスターと各スレーブは、float IP によってポイントされます。 幸いなことに、スレーブ間で何らかの方法でリクエストのバランスを取る必要があります。 SQLプロキシたとえば、クライアント側です。 クライアントのタイプが異なれば、必要なタイプも異なる場合があります SQLプロキシ、誰がどれを必要とするかはクライアント開発者だけが知っています。 この機能は、外部デーモンまたはクライアント ライブラリ (接続プール) などによって実装できます。 これらすべては、フェールオーバー データベース クラスターのトピックを超えています (フェールオーバー SQLプロキシ 独立して実装することも、クライアントのフォールト トレランスと組み合わせて実装することもできます)。

Tuchanka4 の拒否

XNUMX つのデータ センター (つまり XNUMX つのサーバー) に障害が発生した場合、証人は XNUMX 番目のデータ センターに投票します。 その結果、XNUMX 台のサーバーが XNUMX 番目のデータ センターで実行されます。XNUMX 台はマスターを実行し、マスター フロート IP はそれを指します (読み取り/書き込み要求を受信するため)。 XNUMX 番目のサーバーには、同期レプリケーションで実行されているスレーブがあり、スレーブ フロート IP の XNUMX つがそれをポイントしています (読み取り専用リクエストの場合)。

最初に注意すべきことは、すべてのスレーブ フロート IP がワーカーになるわけではなく、XNUMX つだけがワーカーになるということです。 そして、それを正しく扱うためには、次のことが必要になります。 SQLプロキシ すべてのリクエストを唯一残っているフロート IP にリダイレクトしました。 で、もし SQLプロキシ いいえ、その場合は、接続 URL 内ですべての float IP スレーブをカンマで区切ってリストできます。 この場合、 libpq 接続は最初に動作する IP に行われ、これは自動テスト システムで行われます。 おそらく他のライブラリ (JDBC など) では、これは機能しないため、必要になります。 SQLプロキシ。 これは、スレーブのフロート IP が XNUMX つのサーバー上で同時に発生することが禁止されているため、複数のスレーブ サーバーが実行されている場合にスレーブ サーバー間で均等に分散されるようにするために行われます。

XNUMX 番目: データセンターに障害が発生した場合でも、同期レプリケーションが維持されます。 また、二次的な障害が発生した場合、つまり残りのデータセンター内の XNUMX 台のサーバーのうち XNUMX 台に障害が発生した場合でも、クラスターはサービスの提供を停止しますが、コミットを確認したすべてのコミットされたトランザクションに関する情報を保持します。 (二次障害の場合、損失情報はありません)。

Tuchanka3 (3 データセンター)

構造

これは、完全に機能するデータ センターが XNUMX つあり、それぞれのデータ センターが完全に機能するデータベース サーバーを備えている状況のクラスターです。 この場合 クォーラムデバイス 必要ありません。 1 つのデータ センターにはマスターが配置され、他の 2 つのデータ センターにはスレーブが配置されます。 レプリケーションは同期で、タイプ ANY (slave4、slaveXNUMX) です。つまり、クライアントは、いずれかのスレーブがコミットを受け入れたと最初に応答したときにコミット確認を受け取ります。 リソースは、マスターの場合は XNUMX つのフロート IP、スレーブの場合は XNUMX つのフロート IP によって示されます。 TuchankaXNUMX とは異なり、XNUMX つのフロート IP はすべてフォールト トレラントです。 読み取り専用 SQL クエリのバランスをとるには、次のコマンドを使用できます。 SQLプロキシ (別個のフォールト トレランスを使用)、または XNUMX つのスレーブ フロート IP をクライアントの半分に割り当て、残りの半分を XNUMX 番目のクライアントに割り当てます。

Tuchanka3 の拒否

データセンターの XNUMX つが故障しても、XNUMX つが残ります。 XNUMX つ目では、マスターとマスターからのフロート IP が生成され、XNUMX つ目では、スレーブと両方のスレーブ フロート IP が生成されます (インスタンスは、両方のスレーブ フロート IP からのすべての接続を受け入れるために、リソースを二重に予約する必要があります)。 マスターとスレーブ間の同期レプリケーション。 また、クラスターは、XNUMX つのデータセンターが破壊された場合 (同時に破壊されない場合)、コミットおよび確認されたトランザクションに関する情報を保存します (情報の損失はありません)。

ファイル構造と展開の詳細な説明は含めないことにしました。 試してみたい人は、README をすべて読むことができます。 ここでは自動テストについてのみ説明します。

自動試験システム

さまざまな障害をシミュレートしてクラスターの耐障害性をテストするために、自動テスト システムが作成されました。 スクリプトによって起動される test/failure。 スクリプトは、テストするクラスターの数をパラメーターとして受け取ることができます。 たとえば次のコマンドです。

test/failure 2 3

XNUMX 番目と XNUMX 番目のクラスターのみをテストします。 パラメーターが指定されていない場合は、すべてのクラスターがテストされます。 すべてのクラスターが並行してテストされ、結果が tmux パネルに表示されます。 Tmux は専用の tmux サーバーを使用するため、デフォルトの tmux からスクリプトを実行でき、ネストされた tmux が作成されます。 大きなウィンドウと小さなフォントでターミナルを使用することをお勧めします。 テストが開始される前に、スクリプトが完了した時点ですべての仮想マシンがスナップショットにロールバックされます。 setup.

ターミナルはテスト対象のクラスターの数に応じて列に分割されており、デフォルトでは (スクリーンショットでは) 2 つあります。 TuchankaXNUMX を例にコラムの内容を説明します。 スクリーンショットのパネルには番号が付けられています。

1. テスト統計がここに表示されます。 列:
   • 失敗 — 障害をエミュレートするテスト (スクリプト内の関数) の名前。
   • 反応 — クラスターが機能を回復するまでの算術平均時間 (秒単位)。 これは、障害をエミュレートするスクリプトの開始から、クラスターが機能を復元してサービスの提供を継続できるようになる瞬間まで測定されます。 時間が非常に短い場合 (たとえば、3 秒) (これは複数のスレーブ (Tuchanka4 と TuchankaXNUMX) を含むクラスターで発生します)、障害は非同期スレーブにあり、パフォーマンスにまったく影響を与えなかったことを意味します。クラスターの状態が切り替わります。
   • 偏差 — 値の広がり（精度）を示します 反応 標準偏差法を使用します。
   • カウント — このテストが何回実行されたか。
2. 短いログを使用して、クラスターが現在実行していることを評価できます。 反復 (テスト) 番号、タイムスタンプ、および操作の名前が表示されます。 実行時間が長すぎる (5 分を超える) 場合は、問題があることを示します。
3. ハート (ハート) - 現在の時刻。 性能を視覚的に評価する場合 マスターズ 現在時刻は、float IP マスターを使用してテーブルに常に書き込まれます。 成功すると、結果がこのパネルに表示されます。
4. ビート (パルス) - スクリプトによって以前に記録された「現在時刻」 ハート マスターへ、今から読む 奴隷 フロート IP 経由で。 スレーブとレプリケーションのパフォーマンスを視覚的に評価できます。 Tuchanka1 にはフロート IP を持つスレーブはありません (サービスを提供するスレーブはありません) が、インスタンス (DB) が XNUMX つあるため、ここには表示されません。 ビートと ハート XNUMX番目のインスタンス。
5. ユーティリティを使用したクラスターの健全性の監視 pcs mon。 構造、ノード間のリソースの分布、およびその他の有用な情報を表示します。
6. クラスター内の各仮想マシンからのシステム監視がここに表示されます。 クラスターにある仮想マシンの数に応じて、このようなパネルがさらに存在する場合があります。 XNUMX つのグラフ CPU負荷 (仮想マシンには XNUMX つのプロセッサがあります)、仮想マシン名、 システム負荷 (5 分、10 分、15 分にわたって平均されるため、Load Average と呼ばれます)、プロセス データとメモリ割り当て。
7. テストを実行するスクリプトのトレース。 動作の突然の中断や無限の待機サイクルなど、誤動作が発生した場合、ここでこの動作の理由を確認できます。

テストは 5 段階で実行されます。 まず、スクリプトはあらゆる種類のテストを実行し、このテストを適用する仮想マシンをランダムに選択します。 その後、無限のテスト サイクルが実行され、仮想マシンと障害が毎回ランダムに選択されます。 テスト スクリプト (下のパネル) が突然終了するか、何かを待機する無限ループ (XNUMX つの操作の実行時間が XNUMX 分を超える、これはトレースで確認できます) は、このクラスター上のテストの一部が失敗したことを示しています。

各テストは次の操作で構成されます。

1. 障害をエミュレートする機能を起動します。
2. 準備？ — クラスターが復元されるのを待機しています (すべてのサービスが提供されている場合)。
3. クラスターの回復タイムアウトを示します (反応).
4. 修正する — クラスターは「修復中」です。 その後、完全に動作可能な状態に戻り、次の故障に備える必要があります。

以下は、テストの内容の説明を含むテストのリストです。

• フォークボム：フォークボムを使用して「メモリ不足」を発生させます。
• アウトオブスペース: ハードドライブがいっぱいです。 ただし、このテストはかなり象徴的であり、テスト中に発生する負荷がわずかであるため、通常、ハード ドライブがいっぱいになっても PostgreSQL は失敗しません。
• Postgres-KILL: コマンドで PostgreSQL を強制終了します killall -KILL postgres.
• Postgres-STOP: PostgreSQL コマンドがハングします killall -STOP postgres.
• 電源を切る: コマンドを使用して仮想マシンの電源を「切断」します。 VBoxManage controlvm "виртуалка" poweroff.
• リセット: コマンドで仮想マシンをオーバーロードします。 VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: コマンドで SBD デーモンを一時停止します。 killall -STOP sbd.
• シャットダウン: SSH 経由で仮想マシンにコマンドを送信します。 systemctl poweroff、システムは正常にシャットダウンします。
• リンクを解除する: ネットワーク分離、コマンド VBoxManage controlvm "виртуалка" setlinkstate1 off.

標準の tmux コマンド「kill-window」を使用してテストを完了する Ctrl+B &、または「detach-client」コマンド Ctrl-b d: この時点でテストは終了し、tmux が終了し、仮想マシンがオフになります。

テスト中に特定された問題

• 現在 番犬の悪魔 sbd 監視されたデーモンを停止することはできますが、凍結することはありません。 そしてその結果、凍結のみを引き起こす障害が発生します コロシンク и ペースメーカー、しかしぶら下がっていない sbd。 チェック用 コロシンク すでに持っている PR＃83 (GitHub で sbd)、スレッドに受け入れられました マスター。 彼らは (PR#83 で) Pacemaker にも同様のことが起こると約束しました。 レッドハット8 します。 しかし、そのような「誤動作」は推測的なものであり、たとえば次のようなものを使用して人為的に簡単にシミュレートできます。 killall -STOP corosync, しかし、現実では会うことはありません。

• У ペースメーカー のバージョンでは CentOS 7 正しく設定されていない 同期タイムアウト у クォーラムデバイス、 結果として XNUMX つのノードに障害が発生した場合、ある程度の確率で XNUMX 番目のノードも再起動します、マスターが移動することになっていた場所。 拡大すれば治る 同期タイムアウト у クォーラムデバイス デプロイメント中 (スクリプト内) setup/setup1）。 この修正は開発者によって受け入れられませんでした ペースメーカー代わりに、（不特定の将来に）このタイムアウトが自動的に計算されるようにインフラストラクチャを再設計することを約束しました。

• データベース構成で次のように指定されている場合、 LC_MESSAGES (テキストメッセージ) Unicode を使用できます。 ru_RU.UTF-8、その後起動時に ポストグレス ロケールが UTF-8 ではない環境、たとえば空の環境 (ここでは ペースメーカー+pgsqlms(パフ) 走る ポストグレス）その後 ログには UTF-8 文字の代わりに疑問符が含まれます。。 PostgreSQL 開発者は、この場合に何をすべきかについて合意していません。 費用がかかります、インストールする必要があります LC_MESSAGES=en_US.UTF-8 データベース インスタンスを構成 (作成) するとき。

• wal_receiver_timeout が設定されている場合 (デフォルトでは 60 秒)、tuchanka3 クラスターと tuchanka4 クラスターのマスターでの PostgreSQL-STOP テスト中に レプリケーションが新しいマスターに再接続しない。 そこでのレプリケーションは同期であるため、スレーブだけでなく新しいマスターも停止します。 PostgreSQL を構成するときに wal_receiver_timeout=0 を設定することで回避できます。

• ForkBomb テスト中に PostgreSQL でレプリケーションがフリーズする (メモリ オーバーフロー) ことが時々観察されました。 ForkBomb 後、スレーブが新しい​​マスターに再接続できない場合がある。 私がこれに遭遇したのは tuchanka3 クラスターと tuchanka4 クラスターのみで、同期レプリケーションが原因でマスターがフリーズしました。 問題は長時間 (約 XNUMX 時間) 後に自然に解決しました。 これを修正するにはさらなる研究が必要です。 症状は前のバグと似ており、原因は異なりますが、結果は同じです。

クローガンの写真を撮影した場所 逸脱したアート 著者の許可を得て：

出所： habr.com