カスタマーポータルを使用したサブスクリプション管理

Red Hat Subscription Management 1

カスタマーポータルでサブスクリプションおよびシステムの管理

概要

本ガイドは、Red Hat カスタマーポータルでサブスクリプションとシステムを管理するための基本的な情報を提供します。
資産管理を効果的に行うには、ソフトウェアインベントリー (ソフトウェアがインストールされている製品タイプとシステム数の両方) を処理するメカニズムが必要です。Customer Portal Subscription Management のサブスクリプションサービスには、このメカニズムが実装されており、組織全体のサブスクリプションのグローバルな割り当てと、1 台のシステムに割り当てられている固有のサブスクリプションの両方に対する透過性を提供します。
本ガイドは、カスタマーポータルのサブスクリプション管理を使用してサブスクリプションおよびシステムを管理する方法を簡単に説明します。Red Hat Subscription Manager ローカルツールおよびサブスクリプションのコンセプト全般に関する詳細は、『Subscription Management Guide』を参照してください。

1. サブスクリプション管理とは

多くのソフトウェア会社は、販売したライセンスに基づいて製品へのアクセスを提供しています。Red Hat のソフトウェアは GNU Public License v2 で既に入手可能となっており、Red Hat のソースにアクセスすることができます。Red Hat の製品は、サブスクリプション を通じて入手できます。サブスクリプションは、これらの製品を対象に Red Hat が提供するサービス (コンテンツ配信、更新、ナレッジベース、サポートレベルなど) を定義します。Red Hat のサブスクリプションは個別のサーバーに許諾されます。これにより、そのサーバーにサポートを受ける権利が与えられることになります。
カスタマーポータルのサブスクリプション管理は、使用可能な製品のサブスクリプションと、そのサブスクリプションが割り当てられている IT インフラストラクチャーの構成要素との間の関係を構築します。
カスタマーポータルのサブスクリプション管理

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

IT 管理者は、使用可能な製品、その製品のサブスクリプションが割り当てられている場所、管理されているシステムについて把握する必要があります。Red Hat では、カスタマーポータルのサブスクリプション管理を介したサブスクリプションサービスを提供します。これは、Red Hat Subscription Manager を介してローカル (個々のシステム) またはグローバル (環境にあるすべてのサーバー) に管理されます。サブスクリプション管理の最終目的は、管理者がインフラストラクチャー内のどこに製品が割り当てられているのかを把握できるようにすることです。これには以下のような理由があります。
  • 第一の理由は、ご使用のシステムの全製品に有効かつアクティブなサブスクリプションがあることを確認して、管理者が法的要件 (PCI-DSS、SAS-70 など) や内部規定を遵守できるようにすることです。
  • 次は、ご使用のインフラストラクチャーに、数と種類が適切なソフトウェア製品を得ることができるようにすることです。ご使用の環境で実際に使用しているよりも 過剰に システムをサブスクライブしたり、余分なサブスクリプションを購入すると経費がかかります。使用しているサブスクリプションおよび使用可能なサブスクリプションを監視し、有効期限や更新をさらに効率的に管理することで、IT 経費を削減することができます。
  • そして最後に、サブスクリプション管理は、ご使用のシステムがアクセスする必要のある製品を容易に把握して、適切なサブスクリプションが確実に割り当てられるようにします。
カスタマーポータルのサブスクリプション管理は、管理されているシステム、サブスクリプションのコントラクト発効日、サブスクリプションの割り当て先など、アカウント全体で展開されているソフトウェア製品とサブスクリプションを組織全体にわたって監視する手段を提供します。カスタマーポータルのサブスクリプション管理により、インフラストラクチャー内のサブスクリプションや製品について把握することができます。これにより、インストールが制限されたり、先行して実施されることは ありません

1.1. サブスクリプションのプロセス

サブスクリプション管理は、ご使用の IT 環境のシステムと、Red Hat から入手できるソフトウェア製品の関係を特定し、構築する手段です。
サブスクリプション管理は、企業が所有するサブスクリプション、ローカルマシン、それらのマシンにインストールされている製品との関係を定義するための方法です。
  1. アカウントは、製品 に対する サブスクリプション を購入します。これにより、Red Hat の Content Delivery Network、エラータおよびパッチ、アップグレード、サポートがご利用になります。
    サブスクリプションは 数量 を定義します。数量とは、そのサブスクリプションによって、製品および全サポートサービスにアクセスできるシステムの数を意味します。
  2. サーバーは、サブスクリプション管理サービスの インベントリー に追加または 登録 されます。これは、サブスクリプションサービスが、サーバーを管理し、そのサブスクリプションを割り当てることができることを意味します。
  3. サブスクリプションはシステムに アタッチ し、システムが、その製品のサポートサービスおよびコンテンツを利用できるようになります。
カスタマーポータルのサブスクリプション管理によって、管理者はユニット (管理されたシステム、ドメイン、その他のエントリー) をインベントリーに追加したり、そのユニットにサブスクリプションをアタッチしたりすることができます。Red Hat Enterprise Linux システムでは 、特定のシステムを登録し、サブスクリプションを割り当てまたは削除することでシステムを管理するローカルの Red Hat Subscription Manager ツールで利用できます (GUI と subscription-manager はローカルマシンに制限されているため、インベントリー内の他のシステムを管理するのに使用することはできません)。

1.2. ホスト型サービスとオンプレミスサブスクリプション管理アプリケーション

ローカルシステムにおいて、サブスクリプションを割り当て、コンテンツを配信する最も簡単な方法は、Red Hat がホストしているネットワークに直接接続することです。
しかしながら、大規模な環境、高セキュリティの環境、その他の多くの状況では、そうしたホスト型の配置は実行できません。企業には、サブスクリプションを割り当て、ソフトウェアコンテンツをローカルに配信する方法が必要です。
この場合、オンプレミス サブスクリプション管理アプリケーションを使用した組織 が、カスタマーポータルのサブスクリプション管理のインベントリーに追加されます。一連のサブスクリプションがその組織に割り当てられます。割り当てられたサブスクリプションの一覧は マニフェスト に定義されますが、ここには、その組織のサブスクリプション、製品、およびコンテンツリポジトリーの概要が含まれます (したがって、管理されるすべてのシステムが対象です)。サブスクリプション管理アプリケーションでは、そのローカルサイトのシステムおよびユニットをすべて直接管理します。
これには、帯域幅を減らすことでパフォーマンス上のメリットがあります。また、管理者はローカルで柔軟にサブスクリプション管理を行うことができるため、管理上でも多大なメリットをもたらします。

1.3. カスタマーポータルのサブスクリプション管理と RHN Classic

サブスクリプション管理で行うプロセスの中には、聞き覚えのあるプロセスがあるかもしれませんが、それには理由があります。サブスクリプションは Red Hat Network の旧リリースでシステムに割り当てられていた可能性があるからです。カスタマーポータルのサブスクリプション管理では、チャンネル へのアクセス、またはコンテンツ配信ストリームに基づいていました。カスタマーポータルのサブスクリプション管理では、システムで 利用可能な製品とインストール済み製品 を確認することで、サブスクリプションを管理します。これにより、サブスクリプションとシステムの両方を、チャンネルによって定義されたあいまいなブロックではなく、個々のエンティティーとして扱います。
カスタマーポータルのサブスクリプション管理により、システムにインストールされている製品 (ローカルの Red Hat Subscription Manager ツールを使用する場合) と、システムが利用可能なサブスクリプションが分かります。これにより、IT 管理者はソフトウェアのインベントリーを管理し、従来のチャンネルベースのシステムでは不可能な方法でインフラストラクチャーを計画することができます。

注記

カスタマーポータルのサブスクリプション管理は 証明書ベースで で行われます。これは、サブスクリプションサービスと CDN に対してシステムを識別する公開鍵インフラストラクチャー (PKI) 証明書 (識別証明書) が各システムに発行されるためです。システムに新しいサブスクリプションを割り当てるとき、カスタマーポータルのサブスクリプション管理は、サブスクリプション情報を含む エンタイトルメント証明書 を発行します。製品がインストールされると、カスタマーポータルのサブスクリプション管理は、その一意の製品インストールを特定する 製品証明書 を発行します。
証明書を使用することにより、システムに対する個々のサブスクリプションと製品を管理するプロセスが簡略化され、セキュリティが強化されます。
カスタマーポータルのサブスクリプション管理と、RHN Classic は相互に排他的です。システムは、いずれか一方のサブスクリプションサービスで管理され、両方で管理されることはありません。ただし、これらのシステムは「連動」しています。カスタマーポータルのサブスクリプション管理でシステムを登録している場合は、レガシーの RHN Classic ツールに登録されているエラーは存在しません。逆の場合も同じです。両方のサービスはシステムに与えられているサブスクリプションを認識します。

1.4. サブスクリプション関連用語のクイックリファレンス

システム
すべてのエンティティー (物理または仮想マシン) です。これは、サブスクリプションサービスのインベントリーにあり、割り当て可能なサブスクリプションを持っています。
サブスクリプション
サブスクリプションは、使用可能な製品、サポートレベル、製品がインストールできるサーバーの数量 (または数)、製品が使用可能なアーキテクチャー、製品を提供するコンテンツリポジトリー、および製品に関連するその他の情報を定義します。
アタッチ
サブスクリプションをシステムに割り当てることです。
使用状況
組織に利用可能なサブスクリプションの総数と、カスタマーポータルのサブスクリプション管理、RHN Classic などのサブスクリプション管理アプリケーションに割り当てられているサブスクリプションの総数です。
過度の使用
購入したよりも多くのサブスクリプションを割り当てている場合の組織のステータス。これは、インフラストラクチャーが、カスタマーポータルのサブスクリプション管理および RHN Classic の両方を使用してシステムを登録すると発生します。同じサブスクリプションプールから取り出していますが、集計が異なるからです。
サービスレベルの設定
インストール済み製品に対して使用するサービスレベルに基づいた設定。
リリース設定
製品を制限し、特定のオペレーティングシステムのマイナーリリースにアップデートする設定。
組織またはサブスクリプション管理アプリケーションの組織
サブスクリプションのサブセットを含むローカルの細分化。これは、IT 環境を反映するサブスクリプション構造を定義します。組織は、企業内の物理ロケーション、または組織の部門で調整できます。
ホスト型
オンプレミスアプリケーションではなく、Red Hat が提供するサブスクリプションおよびコンテンツサービス。
使用可能
(その一部またはすべてが) システムに割り当てられていないサブスクリプション。
カスタマーポータルのサブスクリプション管理
ホスト型サブスクリプション管理サービス。このサービスでは、サブスクリプションは、チャンネルへのアクセスではなく、製品に基づいて管理 (され、発行した証明書により証明) されます。
CDN
Content Delivery Network のことです。
チャンネル
ソフトウェア製品を軸とした一連のパッケージ、関連製品のグループ、または製品のバージョンです。サブスクリプションを定義するチャンネルベースの方法は、RHN Classic によってのみ使用されます。
互換性
システムのアーキテクチャーと一致する使用可能でアクティブなサブスクリプションです。
ユニット
すべてのエンティティー (物理マシン、仮想マシン、ドメイン、または人) です。これは、サブスクリプション管理サービスのインベントリーにあり、割り当て可能なサブスクリプションを持っています。
コンテンツ
ソフトウェアのダウンロードと更新です。
コンテンツ配信ネットワーク (CDN)
ソフトウェア、更新、パッケージを配信するための Red Hat ホスト型のコンテンツリポジトリーおよび技術です。
エンタイトルメント証明書
システムのサブスクリプションの一覧が含まれる証明書です。製品および数量に関する情報、コンテンツリポジトリー、ロール、さまざまな名前空間が含まれます。
識別証明書
システムをサブスクリプション管理サービスに登録する際に、システムに発行される証明書です。この証明書を使用して、サブスクリプション管理サービスに対してシステムを認証し、特定します。
インベントリー
サブスクリプション管理サービスに登録しているユニット (システム、ドメイン、人、またはアプリケーション) の一覧、および組織が購入した (現在、期限切れ、今後の) サブスクリプションの一覧です。
ライセンス
ソフトウェアの使用方法を定める法的ステートメントです。Red Hat の製品は、GPLv2 でライセンスが供与されます。サブスクリプションは、ある製品が Red Hat のコンテンツストリームにより更新され、サポートを受ける回数 (または数量) を決定します。ただし、ソフトウェア製品をインストールまたは使用する機能は制限しません。
製品
Red Hat Enterprise Linux または Directory Server のような個々のソフトウェア製品です。
製品証明書
製品をインストールした時点でシステムに生成されインストールされる証明書です。これには、製品がインストールされている特定のシステム (そのハードウェアやアーキテクチャーなど) の情報、製品名、バージョン、名前空間が含まれています。これにより、サブスクリプション管理サービスと CDN に対する固有の製品インストールを特定します。
登録する (動詞)
サブスクリプション管理サービスのインベントリーに (物理または仮想) システムを追加することです。
RHN Classic
従来の RHN システムです。今後数年間は使用できますが、段階的に廃止されていきます。
ステータス
システムにインストールされているすべての製品が、アクティブなサブスクリプションで完全にカバーされているかどうか。
サブスクリプションマネージャー
サブスクリプションの表示や割り当て、インベントリー内のシステム管理に使用する一連のツールです。Subscription Manager ツールは 2 つあります。
  • ローカルシステムにインストールされ、そのローカルシステムを管理する Subscription Manager GUI です。これは subscription-manager-gui を実行するか、システム => 管理 メニューで開きます。
  • ローカルシステムにインストールされ、そのローカルシステムを管理する Subscription Manager CLI です。subscription-manager のコマンドを実行してさまざまな操作を行います。このツールは、キックスタートインストールなど、サブスクリプションのスクリプトの対話にも使用できます。
サブスクリプション管理サービス
バックエンドサーバーであり、システムのインベントリーを作成することで個々のシステムと対話します。コントラクト、数量、終了日などのサブスクリプションのインベントリーも管理します。これは、新しいシステムが登録される時、サブスクリプションを割り当てる時、製品がインストールされる時です。サブスクリプション管理サービスは変更を管理し、対応する証明書をシステムに発行して変更に印をつけます。サブスクリプション管理サービスは、ハードウェアやアーキテクチャーの制限など製品のルールも定義し、サブスクリプションの割り当てをサポートします。
X.509 証明書
固有の証明書規格であり、SSL 通信および公開キーインフラストラクチャーに使用する証明書の形式を決定するために使用されます。これにより、RHN Classic システムで使用する Satellite 証明書の新しいサブスクリプション管理サービスによって使用される証明書を明示します。

2. カスタマーポータルのサブスクリプション管理のユーザーパーミッション

Red Hat ログインでユーザーに適切なユーザーパーミッションがある場合に限り、カスタマーポータルのサブスクリプション管理は利用できます。適切なパーミッションがないと、カスタマーポータルのサブスクリプション管理エリアへのアクセスが制限されます。
ユーザーアカウントには、カスタマーポータル: Manage subscriptions (サブスクリプションの管理) パーミッションが必要です。デフォルトでは、全ユーザーにはこのパーミッションが付与されていますが、管理者は ユーザー管理 のエリアで変更できます。
サブスクリプション管理のパーミッション

図2 サブスクリプション管理のパーミッション

3. サブスクリプションおよびシステム情報の概要の表示

3.1. 概要ページ

サブスクリプション管理の最終的な目標は、管理者が、システムと、そのシステムが使用するサブスクリプションとの関係を特定できるようにすること です。これは、外部から潜在的なサブスクリプションを見るローカルシステムのビューと、システムと全サブスクリプションに関するインフラストラクチャーの全体図を見るプライマリーアカウントのビューの 2 つの異なる視点から実行することができます。
Red Hat サブスクリプションマネージャ GUI および CLI はいずれも、ローカルマシンのみを管理するローカルクライアントです。これらのツールで表示できる情報は若干限定されており、1 台のシステムの視点からの情報 (利用可能なサブスクリプションなど) のみが表示されるです。そのため、期限切れおよび使用しているサブスクリプションや、他のアーキテクチャー用のサブスクリプションは表示されません。
カスタマーポータルのサブスクリプション管理は グローバルな ツールで、サブスクリプションとシステムに対する完全なアカウント全体のビューを提供することを目的としています。カスタマーポータルのサブスクリプション管理は、システムの登録、サブスクリプションの割り当て、システム情報や UUID の表示など、オンプレミスツールのタスクを多数実行します。サブスクリプション自体の管理 (例: コントラクト情報の表示やサブスクリプションの更新) を行うことができます。このようなタスクは、ローカルクライアントでは実行できません。
カスタマーポータルのサブスクリプション管理では、サブスクリプションについて 2 つの異なる視点が利用できます。
  • アカウントの全 使用中サブスクリプション のビュー
  • インベントリー内の全 システム のビュー
カスタマーポータルのサブスクリプション管理は、インフラストラクチャー (サーバー) とサブスクリプションとの間の関係を構築します。カスタマーポータルのサブスクリプション管理は、システムを管理し、既存のサブスクリプションをアタッチする インベントリー ツールです。カスタマーポータルのサブスクリプション管理は、サブスクリプションの入手と直観的につながるため、管理者はアカウントに対しサブスクリプションの購入と更新を行うことができます。
カスタマーポータルのサブスクリプション管理メニュー

図3 カスタマーポータルのサブスクリプション管理メニュー

サブスクリプション管理の概要ページでは、インベントリー内のシステムおよびその他のユニットの合計を種類別にまとめています。また、サブスクリプション管理下で管理されるシステムの数、RHN Classic 下で管理される数も表示しています。

注記

カスタマーポータルのサブスクリプション管理は、アカウントの全種類のシステムとユニットを、全体的に理解することができます。これは、サブスクリプションを計画して、効果的に割り当てるために重要なことです。ただし、システムにどの製品がインストールされているか、サブスクリプションがそうした製品に割り当てられているかどうかは明らかでは ありませんインストール済み ソフトウェアのサブスクリプションを監視するには、ローカルの Red Hat Subscription Manager ツールを使用する必要があります。
カスタマーポータルのサブスクリプション管理の概要ページ

図4 カスタマーポータルのサブスクリプション管理の概要ページ

3.2. サブスクリプションの使用

管理者は、サブスクリプションがインベントリー内の任意のシステムにインストールされている製品またはアーキテクチャーに一致しているかどうかにかかわらず、すべてのサブスクリプションを完全に把握している必要があります。カスタマーポータルは、若干異なる視点でサブスクリプションを確認する 3 つの方法を提供します。
  • アクティブかつ割り当て済みのサブスクリプションの数 (合計)
  • カスタマーポータルのサブスクリプション管理で使用できるすべてのサブスクリプション
  • 特定のシステムのアーキテクチャー、ソケット数、インストール済み製品、もしくはその他の特性と一致する、カスタマーポータルのサブスクリプション管理内のサブスクリプション
サブスクリプションの概要 ページには、使用状況サマリーへのリンクがあります。サブスクリプションの使用状況 ページには、RHN Classic またはカスタマーポータルのサブスクリプション管理のどちらで使用されるかに関わらず、アカウント全体で現在アクティブなサブスクリプションの合計と、使用しているサブスクリプションの合計が表示されます。この数は、サブスクリプション管理サービスでサブスクリプション数が変更するたびに更新されます。
この合計は、最初にタイプ別に分けられ、続いてサブスクリプション管理サービス別にそのタイプのサブスクリプション数が表示されます。
全サブスクリプションサービスに対するサブスクリプションの合計

図5 全サブスクリプションサービスに対するサブスクリプションの合計

4. システムの管理

4.1. 新しいシステムの登録

システムにサブスクリプションを割り当てる前に、カスタマーポータルのサブスクリプション管理で インベントリー にそのシステムを追加しておく必要があります。このプロセスを 登録 と呼びます。登録は、多くの場合、マシンの設定や管理の一環として行われるローカル操作ですが、カスタマーポータルのサブスクリプション管理による登録および登録解除は、インフラストラクチャー全体を管理するにあたって、より包括的な概観が必要な場合や、外部のネットワークに接続されていないシステムを管理する必要がある場合に非常に役立ちます。
一部のシステムには、インターネット接続機能がない場合がありますが、管理者は、そのようなシステムに対しても、サブスクリプションを割り当てて監視する必要があります。このような場合には、サブスクリプションマネージャーに依存して登録を行うのではなく、手動でシステムを登録することで対処できます。このプロセスには大まかに分けて 2 つの手順があります。まずはサブスクリプションサービスでエントリーを作成し、次にシステムを設定します。
  1. サブスクリプション タブを展開し、サブスクリプション管理 項目を開き、ユニット 項目を選択します。
  2. 表の上部で 登録 リンクをクリックします。
  3. 新しいシステムに情報を入力します。
    システムが利用可能なサブスクリプションを確認するために、アーキテクチャーとハードウェアの情報が必要です。
    • エントリー名。通常はホスト名です。
    • システムのタイプ。物理または仮想です。
    • アーキテクチャー。互換性のあるサブスクリプションを決定するために使用します。
    • ソケットの数。物理ソケットの数か、仮想マシンの場合は CPU の数になります。一部のサブスクリプションでは一定のソケット数がカバーされますが、大規模なシステムにはサブスクリプションが複数必要になる場合もあります。
  4. システムを作成したら、システムに適切なサブスクリプションをアタッチします。
    1. アタッチ済みのサブスクリプション タブを開きます。
    2. サブスクリプションのアタッチ リンクをクリックします。
    3. 割り当てるすべてのサブスクリプションのチェックボックスをクリックしてから、選択項目の追加 ボタンをクリックします。
  5. ダウンロード リンクをクリックして、各サブスクリプションのエンタイトルメント証明書をダウンロードします。このファイルは、フラッシュドライブなどのポータブルメディアに保存してください。
  6. オプションとして、識別証明書 タブを開いて、ダウンロード ボタンをクリックします。登録したシステムの識別証明書は、システムがサブスクリプション管理サービスに接続するのに使用することができます。システムが完全にオフラインになる場合にはこの操作は不要ですが、システムをネットワークに接続する可能性がある場合は有用です。
  7. エンタイトルメント証明書をメディアデバイスからシステムにコピーします。
  8. エンタイトルメント証明書をインポートします。これを行うには、Subscription Manager UI の システム メニューで 証明書のインポート 項目を使用するか、以下のように import コマンドを使用します。
    [root@server ~]# subscription-manager import /
         --certificate=/tmp/export/entitlement_certificates/596576341785244687.pem /
         --certificate=/tmp/export/entitlement_certificates/3195996649750311162.pem
    Successfully imported certificate 596576341785244687.pem
    Successfully imported certificate 3195996649750311162.pem
  9. 識別証明書をダウンロードした場合は、cert.pem ファイルを直接 /etc/pki/consumer ディレクトリにコピーします。たとえば、以下のコマンドを実行します。
    [root@server ~]# cp /tmp/downloads/cert.pem /etc/pki/consumer

4.2. システムの一覧: インベントリーの表示

カスタマーポータルのサブスクリプション管理で登録したシステムの一覧が インベントリー に表示されます。カスタマーポータルのサブスクリプション管理のシステムインベントリーは、アカウント全体を網羅しており、カスタマーポータルのサブスクリプション管理で表示できます。システムリストを表示する方法はいくつかあります。最も簡単な方法は、サブスクリプション メニューから コンシューマー の項目を選択することです。
メインメニューのリンク

図6 メインメニューのリンク

もしくは、サブスクリプション管理 ページで、ユニットタイプをクリックします。
サブスクリプション管理ページ

図7 サブスクリプション管理ページ

システムの表にはシステム名 (通常は完全修飾ドメイン名またはシステム名) と、システムのタイプが表示されます。デフォルトでは、システムとユニットの一覧が表示されます。タイプまたはシステム名で絞り込むことができます。
システム一覧

図8 システム一覧

4.3. システムの詳細: システム情報の表示

ユニット > タイプ リストでシステム名をクリックすると、そのシステムの詳細ページが開きます。詳細は、サブスクリプション、システム情報、サブスクリプション設定を表示します。
システムの詳細

図9 システムの詳細

システム情報 のタブには、システムに関して集められたシステム情報が表示されます。これは、ハードウェア、アーキテクチャー、システム設定、オペレーティングシステムの情報です。この種類の情報は、プラットフォームが仮想または物理マシンか、オペレーティングシステムのバージョン、そしてシステム設定に応じて変わります。システム情報を使用して、システムが使用可能な 互換性のあるサブスクリプション を決定します。つまり、アーキテクチャー、ハードウェア、オペレーティングシステムのバージョンに対応したサブスクリプションです。
システム情報

図10 システム情報

注記

カスタマーポータルのサブスクリプション管理を使用して、システムを手動でインベントリーに追加した場合には、限定的なシステム情報のみが表示されます。その内容は、登録時に入力したシステム情報によって決まります。
ローカルの Red Hat Subscription Manager ツールを使用して登録したシステムでは、非常に多くのシステム情報が一覧表示される場合があります。これは、オンプレミスの Red Hat Subscription Manager システムサービスで実行されるシステムスキャンの結果によって決まります。

4.4. システムおよびサブスクリプションのアクティブ化

サードパーティーベンダーからシステムまたはパッケージを購入すると、事前定義されたサブスクリプションのセットが同梱されている場合があります。
新しいサブスクリプションをシステムに割り当てるのではなく、既存のサブスクリプションを 交換 または アクティブ化する ことが可能です。サブスクリプションの作成時に、インストール番号 と呼ばれる 16 桁の番号が生成されます。そのキーはサブスクリプションと引き換えに提供されます。
  1. サブスクリプション タブを展開し、サブスクリプション エリアを開き、概要 項目を選択します。
  2. 要約 エリアの右上にある サブスクリプションをアクティブにする リンクをクリックします。
  3. サブスクリプションのアクティベート ページで、 16 桁のインストール番号を入力します。
  4. アクティブ化するウィザードを続行してください。

4.5. システムの削除

システムは、カスタマーポータルのサブスクリプション管理を介して、サブスクリプション管理サービスから削除または登録解除 することができます。これは、Red Hat Subscription Manager で unregister コマンドを実行した場合と同じです。
オフラインシステムの場合は、システムの登録解除にローカルツールを使用することはできない場合があります。カスタマーポータルからシステムを手動で解除すると、割り当てているサブスクリプションが解放されます。
  1. サブスクリプション タブを展開し、サブスクリプション エリアを開き、概要 項目を選択します。
  2. 右側の 使用率 エリアで、サブスクリプション管理 リンクをクリックします。
  3. サブスクリプション管理 ページでシステムタイプのリンクをクリックします。
  4. 削除するシステムの横のチェックボックスを選択します。

    注記

    一度に削除できるシステムは 5 台までです。

注記

システムを 1 台削除する場合は、詳細ページの このシステムの削除 ボタンをクリックして削除することもできます。

4.6. システムの識別証明書の表示および再生成

カスタマーポータルのサブスクリプション管理は 証明書ベース です。標準の SSL 証明書は、サブスクリプション管理サービスに対するシステムとアプリケーションの組織を認証するのに使用します。これは、識別証明書と呼ばれます。
識別証明書には、インベントリー内のシステムまたはアプリケーション組織に対する UUID (証明書の CN)、証明書のシリアル番号、識別証明書の作成日と終了日 (システムが登録された日を作成日とします) が含まれます。
識別証明書タブには、識別証明書にある関連情報がすべて含まれています (シリアル番号、作成日、終了日)。システムまたはアプリケーション組織の UUID は、それを証明書内で特定するために使用されます。
識別証明書の詳細

図11 識別証明書の詳細

システムの識別証明書が削除または破損したため、もしくはシステムを変更したために、システムの識別証明書が失われてしまう事態も起こり得ます。識別証明書は、システムに最初に生成された識別証明書と同様、Base64 でエンコードされた PEM 形式のファイルで、カスタマーポータルのサブスクリプション管理から直接ダウンロードできます。
-----BEGIN CERTIFICATE-----
MIIDdzCCAuCgAwIBAgIIASDVoX2P1a8wDQYJKoZIhvcNAQEFBQAwSzEqMCgGA1UE
AxMhY2FuZGxlcGluMS5kZXZsYWIucGh4MS5yZWRoYXQuY29tMQswCQYDVQQGEwJV
UzEQMA4GA1UEBxMHUmFsZWlnaDAeFw0xMTAzMDkxNTAxMDVaFw0xMjAzMDkxNTAx
MDVaMC8xLTArBgNVBAMMJDdmY2Y2NjYwLTdkZDYtNDdjZi04ZjJjLTQ0NmJiMWE1
YWQyZjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJA0wmfB9znYeZu2
lOCga8ERkKPHDZtBKJknT/L74U4+ZQb7wFfRhhqeAv38erEyH40o79iVZJAc0cnT
pBdUYVN9ronv8vOFgdkqBdrjy4t7qq8ofI6dpj0U8fTaisU82WXBq1t41dn7OrJT
vbRCa4ZCt3FMzTkthd1ZKniLgfvokeGr6gVnh4jEgoFuMPHxigXKPDBvn7R5mf0w
vNM1m2/1OKMPI4u5ZLsN/XTyd4t3MSX25SFqobtkVABW7jVlRvyWuR7V6PxpzmTZ
7CjodUY+CVZrFIiL8s2pMkX38KCEXlUuH8DXymDxj4IAMSYC2SW7F7z2YQNTbAvK
kcklWHECAwEAAaOB+zCB+DARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgSw
MHsGA1UdIwR0MHKAFGiY1N2UtulxcMFy0j6gQGLTyo6CoU+kTTBLMSowKAYDVQQD
EyFjYW5kbGVwaW4xLmRldmxhYi5waHgxLnJlZGhhdC5jb20xCzAJBgNVBAYTAlVT
MRAwDgYDVQQHEwdSYWxlaWdoggkA1s54sVacN0EwHQYDVR0OBBYEFOP0p6JiVnQ2
SBmscyhvB1It2bjmMBMGA1UdJQQMMAoGCCsGAQUFBwMCMCUGA1UdEQQeMBykGjAY
MRYwFAYDVQQDDA10ZXN0LXN5c3RlbS0xMA0GCSqGSIb3DQEBBQUAA4GBADOoBuca
Jg244L6LLMw8ov32VK/kRCk9z8qcMA6y8+jL1yrfW//9Ig1BJiWKnrqln3eSNvf+
zouqNgaS4kvQeQf51lPVws++q3J9/q1i4WvJ4kDRN7HOtasf6KmSBpVM6dSDLrX3
nEZbvD0hT+2YVj/DJ7IXvQ9F3KXDkcwb4Lrh
-----END CERTIFICATE-----
また、元の識別証明書を無効にし、その代わりに新しい識別証明書を生成することもできます。これを証明書の 再生成 と呼びます。再生成された識別証明書の UUID は元の識別証明書と同じです (つまり、インベントリー内における配置と全サブスクリプションが維持されます) が、シリアル番号は異なり、作成日と終了日も新しくなります。

4.7. 登録したシステムのエラータ通知の管理

サブスクリプション管理の一環として、ソフトウェアの更新および新しいリリースの監視があります。利用可能な更新があるたびに (バグ修正後の新しいリリース)、通知の電子メールを管理者に送信することができます。
この通知が優れている点は、登録済み、かつ割り当てられている製品用のサブスクリプションがあるシステムのみを対象として送信されることです。製品に割り当てられたサブスクリプションを持つシステムがない場合は、アカウントにサブスクリプションがあったとしても、通知は送られません。
エラータ通知は、個別のシステムではなく、ユーザーアカウント用の設定としてセットされます。そのため、エラータの更新を確認する場合は、サブスクリプション管理は固有のシステムではなくインベントリー全体を確認します。
登録している あらゆる システムに影響を及ぼす場合は、エラータ通知が送信されます。ただし、電子メールには、実際に影響を受けているシステムの一覧が記載されません。

注記

カスタマーポータルのサブスクリプション管理と RHN Classic は別々のインベントリーを持っているため、それぞれ独自のエラータ通知設定があります。エラータ通知がすでに RHN Classic に有効であっても、カスタマーポータルのサブスクリプション管理に対しても有効にする必要があります。そうしないと、カスタマーポータルのサブスクリプション管理のインベントリーで管理されるシステムに対するエラータ通知は送信されません。
ユーザーアカウントのエラータ通知を設定します。
  1. カスタマーポータルの右上隅にある、ログインユーザーの詳細を展開します。
  2. アカウント設定 リンクをクリックします。
  3. 設定のメインページで、Red Hat アカウント ボックスの真ん中にある アカウントの詳細 リンクをクリックします。
  4. 左側の 好みの設定 メニューにある、Errata Notifications リンクをクリックします。
  5. 更新を受け取るエラータタイプのチェックボックスを選択します。セキュリティーエラータは重大なセキュリティーの問題に関連し、バグ修正と機能強化の通知は製品への増分更新に関連します。
  6. エラータ通知を受け取る頻度を設定します。選択したすべてのタイプのエラータ通知に適用されます。
  7. 保存 ボタンをクリックします。

5. サブスクリプションの管理

システムにサブスクリプションを割り当てることで、そのシステムはサブスクリプション内の Red Hat 製品をインストールして更新することができるようになります。サブスクリプションとは、購入した全製品の全バリエーションの一覧であり、製品とサブスクリプションが利用できる回数を定義します。この数量は、概して利用可能なユーザーライセンス数です。これらのライセンスの 1 つがシステムに割り当てられると、そのサブスクリプションはそのシステムに アタッチ されます。

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

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

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

5.1.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 を掛けた一部のサブスクリプションでは、データセンターの仮想ゲストは、個々のサブスクリプションを消費しません。複数の製品に関する一部のサブスクリプション (クラウドインフラストラクチャー) は、別のシステムにインストールされます。さらに 以前の、2013 年以前のサブスクリプションはすべて同じ環境にインストールされます。サブスクリプションの使用状況ページまたはサブスクリプション管理ツールは、コントラクトで購入した数量を反映しない可能性があります。基本的な数は同じです。異なる点は、ほとんど、全体の数を維持するか、より柔軟なサブスクリプションタイプを維持するために変更を反映しているという点です。

5.2. システムへのサブスクリプションのアタッチ

基本的に、サブスクリプションはソフトウェアダウンロードおよび更新へのアクセスを提供し、サポートレベルを定義します。システムがソフトウェアを使用できるようにするには、そのアクセスの権利を与えるサブスクリプションが必要です。アタッチ済みのサブスクリプション タブを使用して、システムに割り当てられるサブスクリプションを制御します。
アタッチ済みのサブスクリプション タブには、現在システムに割り当てられているサブスクリプションが表示されます。サブスクリプションのアタッチ リンクをクリックすると、ハードウェアと互換性のあるサブスクリプションに基づき、システムが利用可能なすべてのサブスクリプションが表示されます。

注記

使用可能なサブスクリプションは、現在インストール済みの製品と互換性があるサブスクリプションにより決定される場合もあります。このサブスクリプションは、 Red Hat Subscription Manager のローカルクライアントでのみ表示できます。Customer Portal Subscription Management では、現在システムにインストールされている製品に関する情報が確認できないためです。Customer Portal Subscription Management には、サブスクリプションがサブスクリプションサービスのインベントリーをベースにしているという情報だけがあります。
使用可能なサブスクリプションの一覧には、(名前の他に) 製品に関する 3 点の重要な情報が表示されます。
  • サブスクリプションのサービスレベル
  • サブスクリプション購入のコントラクト番号。記録の保持と追跡に重要です。
  • そのサブスクリプションに対して使用できる数量。サブスクリプションはまとまった数量で購入します。この数は購入した総数のうちどれだけ残っているかを示しています。
  • サブスクリプションの開始日と終了日。これにより、有効期限が切れるまで数日間しか有効でないサブスクリプション、または、まだアクティブでないサブスクリプションを割り当てることがないようにします。

注記

フィルター ボックスを使用すると、サブスクリプションの一覧を絞り込むことができます。この機能は、組織が多くのサブスクリプションを持っているため、複数の検索結果ページ間を移動する必要がある場合に便利です。
  1. 「システムの一覧: インベントリーの表示」にあるように、システムエントリーを開きます。
  2. アタッチ済みのサブスクリプション タブを開きます。
  3. サブスクリプションのアタッチ リンクをクリックします。
  4. アタッチするすべてのサブスクリプションのチェックボックスをクリックします。
    通常、サブスクリプションはシステムと 互換性がある、すなわち、システムが認識したハードウェアとアーキテクチャー、設定 (サービスレベルまたはリリースバージョン) にサブスクリプションが適合する場合のみ表示されます。システムのハードウェアとは互換性がないサブスクリプションも含めた、すべてのサブスクリプションを表示するには、このシステムに一致するサブスクリプションのみを表示 チェックボックスのチェックマークを外します。
  5. 選択項目のアタッチ ボタンをクリックします。

5.3. サブスクリプションのアタッチ

サブスクリプションサービスは、システムに割り当てられたサブスクリプションを監視し、有効期限が近づくタイミングを追跡します。サブスクリプションの期限が切れる 24 時間以内に、Subscription Manager により、適合する新しいサブスクリプションにシステムが自動的に再アタッチされます。 これにより、サブスクリプションステータスは緑色のままになります。
そのシステムに利用できるアクティブかつ互換性のあるサブスクリプションが存在する限りは、システムの自動アタッチにより、システム内の製品がサブスクリプションなしの状態になることはありません。

5.3.1. システムの自動アタッチを有効化

自動アタッチは、システムにおいてデフォルトで有効なため、サブスクリプションステータスを維持管理できます。自動アタッチを無効にして、再度有効にするには、システムの詳細ページにある 無効化/有効化 ボタンを切り替えます。
自動アタッチの切り替え

図12 自動アタッチの切り替え

5.3.2. すべてのシステムで自動操作の開始

個々のシステムで自動アタッチが設定され、通常はローカル操作になります。ただし、新しいサブスクリプションセットを購入したり、新たに大量のシステムをプロビジョニングしたときなどに、システムで非同期の一括更新を開始することがより簡単でより有益である場合があります。
ユニット エリアの下部には、登録したすべてのシステムで自動アタッチ操作を実行するボタンがあります。これにより、利用可能なサブスクリプションが必要に応じてシステムに適用され、すべてのシステムを適切なステータス (緑色) にします。
すべてのシステムのアタッチ

図13 すべてのシステムのアタッチ

5.4. サブスクリプションの自動アタッチの優先順位の設定

(新しい製品がインストールされたり、古いサブスクリプションの有効期限が切れたときに) サブスクリプションプロセスがサブスクリプションを自動的に更新してアタッチすると、サブスクリプションサービスが、システムの属性に基づいて最適なサブスクリプションを選択します。属性には、ソケットの数やアーキテクチャーなどのハードウエアの特性や、システムや製品の特性が含まれます。
特定の属性に利用可能なオプションが複数ある場合があります。そのような場合に、管理者は、属性に 優先順位 を設定して、自動アタッチプロセスが選択するサブスクリプションを定義します。たとえば、各サブスクリプションにはサービスレベルの優先順位が定義されています。複数のサービスレベルで利用できるサブスクリプションもあります。サービスレベルの設定には、希望するサービスレベルに一致するサブスクリプションに対する優先順位により、サブスクリプションが自動的に選択されることを意味します。

5.4.1. 推奨されるサービスレベルの設定

サブスクリプションの一部は、システム上の製品に対して定義されるサービスレベルです。Red Hat のサービスレベルは、コントラクトで定義されています。製品サポートのサービスレベルの概要は、https://access.redhat.com/support/offerings/production/sla.html に記載されています。
サポートレベルには 3 つの基本的なレベルがあります。
  • プレミアム
  • 標準
  • なし (セルフサポート)
アカウントには複数のサポートレベルを設定できます。同じ製品に対しても可能です。ただし、IT 環境内のすべてシステムが同じ応答時間とサポートを必要とするわけではありません。たとえば、実稼働システムはビジネスクリティカルなシステムであるため、通常はプレミアムのサポートレベルを選択します。一方、開発中のシステムにはスタンダードレベルのサポートか、セルフサポートを選択できます。

注記

デフォルトでは、サブスクリプションおよびシステムには、利用可能なサポートレベルの中で一番高いものが選択されます。
システムの設定時に、推奨されるサービスレベルを割り当てることができます。サブスクリプションがシステムに自動アタッチし、推奨されるサービスレベルが利用可能な場合、その優先順位に合うサブスクリプションが使用されます (サブスクリプションを手動で選択して割り当てる場合は、サービスレベルの設定は評価および適用されません)。

注記

サービスレベルの設定は、最初に、登録時にクライアントでローカルで設定する必要があります。以下のように自動アタッチするか、後ほど設定を編集します。
[root#server ~]# subscription-manager attach --auto --servicelevel Premium
システムにサービスレベルの優先順位をセットしたら、カスタマーポータルで閲覧、編集することができます。
システムの詳細ページにサービスレベルの優先順位が設定されます。
サービスレベルの優先準備

図14 サービスレベルの優先準備

5.4.2. オペレーティングシステムのリリースバージョンの設定の表示

IT 環境の多くは、一定のセキュリティーレベルか他の基準に合致していると認定されている必要があります。その場合、主要なアップグレードの計画と管理は注意して行う必要があります。管理者がただ yum update を実行して次のバージョンに移行できるものではありません。
リリースバージョンを指定すると、システムが、最新バージョンのリポジトリーを自動的に選択するようなことはせず、オペレーティングシステムのバージョンに関連したコンテンツリポジトリーにアクセスを制限します。
たとえば、指定したオペレーティングシステムバージョンが 6.3 の場合は、他のリポジトリーが利用可能であっても、システムにインストールされる製品およびアタッチされるサブスクリプションには、常に 6.3 のコンテンツリポジトリーが選ばれます。
その特定バージョンのパッケージ、更新、およびエラータだけがシステムに使用されます。
リリースバージョンの設定は、ローカルの Red Hat Subscription Manager ツールを使用してのみセットできます。ただし、ローカルシステムにリリース設定を行った場合は、ポータル内のシステムでその設定を閲覧できます。
オペレーティングシステムのリリースバージョンの設定

図15 オペレーティングシステムのリリースバージョンの設定

5.5. システムのサブスクリプションの表示

システムにサブスクリプションを割り当てると、そのサブスクリプションは アタッチ済みのサブスクリプション タブに、コントラクト番号と終了日とともに表示されます。
サブスクリプションの詳細のリンク

図16 サブスクリプションの詳細のリンク

サブスクリプションの 表示 リンクをクリックすると、そのサブスクリプションに関するさらに詳しい内容が表示されます。これには、サブスクリプションが提供する製品の一覧、注文情報、その特定のサブスクリプションで使用可能なサブスクリプションの数量とタイプ、および証明書 (システムに再生成またはダウンロードして表示することが可能) が含まれます。
サブスクリプションの詳細

図17 サブスクリプションの詳細

5.6. ステータスの確認

カスタマーポータルでは、システムのサブスクリプションをすべて最新に保つことができます。システムの詳細ページには、証明書のステータス サマリーがあり、システムにインストールされているすべての製品に適切なサブスクリプションが適用されているかどうかを示しています。
サブスクリプションのステータス

図18 サブスクリプションのステータス

ステータスには、現在のサブスクリプションが有効な期間と、サブスクリプション証明書が最後に更新された日時が表示されます。
システムサブスクリプションのステータスには、以下の色が付いています。
  • 緑色 は、すべての製品に有効なサブスクリプションがあることを意味します。
  • 黄色 は、更新は有効ですが、一部の製品にアクティブなサブスクリプションがない可能性があることを意味します。
  • 赤色 は、更新が無効であることを意味します。
システムのステータスは、システム情報、インストール済み製品、ローカルのサブスクリプション証明書に基づき、ローカルシステムにより決定されます。この情報は、24 時間ごとに (デフォルト設定) サブスクリプションサービスと同期します。カスタマーポータルは、インストール済み製品の情報は格納せず、システム自体からの情報に依存しています。システムがオフラインでシステム情報を送信できない場合、カスタマーポータルは不明のステータスを反映します。
不明なサブスクリプションのステータス

図19 不明なサブスクリプションのステータス

5.7. システムからサブスクリプションの削除

システムからサブスクリプションを削除して、別のシステムがそのサブスクリプションを使用することができます。システムからサブスクリプションを削除するには、アタッチ済みのサブスクリプション タブのサブスクリプションの横にある 削除 リンクをクリックします。

5.8. 期限が切れたサブスクリプション、および期限切れになるサブスクリプションの管理

概要ページの上部には、サブスクリプションに関連するシンプルかつクリアな 3 つの数字が表示されています。これらは、アクティブなサブスクリプションの数、120 日以内に期限切れになるサブスクリプションの数、過去 30 日間で期限切れになった (更新可能な) サブスクリプションの数を示しています。
これらはアカウント全体の合計数です。アタッチされているサブスクリプションの数、システムの数、サブスクリプションがカスタマーポータルのサブスクリプション管理、RHN Classic、サブスクリプション管理アプリケーションに登録されているかどうかは重要ではありません。
サブスクリプションの概要

図20 サブスクリプションの概要

任意の数字をクリックすると、該当するカテゴリーのサブスクリプションインベントリーのタブが開きます。
  • アクティブなサブスクリプション をクリックすると、アクティブ タブに移動します。
  • 120 日以内に期限切れになるサブスクリプション をクリックすると、更新可能 タブに移動します。
  • 最近期限切れになったサブスクリプション をクリックすると、直近の期限切れ タブに移動します。
タブは、サブスクリプション名、コントラクト番号、開始日、終了日を表示しているため、サブスクリプションの監視と管理を容易に行うことができます。
直近の期限切れのタブ

図21 直近の期限切れのタブ

更新可能 または 直近の期限切れ タブ内の任意のサブスクリプション名をクリックすると、そのコントラクトに関する詳細ページが更新情報とともに表示されます。サブスクリプションを Red Hat から直接購入した場合は、そのページから更新可能です。ベンダーから購入した場合は、連絡先と注文情報が表示されます。
(期限切れになった) 製品の更新情報

図22 (期限切れになった) 製品の更新情報

5.9. サブスクリプションを過剰に使用している状態の解決

Red Hat はサブスクリプションのアタッチを制限しません。つまり、実際に購入した数より多くのサブスクリプションを割り当ててしまうリスクがあります。

警告

過剰なサブスクライブは、サブスクリプションなしでシステムを実行することと同じです。
この状況は、サービス契約違反となる場合があるとともに、IT インフラストラクチャーの全ソフトウェアに適切なライセンスが必要であるとする規制および業界標準 (Sarbanes-Oxley、PCI-DSS、SAS-70 など) に抵触する恐れもあります。
過剰にサブスクリプションを使用している場合は、 概要 ページの 使用 エリアに、明るい黄色の警告が表示されます。使用 ページでは、サブスクリプションの数が種類別に表示され、過剰にサブスクリプションを使用している場合は明るい黄色のバーと、その種類の過剰分を示した負の数字が表示されます。
サブスクリプションの過度の使用

図23 サブスクリプションの過度の使用

自動修復機能はなく、Red Hat が変更すべきシステムやサブスクリプションについて憶測や規則をつくることもありません。これは完全に管理者の判断に委ねられています。合計 の値をクリックすると、登録されているシステムまたはユニットの一覧が開きます。ここで、管理者がシステムエントリーを手動で変更したり、サブスクリプションを手動でアタッチまたは削除したりできます。
システムの確認

図24 システムの確認

システムの名前をクリックすると詳細ページが表示され、そのシステムのサブスクリプションを変更できます。

注記

Review Registrations ページを閲覧するには、組織の管理者パーミッションが必要です。そのパーミッションを持っていても、閲覧できるのはアクセス可能なシステムのみです。必ずしも組織内のすべてのシステムとは限りません。

6. オンプレミスサブスクリプション管理アプリケーションの管理

サブスクリプション管理アプリケーションの組織 は、カスタマーポータルのサブスクリプション管理における特別なエントリータイプで、ローカルシステムを管理するオンプレミスのエントリーです。カスタマーポータルのサブスクリプション管理は、サブスクリプション管理アプリケーションの組織を登録し、組織に大量のサブスクリプションを割り当てます。アプリケーション組織は、インベントリー、サブスクリプション、およびシステムをローカルで管理します。
カスタマーポータルのサブスクリプション管理は、企業のグローバル Red Hat アカウントから、ローカルアプリケーションにサブスクリプションを転送します。サブスクリプション管理アプリケーションの組織エントリーは、カスタマーポータルのサブスクリプション管理がサブスクリプションを転送するのに使用します。
カスタマーポータルのサブスクリプション管理におけるサブスクリプション管理アプリケーションの組織エントリーには、オンプレミスアプリケーション内の組織エントリーと直接つながりがあります。組織の構造は、1 つのローカル組織で構成されるフラットな場合もあれば、同じアプリケーションで管理される互いに独立した複数の組織で構成されるマルチテナントの場合もあります。オンプレミスアプリケーション内のマルチテナントにより、複数の独立したグループにローカルサービスを通じてそれぞれのサブスクリプションとシステムが割り当てられ、管理することができます (オンプレミスアプリケーションの組織構造はカスタマーポータルのサブスクリプション管理に透過的です。カスタマーポータルのサブスクリプション管理は、各サブスクリプション管理アプリケーション組織エントリーと別々に機能します)。
アプリケーションの組織に割り当てたサブスクリプションは、組織内のシステムで利用できるすべてのサブスクリプションおよび製品です。サブスクリプション、製品、および数量は、サブスクリプション管理アプリケーション組織の マニフェスト に一覧表示されます。
ローカルの組織と環境は、Subscription Asset Manager、Satellite 6 などの各種サブスクリプション管理アプリケーションにより管理できます。

6.1. アプリケーションの組織の登録

  1. サブスクリプション タブを展開し、サブスクリプション エリアを開き、概要 項目を選択します。
  2. 右側の 使用率 エリアで、サブスクリプション管理 リンクをクリックします。
  3. サブスクリプション管理アプリケーション 列で、登録 リンクをクリックします。
  4. 新しい組織に必要な情報を入力します。
    • 組織の名前
    • 組織のタイプ。選択肢は、アカウントで利用可能なサブスクリプションに基づいて提供されます。
    • Subscription Asset Manager インスタンスのバージョン。選択肢は、アカウントで利用可能なサブスクリプションに基づいて提供されます。

    注記

    この名前は、オンプレミスアプリケーション内の組織名と対応するようにしてください。
  5. 登録 ボタンをクリックします。
サブスクリプション管理アプリケーションの組織が作成されたら、サブスクリプションを組織にアタッチし、マニフェストをダウンロードしてインストールし、組織が、そのクライアントシステムにサブスクリプションをアタッチできるようにします。

6.2. サブスクリプション管理アプリケーションの一覧および詳細

サブスクリプション管理 ページの下部には、アプリケーションが、登録した組織のタイプおよび数別に一覧表示されています。数値をクリックすると、そのアプリケーションタイプに設定された組織の一覧が開きます。
概要ページのサブスクリプション管理アプリケーション

図25 概要ページのサブスクリプション管理アプリケーション

サブスクリプション管理アプリケーション インベントリーには、利用可能かつ設定済みのアプリケーションタイプ用のタブがあり、そのタイプの組織が一覧表示されています。
サブスクリプション管理アプリケーションインベントリーの表示

図26 サブスクリプション管理アプリケーションインベントリーの表示

この列には、3 つの重要な情報が表示されています。
  • エントリーの詳細ページにリンクしている組織名
  • 組織に割り当てられているサブスクリプションの合計 (製品およびコントラクト全体)
  • システムの UUID のような、組織の UUID
組織の詳細ページは、組織を管理するためのページです。システムの詳細と同じように、その組織のサブスクリプションを管理するためのタブと、識別証明書のタブがあります。また、マニフェストをダウンロードするためのボタンがあります。マニフェストは、オンプレミスアプリケーションにインポートして、所有しているサブスクリプションをアプリケーションに通知するファイルです。
組織の詳細

図27 組織の詳細

6.3. 組織へのサブスクリプションのアタッチ

6.3.1. マニフェスト

「オンプレミスサブスクリプション管理アプリケーションの管理」 の冒頭で簡単に説明したとおり、カスタマーポータルのサブスクリプション管理におけるサブスクリプション管理アプリケーションの組織と、Subscription Asset Manager のようなオンプレミスアプリケーションにおける組織の定義には直接の関係があります。この関係は、カスタマーポータルのサブスクリプション管理がローカルで管理するために、Red Hat からオンプレミスアプリケーションにサブスクリプションを転送するために使用する方法です。
この転送されたサブスクリプションのブロックは、サブスクリプション管理アプリケーションの組織マニフェスト に一覧表示されます。このマニフェストは、カスタマーポータルのサブスクリプション管理から直接ダウンロードする、サブスクリプション管理アプリケーションの組織エントリーの ZIP アーカイブで、オンプレミスアプリケーションにアップロードします。

重要

組織のサブスクリプションに行うすべての変更は、カスタマーポータルのサブスクリプション管理におけるサブスクリプション管理アプリケーションの組織エントリーに割り当てられているサブスクリプションに適用されます。その後、マニフェストを再生成してダウンロードし、アプリケーションに再アップロードします。
マニフェストは、ディレクトリーと JSON ファイルを集めたもので、その JSON ファイルには、サブスクリプション、エンタイトルメント証明書、製品、サブスクリプション管理アプリケーションの組織のルール一覧が含まれます。
manifest.zip
      |
      |- consumer_export.zip
                   |
		   |- export/
		         |
			 |- consumer_types/
			 |
			 |- entitlements/
			 |
			 |- entitlement_certificates/
			 |
			 |- products/
			 |
			 |- rules/
			 |
			 |- consumer.json
			 |
			 |- meta.json
consumer.json と meta.json

この JSON ファイルには、アプリケーションの組織のエントリー情報 (UUID) と、マニフェストの情報 (バージョンおよび作成日) が含まれています。

consumer_types/

consumer_types/ には、サポートされているアプリケーションの各タイプに対して、JSON ファイルが 1 つずつ含まれています。JSON ファイルには、アタッチしているサブスクリプションのタイプが示されています。たとえば、Subscription Asset Manager の場合は、sam.jsonmanifest 値が true になります。

{"id":"5","label":"sam","manifest":true}
entitlements/

entitlements/ には、アプリケーション組織に割り当てられる各サブスクリプションの JSON ファイルが含まれています。各フィールドの名前は、UUID.json と呼ばれています。

このファイルには、サブスクリプションの完全な情報が含まれています。たとえば、コントラクト番号、プール ID、コントラクトの開始日と終了日、サブスクリプションのキーと証明書、同梱されている各製品の製品 ID、数量、サブスクリプションに関連するその他の情報です。
たとえば、以下はサブスクリプション JSON 内の Red Hat Enterprise Linux 製品 1 つ関する情報です。
...
{"id":"8a878dcd3520d43501353f6f98f911e9","productName":"Red Hat Enterprise Linux Server","productId":"69","updated":"2012-02-02T18:59:32.000+0000","created":"2012-02-02T18:59:32.000+0000"}],"endDate":"2012-10-13T03:59:59.000+0000","quantity":50,"productName":"Red Hat Enterprise Linux Server, Premium (4 sockets) (Up to 4 guests)","contractNumber":"2625891","accountNumber":"1506376","productId":"RH0153936","subscriptionId":"2267347","consumed":31,"exported":30,"sourceEntitlement":null,"activeSubscription":true,"restrictedToUsername":null,"productAttributes":[{"productId":"RH0153936","name":"support_type","value":"L1-L3","id":"8a878dcd3520d43501353f6f98f811de","updated":"2012-02-02T18:59:32.000+0000","created":"2012-02-02T18:59:32.000+0000"}
...
entitlement_certificates/

entitlement_certificates/ には、Base64 エンコードされた BLOB のエンタイトルメント証明書がある PEM ファイルが各サブスクリプションに含まれています。

products/

products/ には、サブスクリプションに同梱される各製品の JSON ファイルが含まれています。これには、サポートされているバージョン、コンテンツセット、依存関係、およびリポジトリーに関する詳しい情報、その他の製品固有 (必ずしもサブスクリプション固有ではない) の情報が含まれています。

以下に、基本的な Red Hat Enterprise Linux 製品がある 1 バージョンの JSON ファイルの一部を例として示します。
...
{"name":"Red Hat Enterprise Linux Server","id":"69","attributes":[{"name":"type","value":"SVC"},{"name":"arch","value":"i386,ia64,x86_64"},{"name":"name","value":"Red Hat Enterprise Linux Server"}],"multiplier":1,"href":"/products/69","productContent":[{"content":{"name":"Red Hat Enterprise Linux 5 Server Beta (Source ISOs)","id":"861","type":"file","vendor":"Red Hat","modifiedProductIds":[],"contentUrl":"/content/beta/rhel/server/5/$releasever/$basearch/source/iso","label":"rhel-5-server-beta-source-isos","gpgUrl":"http://","metadataExpire":86400,"requiredTags":"rhel-5-server"},"enabled":false}
...
rules/

rules/ には、JavaScript ファイルが 1 つ含まれ、バックエンドの Red Hat サブスクリプション管理サービスとやりとりするためにアプリケーションが使用する関数を設定します。

6.3.2. 組織へのサブスクリプションのアタッチ

組織にサブスクリプションを割り当てると、組織が管理するシステムに割り当てる、そのタイプのサブスクリプションの数が設定されます (これは、ローカルにインストールされている製品にサブスクリプションを割り当てるシステムとは対照的です)。
アタッチ済みのサブスクリプション タブには、組織に現在割り当てられているサブスクリプションが表示されます。サブスクリプションのアタッチ リンクをクリックすると、アカウント全体のサブスクリプションに基づいて、アプリケーションの組織で利用可能なサブスクリプションがすべて表示されます。
組織にサブスクリプションをアタッチするには、以下を行います。
  1. サブスクリプション タブを展開し、サブスクリプション エリアを開き、概要 項目を選択します。
  2. 右側の 使用率 エリアで、サブスクリプション管理 リンクをクリックします。
  3. サブスクリプション管理アプリケーション 列で、組織のタイプをクリックします。
  4. アプリケーションインベントリーで組織の名前をクリックします。
  5. アタッチ済みのサブスクリプション タブを開きます。
  6. サブスクリプションのアタッチ リンクをクリックして、サブスクリプションを選択するウィンドウを開きます。
  7. 割り当てるサブスクリプションの横にあるチェックボックスを選択して、数量 列でアプリケーション組織の合計を設定します。
    使用可能なサブスクリプションの一覧には、3 つの重要な情報が表示されます。
    • サブスクリプション購入のコントラクト番号。記録の保持と追跡に重要です。
    • そのサブスクリプションに対してまだ使用できる数量。サブスクリプションはまとまった数量で購入します。この数は、購入した総数のうちどれだけ残っているかを示しています。
    • サブスクリプションの開始日と終了日。これにより、有効期限が切れるまで数日間しか有効でないサブスクリプション、または、まだアクティブでないサブスクリプションを割り当てることがないようにします。
      おそらく、組織に割り当てられているサブスクリプションの終了日はそれぞれ異なるため、マニフェストを更新せずにサブスクリプションを更新した方が簡単です。

    注記

    数量は、コントラクトで使用可能なサブスクリプション数の合計に設定されています。他のユニットおよびサブスクリプション管理アプリケーション間で、サブスクリプションを適切に割り振ることができるように、1 つのアプリケーション組織に割り当てられているサブスクリプションの数に注意してください。
  8. 左下隅の 選択項目を追加 ボタンをクリックしてください。

6.3.3. マニフェストをダウンロードする

サブスクリプションがアプリケーション組織に割り当てられると、製品証明書やエンタイトルメント証明書を含むサブスクリプションおよび製品の完全な一覧が 1 つの マニフェスト にまとめられます。マニフェストは、基本的にはローカルのサブスクリプション管理サービスを扱うためにアプリケーション組織が必要とするすべてが記載されたマスターの一覧です。
マニフェストは、マニフェストのダウンロード ボタンからクリックして、アプリケーション組織の詳細ページからダウンロードできます。これにより、manifest.zip アーカイブがローカルのファイルシステムに保存され、Subscription Asset Manager または Satellite 6 にアップロードできるようになります。
アプリケーション組織のマニフェストのダウンロード

図28 アプリケーション組織のマニフェストのダウンロード

6.3.4. マニフェストの更新とサブスクリプションの変更

組織がサブスクリプションを変更 (数量の変更、製品の追加、またはサブスクリプションの更新) する必要がある場合には、カスタマーポータルのサブスクリプション管理で組織にアタッチしたサブスクリプションを編集します。

重要

カスタマーポータルのサブスクリプション管理で新しい組織を作成して、オンプレミスの組織を更新しないようにしてください。 カスタマーポータルのサブスクリプション管理にある既存の組織にアタッチしているサブスクリプションを変更し、更新したマニフェストをオンプレミス組織エントリーが使用するようにします。
  1. サブスクリプション タブを展開し、サブスクリプション エリアを開き、概要 項目を選択します。
  2. 右側の 使用率 エリアで、サブスクリプション管理 リンクをクリックします。
  3. サブスクリプション管理アプリケーション 列で、組織のタイプをクリックします。
  4. アプリケーションインベントリーで組織の名前をクリックします。
  5. アタッチ済みのサブスクリプション タブを開きます。
  6. 更新する以前のサブスクリプションを削除する必要があります。そのサブスクリプションのチェックボックスを選択し、選択項目の削除 ボタンをクリックします。
    サブスクリプション管理アプリケーションの組織に割り当てているサブスクリプション数量を直接変更することはできません。割り当てているサブスクリプションに追加または削除する場合は、元の割り当てを削除して、新しい数量でサブスクリプションを割り当てる必要があります。
    たとえば、使用しているサブスクリプションブロックの数量が 30 で、35 に増やす必要がある場合は、現在のブロックを削除して、数量が 35 の新しいブロックを追加できます。これにより、数量が 35 のサブスクリプションが 1 つになります。もしくは、数量 5 の新しいブロックを追加して、数量が 30 のサブスクリプションが 1 つ、そして数量が 5 のサブスクリプションが 1 つの、合計 2 つのサブスクリプションエントリーを持つこともできます。
  7. 「組織へのサブスクリプションのアタッチ」に従って、新しいサブスクリプションを追加します。
  8. 「マニフェストをダウンロードする」に従って、マニフェストのダウンロード ボタンをクリックし、更新したマニフェストを保存します。
  9. 更新したマニフェストを、オンプレミスアプリケーションにアップロードします。

7. ハイパーバイザーおよび仮想ホストの管理

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

重要

カスタマーポータルのサブスクリプション管理では、ハイパーバイザーとそのゲストとの間に、マッピングまたは視覚表示がありません。

7.1. サポート対象のハイパーバイザー

virt-who プロセスは、異なるいくつかのハイパーバイザーで、ゲストを検出して関連付けられます。
  • Red Hat Enterprise Virtualization Manager (KVM)
  • Xen
  • HyperV
  • VMware ESX / ESX(i)

7.2. ホストおよびゲストの関連付け

サブスクリプションの関係には柔軟性について高い可能性を秘めています。サブスクリプションを、一方では物理マシン または 一定数の仮想マシンに適用し、他方では物理ホストに適用して、ゲストが継承できるようにすることもできます。
サブスクリプションを効果的に管理するには、ホストとゲストの関係のサブスクリプションサービスにおいて、内部の認識が必要です。このように、サブスクリプションサービスが 1 つの物理サブスクリプションを物理ホストに適切にアタッチし、各インスタンスに対して物理サブスクリプションを 2 つ使用するのではなく、(たとえば) 含まれる仮想サブスクリプションをそのゲストに適用します。
この関連は、各ゲストに対して UUID (Universally Unique Identifier) を取り出し、それをそのハイパーバイザーに関連付けることで行います。この UUID は、各仮想システムのシステム情報の一種です。
ハイパーバイザーは、最初にサブスクリプションサービスに登録され、システムの関連プロセスがゲストに対してスキャンし、検出された UUID をサブスクリプションサービスに送信します。これは、virt-who コマンドの実行時に、libvirt プロセスによって行われます。
サブスクリプションサービスがホストとゲストの関連付けを認識し、サブスクリプションを適切にアタッチするには、以下の 3 つの要因を満たす必要があります。
  • 新しいゲストインスタンスを検出するために、適切な仮想検出プロセスを定期的に実行する必要があります。
  • ハイパーバイザーおよびゲストシステムは、同じサブスクリプションサービスに登録する必要があります (つまり、カスタマーポータルのサブスクリプション管理にすべて登録する必要があります)。
  • ハイパーバイザーは、仮想サブスクリプションまたは継承可能なサブスクリプションを含むものにサブスクリプションをアタッチする必要があります。

7.3. KVM または Xen ハイパーバイザーとして設定

  1. virt-who パッケージをインストールします。
    [root@server ~]# yum install virt-who
    これにより、サブスクリプション管理に対して Red Hat Subscription Manager および Subscription Asset Manager が使用できるゲストとホストのマッピングを確立するホストの一覧が作成されます。
  2. 次に、カスタマーポータルにエントリーを作成します。
    1. サブスクリプション タブを展開し、サブスクリプション管理 項目を開き、ユニット 項目を選択します。
    2. 表の上部で 登録 リンクをクリックします。
    3. 新しいハイパーバイザーの名前を入力します。
    4. 登録 ボタンをクリックします。

7.4. VMware Hypervisor の設定

注記

virt-who パッケージは、Red Hat Enterprise Linux に利用可能なホストとゲストのマッピングを作成します。VMware 環境では、VMware ハイパーバイザーに接続する virt-who プロセスを実行するために、Red Hat Enterprise Linux システムが利用可能である必要があります。
  1. カスタマーポータルにハイパーバイザーエントリーを作成します。
    1. サブスクリプション タブを展開し、サブスクリプション管理 項目を開き、ユニット 項目を選択します。
    2. 表の上部で 登録 リンクをクリックします。
    3. 新しいハイパーバイザーの名前を入力します。
    4. 登録 ボタンをクリックします。
  2. Red Hat Enterprise Linux システムに virt-who パッケージをインストールします。
    [root@server ~]# yum install virt-who
  3. virt-who 設定ファイル (/etc/sysconfig/virt-who) を開き、サブスクリプションサービスに必要な情報を設定します。
    1. ESX モードを有効にし、環境を Library に設定します。
      VIRTWHO_ESX=1
      VIRTWHO_ESX_ENV=Library
    2. サブスクリプションの所有者を指定します。これは、組織の ID である必要があります。以下は例となります。
      VIRTWHO_ESX_OWNER=6340056
      複数の組織が存在する場合は、組織に対して、ポータルエントリーで組織 ID が利用可能である必要があります。(単一の組織がある) カスタマーポータルで登録されている場合、またはその組織にすでに別のシステムが登録されている場合は、subscription-manager orgs コマンドを使用して、その ID が利用可能になっています。
    3. vCenter サーバーのホスト名または IP アドレスを設定します。
      VIRTWHO_ESX_SERVER=vcenter.example.com
    4. vCenter サーバーの接続時に使用するユーザー名とパスワードを指定します。
      VIRTWHO_ESX_USERNAME=admin
      VIRTWHO_ESX_PASSWORD=secret
    5. 設定ファイルに加えた変更を保存します。
    6. virt-who サービスを開始して、ホストとゲストのデータをすべて収集しはじめます。
      [root@vmware-server ~]# service virt-who start
      データは、/var/lib/virt-who/hypervisor-systemid-UUID ファイルに追加されます。
    7. chkconfig コマンドで virt-who サービスを設定し、システムの開始時に自動的に開始するようにします。
      [root@vmware-server ~]# chkconfig virt-who on

7.5. ゲストインスタンスの登録

「新しいシステムの登録」に従って、仮想システムを物理システムと同じように登録します。

注記

環境の仮想ホスト、またはハイパーバイザー (VMware の場合) で virt-who プロセスで実行して、virt-who プロセスが物理ホストにゲストをマッピングしているのを確認し、システムが仮想システムとして適切に登録されるようにします。登録されない場合は、仮想インスタンスは物理インスタンスとして処理されます。

7.6. 仮想ホストおよびゲストへのサブスクリプションのアタッチ

仮想ホストおよび仮想ゲストの両方に対するサブスクリプション、設定、および自動アタッチ設定が、物理システムおよびその他のタイプのコンシューマーと同じように設定されます。詳細は「サブスクリプションの管理」を参照してください。
仮想環境でサブスクリプションを使用する際に意識しておくべき点が 2 つあります。
まず、「ホストおよびゲストの関連付け」 に従って、ゲストは、ホストから一部のサブスクリプションを継承できます。これは、一部の製品についてはシステムにサブスクリプションをアタッチする必要がなく、直接アタッチするよりも多くの製品やコンテンツがシステムに利用できることを示しています。
次に、「サブスクリプションとシステムの関係」 にあるように、仮想ゲストに必要なサブスクリプションの数量は、物理マシンよりも少なくなります。物理マシンの場合は、サブスクリプションが、ソケットやコアの数など、マシンの物理属性をカバーする必要があります。サブスクリプションは、ソケットやコアのペアをカバーするために、常に 2 つがセットとなって適用されます。ソケットとコアのすべてをカバーするために、このようなサブスクリプションのペアをアタッチする必要があります (たとえば、4 つのソケットシステムには、2 つサブスクリプションのセットが 2 つ必要になります)。
ただし、仮想ゲストの場合、サブスクリプションの数を数える際にこの物理属性は適用されません。仮想ゲストをカバーするのに必要な数量は 1 です。

7.7. データセンターの作成

物理システムをハイパーバイザーとして登録し、システムにインストールして登録する仮想ゲストの数を無制限に許可するようなデータセンターで利用できる特別なサブスクリプションがあります。その物理システムは、RHEV または Xen を実行する Red Hat Enterprise Linux システム、または VMware または HyperV を実行する Linux 以外のシステムになります。設定は、仮想化環境を実行する場合と同様に重要ではありません。単純に、ホストとゲストのマッピングを作成する virt-who プロセスを実行する Red Hat Enterprise Linux システムが 1 台必要になるだけです。
環境内の各物理ホストに対して、以下を行います。
  1. 「KVM または Xen ハイパーバイザーとして設定」または「VMware Hypervisor の設定」の説明に従って、ホストまたはハイパーバイザーを設定します。
  2. ハイパーバイザーエントリーに、データセンターサブスクリプションをアタッチします。サブスクリプションの名前は Red Hat Enterprise Linux for Virtual Datacenters ... System:Physical です。
  3. 「ゲストインスタンスの登録」に記載されているとおりに、ホストまたはハイパーバイザーにすべてのゲストを登録します。

注記

あるハイパーバイザーから別のハイパーバイザーに仮想インスタンスを移行すると、Red Hat Enterprise Linux サブスクリプションが保存されますが、JBoss Enterprise Application Platform などの追加製品のサブスクリプションの登録を解除して、再アタッチする必要があります。

A. 改訂履歴

改訂履歴
改訂 4-9.2Tue Jul 3 2018Terry Chuang
翻訳ファイルを XML ソースバージョン 4-9 と同期
改訂 4-9.1Tue Jul 3 2018Terry Chuang
翻訳ファイルを XML ソースバージョン 4-9 と同期
改訂 4-9April 13, 2014Ella Deon Ballard
インスタンスベースおよび仮想設定セクションの更新。
改訂 4-5October 1, 2013Deon Ballard
サブスクリプションマネージャーアプリケーションに、バージョンを選択するオプションを追加。
ハイパーバイザーのコンシューマーへの情報の追加。
インスタンスベースのサブスクリプションへの情報の追加。
すべのコンシューマーで自動アタッチを実行するプロシージャーの追加。
改訂 3-0January 8, 2013Ella Deon Lackey
追加オプションのエラータ通知セクションのアップデート。
修正した UI のスクリーンショットをすべて更新。
用語、UI 要素、およびコマンドの追加。
改訂 2-2July 12, 2012Ella Deon Lackey
エラータ通知設定に関する情報を追加。
改訂 2-0June 13, 2012Ella Deon Lackey
y-stream リリース設定に関する情報を追加。
改訂 1-0February 8, 2012Ella Deon Lackey
UI 変更に伴いすべてのスクリーンショットを更新。
サブスクリプション概要を更新。
ディストリビューターとマニフェストに関する情報を追加。
改訂 0-3August 31, 2011Ella Deon Lackey
若干の誤字修正。
改訂 0-2July 1, 2011Ella Deon Lackey
ドキュメントの名前変更とバージョン更新。内容の変更はなし。
改訂 0-1June 16, 2011Ella Deon Lackey
エンタイトルメント管理のためにクロスプラットフォームカウントを新規追加。
改訂 0-0March 18, 2011Ella Deon Lackey
RHSM Web Client およびポータルサブスクリプションのドキュメントの初期ドラフト。

法律上の通知

Copyright © 2010 Red Hat, Inc.
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.