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

多くの人がPostgreSQLに精通しており、小規模なインストールでうまく機能しました。ただし、大企業や企業の要件に関しても、オープンソースへの傾向はより顕著になっています。この記事では、PostgresSQLを企業環境に組み込む方法を示し、Commvaultバックアップシステムを例として使用して、このデータベースのバックアップシステム（DBS）を作成した経験を共有します。





PostgreSQLはすでにその価値を証明しています。それはうまく機能し、AlibabaやTripAdvisorなどのトレンディなデジタルビジネスで使用されています。また、ロイヤルティがないため、MSSQLやOracleDBなどのモンスターに代わる魅力的な選択肢となっています。しかし、エンタープライズランドスケープでPostgreSQLについて考え始めるとすぐに、厳しい要件に遭遇します。「しかし、構成の耐障害性についてはどうでしょうか。耐災害性？包括的な監視はどこにありますか？自動バックアップはどうですか？直接ストレージとセカンダリストレージの両方でテープライブラリを使用するのはどうですか？」





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



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



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



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



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



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

後退する場所はありません！モスクワの開発者の後ろに！

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



大規模なソフトウェア開発者にとって、「トレンディな」オープンソースソリューションを使用する方がはるかに簡単です。Facebookには、このDBMSの作業をサポートするのに十分なスペシャリストがいます。そしてPCAの場合、「2日目」のすべてのタスクが私たちの肩にかかった。フォールトトレランスを提供し、クラスターを組み立て、そしてもちろんバックアップを確立する必要がありました。アクションのロジックは次のとおりです。

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

同時に、私たちは当初、追加のコンポーネントからの巨大なストラップなしで、効果的でシンプルなシステムの作成に着手しました。クラッチが少ないほど、スタッフの作業負荷が少なくなり、IBS障害のリスクが低くなります。2つのソリューションのセットがすでにシステムの信頼性の低さを示唆しているため、VeeamとRMANを使用したアプローチをすぐに除外しました。

企業にとってちょっとした魔法

そのため、同じインフラストラクチャがバックアップデータセンターにミラーリングされている間、それぞれ3ノードの10クラスターに対して信頼性の高いバックアップを保証する必要がありました。 PostgreSQL計画のデータセンターは、アクティブ-パッシブの原則に基づいて機能します。データベースの総量は50TBでした。企業レベルのSRCであれば、これを簡単に処理できます。しかし、ニュアンスは、最初はPostgresにバックアップシステムとの完全かつ深い互換性のためのフックがないということです。したがって、最初にPostgreSQLと組み合わせて最大の機能を備えたソリューションを探し、システムを改良する必要がありました。



私たちは3つの内部「ハッカソン」を実施しました。50を超える開発を調査し、テストし、仮説に関連して変更を加え、再度テストしました。利用可能なオプションを分析した後、Commvaultを選択しました。箱から出して、この製品は最も単純なクラスター化されたPostgreSQLインストールで動作する可能性があり、そのオープンアーキテクチャーは、成功した改良と統合への希望を生み出しました（これは実現しました）。また、CommvaultはPostgreSQLログをバックアップできます。たとえば、PostgreSQL部分のVeritas NetBackupは、完全バックアップのみを作成できます。



アーキテクチャの詳細をご覧ください。 Commvault管理サーバーは、CommServHA構成の2つのデータセンターのそれぞれにインストールされました。システムはミラーリングされ、単一のコンソールを介して管理され、HAの観点からは、すべての企業要件を満たしています。





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



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



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



一般に、プロセスは次のよう



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





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



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



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



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



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



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





現在、SRKは生産サービスに影響を与えませんが、状況が変化した場合、Commvaultで負荷制限システムを有効にすることが可能になります。



いいですか？良い！



そのため、実行可能であるだけでなく、クラスター化されたPostgreSQLインストールの完全に自動化されたバックアップも取得しました。これは、エンタープライズ呼び出しのすべての要件を満たしています。



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



もちろん、途中で7組の鉄のブーツを磨耗させ、多くの困難を克服し、いくつかのレーキを踏んで、多くの間違いを修正しなければなりませんでした。しかし現在、このアプローチはすでにテストされており、過酷なエンタープライズ環境で独自のDBMSの代わりにオープンソースを実装するために使用できます。



企業環境でPostgreSQLを試しましたか？



著者：



Oleg Lavrenov、JetInfosystemsデータストレージシステムの



設計エンジニアDmitryErykin、Jet Infosystems ComputingSystemsの設計エンジニア