Red Hat サブスクリプション管理のワークフローの概要

Red Hat Subscription Management 1

IT インフラストラクチャーとしてサブスクリプションを理解し、管理することを容易にするガイド

Red Hat Subscription Management Documentation Team

October 1, 2013

概要

本ガイドでは、サブスクリプション管理およびツールの背景にある概念と、一般的な使用例を説明します。

1. サブスクリプション管理について

IT ハードウェアには管理のほか、明確なインベントリー管理も必要です。それらのマシンにインストールされたソフトウェアも、管理のほか、明確なインベントリー管理が必要です。

1.1. サブスクリプション管理の目的

IT 管理者はますます、ソフトウェアに関して会計報告を正確に行うプレッシャーに直面しています。また、米国のサーベンス・オクスリー法のような政府による規制だけでなく、PCI-DSS (Payment Card Industry Data Security Standard) や SAS-70 などの重要な業界標準の証明書を取得するプレッシャーにも直面しています。一般に、このソフトウェア資産の会計報告は、ソフトウェアライセンス管理 と呼ばれています。これは、Red Hat のサブスクリプションモデルでは サブスクリプション管理 と呼ばれています。
サブスクリプションの効果的な管理は、企業が以下にあげる 4 つの主要目標を達成するのに役立ちます。
  • ソフトウェアが割り当てられたサブスクリプションおよび有効期限の追跡による 規制に対するコンプライアンスの確保
  • IT 監査の簡略化
  • サブスクリプションとシステムの関係を明確にすることで、より効果的なサブスクリプションの割り当て
  • コストの削減と調達の効率化。システムに対してサブスクリプションが 不十分 な場合は、規制に抵触する可能性があり、逆にサブスクリプションを 過剰 に使用していると、IT の予算に大きな影響を及ぼす恐れがあります。
Red Hat Subscription Management は、購入したサブスクリプションを、その製品がインストールされているマシンに直接関連付けることで、ソフトウェアの数を監視します。サブスクリプション管理は、使用可能な製品のサブスクリプションと、そのサブスクリプションが割り当てられている IT インフラストラクチャーの構成要素との間に 関係 を構築します。
これは、ライセンス管理と非常に似ており、その点では他のソフトウェアに共通していますが、ライセンスの場合は、誰がそのソフトウェアを使用できるかを定義します。Red Hat は、自由で開かれたソフトウェアを約束しているため、ソフトウェアにライセンスを設定しておらず、使用要件を課していません。サブスクリプションでは、以下が可能になります。
  • サポートサービスへのアクセス
  • コンテンツ配信およびホスト型リポジトリー
  • ナレッジベース、フォーラム、ビデオなどのリソースへのアクセス

1.2. サブスクリプション: システム、ソフトウェア、およびサポートの関係

IT インフラストラクチャーは、インストールした製品と、その製品に必要なライセンスまたはサブスクリプションとの間のバランスを保とうとします。
サブスクリプションのライフサイクルには信頼できるパターンがあります。
  1. 企業 (アカウント) は、製品のサブスクリプションを購入します。このサブスクリプションには、使用できる数 (数量)、サポートレベル、コンテンツリポジトリー、および有効期間が定義されています。
  2. システムは、サブスクリプションサービスの インベントリー に追加 (または 登録) されます。これは、サブスクリプションサービスがサーバーを管理し、サブスクリプションをそれにアタッチすることを意味します。
    サブスクリプションサービスは、そのハードウェアやインストールされている製品など、システムに関する情報を収集します。これは、システムに必要なサブスクリプションを決めるために使用されます。
  3. サブスクリプションは、システムに割り当てられます (または アタッチ されます)。
  4. サブスクリプションがアクティブである限り、コンテンツ配信ネットワークからソフトウェアパッケージおよび更新をダウンロードできます。
インベントリー は、単に どの ソフトウェアがインストール済みで、それが どこに インストールされており、いくつの コピーが実際に使用されているかを追跡するための手段です。
サブスクリプションサービスの構造

図1 サブスクリプションサービスの構造

サブスクリプションサービスの各要素は一意に識別される必要があります。これにより、システム、製品、およびサブスクリプションの関係が確立されます。これは、公開鍵インフラストラクチャー (PKI) の証明書 を使用して行われます。サブスクリプションサービスは、ローカルシステムにこのような証明書を生成し、インストールします。
  • システムの 識別証明書: これは、サブスクリプションサービスを定期的に証明するためにシステムが使用するもので、定期的な更新の確認に使用されます。
    これは、システムを登録する際に作成されます。
  • システムにインストールされている各製品の 製品証明書: Red Hat の各製品には、識別証明書があります (が、製品に一意ではありません)。
    これは、製品のインストール時に、システムにインストールされます。
  • システムに割り当てられている各サブスクリプションの サブスクリプション証明書: サブスクリプションに関するインベントリーの情報が含まれます。
    これは、システムにサブスクリプションをアタッチした時に、システムにインストールされます。

注記

サブスクリプションをアタッチしても、インストールや更新は行われません。ソフトウェアパッケージそのものは、yum などの一般的なシステムツールで維持します。同様に、製品がインストールされていても、システムに適切なサブスクリプションがアタッチされていることは限りません。システムに製品をインストールする際には有効な証明書が必要ではないからです。
結局のところ、サブスクリプション管理は、情報の配信を改善し、管理者がインフラストラクチャーを管理しやすくします。サブスクリプション管理の一番の目的は、法規制の順守、インフラストラクチャー管理にあり、さらには購入決定およびシステムメンテナンスを向上させます。
この目的はすべて、結局のところ情報ということになります。管理者に、所有しているサブスクリプションとはどういうものか、システムではどのように使用されるかについて、より良い理解を提供します。
  • 法規制の順守および IT 監査に対しては、Red Hat は、システムとサブスクリプション関連について、アカウント全体のビューを 2 種類提供します。カスタマーポータルにおける使用状況のビューと、Subscription Asset Manager などのサブスクリプション管理アプリケーションにおけるレポーティングおよびダッシュボードです。
  • サブスクリプションをより効率的に割り当てられるように、システムツールを使用して、インストールされている製品に基づいて、関連性と、互換性のあるサブスクリプションをすべてシステムに割り当てる (アタッチする) ことができます。 または 管理者が手動でサブスクリプションを選択してアタッチできます (レポートと通知の表示)。ツールは、利用可能なサブスクリプションと、そのサブスクリプションで利用可能な数量の両方を一覧表示するため、適切なサブスクリプションが割り当てられ、使用されているサブスクリプションの数量が正しくなります。
  • 購入戦略を向上させるために、サブスクリプション管理ツールは、サブスクリプションを過剰に使用している (同じサブスクリプションを使用しているシステムが多すぎる) 場合と、サブスクリプションが足りない (システムにインストールしている製品に対してサブスクリプションが少なすぎる) 場合と、サブスクリプションの有効期限を同時に追跡するのに役立ちます。
    詳細は 「レポートと通知の表示」 を参照してください。
    管理者は、サブスクリプションにおける、時間をベースにした概念 (何をカバーするかだけでなく、どのぐらいの期間 カバーされるか) を把握することで、新しいサブスクリプションの購入時期を理解し、適切な時期に購入できるようになります。
より良い情報とは、より良い管理と言い換えることができます。Red Hat ソフトウェアのサブスクリプション管理に関する長期にわたる目標は、管理者がそのインフラストラクチャーをどのように理解して管理するかを強化していくことにあります。

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

1.3.1. サブスクリプション、製品、システムの相互作用

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

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

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

1.4. サブスクリプション関連の用語

Red Hat Subscription Management のドキュメント、メッセージ、ツールで繰り返し使用される用語があり、ここでは、このような用語を明確に定義しています。サブスクリプションのライフサイクルおよび管理を理解する上で役立ててください。
ここで説明する用語は、Red Hat Subscription Management に関する用語の中で最も一般的なものです。
アカウント
企業に対する基本的な最上位のアカウント。これは、カスタマーポータルで企業を定義するのに使用されるエンティティです。ユーザーとサブスクリプションの情報はすべてここで定義されます。
アタッチ
サブスクリプションをシステムに割り当てることです。
自動アタッチ
新しいサブスクリプションを定期的に確認し、製品に対してサブスクリプションのステータスを変更し、その変更に対応するために新しいサブスクリプションを自動的に割り当てるローカルシステムの設定 (または Subscription Manager ツールで使用するオプション)。システムアーキテクチャー、ハードウェア、インストールされている製品、および定義されてる設定に対して最適なサブスクリプションが選択されます。
証明書
SSL 通信および公開鍵インフラストラクチャーで使用される、X.509 証明書規格に基づいた特別なファイル。これは、Red Hat Subscription Management 内でエレメントを特定するために使用され、たとえば識別情報 (システム)、インストールされている製品、使用しているサブスクリプションを特定するために使用されます。
ID
サブスクリプション管理アプリケーションを使用して登録したエンティティ。この ID は通常、システムと相関関係がありますが、管理アプリケーションのハイパーバイザー、ドメイン、組織、そして RHUI や Satellite などのサーバーになる場合もあります。
インスタンス
サブスクリプションの対象となるシステム内の要素。物理システムの場合、インスタンスはソケットのペアになることが最も一般的です。仮想環境では、1 台の仮想ゲストになります。
インベントリー
サブスクリプションアプリケーションを使用して登録したシステム、ハイパーバイザー、アプリケーションなどのエンティティの一覧。このインベントリーには、その組織が利用可能なサブスクリプション、および使用中のサブスクリプションの一覧も含まれます。
組織
Subscription Asset Manager などのオンプレミスアプリケーションの再分割。組織には、システムインベントリーと、サブスクリプションのサブセットがあります (マニフェストに定義されます)。これは、IT 環境を反映するサブスクリプション構造を定義します。組織は、企業の物理的な場所、または組織の部門に合わせることができます。
プール
組織またはアカウントに割り当てられているすべてのサブスクリプションとその数量。
設定
サブスクリプションを選択する自動アタッチ操作で使用される基準。この設定はローカルシステムで行いますが、自動アタッチに対して評価する必要がある可能性があるサブスクリプション内の属性を定義します。設定は 2 つあり、その 1 つはサブスクリプションのサービスレベルで、もう 1 つはオペレーティングシステムのマイナーリリース (X.Y バージョン (5.10、6.5 など)) となります。
数量
製品またはシステムに対応するために使用するサブスクリプションの数。サブスクリプションは、物理システムのソケット数など、一定の属性に対応します。ハードウェアおよび設定に基づいて、指定したシステムに対応するのに複数のサブスクリプションが必要になる場合もあります。
登録
システムまたはその他の (組織またはハイパーバイザーなどの) エンティティーを、サブスクリプション管理インベントリーに追加すること。
スタッキング
製品またはシステムに対応するために複数のサブスクリプションを組み合わせること。どのサブスクリプションをスタックできるかについてはルールがあります。たとえば、サービスレベルが同じ場合に限り、サブスクリプションをスタックできます。また、サブスクリプションの中には、インストールできる製品を制限するものや、一部のシステムにしか利用できないものもあります。
ステータス
その製品にインストールしているすべての製品や、その製品に関連する有効なサブスクリプションに関する、累積的なステータス。インストールされているすべての製品に有効なサブスクリプションがある場合は、ステータスが 有効 (緑) になります。一部の製品でサブスクリプションが足りないか、その設定に対応するにはサブスクリプションの数量が足りない場合、ステータスは 不十分 (黄色) になります。製品またはシステムにサブスクリプションがない場合、ステータスは 無効 (赤) になります。
サブスクリプション
使用可能な製品、サポートレベル、製品をインストールできるサーバーの数量 (または数)、製品が使用可能なアーキテクチャー、製品を提供するコンテンツリポジトリー、および製品に関連するその他の情報を定義します。
サブスクリプション管理アプリケーション
バックエンドサーバーであり、システムのインベントリーを作成することで個々のシステムと対話します。コントラクト、数量、終了日などのサブスクリプションのインベントリーも管理します。新しいシステムが登録される時、サブスクリプションを割り当てる時、製品をインストールする時に、サブスクリプション管理サービスが変更を管理し、対応する証明書をシステムに発行して変更に印をつけます。サブスクリプション管理サービスは、ハードウェアやアーキテクチャーの制限など製品のルールも定義し、サブスクリプションの割り当てをサポートします。
システム
すべてのエンティティー (物理マシンまたは仮想マシン) です。これは、サブスクリプションサービスのインベントリーにあり、割り当て可能なサブスクリプションを持っています。
使用状況
組織に利用可能なサブスクリプションの総数、およびカスタマーポータルのサブスクリプション管理、RHN Classic などのサブスクリプション管理アプリケーションに割り当てられているサブスクリプションの総数です。

1.5. RHN Classic、Satellite、およびチャンネルのエンタイトルメント

Red Hat Enterprise Linux 6.1 以降、サブスクリプションを定義する方法が変更しました。以前のサブスクリプションモデル (RHN Classic、Satellite 4、および 5 で使用されたモデル) では、サブスクリプションサービスを使用してシステムを登録するには、システムに システムエンタイトルメント が必要でした。したがって、システムには、チャンネルで定義した一連のコンテンツとソフトウェアへのアクセスを付与する チャンネルエンタイトルメント が必要でした。
登録したシステム、そのシステムにインストールしているソフトウェア、そのシステムへのアクセスを付与したチャンネルの間には相関関係がありません。エンタイトルメントプールは 2 つあり、レポーティングでもその関係性は明確になっていません。
ただし、サブスクリプションを明確に追跡することは、IT メンテンナンスで重要性が高まっている部分です。RHN Classic の従来型のチャンネルベースのサブスクリプション管理プロセスは、アクセス付与に関しては優れたものでした。一方で、サブスクリプションの適用方法、使用中のサブスクリプションの数、サブスクリプションの使用場所、個々のシステムが使用しているものについて正確に詳細を把握することは非常に困難でした。
Red Hat Subscription Management は、公開鍵インフラストラクチャー (PKI) 証明書を使用して、システム、システム上の製品、システムにアタッチしているサブスクリプションを独自に特定します。ここでは、システムとサブスクリプション管理サービスとの間、またはシステム、製品、サブスクリプションの間に常に相関関係があります。
従来型のサブスクリプションモデルと、新しいサブスクリプションモデルは、インベントリー内のシステムおよびサブスクリプションの表示または構造化の方法が基本的に異なります。実際には、一般的に、サブスクリプションサービスとシステムのバージョンは混在しています。Red Hat Enterprise Linux 4.x、5.7、および 6.0 (およびそれ以前) のシステムがインフラストラクチャーに存在し、RHN Classic に登録するか、Satellite 4 および 5 を使用している場合は、以前のサブスクリプションモデルを使用します。カスタマーポータルのサブスクリプション管理に登録したシステムや、Subscription Asset Manager を使用しているシステムは、新しいサブスクリプションモデルを使用しています。
このような混合環境を管理者が管理する方法はいくつかあります。
  • レポート機能が強化された Satellite 5.6 および Subscription Asset Manager 1.3 を使用します。
  • Red Hat Enterprise Linux 5 および 6 のシステムを、以前のサブスクリプションサービスから新しいサブスクリプションサービス (Subscription Asset Manager またはカスタマーポータルのサブスクリプション管理) に移行します。これにより、登録が移行し、アタッチしたサブスクリプションが更新され、システムを管理するのに使用するクライアントツールが rhn_register から subscription-manager へ変更します。
いずれのシステムにも長所と短所があり、管理者が決定できます。
移行および強化されたレポーティングにより、サブスクリプションの追跡とメンテナンスの利点が、高水準からレガシーシステムに広がります。
  • チャンネルエンタイトルメントとシステムエンタイトルメントは 1 つのエンタイトルメントプールに統合されるため、新しいサブスクリプションモデルと構造がより似てきました。
  • チャンネルエンタイトルメントから新しい製品のサブスクリプションにマッピングします。
  • チャンネルサブスクリプションに基づいて、管理するシステムにインストールした製品と、それに対応するサブスクリプションを相互に関連付けます。
  • レガシーシステムとエンタイトルメントを、新しいサブスクリプション管理と同じように表示することで、同じような監査レポートを容易に作成できます。
  • レガシーシステムと、Red Hat Subscription Management を使用して登録したシステムに対するサブスクリプションおよび製品について、統一したビューを提供します。