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

Red Hat Subscription Management 1

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

Red Hat Subscription Management Documentation Team

rhsm-docs@redhat.com

法律上の通知

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 サブスクリプションサービスの構造

サブスクリプションサービスの各要素は一意に識別される必要があります。これにより、システム、製品、およびサブスクリプションの関係が確立されます。これは、公開鍵インフラストラクチャー (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 を使用して登録したシステムに対するサブスクリプションおよび製品について、統一したビューを提供します。

2. サブスクリプション管理のためのツールおよびアプリケーション

すべての Red Hat Enterprise Linux サブスクリプションには、サブスクリプションの設定を管理するツールが含まれます。

ローカルシステムを管理する Red Hat Subscription Manager クライアントツール
カスタマーポータルを介して、 1 つのアカウントに対して、システムおよびサブスクリプションアプリケーション組織をグローバルに管理するカスタマーポータルのサブスクリプション管理
オンプレミスサブスクリプションサービスをインストールする Subscription Asset Manager

多様なツールにより、管理者は、組織のビジネスおよびインフラストラクチャーの両方の要望を満たすワークフローを作成できます。このすべての要素が比較的互いに独立しており、潜在的な設定およびデプロイメントのシナリオが存在します。

2.1. ローカルシステムツール (Red Hat Subscription Manager)

登録とサブスクリプションはともに、Red Hat Subscription Manager という名前の UI および CLI のツールを介して、ローカルシステムで管理されます。Subscription Manager は、ローカルシステムが利用できるサブスクリプションと、ローカルシステムが使用したサブスクリプションを追跡して表示します。Subscription Manager は、サブスクリプションサービスに情報を送り返すパイプ役を担っており、利用可能な製品数量やサブスクリプションの有効期限、更新などの変更を同期します。

注記

Red Hat Subscription Manager ツールはシステムを変更するため、常に root として実行します。ただし、Red Hat Subscription Manager は、サブスクリプションのユーザーアカウントを使用して、サブスクリプションサービスに接続します。

Subscription Manager は、システムの登録およびサブスクリプションの両方を処理します。Subscription Manager は firstboot (初回起動) プロセスの一環としてコンテンツと更新の設定を行いますが、Red Hat Subscription Manager の UI または CLI を使用すると、システムを随時登録できます。新規製品および更新は、Red Hat Subscription Manager ツールを使用して表示し、システムに適用することができます。

Red Hat Subscription Manager には、ローカルマシンを管理する、UI ベースのクライアントと、上級ユーザーのための CLI クライアントの 2 つツールがあります。ツールはいずれも、その他のアプリケーションと連携させたり、マシンのキックスタートなど、管理タスクのスクリプトを作成できます。

これらツールにより、管理者は、サブスクリプション管理に直接関連する 3 つの主要タスク (マシンの登録、システムへのサブスクリプション割り当て (アタッチ)、認証に必要な証明書の更新) を実行することができます。利用可能なサブスクリプションを表示したり、追跡するために、システム情報の更新などのマイナーな操作も提供されています。

2.1.1. Red Hat Subscription Manager UI の起動

Red Hat Subscription Manager は、トップパネルの システム > 管理 メニューに、管理ツールの 1 つとして表示されます。

また、以下のコマンドを 1 つ実行すれば、コマンドラインから Red Hat Subscription Manager UI を開くこともできます。

[root@server1 ~]# subscription-manager-gui

Red Hat Subscription Manager UI は、インストール済みの製品、システムのサブスクリプション、システムがアクセスできる利用可能なサブスクリプションを表示するタブで構成された 1 つのウィンドウで、システムの現在の状態についてクイックビューを提供します。管理者は、これらのタブを使用して、システムのサブスクライブ、またはサブスクリプションの解除を行って、サブスクリプションを管理することもできます。

Red Hat Subscription Manager には、製品およびサブスクリプションを管理するタブが 3 つあります。

ご自身のサブスクリプション タブでは、システムが現在サブスクライブしている全サブスクリプションを表示します。
使用可能なすべてのサブスクリプション タブには、システムが利用できる全サブスクリプションが表示されます。デフォルトでは、ハードウェアと互換性のあるサブスクリプションのみが表示されますが、フィルターを使用して、ハードウェアに一致するサブスクリプション、インストール済み製品に一致するサブスクリプション、および現在割り当てられているサブスクリプションと重複しないサブスクリプションのみを表示、または指定した文字列に一致するサブスクリプションだけを表示することもできます。
インストール済み製品 タブは、システムに現在インストールされている製品と、そのステータスを表示します。ここでは、管理者はソフトウェアをインストールすることはできず、インストール済みソフトウェアの表示のみが可能です。

図3 Red Hat Subscription Manager 主な画面

2.1.2. subscription-manager コマンドラインツールの実行

Red Hat Subscription Manager UI から実行できる操作はすべて、subscription-manager ツールでも実行できます。このツールは以下のフォーマットで使用します。

[root@server1 ~]# subscription-manager command [options]

各コマンドには、それぞれ独自の オプション セットを使用します。詳しくは、subscription-manager のヘルプと man ページを参照して下さい。

表1 使用頻度が高い subscription-manager コマンド

コマンド	説明
操作コマンド
register	新規システムをサブスクリプションサービスに登録または特定します。
unregister	マシンの登録解除を行います。サブスクリプションは解除され、サブスクリプションサービスからマシンが削除されます。
attach	特定のサブスクリプションをマシンにアタッチします (割り当てます)。
remove	マシンから特定のサブスクリプションまたはすべてのサブスクリプションを削除します。
redeem	ハードウェアおよび BIOS 情報に基づき、ベンダーから購入した事前指定済みのサブスクリプションに、マシンを自動的にサブスクライブします。
import	サブスクリプションサービスに要求を送り、証明書を受け取る代わりに、手動でサブスクリプション証明書をインストールします。
list	マシンと互換性があるサブスクリプションの一覧を表示します。マシンが実際に使用しているサブスクリプション、あるいマシンが利用できる未使用のサブスクリプションのどちらかです。
設定コマンド
config	Red Hat Subscription Manager 設定ファイル `/etc/rhsm/rhsm.conf` に指定した設定パラメーターを変更します。パラメーターは、configuration_area.parameter="value" の形式で渡します。
service-level	自動アタッチ操作でサブスクリプションを選択する場合は、システムが使用するサービスレベル設定を設定します。
release	自動アタッチ操作でサブスクリプションを選択する際に、システムが使用するオペレーティングシステムのリリースバージョン設定を設定します。
refresh	サーバーから最新のサブスクリプションデータをプル (取り出し) します。通常、システムは設定した間隔 (デフォルトでは 4 時間) でサブスクリプションサーバーをポーリングし、利用可能なサブスクリプションにおける変更を確認します。`refresh` コマンドを実行すると、通常の間隔ではなく、その時点のエンタイトルメントサーバーを確認します。
clean	サブスクリプションサービスのコンシューマー情報に影響を与えることなく、ローカルシステムからサブスクリプションおよび ID データをすべて削除します。システムが使用しているサブスクリプションはいずれも、使用された状態のままとなり、他のシステムが使用することはできません。`clean` コマンドは、ローカルのサブスクリプション情報が何らかの理由で破損または損失した場合に役立ちます。`register --consumerid=EXISTING_ID` コマンドは、システムの再登録に使用します。
情報コマンド
version	ローカルの Red Hat Subscription Manager クライアントのバージョン、システムの登録に使用したサブスクリプションサービスの名前、およびサブスクリプションサービスのバージョンを返します。
identity	システムの識別証明書および登録 ID を処理します。このコマンドを使用すると、現在の UUID を返したり、新しい識別証明書を生成したりできます。
facts	リリースバージョン、CPU 数、その他のアーキテクチャー情報などのシステム情報を一覧表示します。
orgs、repos、environments	特定のユーザーアカウントまたはシステムで利用可能な設定済み組織、環境、およびコンテンツリポジトリを一覧表示します。これらのコマンドは、複数組織のインフラストラクチャーの情報を表示するのに使用します。ローカルマシンや複数組織のインフラストラクチャーの設定には使用しません。

2.2. カスタマーポータルのサブスクリプション管理

エンタイトルメント管理の最終的な目標は、管理者がシステムとそのシステムが使用するサブスクリプションとの関係を特定できるようにすること です。これは、外部から潜在的なサブスクリプションを見るローカルシステムのビューと、システムおよび全サブスクリプションのインフラストラクチャー全体を上から見る組織のビューの、2 つの異なる視点から実行することができます。

Red Hat Subscription Manager の UI および CLI はいずれも、ローカルマシンのみを管理するローカルクライアントです。これらのツールで表示できる情報は若干限定されており、1 台のシステムの視点からの情報 (利用可能なエンタイトルメントなど) のみが表示されるです。そのため、期限切れのサブスクリプションや、利用可能な数量のないサブスクリプション、または他のアーキテクチャー用のサブスクリプションは表示されません。

カスタマーポータルのサブスクリプション管理は グローバルな ツールで、サブスクリプションとシステムについて、組織全体の完全ビューを提供することを目的としています。カスタマーポータルのサブスクリプション管理は、システムの登録、サブスクリプションの割り当て、システム情報や UUID の表示など、ローカルツールのタスクを多数実行します。また、サブスクリプション自体の管理 (例: コントラクト情報の表示やサブスクリプションの更新) を行うこともできます。このようなタスクは、ローカルクライアントでは実行できません。

図4 カスタマーポータルでの RHN サブスクリプション管理

注記

カスタマーポータルのサブスクリプション管理では、組織における全種類のシステムを、全体的に理解することができます。これは、サブスクリプションを計画して、効果的に割り当てるために重要なことです。ただし、システムにどの製品がインストールされているか、サブスクリプションがそうした製品に割り当てられているかどうかは 提供されません。カスタマーポータルで扱うのは、システム全体のステータスのみとなります。

インストールされている各製品のステータスについては、ローカルの Subscription Manager ツールを使用する必要があります。

カスタマーポータルのサブスクリプション管理は、RHN Classic で管理しているシステムおよびサブスクリプションを表示し、RHN Classic Web ツールへのアクセスを提供します。

組織全体の全サブスクリプション (購入したサブスクリプション及びそれらが割り振られたシステム) は https://access.redhat.com/ のアカウントページで確認できます。カスタマーポータルのサブスクリプション管理に関する詳しい情報は、https://access.redhat.com/site/documentation/Red_Hat_Subscription_Management/の『カスタマーポータルを使用したサブスクリプション管理』を参照してください。

2.3. Subscription Asset Manager

サブスクリプションサービスまたはコンテンツ配信、もしくはその両方に対して、ローカルでの制御を管理者が必要とする場合もあります。サブスクリプション管理フレームワークの各コンポーネントは、独立したクライアント設定を持つ独立したアプリケーションであるため、さまざまなソースを使用できます。

Red Hat は、サブスクリプション管理アプリケーションに、サブスクリプション管理機能の一部またはすべてを委譲できます。Red Hat は、サブスクリプションおよびコンテンツ情報の主なソースとなりますが、オンプレミスアプリケーションに情報を送信し、そのアプリケーションがサブスクリプションおよびコンテンツをローカルで管理します。

サブスクリプション管理アプリケーションは、グローバルビューと、サブスクリプションの集中管理を保持しますが、管理者は、サブスクリプション管理設定で IT 環境を定義します。たとえば、IT 管理者は、サブスクリプションを分割するために、互いに独立し (そして不透明な) 組織を作成してから、その組織に複数の環境を作成して、コンテンツとリポジトリーアクセスを管理します。

サブスクリプション管理アプリケーションを使用すると、管理者はネットワークの状態やマシンの物理的な場所に基づいて設定を制御し、パフォーマンスを向上させることができます。

Red Hat サブスクリプション管理は、オンプレミスサブスクリプションサービスを複数提供します。

Subscription Asset Manager: オンプレミスサブスクリプションサービスを提要し、サブスクリプション管理コンテンツ配信のリクエストを代理で行います。
Satellite 6: サブスクリプションサービスと、コンテンツ配信の両方をオンプレミスで提供します。

Subscription Asset Manager は、通常の Red Hat Enterprise Linux サブスクリプションに含まれているため、オンプレミスサービスは、Red Hat Enterprise Linux インフラストラクチャーで利用できます。

2.4. ハイパーバイザーのプロセス

仮想ホストシステムのゲストを自動的に検出し、仮想システムとして登録するために利用可能なサービスがいくつかあります。これにより、仮想システムに固有のサブスクリプションをゲストに使用でき、ホストから継承されたサブスクリプションをゲストに適用できるようになります。

Subscription Manager と連携し、ハイパーバイザーとそのゲストを検出して特定するためのサービス virt-who があります。

virt-who パッケージはデフォルトではインストールされていませんが、Red Hat Enterprise Linux システムのサブスクリプションがあればご利用になれます。

3. サブスクリプションのワークフロー

システムの種類や、システムを体系化する方法は複数あり、Subscription Manager と、サブスクリプションサーバーおよびコンテンツプロバイダーの基本的な概念は、特殊なシステムと複数のインフラストラクチャー設定に対応できるために十分な柔軟性を備えています。

3.1. 使用するワークフローの計画

サブスクリプションサービスとコンテンツサービスは、連携して作用します。システムにおけるローカルの Red Hat Subscription Manager クライアントは、サブスクリプションサービスとコンテンツ配信サービスを特定する必要があります。両サービスはともにホスト型サービスにすることも、ローカル管理のサービスにすることもでき、混合させることもできます。

サブスクリプションおよびコンテンツデータはすべて Red Hat から取得します。デフォルトでは、すべての Red Hat Enterprise Linux システムが Red Hat のホスト型サービスを対象とするように設定されています。管理者がサブスクリプションおよびコンテンツ管理にオンプレミスサーバーを使用する場合、そのオンプレミスサーバーは最初に Red Hat のホスト型サービスからその情報を取得してから、ローカルシステムを管理します。Red Hat サブスクリプションのインベントリーは、オンプレミスのサブスクリプションアプリケーションを認識していますが、そのサブスクリプションアプリケーションが管理するローカルシステムについては認識していません。

Red Hat Subscription Manager 設定は、サブスクリプションサーバーおよびコンテンツサーバーの 2 種類のサーバーを対象にします。この 2 つの設定は、サポートされるサブスクリプションサーバーまたはコンテンツサーバーを使用するように (個別に) 変更できます。表2「ソース別のサブスクリプションおよびコンテンツサービス」には、サブスクリプションサーバーおよびコンテンツサーバーを使用できるサーバーのタイプを記載します。

表2 ソース別のサブスクリプションおよびコンテンツサービス

サーバーのタイプ	サブスクリプションサービスのサポート	コンテンツ配信サービスのサポート	推奨されるエンタイトルメントの種類
カスタマーポータルのサブスクリプション管理			小規模の企業 (20 台以下のサーバー) IT リソースが限定的サブスクリプションまたはコンテンツの更新についてスクリプトを作成する必要はありません。
Subscription Asset Manager			小規模または中規模の企業ホスト型サービスを除外するセキュリティールールが存在するビジネス複数の仮想マシン追加の管理機能を使用しない、監査とレポーティングが必要な大企業
Satellite 6			中規模の企業ホスト型サービスを除外するセキュリティールールが存在するビジネスカスタムコンテンツとデプロイメントのスクリプトサブスクリプションおよびコンテンツの管理と連携するシステム管理

3.2. ユーザーアカウントに関する注記

インベントリーのシステムとサブスクリプションは、サブスクリプション管理サービスを介して管理され、そのサービスはユーザーアカウントに接続されます。

各サブスクリプション管理サービスが、独自のユーザーセットを定義します。作成して使用するユーザーアカウントは、サブスクリプション管理サービスがアクセスするものによって異なります。

カスタマーポータルのサブスクリプション管理

サブスクリプションを最初に購入した時に、Subscription Asset Manager で設定する必要があります。カスタマーポータルに接続していたユーザーアカウントは、そのシステムを管理するのに使用できませんでした。そのアカウントはカスタマーポータルのサブスクリプション管理で作成されています。その管理者は、その他のユーザーアカウントを作成し、企業アカウントと全体に関連付けられるため、(適切なパーミッションが割り当てられた) そのアカウントで、システムおよびサブスクリプションを管理できるようになります。カスタマーポータルのアカウントの作成および管理は「Managing User Access to the Red Hat Customer Portal and the RHN Application」を参照してください。

Subscription Asset Manager

Subscription Asset Manager は、オンプレミスアプリケーションです。IT 管理者が、Red Hat アカウントでサブスクリプションマニフェストに最初にアクセスし、サブスクリプションを管理します。これは、カスタマーポータルで行います。したがって、Subscription Asset Manager アプリケーションそのものを設定して管理する場合は、カスタマーポータルのユーザーアカウントが使用されます。

個々のシステムは Subscription Asset Manager によって管理されるため、このシステムを管理するのに使用するユーザーアカウントは Subscription Asset Manager に設定する必要があります。カスタマーポータルに接続するのに使用するユーザーアカウントを、個々のシステムを管理するのに使用することはできません。ローカルの IT 管理者が、通常のユーザーアカウントを Subscription Asset Manager に作成する必要があります。

アクティベーションキー

ユーザーアカウントはアクティベーションキーに関連付けられ、アクティベーションキーと引き換えるのに使用しますが、使用するユーザーアカウントは、キーの発行者によって異なります。ベンダーがキーを作成した場合は、そのキーで使用するユーザーアカウントを定義します。そのキーの発行者が Red Hat の場合は、Red Hat が定義します。Subscription Asset Manager を使用してローカルの IT 部門がアクティベーションキーを作成した場合は、関連する Subscription Asset Manager ユーザーアカウントが使用されます。

3.3. カスタマーポータル: 自動アタッチシステム

Red Hat Enterprise Linux システムのサブスクリプション管理には、ステップが 2 つあります。サブスクリプションサービスにシステムを登録するステップと、オペレーティングシステムと、システムにインストールした製品にサブスクリプションを適用するステップです。デフォルトでは、システムの Red Hat Subscription Manager UI または初期起動 (firstboot) でサブスクリプションをアタッチする際は、2 つのステップが同時に行われます。

Red Hat Subscription Manager の設定は、サブスクリプションサーバーまたはコンテンツサーバーを対象とします。デフォルトでは、Red Hat のホスト型サービスを対象とします。

したがって、デフォルト設定を使用すると、システムはカスタマーポータルのホスト型サービスに登録され、利用可能な最適なサブスクリプションがシステムに自動的にアタッチされます。

3.3.1. 環境: 小規模企業

ホスト型サービスは、IT 環境の一番の目的がデプロイメントの容易さにある場合に選択できるように設計されています。これは、小規模の企業、または Linux インフラストラクチャーが小規模である企業向けのものです。

Linux サーバーが 20 台以下
システムメンテナンスに対する IT リソースが限定的
カスタムのサブスクリプションまたはコンテンツユーティリティーを作成する必要がない企業
既存の Linux システムにすでに RHN Classic のホスト型サービスを使用しているインフラストラクチャー

ホスト型サービスをご利用になれば、マシンの台数が少ない場合に管理が容易になります。

デフォルトのシステム設定を使用するため、実装が容易
追加のソフトウェアまたはハードウェアのオーバーヘッドがない
組織の設定に基づいて、後にオンプレミスサブスクリプションまたはコンテンツサービスに移行が可能
データセンター、または物理的な場所が異なっても、すべてのシステムでサブスクリプションサービスが同じ

ホスト型サービスでは、ネットワーク全体のパフォーマンスについて、潜在的な問題があります。IT インフラストラクチャーが大きくなると、多数のシステムがコンテンツまたは更新を受け取ろうとした場合に、ローカルの帯域幅またはレイテンシーの問題が発生する場合があります。

注記

初めのうちは、小規模の IT 環境で Red Hat ホスト型サービスを使用しても、将来的にオンプレミスサブスクリプションまたはコンテンツサービスを使用するように展開していくこともできます。

3.3.2. ワークフロー

図5 自動アタッチプロセス

一致したサブスクリプションを自動的にアタッチする場合 (Red Hat Subscription Manager UI のデフォルト設定または subscription-manager コマンドで --auto-attach を使用) は、登録プロセスに必要なステップは 1 つだけです。

3.3.3. オプションおよび詳細

オプションのほとんどは、登録後に設定できます。

追加サブスクリプションのアタッチ。オペレーティングシステムに対してのみサブスクリプションを割り当てる際に、初期起動時に自動アタッチしておく場合に特に便利です。
システム情報の上書き。これは、自動アタッチおよび自動修復プロセスが、互換性のあるサブスクリプションを見つけるために、システムアーキテクチャーとハードウェアを確認する場合に使用されます。
システムレベルの設定 (これも登録時に済ませることができるため、サブスクリプションを選択する際の設定の 1 つとして使用されます)。
リリース設定。これにより、システムはそのリリースバージョン用のソフトウェアだけを更新し、オペレーティングシステムの後続バージョンへのアップグレードは無視します。
関連する yum リポジトリーの有効化または無効化。

3.4. カスタマーポータル: 登録および手動サブスクリプション

システム登録とサブスクリプションは、1 回のステップ (自動アタッチ) で行うことができますが、設定自体は異なる手順を踏んでいるため、この 2 つを別々に実行することができます。これにより、システムがどのようにプロビジョニングされ、どのようにサブスクリプションを割り当てるかについて、より多くの制御が可能になります。

自動アタッチでは、システムのアーキテクチャーや、現在インストールされている製品に最適なサブスクリプションが自動的に割り当てられますが、状況によっては常に最適であることは限りません。たとえば、初期起動時に登録すると、その他の製品をインストールする前に登録することになるため、オペレーティングシステムに対するサブスクリプションのみがアタッチされます。または、その時点でシステムにインストールされていなくても、その後すぐにインストールする製品が存在する場合や、32 ビットのシステム用として表示されているパッケージを 64 ビットのシステムに実行する場合もあります。

いずれの場合も、自動アタッチプロセスでは希望するサブスクリプションを検出することはできません。なぜなら、システムには、どのようなサブスクリプションが含まれているかを知らせる設定はないからです。

登録とサブスクリプションプロセスを分けることで、管理者は手動でサブスクリプションを選択してシステムにアタッチできるようになります。

3.4.1. 環境: 小規模企業

システムが Red Hat のホスト型サービスを使用するのに必要な登録とサブスクリプションの適用については、手動で行うことは何もありません。

これにはいくつかの利点がありますが、特に小規模企業、または Linux システムの数が少ないインフラストラクチャーには利点があります。自動アタッチプロセスを使用すると、デフォルトのシステム設定を使用し、IT スタッフによるメンテナンスが必要なくなるため、ホスト型サービスを使用すると管理上の負荷的コストを最小限に抑えることができるようになります。

3.4.2. ワークフロー

図6 手動によるサブスクリプションのプロセス

システムを登録します。
ここで必要なのは、CLI コマンドの subscription-manager を使用して、カスタマーポータルのサブスクリプション管理で使用するアカウントのユーザー名およびパスワードを送信することです。
Red Hat Subscription Manager UI (システムおよび初期起動の両方で実行) の場合は、自動アタッチ操作がデフォルトで実行します。これを取り消すには、サブスクリプションの自動アタッチを行わないオプションを選択します。または、オペレーティングシステムにはサブスクリプションの自動アタッチを行ってから、後で追加のサブスクリプションをアタッチしたり、その他のサブスクリプションを削除したりできます。
Red Hat Subscription Manager ツールを使用してサブスクリプションを選択し、アタッチします。
システムを登録する際、サブスクリプションサービスはそのアカウントで利用可能なサブスクリプションの一覧を送信します。利用可能なサブスクリプションはすべてそのシステムに割り当てることができます。
Red Hat Subscription Manager UI を使用して、利用可能なサブスクリプションを 利用可能なサブスクリプション タブに一覧表示し、ボタンで選択してアタッチできます。
CLI では、最初に list サブコマンドを使用してサブスクリプションの一覧を表示してから、表示されたプール ID を使用して attach サブコマンドを使用してサブスクリプションをアタッチします。

3.4.3. オプションおよび詳細

オプションのほとんどは、登録後に設定できます。

システムレベルの設定 (これも登録時に済ませることができるため、サブスクリプションを選択する際の設定の 1 つとして使用されます)。
リリース設定。これにより、システムはそのリリースバージョン用のソフトウェアだけを更新し、オペレーティングシステムの後続バージョンへのアップグレードは無視します。
関連する yum リポジトリーの有効化または無効化。

3.5. Subscription Asset Manager: サブスクリプションの直接割り当て

Red Hat ホスト型サービスは、すべてのシステムが 1 つのプールに含まれる、フラットで未定義の構造です。これは便利な場合もありますが、複数の組織部門、物理的な場所、およびコンテンツストリームにシステムが緩やかにまたは厳密に関連付けられているという実際の IT 環境に存在する構造が失われます。Subscription Asset Manager には組織の構造が導入されているため、管理者は (サブスクリプション用に) ローカルの組織とシステムグループを作成し、実際の設定を反映した方法でシステムを配置することが可能になります。

3.5.1. 環境: 小規模企業から大企業までのローカル定義の構造

Subscription Asset Manager では、サブスクリプションサービスとコンテンツサービスに構造が導入されたため、管理者は実際のインフラストラクチャー構造を反映する方法でこれらのシステムを設計できます。

サブスクリプションは、組織ごとにグループ化され、これがトップレベルの階層になります。各組織は、カスタマーポータルのサブスクリプションに対する、サブスクリプションアプリケーションの個別エントリーを表します。

各組織内ではシステムをグループ化し、更新、アクセス制御、コンテンツ管理のためにシステムを構造化することが可能です。

サブスクリプションインベントリーに組織的な構造を導入すると、Subscription Asset Manager でアカウントのサブスクリプションとシステムに関する情報がより分かりやすく提示できます。大企業では、Subscription Asset Manager で必要となるのはこの機能だけかもしれません。つまり、レポーティングと監査には Subscription Asset Manager を使用し、システム管理にはカスタマイズまたはエンタープライズレベルのアプリケーションを使用するという方法です。

中小企業では、Subscription Asset Manager を使うことで、ホスト型サービスのみを使う場合に比べ、以下のようにシステム管理の制御の幅が広がることになります。

ホスト型サービスではなく、オンプレミスサービスを必要とするセキュリティールールの制定。
仮想環境の管理の向上 (特に、臨機応変にシステムを作成または削除する必要がある、プライベートクラウドやデータセンターのなどの場合。
異なるシステムに異なるリポジトリーを定義 (開発システムや実稼働システムごとに異なるソースを用意する場合など)。

Subscription Asset Manager の機能は、カスタマーポータルのサブスクリプション管理および Red Hat Subscription Manager の機能と密接に関連しています。システムを登録して、自動でサブスクリプションを割り当てることができます。リリースバージョンやサービスレベルなどの設定を用いて、ソフトウェア更新を管理できます。

3.5.2. ワークフロー

図7 Subscription Asset Manager の設定

必要に応じて、Red Hat インベントリー内にエントリーを作成します。Subscription Asset Manager 内の全組織に対して、対応するサブスクリプションサービスエントリーが Red Hat インベントリー内に必要になります。
サブスクリプションのブロックを組織に割り当てます。ブロックは、その Subscription Asset Manager 組織のサブスクリプションの マニフェスト になります。
マニフェストをエクスポートします。
マニフェストを Subscription Asset Manager にインポートします。
ローカルマシンで、Subscription Asset Manager サブスクリプションサービスを使用するように Red Hat Subscription Manager クライアントを設定します。オプションで、Subscription Asset Manager コンテンツプロキシーを使用するようにします。

Subscription Asset Manager とマニフェストのバックエンド設定が必要なのは 1 回のみで、Red Hat Subscription Manager の設定変更が必要になるのも、システムあたり 1 回のみです。

以上が完了すると、システム登録とサブスクリプションの割り当てが可能になります。

図8 Subscription Asset Manager での登録

システムを登録します。
CLI の subscription-manager コマンドを使用し、register コマンドに、カスタマーポータルのサブスクリプション管理のアカウントのユーザー名とパスワード、そして Subscription Asset Manager サーバーのホスト名を加えて実行します。
Red Hat Subscription Manager UI を使用する場合は、サブスクリプションの自動アタッチがデフォルトで行われます。後で、サブスクリプションをアタッチするオプションを確認します。
Subscription Asset Manager UI を使用してサブスクリプションを選択し、アタッチします。

3.5.3. 詳細およびオプション

Subscription Asset Manager にシステムを登録すると、管理に Subscription Asset Manager または Red Hat Subscription Manager を使用することができるようになりますが、Red Hat Subscription Manager で設定するオプションは、Subscription Asset Manager で利用可能なものと一致させる必要があります。

システムの自動アタッチを有効にし、オプションでサービスレベルを設定します。

3.6. Subscription Asset Manager: アクティベーションキー

アクティベーションキーは、システム登録前にサブスクリプションを事前設定する方法です (または、キックスタートといったプロビジョニングシステムと併用すると、システムを作成する前に実行されます)。これにより、新規システムに割り当てるサブスクリプションに関する管理者の柔軟性と制御が大幅に増し、ユーザーの登録プロセスが簡素化されます。

3.6.1. 環境: 事前設定システム

「Subscription Asset Manager: サブスクリプションの直接割り当て」では、Subscription Asset Manager を使用することで一般的に役に立つ点を説明しました。これは、Subscription Asset Manager を使用してアクティベーションキーを作成する際にも該当します。

さらに、アクティベーションキーを使用すると、ユーザーにとって登録およびサブスクリプションプロセスが全体的にシンプルになり、ほぼ透過的になります。アクティベーションキーを渡すだけでシステムを登録して設定済みの全サブスクリプションを適用できるため、適用したサブスクリプションの種類や、必要な数量については知る必要がありません。

システムの事前設定を導入すると、管理者はシステム設定の定義で一貫性を保つことができます。たとえば、企業内で会社設定のノートパソコンやワークステーションを従業員に配布する際には、アクティベーションキーと事前設定サブスクリプションを使用することが一般的です。

アクティベーションキーは、システムにアタッチするサブスクリプションのセットを作成しますが、直接システムにアタッチすることはしません。アクティベーションキーは、Subscription Asset Manager 設定内でシステムグループに関連付けることができます。この状態から、どのシステムでも使用することが可能になります。その結果、ユーザーと管理者は以下のような恩恵を受けることができます。

管理者は、システムを最初に作成したり設定したりせずとも、どのサブスクリプションをシステムにインストールするかを制御できます。
アクティベーションキーは Subscription Asset Manager 内で作成され、システム設定やアーキテクチャーに依存しないため、対象となるシステムを先に用意しておく必要がありません。
ユーザーは、手動でサブスクリプションを選択して、アタッチするという作業をしなくても済むため、いずれかのサブスクリプションを忘れるということがなく、1 回のステップで自動的に適切なサブスクリプションをすべてシステムにアタッチすることができます。

3.6.2. ワークフロー

デフォルトでは、システムは Red Hat ホスト型サービスを使用するように設定されています。アクティベーションキーを作成して使用する前に、適切なバックエンドインフラストラクチャーを設定する必要があります。

図9 Subscription Asset Manager の設定

必要に応じて、Red Hat インベントリー内にエントリーを作成します。Subscription Asset Manager 内の全組織に対して、対応するサブスクリプションサービスエントリーが Red Hat インベントリー内に必要になります。
サブスクリプションのブロックを組織に割り当てます。ブロックは、その Subscription Asset Manager 組織のサブスクリプションの マニフェスト になります。
マニフェストをエクスポートします。
マニフェストを Subscription Asset Manager にインポートします。
ローカルマシンで、Subscription Asset Manager サブスクリプションサービスを使用するように Red Hat Subscription Manager クライアントを設定します。オプションで、Subscription Asset Manager コンテンツプロキシーを使用するようにします。
このステップは、システムを登録する前ならいつでも実行できるので、アクティベーションキーの作成後でも構いません。

以上が完了したら、アクティベーションキーを作成できます。

図10 アクティベーションキーを使用して登録

アクティベーションキーを作成します。これは、サブスクリプションをアタッチ可能なコンテナーエントリーになります。
キーにサブスクリプションを割り当てます。
アクティベーションキーを使用してローカルシステムを登録します。
これは基本的には自動アタッチ操作になりますが、Red Hat Subscription Manager が最適なサブスクリプションを評価する代わりに、キーに関連付けられた事前設定のサブスクリプションをアタッチするという点が異なります。

3.6.3. 詳細およびオプション

システムの自動アタッチを有効にし、オプションでサービスレベルを設定します。

3.7. 一般的な管理: Firstboot (初期起動)

初期起動時にシステムを登録することは、後ほど Red Hat Subscription Manager を使用してシステムを登録することと同じであるため、初期起動時の登録には特別なワークフローがありません。初期起動について触れている主な理由は、初期起動ウィザードは、サブスクリプションおよびコンテンツの更新についてシステムを設定する方法を複数用意しているためです。システムでは、最初に設定してから、サブスクリプションを設定する方法がいくつかあるため、使用されるオプションを理解することで、後でシステムを管理するのが容易になります。

初期起動時に、サブスクリプションサービスおよびアタッチしたサブスクリプションは ソフトウェア更新の設定 画面で設定します。以下の 4 つの選択肢があります。

Red Hat Subscription Management を使用。カスタマーポータルのサブスクリプション管理、Subscription Asset Manager、および Satellite 6 で製品駆動型のサブスクリプションサービスを扱います。
RHN Classic を使用。コンテンツへのチャンネル駆動型アクセスを使用します。
Satellite または Proxy のコンテンツ配信を使用。RHN Classic に似たチャンネルベースのシステムを使用します。
後で登録する

図11 Firstboot (初期起動)

デフォルトでは、初期起動で、カスタマーポータルのサブスクリプション管理にシステムを登録し、互換性のあるサブスクリプションを自動アタッチします。このシステムに関しては自動サブスクリプション選択を省略... チェックボックスを選択すると、自動サブスクリプションを無効にして、手動でサブスクリプションをアタッチできるようになります。

コンテンツサーバーを設定する初期起動オプションは、Red Hat Subscription Manager を使用して既存のシステムを設定するのと同じです。

3.8. 一般的な管理: キックスタート

キックスタートは、システムの作成を自動化するためにスクリプトを作成する方法です。キックスタートは、プロビジョニングシステムの重要な要素で、サブスクリプション設定は、インストール後に実行するスクリプトとしてキックスタートに追加できます。

キックスタート設定は、管理者が使用したいワークフロー (ホストサービスへの登録、アクティベーションキーで Subscription Asset Manager インスタンスを使用する登録、サブスクリプションを手動でアタッチなど) に従います。まずは、使用するサブスクリプションのワークフローについて確認し、その後 subscription-manager コマンドを使用して、必要なステップを行っていきます。

3.8.1. 環境: スクリプト化された環境

キックスタートは、システムの作成をスクリプト化するために使用します。したがって、テスト環境や、データセンターやプライベートクラウドなど、インスタンスを定期的に作成して破棄するような環境で使用されます。

3.8.2. ワークフロー

キックスタート時にシステムを登録してサブスクリプションをアタッチするには、インストール後のスクリプトで subscription-manager コマンドを実行します。

%post --log=/root/ks-post.log
/usr/sbin/subscription-manager register --username rhn_username --password rhn_password --auto-attach

この例では、サブスクリプション設定は、デフォルト設定を使用しています。したがって、カスタマーポータルのサブスクリプション管理の (ホスト) システムに登録されます。また、--auto-attach オプションを使用すれば、最適なサブスクリプションがアタッチされます。

3.8.3. オプションおよび詳細

キックスタートは、サポートされる内容で設定を行いますが、環境を設定するために追加でインストール後のスクリプトを使用する必要があります。

--servicelevel オプションを使用して、サービスレベルを設定します。
サブスクリプションを手動でアタッチする場合、--auto-attach オプションは使用せず、2 番目のスクリプトで attach コマンドを使用するか、後でサブスクリプションを追加します。
デフォルトでは、Red Hat Subscription Manager は、カスタマーポータルのホスト型サブスクリプションとコンテンツサービスを使用します。Subscription Asset Manager などのオンプレミスのサービスを使用する場合は、最初に subscription-manager config コマンドを実行して Red Hat Subscription Manager を再設定してから、新しい設定を使用してシステムを登録します。
システムを登録し、アクティベーションキーを使用してサブスクリプションをアタッチする場合は、適切なサブスクリプションサービスを使用するように Red Hat Subscription Manager を設定してから、アクティベーションキーを使用して登録します。

3.9. 一般的な管理: ハイパーバイザーおよびゲスト

Red Hat Enterprise Linux には、仮想ホストシステムのゲストを自動的に検出し、ホストからゲストへのマッピングを作成し、ゲストを仮想システムとして登録するのに利用できるオプションのサービスがあります。これにより、仮想システムに固有のサブスクリプションをゲストに使用でき、ホストから継承されたサブスクリプションを自動的にゲストに適用できるようになります。

virt-who プロセスでは、異なるいくつかのハイパーバイザーで、ゲストを検出して関連付けることができます。

Red Hat Enterprise Virtualization Manager (KVM)
Xen
HyperV
VMware ESX / ESX(i)

3.9.1. 環境: データセンター、クラウド環境、仮想マシンを使用する環境

注記

お使いの環境で仮想システムが多数ある場合や、(テスト環境やプライベートクラウドなど) 仮想ホストの作成と破壊を繰り返している場合は、Subscription Asset Manager を使用してサブスクリプションサービスを管理することを検討してください。Subscription Asset Manager を使用することで、システムのサブスクリプションをまとめて組織を定義し、その組織のグループに、その組織内のコンテンツフローを制御するように定義できます。

Subscription Asset Manager は、すべての Red Hat Enterprise Linux サブスクリプションで利用できます。

サブスクリプションを効果的に管理、特に、継承可能なサブスクリプションや、サブスクリプション間のやりとりを管理するには、ホストとゲストの関係について、サブスクリプションサービスで内部的に認識している必要があります。これが ホストとゲストのマッピングです。このマッピングでは、指定したハイパーバイザーに対するゲストの識別子の一覧を表示します。

ハイパーバイザーは、Subscription Asset Manager またはカスタマーポータルのサブスクリプション管理で特殊なシステムとして登録されます。ハイパーバイザーそのものは、通常の物理システムとして管理されますが、ハイパーバイザーの種類は、特定のシステムがゲストを自身にマッピングし、サブスクリプションがそのゲストに継承可能であるか、別の方法で適用するかを示しています。

すべてのゲストを特定のホストに関連させるホストとゲストのマッピングを使用すると、サブスクリプションサービスは、1 つのサブスクリプションを仮想ホストに適切にアタッチし、(たとえば) 各インスタンスに 2 つの異なるサブスクリプションを使用する代わりに、それに含まれる継承可能なサブスクリプションをゲストに適用します。

この関連は、各ゲストに対して UUID (Universally Unique Identifier) を取り出し、それをそのハイパーバイザーに関連付けることで行います。この UUID は、各仮想システムのシステム情報の一種です。

最初にハイパーバイザーが登録され、次にシステムの関連プロセスがゲストに対してスキャンして、検出した UUID をサブスクリプションサービスを送信します。これは、ハイパーバイザーの virt-who プロセスにより行われます。

3.9.2. ワークフロー

Subscription Asset Manager インスタンスを使用して登録する場合は、Subscription Asset Manager RPM をインストールして Red Hat Subscription Manager を設定します。
subscription-manager コマンドに --type=hypervisor オプションを追加して、システムをハイパーバイザーとして登録します。
インフラストラクチャー内の Red Hat Enterprise Linux システムに virt-who をインストールします。この Red Hat Enterprise Linux システムは、Red Hat Enterprise Linux ゲスト、ハイパーバイザー (Red Hat Enterprise Linux システムとは限りません)、バックエンドのサブスクリプションサービスとのマッピングを管理して、接続します。
Red Hat Enterprise Linux システムが利用できない場合でも、ホストとゲスト間のマッピングが利用できず、仮想システムは物理システムとして扱われます。
VMware や、Subscription Asset Manager を使用している環境の場合: 適切な仮想化およびサブスクリプションサービスを認識するように、virt-who 設定ファイル (/etc/sysconfig/virt-who) を編集します。
virt-who プロセスを開始して、ホストからゲストへのマッピングを作成します。

3.10. 一般的な管理: 切断されているシステム

切断されているシステムは、システムがオンラインであるため、特別なユースケースです。企業のネットワークに接続されていないか、インターネットアクセスがないため、システムがサブスクリプションやコンテンツサービスにアクセスする機能を持っておらず、システムへの変更はすべて手動で行う必要があります。

3.10.1. 環境: セキュリティー環境およびバックアップシステム

切断されているシステムは、簡単に述べるとインターネットに接続できないシステム、またはイントラネットの可能性もあります。この場合でも、そのシステムの製品およびサブスクリプション、および製品そのものは、インベントリーに含まれている必要があります。

これは、しばしば、企業ルールのためにインターネットに接続できないような安全な場所に置かれたサーバーを意味します。または、必要になるまでオフラインのままにしておくバックアップシステムも含まれます。

サブスクリプションおよびコンテンツの操作のほとんどは、ネットワーク上で行う必要があります。たとえば、rhsmcertd プロセスは、指定のサブスクリプションサービスに接続して、4 時間ごとにサブスクリプション情報の更新を確認します。システムがインターネットに接続できないと、その管理タスクのほとんどを実行することができません。

3.10.2. ワークフロー

切断されているシステムのワークフローは、「カスタマーポータル: 自動アタッチシステム」に記載されているワークフローと同じ概念パスに従いますが、必要なサービスに接続してサービスを自動的に実行するツールを使用する代わりに、管理者が証明書を手動で設定してコピーする必要があるという点が異なります。

図12 切断されているシステムの登録

システムのエントリーを作成します。
最も簡単な方法は、カスタマーポータルに、企業のすべてのシステムについて全体像を見ることができるこのエントリーを作成することです。Subscription Asset Manager などのサブスクリプションサービスを使用すると、切断しているシステムはローカルの組織とシステムグループに関連付けることができるため、のちにシステムをオンラインにする場合に有用となります。
システムにサブスクリプションを割り当てます。システムがオンラインの場合は、Red Hat Subscription Manager を使用して、利用可能なサブスクリプションの一覧を取得し、サブスクリプションサービスに渡します (レストランで注文を聞くウエイターのようなものです)。この方法では、ローカルシステムとサブスクリプションサービスの両方が、システムに割り当てるものを認識しています。
切断したシステムを使用して、最初に適切なサブスクリプションを確保してシステムにアタッチすることで、サブスクリプションサービスが割り当てを認識するようにする必要があります。
そのシステムに関する証明書をすべてダウンロードします。識別 (登録) 証明書、アタッチされているサブスクリプションに関する全証明書の両方が必要です。
識別証明書を適切な場所にコピーします。これにより、システムが登録情報を認識します。
サブスクリプション証明書を適切な場所にコピーします。
これにより、サブスクリプションサービスに利用可能なサブスクリプションを問い合わせなくても、システムが、そのシステムに割り当てているサブスクリプションを認識できます。

3.10.3. オプションおよび詳細

実際には、そのシステムがネットワークから切断されている限り、(サービスレベルの設定などの) システムレベルの設定、(別のサブスクリプションまたはコンテンツサービスの使用などの) インフラストラクチャーレベルの設定などの追加設定オプションはすべて、システムには適用されません。自動アタッチなど、パラメーターのほとんどは、ネットワーク上で自動的に行われるためです。

したがって、システムがオンラインになった時にどのような設定を使用するかが、計画すべき内容になります。たとえば、残りのインフラストラクチャーが、カスタマーポータルのサブスクリプション管理のホスト型サービスではなく、Satellite 6 を使用している場合は、切断されたシステムはおそらくカスタマーポータルのサブスクリプション管理ではなく Satellite 6 を使用します。セキュリティールールについては、システムはオンラインにならなければ、設定する必要がないかもしれません。バックアップシステムは、適切な設定が重要になるため、いつでもオンラインにすることができます。

3.11. レガシー: RHN Classic からの移行

認証ベース、またはシステムベースのサブスクリプションが Red Hat Enterprise Linux 6.1 および 5.7 で導入されました。このバージョン以降のリリースでは、システムベースのおよびチャンネルベースのサブスクリプション登録がサポートされます。以前の Red Hat Enterprise Linux システムは、排他的にチャンネルベースのサブスクリプションを使用していました。

システムの登録は、サブスクリプションをそのまま、チャンネルベースの RHN Classic から、カスタマーポータルのサブスクリプション管理や Subscription Asset Manager などのシステムベースのサブスクリプションサービスに完全に移行させることができます。

重要

このような移行スクリプトは、RHN Classic のホスト型サービスに登録しているシステムを移行するために作成されました。したがって、オンプレミスの Satellite サーバーで登録したシステムを移行するためのものではありません。

3.11.1. 環境: 古い Red Hat Enterprise Linux システムを使用する小規模企業

移行スクリプトにより、ホスト型サブスクリプションサービスであるチャンネルベースの RHN Classic から登録を移行します。この移行は、新しいホスト型サブスクリプションであるカスタマーポータルのサブスクリプション管理や、オンプレミスの Subscription Asset Manager システムへの移行になります。

その利便性や一般的なパフォーマンスにより、ホスト型サービスは通常、中小企業で使用されます。このような企業で使用されるサーバーの数は比較的少ないからです。

大企業、特にシステムが 1000 台以上になるような環境では Satellite が使用されますが、これは移行スクリプトではサポートされていません。

3.11.2. ワークフロー

移行プロセスそのものは、管理者が 1 つのステップ (移行スクリプトの実行) を行うだけで完了します。

図13 移行プロセス

システムが RHN Classic システムで識別できる方法は 2 つ (システム ID またはインストール番号) あるため、利用可能な移行スクリプトは 2 つあります。使用する移行スクリプトは、RHN Classic でシステムにどの識別子を使用するかによって異なります。

Red Hat Enterprise Linux 5 および 6: システム登録とサブスクリプションを、RHN Classic から、カスタマーポータルのサブスクリプション管理へ移行します (両方ともホスト型サービス)。
ここでは、rhn-migrate-classic-to-rhsm 移行スクリプトを使用します。
Red Hat Enterprise Linux 5 のみ: RHN Classic 型のチャンネルを使用するローカルシステムの設定を、インストール済みの製品に対してカスタマーポータルのサブスクリプション管理証明書を使用するように移行します。この移行は、システムのインストール番号に基づいて行われます。移行情報の基盤としてインストール番号を使用する方法は、RHN Classic に接続することができない、切断されている (オフラインの) システムで特に便利です。
これには、install-num-migrate-to-rhsm 管理スクリプトを使用します。

3.11.3. オプションおよび詳細

移行が終了したら、ローカルクライアントでは、Subscription Asset Manager または Satellite 6 を使用するように再設定して、管理オプションをさらに追加します。これには、複数のサブ組織やシステムグループを定義して、ローカルシステムのルールに基づいてサブスクリプションを割り当てる機能などが含まれます。

A. 改訂履歴

改訂履歴

改訂 1.3-6.1

Thu Jun 21 2018

Terry Chuang

翻訳ファイルを XML ソースバージョン 1.3-6 と同期

改訂 1.3-6

April 13, 2014

Ella Deon Ballard

インスタンスベースおよび仮想設定セクションの更新。

改訂 1.3-4

September 18, 2013

Ella Deon Lackey

新規コンテンツおよび SAM 1.3 リリース用に再編成。

法律上の通知

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.