組織リソースは、同じリソースプールと共通ポリシーを共有する管理単位またはビジネス機能を表します。Google Distributed Cloud（GDC）エアギャップは、ハードウェア レベルのマルチテナンシー機能を使用して、組織間の物理的な分離を提供します。各組織には、他の組織と共有されない、サービス用の独自のコントロール プレーン コンポーネントもあります。プロジェクト、クラスタ、サービスなどのすべてのリソースは、作成者ではなく組織に属します。そのため、リソースを作成したユーザーが組織を離れても、リソースは削除されません。代わりに、すべてのリソースタイプが組織のライフサイクルに従います。詳細については、GDC リソース階層をご覧ください。
外部ネットワーク接続
組織が有用であるためには、外部ネットワークへの接続が必要です。これにより、プラットフォーム管理者（PA）とアプリケーション オペレーター（AO）は組織とそのリソースを管理し、エンドユーザーは組織内にデプロイされたサービスを利用できます。GDC では、すべての外部接続は相互接続によって提供されます。
組織が作成されても、自動的にネットワークに接続されることはありません。オペレーターは、組織を既存の Interconnect に関連付けるか、新しい専用の Interconnect をプロビジョニングするために、追加の構成手順を実行する必要があります。通常は以下が含まれます。
- 組織を
AttachmentGroupに追加します。 - 新しい物理接続または論理接続の
Interconnectリソースを作成する。 - 組織のネットワーク ルートを外部ネットワークにアドバタイズする
RoutePolicyリソースを定義する。
組織は、専用の相互接続を持つ組織が重複する外部 IP アドレスを使用できるなど、ネットワーク機能を強化し、IP 管理を簡素化します。
コンセプトと構成手順の詳細については、Interconnect の概要をご覧ください。
Interconnect 接続モデル
GDC Interconnect は、セキュリティと IP 管理の要件に合わせて 2 つの主要な構成をサポートしています。
共有外部ネットワーク接続
このモデルでは、複数の組織が共通の外部ネットワークを介して GDC ゾーンに接続できます。この構成では、通常、インフラストラクチャ オペレーター（IO）が物理接続と BGP ピアリングを管理します。重要な要件は、各組織で使用される外部 IP アドレスが共有ネットワーク全体で一意であることです。このモデルは、共通の信頼ドメインを持つ環境で管理が容易です。
専用の外部ネットワーク接続
このモデルは、より高度な分離を必要とし、個別の外部ネットワークに接続する組織を対象としています。専用接続を使用すると、PA は BGP ピアリングを管理して、より詳細な制御を行うことができます。
このモデルの大きなメリットは、組織が重複する外部 IP アドレスを使用できることです。この機能により、GDC ユニバース内のすべてのテナントで IP 範囲の競合を解消する必要がなくなるため、IP アドレス管理が簡素化されます。
コンセプトと構成手順の詳細については、Interconnect の概要をご覧ください。
組織のアーキテクチャ
GDC には、組織向けに次の 2 つのアーキテクチャが用意されています。
- GDC エアギャップ組織 v1 アーキテクチャ（v1 組織）
- GDC エアギャップ組織 v2 アーキテクチャ（v2 組織）
表面上は、どちらのアーキテクチャでも、組織は同様の方法でプロビジョニング、使用、運用されます。ただし、基盤となるクラスタ、ネットワーキング、ストレージのアーキテクチャは、組織タイプごとに異なります。
GDC エアギャップ組織 v1 アーキテクチャ
v1 組織は次の 2 つのクラスタで構成されます。
- 組織管理者クラスタ: 組織のマネージド サービスと Marketplace サービスのコントロール プレーン コンポーネントを実行します。また、一部のコア インフラストラクチャ サービスもホストします。
- システム クラスタ: 組織の仮想マシン（VM）ワークロードと一部のマネージド サービス データプレーン ワークロードを実行します。ワーカーノードの数は、クラスタの使用率によって異なります。
PA と AO は、ワークロードのデプロイとシステムの管理を行うために、これらのクラスタタイプにアクセスする必要があります。
仮想クラスタのストレージは、クラスタ内のベンダー固有の CSI ドライバによって処理されます。
GDC エアギャップ組織 v2 アーキテクチャ
v2 組織は、組織のコントロール プレーン コンポーネントとデータプレーン コンポーネントを実行する組織インフラストラクチャ クラスタと呼ばれるクラスタで構成されます。このクラスタには、コンテナ以外のすべてのワークロードとサービスがデプロイされる管理 API サーバーもホストされます。管理 API サーバーは、PA と AO がワークロードをデプロイできるレイヤを提供しますが、組織インフラストラクチャ クラスタと直接やり取りすることはできません。
仮想クラスタのストレージは、組織のインフラストラクチャ クラスタの CSI ドライバがオペレーションを処理できるようにするプロキシ CSI ドライバによって処理されます。
IP アドレス管理、上り（内向き）と下り（外向き）の再ルーティング、VRF 構造などのネットワーキング コンポーネントにより、v1 組織アーキテクチャよりもシステムのセキュリティとユーザビリティが向上します。
v2 組織の新機能
v2 組織アーキテクチャでは、v1 組織アーキテクチャと比較して、いくつかのコンポーネントに変更が導入されています。
API とクラスタのアーキテクチャ
v2 組織アーキテクチャでは、以前のアーキテクチャで提供されていた 2 つのクラスタではなく、組織に対して 1 つのクラスタのみが提供されます。クラスタの削減により、ハードウェア リソースをより柔軟に使用できます。
また、v1 組織では利用できなかったコントロール プレーンとデータプレーンのネットワーク分離もあります。管理 API サーバー（コントロール プレーン）を、データプレーンが公開されている顧客ネットワークとは異なる顧客ネットワークで公開できるようになりました。この分離により、クラウド リソースのプロビジョニングとリソース消費の間に、オプションの追加の分離レイヤが提供されます。管理者とデベロッパーは、両方の外部ネットワークに接続している必要があります。
ストレージ
新しい v2 組織アーキテクチャでは、以前のアーキテクチャで使用されていた NetApp Trident CSI ドライバではなく、KubeVirt CSI ドライバをデプロイすることで、ユーザー クラスタから NetApp ストレージ認証情報を削除します。この CSI ドライバの更新により、ストレージ アレイの直接権限がさらに削減されます。
ネットワーキング
v2 組織では、次のネットワークの改善が利用可能です。
ノード間暗号化
v2 組織アーキテクチャは、組織のベアメタル ノード間の暗号化を提供します。これにより、物理ノードから送信されるすべての顧客ネットワーク トラフィックが暗号化され、ネットワーク スイッチが暗号化されていないトラフィックを認識できなくなります。
ネットワーク トラフィックを処理するための専用クラスタ
境界クラスタは、組織のすべての上り（内向き） / 下り（外向き）（North / South）トラフィックを処理するスケーラブルな仮想クラスタです。このクラスタにより、GDC ユニバースは将来、よりスケーラブルな仮想侵入検知 / 防御システム（IDPS）オプションに移行できます。
簡素化された VM ネットワーキング
v2 組織アーキテクチャでは、以前のアーキテクチャの VM あたりの 2 つのインターフェースが 1 つのインターフェースに統合されます。VM はデフォルトの仮想プライベート クラウド（VPC）ネットワーキング モデルに移行されます。つまり、VM はレイヤ 3（L3）レベルでネットワークに接続されます。
お客様は独自のサブネットを定義することもできますが、これは v1 組織ではサポートされていません。
IP アドレスの効率的な使用と管理
v2 組織アーキテクチャでは、組織の外部 IP アドレスの重複が許可されます。重複する外部 IP アドレスを使用すると、組織は顧客ネットワークに直接接続できるため、GDC ユニバース内のすべての組織で調整された単一の大きな外部 IP アドレス空間は不要になります。
IP アドレスは、単一のゾーン スコープの親サブネットに固定されるのではなく、組織ごとに提供されます。この機能により、オペレーターが IP アドレスを指定する必要がなくなり、管理者が独自の IP アドレスを指定できるようになります。この機能は、親スーパーネットを共有しないことで、強力なネットワーク分離を必要とする組織に優れた伸縮性と分離を提供します。
v1 組織では、上り（内向き）NAT IP アドレスは、プロジェクトごと、ユーザー クラスタごと、組織ごとに 1 つ必要でした。v2 組織の場合、この要件は大幅に改善され、プロジェクトごと、組織ごとに 1 つになりました。この変更により、お客様が提供した IP アドレスの使用効率が向上します。
v1 組織と v2 組織の機能の違い
v2 組織は、v1 組織と同じ機能をすべて提供します。v2 組織で使用できない機能は次のとおりです。
- Vertex AI
- Database Service CLI
マルチゾーン組織はどのようなアーキテクチャを使用しますか？
マルチゾーン GDC ユニバースで、既存の組織を新しいゾーンに拡張する場合、新しいゾーンの組織は既存のゾーンと同じアーキテクチャを使用する必要があります。したがって、ゾーンごとに異なる組織アーキテクチャを使用することはできません。
v2 組織をプロビジョニングする方法
組織をプロビジョニングすると、認定プロセスが適用されないお客様に対して、デフォルトで v2 組織が作成されます。
ただし、v2 組織ではアーキテクチャが大幅に変更されています。認定の対象となるお客様のデプロイの場合、v2 組織アーキテクチャの認定が完了するまで、v1 組織アーキテクチャがデフォルトのままになります。
組織アーキテクチャのデフォルトは、ゾーンのデプロイ時に構成される機能フラグによって制御されます。
組織アーキテクチャを強制する方法
まれに、デフォルトのプロビジョニング動作をオーバーライドし、プロビジョニング プロセス中に Organization リソースに spec.compatibilityOptions.architectureOverridePolicy フィールドを追加して、特定の組織アーキテクチャを強制的に選択することがあります。詳細については、顧客組織の作成ページをご覧ください。
特定の動作を強制する正当な理由がない限り、組織のデフォルトのアーキテクチャをオーバーライドすることはおすすめしません。
たとえば、タスクをブロックする v2 組織で重大な問題が発生した場合は、v1 組織を強制的に使用できます。同様に、認定が必要で、認定プロセスを開始するために 1 つの v2 組織が必要な場合は、v2 組織を強制的に作成できます。これらのオーバーライド フラグは、間違ったアーキテクチャで将来の組織のプロビジョニングが行われるのを防ぐために、厳密に必要でなくなった時点で削除する必要があります。
既存の v1 組織はどうなりますか？
GDC エアーギャップ 1.14.2 より前に作成された既存の組織は、GDC ゾーンがバージョン 1.14.2 以降にアップグレードされても、同じアーキテクチャのままです。v1 組織を v2 組織に変換するためのインプレース アップグレードは利用できませんが、v1 組織の既存の機能は、v1 組織アーキテクチャの将来の非推奨化まで引き続きサポートされます。
今後、新機能は v2 組織にのみ追加される可能性があります。そのため、できるだけ早く v1 組織から新しい v2 組織アーキテクチャにワークロードを移行することをおすすめします。単一の GDC エアギャップ ユニバースには、両方の組織アーキテクチャを同時に含めることができるため、移行が容易になります。