大規模デプロイメントにおける推奨事項

Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform を大規模にデプロイするためのハードウェア要件と設定

OpenStack Documentation Team

概要

このガイドには、大規模な Red Hat OpenStack Platform をデプロイする際のさまざまな推奨事項を記載します。推奨事項には、ハードウェアの推奨事項、アンダークラウドのチューニング、およびオーバークラウドの設定が含まれます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
  7. Submit をクリックします。

第1章 大規模デプロイメントにおける推奨事項

大規模な Red Hat OpenStack Platform (RHOSP) 環境をデプロイする際には、以下のアンダークラウドおよびオーバークラウドの推奨事項、仕様、および設定を使用します。100 を超えるオーバークラウドノードが含まれる RHOSP 16.1 デプロイメントは、大規模な環境とみなされます。Red Hat は、ミニオンを使用しない RHOSP 16.1 を使用して、700 のオーバークラウドノードが含まれる大規模な環境で、最大限のパフォーマンスをテストおよび検証しています。

DCN ベースのデプロイメントの場合には、中央サイトおよびエッジサイトからのノードの数が非常に大きい場合があります。DCN デプロイメントに関する推奨事項は、Red Hat Global Support Services にお問い合わせください。

第3章 Red Hat OpenStack デプロイメントのベストプラクティス

OpenStack のデプロイを計画して準備する場合は、以下のベストプラクティスを確認してください。お使いの環境で、これらのプラクティスの 1 つまたは複数を適用できます。

3.1. Red Hat OpenStack デプロイメントの準備

Red Hat OpenStack Platform (RHOSP) をデプロイする前に、以下のデプロイメント準備タスクのリストを確認してください。お使いの環境で、デプロイメント準備タスクの 1 つまたは複数を適用できます。

イントロスペクションのサブネット範囲を設定して、一度にイントロスペクションを実施する最大オーバークラウドノードに対応する
director を使用して RHOSP をデプロイおよび設定する場合は、コントロールプレーンネットワークに CIDR 表記を使用して、現在または今後追加するすべてのオーバークラウドノードに対応します。
オーバークラウドイメージの root パスワードを設定して、オーバークラウドイメージへのコンソールアクセスを許可する

ネットワークが正しく設定されていない場合に、コンソールを使用して失敗したデプロイメントのトラブルシューティングを行います。詳細は、パートナー統合ガイド の director への virt-customize のインストール および root パスワードの設定 を参照してください。この推奨事項を実施する場合は、パスワード管理に関する組織の情報セキュリティーポリシーを順守してください。

あるいは、userdata_root_password.yaml テンプレートを使用して、NodeUserData パラメーターを使用して root パスワードを設定することができます。テンプレートは /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml にあります。

以下の例では、テンプレートを使用して NodeUserData パラメーターを設定します。 

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml
parameter_defaults:
  NodeRootPassword: '<password>'
スケジューラーヒントを使用して、ハードウェアをロールに割り当てる
  • スケジューラーヒントを使用して、Controller、Compute、CephStorage などのロールにハードウェアを割り当てます。スケジューラーヒントにより、特定のハードウェアのみに影響するデプロイメントの問題をより簡単に特定できます。
  • 単一プロセスである nova-scheduler は、多数のノードをスケジュールする際に酷使される可能性があります。スケジューラーヒントは、タグの照合を実装する際に nova-scheduler への負荷を軽減します。その結果、nova-scheduler はデプロイメント時のスケジューリングエラーが減少し、スケジューラーヒントを使用した場合のデプロイメントの所要時間が短縮されました。
  • スケジューラーヒントを使用する場合は、プロファイルのタグ付けを使用しないでください。
  • パフォーマンステストでは、特定のロールに同じハードウェアを使用して、テストおよびパフォーマンスの結果の差異を軽減します。
  • 詳しい情報は、オーバークラウドの高度なカスタマイズ の 特定のノード ID の割り当て を参照してください。
各ノードのルートディスクヒントとして World Wide Name (WWN) を設定し、デプロイメントおよび起動時にノードが誤ったディスクを使用しないようにする。
ノードに複数のディスクが含まれる場合は、イントロスペクションデータを使用し、各ノードのルートディスクヒントとして WWN を設定します。これにより、デプロイメントおよび起動時にノードが誤ったディスクを使用しないようになります。詳細は、Director インストールおよび使用方法 の マルチディスククラスターの Root ディスクの定義 を参照してください。
複数のディスクを持つノードで Bare Metal サービス (ironic) の自動クリーニングを有効にする

Bare Metal サービスの自動クリーニングを使用して、複数のディスクを持ち、複数のブートローダーがある可能性のあるノードでメタデータを消去します。ディスクに複数のブートローダーが存在するため、ノードはブートディスクとの一貫性を失う可能性があり、その結果、誤った URL を使用するメタデータをプルしようとするとノードのデプロイメントに失敗します。

Bare Metal サービスの自動クリーニングを有効にするには、アンダークラウドノードで undercloud.conf ファイルを編集し、以下の行を追加します。 

clean_nodes = true
Bare Metal (ironic) イントロスペクションのノード数を制限する

すべてのノードで同時にイントロスペクションを実行する場合には、ネットワークの制約により失敗する可能性があります。一度に最大 50 のノードでイントロスペクションを実施します。

undercloud.conf ファイルの dhcp_start および dhcp_end の範囲が、環境にあるノードの数に対して十分な大きさになるようにしてください。

利用可能な IP が十分にない場合は、範囲のサイズを超えて発行しないでください。これにより、同時に実行するイントロスペクション操作の数が制限されます。イントロスペクションの DHCP リースが期限切れになるのを許可するには、イントロスペクションが完了してから数分間は IP アドレスをさらに発行しないでください。

異なるタイプの設定向けに Ceph を準備する

以下のリストは、設定タイプ別の推奨事項セットです。

  • オールフラッシュ​ OSD 設定

    それぞれの OSD には、デバイス種別の IOPS 能力に応じて追加の CPU が必要になるため、OSD 数が少ない場合、Ceph IOPS は CPU 性能に依存します。これは、従来の HDD よりも 2 桁大きい IOPS 能力を持つことのできる NVM SSD の場合に言えます。SATA/SAS SSD の場合、HDD よりも 1 桁大きいランダム IOPS/OSD が予想されますが、シーケンシャル IOPS は 2 - 4 倍しか増えません。Ceph が OSD デバイス用に必要とする CPU リソースよりも少ないリソースしか Ceph に提供できません。

  • ハイパーコンバージドインフラストラクチャー (HCI)

    OpenStack Compute (nova) ゲスト用に、CPU パワー、メモリー、およびネットワークの半分以上を確保することが推奨されます。OpenStack Compute (nova) ゲストと Ceph Storage の両方をサポートするのに十分な CPU パワーとメモリーがあることを確認します。Ceph Storage のメモリー消費は弾力的ではないため、メモリー消費を確認します。マルチ CPU ソケットシステムでは、NUMA ピニングされた Ceph で Ceph の CPU 消費を 1 つのソケットに制限します。たとえば、numactl -N 0 -p 0 コマンドを使用します。Ceph のメモリー消費を 1 つのソケットにハードピニングしないでください。

  • NFV 等のレイテンシーに影響を受けるアプリケーション

    異なる NUMA ソケットおよびネットワークカード上で動作するネットワークアプリケーションを使用して、可能であれば Ceph が使用するネットワークカードと同じ CPU ソケットに Ceph を配置し、ネットワークカードの割り込みをその CPU ソケットに制限します。

    デュアルブートローダーを使用する場合は、OSD のマッピングに disk-by-path を使用します。これにより、デバイス名を使用するのとは異なり、ユーザーは一貫性のあるデプロイメントを行うことができます。以下のスニペットは、disk-by-path マッピングの CephAnsibleDisksConfig の例です。 

    CephAnsibleDisksConfig:
  osd_scenario: non-collocated
  devices:
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:0:0
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:1:0
  dedicated_devices:
    - /dev/nvme0n1
    - /dev/nvme0n1
  journal_size: 512

3.2. Red Hat OpenStack のデプロイメント設定

Red Hat OpenStack Platform (RHOSP) デプロイメント設定の推奨事項に関する以下のリストを確認してください。

小規模なデプロイメントにより heat テンプレートを検証する
3 つ以上のコントローラーノード、1 つのコンピュートノード、および 3 つの Ceph Storage ノードで設定される、小規模な環境をデプロイします。この設定を使用して、すべての heat テンプレートが正しいことを確認できます。
アンダークラウドでテレメトリー通知を無効にする

以下の OpenStack サービスについて、アンダークラウドでテレメトリーの通知を無効化し、RabbitMQ キューを削減できます。

  • Compute (nova)
  • Networking (neutron)
  • Orchestration (heat)
  • Identity (keystone)

通知を無効化するには、/usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml テンプレートで、通知ドライバーの設定を noop に設定します。

同時にプロビジョニングされるノードの数を制限する

平均的なエンタープライズレベルのラックユニット内に収まる典型的なサーバーの数は 50 台であるため、1 つのラック分の平均的なノードをデプロイできます。

デプロイメントでの問題を診断するために必要なデバッグを最小限にするには、一度に 50 を超えるノードをデプロイしないでください。ただし、より大きな数のノードをデプロイする場合として、Red Hat では最大 100 ノードの同時テストに成功しています。

コンピュートノードをバッチでスケーリングするには、、--limit オプションを指定して openstack overcloud deploy コマンドを使用します。これにより、時間が節約され、アンダークラウドでのリソース消費が削減されます。

注記

config-download の特定のタスクセットでデプロイメントを実施する場合は、このオプションを使用して config-download Playbook からのタグのコンマ区切りリストを指定します。

未使用の NIC を無効にする

デプロイ中にオーバークラウドに未使用の NIC がある場合は、NIC 設定テンプレートで未使用のインターフェイスを定義して、インターフェイスを use_dhcp: false および defroute: false に設定する必要があります。

未使用のインターフェイスを定義しない場合は、イントロスペクションおよびスケーリング操作中に、ルーティングの問題や IP 割り当ての問題が発生する可能性があります。デフォルトでは、NIC は BOOTPROTO=dhcp を設定します。つまり、未使用のオーバークラウド NIC は、PXE プロビジョニングに必要な IP アドレスを消費します。これにより、ノードで利用可能な IP アドレスのプールが減少する場合があります。

未使用の Bare Metal Provisioning (ironic) ノードの電源をオフにする
メンテナンスモードにある未使用の Bare Metal Provisioning (ironic) ノードの電源をオフにしてください。Red Hat は、以前のデプロイメントからのノードが電源オンの状態でメンテナンスモードになるケースを特定しています。これは、Bare Metal の自動クリーニングで発生する可能性があります。この場合、クリーニングに失敗したノードがメンテナンスモードに設定されます。Bare Metal Provisioning は、メンテナンスモードのノードの電源状態を追跡せず、電源状態を誤ってオフとして報告します。これにより、進行中のデプロイメントで問題が発生する可能性があります。デプロイメントの失敗後に再デプロイする場合は、ノードの電源管理デバイスを使用するすべての未使用ノードの電源をオフにしてください。

3.3. アンダークラウドのチューニング

RHOSP のデプロイメントをスケーリングする予定で、デフォルトのアンダークラウド設定にチューニングを適用する場合には、本セクションを確認してください。

Telemetry サービス (ceilometer) を使用する場合は、サービスのパフォーマンスが向上します

Telemetry は CPU 負荷の高いサービスであるため、RHOSP 16.1 では Telemetry はデフォルトで有効にされません。Telemetry を使用する場合は、サービスのパフォーマンスを高めます。

詳細は、特定の Red Hat OpenStack Platform サービスのデプロイメントに関する推奨事項ガイド の Telemetry サービスの設定に関する推奨事項 を参照してください。

プロビジョニングプロセスと設定プロセスを分離する
  • スタックおよび関連する RHOSP リソースのみを作成するには、--stack-only オプションを指定してデプロイメントコマンドを実行できます。
  • Red Hat は、100 を超えるノードをデプロイする場合、スタックと config-download の手順を分離することを推奨しています。

オーバークラウドに必要なすべての環境ファイルを追加します。 

$ openstack overcloud deploy \
  --templates \
  -e <environment-file1.yaml> \
  -e <environment-file2.yaml> \
  ...
  --stack-only

  • スタックのプロビジョニングが完了したら、tripleo-admin ユーザーのアンダークラウドからオーバークラウドへの SSH アクセスを有効にすることができます。config-download プロセスでは、tripleo-admin ユーザーを使用して Ansible ベースの設定を実施します。 

    $ openstack overcloud admin authorize

  • オーバークラウドスタックの作成を無効にして、ソフトウェア設定を適用する config-download ワークフローのみを実行するには、--config-download-only オプションを指定してデプロイメントコマンドを実行します。オーバークラウドに必要なすべての環境ファイルを追加します。 

    $ openstack overcloud deploy \
 --templates \
 -e <environment-file1.yaml> \
 -e <environment-file2.yaml> \
  ...
 --config-download-only
  • config-download Playbook の実行を特定のノードまたはノードセットに制限するには、--limit オプションを使用します。

  • --limit オプションを使用して、ノードを異なるロールに分割したり、デプロイするノードの数を制限したり、特定のハードウェアタイプでノードを分割したりできます。スケールアップ操作の場合、新しいノードにのみソフトウェア設定を適用するには、--config-download-only オプションと共に --limit オプションを使用します。 

    $ openstack overcloud deploy \
--templates \
-e <environment-file1.yaml> \
-e <environment-file2.yaml> \
...
--config-download-only --config-download-timeout --limit <Undercloud>,<Controller>,<Compute-1>,<Compute-2>

3.4. オーバークラウドのチューニング

Red Hat OpenStack Platform (RHOSP) のデプロイメントをスケーリングする予定で、デフォルトのオーバークラウド設定にチューニングを適用する場合には、以下のセクションを確認してください。

フェイルオーバーを防ぐために OVN OVSDB クライアント確認間隔を増やします

大規模な RHOSP デプロイメントの OVSDB クライアント確認間隔を増やします。Pacemaker は、設定されたタイムアウト内に OVN からの応答を取得しない場合に、ovn-dbs-bundle のフェイルオーバーをトリガーします。OVN OVSDB クライアント確認間隔を 360 秒に増やすには、heat テンプレートの OVNDBSPacemakerTimeout パラメーターを編集します。 

OVNDBSPacemakerTimeout: 360

それぞれのコンピュートノードおよびコントローラーノードで、OVN コントローラーは OVN SBDB を定期的に確認し、これらの要求がタイムアウトした場合には、OVN コントローラーが再同期します。リソースの作成要求が複数のコンピュートノードおよびコントローラーノードに読み込まれる場合、デフォルトの 60 秒のタイムアウト値は十分ではありません。OVN SBDB クライアント確認間隔を 180 秒に増やすには、heat テンプレートの OVNOpenflowProbeInterval パラメーターを編集します。 

ControllerParameters:
  OVNRemoteProbeInterval: 180000
  OVNOpenflowProbeInterval: 180
注記

RHOSP ユーザーおよびサービスによってトリガーされた操作時に、リソースの制約 (CPU または メモリーリソースの制約) により、複数のコンポーネントが設定したタイムアウト値に到達する場合があります。これにより、haproxy フロントエンドまたはバックエンドへのタイムアウトリクエストの失敗、メッセージングタイムアウト、db クエリー関連の失敗、クラスターの不安定性などが生じる可能性があります。初回のデプロイメント後にオーバークラウド環境のベンチマークテストを実施し、タイムアウト関連のボトルネックを特定するのに役立てます。

第4章 デバッグの推奨問題および既知の問題

デプロイメントのトラブルシューティングに役立つ可能性のあるデバッグの提案については、以下のセクションを参照してください。

4.1. 既知の問題

既存の現在の制限の概要を以下に示します。

BZ#1857451 - Ansible forks value should have an upper limit and Current Calculation needs to change
デフォルトでは、mistral の Ansible Playbook は、ansible.cfg ファイルの 10*CPU_COUNT フォークを使用するように設定されています。Ansible の実行を特定ノードまたはノードセットに制限する --limit オプションは使用せず、Ansible 実行がすべての既存ノードで実行されるように設定されている場合、Ansible はメモリーをほぼ 100% 消費します。

4.2. イントロスペクションのデバッグ

イントロスペクションをデバッグする際には、以下のリストに示す推奨事項を確認してください。

undercloud.conf ファイルでイントロスペクション用 DHCP 範囲と NIC を確認する
これらの値のいずれかが誤りである場合は修正し、openstack undercloud install コマンドを再度実行します。
DHCP 範囲のノードが許容できるよりも多くのノードでイントロスペクションを試行しないようにする
各ノードの DHCP リースは、イントロスペクションの終了後約 2 分間アクティブな状態を維持します。
ターゲットノードが応答している状態にする
全ノードでイントロスペクションに異常が発生した場合は、設定済みの NIC を使用してネイティブ VLAN 経由でターゲットノードを ping できること、および帯域外インターフェイスの認証情報およびアドレスが正しいことを確認します。
コンソールでイントロスペクションコマンドを確認する
特定のノードをデバッグする際には、ノードのブート時にコンソールを監視し、ノードのイントロスペクションコマンドを確認します。PXE プロセスの完了前にノードが停止した場合は、接続、IP の割り当て、およびネットワーク負荷を確認します。ノードが BIOS を終了し、イントロスペクションイメージでブートする場合は、障害はまれで、ほぼ接続性の問題に関連します。イントロスペクションイメージからのハートビートが、アンダークラウドへの伝送中に中断されないようにします。

4.3. デプロイメントのデバッグ

デプロイメントをデバッグには、以下の推奨事項を実行してください。

プロビジョニングネットワーク上のアドレスを提供する DHCP サーバーを検証する

プロビジョニングネットワーク上のアドレスを提供する追加の DHCP サーバーが原因で、Red Hat OpenStack Platform director はマシンを検査およびプロビジョニングできなくなる場合があります。

  • DHCP または PXE のイントロスペクションの問題が発生した場合は、以下のコマンドを入力します。 

    $ sudo tcpdump -i any port 67 or port 68 or port 69

  • DHCP または PXE のデプロイメントの問題が発生した場合は、以下のコマンドを入力します。 

    $ sudo ip netns exec qdhcp tcpdump -i <interface> port 67 or port 68 or port 69
障害が発生したディスクまたは外部ディスクの状態を確認する
障害が発生したディスクまたは外部ディスクは、ディスクの状態をチェックし、マシンの帯域外管理に応じて、失敗したディスクまたは外部ディスクの状態が Up に設定されていることを確認します。デプロイメントサイクル中にディスクの Up 状態が終了し、ベースオペレーティングシステムに表示されるディスクの順番が変化する可能性があります。
以下のコマンドを使用して、失敗したオーバークラウドのデプロイメントをデバッグする
  • openstack stack failures list overcloud
  • heat resource-list -n5 overcloud | grep -i fail
  • less /var/lib/mistral/config-download-latest/ansible.log

コマンドの出力を確認するには、障害が発生するノードにログインして、/var/log/ および /var/log/containers/ のログファイルを確認します。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
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, the Red Hat 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 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.