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