4.3. 複数のクラウドの設定
Service Telemetry Framework (STF) の単一インスタンスをターゲットにするように複数の Red Hat OpenStack Platform (RHOSP) クラウドを設定できます。複数のクラウドを設定する場合に、クラウドはすべて独自で一意のメッセージバストピックでメトリクスおよびイベントを送信する必要があります。STF デプロイメントでは、Smart Gateway インスタンスは、これらのトピックをリッスンして、共通のデータストアに情報を保存します。データストレージドメインの Smart Gateway によって保存されるデータは、各 Smart Gateway が作成するメタデータを使用してフィルターされます。
図4.1 RHOSP の 2 つのクラウドが STF に接続

複数のクラウドのシナリオで RHOSP オーバークラウドを設定するには、次のタスクを実行します。
- 各クラウドで使用する AMQP アドレスの接頭辞を計画します。詳細は、「AMQP アドレス接頭辞の計画」 を参照してください。
- メトリクスとイベントのコンシューマーである Smart Gateway を各クラウドに配備し、対応するアドレス接頭辞をリッスンします。詳細は、「Smart Gateway の導入」 を参照してください。
- 各クラウドに固有のドメイン名を設定します。詳細は、「独自のクラウドドメインの設定」 を参照してください。
- STF の基本設定を作成します。詳細は、「STF の基本設定の作成」 を参照してください。
- 各クラウドがメトリクスやイベントを正しいアドレスで STF に送信するように設定します。詳細は、「複数クラウドの Red Hat OpenStack Platform 環境ファイルの作成」 を参照してください。
4.3.1. AMQP アドレス接頭辞の計画
デフォルトでは、Red Hat OpenStack Platform (RHOSP) ノードは、collectd と Ceilometer という 2 つのデータコレクターを通じてデータを受け取ります。collectd-sensubility プラグインでは、固有のアドレスが必要です。これらのコンポーネントは、Telemetry データまたは通知をそれぞれの AMQP アドレス (例: collectd/telemetry) に送信します。STF Smart Gateway は、データのこれらの AMQP アドレスでリッスンします。複数のクラウドをサポートし、どのクラウドが監視データを生成したかを識別するために、各クラウドがデータを固有のアドレスに送信するように設定します。アドレスの 2 番目の部分に、クラウド識別子の接頭辞を追加します。以下のリストは、アドレスと識別子の例です。
-
collectd/cloud1-telemetry -
collectd/cloud1-notify -
sensubility/cloud1-telemetry -
anycast/ceilometer/cloud1-metering.sample -
anycast/ceilometer/cloud1-event.sample -
collectd/cloud2-telemetry -
collectd/cloud2-notify -
sensubility/cloud2-telemetry -
anycast/ceilometer/cloud2-metering.sample -
anycast/ceilometer/cloud2-event.sample -
collectd/us-east-1-telemetry -
collectd/us-west-3-telemetry
4.3.2. Smart Gateway の導入
各クラウドのデータ収集タイプごとに、collectd メトリクス用、collectd イベント用、Ceilometer メトリクス用、Ceilometer イベント用、collectd-sensubility メトリクス用の Smart Gateway を導入する必要があります。各 Smart Gateway は、対応するクラウドに定義された AMQP アドレスをリッスンするように設定します。Smart Gateway を定義するには、ServiceTelemetry マニフェストに clouds パラメーターを設定します。
STF を初めてデプロイする際は、1 つのクラウドに対する初期の Smart Gateway を定義する Smart Gateway マニフェストが作成されます。複数のクラウドサポートに Smart Gateway をデプロイする場合には、メトリクスおよび各クラウドのイベントデータを処理するデータ収集タイプごとに、複数の Smart Gateway をデプロイします。最初の Smart Gateway は、以下のサブスクリプションアドレスを使用して cloud1 で定義されます。
| collector | type | デフォルトサブスクリプションアドレス |
| collectd | metrics | collectd/telemetry |
| collectd | events | collectd/notify |
| collectd-sensubility | metrics | sensubility/telemetry |
| Ceilometer | metrics | anycast/ceilometer/metering.sample |
| Ceilometer | events | anycast/ceilometer/event.sample |
前提条件
- クラウドの命名方法を決めています。命名スキームの決定の詳細は、「AMQP アドレス接頭辞の計画」 を参照してください。
-
clouds オブジェクトのリストを作成しました。
cloudsパラメーターのコンテンツ作成の詳細は、「clouds パラメーター」 を参照してください。
手順
- Red Hat OpenShift Container Platform にログインします。
service-telemetrynamespace に切り替えます。$ oc project service-telemetry
defaultの ServiceTelemetry オブジェクトを編集し、設定でcloudsパラメーターを追加します。警告クラウド名が長くなると、Pod 名の最大長 63 文字を超える可能性があります。
ServiceTelemetry名のdefaultとclouds.nameの組み合わせが 19 文字を超えないようにしてください。クラウド名には、-などの特殊文字を含めることはできません。クラウド名を英数字 (a-z、0-9) に制限します。トピックアドレスには文字の制限がなく、
clouds.nameの値とは異なる場合があります。$ oc edit stf default
apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: ... spec: ... clouds: - name: cloud1 events: collectors: - collectorType: collectd subscriptionAddress: collectd/cloud1-notify - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/cloud1-event.sample metrics: collectors: - collectorType: collectd subscriptionAddress: collectd/cloud1-telemetry - collectorType: sensubility subscriptionAddress: sensubility/cloud1-telemetry - collectorType: ceilometer subscriptionAddress: anycast/ceilometer/cloud1-metering.sample - name: cloud2 events: ...- ServiceTelemetry オブジェクトを保存します。
各 Smart Gateway が起動していることを確認します。この作業は、Smart Gateway の台数によっては数分かかることがあります。
$ oc get po -l app=smart-gateway NAME READY STATUS RESTARTS AGE default-cloud1-ceil-event-smartgateway-6cfb65478c-g5q82 2/2 Running 0 13h default-cloud1-ceil-meter-smartgateway-58f885c76d-xmxwn 2/2 Running 0 13h default-cloud1-coll-event-smartgateway-58fbbd4485-rl9bd 2/2 Running 0 13h default-cloud1-coll-meter-smartgateway-7c6fc495c4-jn728 2/2 Running 0 13h default-cloud1-sens-meter-smartgateway-8h4tc445a2-mm683 2/2 Running 0 13h
4.3.3. デフォルトの Smart Gateway を削除
複数のクラウドに Service Telemetry Framework (STF) を設定したら、デフォルトの Smart Gateway が使用されなくなった場合に、そのゲートウェイを削除できます。Service Telemetry Operator は、作成済みではあるが、オブジェクトの ServiceTelemetry clouds 一覧に表示されなくなった SmartGateway オブジェクトを削除できます。clouds パラメーターで定義されていない SmartGateway オブジェクトの削除を有効にするには、ServiceTelemetry マニフェストで cloudsRemoveOnMissing パラメーターを true に設定する必要があります。
Smart Gateway をデプロイしない場合は、clouds: [] パラメーターを使用して空のクラウド一覧を定義します。
cloudsRemoveOnMissing パラメーターはデフォルトで無効にされています。cloudsRemoveOnMissing パラメーターが有効な場合には、現在の namespace で手動で作成された SmartGateway オブジェクトを削除するとそのオブジェクトは復元できません。
手順
-
Service Telemetry Operator が管理するクラウドオブジェクトの一覧で
cloudsパラメーターを定義します。詳細は、「clouds パラメーター」 を参照してください。 ServiceTelemetry オブジェクトを編集し、
cloudsRemoveOnMissingパラメーターを追加します。apiVersion: infra.watch/v1beta1 kind: ServiceTelemetry metadata: ... spec: ... cloudsRemoveOnMissing: true clouds: ...- 修正内容を保存します。
オペレーターが Smart Gateway を削除したことを確認します。Operator が変更を調整する間、数分かかることがあります。
$ oc get smartgateways
4.3.4. 独自のクラウドドメインの設定
Red Hat OpenStack Platform (RHOSP) から Service Telemetry Framework (STF) への AMQ Interconnect ルーター接続が一意で、競合しないようにするには、CloudDomain パラメーターを設定します。
既存のデプロイメントではホスト名またはドメイン名を変更しないようにしてください。ホストとドメイン名の設定は、新しいクラウドデプロイメントでのみサポートされます。
手順
-
新しい環境ファイルを作成します (例:
hostnames.yaml)。 以下の例に示すように、環境ファイルで
CloudDomainパラメーターを設定します。hostnames.yaml
parameter_defaults: CloudDomain: newyork-west-04 CephStorageHostnameFormat: 'ceph-%index%' ObjectStorageHostnameFormat: 'swift-%index%' ComputeHostnameFormat: 'compute-%index%'- 新しい環境ファイルをデプロイメントに追加します。
関連情報
- 「複数クラウドの Red Hat OpenStack Platform 環境ファイルの作成」
- オーバークラウドパラメーター ガイドの コアオーバークラウドパラメーター
4.3.5. 複数クラウドの Red Hat OpenStack Platform 環境ファイルの作成
発信元のクラウドに応じてトラフィックをラベリングするには、クラウド固有のインスタンス名を持つ設定を作成する必要があります。stf-connectors.yaml ファイルを作成し、CeilometerQdrEventsConfig、CeilometerQdrMetricsConfig、および CollectdAmqpInstances の値を調整して AMQP アドレスの接頭辞スキームと一致するようにします。
コンテナーのヘルスおよび API ステータスのモニターリングを有効にしている場合は、CollectdSensubilityResultsChannel パラメーターも変更する必要があります。詳細は、「Red Hat OpenStack Platform API のステータスおよびコンテナー化されたサービスの健全性」 を参照してください。
前提条件
- STF によってデプロイされる AMQ Interconnect から CA 証明書を取得している。詳細は、「オーバークラウドの設定向け Service Telemetry Framework からの CA 証明書の取得」 を参照してください。
- clouds オブジェクトのリストを作成しました。clouds パラメーターのコンテンツを作成する方法については、clouds 設定パラメーター を参照してください。
- AMQ Interconnect のルートアドレスを取得しました。詳細は、「AMQ Interconnect ルートアドレスの取得」 を参照してください。
- これで STF の基本設定ができました。詳細は、「STF の基本設定の作成」 を参照してください。
- 固有のドメイン名環境ファイルを作成しました。詳細は、「独自のクラウドドメインの設定」 を参照してください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 -
/home/stackディレクトリーにstf-connectors.yamlという設定ファイルを作成します。 stf-connectors.yamlファイルで、オーバークラウドデプロイメント上の AMQ Interconnect をに接続するようにMetricsQdrConnectorsアドレスを設定します。CeilometerQdrEventsConfig、CeilometerQdrMetricsConfig、CollectdAmqpInstances、およびCollectdSensubilityResultsChannelトピックの値を、このクラウドデプロイメントに必要な AMQP アドレスに一致するように設定します。stf-connectors.yaml
resource_registry: OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-puppet.yaml parameter_defaults: MetricsQdrConnectors: - host: default-interconnect-5671-service-telemetry.apps.infra.watch port: 443 role: edge verifyHostname: false sslProfile: sslProfile MetricsQdrSSLProfiles: - name: sslProfile caCertFileContent: | -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- CeilometerQdrEventsConfig: driver: amqp topic: cloud1-event CeilometerQdrMetricsConfig: driver: amqp topic: cloud1-metering CollectdAmqpInstances: cloud1-notify: notify: true format: JSON presettle: false cloud1-telemetry: format: JSON presettle: false CollectdSensubilityResultsChannel: sensubility/cloud1-telemetry-
複数のクラウドデプロイメント用に
collectd-write-qdr.yaml環境ファイルを含めないため、resource_registry設定は collectd サービスを直接ロードします。 -
hostパラメーターを、「AMQ Interconnect ルートアドレスの取得」 で取得した値に置き換えます。 -
caCertFileContentパラメーターを、「オーバークラウドの設定向け Service Telemetry Framework からの CA 証明書の取得」 で取得したコンテンツに置き換えます。 -
MetricsQdrConnectorsのhostサブパラメーターを、「AMQ Interconnect ルートアドレスの取得」 で取得した値に置き換えます。 -
CeilometerQdrEventsConfigのトピック値を設定して、Ceilometer イベントのトピックを定義します。値は、cloud1-eventなどのクラウドの一意のトピック識別子です。 -
CeilometerQdrMetricsConfig.topicのtopic値を設定して、Ceilometer メトリックのトピックを定義します。値は、cloud1-meteringなどのクラウドの一意のトピック識別子です。 -
CollectdAmqpInstancesサブパラメーターを設定して、collectd イベントのトピックを定義します。セクション名は、cloud1-notifyなどのクラウドの一意のトピック識別子です。 -
CollectdAmqpInstancesサブパラメーターを設定して、collectd メトリックのトピックを定義します。セクション名は、cloud1-telemetryなどのクラウドの一意のトピック識別子です。 CollectdSensubilityResultsChannelを設定して、collectd-sensubility イベントのトピックを定義します。値は、sensubility/cloud1-telemetryなどのクラウドの一意のトピック識別子です。注記collectd および Ceilometer のトピックを定義すると、指定した値は、Smart Gateway クライアントがメッセージをリッスンするために使用する完全なトピックに置き換えられます。
Ceilometer トピック値はトピックアドレス
anycast/ceilometer/<TOPIC>.sampleに置き換えられ、collectd トピック値はトピックアドレスcollectd/<TOPIC>に置き換えられます。sensubility の値は完全なトピックパスであり、トピック値からトピックアドレスへの転置はありません。完全なトピックアドレスを参照する
ServiceTelemetryオブジェクトのクラウド設定の例については、「clouds パラメーター」 を参照してください。
-
複数のクラウドデプロイメント用に
-
stf-connectors.yamlファイルの命名規則が、Smart Gateway 設定のspec.bridge.amqpUrlフィールドと一致していることを確認します。たとえば、CeilometerQdrEventsConfig.topicフィールドをcloud1-eventの値に設定します。 -
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source stackrc
実際の環境に該当するその他の環境ファイルと共に、
openstack overcloud deploymentコマンドにstf-connectors.yamlファイルおよび一意のドメイン名環境ファイルhostnames.yamlを追加します。警告カスタム
CollectdAmqpInstancesパラメーターでcollectd-write-qdr.yamlファイルを使用する場合、データはカスタムおよびデフォルトのトピックに公開されます。複数のクラウド環境では、stf-connectors.yamlファイルのresource_registryパラメーターの設定では collectd サービスを読み込みます。(undercloud)$ openstack overcloud deploy --templates \ -e [your environment files] \ -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/ceilometer-write-qdr.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-edge-only.yaml \ -e /home/stack/hostnames.yaml \ -e /home/stack/enable-stf.yaml \ -e /home/stack/stf-connectors.yaml
- Red Hat OpenStack Platform オーバークラウドのデプロイ
4.3.5.1. Service Telemetry Framework の Ansible ベースのデプロイ
この機能の内容は、本リリースでは ドキュメントプレビュー として提供されているため、Red Hat で完全には検証していません。テスト用にのみ使用し、実稼働環境では使用しないでください。
Red Hat OpenStack Platform 17.0 の時点で、プレビュー機能として、Puppet の代わりに Ansible を使用して Service Telemetry Framework (STF) コンポーネントをデプロイできます。Ansible の使用には、以下の利点があります。
- 単一のサービス固有の THT 変数 (MetricsQdrVars および CollectdVars) の下での設定の統合
- QDR モードをメッシュモードからエッジのみに切り替える機能
- デプロイスタックで使用されるテクノロジーが少ないため、デバッグプロセスが簡素化されます。
Ansible ベースのデプロイメントを使用するには、stf-connectors.yaml ファイルの resource_registry セクションの puppet を ansible に置き換えます。
OS::TripleO::Services::Collectd: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/collectd-container-ansible.yaml
OS::TripleO::Services::MetricsQdr: /usr/share/openstack-tripleo-heat-templates/deployment/metrics/qdr-container-ansible.yaml設定を設定するには、次の例に示すように、新しいサービス固有の THT 変数を使用します。
parameter_defaults:
MetricsQdrVars:
tripleo_metrics_qdr_deployment_mode: edge-only
CollectdVars:
tripleo_collectd_amqp_host: stf.mycluster.example.comサポートされている設定パラメーターの完全なリストは、上記で参照されているデプロイメントファイルにあります。https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/deployment/metrics/qdr-container-ansible.yaml#L172
関連情報
- デプロイメントの検証方法は、「クライアント側のインストールの検証」 を参照してください。
4.3.6. 複数のクラウドからメトリクスデータを照会
Prometheus に保存されるデータには、収集元の Smart Gateway に従って service ラベルが割り当てられます。このラベルを使用して、特定のクラウドのデータを照会することができます。
特定のクラウドからデータをクエリーするには、関連する service ラベルに一致する Prometheus promql クエリーを使用します (例: collectd_uptime{service="default-cloud1-coll-meter"})。