Hybrid Manager Architecture#
High-level diagram of Hybrid Manager’s architecture#
図の最も外側のコンテナは、 EKS on AWS や GKE on GCP などのクラウドサービスプロバイダーのインフラストラクチャ、またはオンプレミスインフラストラクチャで実行されているKubernetesクラスターを示しています。この文脈での「オンプレミス」には、組織のインフラストラクチャ内でホストされる物理サーバーベアメタル、仮想マシン、またはプライベートクラウドでの展開が含まれます。 図の内部に向かって作業すると、注意すべき3つの主な論理グループがあります。
Kubernetesコントロールプレーン Kubernetesコントロールプレーンは、
kube-apiserver、etcd、kube-scheduler、kube-controller-manager、クラウドセットアップの場合はcloud-controller-managerなどのコアKubernetesコンポーネントで構成され、2つまたは3つのKubernetesコントロールによって実装されますノード。コントロールコンピューティンググループ HMのコントロールコンピューティンググループは、Grafana、Loki、Thanos、PrometheusなどのHMのコア管理コンポーネントを実装する2または3つのKubernetesワーカーノードで実行されている70以上のポッドの論理グループです。可観測性のためのCert Manager、証明書管理のためのCert Manager、ネットワーキングのためのIstio、ソフトウェアリリースを保護するためのトラストマネージャーなど。コンポーネントの70以上のポッドは、
kube-schedulerがそれらを配置する方法に従って、ワーカーノード全体に分散されます。これは、図に示されているほど単純ではありません。必要に応じて、より多くのワーカーノードを追加して、より多くのDatabase as a Serviceリソースをサポートできます。データコンピューティンググループ HMのデータコンピューティンググループは、名前空間によって編成されたPostgresクラスターの論理グループであり、
kube-schedulerが配置する少なくとも3つのKubernetesワーカーノードに分散された多数のポッドで実行されます。写真ほど単純ではありません。 HMを使用してデータベースが追加されると、ワーカーノードの数は3から増やすことができますが、これを自動的に行うには、ワーカーノードを手動で追加するか、インフラストラクチャとともに自動スケーリングの構成が必要になる場合があります。
Control Compute Groupingのワーカーノードと、 およびData Compute Groupingのワーカーノードは両方とも、スナップショット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 Cloudバックアップを、マルチゾーンレプリケーションをネイティブにサポートするAWS S3のようなオブジェクトストアに保存できます。または、ローカルオブジェクトストアでは、バックアップがリモートサイトにレプリケートされるように追加の構成が必要になる場合があります。ストレッチクラスターは、地理的に分散した場所全体でデータのレプリケーションと冗長性を有効にすることにより、これらの制限を緩和します。
高可用性と復元力#
HMは、Kubernetesの実績のあるテクノロジーを活用して、自動フェイルオーバーメカニズムを介して高可用性を保証します。これらのメカニズムは、ストレッチクラスター内、アベイラビリティーゾーン全体、または同じリージョン内のゾーン間で機能します。このアーキテクチャは、スナップショットバックアップを介したより高速なバックアップと、大規模なデータセットのリカバリをサポートしていますが、マルチサイトのリカバリ機能は、基になるストレージインフラストラクチャに依存します。複数のラックまたはデータセンターにまたがるSANストレージエリアネットワークなどの高度なストレージ構成を使用するお客様の場合、HMはインフラストラクチャを活用して復元力を強化し、迅速なフェイルオーバーを保証できます。ただし、これらの構成はすべてのユーザーで共通ではない場合があります。