Planning your architecture

Planning your architecture#

概要#

前提条件#

  • アーキテクチャプランで有効にするビジネス目標のリスト例:バグデコンストレイン、目的のアップタイム、目的のレイテンシー)

結果#

  • ハイブリッドマネージャーHMアーキテクチャのトポロジ、局所性、および冗長モデルを定義するアーキテクチャ決定レコードADR。 (少なくとも、ノート付きのアーキテクチャ図)

  • HM Helmチャート構成ファイルの初期入力 ``values.yaml`` .

注釈

最終的に展開アーキテクチャを所有するのは、顧客であるあなたです。 EDBのセールスエンジニアリング、プロフェッショナルサービス、サポートチーム、またはドキュメントを参照することができますが、最終的なアーキテクチャの決定はあなたのチームにあります。

次のフェーズ フェーズ2 フェーズ2システム要件の収集

アーキテクチャの発見#

アーキテクチャ検出の目標は、ハイブリッドマネージャーHMを正常に展開するために必要な決定をナビゲートおよび文書化することです。 これらの決定は、 ** フェーズ2システム要件の収集 ** フェーズ2および ** Preparing your environment ** フェーズ3のブループリントを形成します。

付属の質問は、データベースレイヤーを超えて広がる幅広い考慮事項をカバーしています。 このガイドは、2つの観点から見る必要があります。

  • 現在の状態 現在、既存のデータベースとアプリケーションのワークロードはどこにありますか？

  • 目標の状態 HMをすぐにどこに展開する予定ですか、そして次の1〜2年でどこに拡張する予定ですか。

地域 HMはどこに住んでいますか？#

データベースと依存アプリケーションの物理的または論理的な場所を理解することは、必要なアーキテクチャを決定するために重要です。

  • 回答する質問 *現在のデータベースソリューションは、 クラウドリージョンCSP または 物理データセンターオンプレミスの観点からどこにありますか。

*これらのデータベースの依存アプリケーションのワークロードはどこにありますか?

*** 依存関係の上流レイヤー**はありますか、それらはどこにありますか。

  • 分析 ローカリティは、展開の初期スコープたとえば、単一のクラウドリージョン対マルチリージョンなどを決定します。複数のリージョン、クラウド、またはハイブリッドクラウド環境にまたがる予定がある場合、** Postgres Distributed **が適切なデータベースサービスの推奨事項となる可能性があります。* 上流アプリケーションの局所性は、ネットワーク遅延を最小限に抑えるためのキーとなります。

ディザスターリカバリーホット/コールド#

ディザスターリカバリーDRは、さまざまな場所でのビジネスの継続性を保証します。

  • 回答する質問 事業継続のサブセットとしてのディザスターリカバリーは、これらの場所でどのように達成されますか、または ディザスターリカバリーとして特に割り当てられた追加のロケーション はありますか。特にDR** として割り当てられた **追加の場所はありますか?*DR機能 検証はどのように行われ、どのくらいの頻度で行われますか？

  • 分析 専用のセカンダリロケーションがあることは、強力なアーキテクチャ要件を示しています。 正式なDR実践が存在しない場合、HM DBaaSファーウェイレプリカソリューションは新しい機能を提供する場合があります。

アクティブネス アクティブ/パッシブvs.アクティブ/アクティブ#

アクティブ度は、重要なワークロードに分散ロケーションがどのように利用されているかを表します。

  • 回答する質問 複数の場所がある場合、重要な依存ワークロードはこれらのシステムをどのように利用しますか。 トランザクション処理OLTPに対して1つの場所はアクティブで、もう1つはパッシブですか？ * 1つの場所はOLTP用にアクティブで、もう1つの場所は分析処理OLAP / BI用にアクティブですか？

  • 分析 ターゲット状態が複数のデータベースインスタンスへの同時書き込みが必要な場合、場所全体で真の アクティブ/アクティブ 、マルチライターのため、 Postgres Distributed が必要なソリューションです。 Capacity..場所が受動的に待機しているコールドスタンバイか、アクティブに実行しているホットスタンバイかを理解することは、リソース要件と目標復旧時間RTOを定義するのに役立ちます。*** ビジネス継続性** アクティブ/パッシブ、アクティブ/アクティブ、スタンバイモデルを中心としたアーキテクチャの選択では、ダウンタイム/データ損失に対する組織の許容範囲と、冗長システムの維持コストのバランスを取る必要があります。

これらのトピックは、アクティブ性の議論に自然に続き、アプリケーションエコシステムの全体像を完成させるのに役立ちます。

  • 消費アプリケーションの観点からの入力トラフィックルーティング。

  • さまざまなアプリケーションレイヤーでのレプリケーション。

  • キャッシュレイヤーとデータベースに対するその相対的な場所。

  • セッション要求たとえば、セッションレプリケーションはアプリケーションレイヤーで処理されますか？

ライフサイクル操作#

運用慣行を理解することは、データベースサービスの管理に必要なKubernetes環境の複雑さを判断するのに役立ちます。

  • 回答する質問 *** Blue/Green や Canary などのライフサイクル操作パターンを利用していますか。* DML/ DDLの更新 データとスキーマと エンジンのアップグレード **メジャーバージョンをどのように処理しますか？*どのような プリプロダクション環境ステージング、開発、テストが必要です。

  • 分析 ブルー/グリーン展開のようなプラクティスは、EDBのデータベースソリューションが提供するゼロダウンタイム機能とよく連携します。実稼働前環境の数は、** フェーズ2システム要件の収集 **で定義された合計クラスター数とリソースサイズに直接影響します。

サポートされているプラットフォーム#

HMとKubernetesは1対1の関係にあります。各HM展開には、独自の専用のKubernetesクラスターが必要です。 Kubernetesクラスターは、現在のバージョンでHM専用である必要があります。他のワークロードとの共有はサポートされていません。

  • Amazon EKS Elastic Kubernetes Service

  • Google GKE Google Kubernetes Engine

  • Rancher RKE2 Rancher Kubernetes Engine

  • Red Hat OpenShift RHOS

注釈

お客様は、Kubernetesクラスターの完全なライフサイクル管理、プロビジョニング、展開、アップグレード、スケーリングの責任を負います。

HM分散リファレンスアーキテクチャ#

HM分散リファレンスアーキテクチャは、最高レベルのスケールと最速のSLAを達成するための最終目標を表しています。 通常、複数のデータセンターにまたがります。

HM reference architecture

HM reference architecture#

図の凡例リファレンス#

凡例は、アーキテクチャ図で使用される色と論理グループを定義します。

  • ローカリティ 物理的なデータセンターまたは地理的地域たとえば「City 1」および「Data Center 1」などの最高レベルの物理的または論理グループ。

  • Kubernetesクラスター プラットフォーム全体をホストする完全なKubernetes環境すべてのCPおよびワーカーノードを含む。

  • EDB HM: コアHMコンポーネントの論理境界。これは通常、専用のKubernetes名前空間たとえばコントロールプレーンとして実装されます。

  • コンピューティングマシン Kubernetesワーカーノードとして機能し、クラスターにCPU、メモリ、およびストレージを提供する仮想マシンvm01、vm02、vm03など。

  • インフラストラクチャの抽象化 この重要なレイヤーは、基になる物理または仮想インフラストラクチャを抽象化するKubernetesネイティブリソースを表します。これらのリソースは、Kubernetesクラスターの環境によって提供される必要があります。 *** 例1:type:LoadBalancer これは、外部ロードバランサーを要求するKubernetes Serviceタイプです。パブリッククラウド環境AWS、GCP、Azureなどでは、これは管理対象サービスとして自動的にプロビジョニングされます。オンプレミスまたはベアメタル展開では、これらのロードバランサー要求を満たすためのMetalLBのようなソリューションを提供する必要があります。* 例2StorageClass** このリソースは、「ブロックストレージ」および「オブジェクトストレージ」要件を抽象化します。 Kubernetesストレージ要求永続ボリューム要求を実際のプロビジョニングされたストレージハードウェアまたはソフトウェアlocal-pv、Ceph、vSphere、またはクラウドベースのディスクなどにマッピングします。

デプロイメントアーキテクチャ#

以下のリファレンスアーキテクチャA〜Dをリファレンスモデルとして使用して、「

Target state 」と一致するトポロジを決定します。

注釈

上記のこの凡例は、以下のリファレンスアーキテクチャA〜Dにも適用されます。

A.最小コントロールプレーン#

最小インストールでは、Kubernetes制御ノードにHMコントロールプレーンCPをコロケーションします。

これは次の場合に完全に機能します。

  • Postgres / Oracleエステートのビューの一元化。

  • データベース移行機能。

  • GenAI 管理対象Postgresインスタンスの不足による機能の制限。

HM minimum

HM minimum#

内部アーキテクチャ HMコントロールプレーン#

HMは、Kubernetesクラスター内で実行される複数のコアマイクロサービスで構成されています。これらのコンポーネントを理解することは、リソースの割り当てとセキュリティ境界を計画する際に役立ちます。

  • GenAI AI / ML機能を提供します。このコンポーネントは有効になっている場合、 ** フェーズ2システム要件の収集 ** でのGPU対応ワーカーノードの必要性を指示します。 ** 参照*

GenAI in HM

  • Postgresライフサイクル操作 データベースの展開、スケーリング、更新を管理するオーケストレーションエンジン。 ** 参照*

Cluster Management

  • テレメトリ メトリックとログを収集します。このサービスでは、状態を報告するためにアウトバウンドネットワークアクセスが必要です。 ** 参照* Monitoring with Hybrid Manager

  • データベース移行アシスタント 外部ソースからプラットフォームへのデータの移動を促進します。 ** 参照* Migrating databases with Hybrid Manager

  • エステート HM DBAAS内部システムと外部データベースを使用して作成するリソースのインベントリを管理します。 ** 参照*

Enable monitoring>On external database clusters

アーキテクチャの依存関係#

上記のアーキテクチャ図は、いくつかの外部コンポーネントを参照しています。 ** フェーズ2システム要件の収集 ** でこれらの特定のハードウェア/ソフトウェア要件を検証している間、アーキテクチャデザインでの接続を考慮する必要があります。

  • IDプロバイダーIdP ユーザー認証に必要です。このアーキテクチャは、すべての人によるアクセスについてOIDC LDAP / SAMLに依存しています。

  • キー管理サービスKMS オプショナル セキュリティポリシーで透過的データ暗号化TDEが要求される場合にのみ必要。

  • オブジェクトストレージ システムの復元力に必要です。バックアップ、ログをホストし、マルチロケーショントポロジのデータレプリケーションを促進します。

  • ブロックストレージ データベースのパフォーマンスに必要です。ストレージアーキテクチャは、Postgresデータレイヤーの永続ボリュームPVCを提供する必要があります。

  • ローカルネットワーク CPをデータプレーンに接続するファブリック。ここでのレイテンシーは、ローカリティの決定を促進します。

  • Container Registry アプリケーションイメージの信頼できるソース。エアギャップデザインの場合、これはローカル同期レジストリを表します。

B. HMデータプレーンPostgresライフサイクルオーケストレーション#

HM CPの横にあるのは、HMデータプレーンDPです。これは、実際のデータベースワークロードが存在する場所です。

  • Postgresクラスター 実際のデータベースインスタンスプライマリおよびスタンバイ。

  • 拡張機能 PostGIS、PGVector、およびその他のデータベース拡張機能。

  • バックアップエージェント オブジェクトストレージへのWALアーカイブを管理するローカルツールBarmanのような。

HM Data Plane

HM Data Plane#

C.フル機能の展開#

このビューには、AIワークロードのGPUアクセラレーションなどのリソースを含む、完全な機能のHM展開が示されています。

HM fully featured

HM fully featured#

D.マルチロケーションハブアンドスポーク#

マルチロケーション機能は、ハブアンドスポークモデルに従ったDBaaSオファリングです。

  1. DBaaSオファリングとして、セカンダリHMの機能セットは、プライマリと比べて低下します。

  2. プライマリHMはセカンダリを制御します。

  3. 接続は、負荷分散されたエンドポイントを使用して確立されます。たとえば、サブマリーナのようなネットワークメッシュサービスではありません。

HM multi-location

HM multi-location#

構成への影響#

この検出プロセス中に行われる決定は、インストール構成のルートパラメーターの一部を直接決定します。

ファイルをまだ作成する必要はありませんが、 アーキテクチャ決定レコード でこれらのキーの値を指定する必要があります。 SRE / Admin は、これらの入力に基づいて、 Phase 2: Gathering your system requirements の構成ファイルを記録するか続行/開始し、および/またはこれらの仕様を使用して ** Preparing your environment ** に構成ファイルvalues.yaml をビルドします。

構成の詳細#

Architecture decision

Config parameter (values.yaml)

Example value

Kubernetes Platform

system

eks, gke, rhos

Target location

parameters.upm-beacon.beacon_location_id

aws-us-east-1

Provisioning mode

beaconAgent.provisioning.provider

aws or gcp

構成ファイルへの影響#

次に、決定が、フェーズ3で作成するHM Helmチャート values.yaml の最終構成ファイル構造にどのようにマッピングされるかを示します。

system: <Kubernetes_Flavor> # e.g., rhos, rke2, eks, gke
bootstrapImageName: [https://docker.enterprisedb.com/pgai-platform/edbpgai-bootstrap/bootstrap-](https://docker.enterprisedb.com/pgai-platform/edbpgai-bootstrap/bootstrap-)<Kubernetes_Flavor>
bootstrapImageTag: <Version>
parameters:
  upm-beacon:
    beacon_location_id: <Deployment_Location_Name> # Identified in Phase 1: a simple string which will be a hint in the UI to identify this location.
beaconAgent:
    provisioning:
        provider: <Provider_Name> # AWS or GCP
        openshift: <Boolean_Value> # Defaults to `false`, set to true if deploying on RHOS

次のフェーズ#

アーキテクチャが定義され、理想的には参照用にADRに記録されます。

** フェーズ2システム要件の収集 に進んで、インフラストラクチャがADRのデザインと一致できることを確認します。**

目次