アンブレイカブルPostgreSQL、または「オープン」DBMSにフォールトトレランスを提供する方法

インターネットには、障害に強いPostgreSQLデータベース管理システムを構築する方法に関する情報が満載です。しかし、それは大企業のタスクにはあまり適用できず、企業標準の厳格さに耐えられません。新しいAISOSAGOのITインフラストラクチャを作成するプロジェクトでは、このパズルの解決に真っ向から取り組む必要がありました。そして、多くのソリューションを慎重に選択してテストドライブした後、データベースの高可用性を確保するために使用するのに最適なITツールとシナリオのセットを見つけました。入手したレシピを共有します。







最近、ロシアの大企業は、手頃な価格のストレージソリューションにますます注目しています。オープンソースDBMSは、Oracle、SAP HANA、Sybase、Informix（PostgreSQL、MySQL、MariaDBなど）の競合製品になります。欧米の巨人（Alibaba、Instagram、Skype）は、IT業界で長い間それらを使用してきました。



JetInfosystemsが新しいAISOSAGOのITインフラストラクチャを構築していたロシア自動車保険会社連合（RSA）のプロジェクトでは、開発者はPostgreSQLDBMSを使用しました。そして、ハードウェア障害が発生した場合にデータベースの可用性を最大化し、データの損失を最小化する方法について考えました。そして、このソリューションの「紙面での」説明は2 + 2のように単純に見えます。実際、私たちのチームは耐障害性を達成するために一生懸命努力しなければなりませんでした。



PostgreSQL用のフェイルオーバークラスタリングツールがいくつかあります。これらは、Stolon、Patroni、Repmgr、Pacemaker + Corosyncなどです。



Patroniを選択したのは、このプロジェクトが活発に開発されているためです。同様のプロジェクトとは異なり、明確なドキュメントがあり、データベース管理者の選択肢になりつつあります。

「スープセット」の構成

Patroniは、PostgreSQLデータベースサーバーの主要な役割をレプリカに自動的に切り替えるための一連のpythonスクリプトです。また、PostgreSQL DBMS自体のパラメータを保存、変更、および適用することもできます。 PostgreSQL構成ファイルを各サーバーで個別に最新の状態に保つ必要はないことがわかりました。



PostgreSQLはオープンソースのリレーショナルデータベースです。それは、大規模で複雑な分析プロセスでそれ自体が証明されています。



Keepalived-マルチノード構成では、プライマリPostgreSQLノードの役割が現在使用されているクラスターのまさにノードで専用IPアドレスを有効にするために使用されます。 IPアドレスは、アプリケーションとユーザーのエントリポイントとして機能します。



DCSは分散構成ストレージです。Patroniはこれを使用して、クラスターの構成、クラスターサーバーの役割に関する情報を格納し、独自のPostgreSQL構成パラメーターを格納します。この記事では、etcdに焦点を当てます。

ニュアンスのある実験

耐障害性の最適なソリューションを探し、さまざまなオプションの動作に関する仮説をテストするために、いくつかのテストベンチを作成しました。最初に、ターゲットアーキテクチャとは異なるソリューションを検討しました。たとえば、PostgreSQLのプライマリノードとしてHaproxyを使用したり、DCSをPostgreSQLと同じサーバーに配置したりしました。内部ハッカソンを開催し、サーバーコンポーネントの障害、ネットワークの使用不可、ファイルシステムのオーバーフローなどが発生した場合にPatroniがどのように動作するかを調査しました。つまり、彼らはさまざまな障害シナリオを考え出しました。これらの「科学的研究」の結果として、耐障害性ソリューションの最終的なアーキテクチャが形成されました。

ハイIT料理の料理

PostgreSQLにはサーバーの役割があります。primary-データの書き込み/読み取り機能を備えたインスタンス。レプリカ-読み取り専用インスタンスであり、常にプライマリと同期されます。これらの役割は、PostgreSQLの実行中は静的であり、プライマリの役割を持つサーバーに障害が発生した場合、DBAはレプリカの役割を手動でプライマリに上げる必要があります。



Patroniは、フェイルオーバークラスターを作成します。つまり、サーバーをプライマリおよびレプリカの役割と組み合わせます。障害が発生した場合、それらの間で自動的に役割が逆転します。





上の図は、アプリケーションサーバーがPatroniクラスター内のサーバーの1つに接続する方法を示しています。この構成では、1つのプライマリノードと2つのレプリカを使用し、そのうちの1つは同期しています。同期レプリケーションでは、PostgreSQLは、プライマリが常に変更がレプリカに書き込まれるのを待つように機能します。同期レプリカが使用できない場合、プライマリはそれ自体に変更を書き込みません。読み取り専用になります。これがPostgreSQLのアーキテクチャです。 「その性質を変更する」ために、2番目のレプリカが使用されます-非同期（同期レプリケーションが必要ない場合は、1つのレプリカに制限できます）。



2つ以上のレプリカを使用して同期レプリケーションを有効にする場合、Patroniは常に1つの同期レプリカのみを作成します。プライマリノードに障害が発生すると、Patroniは同期レプリカのレベルを上げます。



次の図は、産業用エンタープライズソリューションに不可欠な追加のPatroni機能（バックアップサイトへのデータ複製）を示しています。





Patroniは、この機能をstandby_clusterと呼びます。これにより、Ratroniクラスターをリモートサイトで非同期レプリカとして使用できます。メインサイトが失われると、Patroniクラスターはメインサイトであるかのように機能し始めます。



バックアップサイトクラスターのノードの1つは、スタンバイリーダーと呼ばれます。これは、メインサイトのプライマリノードの非同期レプリカです。バックアップサイトクラスターの残りの2つのノードは、スタンバイリーダーからデータを受信します。これがカスケードレプリケーションの実装方法であり、技術サイト間のトラフィック量を削減します。

Patroniクラスターアプリケーションの構成

起動すると、Patroniは別のTCPポートを作成します。このポートにHTTP要求を行うと、クラスターのどのノードがプライマリで、どのノードがレプリカであるかを理解できます。





keepalivedでは、PatroniTCPポートをポーリングする監視オブジェクトとして小さな自作のスクリプトを指定しました。スクリプトはHTTPGET 200応答を想定しています。応答するクラスターノードはプライマリノードであり、keepalivedはその上でクラスターへの接続専用のIPアドレスを起動します。



同期レプリカからのHTTPGET 200応答を待機するように2番目のkeepalivedインスタンスを構成すると、同じクラスターノード上のkeepalivedは別の専用IPアドレスを起動します。このアドレスは、アプリケーションがデータベースからデータを読み取るために使用できます。このオプションは、たとえば、レポートの作成に役立ちます。



Patroniはスクリプトのセットであるため、各ノード上のインスタンスは相互に直接「通信」しませんが、これには構成ストアを使用します。それとしてetcdを使用します。これは、Patroni自体のクォーラムです。現在のプライマリノードは、etcdリポジトリ内のキーを常に更新し、それが主要なものであることを示します。残りのクラスターノードは常にこのキーを読み取り、それらがレプリカであることを「理解」します。 etcdサービスは、3または5の量の専用サーバーにあります。これらのサーバー間のetcdリポジトリ内のデータの同期は、etcdサービス自体によって実行されます。



実験の過程で、etcdサービスを別のサーバーに移動する必要があることがわかりました。まず、etcdはネットワークの待ち時間とディスクサブシステムの応答性に非常に敏感であり、専用サーバーはロードされません。次に、Patroniクラスターのノードがネットワークで分離されている可能性があるため、「ブレインスプリット」が発生する可能性があります。etcdクラスターも「崩壊」するため、2つのプライマリノードが表示され、お互いについて何も知りません。

練習チェック

AIS OSAGOのITインフラストラクチャを構築するプロジェクトの規模では、PostgreSQLの耐障害性を実現することは、オープンDBMSを企業のITランドスケープに「組み込む」タスクの1つです。その隣には、PostgreSQLクラスターをバックアップシステムと統合すること、インフラストラクチャの監視と情報セキュリティツール、およびバックアップサイトでの信頼できるデータの安全性に関する関連する問題があります。これらの各方向には、独自の落とし穴とそれらを回避する方法があります。そのうちの1つについてはすでに説明しました。エンタープライズソリューションを使用したPostgreSQLバックアップについて説明しました。





スタンドで私たちが考え、テストしたPostgreSQLのフォールトトレランスアーキテクチャは、実際にその有効性を証明しています。このソリューションは、さまざまなシステムおよび論理障害を「転送」する準備ができています。現在、10個の高負荷のPatroniクラスターで実行され、1時間あたり数百ギガバイトのデータのPostgreSQL処理負荷に耐えます。



著者：ドミトリーErykin、とのコンピューティングシステムのエンジニア、デザイナージェットインフォシステムズ