AlloyDB Omni は、Kubernetes 以外の環境（Red Hat Package Manager（RPM）パッケージを使用する Red Hat Enterprise Linux（RHEL）や互換性のあるシステムなど）に AlloyDB Omni をデプロイして管理するためのオーケストレーション プラットフォームを提供します。RPM オーケストレーターのデプロイ オプションを使用すると、クラウドのような柔軟性と自動化をオンプレミスと仮想マシン（VM）のインフラストラクチャに拡張できます。
RPM オーケストレーターを使用する AlloyDB Omni を使用すると、標準の RPM パッケージを使用して AlloyDB Omni インスタンスをインストール、構成、管理できます。このアプローチは、VM インフラストラクチャに多額の投資を行っており、Ansible などの自動化ツールを中心に確立された運用プラクティスを持つ組織をサポートします。RPM オーケストレーターのデプロイ オプションは、Docker などのコンテナ化レイヤや Kubernetes などのオーケストレーション システムを必要とせずに、Linux VM またはベアメタル サーバーで直接実行されます。
このデプロイ オプションの使用を開始するには、登録フォームを使用してアクセスをリクエストしてください。
ユースケース
RPM オーケストレーターのデプロイ オプションは、次のユースケースをサポートしています。
| ユースケース | 説明 |
|---|---|
| VM インフラストラクチャを使用する企業 | Kubernetes が標準ではない企業や、標準の VM またはベアメタル デプロイを優先するアプリケーションの依存関係を持つコンテナ化された環境をサポートします。 |
| オペレーションの簡素化 | Ansible などの使い慣れたツールを使用して、データベースのデプロイ、構成、ライフサイクル管理を自動化します。 |
| 高可用性（HA）と障害復旧（DR） | 自動フェイルオーバーと復旧メカニズムを備えた復元力のある AlloyDB Omni クラスタを設定します。 |
| ハイブリッド環境 | オンプレミス データセンターとクラウド VM で一貫したデータベース オペレーションを確保します。 |
| レガシー システムの統合 | コンテナ化されていない環境向けに設計された既存のアプリケーションやシステムと統合します。 |
利点
RPM オーケストレーターのデプロイ オプションには次の利点があります。
- 迅速なデプロイ: プロビジョニングから検証までのライフサイクル全体を自動化し、AlloyDB Omni クラスタの設定にかかる時間と複雑さを大幅に削減します。
- シームレスな統合: 標準の Linux パッケージ管理（RPM）や一般的な自動化フレームワーク（Ansible など）とネイティブに統合されているため、チームは既存のスキルとツール統合を使用できます。
- 一貫したエクスペリエンス: AlloyDB Omni Kubernetes Operator と同等の管理とオペレーションのユーザー エクスペリエンスと機能セットを提供し、さまざまなデプロイモデルで一貫性を実現します。
- エンタープライズ グレードの高可用性（HA）と障害復旧（DR）: 事業継続性のニーズを満たすために、高可用性と障害復旧の柔軟な構成をサポートします。
- 堅牢なセキュリティ: ユーザー管理、証明書（SSL）を使用したネットワーク セキュリティ、Microsoft Active Directory などのシステムとの統合など、多面的なセキュリティ戦略の実装を容易にします。
- 一元管理: AlloyDB Omni サービスを使用して、VM 上の AlloyDB Omni を管理するための一元化されたコントロール プレーンを提供します。
- 可観測性と監査: rsyslog を使用して外部ロギング サーバー（Elastic Stack など）と統合し、ログの一元管理、モニタリング、監査を可能にします。
- データ保護: バックアップと復元の構成と戦略を簡素化する機能が含まれています。
- 接続プーリング: PgBouncer のデプロイをサポートし、データベース接続を最適化してパフォーマンスを向上させます。
- フリート管理: 複数の AlloyDB Omni クラスタを大規模に管理できます。
アーキテクチャ
AlloyDB Omni は、柔軟性を提供するコンポーネントの階層を定義します。この柔軟性により、データの可用性を最大限に高め、クエリのパフォーマンスとスループットを最適化できます。このアプローチでは、AlloyDB Omni デプロイをモニタリングし、ワークロードに合わせてスケールとサイズを調整できます。
階層の最上位のリソースは、プライマリ クラスタと 1 つ以上のセカンダリ クラスタを備えた AlloyDB Omni デプロイです。 AlloyDB Omni クラスタには 1 つ以上のインスタンスがあります。これは、ユーザーが接続するコンピューティング リソースの抽象化です。クラスタには、プライマリ インスタンス（読み取り / 書き込み）と 1 つ以上のオプションの読み取りプール インスタンス（読み取り専用）が含まれます。各インスタンスには独自のエンドポイントがあります。必要に応じて、スタンドアロン デプロイ用の単一ノードまたは高可用性デプロイ用の複数ノードでプライマリ インスタンスを設定できます。すべてのノードには、ソフトウェア パッケージを使用してデプロイされた AlloyDB Omni とその他の関連コンポーネントがあります。
プライマリ インスタンスには、トランザクション ワークロードを処理するように設計されたアクティブ（読み取り / 書き込み）ノードが 1 つ含まれています。基本的なテスト、実験、開発以外のデータベース クラスタの場合は、追加のスタンバイ ノードを使用して高可用性を設定します。プライマリ ノードで障害が発生した場合にデータ損失を回避し、目標復旧時点（RPO）をゼロにするには、スタンバイ ノードの同期レプリケーション モードを構成します。
復元力のある HA
復元力のある HA アーキテクチャでは、専用のロードバランサ ノードを使用せずに、アクティブなプライマリ ノードとスタンバイ
ノードを別々のゾーンにデプロイします。
代わりに、keepalived サービスがデータベース
ノードで直接実行され、アクティブなプライマリ ノードで読み取り / 書き込み
エンドポイントを公開するフローティング仮想 IP アドレスを管理します。
次の図は、ベアメタル環境または VM 環境における復元力のある HA デプロイ アーキテクチャを示しています。
図 1.AlloyDB Omni の復元力のある HA デプロイ アーキテクチャ
スケーラブルな HA
スケーラブルな HA アーキテクチャでは、アクティブなプライマリ ノードとスタンバイ ノードを別々のゾーンにデプロイし、専用の HAProxy ロードバランサ ノードとペアにします。これらのロードバランサ ノードは、読み取り / 書き込みエンドポイントと読み取り専用 エンドポイントを公開し、クライアント トラフィックをルーティングします。
次の図は、ベアメタル環境または VM 環境における AlloyDB Omni スケーラブル HA デプロイの分類を示しています。
図 2.AlloyDB Omni スケーラブル HA VM デプロイ アーキテクチャ
コンポーネント
RPM オーケストレーターのデプロイ オプションには、フルスタックの高可用性 AlloyDB Omni デプロイ用のソフトウェア コンポーネントのセットが含まれています。各コンポーネントは RPM パッケージまたは Debian パッケージとしてインストールされます。リファレンス アーキテクチャは、データベース オペレーションでこれらのコンポーネントに依存しています。
| コンポーネント | 説明 |
|---|---|
| オーケストレーター | AlloyDB Omni オーケストレーションは、コマンドライン インターフェースと Ansible インターフェースを提供し、分散環境で 1 つ以上の AlloyDB Omni クラスタをデプロイして管理できるようにします。 |
| alloydbomni | AlloyDB Omni コアには、パフォーマンスを向上させるための PostgreSQL と Autopilot の機能が含まれています。また、オンライン分析処理（OLAP）や生成 AI などの最新のワークロードをサポートする機能も含まれています。 |
| alloydbomni_monitor | AlloyDB Omni モニターを使用すると、AlloyDB Omni から指標を取得できます。 |
| etcd | etcd は、クラスタ マネージャーが PostgreSQL の構成と状態情報を保存するために使用する分散構成システムを提供します。 |
| クラスタ マネージャー | 中央コントロール プレーンは、クラスタ全体のオペレーションをオーケストレーションします。これには、クラスタのブートストラップ、HA の管理、フェイルオーバーの処理、アップグレードの調整、自動化ツール（Ansible や alloydbctl コマンドライン ユーティリティなど）のインターフェースの公開が含まれます。 |
| ノード マネージャー | AlloyDB Omni クラスタ内の各ノードで実行されるエージェント。クラスタ マネージャーと連携して、ノードでタスクを実行します。たとえば、AlloyDB Omni のインストールと構成、データベース サービスのライフサイクル（開始と停止）の管理、ノードの健全性のモニタリング、ログと指標の収集などです。 |
| HAProxy | HAProxy は、AlloyDB Omni デプロイのロードバランサとして機能します。読み取り / 書き込みエンドポイントと読み取り専用エンドポイントを公開します。クラスタ マネージャーと連携して、トラフィックを適切なアクティブ ノードにリダイレクトします。 |
| keepalived | keepalived は、フローティング仮想 IP アドレスを使用して、参加ノード（HAProxy など）に HA を提供できます。 |
| PgBouncer | PgBouncer は、PostgreSQL データベース用の軽量接続プーラーです。 |
| pgBackRest | pgBackRest は、PostgreSQL 向けに設計されたオープンソースのバックアップと復元ツールです。 |
このアーキテクチャを使用すると、既存の Linux VM 環境で AlloyDB Omni を効率的に実行して運用し、AlloyDB Omni と確立された運用プラクティスの使い慣れた環境を組み合わせることができます。
システム要件
AlloyDB Omni デプロイ スタックのシステム要件には、さまざまなコンポーネントを実行するように事前構成された仮想マシンのセットが含まれます。各 AlloyDB Omni 仮想マシンには、ext4/xfs ファイル システムで構成されたデータディスクが接続されている必要があります。ディスクサイズはデータサイズから推定されます。ストレージのパフォーマンス特性は、AlloyDB Omni のパフォーマンスに影響します。次の表に、VM の最小 CPU 構成と推奨 CPU 構成、最小メモリ構成と推奨メモリ構成を示します。
| VM のタイプ | 最小ハードウェアとオペレーティング システム（OS） | 推奨ハードウェアと OS |
|---|---|---|
| コントローラ ノード |
|
|
| ロードバランサ ノード |
|
|
| AlloyDB Omni（スタンドアロン） |
|
|
| AlloyDB Omni（高可用性） |
|
|
| バックアップ リポジトリ ノード |
|
|
HA デプロイのリファレンス アーキテクチャ
HA アーキテクチャは、単一ノード データベースの設定と比較して、データ層のダウンタイムに対する保護を強化します。どちらの HA リファレンス アーキテクチャも、アクティブなプライマリ ノードと同期ストリーミング レプリケーション スタンバイ ノードを使用して、別々のゾーンにデプロイされたマルチノード データベースの設定（primary_instance_nodes グループ）を使用します。プライマリ ノードで障害が発生すると、スタンバイ ノードがプライマリとして引き継ぎ、クライアント クエリを処理します。
ソフトウェア スタックのクラスタ マネージャー コンポーネントは、クラスタ構成を実行し、AlloyDB Omni サーバーの健全性をモニタリングし、etcd などの分散構成システムを使用して新しいプライマリを選択することで、自動フェイルオーバーをオーケストレーションします。企業は、可用性の重要な指標として目標復旧時点（RPO）と目標復旧時間（RTO）を使用します。HA アーキテクチャの設定では、ゾーンレベルの障害に対する RPO と RTO がほぼゼロになります。また、非同期レプリケーションを使用してバックアップとオプションの読み取りプール インスタンスを構成し、読み取り専用ワークロードをオフロードすることもできます。
ワークロードとルーティングの要件に応じて、専用のロードバランサ ノードなしで動作する復元力のある HA アーキテクチャと、専用のロードバランサ ノードを含むスケーラブルな HA アーキテクチャのいずれかを使用して、AlloyDB Omni をデプロイできます。
復元力のある HA
復元力のある HA アーキテクチャでは、専用のロードバランサ ノードを使用せずにデータベース ノード
（primary_instance_nodes グループ）をデプロイします。
- 仮想 IP ルーティング:
keepalivedサービスはデータベース ノードで直接実行され、アクティブなプライマリ ノードを指すフローティング 仮想 IP アドレスを管理します。この 構成では、読み取り / 書き込みエンドポイントがアクティブ ノードで直接公開されます。クライアント アプリケーションは、仮想 IP アドレスを使用してデータベースに接続します。フェイルオーバーが発生してスタンバイ ノードが プライマリに昇格すると、keepalivedサービスは仮想 IP アドレスを新しいアクティブなプライマリ ノードに自動的に切り替えます。 - 接続プーリング: 接続プーリングに PgBouncer を使用する場合、データベース ノードで直接実行されます。
スケーラブルな HA
スケーラブルな HA アーキテクチャでは、専用のロードバランサ ノード
（load_balancer_nodes グループ）をデータベース クラスタに追加します。
- HAProxy ロード バランシング: 専用のロード バランサ ノードは HAProxy を実行し、読み取り / 書き込みエンドポイントと読み取り専用 エンドポイントの両方を公開します。HAProxy はクラスタ マネージャーと連携してノード の状態をモニタリングし、読み取り / 書き込みクエリをアクティブなプライマリ ノードにルーティングし、 読み取り専用クエリを健全なスタンバイ ノードまたはオプションの 読み取りプール インスタンスに分散します。フェイルオーバーが発生すると、HAProxy は 読み取り / 書き込みトラフィックを新しいアクティブ ノードに自動的に切り替えます。
- ロードバランサの高可用性:
keepalivedサービスはロードバランサ ノードで実行され、 フローティング仮想 IP アドレスを管理します。クライアントは、この仮想 IP アドレスを使用して HAProxy ロードバランサに接続し、データベース オペレーションを実行します。アクティブな HAProxy サービスまたはロードバランサ ノード で障害が発生すると、keepalivedサービスは仮想 IP アドレスを別のロードバランサ ノードに移行します。 - 接続プーリング: 接続プーリングに PgBouncer を使用する場合、専用のロードバランサ ノードで HAProxy および
keepalivedとともに実行されます。
次の図は、HA デプロイ アーキテクチャを示しています。
図 3.HA デプロイ アーキテクチャ
RPM オーケストレーター
RPM オーケストレーターを使用する AlloyDB Omni は、一連の VM またはベアメタル サーバーに AlloyDB Omni データベース クラスタをインストール、設定、管理するための自動化プラットフォームとコントロール プレーンを提供します。これには、スタンドアロン、復元力のある、スケーラブルな高可用性（HA）など、さまざまなリファレンス アーキテクチャ構成が含まれます。
AlloyDB Omni クラスタ マネージャーはコントロール プレーンを提供します。 このコンポーネントは、AlloyDB Omni クラスタの管理と高可用性を自動化し、AlloyDB Omni クラスタのエンドツーエンドのライフサイクルを制御するコアサービスです。コントロール プレーン自体は高可用性であり、さまざまな障害シナリオを処理します。
RPM オーケストレーターのデプロイ オプションは、AlloyDB Omni クラスタ マネージャー サービスと通信するためのリモート インターフェースです。オーケストレーターは、コントロール ノードと呼ばれる専用ノードで実行されます。 このノードから、安全なチャネルを介して 1 つ以上のクラスタをリモートで管理できます。環境との互換性を確保するため、複数の AlloyDB Omni オーケストレーターを使用できます。自動化のニーズに適したオーケストレーターを選択してください。
- AlloyDB Omni オーケストレーター CLI（RPM として利用可能）: シェル スクリプトを使用してクラスタのデプロイと管理を自動化する環境に おすすめします。
- RPM オーケストレーター Ansible（Ansible Collection として利用可能）: Ansible ベースの組み込み 自動化を使用し、追加の Ansible ロールを呼び出して拡張する準備ができている環境におすすめします。既存の Ansible プレイブックとの簡単な統合を可能にする Ansible プレイブックの例が用意されています。
AlloyDB Omni オーケストレーターは、次の AlloyDB Omni クラスタ関連のオペレーションを容易にします。Ansible ベースのオーケストレーターは、これらのオペレーションごとに Ansible ロールを提供します。コマンドラインには、シェル プロンプトまたはシェル スクリプトを使用して呼び出される一連のコマンドが用意されています。
Installation: 各ノードにさまざまなクラスタ コンポーネントをインストールします。Bootstrap: 仕様に従ってすべてのコンポーネントを構成してブートストラップします。Update: 新しいバージョンまたは更新された構成のリソースを更新します。Status: クラスタ内のすべてのコンポーネントまたはサービスのステータスを取得します。Delete: クラスタ リソースを削除します。
オーケストレーターは、YAML 形式で一連の仕様を入力として受け取ります。
- Deployment の仕様: これは、VM クラスタのトポロジを定義する Ansible インベントリ形式と同じです。これには、次のようなさまざまな VM グループとその構成が含まれます。
primary_instance_nodes: AlloyDB Omni データベース サーバー専用のノード。cluster_manager_nodes: 省略可。AlloyDB Omni クラスタ マネージャー サーバーを実行するノード。専用のクラスタ マネージャー ノードが存在しない場合は、primary_instance_nodesにクラスタ マネージャーをデプロイできます。etcd_nodes: クラスタ マネージャーは etcd にメタデータを保存します。明示的に指定しない限り、etcd はクラスタ マネージャー ノードと同じノードで実行できます。load_balancer_nodes: 省略可。スケーラブルな HA デプロイで HAProxy ベースのロードバランサ専用の追加ノード。省略した場合、復元力のある HA デプロイでは、keepalivedと PgBouncer がprimary_instance_nodesグループのノードで直接実行されます。
- リソース仕様: クラスタは、デプロイして管理する 1 つ以上のクラスタ リソース（データベース クラスタや接続プーラーなど）で構成されます。リソース仕様は YAML 形式で、クラスタにデプロイするリソースを記述します。
制限事項
- RPM オーケストレーターのデプロイ オプションは、次のもののみをサポートしています。
- AlloyDB Omni PostgreSQL 18
- RHEL バージョン 9 互換のソフトウェア パッケージ
- Intel x86 64 ビット プラットフォーム
- メジャー バージョンのアップグレードはサポートされていません。
- 障害復旧と読み取りプール インスタンスの設定手順は含まれていません。
- AlloyDB Omni モニタリングは SSL 接続をサポートしていません。モニタリング ダッシュボード サーバーは、AlloyDB Omni ノードと同じプライベート ネットワークにデプロイする必要があります。
- AlloyDB Omni は、パーミッシブ モードと自動適用モードの両方で SELinux をサポートしています。クラスタをブートストラップする前に、選択した SELinux モードを構成する必要があります。ブートストラップ後に自動適用モードに切り替えることはできません。
次のステップ
- このデプロイ オプションの使用を開始するには、登録フォームを使用してアクセスをリクエストしてください。
- AlloyDB Omni のダウンロード オプションとインストール オプションを選択する。
- AlloyDB Omni オーケストレーターをインストールする。