SUSE Edge 3.3.1ドキュメント #

SUSE Edgeは、既存のSUSEとRancherのコンポーネントと、エッジコンピューティングに必要な制約や複雑さに対応できるようにEdgeチームが構築した追加機能とコンポーネントで構成されています。管理クラスタとダウンストリームクラスタの両方で使用されるコンポーネントは、高レベルなアーキテクチャ図とともに以下に説明しますが、これは網羅的なリストではないことに注意してください。

3.1.1 管理クラスタ #

 

• 管理: これは、接続されたダウンストリームクラスタのプロビジョニングとライフサイクルの管理に使用されるSUSE Edgeの中核です。管理クラスタには通常、以下のコンポーネントが含まれます。

  • Rancher Prime (第5章 「Rancher」)によるマルチクラスタ管理により、ダウンストリームクラスタのオンボーディングとインフラストラクチャおよびアプリケーションの継続的なライフサイクル管理のための共通ダッシュボードが可能になり、包括的なテナント分離とIDP (アイデンティティプロバイダ)統合、サードパーティの統合および拡張のための大規模なマーケットプレイス、ベンダーニュートラルなAPIも提供されます。

  • SUSE Multi-Linux Managerを使用したLinuxシステム管理により、ダウンストリームクラスタ上で実行される基礎となるLinuxオペレーティングシステム(*SUSE Linux Micro (第9章 「SUSE Linux Micro」))の自動的なLinuxパッチおよび設定管理が可能になります。このコンポーネントはコンテナ化されていますが、現時点では他の管理コンポーネントとは別のシステムで実行する必要があるため、上の図では「Linux管理」とラベル付けされています。

  • 特定のSUSE Edgeリリースへの管理クラスタコンポーネントのアップグレードを処理する専用のライフサイクル管理(第23章 「Upgrade Controller」)コントローラ。

  • Elemental (第13章 「Elemental」)を使用したRancher Primeへのリモートシステムのオンボーディングにより、接続されたエッジノードを目的のKubernetesクラスタに遅延バインディングしたり、GitOps経由でアプリケーションをデプロイメントしたりできます。

  • Metal3 (第10章 「Metal³」)、MetalLB (第19章 「MetalLB」)、およびCAPI (Cluster API)インフラストラクチャプロバイダによるオプションの完全なベアメタルライフサイクルおよび管理サポートにより、リモート管理機能を備えたベアメタルシステムの完全なエンドツーエンドのプロビジョニングが可能になります。

  • ダウンストリームクラスタとそれらに存在するアプリケーションのプロビジョニングとライフサイクルの管理のためのFleet (第8章 「Fleet」)と呼ばれるオプションのGitOpsエンジン。

  • 管理クラスタ自体を支えるのは、ベースオペレーティングシステムとしてのSUSE Linux Micro (第9章 「SUSE Linux Micro」)と、管理クラスタアプリケーションをサポートするKubernetesディストリビューションとしてのRKE2 (第16章 「RKE2」)です。

3.1.2 ダウンストリームクラスタ #

 

• ダウンストリーム: これは、エッジでユーザワークロードを実行するために使用されるSUSE Edgeの分散部分です。つまり、エッジの場所自体で実行されるソフトウェアであり、通常は次のコンポーネントで構成されます。

  • K3s (第15章 「K3s」)やRKE2 (第16章 「RKE2」)などのセキュアで軽量なディストリビューションを含む、Kubernetesディストリビューションの選択肢(RKE2は、政府機関や規制産業での使用に耐えるように強化、認定、最適化されています）。

  • SUSE Security (第18章 「SUSE Security」)を使用するとイメージ脆弱性スキャン、ディープパケットインスペクション、リアルタイム脅威および脆弱性保護のようなセキュリティ機能が有効になります。

  • SUSE Storage (第17章 「SUSE Storage」)によるソフトウェアブロックストレージにより、軽量で永続的、弾力性があり、拡張可能なブロックストレージが可能になります。

  • SUSE Linux Micro (第9章 「SUSE Linux Micro」)を搭載した、軽量でコンテナに最適化された堅牢なLinuxオペレーティングシステムで、エッジでのコンテナや仮想マシンの実行に不変で耐障害性に優れたOSを提供します。SUSE Linux Microは、 AArch64およびAMD64/Intel 64アーキテクチャの両方で使用でき、レイテンシの影響を受けやすいアプリケーション(通信事業者のユースケースなど)向けのリアルタイムカーネルもサポートしています。

  • 接続されたクラスタ(つまり、管理クラスタに接続しているクラスタ)には、Rancher Primeへの接続を管理するためのRancher System Agentと、SUSE Multi-Linux Managerからの指示を受けてLinuxソフトウェアの更新を適用するためのvenv-salt-minionの2つのエージェントがデプロイされます。これらのエージェントは、切断されたクラスタの管理には必要ありません。

上記のイメージは、接続されたダウンストリームクラスタと、それらの管理クラスタへの接続に関する高レベルアーキテクチャの概要を示しています。管理クラスタは、ダウンストリームクラスタとターゲット管理クラスタとの間のネットワーキングの可用性に応じて、オンプレミスとクラウドの両方の容量で、さまざまな基礎となるインフラストラクチャプラットフォーム上にデプロイできます。これが機能するための唯一の要件は、ダウンストリームクラスタノードを管理インフラストラクチャに接続するネットワークでアクセス可能なAPIとコールバックURLです。

この接続が確立されるメカニズムは、ダウンストリームクラスタのデプロイメントのメカニズムとは異なるものであることを認識することが重要です。この詳細については、次のセクションでさらに詳しく説明しますが、基本的な理解を深めるために、接続されたダウンストリームクラスタが「管理」クラスタとして確立される主なメカニズムは3つあります。

注記

大規模なデプロイメントの規模に対応し、地理的に分散した環境における帯域幅とレイテンシの問題を最適化し、停止時や管理クラスタのアップグレード時の混乱を最小限に抑えるために、複数の管理クラスタを実装することが推奨されます。現在の管理クラスタのスケーラビリティの限界とシステム要件については、こちらをご覧ください。

ダイレクトネットワークプロビジョニングでは、デプロイ先のハードウェアの詳細がわかっている場合に、アウトオブバンド管理インタフェースに直接アクセスして、プロビジョニングプロセス全体をオーケストレーションして自動化します。このシナリオで顧客が期待するソリューションとは、エッジサイトを一元的な場所から完全に自動化してプロビジョニングすることができ、ブートイメージの作成をはるかに上回る機能を備えていて、エッジロケーションでの手動操作を最小限に抑えられるソリューションです。つまり、ラックに搭載して電源をオンにし、必要なネットワークを物理ハードウェアに接続するだけで、自動化プロセスによってアウトオブバンド管理(Redfish APIなど)を介してマシンの電源が投入され、ユーザの介入なしにインフラストラクチャのプロビジョニング、オンボーディング、デプロイメントが処理されるソリューションです。これが機能するための鍵は、管理者がシステムを把握している、つまりどのハードウェアがどこにあるかを管理者が把握していることと、デプロイメントが中央で処理されることが想定されていることです。

このソリューションは最も堅牢です。管理者がハードウェアの管理インタフェースを直接操作して既知のハードウェアを扱うことに加え、ネットワークの利用可否に対する制約が少ないためです。機能面では、このソリューションは、Cluster APIとMetal³を広範に使用して、ベアメタルからオペレーティングシステム、Kubernetes、階層化アプリケーションまでを自動プロビジョニングし、デプロイメント後にSUSE Edgeの他の一般的なライフサイクル管理機能にリンクする機能を提供します。このソリューションのクイックスタートについては、第1章 「Metal³を使用したBMCの自動デプロイメント」を参照してください。

場合によっては、中央管理クラスタでハードウェアを直接管理できない環境で運用することがあります(たとえば、リモートネットワークがファイアウォールの背後にある場合や、アウトオブバンド管理インタフェースがない場合などがあり、エッジでよく見られる「PC」タイプのハードウェアで一般的です)。このシナリオの場合のために、SUSEでは、ハードウェアのブートストラップ時にその配置先がわかっていなくても、クラスタとそのワークロードをリモートでプロビジョニングできるツールを提供しています。エッジコンピューティングについて考える場合、ほとんどの人はこう考えます。エッジコンピューティングとは、不明な部分がある数千あるいは数万台のシステムがエッジロケーションで起動し、安全にPhone Home通信を行い、そのシステムの身元を検証し、実行すべき処理についての指示を受信することです。ここで要件として期待されるのは、工場でマシンを事前イメージングしたり、USBなどでブートイメージをアタッチしたりする以外には、ユーザがほとんど介入しなくてもプロビジョニングとライフサイクル管理ができることです。この領域での主な課題は、こうしたデバイスの規模、一貫性、セキュリティ、ライフサイクルに対処することです。

このソリューションでは、非常に柔軟で一貫性のある方法でシステムをプロビジョニングおよびオンボーディングできます。システムの場所、タイプや仕様、初回電源投入日時などは問いません。SUSE Edgeでは、Edge Image Builderを使用してシステムを非常に柔軟にカスタマイズできます。また、ノードのオンボーディングとKubernetesのプロビジョニングにはRancherのElementalが提供する登録機能を活用するとともに、オペレーティングシステムへのパッチの適用にはSUSE Multi-Linux Managerを活用します。このソリューションのクイックスタートについては、第2章 「Elementalを使用したリモートホストのオンボーディング」を参照してください。

スタンドアロン環境、エアギャップ環境、またはネットワークが制限された環境で運用する必要があるお客様向けに、SUSE Edgeでは、必要なデプロイメントアーティファクトがすべて含まれる、完全にカスタマイズされたインストールメディアを生成できるソリューションを提供しています。これにより、シングルノードとマルチノード両方の高可用性Kubernetesクラスタを、必要なワークロードと追加の階層化コンポーネントを含めてエッジに設定できます。これはすべて、外部とのネットワーク接続や集中管理プラットフォームの介入なしに行うことができます。ユーザエクスペリエンスは、インストールメディアをターゲットシステムに提供するという点では「Phone Home」ソリューションによく似ていますが、このソリューションは「インプレースでブートストラップ」する点が異なります。このシナリオでは、生成されたクラスタをRancherに接続して継続的に管理する(つまり、大幅な再設定や再デプロイメントなしに、「非接続」動作モードから「接続」動作モードに移行する)ことも、分離した状態のまま動作を続行することもできます。どちらの場合も、一貫した同じメカニズムを適用してライフサイクル操作を自動化できることに注意してください。

さらに、このソリューションを使用すると、「ダイレクトネットワークプロビジョニング」モデルと「Phone Homeネットワークプロビジョニング」モデルの両方をサポートする集中型インフラストラクチャをホストできる管理クラスタを迅速に作成することもできます。この方法では、あらゆるタイプのエッジインフラストラクチャを最も迅速・簡単にプロビジョニングできます。このソリューションでは、SUSE Edge Image Builderの機能を多用して、完全にカスタマイズされた無人インストールメディアを作成します。クイックスタートについては、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。