第5章 システムとサブスクリプションの管理

システムは、サブスクリプションを使用してインストール可能なソフトウェアパッケージを定義します。更新をダウンロードするには、システムに最新のサブスクリプションが必要です。

5.1. システム上のサブスクリプション

システムにサブスクリプションを割り当てることで、そのシステムはサブスクリプション内の Red Hat 製品をインストールして更新することができるようになります。サブスクリプションとは、購入した全製品の全バリエーションの一覧であり、製品とサブスクリプションが利用できる回数を定義します。これらのライセンスの 1 つがシステムに割り当てられると、そのサブスクリプションはそのシステムに アタッチ されたことになります。
組織で利用可能なサブスクリプションは、組織マニフェストで定義されます (「マニフェストのインポートおよびメンテナンス」)。システムについては、サブスクリプションはいくつかの追加方法があります。
  • 手動でサブスクリプションを追加および削除する
  • インストール済み製品およびシステムの特性に基づくサブスクリプションの自動アタッチ
  • システムをアクティベーションキーに登録してサブスクリプションを事前設定にアタッチする

5.1.1. サブスクリプションとシステムの関係

5.1.1.1. サブスクリプション、製品、システムとの対話

システム上の製品間には、関係性、依存性、そして競合性が存在します。同様に、サブスクリプション間にも関係があり、これは、サブスクリプションに対応するソフトウェアの関係に相当します。サブスクリプションの中には、仮想ゲストを許可するもの、他のサブスクリプションを必要とするもの、他のサブスクリプションと競合するものがあります。
サブスクリプションは、インストール済みの製品、その製品間、そしてこれらの製品がインストールされているシステムとの関係を定義します。同様に、サブスクリプションは、システム間の関係のほか、環境内でのシステム間の相互作用の方法についても定義できます。これは、特に仮想環境において明らかです。仮想環境では、サブスクリプションは物理ホストおよび仮想ゲストに対して様々な関係を定義できます。しかし、システム間の相互作用には他の方法もあります。たとえば、データセンターやクラウドインフラストラクチャーなどです。サブスクリプションは、これらのメタ関係の一部になります。
これらの関係の定義にサブスクリプションを使用すると、製品やシステムの相互作用の方法に幅広い柔軟性が追加されます。
  • 1 つの製品を 1 つのシステムに関連付けます (これが最も一般的な関係になります)。
  • 1 つの製品に制限することで、特定の異なる製品と同じシステムにインストールできないようにします。
  • システムを一貫性のあるサービスレベルに維持します。各サブスクリプションには、製品のサービスレベル (例: 標準またはプレミアム) に関する定義が含まれています。サブスクリプションのクライアントはまず、同じサービスレベルのサブスクリプションの割り当てを試みます (適用可能)。これは、システムのサポートレベルの一貫性を保持することが目的です。
  • 仮想マシンが、ホストからサブスクリプションを継承できます。
  • ホストが、データセンターデプロイメントに無制限のゲストを保持できるようになります。
  • 1 つの「サブスクリプション」を複数のシステムに渡って使用することを許可します。これは、Red Hat Cloud Infrastructure などで利用できます。この場合、サブスクリプションを 1 つ購入すると、Red Hat Enterprise Linux、Red Hat OpenStack、Red Hat Virtualization、および Satellite 6 の 4 つの製品をカバーできます。これらの各製品は独自のサブスクリプションを持つことになり、スタック作成のために様々なシステムで利用できます。
  • 同じタイプのサブスクリプションをスタックまたは組み合わせて、システムを網羅します。

5.1.1.2. サブスクリプションの計算

サブスクリプションサービスのインベントリーの一環として、サブスクリプションの追跡があります。つまり、どのサブスクリプションが購入されたかだけでなく、これらのサブスクリプションのうち利用可能な数はどれくらいかを追跡します。
サブスクリプションの初回購入時には、そのサブスクリプションを使用できる時間を定義します。サブスクリプションの数は、基本となるシステムの特定の要素をベースとしています。最も一般的なのは、ソケット数です (ただし、特定のサブスクリプションによっては、コア数など、ソケット数以外のものもあり得ます)。サブスクリプションによって直接カバーされるシステムまたはソフトウェアの要素は、インスタンスと呼ばれます。
たとえば、2 ソケットの Red Hat Enterprise Linux のサブスクリプションの場合は、製品が Red Hat Enterprise Linux and で、属性は物理ソケットペアになります。ソケットのペアはインスタンスです。
1 つのサブスクリプションには通常、1 つのソケット数 (または他の属性) が必要です。したがって、8 つのソケットのシステムの場合は、ソケット数をカバーするために 4 つのソケットのシステムよりもサブスクリプションの数が必要となります (これをスタッキングと呼びます)。
ただし、このような単純なアレンジメントが、すべてのサブスクリプションに適用されるわけではありません。
2013 年 10 月以降、Red Hat は、以下のようなサブスクリプション関係の導入を開始しました。
  • 1 つのサブスクリプションを使用する複数の製品 (Red Hat クラウドインフラストラクチャー)
  • 継承可能なサブスクリプション
  • 仮想ゲストを無制限に許可するデータセンターサブスクリプション (ホストだけが特定のサブスクリプションが必要)
また、2013 年のサブスクリプション変更により、サブスクリプションでの仮想ゲストの処理方法が変更になりました。物理システムに対するサブスクリプションと、仮想ゲストに対するサブスクリプションは別になっていました。現在のサブスクリプションモデルでは、物理システムと仮想システムの両方に同じサブスクリプションが使用されます。ただし、物理システムと仮想システムでは、使用される数量が異なります。
前述したように、物理システムでは、1 つのサブスクリプションの数は、ソケットのペアごとに使用されます。仮想ゲストは、ソケットのペアではなく 1 つのソケットとしてカウントします。つまり、仮想ゲストは基本的にサブスクリプションの数の半分になります。仮想ゲストがインベントリーに追加されると、利用可能なサブスクリプション数の合計に 2 を掛けます (インスタンスの乗数)。これにより、仮想ゲストの利用数が「半分」だけでも、サブスクリプションのカウントは整数のままでよいことになります。
ただし、一部のサブスクリプション数に 2 を掛けても、データセンターの仮想ゲストは、個々のサブスクリプションを使用しません。複数の製品に関する一部のサブスクリプション (Cloud Infrastructure) は、別のシステムにインストールされます。さらに、2013 年以前のサブスクリプションはすべて同じ環境にインストールされます。サブスクリプションの使用状況ページまたはサブスクリプション管理ツールに一覧表示された実際の数は、コントラクトで購入した数量を反映しない可能性があります。基本的な数は同じです。異なる点は、主に、全体の数を維持するか、より柔軟なサブスクリプションタイプを維持するために変更を反映しているという点です。