「無料」PostgreSQL を過酷なエンタープライズ環境に適合させる方法

PostgreSQL DBMS は多くの人に馴染みがあり、小規模なインストールでその効果が実証されています。 しかし、大企業やエンタープライズ要件に関しても、オープンソースへの傾向がますます明らかになってきています。 この記事では、Postgres を企業環境に統合する方法を説明し、例として Commvault バックアップ システムを使用してこのデータベースのバックアップ システム (BSS) を作成した経験を共有します。

PostgreSQL はすでにその価値を証明しています。DBMS は優れた機能を持ち、Alibaba や TripAdvisor などの流行のデジタル ビジネスで使用されており、ライセンス料がかからないため、MS SQL や Oracle DB などのモンスターに代わる魅力的な代替品となっています。 しかし、エンタープライズ環境における PostgreSQL について考え始めるとすぐに、次のような厳しい要件に直面します。 災害耐性？ 包括的な監視はどこにあるのでしょうか？ 自動バックアップについてはどうですか? テープ ライブラリを直接と二次ストレージの両方で使用するのはどうですか?」


一方で、PostgreSQL には、Oracle DB の RMAN や SAP データベース バックアップなどの「アダルト」DBMS のようなバックアップ ツールが組み込まれていません。 一方、企業バックアップ システムのサプライヤー (Veeam、Veritas、Commvault) は、PostgreSQL をサポートしていますが、実際には、特定の (通常はスタンドアロン) 構成と一連のさまざまな制限でのみ動作します。

Barman、Wal-g、pg_probackup など、PostgreSQL 用に特別に設計されたバックアップ システムは、PostgreSQL DBMS の小規模なインストールや、IT 環境の他の要素の大規模なバックアップが必要ない場合に非常に人気があります。 たとえば、インフラストラクチャには、PostgreSQL に加えて、物理サーバーおよび仮想サーバー、OpenShift、Oracle、MariaDB、Cassandra などが含まれる場合があります。 これらすべてを共通のツールでバックアップすることをお勧めします。 PostgreSQL 専用の別のソリューションをインストールするのは悪い考えです。データはディスクのどこかにコピーされ、その後テープに削除する必要があります。 この二重バックアップにより、バックアップ時間が長くなり、さらに重要なことに、リカバリ時間も長くなります。

エンタープライズ ソリューションでは、インストールのバックアップは、専用クラスター内の特定の数のノードで行われます。 同時に、たとえば、Commvault は、プライマリとセカンダリが特定のノードに厳密に割り当てられている XNUMX ノード クラスタでのみ動作します。 また、セカンダリからのバックアップには制限があるため、プライマリからバックアップすることのみが意味があります。 DBMS の特性により、セカンダリではダンプが作成されないため、ファイル バックアップの可能性のみが残ります。

ダウンタイムのリスクを軽減するために、フォールト トレラント システムを作成するときに、「ライブ」クラスター構成が作成され、プライマリは異なるサーバー間で段階的に移行できます。 たとえば、Patroni ソフトウェア自体は、ランダムに選択されたクラスター ノードでプライマリを起動します。 IBS には、そのままではこれを追跡する方法がなく、構成が変更されるとプロセスが中断します。 つまり、外部制御を導入すると、ISR が効率的に機能しなくなります。これは、制御サーバーが、どこからどのデータをコピーする必要があるのか​​を理解していないためです。

もう XNUMX つの問題は、Postgres でのバックアップの実装です。 これはダンプによって可能であり、小規模なデータベースで動作します。 ただし、大規模なデータベースでは、ダンプに時間がかかり、多くのリソースが必要となり、データベース インスタンスの障害につながる可能性があります。

ファイル バックアップによって状況は修正されますが、大規模なデータベースではシングル スレッド モードで動作するため速度が低下します。 さらに、ベンダーには多くの追加の制限があります。 ファイル バックアップとダンプ バックアップを同時に使用できないか、重複排除がサポートされていません。 問題はたくさんありますが、ほとんどの場合、Postgres の代わりに、高価ではあるが実績のある DBMS を選択する方が簡単です。

退却する場所はありません！ モスクワの開発者は遅れています!

しかし、最近、私たちのチームは難しい課題に直面しました。IT インフラストラクチャを作成した AIS OSAGO 2.0 を作成するプロジェクトで、開発者は新しいシステムに PostgreSQL を選択しました。

大規模なソフトウェア開発者にとって、「流行の」オープンソース ソリューションを使用するのははるかに簡単です。 Facebook には、この DBMS の運用をサポートするのに十分な専門家がいます。 そして、RSA の場合、「XNUMX 日目」のすべてのタスクが私たちの肩にのしかかりました。 耐障害性を確保し、クラスターを構築し、そしてもちろんバックアップをセットアップする必要がありました。 行動のロジックは次のとおりです。

• クラスターのプライマリ ノードからバックアップを作成するように SRK に指示します。 これを行うには、SRK がそれを見つける必要があります。つまり、XNUMX つまたは別の PostgreSQL クラスター管理ソリューションとの統合が必要です。 RSA の場合、これには Patroni ソフトウェアが使用されました。
• データの量とリカバリ要件に基づいてバックアップの種類を決定します。 たとえば、ページを細かく復元する必要がある場合はダンプを使用し、データベースが大きく、詳細な復元が必要ない場合はファイル レベルで作業します。
• マルチスレッド モードでバックアップ コピーを作成するソリューションにブロック バックアップの機能を追加します。

同時に、私たちは当初、追加コンポーネントの巨大なハーネスを使用せずに、効果的でシンプルなシステムを作成することに着手しました。 松葉杖の数が減れば、スタッフの仕事量も減り、IBS 障害のリスクも低くなります。 XNUMX つのソリューションのセットがすでにシステムの信頼性の低さを示唆しているため、Veeam と RMAN を使用するアプローチを直ちに除外しました。

企業向けのちょっとした魔法

そのため、バックアップ データ センターにミラーリングされた同じインフラストラクチャを使用して、それぞれ 10 ノードからなる 3 個のクラスターの信頼性の高いバックアップを保証する必要がありました。 PostgreSQL の観点から見たデータセンターは、アクティブ/パッシブの原則に基づいて動作します。 データベースの合計サイズは 50 TB でした。 企業レベルの制御システムであれば、これに簡単に対処できます。 ただし、最初は Postgres にはバックアップ システムとの完全かつ深い互換性に関する手がかりがないことに注意してください。 したがって、最初は PostgreSQL と組み合わせて最大限の機能を備えたソリューションを探し、システムを改良する必要がありました。

私たちは 3 回の社内「ハッカソン」を開催しました。私たちは XNUMX 以上の開発を検討し、テストし、仮説に関連して変更を加え、再度テストしました。 利用可能なオプションを検討した結果、Commvault を選択しました。 この製品は、箱から出してすぐに最も単純な PostgreSQL クラスターのインストールで動作し、そのオープン アーキテクチャにより、開発と統合が成功するという期待が (当然のことながら) 高まりました。 Commvault は PostgreSQL ログをバックアップすることもできます。 たとえば、PostgreSQL に関して言えば、Veritas NetBackup は完全バックアップのみを作成できます。

建築についてさらに詳しく。 Commvault 管理サーバーは、CommServ HA 構成の XNUMX つのデータ センターのそれぞれにインストールされました。 システムはミラーリングされ、XNUMX つのコンソールを通じて管理され、HA の観点からはすべての企業要件を満たします。

また、各データセンターに XNUMX 台の物理メディア サーバーを立ち上げ、そこにファイバー チャネル経由で SAN 経由でバックアップ専用のディスク アレイとテープ ライブラリを接続しました。 拡張された重複排除データベースによりメディア サーバーのフォールト トレランスが確保され、各サーバーを各 CSV に接続することで、コンポーネントに障害が発生した場合でも継続的な運用が可能になりました。 このシステム アーキテクチャにより、データ センターの XNUMX つが停止した場合でもバックアップを継続できます。

Patroni は各クラスターのプライマリ ノードを定義します。 データセンター内の任意の空きノードにすることができますが、ほとんどの場合に限ります。 バックアップでは、すべてのノードがセカンダリになります。

Commvault がどのクラスタ ノードがプライマリであるかを理解するために、(ソリューションのオープン アーキテクチャのおかげで) システムを Postgres と統合しました。 この目的のために、プライマリ ノードの現在の場所を Commvault 管理サーバーに報告するスクリプトが作成されました。

一般に、プロセスは次のようになります。

Patroni がプライマリを選択 → Keepalived が IP クラスタを選択してスクリプトを実行 → 選択したクラスタ ノード上の Commvault エージェントが、これがプライマリであるという通知を受信 → Commvault が擬似クライアント内でバックアップを自動的に再構成します。

このアプローチの利点は、このソリューションが一貫性、ログの正確性、または Postgres インスタンスの回復に影響を与えないことです。 また、Commvault のプライマリ ノードとセカンダリ ノードを修正する必要がないため、拡張も容易です。 システムがプライマリの場所を認識できれば十分であり、ノード数はほぼ任意の値に増やすことができます。

この解決策は理想的なふりをするものではなく、独自のニュアンスを持っています。 Commvault はインスタンス全体のみをバックアップでき、個々のデータベースはバックアップできません。 したがって、データベースごとに個別のインスタンスが作成されました。 実際のクライアントは仮想の擬似クライアントに結合されます。 各 Commvault 擬似クライアントは UNIX クラスターです。 Postgres 用 Commvault エージェントがインストールされているクラスター ノードがそれに追加されます。 その結果、擬似クライアントのすべての仮想ノードが XNUMX つのインスタンスとしてバックアップされます。

各擬似クライアント内には、クラスターのアクティブ ノードが示されます。 これは、Commvault の統合ソリューションが定義するものです。 その動作原理は非常に単純です。クラスタ IP がノード上で生成されると、スクリプトは Commvault エージェントのバイナリに「アクティブ ノード」パラメータを設定します。実際、スクリプトはメモリの必要な部分に「1」を設定します。 。 エージェントはこのデータを CommServe に送信し、Commvault は目的のノードからバックアップを作成します。 さらに、構成の正確性がスクリプト レベルでチェックされるため、バックアップ開始時のエラーを回避できます。

同時に、大規模なデータベースは複数のスレッドにわたってブロック単位でバックアップされ、RPO とバックアップ ウィンドウの要件を満たします。 システムへの負荷はわずかです。フル コピーはそれほど頻繁には発生せず、他の日や負荷が低い時間帯にはログのみが収集されます。

ちなみに、PostgreSQL アーカイブ ログのバックアップには別のポリシーを適用しました。これらのログには固有のデータが含まれているため、ログは異なるルールに従って保存され、異なるスケジュールに従ってコピーされ、重複排除は有効になっていません。

IT インフラストラクチャ全体の一貫性を確保するために、個別の Commvault ファイル クライアントが各クラスタ ノードにインストールされます。 これらはバックアップから Postgres ファイルを除外し、OS とアプリケーションのバックアップのみを目的としています。 データのこの部分にも独自のポリシーと保存期間があります。

現在、IBS は生産性サービスに影響を与えませんが、状況が変化した場合は、Commvault で負荷制限を有効にすることができます。

良いですか？ 良い！

そのため、PostgreSQL クラスターのインストール用に、実行可能なだけでなく完全に自動化されたバックアップも受け取りました。これは、企業向けのすべての要件を満たしています。

RPO および RTO パラメータの 1 時間および 2 時間は余裕を持ってカバーされており、保存されるデータの量が大幅に増加した場合でもシステムがそれらのパラメータに準拠することを意味します。 多くの疑問に反して、PostgreSQL とエンタープライズ環境は非常に互換性があることが判明しました。 そして今では、私たち自身の経験から、このような DBMS のバックアップがさまざまな構成で可能であることがわかりました。

もちろん、この道に沿って、私たちはXNUMX足の鉄のブーツを履きつぶし、多くの困難を克服し、いくつかの熊手を踏み、多くの間違いを正さなければなりませんでした。 しかし現在、このアプローチはすでにテストされており、企業の厳しい条件下で独自の DBMS の代わりにオープンソースを実装するために使用できるようになりました。

企業環境で PostgreSQL を使ってみたことがありますか?

著者：

Jet Infosystems、データ ストレージ システムの設計エンジニア、Oleg Lavrenov 氏

Dmitry Erykin 氏、Jet Infosystems のコンピューター システム設計エンジニア

出所： habr.com