第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