Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.2. コントロールプレーンの作成

コントロールプレーンを作成し、Red Hat OpenStack Services on OpenShift (RHOSO) サービスを有効にするには、OpenStackControlPlane カスタムリソース (CR) を定義する必要があります。

次の手順では、各サービスの推奨設定を使用して初期コントロールプレーンを作成します。この手順により、動作するコントロールプレーン環境を迅速に作成できます。この環境を使用して、問題のトラブルシューティングや環境のテストを実行してから、必要なカスタマイズをすべて追加できます。デプロイした環境にサービスのカスタマイズを追加できます。デプロイ後にコントロールプレーンをカスタマイズする方法の詳細は、Red Hat OpenStack Services on OpenShift デプロイメントのカスタマイズ ガイドを参照してください。

OpenStackControlPlane CR の例は、OpenStackControlPlane CR の例 を参照してください。

ヒント

OpenStackControlPlane CRD 定義と仕様スキーマを表示するには、次のコマンドを使用します。 

$ oc describe crd openstackcontrolplane

$ oc explain openstackcontrolplane.spec

手順

  1. ワークステーションに openstack_control_plane.yaml という名前のファイルを作成して、OpenStackControlPlane CR を定義します。 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
  namespace: openstack

  2. Red Hat OpenStack Services on OpenShift へのセキュアなアクセスの提供 で、RHOSO サービス Pod へのセキュアなアクセスを提供するために作成した Secret CR を指定します。 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
  namespace: openstack
spec:
  secret: osp-secret

  3. Red Hat OpenShift Container Platform (RHOCP) クラスターストレージバックエンド用に作成した storageClass を指定します。 

    spec:
  secret: osp-secret
  storageClass: <RHOCP_storage_class>
    • <RHOCP_storage_class> は、RHOCP クラスターストレージバックエンド用に作成したストレージクラスに置き換えます。ストレージクラスの詳細は、ストレージクラスの作成 を参照してください。

  4. RHOSO サービス用のデフォルトの RabbitMQ クラスターを指定するために、RabbitMQ のグローバル設定である messagingBus と notificationsBus を追加します。 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  messagingBus:
    cluster: <rabbitmq-cluster>

  notificationsBus:
    cluster: <rabbitmq-cluster>
    • <rabbitmq-cluster> は、すべての RHOSO サービスが使用するデフォルトの RabbitMQ クラスターに置き換えます。この例では、rabbitmq です。RabbitMQ インターフェイスは OpenStack サービス向けにカスタマイズできます。詳細は、高可用性サービスの監視 ガイドの OpenStack サービスの RabbitMQ インターフェイスについて を参照してください。

  5. 次のサービス設定を追加します。

    注記
    • 次のサービス例は、loadBalancerIPs フィールドにデフォルトの RHOSO MetalLB IPAddressPool 範囲の IP アドレスを使用します。作成した MetalLB IPAddressPool の範囲の IP アドレスで loadBalancerIPs フィールドを更新します。
    • デフォルトのパブリックサービスエンドポイントをオーバーライドできません。パブリックエンドポイントではルートのみがサポートされているため、パブリックサービスエンドポイントはデフォルトで RHOCP ルートとして公開されます。

    • Block Storage サービス (cinder): 

        cinder:
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      cinderAPI:
        replicas: 3
        override:
          service:
            internal:
              metadata:
                annotations:
                  metallb.universe.tf/address-pool: internalapi
                  metallb.universe.tf/allow-shared-ip: internalapi
                  metallb.universe.tf/loadBalancerIPs: 172.17.0.80
              spec:
                type: LoadBalancer
      cinderScheduler:
        replicas: 1
      cinderBackup:
        networkAttachments:
        - storage
        replicas: 0
      cinderVolumes:
        volume1:
          networkAttachments:
          - storage
          replicas: 0
      • cinderBackup.replicas: cinderBackup サービスをアクティブ化せずに初期コントロールプレーンをデプロイできます。サービスをデプロイするには、サービスの replicas の数を設定し、サービスのバックエンドを設定する必要があります。各サービスの推奨レプリカと、Block Storage サービスおよびバックアップサービスのバックエンドを設定する方法は、永続ストレージの設定 の Block Storage バックアップサービスの設定 を参照してください。
      • cinderVolumes.replicas: cinderVolumes サービスをアクティブ化せずに初期コントロールプレーンをデプロイできます。サービスをデプロイするには、サービスの replicas の数を設定し、サービスのバックエンドを設定する必要があります。cinderVolumes サービスの推奨レプリカ数と、サービスのバックエンドを設定する方法は、永続ストレージの設定 の Block Storage ボリュームサービスコンポーネントの設定 を参照してください。

    • Compute サービス (nova): 

        nova:
    apiOverride:
      route: {}
    template:
      apiServiceTemplate:
        replicas: 3
        override:
          service:
            internal:
              metadata:
                annotations:
                  metallb.universe.tf/address-pool: internalapi
                  metallb.universe.tf/allow-shared-ip: internalapi
                  metallb.universe.tf/loadBalancerIPs: 172.17.0.80
              spec:
                type: LoadBalancer
      metadataServiceTemplate:
        replicas: 3
        override:
          service:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/allow-shared-ip: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.80
            spec:
              type: LoadBalancer
      schedulerServiceTemplate:
        replicas: 3
      cellTemplates:
        cell0:
          cellDatabaseAccount: nova-cell0
          cellDatabaseInstance: openstack
          messagingBus:
            cluster: rabbitmq
          hasAPIAccess: true
        cell1:
          cellDatabaseAccount: nova-cell1
          cellDatabaseInstance: openstack-cell1
          messagingBus:
            cluster: rabbitmq-cell1
          noVNCProxyServiceTemplate:
            enabled: true
            networkAttachments:
            - ctlplane
          hasAPIAccess: true
      secret: osp-secret
      注記

      デフォルトでは、各デフォルトセル (cell0 および cell1) に対して、Compute サービス (nova) の完全なセット (nova-api、nova-metadata、nova-scheduler、nova-conductor) がデプロイされます。novncproxy サービスも、デフォルトで cell1 に対して有効になります。

    • データプレーンの DNS サービス: 

        dns:
    template:
      options:
      - key: server
        values:
        - <IP address for DNS server reachable from dnsmasq pod>
      override:
        service:
          metadata:
            annotations:
              metallb.universe.tf/address-pool: ctlplane
              metallb.universe.tf/allow-shared-ip: ctlplane
              metallb.universe.tf/loadBalancerIPs: 192.168.122.80
          spec:
            type: LoadBalancer
      replicas: 2
      • options: キーと値のペアを使用して、各 DNS サーバーに必要な dnsmasq インスタンスを定義します。この例では、リクエストの転送先として設定されている DNS サーバーが 1 つしかないため、定義されているキーと値のペアは 1 つだけです。

      • key: デプロイする dnsmasq インスタンス用にカスタマイズする dnsmasq パラメーターを指定します。以下の有効な値のいずれかに設定します。

        • server
        • rev-server
        • srv-host
        • txt-record
        • ptr-record
        • rebind-domain-ok
        • naptr-record
        • cname
        • host-record
        • caa-record
        • dns-rr
        • auth-zone
        • synth-domain
        • no-negcache
        • local

      • values: RHOCP クラスターネットワーク上の dnsmasq Pod から到達可能な DNS サーバーの値を指定します。値として、汎用 DNS サーバー (例: 1.1.1.1) または特定のドメインの DNS サーバー (例: /google.com/8.8.8.8) を指定できます。

        注記

        この DNS サービス (dnsmasq) は、RHOSO データプレーン上のノードに DNS サービスを提供します。dnsmasq は、クラウドテナントに DNS をサービスとして提供する RHOSO DNS サービス (designate) とは異なります。

    • Identity サービス (keystone) 

        keystone:
    apiOverride:
      route: {}
    template:
      override:
        service:
          internal:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/allow-shared-ip: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.80
            spec:
              type: LoadBalancer
      databaseInstance: openstack
      secret: osp-secret
      replicas: 3

    • Image サービス (glance): 

        glance:
    apiOverrides:
      default:
        route: {}
    template:
      databaseInstance: openstack
      storage:
        storageRequest: 10G
      secret: osp-secret
      keystoneEndpoint: default
      glanceAPIs:
        default:
          replicas: 0 # Configure back end; set to 3 when deploying service
          override:
            service:
              internal:
                metadata:
                  annotations:
                    metallb.universe.tf/address-pool: internalapi
                    metallb.universe.tf/allow-shared-ip: internalapi
                    metallb.universe.tf/loadBalancerIPs: 172.17.0.80
                spec:
                  type: LoadBalancer
          networkAttachments:
          - storage
      • glanceAPIs.default.replicas: Image サービス (glance) をアクティブ化せずに、初期コントロールプレーンをデプロイできます。Image サービスをデプロイするには、サービスの replicas の数を設定し、サービスのバックエンドを設定する必要があります。Image サービスの推奨レプリカとサービスのバックエンドの設定方法は、永続ストレージの設定 の Image サービス (glance) の設定 を参照してください。Image サービスをデプロイしない場合、クラウドへのイメージのアップロードやインスタンスの起動は行えません。

    • Key Management サービス (barbican): 

        barbican:
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      barbicanAPI:
        replicas: 3
        override:
          service:
            internal:
              metadata:
                annotations:
                  metallb.universe.tf/address-pool: internalapi
                  metallb.universe.tf/allow-shared-ip: internalapi
                  metallb.universe.tf/loadBalancerIPs: 172.17.0.80
              spec:
                type: LoadBalancer
      barbicanWorker:
        replicas: 3
      barbicanKeystoneListener:
        replicas: 1

    • Networking サービス (neutron): 

        neutron:
    apiOverride:
      route: {}
    template:
      replicas: 3
      override:
        service:
          internal:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/allow-shared-ip: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.80
            spec:
              type: LoadBalancer
      databaseInstance: openstack
      secret: osp-secret
      networkAttachments:
      - internalapi
      重要

      既知の問題 [1] のため、mac_binding_age_threshold を 0 に 設定する必要があります。デフォルト値は 300 です。今後の RHOSO 18.0 リリースで問題が解決されたら、mac_binding_age_threshold を 300 にリセットする必要があります。

      この問題は、OVN コアのバグが原因です。このバグにより、OVN はローカルネットワークに接続されているすべてのポートに対して、アドレス解決プロトコル (ARP) メッセージと近隣探索プロトコル (ND) メッセージを送信してしまう。別のシャーシ内の論理ルーターポートがゲートウェイ IP を検出すると、MAC_Binding レジスターを作成し、誤った MAC アドレスを含む ARP/ND を返信します。それは外部スイッチ/ルーターを混乱させる。

      [1] RHOSO 18.0.18 およびそれ以前のバージョンに影響する既知の問題の詳細は、OVN MAC_Binding のエージングは、コア OVN が修正されるまで 0 にする必要があります を参照してください。

    • Object Storage サービス (swift): 

        swift:
    enabled: true
    proxyOverride:
      route: {}
    template:
      swiftProxy:
        networkAttachments:
        - storage
        override:
          service:
            internal:
              metadata:
                annotations:
                  metallb.universe.tf/address-pool: internalapi
                  metallb.universe.tf/allow-shared-ip: internalapi
                  metallb.universe.tf/loadBalancerIPs: 172.17.0.80
              spec:
                type: LoadBalancer
        replicas: 2
        secret: osp-secret
      swiftRing:
        ringReplicas: 3
      swiftStorage:
        networkAttachments:
        - storage
        replicas: 3
        storageRequest: 10Gi

    • Optimize サービス (watcher): 

        watcher:
    enabled: true

    • OVN: 

        ovn:
    template:
      ovnDBCluster:
        ovndbcluster-nb:
          replicas: 3
          dbType: NB
          storageRequest: 10G
          networkAttachment: internalapi
        ovndbcluster-sb:
          replicas: 3
          dbType: SB
          storageRequest: 10G
          networkAttachment: internalapi
      ovnNorthd: {}

    • Placement サービス (placement): 

        placement:
    apiOverride:
      route: {}
    template:
      override:
        service:
          internal:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/allow-shared-ip: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.80
            spec:
              type: LoadBalancer
      databaseInstance: openstack
      replicas: 3
      secret: osp-secret

    • オプション: Telemetry サービス (ceilometer、prometheus): 

        telemetry:
    enabled: true
    template:
      metricStorage:
        enabled: true
        dashboardsEnabled: true
        dataplaneNetwork: ctlplane
        networkAttachments:
          - ctlplane
        monitoringStack:
          alertingEnabled: true
          scrapeInterval: 30s
          storage:
            strategy: persistent
            retention: 24h
            persistent:
              pvcStorageRequest: 20G
      autoscaling:
        enabled: false
        aodh:
          databaseAccount: aodh
          databaseInstance: openstack
          passwordSelector:
            aodhService: AodhPassword
          serviceUser: aodh
          secret: osp-secret
        heatInstance: heat
      ceilometer:
        enabled: true
        secret: osp-secret
      logging:
        enabled: false
      • telemetry.enabled: RHOSO 環境で Telemetry サービスが必要ない場合は false に設定します。true の場合、RHOCP クラスターに Cluster Observability Operator をインストールする必要があります。
      • telemetry.template.metricStorage.dataplaneNetwork: データプレーン node_exporter エンドポイントをスクレイピングするために使用するネットワークを定義します。
      • telemetry.template.metricStorage.networkAttachments: NetworkAttachmentDefinition リソース名を使用して、各サービス Pod がアタッチされているネットワークをリスト表示します。指定したネットワークアタッチメントごとに、サービスの NIC を設定します。各サービス Pod が割り当てられている分離ネットワークを設定しなかった場合は、デフォルトの Pod ネットワークが使用されます。Prometheus がデータプレーンノードからデータをスクレイピングできるように、dataplaneNetwork として指定したネットワークと一致する networkAttachment を作成する必要があります。
      • telemetry.template.autoscaling: 自動スケーリングが無効になっている場合でも、autoscaling フィールドが存在している必要があります。自動スケーリングの詳細は、インスタンスの自動スケーリング を参照してください。

  6. 次のサービス設定を追加して、高可用性 (HA) を実装します。

    • すべての RHOSO サービスで使用するための MariaDB Galera クラスター (openstack) と、cell1 の Compute サービスで使用するための MariaDB Galera クラスター (openstack-cell1)。 

        galera:
    templates:
      openstack:
        storageRequest: 5000M
        secret: osp-secret
        replicas: 3
      openstack-cell1:
        storageRequest: 5000M
        secret: osp-secret
        replicas: 3

    • 3 つの memcached サーバーが含まれる単一の memcached クラスター。 

        memcached:
    templates:
      memcached:
         replicas: 3

    • すべての RHOSO サービスで使用される RabbitMQ クラスター (rabbitmq) と、cell1 の Compute サービスで使用される RabbitMQ クラスター (rabbitmq-cell1)。 

        rabbitmq:
    templates:
      rabbitmq:
        persistence:
          storage: <rabbitmq_cluster_storage>
        replicas: 3
        override:
          service:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.85
            spec:
              type: LoadBalancer
      rabbitmq-cell1:
        persistence:
          storage: <rabbitmq_cluster_storage>
        replicas: 3
        override:
          service:
            metadata:
              annotations:
                metallb.universe.tf/address-pool: internalapi
                metallb.universe.tf/loadBalancerIPs: 172.17.0.86
            spec:
              type: LoadBalancer

    • <rabbitmq_cluster_storage> は、各 RabbitMQ クラスターにとって十分なストレージ容量 (例: 10Gi) に置き換えます。

      注記

      すべての RabbitMQ インスタンスは同じポートを使用するため、同じ仮想 IP (VIP) アドレスに複数の RabbitMQ インスタンスを設定することはできません。複数の RabbitMQ インスタンスを同じネットワークに公開する必要がある場合は、個別の IP アドレスを使用する必要があります。

      RabbitMQ は、データの安全性と可用性を向上させるために、デフォルトで Quorum キューを使用します。その代償として、レイテンシーがわずかに増加します。

      警告

      既存の RHOSO デプロイメントでは、Quorum キューを使用するように RabbitMQ クラスターを設定してはなりません。設定した場合、既存の RHOSO サービスが起動しなくなるか、正常に動作しなくなります。

      RabbitMQ Quorum キューは、Raft コンセンサスアルゴリズムに基づく耐久性のある複製キューです。

      注記

      耐久性を確保するためには、RabbitMQ Quorum キューをディスクに保存する必要があります。Quorum キューは、ディスク領域を多く占有する可能性があります。メッセージが消費された後または期限切れになった後の領域解放にかかる時間は、ワークロードと設定に応じて大幅に異なります。各 RabbitMQ クラスターに十分なストレージが割り当てられていることを確認してください。

      RabbitMQ のフェイルオーバー動作の改善

      RabbitMQ サービスは、OpenShift のデフォルトの可用性チェックを回避し、改善されたフェイルオーバー動作を提供するように設定できます。デフォルトの可用性チェックでは、サービスが停止したと判定するまでに最大 5 分間かかることがあります。この改善されたフェイルオーバー動作を実装すると、各 OpenStack サービスは RabbitMQ Pod が稼働しているかどうかを確認し、稼働していない場合は次の Pod に移行するようになります。

      注記

      RabbitMQ クラスターのこの改善されたフェイルオーバー動作を実装するには、RabbitMQ ですでに使用されているデフォルトの RHOSO MetalLB IPAddressPool 範囲から、3 つの空き IP アドレスを予約する必要があります。

      たとえば、rabbitmq-cell1 RabbitMQ クラスターのフェイルオーバー動作を改善する場合は、OpenStackControlPlane CR の rabbitmq.templates.rabbitmq-cell1 セクションの末尾に次の行を追加します。 

          podOverride:
      services:
        - metadata:
            annotations:
              metallb.universe.tf/address-pool: "internalapi"
              metallb.universe.tf/loadBalancerIPs: "172.17.0.87"
          spec:
            type: LoadBalancer
        - metadata:
            annotations:
              metallb.universe.tf/address-pool: "internalapi"
              metallb.universe.tf/loadBalancerIPs: "172.17.0.88"
          spec:
            type: LoadBalancer
        - metadata:
            annotations:
              metallb.universe.tf/address-pool: "internalapi"
              metallb.universe.tf/loadBalancerIPs: "172.17.0.89"
          spec:
            type: LoadBalancer

  7. コントロールプレーンを作成します。 

    $ oc create -f openstack_control_plane.yaml -n openstack

  8. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待機します。次のコマンドを実行して、ステータスを確認します。 

    $ oc get openstackcontrolplane -n openstack
NAME 						STATUS 	MESSAGE
openstack-control-plane 	Unknown 	Setup started

    ステータスが "Setup complete" であれば、OpenStackControlPlane リソースが作成されています。

    ヒント

    デプロイの進行状況を追跡するには、get コマンドの末尾に -w オプションを追加します。

    注記

    コントロールプレーンを作成すると、OpenStackClient Pod も作成されます。この Pod にリモートシェル (rsh) を介してアクセスして、OpenStack CLI コマンドを実行できます。 

    $ oc rsh -n openstack openstackclient

  9. オプション: openstack namespace 内の Pod を確認して、コントロールプレーンがデプロイされていることを確認します。 

    $ oc get pods -n openstack

    すべての Pod が完了または実行中の状態であれば、コントロールプレーンがデプロイされています。

検証

  1. OpenStackClient Pod へのリモートシェル接続を開きます。 

    $ oc rsh -n openstack openstackclient

  2. 内部サービスエンドポイントが各サービスに登録されていることを確認します。 

    $ openstack endpoint list -c 'Service Name' -c Interface -c URL --service glance
+--------------+-----------+---------------------------------------------------------------+
| Service Name | Interface | URL                                                           |
+--------------+-----------+---------------------------------------------------------------+
| glance       | internal  | https://glance-internal.openstack.svc                     |
| glance       | public    | https://glance-default-public-openstack.apps.ostest.test.metalkube.org |
+--------------+-----------+---------------------------------------------------------------+

  3. OpenStackClient Pod を終了します。 

    $ exit
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る