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

• コントローラーノード 3 台
• データベースノード 3 台
• メッセージングノード 3 台

オーバークラウドイメージの root パスワードを設定します。

• オーバークラウドイメージの root パスワードを設定して、オーバークラウドイメージへのコンソールアクセスを許可する。ネットワークが正しく設定されていない場合に、コンソールを使用して失敗したデプロイメントのトラブルシューティングを行います。パートナー統合ガイド の director への virt-customize のインストール および root パスワード の設定 を参照してください。

特定のノード ID の割り当て

• スケジューラーヒントを使用して、Controller、Compute、CephStorage などのロールにハードウェアを割り当てます。スケジューラーヒントにより、特定のハードウェアのみに影響するデプロイメントの問題をより簡単に特定できます。
• 単一プロセスである nova-scheduler は、多数のノードをスケジュールする際に酷使される可能性があります。タグの照合を実装する際に、スケジューラーヒントは nova-scheduler への負荷を軽減します。その結果、nova-scheduler はデプロイメント時のスケジューリングエラーが少なくなりました。スケジューラーヒントにより、デプロイメントが一般的に短縮されます。
• スケジューラーヒントを使用する場合は、プロファイルのタグ付けを使用しないでください。
• パフォーマンステストでは、特定のロールに同じハードウェアを使用して、テストおよびパフォーマンスの結果の差異を軽減します。
• オーバークラウドの高度なカスタマイズの 特定の ノード ID の割り当て を参照して ください。

ルートディスクヒントの設定

• ノードに複数のディスクが含まれる場合は、イントロスペクションデータを使用して、各ノードのルートディスクヒントとして WWN を設定します。これにより、デプロイメントおよび起動時にノードが誤ったディスクを使用しないようになります。director のインストールと使用方法の ルートディスク の定義 を参照してください。

OpenStack Bare Metal サービス(ironic)のクリーニングを使用する

• ironic の自動クリーニングを使用して、複数のディスクを持ち複数のブートローダーを持つ可能性があるノードでメタデータを削除することを強く推奨します。ディスクに複数のブートローダーが存在することが原因でノードがブートディスクと一貫性がなくなる場合があり、これにより、誤った URL を使用してメタデータをプルする際にノードがデプロイに失敗する場合があります。

ironic イントロスペクションのノード数を制限する

• 一度に全ノードをイントロスペクションすると失敗します。イントロスペクションの場合は、一度に 20 ノードが推奨されます。undercloud.conf ファイルの dhcp_start および dhcp_end の範囲が、環境にあるノードの数に対して十分な大きさになるようにしてください。十分な IP が利用できない場合は、同時にイントロスペクション操作の数を制限するために、範囲のサイズを超えて発行します。イントロスペクションの DHCP リースが期限切れになるのを許可するには、イントロスペクションが完了してから数分間は IP アドレスをさらに発行しないでください。

Ceph の準備

• 以下の一覧は、異なるタイプの設定の推奨事項のセットです。

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

  それぞれの OSD には、デバイス種別の IOPS 能力に応じて追加の CPU が必要になるため、Ceph IOPS は少数の OSD で CPU に制限されます。これは、従来の HDD よりも 2 桁大きい IOPS 能力を持つことのできる NVM SSD の場合に言えます。SATA/SAS SSD の場合、HDD よりも 1 桁大きいランダム IOPS/OSD が予想されますが、シーケンシャル IOPS は 2 - 4 倍しか増えません。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 を Ceph が使用するネットワークカードと同じ CPU ソケットに配置し、ネットワークカードの割り込みをその 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

  Copy to Clipboard Toggle word wrap

小規模なスケールでデプロイメントコマンドを検証する

• 3 つ以上のコントローラーノード、1 つのコンピュートノード、および 3 つの Ceph Storage ノードで設定される小規模な環境をデプロイします。この設定を使用して、すべての heat テンプレートが正しいことを確認することができます。ノードをさらに追加すると、デプロイにかかる時間が長くなるため、この推奨ノードレイアウトとその他のノード種別を使用して、Heat テンプレートに問題が存在するかどうかを確認することができます。

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

• Red Hat は、32 ノードを同時にデプロイすることを推奨します。32 は、平均的なエンタープライズレベルのラックユニット内に収まる一般的なサーバーの量です。これにより、平均の 1 つのラックを同時にデプロイできます。デプロイメントでの問題を診断するために必要なデバッグを最小限にするには、一度に 50 を超えるノードをデプロイしないでください。より多くのノードをデプロイすることに気づいた場合は、Red Hat は最大 100 ノードを同時に成功した状態でテストしました。

未使用の NIC を無効にする

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

未使用の ironic ノードの電源をオフにする

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

Keystone ワーカー数の増加

• Red Hat では、8 つ以上の keystone 管理プロセスと、アンダークラウド上に 4 つの keystone のメインプロセスを使用することを推奨しています。設定ファイルは、/etc/httpd/conf.d/10-keystone_wsgi_admin.conf および /etc/httpd/conf.d/10-keystone_wsgi_main.conf です。

• アップグレード間で永続的な変更を行うには、または openstack undercloud install を再実行する際に、undercloud.conf ファイルに hieradata_override を設定してカスタムの hieradata ファイルを注入します。以下の行をカスタムの hieradata ファイルに追加します。

  keystone::wsgi::apache::custom_wsgi_process_options_admin: { processes : "8" }
  keystone::wsgi::apache::custom_wsgi_process_options_main: { processes : "4" }

  Copy to Clipboard Toggle word wrap

Heat API 呼び出しの応答タイムアウトを増やします。

• デフォルトの rpc_response_timeout は、/etc/heat/heat.conf で 600 秒に設定されています。深刻なリソースの競合がある場合は、タイムアウトを増やします。デプロイメントがメッセージングタイムアウトで終了した場合、これはこの設定を増やすためのインジケーターです。これは一般的な問題にしないでください。

• アップグレード間で永続的な変更を行うか、openstack undercloud install を再実行する際には、以下の行をカスタムの hieradata ファイルに追加し、適切なタイムアウト時間を指定します。

  heat::rpc_response_timeout: 600

  Copy to Clipboard Toggle word wrap

Keystone トークンのタイムアウト時間を増やします。

• オーバークラウドのデプロイのタイムアウト時間を 14,400 秒以上に増やす場合は、keystone.conf の keystone トークンの有効期限のタイムアウトを、秒単位で同等の値に更新する必要があります。デフォルトの Keystone トークンのタイムアウト時間は 14400 秒です。

• アップグレード間で永続的な変更を行うか、openstack undercloud install を再実行する際には、以下の行をカスタムの hieradata ファイルに追加し、適切なタイムアウト時間を指定します。

  * keystone::token_expiration: 14400

  Copy to Clipboard Toggle word wrap

Telemetry が使用されていない場合は、無効にします。

• 請求に使用するメトリックデータが必要ない場合は、Telemetry を無効にします。アンダークラウド上で Telemetry を無効にするには、undercloud.conf ファイルを編集し、enable_telemetry の値を false に変更し、openstack undercloud install コマンドを再実行します。
• openstack overcloud deploy 中に Telemetry を無効にするには、Deployment Recommendations for Specific Red Hat OpenStack Platform Services Guide の Telemetry を参照してください。

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

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

• DHCP または PXE の問題の場合：

  • イントロスペクションの問題については、以下のコマンドを実行します。

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

    Copy to Clipboard Toggle word wrap

  • デプロイメントの問題については、以下を実行します。

    sudo ip netns exec qdhcp tcpdump -i <interface> port 67 or port 68 or port 69

    Copy to Clipboard Toggle word wrap
• 障害の発生したディスクまたは外部ディスクの場合、マシンの帯域外管理に応じて Up 状態を持たないディスクに注意してください。ディスクは、デプロイメントサイクル中に Up の状態を終了し、ディスクがベースオペレーティングシステムに表示される順番を変更する可能性があります。
• openstack stack failures list overcloud、heat resource-list -n5 overcloud | grep -i fail を実行します。出力を確認し、障害が発生するノードにログインして /var/log/ および /var/log/containers/ のログを確認し、journalctl -u os-collect-config を実行します。