Hybrid Manager architecture#
High-level diagram of Hybrid Manager’s architecture#
図の最も外側のコンテナは、 EKS on AWS や GKE on GCP などのクラウドサービスプロバイダーのインフラストラクチャ、またはオンプレミスインフラストラクチャで実行されているKubernetesクラスターを示しています。この文脈での「オンプレミス」には、組織のインフラストラクチャ内でホストされる物理サーバーベアメタル、仮想マシン、またはプライベートクラウドでの展開が含まれます。
図の内部に向かって作業すると、3つの主な論理グループは次のとおりです。
Kubernetesコントロールプレーン Kubernetesコントロールプレーンは、コアKubernetesコンポーネントで構成され、2つまたは3つのKubernetes制御ノードによって実装されます。コアコンポーネントの例は、
kube-apiserver、etcd、kube-scheduler、kube-controller-manager、およびクラウド設定の場合はcloud-controller-managerです。制御コンピューティンググループ HMの制御コンピューティンググループは、2または3つのKubernetesワーカーノードで実行されている70以上のポッドの論理グループです。 Grafana、Loki、Thanos、オブザーバビリティのPrometheus、証明書管理のCert Manager、ネットワーキングのIstio、ソフトウェアリリースを保護するためのトラストマネージャーなど、HMのコア管理コンポーネントを実装しています。
コンポーネントの70以上のポッドは、kube-scheduler
がそれらを配置する方法に従って、ワーカーノード全体に分散されます。これは、図に示されているほど単純ではありません。
必要に応じて、ワーカーノードを追加して、より多くのDatabase-as-a-Serviceリソースをサポートできます。
データコンピューティンググループ HMのデータコンピューティンググループは、名前空間によって編成されたPostgresクラスターの論理グループです。
kube-schedulerが配置すると、少なくとも3つのKubernetesワーカーノードに分散された多数のポッドで実行されますが、図ほど単純ではない場合があります。
HMを使用してデータベースが追加されると、ワーカーノードの数を3つから増やすことができます。ただし、これを自動的に行うには、ワーカーノードを手動で追加するか、インフラストラクチャとともに自動スケーリングを構成する必要がある場合があります。
制御コンピューティンググループのワーカーノードとデータコンピューティンググループのワーカーノードは両方とも、スナップショットSANを使用するオンプレミスまたはEKSでEBSを使用するオンプレミスまたは Barman for the cloud を使用するS3互換オブジェクトストアにバックアップされます。
スケーラビリティ#
スケーラビリティをサポートするために、HMはKubernetesの自動スケーリング機能と統合しています。これは、AWSのようなプラットフォームで、データコンピューティンググループのワーカーノードを、AWSのマネージドサービス Auto Scaling groups を使用して、必要に応じてクラスターに自動的に追加できることを意味します。ただし、HMのKubernetes自動スケーリング機能を無効にして、コストを制御できます。さらに、オンプレミス展開の自動スケーリング機能を有効にするには、追加のインフラストラクチャ構成が必要であることに注意してください。これは、AWSのAuto Scalingグループの場合と同様に、オンプレミス展開にはすぐに使える自動スケーリング機能がないためです。
included Grafana dashboards または using Kubernetes `kubectl commands <Tracing clusters back to their Kubernetes resources>` を使用して、データベースクラスターを実装するポッドとワーカーノードの分散とリソース使用量をモニタできます。
バックアップアーキテクチャ#
HMは、データの完全性と復旧可能性を保証するための堅牢なバックアップオプションを提供します。データコンピューティンググループ内の各HMワーカーノードは、デフォルトで夜間バックアップを実行し、 Barmanクラウド用またはスナップショットバックアップを使用して保存されます。
スナップショットバックアップは、復旧時間を短縮するために利用できますが、ストレージレイヤーに互換性のあるCSIドライバーが必要ですクラウドベースのスナップショットとローカルディスクスナップショットの両方。論理ボリュームマネージャーLVMセットアップの制約を考慮すると、スナップショットはローカルリカバリに最適ですが、サイト間の共有アクセスが欠如しているため、マルチサイトまたはグローバルリカバリシナリオのセットアップで使用する場合、制限に直面する場合があります。
より堅牢なマルチアベイラビリティーゾーンのリカバリーのために、 Barmanクラウドバックアップは、マルチゾーンレプリケーションをネイティブにサポートするAWS S3のようなオブジェクトストアに保存できます。または、ローカルオブジェクトストアでは、バックアップがリモートサイトにレプリケートされるように追加の構成が必要になる場合があります。ストレッチクラスターは、地理的に分散した場所全体でデータのレプリケーションと冗長性を有効にすることにより、これらの制限を緩和します。
高可用性と復元力#
HMは、Kubernetesの実績のあるテクノロジーを活用して、自動フェイルオーバーメカニズムを介して高可用性を保証します。これらのメカニズムは、ストレッチクラスター内、アベイラビリティーゾーン全体、または同じリージョン内のゾーン間で機能します。このアーキテクチャは、スナップショットバックアップを介したより高速なバックアップと、大規模なデータセットのリカバリをサポートしていますが、マルチサイトのリカバリ機能は、基になるストレージインフラストラクチャに依存します。複数のラックまたはデータセンターにまたがるストレージエリアネットワークSANなどの高度なストレージ構成を使用しているお客様の場合、HMはインフラストラクチャを活用して復元力を強化し、迅速なフェイルオーバーを保証できます。ただし、これらの構成はすべてのユーザーで共通ではない場合があります。