特定の Red Hat OpenStack Platform サービスのデプロイメントに関する推奨事項
Red Hat OpenStack Platform Telemetry サービスおよび Object Storage サービスの最大パフォーマンスの活用
OpenStack Documentation Team
rhos-docs@redhat.com概要
第1章 オーバークラウドを最適化する理由
大規模なオーバークラウドにスケーリングする、あるいは大規模なオーバークラウドをデプロイする予定の場合は、オーバークラウドを最適化して、ワークロードが増えるにつれてパフォーマンスの問題が発生するのを防ぎます。これらの推奨事項に従うことで、スケーリングがオーバークラウドの Telemetry サービスおよび Object Storage サービスのパフォーマンスに影響を与えるのを防ぐことが可能です。
第2章 Telemetry サービスの設定に関する推奨事項
Red Hat OpenStack Platform (RHOSP) Telemetry は CPU 負荷の高いサービスであるため、RHOSP 16.1 では Telemetry はデフォルトで有効にされません。ただし、これらのデプロイメントの推奨事項に従うことで、Telemetry を有効にした場合のパフォーマンス低下を回避することができます。
これらの手順(1 つは小規模なテストオーバークラウド用、もう 1 つは大規模な実稼働オーバークラウド用)には、Telemetry サービスのパフォーマンスを最大化する推奨事項が含まれています。
2.1. 小規模なテスト用オーバークラウド上での Telemetry サービスの設定
小規模なテストオーバークラウドで Red Hat OpenStack Platform (RHOSP) Telemetry サービスを有効にする場合、ファイルバックエンドを使用してそのパフォーマンスを向上させることができます。
前提条件
- Telemetry サービスを設定するオーバークラウドのデプロイメントが、実稼働環境用のシステム ではない。
- オーバークラウドは、100 未満のインスタンスをサポートする小規模なデプロイメントで、各コントローラーノードの物理コアは最大でも 12 (ハイパースレッディング機能が有効な場合は 24 コア) である。
- オーバークラウドデプロイメントの高可用性は 無効である。
手順
/usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml環境ファイルのparameter_defaultsに以下を追加します。parameter_defaults: GnocchiBackend: file
enable-legacy-telemetry.yamlファイルをopenstack overcloud deployコマンドに追加します。openstack overcloud deploy \ -e /home/stack/environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml \ [...]
関連情報
- Director のインストールおよび使用方法の オーバークラウド環境の変更
2.2. 大規模な実稼働用オーバークラウド上での Telemetry サービスの設定
大規模な実稼働用オーバークラウドで Red Hat OpenStack Platform (RHOSP) Telemetry サービスを有効にする場合、Telemetry サービスを専用のノードにデプロイしてそのパフォーマンスを向上させることができます。
Telemetry サービスは、常にストレージバックエンドとして選択された RHOSP オブジェクトストアを使用します。Red Hat Ceph Storage を有効にしない場合、Telemetry サービスは RHOSP Object Storage サービス (swift) を使用します。デフォルトでは、RHOSP director は Object Storage サービスと Telemetry サービスを Controller 上に共存させます。
時系列データベース (gnocchi) ストレージ用の RHOSP オブジェクトストレージ (swift) の使用は、小規模で非実稼働環境でのみサポートされています。
前提条件
- Telemetry サービスをデプロイするオーバークラウドが、大規模な実稼働用のオーバークラウドである。
手順
専用のテレメトリーノードを設定するには、Controller ロールから Telemetry サービスを削除します。
/usr/share/openstack-tripleo-heat-templates/roles_data.yamlを/home/stack/templates/roles_data.yamlにコピーして、Orchestration サービス (heat) カスタム環境ファイルを作成します。/home/stack/templates/roles_data.yamlで、Controller ロールのServicesDefault一覧から以下の行を削除します。- OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::AodhListener - OS::TripleO::Services::PankoApi - OS::TripleO::Services::CeilometerAgentIpmi以下のスニペットを追加して
roles_data.yamlを保存します。- name: Telemetry ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::Timezone - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Securetty - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::SensuClient - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::AuditD - OS::TripleO::Services::Collectd - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::Docker - OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::AodhListener - OS::TripleO::Services::PankoApi - OS::TripleO::Services::CeilometerAgentIpmi/home/stack/node-info.yamlファイルで、Telemetry サービスの専用ノード数を設定します。たとえば、
TelemetryCount:3をparameter_defaultsに追加して、3 つの専用 Telemetry ノードをデプロイします。parameter_defaults: TelemetryCount: 3
これで、カスタムの Telemetry ロールが追加されました。
このロールで、新規フレーバーを定義して、特定のテレメトリーノードをタグ付けして割り当てることができます。
オーバークラウドをデプロイする際には、
roles_data.yamlおよびstorage-environment.yamlをopenstack overcloud deployコマンドが呼び出すテンプレートおよび環境ファイルの一覧に追加します。$ openstack overcloud deploy \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/storage-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml \ [...]
- Object Storage に専用ノードを割り当てることができない場合は、コントローラーノード上で全ストレージ I/O を下げて動作するように Object Storage を設定します。
関連情報
- Advanced Overcloud Customizationの Creating a New Role
- Object Storage サービス (swift) の設定に関する推奨事項
- Director Installation and Usageの Modifying the Overcloud Environment
第3章 Object Storage サービス (swift) の設定に関する推奨事項
Red Hat Ceph Storage を使用せずに Red Hat OpenStack Platform (RHOSP) をデプロイする場合、RHOSP director は RHOSP Object Storage サービス (swift) をデプロイします。Object Store サービスは、RHOSP Telemetry サービスおよび RabbitMQ を含む複数の OpenStack サービスのオブジェクトストアです。Object Storage サービスと共に Telemetry サービスを使用する場合における、RHOSP のパフォーマンスを向上させるためのさまざまな推奨事項を以下に示します。
3.1. Object Storage サービスのディスク設定に関する推奨事項
Red Hat OpenStack Platform (RHOSP) Object Storage サービス用に、1 つまたは複数の独立したローカルディスクを使用します。
デフォルトでは、RHOSP director は、Object Storage サービス用にシステムディスクの /srv/node/d1 ディレクトリーを使用します。コントローラーではこのディスクは他のサービスにも使用され、エンタープライズ設定で Telemetry サービスがイベントの記録を開始した後に、ディスクがパフォーマンスのボトルネックになる可能性があります。
以下の例は、RHOSP Orchestration サービス (heat) のカスタム環境ファイルからの抜粋です。各コントローラーノードで、Object Storage サービスは 2 つの独立したディスクを使用します。両方のディスク全体には XFS ファイルシステムが含まれています。
parameter_defaults:
SwiftRawDisks: {"sdb": {}, "sdc": {}}
SwiftRawDisks は、ノード上の各ストレージディスクを定義します。以下の例では、各コントローラーノードの sdb ディスクと sdc ディスクの両方を定義します。
複数のディスクを設定する場合は、Bare Metal サービス (ironic) が必ず目的のルートディスクを使用するようにします。
関連情報
- Director Installation and Usage の Defining the Root Disk for Nodes
3.2. Object Storage の専用ノードの定義
ノードを Red Hat OpenStack Platform (RHOSP) Object Storage サービス専用とすることで、パフォーマンスが向上します。
手順
-
(デフォルトの
/usr/share/openstack-tripleo-heat-templates/roles_data.yamlをベースとする) カスタムのroles_data.yamlファイルを作成します 。 カスタム
roles_data.yamlファイルを編集し、コントローラーノードから Object Storage サービスのエントリーを削除します。具体的には、
ControllerロールのServicesDefault一覧から以下の行を削除します。- OS::TripleO::Services::SwiftStorage
カスタム環境ファイルで
ObjectStorageCountリソースを使用して、Object Storage サービスに割り当てる専用ノードの数を設定します。たとえば、
ObjectStorageCount:3を環境ファイルのparameter_defaultsに追加して、3 つのオブジェクトストレージ専用ノードをデプロイします。parameter_defaults: ObjectStorageCount: 3
この設定を適用するには、その他の環境ファイルと共に
roles_data.yamlをスタックに追加して、オーバークラウドをデプロイします。(undercloud) $ openstack overcloud deploy --templates \ -e [your environment files] -e /home/stack/templates/roles_data.yaml
関連情報
- オーバークラウドの高度なカスタマイズ の コンポーザブルサービスとカスタムロール
- オーバークラウドの高度なカスタマイズの ロールへのサービスの追加と削除
- Director のインストールおよび使用方法の オーバークラウド環境の変更
3.3. Object Storage サービスにおけるパーティションのべき乗に関する推奨事項
Red Hat OpenStack Platform (RHOSP) Object Storage サービス用に独立したノードを使用する場合には、パーティションのべき乗により大きな値を使用します。
Object Storage サービスは、変更した ハッシュリング を使用して、データをディスクとノードに分散します。デフォルトでは、アカウント用、コンテナー用、およびオブジェクト用の 3 つのリングがあります。各リングは、パーティションのべき乗 と呼ばれる固定パラメーターを使用します。このパラメーターは、作成可能なパーティションの最大数を設定します。
パーティションのべき乗パラメーターは重要で、新規コンテナーとそのオブジェクトについてしか変更できません。そのため、初回デプロイメント の前にこの値を設定することが重要になります。
RHOSP director がデプロイする環境のデフォルトのパーティションのべき乗値は 10 です。小規模なデプロイメント、特に Object Storage サービスにコントローラーノード上のディスクだけを使用する計画の場合には、これが妥当な値です。
以下の表は、3 つのレプリカを使用する場合に適切なパーティションのべき乗を選択するのに役立ちます。
表3.1 利用可能なディスクの数に対する適切なパーティションのべき乗値
| パーティションのべき乗 | ディスクの最大数 |
| 10 | 35 まで |
| 11 | 75 まで |
| 12 | 150 まで |
| 13 | 250 まで |
| 14 | 500 まで |
パーティションのべき乗に過剰に大きな値を設定すると (例: 40 ディスクに対して 14)、レプリケーション時間に悪影響を及ぼします。
パーティションのべき乗を設定するには、以下のリソースを使用します。
parameter_defaults: SwiftPartPower: 11
新しいコンテナーに追加のオブジェクトサーバーリングを設定することもできます。これは、当初小さなパーティションのべき乗値を使用する Object Storage サービスのデプロイメントにディスクを追加する場合に便利です。
関連情報
- ストレージガイド の Object Storage リング
- swift のアップストリームドキュメントの The Rings
- Director のインストールおよび使用方法の オーバークラウド環境の変更
