Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第2章 要件

本章では、director を使用して Red Hat OpenStack Platform をプロビジョニングする環境をセットアップするための主要な要件を記載します。これには、director のセットアップ/アクセス要件や OpenStack サービス用に director がプロビジョニングするホストのハードウェア要件が含まれます。

注記

Red Hat OpenStack Platform をデプロイする前には、利用可能なデプロイメントメソッドの特性を考慮することが重要です。詳しくは、「Installing and Managing Red Hat OpenStack Platform」のアーティクルを参照してください。

2.1. 環境要件

最小要件

  • Red Hat OpenStack Platform director 用のホストマシン 1 台
  • Red Hat OpenStack Platform コンピュートノード用のホストマシン 1 台
  • Red Hat OpenStack Platform コントローラーノード用のホストマシン 1 台

推奨要件

  • Red Hat OpenStack Platform director 用のホストマシン 1 台
  • Red Hat OpenStack Platform コンピュートノード用のホストマシン 3 台
  • クラスター内に Red Hat OpenStack Platform コントローラーノード用のホストマシン 3 台
  • クラスター内に Red Hat Ceph Storage ノード用のホストマシン 3 台

以下の点に注意してください。

  • 全ノードにはベアメタルシステムを使用することを推奨します。最低でも、コンピュートノードにはベアメタルシステムが必要です。
  • すべてのオーバークラウドベアメタルシステムには、Intelligent Platform Management Interface (IPMI) が必要です。これは、director が電源管理を制御するためです。
  • 各ノードの内部 BIOS クロックを UTC に設定します。これにより、タイムゾーンオフセットを適用する前に hwclock が BIOS クロックを同期するとファイルのタイムスタンプに未来の日時が設定される問題を防ぐことができます。
警告

Red Hat Enterprise Linux 7.3 カーネルにアップグレードするには、Open vSwitch (OVS) 2.4.0 も OVS 2.5.0 にアップグレードする必要があります。カーネルだけアップグレードすると、OVS は機能しなくなります。

2.2. アンダークラウドの要件

director をホストするアンダークラウドシステムは、オーバークラウド内の全ノードのプロビジョニングおよび管理を行います。

  • Intel 64 または AMD64 CPU 拡張機能をサポートする、8 コア 64 ビット x86 プロセッサー
  • 最小 16 GB の RAM
  • ルートディスク上に最小 40 GB の空きディスク領域。オーバークラウドのデプロイメントまたは更新を試みる前に、少なくとも 10 GB の空き領域を確保するようにしてください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。
  • 最小 2 枚の 1 Gbps ネットワークインターフェースカード。ただし、特にオーバークラウド環境で多数のノードをプロビジョニングする場合には、ネットワークトラフィックのプロビジョニング用に 10 Gbps インターフェースを使用することを推奨します。
  • ホストオペレーティングシステムとして、Red Hat Enterprise Linux 7.7 がインストール済みであること。
  • ホスト上で SELinux が Enforcing モードで有効化されていること。

2.2.1. 仮想化サポート

Red Hat は、以下のプラットフォームでのみ仮想アンダークラウドをサポートします。

プラットフォーム説明

Kernel-based Virtual Machine (KVM)

認定済みのハイパーバイザーとしてリストされている Red Hat Enterprise Linux 7 でホストされていること

Red Hat Virtualization

認定済みのハイパーバイザーとしてリストされている Red Hat Virtualization 4.x でホストされていること

Microsoft Hyper-V

Red Hat Customer Portal Certification Catalogue に記載の Hyper-V のバージョンでホストされていること

VMware ESX および ESXi

Red Hat Customer Portal Certification Catalogue に記載の ESX および ESXi のバージョンでホストされていること

重要

Red Hat OpenStack Platform director 10 には、ホストオペレーティングシステムとして最新バージョンの Red Hat Enterprise Linux が必要です。このため、仮想化プラットフォームは下層の Red Hat Enterprise Linux バージョンもサポートする必要があります。

仮想マシンの要件

仮想アンダークラウドのリソース要件は、ベアメタルのアンダークラウドの要件と似ています。ネットワークモデル、ゲスト CPU 機能、ストレージのバックエンド、ストレージのフォーマット、キャッシュモードなどプロビジョニングの際には、さまざまなチューニングオプションを考慮する必要があります。

ネットワークの考慮事項

仮想アンダークラウドの場合は、以下にあげるネットワークの考慮事項に注意してください。

電源管理
アンダークラウドの仮想マシンには、オーバークラウドのノードにある電源管理のデバイスへのアクセスが必要です。これには、ノードの登録の際に、pm_addr パラメーターに IP アドレスを設定してください。
プロビジョニングネットワーク
プロビジョニング (ctlplane) ネットワークに使用する NIC には、オーバークラウドのベアメタルノードの NIC に対する DHCP 要求をブロードキャストして、対応する機能が必要です。仮想マシンの NIC をベアメタルの NIC と同じネットワークに接続するブリッジを作成することを推奨します。
注記

一般的に、ハイパーバイザーのテクノロジーにより、アンダークラウドが不明なアドレスのトラフィックを伝送できない場合に問題が発生します。Red Hat Enterprise Virtualization を使用する場合には、anti-mac-spoofing を無効にしてこれを回避してください。VMware ESX または ESXi を使用している場合は、偽装転送を承諾してこれを回避します。

アーキテクチャーの例

これは、KVM サーバーを使用した基本的なアンダークラウドの仮想化アーキテクチャー例です。これは、ネットワークやリソースの要件に合わせてビルド可能な基盤としての使用を目的としています。

KVM ホストは Linux ブリッジを 2 つ使用します。

br-ex (eth0)
  • アンダークラウドへの外部アクセスを提供します。
  • 外部ネットワークの DHCP サーバーは、仮想 NIC (eth0) を使用してアンダークラウドにネットワーク設定を割り当てます。
  • アンダークラウドがベアメタルサーバーの電源管理インターフェースにアクセスできるようにします。
br-ctlplane (eth1)
  • ベアメタルのオーバークラウドノードと同じネットワークに接続します。
  • アンダークラウドは、仮想 NIC (eth1) を使用して DHCP および PXE ブートの要求に対応します。
  • オーバークラウドのベアメタルサーバーは、このネットワークの PXE 経由でブートします。

KVM ホストには、以下のパッケージが必要です。

$ yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync

以下のコマンドは、KVM ホストにアンダークラウドの仮想マシンして、適切なブリッジに接続するための仮想 NIC を 2 つ作成します。

$ virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.3-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7

このコマンドにより、libvirt ドメインが起動します。virt-manager に接続し、段階を追ってインストールプロセスが進められます。または、以下のオプションを使用してキックスタートファイルを指定し、無人インストールを実行することもできます。

--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"

インストールが完了したら、root ユーザーとしてインスタンスに SSH 接続して、「4章アンダークラウドのインストール」の手順に従います。

バックアップ

以下のように、仮想アンダークラウドをバックアップするためのソリューションは複数あります。

  • オプション 1:『director のアンダークラウドのバックアップと復元』の説明に従います。
  • オプション 2: アンダークラウドをシャットダウンして、アンダークラウドの仮想マシンストレージのバックアップのコピーを取ります。
  • オプション 3: ハイパーバイザーがライブまたはアトミックのスナップショットをサポートする場合は、アンダークラウドの仮想マシンのスナップショットを作成します。

KVM サーバーを使用する場合は、以下の手順でスナップショットを作成してください。

  1. qemu-guest-agent がアンダークラウドのゲスト仮想マシンで実行していることを確認してください。
  2. 実行中の仮想マシンのライブスナップショットを作成します。
$ virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce
  1. QCOW バッキングファイルのコピー (読み取り専用) を作成します。
$ rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2
  1. QCOW オーバーレイファイルをバッキングファイルにマージして、アンダークラウドの仮想マシンが元のファイルを使用するように切り替えます。
$ virsh blockcommit undercloud vda --active --verbose --pivot

2.3. ネットワーク要件

アンダークラウドのホストには、最低でも 2 つのネットワークが必要です。

  • プロビジョニングネットワーク: オーバークラウドで使用するベアメタルシステムの検出がしやすくなるように、DHCP および PXE ブート機能を提供します。このネットワークは通常、director が PXE ブートおよび DHCP の要求に対応できるように、トランキングされたインターフェースでネイティブ VLAN を使用する必要があります。一部のサーバーのハードウェアの BIOS は、VLAN からの PXE ブートをサポートしていますが、その BIOS が、ブート後に VLAN をネイティブ VLAN に変換する機能もサポートする必要があります。この機能がサポートされていない場合には、アンダークラウドに到達できません。現在この機能を完全にサポートしているサーバーハードウェアはごく一部です。プロビジョニングネットワークは、オーバークラウドノード上で Intelligent Platform Management Interface (IPMI) により電源管理を制御するのに使用するネットワークでもあります。
  • 外部ネットワーク: オーバークラウドおよびアンダーグラウンドへの外部アクセスに使用する別個のネットワーク。このネットワークに接続するこのインターフェースには、静的または外部の DHCP サービス経由で動的に定義された、ルーティング可能な IP アドレスが必要です。

これは、必要なネットワークの最小数を示します。ただし、director は他の Red Hat OpenStack Platform ネットワークトラフィックをその他のネットワーク内に分離することができます。Red Hat OpenStack Platform は、ネットワークの分離に物理インターフェースとタグ付けされた VLAN の両方をサポートしています。

以下の点に注意してください。

  • 標準的な最小限のオーバークラウドのネットワーク構成には、以下が含まれます。

    • シングル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1つ。
    • デュアル NIC 構成: プロビジョニングネットワーク用の NIC を 1 つと、外部ネットワーク用の NIC を 1 つ。
    • デュアル NIC 構成: ネイティブの VLAN 上にプロビジョニングネットワーク用の NIC を 1 つと、異なる種別のオーバークラウドネットワークのサブネットを使用するタグ付けされた VLAN 用の NIC を 1 つ。
    • 複数 NIC 構成: 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用します。
  • 追加の物理 NIC は、個別のネットワークの分離、ボンディングインターフェースの作成、タグ付された VLAN トラフィックの委譲に使用することができます。
  • ネットワークトラフィックの種別を分離するのに VLAN を使用している場合には、802.1Q 標準をサポートするスイッチを使用してタグ付けされた VLAN を提供します。
  • オーバークラウドの作成時には、全オーバークラウドマシンで 1 つの名前を使用して NIC を参照します。理想としては、混乱を避けるため、対象のネットワークごとに、各オーバークラウドノードで同じ NIC を使用してください。たとえば、プロビジョニングネットワークにはプライマリー NIC を使用して、OpenStack サービスにはセカンダリー NIC を使用します。
  • プロビジョニングネットワークの NIC は director マシン上でリモート接続に使用する NIC とは異なります。director のインストールでは、プロビジョニング NIC を使用してブリッジが作成され、リモート接続はドロップされます。director システムへリモート接続する場合には、外部 NIC を使用します。
  • プロビジョニングネットワークには、環境のサイズに適した IP 範囲が必要です。以下のガイドラインを使用して、この範囲に含めるべき IP アドレスの総数を決定してください。

    • プロビジョニングネットワークに接続されているノード 1 台につき最小で 1 IP アドレスを含めます。
    • 高可用性を設定する予定がある場合には、クラスターの仮想 IP 用に追加の IP アドレスを含めます。
    • 環境のスケーリング用の追加の IP アドレスを範囲に追加します。

      注記

      プロビジョニングネットワーク上で IP アドレスが重複するのを避ける必要があります。詳しい情報は、「ネットワークのプランニング」を参照してください。

      注記

      ストレージ、プロバイダー、テナントネットワークの IP アドレスの使用範囲をプランニングすることに関する情報は、『ネットワークガイド』を参照してください。

  • すべてのオーバークラウドシステムをプロビジョニング NIC から PXE ブートするように設定して、同システム上の外部 NIC およびその他の NIC の PXE ブートを無効にします。また、プロビジョニング NIC の PXE ブートは、ハードディスクや CD/DVD ドライブよりも優先されるように、ブート順序の最上位に指定するようにします。
  • すべてのオーバークラウドベアメタルシステムには、Intelligent Platform Management Interface (IPMI) などのサポート対象の電源管理インターフェースが必要です。このインターフェースにより、director は各ノードの電源管理機能を制御することが可能となります。
  • 各オーバークラウドシステムの詳細 (プロビジョニング NIC の MAC アドレス、IPMI NIC の IP アドレス、IPMI ユーザー名、IPMI パスワード) をメモしてください。この情報は、後でオーバークラウドノードを設定する際に役立ちます。
  • Red Hat のサポートには、フェンシンが必須です。コントローラーから OOB IPMI へのネットワークフローを追加する必要があります。
  • インスタンスが外部のインターネットからアクセス可能である必要がある場合には、パブリックネットワークから Floating IP アドレスを割り当てて、そのアドレスをインスタンスに関連付けます。インスタンスは、引き続きプライベートの IP アドレスを確保しますが、ネットワークトラフィックは NAT を使用して、Floating IP アドレスに到達します。Floating IP アドレスは、複数のプライベート IP アドレスではなく、単一のインスタンスにのみ割り当て可能である点に注意してください。ただし、Floating IP アドレスは、単一のテナントでのみ使用するように確保され、そのテナントは必要に応じて特定のインスタンスに関連付け/関連付け解除することができます。この設定では、お使いのインフラストラクチャーが外部のインターネットに公開されます。したがって、適切なセキュリティープラクティスを順守しているかどうかを確認しなければならない場合があります。
  • 1 つのブリッジには単一のインターフェースまたは単一のボンディングのみをメンバーにすると、Open vSwitch でネットワークループが発生するリスクを緩和することができます。複数のボンディングまたはインターフェースが必要な場合には、複数のブリッジを設定することが可能です。
  • オーバークラウドノードが Red Hat Content Delivery Network やネットワークタイムサーバーなどの外部のサービスに接続できるようにするには、DNS によるホスト名解決を使用することを推奨します。
重要

OpenStack Platform の実装のセキュリティーレベルは、その環境のセキュリティーレベルと同等です。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスが正しく制御されるようにします。以下に例を示します。

  • ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークはセキュリティーレベルがはるかに低くなります。
  • サービスアクセスとポートを最小限に制限します。
  • 適切なファイアウォールルールとパスワードが使用されるようにします。
  • SELinux が有効化されていることを確認します。

システムのセキュリティー保護については、以下のドキュメントを参照してください。

2.4. オーバークラウドの要件

以下の項では、オーバークラウドのインストール内の個別システムおよびノードの要件について詳しく説明します。

注記

SAN (FC-AL、FCoE、iSCSI) からのオーバークラウドノードのブートは、まだサポートされていません。

2.4.1. コンピュートノードの要件

コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させる役割を果たします。コンピュートノードは、ハードウェアの仮想化をサポートしている必要があります。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーで、Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されていること。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。
メモリー容量
最小で 6 GB のメモリー。仮想マシンインスタンスに割り当てるメモリー容量に基づいて、この最低要求に追加の RAM を加算します。
ディスク容量
最小 40 GB の空きディスク領域
ネットワークインターフェースカード
最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

2.4.2. コントローラーノードの要件

コントローラーノードは、RHEL OpenStack Platform 環境の中核となるサービス (例: Horizon Dashboard、バックエンドのデータベースサーバー、Keystone 認証、高可用性サービスなど) をホストする役割を果たします。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
メモリー容量

最小のメモリー容量は 32 GB です。ただし、推奨のメモリー容量は、仮想 CPU の数によって異なります (CPU コアをハイパースレッディングの値で乗算した数値に基づいています)。以下の計算を参考にしてください。

  • コントローラーの最小メモリー容量の算出:

    • 1 仮想 CPU あたり 1.5 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 72 GB 必要です。
  • コントローラーの推奨メモリー容量の算出:

    • 1 仮想 CPU あたり 3 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 144 GB 必要です。

メモリーの要件に関する詳しい情報は、Red Hat カスタマーポータルで「Red Hat OpenStack Platform Hardware Requirements for Highly Available Controllers」のアーティクルを参照してください。

ディスクストレージとレイアウト

デフォルトでは、Telemetry (gnocchi) および Object Storage (swift) サービスはいずれもコントローラーにインストールされ、ルートディスクを使用するように設定されます。これらのデフォルトは、コモディティーハードウェア上に構築される小型のオーバークラウドのデプロイに適しています。これは、概念検証およびテストの標準的な環境です。これらのデフォルトにより、最小限のプランニングでオーバークラウドをデプロイすることができますが、ワークロードキャパシティーとパフォーマンスの面ではあまり優れていません。

ただし、Telemetry がストレージに絶えずアクセスするため、エンタープライズ環境では、これによって大きなボトルネックが生じる可能性があります。これにより、ディスク I/O が過度に使用されて、その他すべてのコントローラーサービスに深刻な影響をもたらします。このタイプの環境では、オーバークラウドのプランニングを行って、適切に設定する必要があります。

Red Hat は、Telemetry と Object Storage の両方の推奨設定をいくつか提供しています。詳しくは、『Deployment Recommendations for Specific Red Hat OpenStack Platform Services』を参照してください。

ディスク容量
Object Storage サービス (swift) がコントローラーノード上で実行されていない場合には、最低でも 40 GB のディスク容量が利用可能であること。
ネットワークインターフェースカード
最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

2.4.3. Ceph Storage ノードの要件

Ceph Storage ノードは、RHEL OpenStack Platform 環境でオブジェクトストレージを提供する役割を果たします。

配置グループ
デプロイメントの規模によらず、動的で効率的なオブジェクトの追跡を容易に実施するために、Ceph では配置グループが使用されています。OSD の障害やクラスターのリバランスの際には、Ceph は配置グループおよびその内容を移動または複製することができるので、Ceph クラスターは効率的にリバランスおよび復旧を行うことができます。director が作成するデフォルトの配置グループ数が常に最適とは限らないので、実際の要件に応じて正しい配置グループ数を計算することが重要です。配置グループの計算ツールを使用して、正しい数を計算することができます (Ceph Placement Groups (PGs) per Pool Calculator を参照)。
プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
メモリー容量
メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。
ディスク容量
ストレージ要件は、メモリーの容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。
ディスクのレイアウト

推奨される Red Hat Ceph Storage ノードの構成には、少なくとも以下のようなレイアウトの 3 つのディスクが必要です。

  • /dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。
  • /dev/sdb: ジャーナルディスク。このディスクは、Ceph OSD ジャーナル向けにパーティションに分割されます。たとえば、/dev/sdb1/dev/sdb2/dev/sdb3 (以下同様) のように分割されます。ジャーナルディスクは、通常システムパフォーマンスの向上に役立つソリッドステートドライブ (SSD) です。
  • /dev/sdc 以降: OSD ディスク。ストレージ要件で必要な数のディスクを使用します。
ネットワークインターフェースカード
最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースカードを使用します。特に大量のトラフィックにサービスを提供する OpenStack Platform 環境を構築する場合には、ストレージノードには 10 Gbps インターフェースを使用することを推奨します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

Ceph Storage クラスターを使用するオーバークラウドのインストールについての詳しい情報は、『オーバークラウド向けの Red Hat Ceph Storage』を参照してください。

2.4.4. Object Storage ノードの要件

オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。オブジェクトストレージプロキシーは、コントローラーノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
メモリー容量
メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。最適なパフォーマンスを得るには、特にワークロードが小さいファイル (100 GB 未満) の場合にはハードディスク容量 1 TB あたり 2 GB のメモリーを使用することを推奨します。
ディスク容量

ストレージ要件は、ワークロードに必要とされる容量により異なります。アカウントとコンテナーのデータを保存するには SSD ドライブを使用することを推奨します。アカウントおよびコンテナーデータとオブジェクトの容量比率は、約 1 % です。たとえば、ハードドライブの容量 100 TB ごとに、アカウントおよびコンテナーデータの SSD 容量は 1 TB 用意するようにします。

ただし、これは保存したデータの種類により異なります。保存するオブジェクトサイズの大半が小さい場合には、SSD の容量がさらに必要です。オブジェクトが大きい場合には (ビデオ、バックアップなど)、SSD の容量を減らします。

ディスクのレイアウト

推奨のノード設定には、以下のようなディスクレイアウトが必要です。

  • /dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。
  • /dev/sdb: アカウントデータに使用します。
  • /dev/sdc: コンテナーデータに使用します。
  • /dev/sdd 以降: オブジェクトサーバーディスク。ストレージ要件で必要な数のディスクを使用します。
ネットワークインターフェースカード
最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

2.5. リポジトリーの要件

アンダークラウドおよびオーバークラウドにはいずれも、Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite 5 もしくは 6 のいずれかを使用した Red Hat リポジトリーへのアクセスが必要です。Red Hat Satellite Server を使用する場合は、必要なリポジトリーをお使いの OpenStack Platform 環境に同期します。以下の CDN チャネル名一覧を参考にしてください。

警告

Red Hat Enterprise Linux 7.3 カーネルにアップグレードするには、Open vSwitch (OVS) 2.4.0 も OVS 2.5.0 にアップグレードする必要があります。カーネルだけアップグレードすると、OVS は機能しなくなります。

表2.1 OpenStack Platform リポジトリー

名前

リポジトリー

要件の説明

Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rpms

ベースオペレーティングシステムのリポジトリー

Red Hat Enterprise Linux 7 Server - Extras (RPMs)

rhel-7-server-extras-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 7 Server - RH Common (RPMs)

rhel-7-server-rh-common-rpms

Red Hat OpenStack Platform のデプロイと設定用のツールが含まれます。

Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64

rhel-7-server-satellite-tools-6.2-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat Enterprise Linux High Availability (for RHEL 7 Server) (RPMs)

rhel-ha-for-rhel-7-server-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Enterprise Linux OpenStack Platform 10 for RHEL 7 (RPMs)

rhel-7-server-openstack-10-rpms

Red Hat OpenStack Platform のコアリポジトリーRed Hat OpenStack Platform director のパッケージも含まれます。

Red Hat Ceph Storage OSD 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-osd-rpms

(Ceph Storage ノード向け) Ceph Storage Object Storage デーモンのリポジトリー。Ceph Storage ノードにインストールします。

Red Hat Ceph Storage MON 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-mon-rpms

(Ceph Storage ノード向け) Ceph Storage Monitor デーモンのリポジトリー。Ceph Storage ノードを使用して OpenStack 環境にあるコントローラーノードにインストールします。

Red Hat Ceph Storage Tools 2 for Red Hat Enterprise Linux 7 Server (RPMs)

rhel-7-server-rhceph-2-tools-rpms

Ceph Storage クラスターと通信するためのノード用のツールを提供します。このリポジトリーは、Ceph Storage クラスターを使用するオーバークラウドをデプロイする際に、すべてのオーバークラウドノードで有効にする必要があります。

注記

ネットワークがオフラインの Red Hat OpenStack Platform 環境用リポジトリーを設定するには、Red Hat カスタマーポータルで「オフライン環境で Red Hat OpenStack Platform Director を設定する」のアーティクルを参照してください。