概要
- SUSE は、特に環境が SLES、Rancher Manager、RKE2 または K3s、Fleet、そして検証済みのサポートマトリックスを中心に標準化されている場合、Linux および Kubernetes の運用から相当な反復作業を取り除くことができます。同社が商業的に販売しているのは、オープンソースコードそのものというよりも、バージョンの維持されたシーケンス、署名済みアーティファクト、文書化された例外、そしてそのシーケンスが失敗した場合のエンジニアへのアクセスです。
- サポートされるシーケンスは意図的に制約されています。Rancher のマイナーリリースは、最新のパッチから最新のパッチへと一度に一つずつ移行する必要があります。ロールバックは Helm のダウングレードではなく、バックアップからのリストアです。RKE2 の自動化は、無効な Kubernetes のダウングレードを防ぐものではありません。Longhorn は逐次的なマイナーアップグレードを許可し、成功後のダウングレードは許可しません。また、Rancher 自身のバックアップは、管理アプリケーションを保護するものであり、全ての下流ワークロードやボリュームを保護するものではありません。
- 公開されている顧客事例は、SUSE が通常のプロビジョニングやリリース作業を数時間や数日から数分に短縮できることを示しています。しかし、総合的なライフサイクル削減を確立するのに十分な数の失敗試行、アップグレードウィンドウ、サポート解決時間、または保守労力を公開していません。購入者は、SUSE を支持された境界内に保たれたクラスター月あたりのコストと、代表的な例外からのリカバリによって評価すべきであり、ハッピーパスの速度によってではありません。
期限切れのクラスター1 つが、製品バンドルをシーケンスに変える
ありふれた問題を抱えるプラットフォームチームを想像してほしい。Rancher 管理サーバーがマイナーリリース 1 つ分遅れている。12 の RKE2 クラスターが 2 つのデータセンターと 3 つのエッジ拠点にまたがっている。1 つの拠点は直接のインターネット接続がない。Fleet は監視チャートといくつかの社内アプリケーションを配布している。Longhorn は 2 つのステートフルサービスのデータを保存している。Linux ホストは異なる SLES サービルパックを使用している。データベースベンダーが 1 つのグループの認定を遅らせたからだ。アイデンティティプロバイダー、プライベートレジストリ、ロードバランサー、ストレージドライバー、そして複数のアドミッションウェブフックが、SUSE の直接の管理外に存在する。
リクエストは単純に聞こえる: セキュリティ修正を適用し、システム群をサポート対象に戻すこと。しかし、これは単一のアップグレードではない。チームは Rancher の現在のパッチを特定し、次のリリースの既知の問題を精査し、サポートされる Kubernetes のバージョンを確認し、ホストのオペレーティングシステムを検証し、重要なチャートとコントローラーをすべてテストし、変更されたイメージセットを非接続レジストリにミラーリングし、管理アプリケーションをバックアップし、各下流のコントロールプレーンのスナップショットを取得し、アプリケーションデータを保護し、正しい順序でノードをドレインし、Fleet の調整を監視し、ストレージの健全性を確認し、変更の半分しか成功しなかった場合の「戻す」意味を決定しなければならない。
このシーケンスこそが、SUSE の真の商業的な対象領域である。Linux と Kubernetes はオープンソースだ。Rancher Manager、RKE2、K3s、Fleet、Longhorn もまた、公開ソースとコミュニティ版がある。有能なチームは SUSE の契約なしでそれらを運用できる。サブスクリプションが購入するのは、より再現が難しいものだ: 変化する上流プロジェクトを通る特定の経路がテストされている、リリースアーティファクトが追跡可能である、サポートエンジニアが関与する、そして陳腐化したパスが一定期間維持されるというベンダーの主張である。
その経路の価値は、新規インストールから判断できるものではない。インストールはイベントだが、ライフサイクル管理は繰り返しのタスクである。プラットフォームは 10 回はクリーンにインストールできても、11 回目の変更でカスタムコントローラーが取り残されたり、リストアが認証情報を欠落させたり、古いクラスターが現在のバージョンを受け入れる前に 3 回の逐次アップグレードを必要としたりすれば、それでもコストがかさむ。したがって、有用な分母は作成されたクラスター数ではない。それは、安全かつサポート可能な状態に保たれたクラスター月数であり、さらに予定外のサービス損失なしに完了した許容された変更である。
SUSE のドキュメントは、多くの境界について異例なほど率直である。それは強みだ。また、同社がアップグレード作業をなくすわけではないことも明確にしている。作業をより狭いパスに整理し、そのパスを支援することに同意している。問題は、顧客がすべてのローカルな例外を個別のエンジニアリングプロジェクトにせずにそのパスにとどまれるかどうかだ。
SUSE の名称は、企業、複数の製品、そして多くの上流プロジェクトを包含する
BTW のディレクトリエントリは、ここで取り上げる企業を特定しているが、そのネットワーク由来の要約はビジネスを定義するには不十分だ。SUSE は、1992 年に始まる歴史と、エンタープライズオープンソースを中心に構築されたポートフォリオを通じて自社を説明している。その現在の企業境界は、上場発行体だった時よりも不透明だ。SUSE は、非上場のルクセンブルク企業への合併を通じて、2023 年 11 月にフランクフルト証券取引所から撤退したと述べている。その取引前の最後の公開四半期報告書では、2023 年度第 3 四半期の調整後収益が 1 億 7,330 万ドル、年次経常収益が 3 か月遅れで測定して 6 億 6,490 万ドルと報告されている。これらの数字は、実質的なサブスクリプション事業を確立しているが、現在の製品収益やサポート品質ではない。
製品の境界はより重要である。SUSE Linux Enterprise Server は、商用 Linux ディストリビューションおよびサポート提供である。Rancher Manager は、2020 年 12 月の Rancher Labs 買収完了を通じて SUSE にもたらされた。Rancher Manager はマルチクラスター管理製品であり、Kubernetes そのものではない。RKE2 は、データセンターやセキュリティを重視するデプロイメントを対象とした SUSE の Kubernetes ディストリビューションである。K3s は、エッジで頻繁に使用される小規模なディストリビューションである。Fleet は、クラスター全体に望ましいアプリケーションと構成の状態を適用する。Longhorn は、SUSE Storage としてポートフォリオ内で販売されており、分散ブロックストレージを提供する。各製品には、独自のバージョン、データ、コントローラー、リカバリ手順、および上流依存関係がある。
Rancher Prime は、これらのプロジェクトを置き換える秘密のプロプライエタリフォークではない。SUSE 自身の用語集では、コマーシャルエディションはコミュニティ Rancher と同じソースコードに基づいて構築されており、信頼できる配信、延長されたライフサイクル、セキュリティ保証、集中したアーキテクチャガイダンス、およびアドバイザリーが追加されていると説明している。この区別は、経済性において中心的なものである。顧客は主にコードを実行する許可に対して支払っているのではない。テストされサポートされた動作範囲に対して支払っているのだ。
その範囲は、Rancher 画面に表示されるすべてについて SUSE に責任を負わせるものではない。クラスターは、Amazon、Microsoft、または Google によってホストされ、サードパーティのネットワークとストレージレイヤーを使用し、外部ディレクトリに対して認証し、顧客リポジトリからのチャートを実行することがある。Rancher は、それらの可用性や意味論を制御することなく、それらのシステムに変更を要求できる。RKE2 は、選択されたコンポーネントとデフォルトとともに上流の Kubernetes をパッケージ化するが、顧客は結果を変更するウェブフック、オペレーター、カーネルモジュールを追加できる。Fleet はチャートを適用できるが、そのチャートの作者が振る舞いの多くを所有している。Longhorn はブロックを複製できるが、アプリケーションは依然として一貫性のあるデータベースバックアップを必要とする。
したがって、正しい判断には 3 つのレベルがある。上流のテクノロジーは、Linux、Kubernetes、Helm、および関連するコントローラーが何をできるかを定義する。SUSE の製品は、テストしサポートするバージョン、コンポーネント、デフォルト、手順を決定する。顧客のデプロイメントは、それらの選択をローカルのインフラストラクチャ、アプリケーション、運用規律と組み合わせる。あるレベルでの成功や失敗は、自動的に他の 2 つに関する証拠にはならない。
サポートは、ほとんどの可能な組み合わせを拒否することから始まる
「オープンチョイス」という言葉は、適合するコンポーネントであればどれとでも組み合わせられると示唆する場合がある。本番環境では、サポートはその逆を行うことで機能する。それは組み合わせ問題を有限の集合に縮小する。
SUSE のRancher サポートマトリックスは、正確な Rancher、Kubernetes、オペレーティングシステム、アーキテクチャ、コンポーネントの組み合わせを指定している。そのライフサイクルテーブルは、Rancher と RKE2 のリリースラインに別々の日付を提供している。例えば、Rancher 2.14 は 2026 年 4 月に一般提供が開始された。このテーブルでは、保守終了まで 6 か月、その後にサポート終了日が設定されている。RKE2 のマイナーバージョンは別のカレンダーに従う。SLES サービスパックはさらに別のオーバーレイを持つ。Longhorn には独自の Kubernetes の要件がある。ソフトウェアがこれらの行の外でコンパイルまたは起動できるという事実は、SUSE がその組み合わせをテストしたことや、通常の条件の下でその欠陥を解決することを意味するわけではない。
これは SUSE 特有のものではない。上流の Kubernetes は、最新リリースの移動するセットのみをサポートし、厳格なバージョンの相違とアップグレード順序を課している。API サーバーはマイナーバージョンをスキップできない。Kubelet は API サーバーよりも新しくできない。アドミッションウェブフックは、新しいサーバーが送信するリソースとフィールドを理解する必要がある。ディストリビューションは、上流プロジェクトが独立して変化する間に、組み合わせを選択してテストしなければならない。
SUSE の商業的な貢献は、部分的には「ノー」と言う決定にある。修正をバックポートし、互換性のあるビルドを公開し、顧客に既知のターゲットを提供できる。サポートマトリックスはまた、オペレーターに対して、除外がそのターゲットから逸脱した時を知らせる。プライベートレジストリの設定、変更されたパッケージ、サポートされていない CNI、またはサポート終了したマイナーバージョンはまだ動作するかもしれないが、顧客は診断のより多くを負担する。
これは有用な規律を生み出す。プラットフォームチームは、すべてのクラスターを有限のマトリックスに対してインベントリし、「おそらく問題ない」を明示的な例外リストに変換できる。例外の経過期間、所有者、削除日を測定できる。ビジネス価値が永続的なテストを正当化しない場合、新しいローカルのバリエーションを拒否できる。マトリックスは、システム群が成長するにつれてより価値が高まる。なぜなら、承認された 1 つの組み合わせのコストが、多くの繰り返されるクラスターに分散できるからだ。
それはまた、微妙な種類のロックインを生み出す。SUSE のテストされた範囲に依存する顧客は、SUSE のリリースケイデンス、非推奨の選択、パッケージングに従わなければならない。Rancher 2.14 は、Kubernetes 1.32 のサポートを削除し、組み込みの Cluster API 実装を Rancher Turtles に置き換えた。Fleet は新しい Helm 世代に移行した。将来のチャート保持ポリシーは、新しいブランチで古いアプリケーションチャートのバージョンの表示を停止する。これらは健全な保守の決定かもしれないが、顧客はそのタイミングを制御できない。
それらの決定に従うコストが、同等の検証機能を内部で維持するよりも低い場合、サブスクリプションは価値がある。顧客のシステム群が非常に珍しく、重要な組み合わせのほとんどがマトリックス内に残らない場合、それは弱い。その場合、企業はサポートされた中心部を購入し、サポートされていない周辺部を運用していることになる。
Rancher のアップグレードは、パッケージの置き換えではなく、制御された移行である
現在のRancher アップグレードガイドは、マイナーバージョン間のテストされサポートされた唯一のパスを定義している: 現在のマイナーの最新パッチから次のマイナーの最新パッチへ移行すること。2.11 のチームは直接 2.14 にジャンプすることはできない。まず最新の 2.11 パッチに到達し、その後 2.12 と 2.13 を順番に通過し、各リリースのノートとサポートステータスを確認する必要がある。
このルールは、放置を複合的な作業に変える。プラットフォームが 1 年スキップすると、欠落したセキュリティ修正が蓄積されるだけではない。中間のデータ変換、チャートの変更、削除された Kubernetes バージョン、期限切れのサポートウィンドウが蓄積される。各ホップには準備、実行、検証、続行の決定が必要である。保守を延期するという一見安価な決定は、期間が不明な将来のウィンドウから時間を借りていることになる。
このガイドは、オペレーターに対して、Rancher を実行する Kubernetes クラスターをバックアップし、チャートリポジトリを更新し、機能チャートのバージョンを調べ、Helm アップグレードを実行し、デプロイメントを確認するように指示している。エアギャップインストールでは、最初に新しいリリースのイメージをプライベートレジストリに取り込む必要がある。これらの手順は簡単だが、状態遷移は 1 つのデプロイメントに限定されない。Rancher は、クラスター、ユーザー、権限、カタログ、管理機能のためのカスタムリソースを保存している。インストールされたチャートと下流エージェントには独自の互換性がある。外部 ID とクラウド認証情報は、変更されたプロバイダーに対して失敗しても構文的には有効であり得る。
リリースノートは、アップグレード手順が汎用的でありえない理由を示している。2.14 リリースラインでは、Cluster API マネージャーが変更され、Fleet ベースのアドオンプロバイダーがデフォルトで無効化され、Fleet が Helm 3 から Helm 4 に移行され、いくつかの既知のリカバリと認証の制限が継続された。2.13.1 のノートでは、チャート名の変更がアップグレードの複雑化を引き起こしたため、SUSE がよりスムーズな経路を準備する間、既存顧客は古い名前を維持することを推奨し、OIDC 設定がアップグレード中に失われる可能性があるケースや、エアギャッププロビジョニングの欠陥により Cluster API コントローラーがアクティブにならないケースも開示された。
これらは、すべての Rancher アップグレードが失敗する証拠ではない。リリース固有のレビューが製品の一部であることの証拠である。サポートの価値は、顧客が遭遇する前にそのような例外を収集することに部分的にある。オペレーターのタスクは、いずれかがシステム群に適用されるかを特定し、代表的な環境で移行を再現し、既知の問題が本番インシデントになる前に停止することである。
検証は、Rancher ポッドが準備完了になるだけでは不十分だ。管理サーバーは健全でも、下流エージェントがチェックインできない、ID グループが正しくマッピングされない、Fleet が間違ったクラスターをターゲットにする、またはクラウドドライバーが停止することがある。公開されているRancher イシューには、RKE2 と RKE1 クラスターが非アクティブのままで、Fleet チャートのインストールが失敗し、チーム間の作業が必要になった過去のアップグレードが記録されている。1 つのイシューは頻度について何も語らない。これは、「Rancher が稼働している」と「システム群が管理可能である」が別個の事後条件である理由を示している。
したがって、本格的な受け入れテストでは、運用権限を生み出すユーザージャーニーをたどるべきである: 各 ID プロバイダーを通じてサインインし、正しいロールでクラスターを列挙し、無害な Fleet 変更を調整し、廃棄可能なノードをプロビジョニングし、ログを取得し、下流のスナップショットを取得し、アラートが到着することを確認する。そうして初めて、コンテナではなく管理機能が戻ったことになる。
ロールバックは複数の時計を持つ復元である
Rancher のドキュメントは、購入者が保持すべき正確な言葉を使用している。Helm やkubectlを使用した古い Rancher バージョンへの変更はサポートされていない。ロールバックとは、古いバージョンで作成されたバックアップを復元し、その古いバージョンを再起動することを意味する。移行先は依然としてサポート対象でなければならない。
これはパッケージの取り消しとは異なる。アップグレードはカスタムリソースを変換し、コントローラーを置き換え、新しい形式のレコードを作成できる。コンテナが起動しても、古いコードをその新しい状態に対して実行するのは安全でない場合がある。復元は管理データを以前の時点に戻す。つまり、バックアップ後に行われた変更が失われる可能性がある。オペレーターは、その損失が許容可能かどうか、また Rancher の外で変更が続いたものを調整する方法を決定しなければならない。
Rancher 2.14 は具体的な例を提供している。その Cluster API 依存関係により、カスタムリソースがある API バージョンから別の API バージョンに移動された。新しいカスタムリソースを含むクラスター上で古いバックアップデータを復元する場合、それらのレコードが存在する間は古い定義が単純に新しいものを置き換えることはできない。ロールバックガイドは追加のクリーンアップを規定している。これは、Kubernetes 形式で露出された通常の分散データ問題である: ソフトウェアバージョンと保存された表現は一緒に移動しなければならない。
完全な SUSE システム群には少なくとも 4 つのリカバリ時計が存在する。
1 つ目は Rancher 管理アプリケーションである。Rancher バックアップオペレーターは、ローカル管理クラスター内で実行され、Rancher アプリケーションをバックアップする。すべての下流クラスターをバックアップするわけではない。そのリソースセットは事前定義されており、現在のドキュメントでは、Fleet リポジトリによって参照される特定のシークレットは、別途処理されない限り含まれないと警告されている。
2 つ目は各下流 Kubernetes コントロールプレーンである。Rancher が作成した RKE2 および K3s クラスターの場合、スナップショットには etcd データ、Kubernetes バージョン、クラスター設定を含めることができる。すべての etcd ノードが失われた場合にローカルスナップショットが消えるため、SUSE は外部の S3 互換ターゲットを推奨している。etcd を復元すると、Kubernetes オブジェクトとクラスター設定が戻る可能性がある。別の場所に保存されたアプリケーションバイトが必ずしも戻るわけではない。
3 つ目は永続的なアプリケーションデータである。Longhorn には独自のボリュームスナップショットとリモートバックアップがある。外部アレイ、クラウドディスク、マネージドデータベースには異なるメカニズムがある。データベースポッドが存在すべきという Kubernetes オブジェクトは、データベースのトランザクション整合性のあるコピーではない。リカバリはコントロールプレーンの時間とデータの時間を揃える必要がある。
4 つ目は外部状態である: DNS、クラウドインスタンス、ロードバランサー、ID グループ、レジストリコンテンツ、証明書、および他のシステムを通じて作成されたレコード。Rancher を火曜日に復元しても、クラウドロードバランサーが水曜日を忘れるわけではない。Fleet は、水曜日のデータを含むクラスターに火曜日の望ましい状態を再適用する可能性がある。完全なロールバックは、時計を超えた調整作業であり、1 つのボタンではない。
バックアップ自体にも依存関係がある。SUSE の詳細な使用ガイドでは、バックアップ暗号化が設定されていない限り、機密値が平文で保存される可能性があり、暗号化設定はオペレーターがバックアップしないため別途保存する必要があると述べている。アーカイブを暗号化して鍵を失うチームは、リカバリを不可能にすることで機密性を達成したことになる。
したがって、適切なテストはバックアップ成功イベントではなく、復元ドリルである。既知のワークロードトランザクションから始め、管理状態とアプリケーション状態を変更し、管理環境を削除し、許可されたトポロジーに復元し、別途保持されたシークレットを再作成し、古い状態と新しい状態の両方を検証する。人間の分単位の時間と経過時間を測定する。バックアップファイルは準備の証拠である。復旧されたサービスはリカバリの証拠である。
RKE2 は、システム群の準備ができているかを判断せずにノード作業を自動化できる
RKE2 は、Kubernetes のインストールとアップグレードを、より再現可能なディストリビューションタスクに変える。その手動手順では、オペレーターに対して、サーバーノードをエージェントより前に一度に 1 つずつアップグレードするよう指示している。安定版、最新版、バージョン固有のチャネルを提供している。また、このプロセスでは、サポートされていない Kubernetes バージョンの変更からオペレーターを保護するものは何もないと警告している。
system-upgrade-controllerは、より多くの反復を排除する。Plan はノードとターゲットバージョンを選択する。コントローラーは特権ジョブをスケジュールし、ジョブが終了するとノードに完了ラベルが与えられる。メンテナンスウィンドウは新しいジョブの開始を制限できるが、既に作成されたジョブはウィンドウが閉じた後も続く可能性がある。
これは有用な自動化である。これがなければ、エンジニアはホストにログインし、パッケージやバイナリを置き換え、サービスを再起動し、メンバーシップを監視し、シーケンスを繰り返す必要がある。コントローラーは順序を強制し、進捗を可視化できる。フリートスケールでは、同一作業の多くの時間を削減できる。
しかし、ワークロードが生き残るかどうかは判断しない。ノードジョブが完了したことは、その層で規定された操作が正常に終了したことを証明する。PodDisruptionBudget が正常なドレインを許可したこと、ストレージレプリカが再構築されたこと、アドミッションウェブフックが新しいオブジェクトを受け入れること、アプリケーションがレイテンシー目標を満たすこと、または古いクライアントがまだ動作することを証明するわけではない。これらの事後条件は他のシステムに属する。
コントローラーの権限はリスクを示している。SUSE は、ホスト名前空間へのアクセス、再起動の許可、ホストルートの読み書きマウントを文書化している。これはノードメンテナンスには適切であり、コントローラーをシステム群の最も信頼性の高い領域の一部にする。したがって、Plan の作成、イメージの出自、ターゲットの選択、変更の承認は、通常のアプリケーションデプロイメントよりも強力な制御を受けるに値する。
ダウングレードには別の鋭いエッジがある。Kubernetes は、コントロールプレーンコンポーネントのその場でのダウングレードをサポートしておらず、SUSE は RKE2 アップグレードイメージが Plan が古いバージョンをターゲットにするのを防がないと述べている。有効なリカバリは、古いバイナリと、それで読み取り可能であることが分かっているデータストアスナップショットを組み合わせる。自動化は指示を実行できるが、無効な指示を安全にすることはできない。
この区別は、能力と信頼性を分ける。基盤となる Kubernetes テクノロジーは、定義された相違内でのローリングコンポーネント置換をサポートしている。RKE2 はコンポーネントをパッケージ化し、ノード操作を自動化する。製品の信頼性は、コントローラー、イメージ、順序付け、および可観測性が機能していることに依存する。デプロイメントの結果は、顧客のワークロード、中断予算、データシステム、リカバリの実践に依存する。顧客の証拠が最後の部分をカバーしていない限り、自動アップグレードに関するベンダーの声明は主に中間層に適用される。
Fleet は普通のことを安価にし、ミスを拡大可能にする
Fleet は別の反復的なタスク、つまり多くのクラスターにアプリケーションと設定を適用することに対処する。望ましい状態は Git に存在する。Fleet はリポジトリコンテンツをバンドルに変換し、クラスターをターゲットにし、エージェントを通じてリリースを適用する。プラットフォームチームは、クラスターをグループ化し、ロールアウトを分割し、昇格前に一時停止し、利用できないターゲットの数を制限できる。
これらの制御は作業を変革できる。エンジニアは、同じリソースを編集するために 200 のエッジサイトを訪問する必要がなくなる。変更はカナリアグループ、地域パーティション、そして残りのシステム群へと移動できる。リポジトリは意図を記録する。ステータスはどのクラスターがそれを受け入れたかを明らかにする。これは、準備された環境が数日ではなく数分で出現できるという顧客の主張の背後にあるメカニズムである。
Fleet 設定リファレンスは、難しい選択も明らかにする。ドリフト修正はオプションである。通常の修正は Helm のマージ動作を使用するが、強制修正はリソースを削除して再作成できる。失敗したロールバック履歴は、保持が有効になっていない限り破棄される可能性がある。依存関係はバンドルを順序付けることができるが、それはオペレーターが依存関係をモデル化した場合のみである。デフォルトのロールアウトしきい値は、重要なシステム群には寛容すぎる可能性がある。
ドリフトは常にエラーとは限らない。インシデント対応者は、サイトを稼働させ続けるためにレプリカ数、ネットワークポリシー、またはイメージを変更することがある。自動修正は、その緊急アクションが Git に記録される前にそれを消去できる。修正をオフにするとアクションは保持されるが、システム群が分岐することを許す。優れた運用モデルでは、所有者、理由、有効期限、調整計画を記録する非常時用の経路が必要である。
トラブルシューティングは分散されたままである。Fleet の独自のガイドでは、コントローラーログ、リポジトリジョブ、バンドル数、コミット状態、ターゲットクラスター内のエージェントを調べるようオペレーターに指示している。リポジトリはタイムアウトや衝突の後に同期を停止することがある。バンドルは、コントローラーが 1 つのフィールドを継続的に書き換えるため、変更されたままになることがある。クラスターは利用できない場合がある。高負荷時には、デフォルトの衝突再試行回数 1 では不十分な場合がある。
Fleet の成功指標は「コミットが確認された」であるべきではない。受け入れられる単位は、意図されたリソースが正しいクラスターに到達し、ヘルスチェックに合格し、アプリケーションの動作が許容範囲内に留まり、例外が可視化されているバンドルである。ターゲット数は分母に含めるべきである。999 サイトが更新され、1 つの切断されたサイトがひっそりと脆弱なままである場合、ダッシュボードのパーセンテージは優れているように見えても、最も露出した場所は変わらない。
ここが SUSE が真のレバレッジを生み出せる場所である。Rancher は共通のインベントリとアイデンティティ層を提供し、Fleet は反復的な配信メカニズムを提供し、サポートは製品の欠陥とターゲット固有の問題を区別するのに役立つ。レバレッジは、クラスターがテスト済みの形状を共有する場合に最も強くなる。独自のチャートオーバーライド、ローカルラベルの慣例、緊急時の変更が増えるごとに、それは減少する。
Longhorn はアップグレードの非対称性を無視できなくする
ストレージは、「ロールバック」のような安心させる言葉が危険になる場所である。ステートレスなコントローラーはしばしば再デプロイできる。ボリュームは、チャートから再構築できないアプリケーション履歴を含んでいる。
Longhorn の現在のアップグレードポリシーでは、一度に 1 つのマイナーバージョンのみが許可されている。1.5 から 1.6 への移行はサポートされているが、マイナーバージョンを飛び越えることはサポートされていない。アップグレード前チェックは無効なパスを拒否する。新しいリリースへのアップグレードが成功すると、ダウングレードはサポートされない。成功完了前の Helm ロールバックは、データとカスタムリソースが先に進んだ後に古いストレージエンジンを実行することと同じではない。
SUSE Storage の重要な注意事項は、安全性のケースをより具体的にしている。新しいリリースでは、スナップショットコンポーネントが変更されたため、最小の Kubernetes バージョンが必要である。自動化されたチェックはすべてのシナリオをカバーしていない。オペレーターは、障害が発生したボリュームのアップグレードを避け、新しいデータエンジンを使用するボリュームをデタッチし、システムバックアップを作成するよう指示されている。失敗したバッキングイメージや使用不能なレプリカは、リモートバックアップが存在しない場合、クリーンアップを永久的なデータ損失に変える可能性がある。
これらの制約は、プロジェクトに自動化が欠けていることの兆候ではない。それらは、ストレージの状態に方向性があることの証拠である。新しいエンジンは古いエンジンが解釈できないメタデータを書き込む可能性がある。新しいカスタムリソースバージョンは元に戻せないかもしれない。2 つの良好なコピーが存在する場合には無害なレプリカの再構築が、残りのコピーが破損している場合には致命的になり得る。
通常のパスは依然として効率的であり得る。事前チェックは明らかなバージョンスキップと不健康な状態をキャッチする。標準的なクラスターは、コンポーネントを順番にドレインして更新できる。共有サポートマトリックスは、Kubernetes とストレージバージョンの不確実性を低減する。オペレーターはもはやすべてのコマンドを考案する必要はない。
例外パスは依然として人間の手に委ねられている。誰かが、劣化したボリュームを修復しても安全か、スナップショットがアプリケーション整合性を持っているか、リモートバックアップが最新か、ビジネスがデタッチに耐えられるかを決定しなければならない。アップグレード後、誰かがアプリケーション層でバイトを検証しなければならない。「すべてのボリュームが健全」というのは、データベースが最新のコミット済みトランザクションを読み取れることの証明ではない。
これはスイート全体の経済性を変える。顧客が Longhorn、Rancher、RKE2 を一緒に選択する場合、より一貫性のあるサポートされた組み合わせを得る。また、いくつかのライフサイクル決定を 1 つのベンダーのリリースケイデンスに集中させる。外部ストレージプラットフォームを維持する場合、別のサプライヤーと互換性の境界を保持するが、既存の運用専門知識を保持する可能性がある。普遍的な答えはない。関連する尺度は、保護されたワークロードあたりのリカバリ作業であり、ドリルを含み、ストレージインストール速度ではない。
SLES はライフサイクルを延長するが、サービスパックは依然として期限を生み出す
SUSE の Linux の伝統は、異なる種類のライフサイクル価値を提供する。SLES は 13 年間のメジャーリリースライフを宣伝している: 10 年間の一般サポートと 3 年間の延長サポート。その見出しは、マシンを変更せずに放置する許可のように聞こえる可能性がある。詳細なポリシーはより規律正しい。サービスパックは約 12〜14 か月ごとに到着する。通常、前のサービスパックは次のパックの後 6 か月間のサポートを受ける。長期サービスパックサポートはより多くの時間を購入できるが、延長フェーズでは対象となる新しいデプロイメント、機能強化、修正が狭まる。
SLES 15 SP6 アップグレードガイドでは、サポートされるパスでの限定的なサービスパックスキップのみが許可されている。古いシステムには中間リリースまたは LTSS 資格が必要である。また、このガイドは OS パスが必ずしもアプリケーションパスではないことも警告している: Linux がさらに進めても、データベースは中間バージョンを必要とする場合がある。
これは商業的に理にかなっている。企業は、アプリケーションのベンダーがオペレーティングシステムの認定をゆっくりと行うアプリケーションを実行している。SUSE は、顧客が次のサービスパックをテストする間、セキュリティ修正をバックポートし、サービスパックを存続可能に保つことができる。これにより、緊急移行が計画的なプロジェクトに変換される。顧客は時間とエンジニアリングの継続性に対して支払う。
時間は作業がないことと同じではない。バックポートは、パッケージのバージョン番号が同じ修正を含む上流バージョンに似ていない可能性があることを意味する。セキュリティチームは、単純なバージョンスキャナーではなく SUSE アドバイザリーを使用しなければならない。LTSS は購入し、有効化し、追跡する必要がある。モジュールと拡張機能には依存関係がある。長期サービスパック上のサーバーは、新しいハードウェア、ソフトウェア、スタッフの経験と比較して徐々に特異になりながらも、安全を保つことができる。
SLES はまた、有用なローカルリカバリを提供する。デフォルトの Btrfs ルートレイアウトでは、Snapper は変更前のスナップショットを作成し、以前のルート状態を起動できる。サービスパックのロールバック手順は、オペレーターに読み取り専用の以前のスナップショットを検査し、ロールバックを永続的にし、リポジトリ登録を修復する方法を提供する。
限界は重要である。SUSE のSnapper ドキュメントでは、完全な同一のシステム復元は不可能であると述べている。ルートサブボリュームのみが戻る。除外された場所はそのまま前進する。古いコードが新しい形式で書かれたデータに出会ったり、所有権が変更されたりすると、アプリケーションが壊れる可能性がある。スナップショットは同じファイルシステム上に存在し、スペースを消費する。ロールバック後に登録が調整されていない場合、間違ったリポジトリを指す可能性がある。
カーネルライブパッチは一部のメンテナンスウィンドウを狭めるが、再起動をなくすわけではない。SUSE は、ライブパッチは技術的に可能な場合に適格な重要修正をカバーするが、正確なカーネルリビジョンに関連付けられており、通常のカーネル更新と再起動までの一時的な措置であると述べている。データ構造の変更はライブで適用できない場合がある。
したがって、SLES は時間の停止ではなく、信頼できるサポート滑走路を提供する。その経済的価値は、ダウンタイムが高くつき、認定が遅く、顧客がパッチ適用を標準化するのに十分な類似システムを持っている場合に最も高くなる。迅速にプロバイダーイメージ上で再構築できる使い捨てのクラウドワークロードや、アプリケーションが既により高速なプラットフォームケイデンスを必要とするチームにとっては低くなる。
エアギャップ運用は、クラウド依存を在庫作業に置き換える
非接続運用は、SUSE が存在する最も強力な理由の 1 つである。パブリッククラウドのコントロールプレーンは顧客からメンテナンスを取り除くことができるが、すべての防衛、産業、通信、または規制対象環境にサービスを提供できるわけではない。Rancher、RKE2、K3s、SLES は、顧客がマシンとレジストリを制御する場所で実行できる。
その自由には具体的なコストが伴う。エアギャップ Rancher インストールの場合、オペレーターはリリース固有のイメージリストと保存/ロードスクリプトをダウンロードし、必要に応じて証明書管理イメージを追加し、接続されたワークステーションでセットをプルし、承認された境界を通じてアーカイブを移動し、プライベートレジストリに取り込む。Windows および ARM デプロイメントはバリアントを追加する。すべてのリリースで部品表が変わる。
公開アーティファクトはこの領域を測定可能にする。安定版 Rancher v2.14.2 のrancher-images.txtを直接静的チェックしたところ、760 のユニークな非空イメージ参照が見つかった。v2.14.3 リストには 856 が含まれており、前のパッチと比較して 126 の追加と 30 の削除があった。イメージリストと Linux ダイジェストリストの公開チェックサムは、ストリーミングされたファイルと一致した。
これらの数字は、実行中の最小 Rancher サーバーのコンテナ数ではない。このリストは、インストール、クラスタープロビジョニング、オプションの Rancher ツールをカバーしている。また、カウントはバイト数や転送時間を明らかにしない。これらは、「エアギャップをサポート」が二値の機能ではない理由を示している。顧客は、どのアーティファクトが必要かを決定し、それらをダイジェストと署名とともにミラーリングし、スキャンまたは承認し、ソースを保持し、プライベートレジストリ参照をテストし、どのコンポーネントも利用できないパブリックエンドポイントに到達しないことを証明しなければならない。
省略されたイメージは、最悪の瞬間まで現れない可能性がある。管理サーバーは正しくアップグレードされても、後のノード置換でミラーリングされなかったバージョンが要求される場合がある。監視チャートはコアリスト外のイメージを使用するかもしれない。エッジサイトは適切なイメージを持っていても、有効期限切れのレジストリ認証情報を持っているかもしれない。通常のアップグレードは接続されたラボでは成功しても、供給状態が異なるため非接続サイトでは失敗する。
SUSE Prime は、信頼できるレジストリ、署名済みアーティファクト、ソースとオリジンリスト、既知のインベントリを通じてこの作業を削減できる。しかし、顧客のセキュリティ境界を越えてバイトを運んだり、ローカルポリシーの下でそれらを承認したりすることはできない。顧客は依然として、プライベートレジストリの容量計画、保持、認証情報、災害復旧を所有している。ノード再構築中にそのレジストリがダウンしている場合、ローカル主権はローカルのクラウド依存を生み出している。
適切な分母は、例外を含むリリースごとに調整されたイメージとクラスターである。転送されたバイト数、承認時間、デプロイ前に見つかった欠落アーティファクト、変更中の失敗したプル、パブリックアクセスが削除されたサイトの再構築時間を測定する。そうして初めて、顧客はエアギャップ Rancher を、運用上は安価だが法的または物理的に利用できないマネージドクラウドと比較できる。
有償サポートは、保証された復旧時間ではなく、アクセスと優先順位付けを購入する
サポート契約は、公開証拠からは最も再現が難しい製品部分である。SUSE は有用な条件を公開している。Rancher Prime サポートでは、Standard 顧客には重大なケースで目標初期応答時間が 2 営業時間、Priority 顧客には 1 時間であり、カバレッジ時間が異なる。SUSE はまた、アップグレードパスの検証、サポート可能性レビュー、待機支援を宣伝している。
「初期応答」が重要なフレーズである。これは診断、回避策、パッチ、または復旧までの時間ではない。1 時間の確認応答でも、問題が Rancher、上流コントローラー、クラウドプロバイダー、顧客の設定にまたがる場合、長いインシデントにつながる可能性がある。逆に、経験豊富なエンジニアは、契約上許容される時間が長くても既知の欠陥を迅速に解決できる。
サポートは、見逃しやすい方法で価値を生み出す。エンジニアは、顧客が分離するのに数日かかる故障のサインを認識するかもしれない。SUSE は独自のサポートマトリックスを解釈し、アップグレード前に設定を変更する必要があるかどうかを助言できる。自らが保守するプロジェクトでの修正を調整できる。古い商用リリース用の重要なパッチを利用可能に保つことができる。指名されたアカウントチームは、危機の前に顧客が規律を維持するのを支援できる。
また、サポートは作業も導入する。ケースには診断、ログ、再現、重大度の正当化、応答可能な顧客担当者が必要である。機密環境ではログの持ち出しが許可されない場合がある。故障は、SUSE が所有しているかどうかを特定するのに十分なまでに縮小しなければならない。顧客は通常、変更を実行し、ビジネスサービスを検証する。エスカレーションは作業を組織間で移動させるが、作業を消滅させるわけではない。
公開価格例は、決定の枠組みを提供するが完成はしない。SUSE のRancher Prime ショップでは、調査時点で、1〜2 ソケット、最大 64 コアユニットの 1 年間の Standard サブスクリプションが$6,525、より小さい 2 コアまたは 4vCPU ユニットが$2,175 と表示されていた。小さいユニットの Priority は$2,900 だった。これらは記載された希望小売価格の例であり、異種混合のフリートに対する見積もりではない。契約単位、最低額、アドオン、割引、エンタープライズ条件が総額を変える可能性がある。
サブスクリプションは分子の 1 つに過ぎない。Rancher 管理クラスター、プライベートレジストリ、監視、バックアップストレージ、Longhorn 容量、実装、トレーニング、テスト環境、プラットフォームエンジニアを追加する。バージョンを最新に保つ作業を追加する。次に、プラットフォームが真に取り除く労働、回避された停止、延期された移行を差し引く。エンジニアがダッシュボードアクションの準備と検証に同じ時間を費やす場合、ダッシュボードアクションを節約された労働としてカウントしない。
サポート契約は、他の方法では数日間にわたって複数のシニアエンジニアを消費する稀なアップグレードや、バックポートが急いだ移行を回避するセキュリティ修正など、コストのかかるテールを短縮する場合にその価格を稼ぐ。公開証拠はその分布を明らかにしない。購入者は、重大度と製品別の匿名化された解決統計、同様のトポロジーを持つ更新参照、購入前のスコープ付きアップグレード検証を要求すべきである。
顧客事例はレバレッジを証明するが、一般的な信頼性率ではない
SUSE は、通常の作業がより速くなるという信頼できる例を公開している。ドイツの IT プロバイダーECKD は、スクリプトがあってもかつて約 4 時間かかっていたリリースデプロイメントが、Rancher Prime と Kubernetes で約 15 分に短縮されたと述べている。同じ顧客事例では、SUSE カスタマーサクセスが緊急の問題に対処するのに役立ったとも述べている。その組み合わせはもっともらしい: 標準化と反復的な自動化が確立されたパスを圧縮し、人的サポートが例外を処理する。
Armedia はさらに大きな削減を説明している。SUSE がホストするインタビューで、企業リーダーは、アプリケーションのためのインフラストラクチャの準備が、クラウドとオンプレミス環境にわたって Rancher と Fleet を使用して 7〜14 日から約 12 分に短縮されたと述べている。これは舗装されたパスにとって有用な証拠である。プラットフォームの設計、統合、セキュリティ確保、保守に 12 分かかったことを意味するものではない。
ポーランドの保険会社 PZU は、より関連性の高いライフサイクルの例を提供している。SUSE のケーススタディでは、PZU が古い Kubernetes プラットフォームに技術的負債が蓄積された後、エアギャップのオンプレミス環境で Rancher Prime を採用し、現在ではライブ本番システムのダウンタイムなしでコンテナをアップグレードできると述べている。表現はクラスターアップグレードのベンチマークよりも狭い。Kubernetes、ストレージ、管理プレーンのアップグレードが依然として困難な一方で、アプリケーションコンテナの更新は日常的であり得る。
これらの公開アカウントはいずれも、信頼性の主張に必要な分母を提供していない。すべての試みられた変更、介入、ロールバック、停止、サポートケース、スタッフ時間を公開していない。Rancher を Kubernetes、新しい運用慣行、ハードウェア交換、アプリケーション再設計から分離していない。それらはベンダーによって選択されている。
独立した報告は、ベンチマークを生み出すことなく、有用なカウンターウェイトを追加する。2023 年のTechTarget レポートは、内部チームがより多くの専門知識を開発した後に、マルチクラスター管理のためにオープンソース Rancher を保持したが、有償サポートを離れた 1 社について説明した。1 人の顧客は解約率を確立できない。それは商用オープンソースに最も関連性の高い代替手段を示している: 別の製品ではなく、より有能な内部チームによって運用される同じソースコードである。
バランスの取れた結論は、SUSE が繰り返される標準化されたタスクで大きな利益を生み出せるということである。公開証拠は、まさにサブスクリプションが最も重要であるはずの場所、つまり失敗した変更、深いエスカレーション、リカバリにおいて最も弱い。このギャップは信頼性を低下させるべきだが、文書化された利益を消し去るものではない。
代替手段は作業を異なる所有者に移す
コミュニティ運用は最も近い代替手段である。顧客は公開プロジェクトから Rancher、RKE2、K3s、Fleet、Longhorn を実行し、インテグレーターからサポートを購入するか、独自の検証を構築できる。これは SUSE のサブスクリプションコストを回避し、タイミングをより制御できる。上流の変更を追跡し、欠陥を再現し、アーティファクトを保守し、組み立てられた結果を所有するベンダーがいないことを受け入れることができるスタッフが必要である。
マネージド Kubernetes は、コントロールプレーンをハイパースケーラーに移動する。Amazon EKS は、Kubernetes マイナーに対して 14 か月の標準サポートと、さらに 12 か月の有償延長サポートを提供し、最終的にはコントロールプレーンをアップグレードする。そのドキュメントでは、依然としてアドオンと多くのノードが顧客に委ねられている。Azure AKS は自動チャネルと計画メンテナンスを提供するが、4 時間以上のウィンドウを推奨しており、依然として中断予算、ノードイメージ、オペレーターの実践に依存している。
これらのサービスは、既に 1 つのクラウドにコミットしているチームにとってはより安価になる可能性がある。なぜなら、プロバイダーがコントロールプレーンマシンを運用し、アイデンティティ、ネットワーキング、サポートを統合するからである。非接続サイト、マルチクラウドの一貫性、プロバイダー境界を受け入れられない顧客にとっては弱くなる。Rancher を使用して EKS または AKS を管理することは、両方のベンダーのライフサイクルルールを保持しながらインベントリを統一できる。それらを 1 つのスタックに変えるわけではない。
Red Hat OpenShift は、最強のエンタープライズディストリビューション代替手段である。オペレーティングシステム、Kubernetes、オペレーター、更新サービスをより密接に統合している。OpenShift の更新グラフは推奨パスと条件付きリスクを公開している。これにより、より意見の強いテスト済みユニットを顧客に提供できるが、自由度は低く、大きな移行とサブスクリプションのコミットメントを必要とする。その存在はまた、狭いアップグレードパスが責任あるエンタープライズ Kubernetes の特徴であり、SUSE の弱点の証拠ではないことを示している。
より小規模なプラットフォームでは、kubeadm、Kubespray、Talos、Canonical Kubernetes、または別のディストリビューションを使用し、Fleet の代わりに Argo CD または Flux を選択できる。最良のオプションは既存のスキルと制約に依存する。Rancher は、顧客が多数のインフラプロバイダーにわたる 1 つのビューを必要とし、比較的オープンな管理層を望む場合に魅力的である。ほぼすべてのワークロードが単一のクラウドのマネージドサービスに適合する場合や、企業が既にクラスターを使い捨てとして扱う成熟した内部プラットフォームを持っている場合には、あまり魅力的ではない。
切り替えコストはデータ形式だけに存在するわけではない。Kubernetes リソースは原則として移植可能だが、Rancher のロール、Fleet のターゲティング、カスタムチャート、RKE2 の設定、Longhorn ボリューム、SLES の自動化、プライベートレジストリの手順、スタッフの習慣は意味を蓄積する。移行は YAML を保持しても、新しいアイデンティティモデル、ストレージの移動、監視設計、インシデントの実践を必要とする可能性がある。
移植性をテストする方法は、それを実行することだ。アプリケーションを再構築せずに、1 つの代表的なクラスターを Rancher 管理から外す。そのアクセス制御と監視を別の場所で調整する。1 つの Fleet 管理アプリケーションを別の配信ツールに移動する。1 つの Longhorn バックアップサービスを別のストレージシステムに復元する。運用に必要なインベントリと監査証拠をエクスポートする。その労力は、ソースコードのライセンスよりも優れたロックインの尺度である。
経済単位はサポートされた月と許容された変更である
SUSE のポートフォリオは、2 つのリンクされた分母を通じて測定されるべきである。
1 つ目は、サポートされたクラスター月またはサーバー月である。セキュリティサポートされた OS、Kubernetes、Rancher、ストレージの組み合わせの上に留まっているすべての管理対象システムをカウントする。マトリックス外の期間、期限切れの認証情報、欠落したアーティファクト、テストされていないリカバリの期間を差し引く。この分母は、商用ディストリビューションが実行することになっている地味な作業に報いる。
2 つ目は、許容された変更である。パッチ、サービスパック、Rancher マイナー、Kubernetes マイナー、Fleet バンドル、またはストレージアップグレードは、意図されたバージョンがアクティブであり、アプリケーションがサービステストに合格し、データが一貫性があり、アクセスが依然として機能し、リカバリポイントが有効である場合にのみカウントされる。コントローラーの完了ラベルは中間イベントである。
分子には、サブスクリプション、インフラストラクチャ、すべての人的作業を含めるべきである。準備には、バージョン発見、リリースノートのレビュー、互換性チェック、イメージのミラーリング、承認が含まれる。実行には、ドレイン、再起動、観測が含まれる。例外処理には、サポートケース、回避策、再試行が含まれる。リカバリには、管理、コントロールプレーン、アプリケーション状態の復旧が含まれる。維持には、テスト環境を代表的に保ち、ローカルのバリエーションを取り除くことが含まれる。
中央値を報告するが、それがテールを隠さないようにする。標準的な自動化は 95 件の通常のデプロイメントを 4 時間から 15 分に短縮するかもしれない。5 つの例外がそれぞれ数人を数日間消費する場合、依然として年間コストを支配する可能性がある。結果によって失敗を重み付けする: 1 つの誤ったストレージリカバリは、多くの高速なステートレス更新によって相殺されない。
類似のものを比較する。マネージドクラウドの価格にはコントロールプレーンの運用が含まれるが、ネットワーク、延長バージョン、プロバイダーサポート料金が追加される可能性がある。コミュニティソフトウェアにはサブスクリプションがないが、より多くの内部エンジニアリングが必要である。OpenShift はより多くのコンポーネントをバンドルし、統合の選択肢を減らす一方でコミットメントを増やすことができる。古い仮想マシンのプロセスは遅いかもしれないが、既に償却され、馴染みがある。
労働の転送は明示的であるべきである。Rancher はホストごとの作業を排除し、プラットフォームポリシー作業を生み出すことができる。Fleet は繰り返されるアプリケーション編集を排除し、リポジトリ、ターゲティング、例外作業を生み出すことができる。SLES のバックポートは、急いだアプリケーション移行を排除し、ライフサイクル追跡を生み出すことができる。サポートは一部の診断を排除し、ケース調整を生み出すことができる。これらの転送は優れた取引かもしれないが、排除と呼ぶことは、システムを安全に保つために必要な人員を曖昧にする。
購入者はクリーンインストールではなく、失敗から始めるべきである
この調査のために直接の SUSE デプロイメントは利用できなかった。製品は、稼働時間、アップグレード期間、サポート、総コストについてスコアリングされなかった。信頼できる評価は、代表的なシステム群と意図的に不都合なケースから始まるだろう。
少なくとも 24 のクラスターを使用する: HA データセンターRKE2、小規模な K3s エッジ、1 つのパブリッククラウドサービス、非接続グループ。OIDC、プライベートレジストリ、Fleet、ステートフル Longhorn サービス、外部ストレージクラス、監視、アドミッションウェブフック、実際の中断予算を含める。合成データと隔離されたアカウントを使用する。
通常のパッチ変更と逐次的なマイナーアップグレードを事前登録し、その後、通常はデモンストレーションから逃れる失敗を追加する: 1 つの欠落したエアギャップイメージ、期限切れのレジストリ認証情報、新しいリソース形式を拒否する Webhook、中断予算によってブロックされたドレイン、誤ったラベルを持つ Fleet ターゲット、障害が発生したボリューム、満杯のスナップショット場所、オフラインのエッジサイト、変更されたアイデンティティプロバイダー証明書、カスタムリソース変換を跨ぐロールバック。
コミュニティ運用、Rancher Prime、最も信頼できるマネージドまたはエンタープライズの代替手段を比較する。正確なバージョンとアーティファクトを固定する。すべての再試行と人的介入をカウントする。エンジニアが失敗を見た後に困難なケースを削除することを許可しない。
主な結果は、エンドツーエンドの許容された完了である。初回試行の成功率、サービス可用性、人間のアクティブな分単位の時間、経過時間、部分的な完了、不確定のまま残されたクラスター、達成されたリカバリポイント、達成されたリカバリ時間を測定する。エアギャップについては、イメージ、バイト、承認、失敗したプルをカウントする。サポートについては、最初の応答、有用な診断、回避策、エンジニアリングハンドオフ、最終解決を別々に記録する。
リカバリはすべての時計でテストする必要がある。Rancher 管理状態を復元する。下流の etcd スナップショットを復元する。別途保持された Fleet シークレットを再作成する。Longhorn バックアップアプリケーションを復旧し、そのトランザクションを検証する。外部のロードバランサーとアイデンティティを調整する。いずれかの層が成功ステータスを返してもビジネスサービスが誤っている場合、リカバリは失敗している。
少なくとも 1 つの完全なリリースサイクルを通じて演習を実行する。クリーンインストールはアーキテクチャを示し、アップグレードは保守性を示し、失敗したアップグレードは製品とサポート組織を示す。3 つ目だけが、サブスクリプションがそのマージンを稼ぐかどうかを明らかにする。
SUSE にとって有利なケースを強化する結果がいくつかある。Prime は、同じコミュニティスタックに対して、人間の分単位の時間と結果に重み付けされた失敗のテールを実質的に削減するはずである。アップグレード検証は、変更前に該当するリリース問題をキャッチするべきである。信頼できるアーティファクトは、エアギャップ承認作業を削減するべきである。サポートは、内部スタッフが迅速に解決できないケースでの診断と復旧を短縮するべきである。システム群は、頻繁なアプリケーションの再設計を強いることなく、サポートされる組み合わせ内に留まるべきである。
結果がそれを弱める可能性もある。最も重要な統合のほとんどがマトリックス外に留まる場合、サポートは境界を定義することに時間を費やすかもしれない。有償ケースが迅速な確認応答を受け取るが有用なアクションが遅い場合、目標応答は運用上の価値がほとんどない。Fleet と Rancher が通常の変更を簡素化する一方で、ストレージとアイデンティティの例外がコストを支配する場合、スイートはサービスよりもダッシュボードを改善するかもしれない。マネージド Kubernetes がはるかに低いスタッフコストで法的および地理的な要件を満たす場合、マルチクラウドの柔軟性はめったに行使されない高価なオプションかもしれない。
判断
SUSE は防御可能な商用オープンソースの提案を持っている。急速に動くプロジェクトを取り上げ、維持された組み合わせ、リリースアーティファクト、ライフサイクルのコミットメント、エンジニアへのアクセスを販売している。SLES は破壊的な移行を延期できる。Rancher は異種混合のクラスターに共通の管理面を提供できる。RKE2 と K3s はクラスター構築とノード変更を再現可能にできる。Fleet は 1 つの承認された変更を多数に変換できる。Longhorn は、外部アレイやクラウドディスクが不適切な場合にサポートされるストレージオプションを提供できる。
この提案は、コントロールプレーン全体を 1 つのクラウドプロバイダーに引き渡せない規制対象、非接続、エッジ、マルチインフラのシステム群にとって最も強力である。標準化された運用モデルのコストを分散させるのに十分な反復クラスターを持つ組織にとっても強力である。これらの環境では、1 つの重大な停止または 1 つの急いだサポート外の移行を回避することで、相当なサブスクリプション費用を正当化できる。
公開証拠は、SUSE がライフサイクル作業を単純または一般的に安価にするというより強い主張を支持していない。独自のドキュメントは、逐次パス、Rancher マイナーの短いメンテナンスウィンドウ、別々のバックアップドメイン、不可逆的なストレージ遷移、リリース固有の移行、初回応答に限定されたサポート目標を示している。顧客事例は速い通常のワークフローを定量化しているが、例外の分母は空のままである。
それは矛盾ではない。基盤となる状態が困難であるため、サポートされるパスは価値がある。広範で制約のない約束はより信頼性が低いだろう。テストは、そのパスが顧客の実際のシステム群にとって十分に広いかどうか、そして現実がその外に押し出されたときに SUSE が支援するかどうかである。
答えは顧客によって異なる。厳格なエアギャップ要件を持つ標準化された RKE2 フリートは、1 つの説明責任のあるサプライヤーと検証されたインベントリから高い価値を得るかもしれない。1 つのハイパースケーラー上のクラウドネイティブチームは、プロバイダーのマネージドコントロールプレーンによってより適切にサービスされるかもしれない。成熟したプラットフォームグループはコミュニティプロジェクトを使用し、必要な場合にのみ専門知識を購入するかもしれない。高度にカスタマイズされたシステム群は、サブスクリプションによって例外を標準製品に変えることができないことに気付くかもしれない。
信頼性を最も向上させる事実は、プロモーションではなく運用に関わるものである: 代表的フリート全体での初回試行アップグレード結果、製品別の中央値と最悪ケースのサポート解決、Rancher、Fleet、Kubernetes、ストレージを跨ぐ復元ドリル、リリースごとのエアギャップ更新作業、プラットフォームスタッフと失敗した変更を含む顧客の総コスト調査。SUSE はすべてのトポロジーが比較可能であるふりをせずに、これらを公開することができる。
それまでは、適切な購買質問は SUSE にエンタープライズ機能があるかどうかではない。それはある。問題は、顧客の反復作業のどれだけが SUSE のテスト済みシーケンス内に収まるか、例外がどれほど高くつくか、そして複数の層が異なる方向に動くときに誰がサービスを復旧できるかである。商用オープンソースは、答えが変更を通じた実践されたルートであるときにその価格を稼ぐ。それは、「サポートされている」が簡単なケースのラベルになり、困難なケースでの交渉になるときに失う。