第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>'
resource_registry: OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml parameter_defaults: NodeRootPassword: '<password>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - スケジューラーヒントを使用して、ハードウェアをロールに割り当てる
-
スケジューラーヒントを使用して、
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
clean_nodes = trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 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の例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow