RPM オーケストレーターを使用する AlloyDB Omni の概要

ドキュメントのバージョンを選択してください。

AlloyDB Omni は、Kubernetes 以外の環境(Red Hat Enterprise Linux(RHEL)や Red Hat Package Manager(RPM)パッケージを使用する互換性のあるシステムなど)に 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 のデプロイをモニタリングし、ワークロードに合わせてスケールとサイズを調整できます。

次の図は、ベアメタル環境または VM 環境での AlloyDB Omni デプロイの分類を示しています。

AlloyDB Omni VM のデプロイ トポロジ。

図 1.AlloyDB Omni VM デプロイ トポロジ

階層の最上位のリソースは、プライマリ クラスタと 1 つ以上のセカンダリ クラスタを備えた AlloyDB Omni デプロイです。 AlloyDB Omni クラスタには 1 つ以上のインスタンスがあります。これは、ユーザーが接続するコンピューティング リソースの抽象化です。クラスタには、プライマリ インスタンス(読み取り / 書き込み)と、1 つ以上のオプションの読み取りプール インスタンス(読み取り専用)が含まれます。各インスタンスには、独自のアクセス エンドポイントがあります。必要に応じて、スタンドアロン デプロイ用の単一ノードまたは高可用性デプロイ用の複数ノードでプライマリ インスタンスを設定できます。すべてのノードには、ソフトウェア パッケージを使用してデプロイされた AlloyDB Omni とその他の関連コンポーネントがあります。

プライマリ インスタンスには、トランザクション ワークロードを処理するように設計されたアクティブ(読み取り / 書き込み)ノードが 1 つ含まれています。基本的なテスト、実験、開発以外のデータベース クラスタの場合は、追加のスタンバイ ノードを使用して高可用性を設定します。 読み取り / 書き込みトランザクションを処理するプライマリ ノードの可用性が失われる障害が発生した場合にデータ損失(RPO=0)を回避するには、スタンバイ ノードの同期レプリケーション モードを構成します。 RPORPO は目標復旧時点として定義されます。

コンポーネント

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
コントローラ ノード
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 2 vCPU
  • RAM: 2 GB
  • ディスク: 10 GB
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 8 vCPU
  • RAM: 8 GB
  • ディスク: 20 GB 以上
ロードバランサ ノード
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 2 vCPU
  • RAM: 2 GB
  • ディスク: 10 GB
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 16 vCPU
  • RAM: 8 GB
  • ディスク: 20 GB 以上
AlloyDB Omni(スタンドアロン)
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 2 vCPU
  • RAM: 16 GB
  • ディスク: 20 GB
  • データディスク: データサイズの 2 倍
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 64 vCPU
  • RAM: AlloyDB Omni の vCPU あたり 8 GB
  • ディスク: 20 GB
  • データディスク: データサイズの 2 倍
AlloyDB Omni(高可用性)
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 4 vCPU
  • RAM: 20 GB
  • ディスク: 10 GB
  • データディスク: データサイズの 2 倍
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 64 vCPU
  • RAM: AlloyDB Omni の vCPU あたり 8 GB 以上
  • ディスク: 20 GB
  • データディスク: データサイズの 2 倍
バックアップ リポジトリ ノード
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 2 vCPU
  • RAM: 2 GB
  • ディスク: 10 GB
  • バックアップ ディスク: N 日数 * データサイズ
  • OS: RHEL9
  • CPU: AVX2 をサポートする x86-64 8 vCPU
  • RAM: 8 GB
  • ディスク: 20 GB
  • バックアップ ディスク: N 日数 * データサイズ

HA デプロイのリファレンス アーキテクチャ

HA アーキテクチャでは、単一ノードのデータベース設定よりも、データレベルのダウンタイムに対する保護が強化されます。このリファレンス アーキテクチャ構成では、3 つのノードを使用します。1 つのノードはプライマリ アクティブとして、他のノードは同期ストリーミング レプリケートされたスタンバイ サーバーとして、別々のゾーンにデプロイされます。プライマリ ノードに障害が発生すると、スタンバイ ノードの 1 つがプライマリとして引き継ぎ、クライアント クエリを処理します。

ソフトウェア スタックのクラスタ マネージャー コンポーネントは、クラスタ構成を実行します。クラスタ マネージャーは AlloyDB Omni サーバーもモニタリングし、etcd などの分散構成システムの助けを借りて新しいプライマリを選択します。企業は、可用性の主要な指標として RPO と RTO(目標復旧時間)を使用します。HA アーキテクチャの設定では、ゾーンレベルの障害に対する RPO と RTO がほぼゼロになります。

追加のノードは、HAProxy ベースのロードバランサをデプロイします。読み取り専用ワークロード用に構成された追加のエンドポイントがあります。HAProxy はクラスタ マネージャーと連携して、現在のアクティブ ノードをモニタリングし、フェイルオーバーが発生した場合は新しいアクティブ ノードに切り替えます。クライアントは HAProxy ノードに接続して、データベースに対するオペレーションを実行します。次の図は、この HA デプロイ アーキテクチャを示しています。

AlloyDB Omni HA デプロイ アーキテクチャ。

図 2: 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: クラスタ内のすべてのコンポーネントまたはサービスのステータスを取得します。
  • List: クラスタにデプロイされている使用可能なリソースのリストを取得します。
  • Delete: クラスタ リソースを削除します。

オーケストレーターは、YAML 形式で一連の仕様を入力として受け取ります。

  • デプロイ仕様: これは、VM クラスタのトポロジを定義する Ansible インベントリ形式と同じです。構成とともに、次のようなさまざまな VM グループが含まれています。
    • primary_instance_nodes: AlloyDB Omni データベース サーバー専用のノード。
    • cluster_manager_nodes: 省略可。AlloyDB Omni クラスタ マネージャー サーバーを実行するノード。専用のクラスタ マネージャー ノードが存在しない場合は、primary_instance_nodes にクラスタ マネージャーをデプロイできます。
    • etcd_nodes: クラスタ マネージャーは etcd にメタデータを保存します。明示的に指定しない限り、etcd はクラスタ マネージャー ノードと同じノードで実行できます。
    • load_balancer_nodes: HAProxy ベースのロードバランサ専用の追加ノードです。
  • リソース仕様: クラスタは、デプロイして管理する 1 つ以上のクラスタ リソース(データベース クラスタや接続プーラーなど)で構成されます。リソース仕様は YAML 形式で、クラスタにデプロイするリソースを記述します。

制限事項

  • プレビュー リリースでは、次のもののみがサポートされています。
    • AlloyDB Omni PostgreSQL 18
    • RHEL バージョン 9 互換のソフトウェア パッケージ
    • Intel x86 64 ビット プラットフォーム
  • メジャー バージョンのアップグレードはサポートされていません。
  • 障害復旧と読み取りプール インスタンスを設定する手順は含まれていません。
  • AlloyDB Omni モニタリングでは SSL 接続はサポートされていません。モニタリング ダッシュボード サーバーは、AlloyDB Omni ノードと同じプライベート ネットワークにデプロイする必要があります。
  • AlloyDB Omni では、SELinux が存在する場合、ファイル システムへのアクセスなど、許可されるようにホストで構成されていることを前提としています。

次のステップ