このリファレンス アーキテクチャは、Google Distributed Cloud（GDC）エアギャップ環境にセルフマネージド Oracle データベースをデプロイして運用するための概念フレームワークを提供します。 このソリューションを使用すると、重要なデータベース ワークロードを、Kubernetes向け公式 Oracle Database Operator を Standard クラスタで使用して維持できます。
このアーキテクチャは、お客様所有ライセンスの使用（BYOL）モデルを有効にすることに重点を置いており、分離された環境内に標準化された安全で高可用性のデータベースをデプロイできます。プロビジョニングとネットワーキングから、高可用性、バックアップ、復元、オブザーバビリティなどの本番環境グレードのオペレーションまで、ライフサイクル全体をカバーします。
特長と機能
このソリューションは、データベース管理のためのいくつかのコア機能コンポーネントを提供します。
- 自動化されたライフサイクル管理: Oracle Database Operator を使用して シングル インスタンス データベース（SIDB）のプロビジョニング、クローニング、パッチ適用、構成を自動化します。
- 高可用性: Oracle Data Guard の統合サポートにより、 同期または非同期のレプリケーションと自動フェイルオーバー機能を提供します。 高可用性は単一ゾーン内でサポートされます。
- 永続ストレージの統合: GDC の既存の standard-rwo ストレージ クラスをデータベース ファイルにシームレスに利用して、データの耐久性を確保します。
- 安全なイメージ管理: Oracle Container Registry から ローカルの Harbor レジストリへの Oracle コンテナ イメージのミラーリングをサポートします。脆弱性 スキャンも統合されています。
- 統合されたオブザーバビリティ: データベース指標を Prometheus にエクスポートし、サイドカー パターンを使用してアラートログを転送する組み込みメカニズム。
- 柔軟なネットワーキング: 内部および外部の L4 ロードバランサをサポートし、データベース エンドポイントを安全に 公開します。
アーキテクチャの原則
- セルフマネージド アプローチ: Oracle ワークロードを デプロイして管理するためのアーキテクチャ フレームワークを提供します。
- クラウドネイティブ オペレーション: オペレーター パターンを使用してステートフル ワークロードを管理し、さまざまな環境で一貫性を確保します。
- データベース対応の復元力: インフラストラクチャ レベルのレプリケーションよりもデータベース レベルのレプリケーション（Data Guard）を優先して、論理的な一貫性 と迅速な復旧を確保します。
- セキュリティ重視の設計: ローカル レジストリ、必須のイメージ スキャン、すべてのデータベース トラフィックに対する明示的なネットワーク ポリシーを使用して、エアギャップ要件に準拠します。
アーキテクチャ
このアーキテクチャは、GDC Standard クラスタ、Oracle Database Operator、SIDB リソース、Harbor などのサポート インフラストラクチャの関係を示しています。
コンセプトとテクノロジー
このセクションでは、機能コンポーネント、その役割、システム内での通信方法について詳しく説明します。
インフラストラクチャとプラットフォーム
- GDC Standard クラスタ: Oracle Operator とデータベース Pod が存在するプライマリ コンピューティング環境。
- Harbor レジストリ: すべてのコンテナ イメージの安全なローカルの信頼できる情報源。既知の脆弱性がないことを確認するために、自動スキャンを提供します。
- 永続ストレージ: GDC standard-rwo ストレージ クラスは、PersistentVolumeClaim を使用して、Oracle データ ファイル、REDO ログ、制御ファイルに必要な基盤となるブロック ストレージを提供します。
サービスとロジック
- Oracle Database Operator:
SingleInstanceDatabaseやDataguardBrokerなどのカスタム リソースを監視するコントローラ。これらを標準の Kubernetes オブジェクトに調整します。これには、データベース Pod の StatefulSet やネットワーキングのサービスが含まれます。 - シングル インスタンス データベース（SIDB）: Oracle マルチテナント アーキテクチャ（CDB/PDB）を使用したコンテナ化されたデプロイ。複数の個別の SIDB インスタンスをデプロイすることも、1 つの SIDB 内に複数のプラグイン可能データベース（PDB）を作成してワークロードを統合することもできます。
- Data Guard Broker: プライマリ インスタンスと
スタンバイ インスタンス間のロール遷移をオーケストレートします。フェイルオーバー後にトラフィックを正しくルーティングするために Kubernetes サービスで使用されるデータベース ロールラベル（
database.oracle.com/role: primaryなど）を管理します。 - L4 ロードバランサ: データベース接続に安定した IP アドレスを提供します。
データフローとインターフェース
- SQL*Net（ポート 1521）: アプリケーション接続のプライマリ プロトコル。
- オブザーバビリティ エクスポーター: Prometheus の
/metricsエンドポイントを公開します。 - アラートログ: 標準のデータベース アラートログは
stdoutに送信され、GDC Logging エージェントによって 収集されます。 - RMAN チャネル:
CronJobリソースが S3 互換のオブジェクト ストレージにバックアップをストリーミングするために使用します。
考慮事項
- スケーラビリティとパフォーマンス:
- ワーカーノードは、本番環境ワークロード用に最小 8 個の vCPU と 32 GiB の RAM でサイズ設定する必要があります。
nodeSelectorまたは Taint と Toleration を使用して、特定のノードをデータベース ワークロード専用にすることをおすすめします。- パフォーマンスは基盤となるストレージに大きく依存します。IOPS が高い
standard-rwoを使用することをおすすめします。
- リソース管理とライセンス:
- このソリューションは、お客様所有ライセンスの使用（BYOL）モデルに準拠しています。
- 透過的なデータ暗号化（TDE）、高度な圧縮、Active Data Guard（読み取り専用スタンバイ）などの高度な機能には、特定の Enterprise Edition ライセンスが必要です。
- Oracle Database Free Edition は、開発とテストに使用できます。
- 可用性と信頼性:
- 高可用性は、プライマリ インスタンスとスタンバイ インスタンスが同じ名前空間に存在するシングルゾーン Data Guard 構成によって実現されます。
primaryロールラベルのセレクタを持つ Service を使用すると、クライアント側の変更なしで、フェイルオーバー時にクライアントをシームレスにリダイレクトできます。- データ保護のため、このソリューションでは RMAN を使用して S3 互換バケットにバックアップします。
- 運用管理:
- Operator を使用するとデプロイが簡素化されますが、チューニングや複雑な復元などの日常的なオペレーションでは、データベース管理の専門知識が役立ちます。
stdoutに送信されない詳細なトレースログと監査ログを転送するには、サイドカー コンテナの使用をおすすめします。
設計上の意思決定
このソリューションの主なアーキテクチャ上の選択肢は、自動化とエアギャップ環境の制約のバランスを取ることに重点を置いています。
Data Guard とストレージ レベルのレプリケーション
Data Guard はデータベース対応であるため、高可用性メカニズムです。このアプローチは、スタンバイに書き込まれる前にブロックを検証することで、論理的な破損を防ぎ、最大可用性モードでデータ損失をゼロに抑えます。これには Enterprise Edition の追加ライセンスが必要で、ボリューム スナップショットよりも設定オーバーヘッドが増えますが、リファイン ワークロードに必要な一貫性が得られます。
ロードバランサのサービス管理
デフォルトでは、SingleInstanceDatabase 仕様で loadBalancer: true パラメータを設定すると、外部ロードバランサ サービスが自動的に作成されます。内部ロードバランサの場合は、別のサービス リソース
必要な
networking.gke.io/load-balancer-type: "Internal" アノテーションを含めるために、手動で作成する必要があります。この手動アプローチでは、デフォルトの Operator 管理サービスが公開しないアノテーションとラベルを宣言的に制御できます。
ログのサイドカーのオブザーバビリティ戦略
このソリューションでは、ログ転送にサイドカー コンテナを使用することをおすすめします。これにより、ログ収集がメインのデータベース プロセスから切り離され、ログの量が多くてもデータベースのパフォーマンスに影響しません。これにより、データベース Pod ごとのリソース フットプリントが増加しますが、データベースの安定性に影響を与えることなく、信頼性の高いテレメトリー収集を確保できます。
前提条件と制限事項
前提条件
- 環境には、イメージ ホスティング用に事前構成されたアクセス可能な Harbor インスタンスがあります。
- Operator の Webhook 証明書を処理するために、cert-manager が Standard クラスタにプリインストールされています。
- RMAN バックアップ ターゲットに S3 互換のオブジェクト ストアを使用できます。
制限事項
- シングルゾーン HA: 高可用性構成は 単一ゾーン内でサポートされます。
- Oracle RAC なし: Real Application Clusters（RAC）のサポートは 含まれていません。このソリューションは、シングル インスタンスと Data Guard に重点を置いています。
- Standard クラスタのみ: このソリューションは GDC Standard クラスタで検証されており、 共有ユーザー クラスタではサポートされていません。