ネットワーク機能仮想化環境のデプロイ

手順

1. 事前にプロビジョニングされたノードを使用したデータプレーンノードセットの作成 または プロビジョニングされていないノードを使用したデータプレーンノードセットの作成 の手順を実行する場合は、OpenStackDataPlaneNodeSet マニフェストに edpm_ovs_dpdk_enable_tso: true 値のペアを含めます。以下に例を示します。

     nodeTemplate:
       ansible:
         ansibleUser: cloud-admin
         ansiblePort: 22
         ansibleVarsFrom:
           - prefix: subscription_manager_
             secretRef:
               name: subscription-manager
           - secretRef:
               name: redhat-registry
         ansibleVars:
           edpm_ovs_dpdk_enable_tso: true
           edpm_bootstrap_command: |
          ...

2. ノードセットの作成手順を完了します。

手順

1. cluster-admin 権限を持つユーザーとして RHOCP Web コンソールにログインします。
2. Operators → OperatorHub を選択します。
3. Filter by keyword に OpenStack と入力します。
4. Red Hat というソースラベルが付いた OpenStack Operator タイルをクリックします。
5. Operator の情報を確認してから、Install をクリックします。
6. Install Operator ページで、Installed Namespace リストから "Operator recommended Namespace: openstack-operators" を選択します。
7. Install Operator ページで、Update approval リストから "Manual" を選択します。保留中の Operator 更新を手動で承認する方法は、RHOCP Operator ガイドの 保留中の Operator 更新の手動承認 を参照してください。
8. Install をクリックして、Operator を openstack-operators namespace で使用できるようにします。Status が Succeeded の場合、OpenStack Operator はインストールされています。
9. Create OpenStack をクリックして、Create OpenStack ページを開きます。
10. Create OpenStack ページで、Create をクリックして、OpenStack Operator 初期化リソースのインスタンスを作成します。openstack インスタンスの Status が Conditions: Ready の場合、OpenStack Operator は使用できる状態です。

手順

1. デプロイする RHOSO 環境用の openstack プロジェクトを作成します。

   $ oc new-project openstack

2. OpenStack Operator による特権 Pod の作成を有効にするために、openstack namespace にラベルが付いていることを確認します。

   $ oc get namespace openstack -ojsonpath='{.metadata.labels}' | jq
   {
     "kubernetes.io/metadata.name": "openstack",
     "pod-security.kubernetes.io/enforce": "privileged",
     "security.openshift.io/scc.podSecurityLabelSync": "false"
   }

   Security Context Constraint (SCC) が "privileged" でない場合は、次のコマンドを使用して変更します。

   $ oc label ns openstack security.openshift.io/scc.podSecurityLabelSync=false --overwrite
   $ oc label ns openstack pod-security.kubernetes.io/enforce=privileged --overwrite

3. オプション: openstack namespace でコマンドを実行するときに namespace の指定を不要にするには、デフォルトの namespace を openstack に設定します。

   $ oc project openstack

手順

1. ワークステーションに Secret CR (例: openstack_service_secret.yaml) を作成します。

2. openstack_service_secret.yaml に次の初期設定を追加します。

   apiVersion: v1
   data:
     AdminPassword: <base64_password>
     AodhPassword: <base64_password>
     BarbicanPassword: <base64_password>
     BarbicanSimpleCryptoKEK: <base64_fernet_key>
     CeilometerPassword: <base64_password>
     CinderPassword: <base64_password>
     DbRootPassword: <base64_password>
     DesignatePassword: <base64_password>
     GlancePassword: <base64_password>
     HeatAuthEncryptionKey: <base64_password>
     HeatPassword: <base64_password>
     IronicInspectorPassword: <base64_password>
     IronicPassword: <base64_password>
     ManilaPassword: <base64_password>
     MetadataSecret: <base64_password>
     NeutronPassword: <base64_password>
     NovaPassword: <base64_password>
     OctaviaPassword: <base64_password>
     PlacementPassword: <base64_password>
     SwiftPassword: <base64_password>
   kind: Secret
   metadata:
     name: osp-secret
     namespace: openstack
   type: Opaque

   • <base64_password> を、base64 でエンコードされた 32 文字のキーに置き換えます。

     注記

     HeatAuthEncryptionKey パスワードは、Orchestration サービス (heat) 暗号化用の 32 文字のキーである必要があります。それ以外の全サービスでパスワードの長さを増やす場合は、HeatAuthEncryptionKey のパスワードの長さが 32 のままであることを確認してください。

     次のコマンドを使用して、base64 でエンコードされたパスワードを手動で生成できます。

     $ echo -n <password> | base64

     もしくは、Linux ワークステーションを使用しており、cat などの Bash コマンドを使用して Secret CR を生成している場合は、<base64_password> を次のコマンドに置き換えて、各サービスのランダムパスワードを自動生成できます。

     $(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 32 | base64)

   • <base64_fernet_key> は、base64 でエンコードされた fernet キーに置き換えます。次のコマンドを使用して、手動で生成できます。

     $(python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode('UTF-8'))" | base64)

3. クラスターに Secret CR を作成します。

   $ oc create -f openstack_service_secret.yaml -n openstack

4. Secret CR が作成されたことを確認します。

   $ oc describe secret osp-secret -n openstack

手順

1. ワークステーションに openstack_netconfig.yaml という名前のファイルを作成します。

2. openstack_netconfig.yaml に次の設定を追加して、NetConfig CR を作成します。

   apiVersion: network.openstack.org/v1beta1
   kind: NetConfig
   metadata:
     name: openstacknetconfig
     namespace: openstack

3. openstack_netconfig.yaml ファイルで、各データプレーンネットワークのトポロジーを定義します。デフォルトの Red Hat OpenStack Services on OpenShift (RHOSO) ネットワークを使用するには、各ネットワークの仕様を定義する必要があります。デフォルトの RHOSO ネットワークの詳細は、デフォルトの Red Hat OpenStack Services on OpenShift ネットワーク を参照してください。次の例では、データプレーン用の分離ネットワークを作成します。

   spec:
     networks:
     - name: CtlPlane
       dnsDomain: ctlplane.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 192.168.122.120
           start: 192.168.122.100
         - end: 192.168.122.200
           start: 192.168.122.150
         cidr: 192.168.122.0/24
         gateway: 192.168.122.1
     - name: InternalApi
       dnsDomain: internalapi.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.17.0.250
           start: 172.17.0.100
         excludeAddresses:
         - 172.17.0.10
         - 172.17.0.12
         cidr: 172.17.0.0/24
         vlan: 20
     - name: External
       dnsDomain: external.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 10.0.0.250
           start: 10.0.0.100
         cidr: 10.0.0.0/24
         gateway: 10.0.0.1
     - name: Storage
       dnsDomain: storage.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.18.0.250
           start: 172.18.0.100
         cidr: 172.18.0.0/24
         vlan: 21
     - name: Tenant
       dnsDomain: tenant.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.19.0.250
           start: 172.19.0.100
         cidr: 172.19.0.0/24
         vlan: 22

   • spec.networks.name: ネットワークの名前 (例: CtlPlane)。
   • spec.networks.subnets: IPv4 サブネット仕様。
   • spec.networks.subnets.name: サブネットの名前 (例: subnet1)。
   • spec.networks.subnets.allocationRanges: NetConfig allocationRange。allocationRange が、MetalLB IPAddressPool の範囲および IP アドレスプール範囲と重複しないようにしてください。
   • spec.networks.subnets.excludeAddresses: オプション: データプレーンノードで使用してはならない割り当て範囲の IP アドレスのリスト。
   • spec.networks.subnets.vlan: ネットワーク VLAN。デフォルトの RHOSO ネットワークの詳細は、デフォルトの Red Hat OpenStack Services on OpenShift ネットワーク を参照してください。
4. openstack_netconfig.yaml 定義ファイルを保存します。

5. データプレーンネットワークを作成します。

   $ oc create -f openstack_netconfig.yaml -n openstack

6. データプレーンネットワークが作成されたことを確認するために、openstacknetconfig リソースを表示します。

   $ oc get netconfig/openstacknetconfig -n openstack

   エラーが表示された場合は、基礎となる network-attach-definition とノードのネットワーク設定ポリシーを確認してください。

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

手順

1. デプロイする RHOSO 環境用の openstack プロジェクトを作成します。

   $ oc new-project openstack

2. OpenStack Operator による特権 Pod の作成を有効にするために、openstack namespace にラベルが付いていることを確認します。

   $ oc get namespace openstack -ojsonpath='{.metadata.labels}' | jq
   {
     "kubernetes.io/metadata.name": "openstack",
     "pod-security.kubernetes.io/enforce": "privileged",
     "security.openshift.io/scc.podSecurityLabelSync": "false"
   }

   Security Context Constraint (SCC) が "privileged" でない場合は、次のコマンドを使用して変更します。

   $ oc label ns openstack security.openshift.io/scc.podSecurityLabelSync=false --overwrite
   $ oc label ns openstack pod-security.kubernetes.io/enforce=privileged --overwrite

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

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

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

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

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

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
   spec:
     secret: osp-secret
     storageClass: your-RHOCP-storage-class

   注記

   ストレージクラスの詳細は、ストレージクラスの作成 を参照してください。

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

   • 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 # backend needs to be configured to activate the service
           cinderVolumes:
             volume1:
               networkAttachments:
               - storage
               replicas: 0 # backend needs to be configured to activate the service

     重要

     この Block Storage サービスの定義はサンプルです。場合によっては、実際の NFV 環境に合わせて変更する必要があります。詳細は、デプロイメントのプランニング の ストレージと共有ファイルシステムのプランニング を参照してください。

     注記

     コントロールプレーンの最初のデプロイでは、cinderBackup および cinderVolumes サービスがデプロイされますが、アクティブ化はされません (replicas: 0)。デプロイ後に、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
           schedulerServiceTemplate:
             customServiceConfig: |
               [filter_scheduler]
               enabled_filters = AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter, AggregateInstanceExtraSpecsFilter
               available_filters = nova.scheduler.filters.all_filters
           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
             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
           cellTemplates:
             cell1:
               noVNCProxyServiceTemplate:
                 enabled: true
                 networkAttachments:
                 - ctlplane
           secret: osp-secret

     注記

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

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

       dns:
         template:
           options: 

     1

     
           - key: server 

     2

     
             values: 

     3

     
             - 192.168.122.1
           - key: server
             values:
             - 192.168.122.2
           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

     1

     キーと値のペアを使用して、各 DNS サーバーに必要な dnsmasq インスタンスを定義します。この例では、要求を転送するように設定された DNS サーバーが 2 つあるため、2 つのキーと値のペアが定義されています。

     2

     デプロイする 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

     3

     dnsmasq パラメーターの値を指定します。値として、汎用 DNS サーバー (例: 1.1.1.1) または特定のドメインの DNS サーバー (例: /google.com/8.8.8.8) を指定できます。

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

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

   • 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 # backend needs to be configured to activate the 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

     注記

     コントロールプレーンの最初のデプロイでは、Image サービスがデプロイされますが、アクティブ化はされません (replicas: 0)。デプロイ後に、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

   • Memcached:

       memcached:
         templates:
           memcached:
              replicas: 3

   • 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
           customServiceConfig: |
             [DEFAULT]
             global_physnet_mtu = 9000
             [ml2]
             mechanism_drivers = ovn
             [ovn]
             vhost_sock_dir = <path>
             [ml2_type_vlan]
             network_vlan_ranges = <network_name1>:<VLAN-ID1>:<VLAN-ID2>,<network_name2>:<VLAN-ID1>:<VLAN-ID2>

     • SR-IOV を使用する場合は、sriovnicswitch メカニズムドライバーも追加する必要があります (例: mechanism_drivers = ovn,sriovnicswitch)。
     • & lt;path& gt; は、vhost ソケットへの絶対パス（例： /var/lib/vhost_sockets ）に置き換えます。
     • <network_name1> と <network_name2> は、ゲートウェイが存在する物理ネットワークの名前に置き換えます。(このネットワークは、neutron ネットワーク provider:*name フィールドで設定します。)
     • <VLAN-ID1> と `<VLAN-ID2>` を、使用している VLAN ID に置き換えます。

   • 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
           swiftRing:
             ringReplicas: 3
           swiftStorage:
             networkAttachments:
             - storage
             replicas: 3
             storageClass: local-storage
             storageRequest: 100Gi

   • 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: {}
           ovnController:
             networkAttachment: tenant
             nicMappings:
               <network_name>: <nic_name>

     • <network_name> は、ゲートウェイが存在する物理ネットワークの名前に置き換えます。(このネットワークは、neutron ネットワーク provider:*name フィールドで設定します。)
     • <nic_name> は、ゲートウェイネットワークに接続する NIC の名前に置き換えます。
     • オプション: 必要に応じて、nicMappings の下に追加の <network_name>:<nic_name> ペアを追加します。

   • 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

   • RabbitMQ:

       rabbitmq:
         templates:
           rabbitmq:
             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:
             replicas: 3
             override:
               service:
                 metadata:
                   annotations:
                     metallb.universe.tf/address-pool: internalapi
                     metallb.universe.tf/loadBalancerIPs: 172.17.0.86
                 spec:
                   type: LoadBalancer

   • Telemetry サービス (ceilometer、prometheus):

       telemetry:
         enabled: true
         template:
           metricStorage:
             enabled: true
             monitoringStack:
               alertingEnabled: true
               scrapeInterval: 30s
               storage:
                 strategy: persistent
                 retention: 24h
                 persistent:
                   pvcStorageRequest: 20G
           autoscaling: 

     1

     
             enabled: false
             aodh:
               passwordSelectors:
               databaseAccount: aodh
               databaseInstance: openstack
               memcachedInstance: memcached
               secret: osp-secret
             heatInstance: heat
           ceilometer:
             enabled: true
             secret: osp-secret
           logging:
             enabled: false

     1

     自動スケーリングが無効になっている場合でも、autoscaling フィールドが存在している必要があります。

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

   $ oc create -f openstack_control_plane.yaml -n openstack

   注記

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

   $ oc rsh -n openstack openstackclient

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) を介してアクセスして、RHOSO 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  | http://glance-internal.openstack.svc:9292                     |
   | glance       | public    | http://glance-public-openstack.apps.ostest.test.metalkube.org |
   +--------------+-----------+---------------------------------------------------------------+

3. OpenStackClient Pod を終了します。

   $ exit

手順

1. ワークステーションで OpenStackControlPlane CR ファイルを開きます。

2. コントロールプレーンから削除するサービスを見つけて無効にします。

     cinder:
       enabled: false
       apiOverride:
         route: {}
         ...

3. コントロールプレーンを更新します。

   $ oc apply -f openstack_control_plane.yaml -n openstack

4. RHOCP が無効なサービスに関連するリソースを削除するまで待機します。次のコマンドを実行して、ステータスを確認します。

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

   ステータスが "Setup complete" であれば、無効にしたサービスで OpenStackControlPlane リソースが更新されています。

   ヒント

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

5. オプション: openstack namespace 内の Pod を確認して、無効にしたサービスの Pod がリストに表示されなくなったことを確認します。

   $ oc get pods -n openstack

6. サービスが削除されていることを確認します。

   $ oc get cinder -n openstack

   サービスが正常に削除されていれば、このコマンドで次のメッセージが返されます。

   No resources found in openstack namespace.

7. サービスの API エンドポイントが Identity サービス (keystone) から削除されていることを確認します。

   $ oc rsh -n openstack openstackclient
   $ openstack endpoint list --service volumev3

   サービスの API エンドポイントが正常に削除されていれば、このコマンドで次のメッセージが返されます。

   No service with a type, name or ID of 'volumev3' exists.

手順

1. プロビジョニングされていないノードの場合は、Ansible の SSH 鍵ペアを作成します。

   $ ssh-keygen -f <key_file_name> -N "" -t rsa -b 4096

   • <key_file_name> は、鍵ペアに使用する名前に置き換えます。

2. Ansible 用の Secret CR を作成し、クラスターに適用します。

   $ oc create secret generic dataplane-ansible-ssh-private-key-secret \
   --save-config \
   --dry-run=client \
   --from-file=ssh-privatekey=<key_file_name> \
   --from-file=ssh-publickey=<key_file_name>.pub \
   [--from-file=authorized_keys=<key_file_name>.pub] -n openstack \
   -o yaml | oc apply -f -

   • <key_file_name> を SSH 鍵ペアファイルの名前と場所に置き換えます。
   • オプション: データプレーンを作成するときにプロビジョニングする必要があるベアメタルノードに対してのみ、--from-file=authorized_keys オプションを含めます。

3. コンピュートノードを作成する場合は、移行用のシークレットを作成します。

   1. インスタンス移行用の SSH 鍵ペアを作成します。

      $ ssh-keygen -f ./nova-migration-ssh-key -t ecdsa-sha2-nistp521 -N ''

   2. 移行用の Secret CR を作成し、クラスターに適用します。

      $ oc create secret generic nova-migration-ssh-key \
      --save-config \
      --from-file=ssh-privatekey=nova-migration-ssh-key \
      --from-file=ssh-publickey=nova-migration-ssh-key.pub \
      -n openstack \
      -o yaml | oc apply -f -

4. Red Hat カスタマーポータルに登録されていないノードの場合は、subscription-manager 認証情報用の Secret CR を作成してノードを登録します。

   $ oc create secret generic subscription-manager \
   --from-literal rhc_auth='{"login": {"username": "<subscription_manager_username>", "password": "<subscription_manager_password>"}}'

   • <subscription_manager_username> を、subscription-manager に設定したユーザー名に置き換えます。
   • <subscription_manager_password> を、subscription-manager に設定したパスワードに置き換えます。

5. Red Hat レジストリーの認証情報を含む Secret CR を作成します。

   $ oc create secret generic redhat-registry --from-literal edpm_container_registry_logins='{"registry.redhat.io": {"<username>": "<password>"}}'

   • <username> と <password> を Red Hat レジストリーのユーザー名とパスワードの認証情報に置き換えます。

     レジストリーサービスアカウントの作成方法は、ナレッジベース記事の Creating Registry Service Accounts を参照してください。

6. コンピュートノードを作成する場合は、libvirt のシークレットを作成します。

   1. ワークステーションに secret_libvirt.yaml という名前のファイルを作成し、libvirt シークレットを定義します。

      apiVersion: v1
      kind: Secret
      metadata:
       name: libvirt-secret
       namespace: openstack
      type: Opaque
      data:
       LibvirtPassword: <base64_password>

      • <base64_password> を、最大長 63 文字の base64 でエンコードされた文字列に置き換えます。次のコマンドを使用して、base64 でエンコードされたパスワードを生成できます。

        $ echo -n <password> | base64

        ヒント

        ユーザー名とパスワードを base64 でエンコードする必要がない場合は、data フィールドの代わりに stringData フィールドを使用してユーザー名とパスワードを設定します。

   2. Secret CR を作成します。

      $ oc apply -f secret_libvirt.yaml -n openstack

7. Secret CR が作成されたことを確認します。

   $ oc describe secret dataplane-ansible-ssh-private-key-secret
   $ oc describe secret nova-migration-ssh-key
   $ oc describe secret subscription-manager
   $ oc describe secret redhat-registry
   $ oc describe secret libvirt-secret

手順

1. CPU ピニングと PCI パススルーの設定を定義する ConfigMap CR を作成し、ワークステーション上の YAML ファイル (例: pinning-passthrough.yaml) に保存します。

   環境に応じて値 (太字部分) を変更します。

   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cpu-pinning-nova
   data:
     25-cpu-pinning-nova.conf: |
       [DEFAULT]
       reserved_host_memory_mb = 4096
       [compute]
       cpu_shared_set = 0-3,24-27
       cpu_dedicated_set = 8-23,32-47
       [neutron]
       physnets = <network_name1>, <network_name2>
       [neutron_physnet_<network_name1>]
       numa_nodes = <ID list>
       [neutron_physnet_<network_name2>]
       numa_nodes = <ID list>
       [neutron_tunnel]
       numa_nodes = <ID list>
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: sriov-nova
   data:
     26-sriov-nova.conf: |
       [libvirt]
       cpu_power_management=false
       [pci]
       passthrough_whitelist = {"address": "0000:05:00.2", "physical_network":"sriov-1", "trusted":"true"}
       passthrough_whitelist = {"address": "0000:05:00.3", "physical_network":"sriov-2", "trusted":"true"}
   ---

   • cpu_shared_set: vCPU のインベントリーを指定するために使用する物理ホスト CPU 番号のコンマ区切りリストまたは範囲を入力します。これにより、ピニングされていないインスタンスをスケジュールできるホスト CPU を決定します。また、共有エミュレータースレッドポリシーで設定されたインスタンスのインスタンスエミュレータースレッドをオフロードするホスト CPU を決定します。
   • cpu_dedicated_set: ピニングされたインスタンス CPU のプロセスをスケジュールできる物理ホスト CPU 番号のコンマ区切りのリストまたは範囲を入力します。たとえば、4-12,^8,15 は、8 を除く 4 - 12 および 15 のコアを予約します。
   • <network_name_n_>: <network_name1> と <network_name2> は、ゲートウェイが配置されている物理ネットワークの名前に置き換えます。(このネットワークは、neutron ネットワーク provider:*name フィールドで設定します。)

   • numa_nodes = <ID list>: <ID list> を、この物理ネットワークに関連付けられている NUMA ノードの ID のコンマ区切りリストに置き換えます。たとえば、0,1 です。以下に例を示します。

     [neutron]
     physnets = foo,bar
     
     [neutron_physnet_foo]
     numa_nodes = 0
     
     [neutron_physnet_bar]
     numa_nodes = 2, 3

     この設定では、provider:physical_network=foo で 1 つ以上の L2 タイプのネットワークを使用するインスタンスは NUMA ノード 0 のホストコアでスケジュールされる必要があり、provider:physical_network=bar で 1 つ以上のネットワークを使用するインスタンスは NUMA ノード 2 と 3 の両方のホストコアでスケジュールされる必要があります。後者の場合、hw:numa_nodes extra 仕様を使用して、ゲストを 2 つ以上のホスト NUMA ノードに分割する必要があります。

   • passthrough_whitelist: "address" と "physical_network" に、有効な NIC アドレスと名前を指定します。

2. ConfigMap CR ファイルを使用して、ConfigMap オブジェクトを作成します。

   例

   $ oc create -f sriov-pinning-passthru.yaml -n openstack

3. SR-IOV カスタムサービスを定義する OpenStackDataPlaneService CR を作成し、ワークステーション上の YAML ファイル (例: nova-custom-sriov.yaml) に保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-sriov

4. ConfigMap CR をカスタムサービスに追加し、このサービスを実行するノードセットの接続先セルの Secret CR を指定します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-sriov
   spec:
     label: dataplane-deployment-nova-custom-sriov
     dataSources:
       - configMapRef:
           name: cpu-pinning-nova
       - configMapRef:
           name: sriov-nova
       - secretRef:
           name: nova-cell1-compute-config
       - secretRef:
           name: nova-migration-ssh-key
     tlsCerts:
       default:
         contents:
           - dnsnames
           - ips
         networks:
           - ctlplane
         issuer: osp-rootca-issuer-internal
     caCerts: combined-ca-bundle

5. Ansible Playbook を参照するか、playbookContents フィールドに Ansible プレイを含めることで、カスタムサービスを作成するための Ansible コマンドを指定します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-sriov
   spec:
     label: dataplane-deployment-nova-custom-sriov
     edpmServiceType: nova
     dataSources:
       - configMapRef:
           name: cpu-pinning-nova
       - configMapRef:
           name: sriov-nova
       - secretRef:
           name: nova-cell1-compute-config
       - secretRef:
           name: nova-migration-ssh-key
     playbook: osp.edpm.nova
     tlsCerts:
       default:
         contents:
           - dnsnames
           - ips
         networks:
           - ctlplane
         issuer: osp-rootca-issuer-internal
     caCerts: combined-ca-bundle

   • playbook: サービスで使用できるデフォルトの Playbook を識別します。

     この場合は、Compute サービス (nova) です。デフォルト Playbook のリストは、https://openstack-k8s-operators.github.io/edpm-ansible/playbooks.html で確認してください。

6. custom-nova-sriov サービスを作成します。

   $ oc apply -f nova-custom-sriov.yaml -n openstack

7. カスタムサービスが作成されたことを確認します。

   $ oc get openstackdataplaneservice nova-custom-sriov -o yaml -n openstack

手順

1. パラメーターの設定を定義する ConfigMap CR を作成し、ワークステーション上の YAML ファイル (例: dpdk-custom.yaml) に保存します。

   環境に応じて値 (太字部分) を変更します。

   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: dpdk-custom-nova
     namespace: openstack
   data:
     25-dpdk-custom-nova.conf: |
       [DEFAULT]
       reserved_host_memory_mb = 4096
       [compute]
       cpu_shared_set = 0-3,24-27
       cpu_dedicated_set = 8-23,32-47
       [neutron]
       physnets = <network_name1>, <network_name2>
       [neutron_physnet_<network_name1>]
       numa_nodes = <ID list>
       [neutron_physnet_<network_name2>]
       numa_nodes = <ID list>
       [neutron_tunnel]
       numa_nodes = <ID list>
       [libvirt]
       live_migration_permit_post_copy=false
   ---

   • cpu_shared_set: vCPU のインベントリーを指定するために使用する物理ホスト CPU 番号のコンマ区切りリストまたは範囲を入力します。これにより、ピニングされていないインスタンスをスケジュールできるホスト CPU を決定します。また、共有エミュレータースレッドポリシーで設定されたインスタンスのインスタンスエミュレータースレッドをオフロードするホスト CPU を決定します。
   • cpu_dedicated_set: ピニングされたインスタンス CPU のプロセスをスケジュールできる物理ホスト CPU 番号のコンマ区切りのリストまたは範囲を入力します。たとえば、4-12,^8,15 は、8 を除く 4 - 12 および 15 のコアを予約します。
   • <network_name_n_>: <network_name1> と <network_name2> を、NUMA アフィニティーを設定する必要があるゲートウェイが配置されている物理ネットワークの名前に置き換えます。(このネットワークは、neutron ネットワーク provider:*name フィールドで設定します。)

   • <ID list>: <ID list> を、この物理ネットワークに関連付けられている NUMA ノードの ID のコンマ区切りリストに置き換えます。たとえば、0,1 です。以下に例を示します。

     [neutron]
     physnets = foo,bar
     
     [neutron_physnet_foo]
     numa_nodes = 0
     
     [neutron_physnet_bar]
     numa_nodes = 2, 3

     この設定では、provider:physical_network=foo` で 1 つ以上の L2 タイプのネットワークを使用するインスタンスは NUMA ノード 0 のホストコアでスケジュールされる必要があり、provider:physical_network=bar` で 1 つ以上のネットワークを使用するインスタンスは NUMA ノード 2 と 3 の両方のホストコアでスケジュールされる必要があります。後者の場合、hw:numa_nodes extra` 仕様を使用して、ゲストを 2 つ以上のホスト NUMA ノードに分割する必要があります。

   • live_migration_permit_post_copy=false: DPDK を使用する Geneve ネットワークに接続されたインスタンスのブロックライブマイグレーションを正常に実行するために必要です。

2. ConfigMap CR ファイルを使用して、ConfigMap オブジェクトを作成します。

   例

   $ oc create -f dpdk-custom.yaml -n openstack

3. OVS-DPDK カスタムサービスを定義する OpenStackDataPlaneService CR を作成し、ワークステーション上の YAML ファイル (例: nova-custom-ovsdpdk.yaml) に保存します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-ovsdpdk
     namespace: openstack

4. ConfigMap CR をカスタムサービスに追加し、このサービスを実行するノードセットの接続先セルの Secret CR を指定します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-ovsdpdk
     namespace: openstack
   spec:
     label: dataplane-deployment-nova-custom-ovsdpdk
     edpmServiceType: nova
     dataSources:
       - configMapRef:
           name: dpdk-custom-nova
       - secretRef:
           name: nova-cell1-compute-config
       - secretRef:
           name: nova-migration-ssh-key
     tlsCerts:
       default:
         contents:
           - dnsnames
           - ips
         networks:
           - ctlplane
         issuer: osp-rootca-issuer-internal
     caCerts: combined-ca-bundle

5. Ansible Playbook を参照するか、playbookContents フィールドに Ansible プレイを含めることで、カスタムサービスを作成するための Ansible コマンドを指定します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: nova-custom-ovsdpdk
     namespace: openstack
   spec:
     label: dataplane-deployment-nova-custom-ovsdpdk
     edpmServiceType: nova
     dataSources:
       - configMapRef:
           name: dpdk-custom-nova
       - secretRef:
           name: nova-cell1-compute-config
       - secretRef:
           name: nova-migration-ssh-key
     playbook: osp.edpm.nova
     tlsCerts:
       default:
         contents:
           - dnsnames
           - ips
         networks:
           - ctlplane
         issuer: osp-rootca-issuer-internal
     caCerts: combined-ca-bundle

   • playbook: サービスで使用できるデフォルトの Playbook を識別します。

     この場合は、Compute サービス (nova) です。デフォルト Playbook のリストは、https://openstack-k8s-operators.github.io/edpm-ansible/playbooks.html で確認してください。

6. nova-custom-ovsdpdk サービスを作成します。

   $ oc apply -f nova-custom-ovsdpdk.yaml -n openstack

7. カスタムサービスが作成されたことを確認します。

   $ oc get openstackdataplaneservice nova-custom-ovsdpdk -o yaml -n openstack

手順

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

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: openstack-data-plane 

   1

   
     namespace: openstack
   spec:
     env:
       - name: ANSIBLE_FORCE_COLOR
         value: "True"

   1

   OpenStackDataPlaneNodeSet CR 名は、一意であり、小文字の英数字と - (ハイフン) または . (ピリオド) のみが含まれ、先頭と末尾は英数字で、最大長 53 文字である必要があります。この例の名前を、セット内のノードを表す名前に更新してください。

2. このセット内のノードが事前にプロビジョニングされていることを指定します。

     preProvisioned: true

3. Ansible がデータプレーンノードに接続できるようにするために作成した SSH 鍵シークレットを追加します。

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>

   • <secret-key> は、データプレーンシークレットの作成 でこのノードセット用に作成した SSH 鍵の Secret CR の名前 (例: dataplane-ansible-ssh-private-key-secret) に置き換えます。
4. ログを保存するために、Red Hat OpenShift Container Platform (RHOCP) クラスターの openstack namespace に永続ボリューム要求 (PVC) を作成します。volumeMode を Filesystem に、accessModes を ReadWriteOnce に設定します。NFS ボリュームプラグインを使用する PersistentVolume (PV) からのログのストレージを要求しないでください。NFS は FIFO と互換性がないため、ansible-runner はログを保存するために書き込む FIFO ファイルを作成します。PVC の詳細は、RHOCP ストレージ ガイドの 永続ストレージについて、および デプロイメントのプランニング の Red Hat OpenShift Container Platform クラスターの要件 を参照してください。

5. データプレーンノードの永続的なロギングを有効にします。

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>
       extraMounts:
         - extraVolType: Logs
           volumes:
           - name: ansible-logs
             persistentVolumeClaim:
               claimName: <pvc_name>
           mounts:
           - name: ansible-logs
             mountPath: "/runner/artifacts"

   • <pvc_name> を、RHOCP クラスター上の PVC ストレージの名前に置き換えます。
6. このグループ内のノードセットの共通設定を nodeTemplate セクションに追加します。この OpenStackDataPlaneNodeSet 内の各ノードがこの設定を継承します。共通のノード属性を設定するために使用できるプロパティーの詳細は、OpenStackDataPlaneNodeSet CR の spec プロパティー を参照してください。

7. Red Hat カスタマーポータルに登録されていないノードのオペレーティングシステムを登録し、ノードのリポジトリーを有効にします。次の手順は、ノードを CDN に登録する方法を示しています。Red Hat Satellite 6.13 にノードを登録する方法の詳細は、ホストの管理 を参照してください。

   1. subscription-manager の認証情報を含む Secret CR を作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: subscription-manager
      data:
        username: <base64_encoded_username>
        password: <base64_encoded_password>

   2. Red Hat レジストリーの認証情報を含む Secret CR を作成します。

      $ oc create secret generic redhat-registry --from-literal edpm_container_registry_logins='{"registry.redhat.io": {"<username>": "<password>"}}'

      • <username> と <password> を Red Hat レジストリーのユーザー名とパスワードの認証情報に置き換えます。

   レジストリーサービスアカウントの作成方法は、Red Hat ナレッジベースアーティクルの Creating Registry Service Accounts を参照してください。

   1. ユーザー名とパスワードのソースとして使用する Secret CR を指定します。

        nodeTemplate:
          ansible:
            ...
            ansibleVarsFrom:
              - prefix: subscription_manager_
                secretRef:
                  name: subscription-manager
              - secretRef:
                  name: redhat-registry
            ansibleVars:
             rhc_release: 9.4
             rhc_repositories:
               - {name: "*", state: disabled}
               - {name: "rhel-9-for-x86_64-baseos-eus-rpms", state: enabled}
               - {name: "rhel-9-for-x86_64-appstream-eus-rpms", state: enabled}
               - {name: "rhel-9-for-x86_64-highavailability-eus-rpms", state: enabled}
               - {name: "fast-datapath-for-rhel-9-x86_64-rpms", state: enabled}
               - {name: "rhoso-18.0-for-rhel-9-x86_64-rpms", state: enabled}
               - {name: "rhceph-7-tools-for-rhel-9-x86_64-rpms", state: enabled}

8. このノードセット内の各ノードを定義します。

     nodes:
       edpm-compute-0: 

   1

   
         hostName: edpm-compute-0
         networks: 

   2

   
           - name: ctlplane
             subnetName: subnet1
             defaultRoute: true
             fixedIP: 192.168.122.100 

   3

   
           - name: internalapi
             subnetName: subnet1
             fixedIP: 172.17.0.100
           - name: storage
             subnetName: subnet1
             fixedIP: 172.18.0.100
           - name: tenant
             subnetName: subnet1
             fixedIP: 172.19.0.100
         ansible:
           ansibleHost: 192.168.122.100
           ansibleUser: cloud-admin
           ansibleVars: 

   4

   
             fqdn_internal_api: edpm-compute-0.example.com
             edpm_network_config_nmstate: true 

   5

   
       edpm-compute-1:
         hostName: edpm-compute-1
         networks:
           - name: ctlplane
             subnetName: subnet1
             defaultRoute: true
             fixedIP: 192.168.122.101
           - name: internalapi
             subnetName: subnet1
             fixedIP: 172.17.0.101
           - name: storage
             subnetName: subnet1
             fixedIP: 172.18.0.101
           - name: tenant
             subnetName: subnet1
             fixedIP: 172.19.0.101
         ansible:
           ansibleHost: 192.168.122.101
           ansibleUser: cloud-admin
           ansibleVars:
             fqdn_internal_api: edpm-compute-1.example.com

   1

   ノード定義の参照 (例: edpm-compute-0)。ノードセット内の各ノードにノード定義が必要です。

   2

   ノードの IPAM と DNS レコードを定義します。

   3

   ネットワークの予測可能な IP アドレスを指定します。この場合、NetConfig CR でネットワークに定義された割り当て範囲内のアドレスでなければなりません。

   4

   ノードをカスタマイズするノード固有の Ansible 変数。

   注記
   • nodes セクションに定義するノードには、nodeTemplate セクションで設定されているのと同じ Ansible 変数を設定できます。Ansible 変数が特定のノードと nodeTemplate セクション内の両方に設定されている場合は、ノード固有の値が nodeTemplate セクションの値をオーバーライドします。
   • ノードのすべての nodeTemplate Ansible 変数を複製してデフォルトをオーバーライドし、ノード固有の値を設定する必要はありません。設定する必要があるのは、オーバーライドするノードの Ansible 変数だけです。
   • 多くの ansibleVars の名前には edpm が含まれています。これは "External Data Plane Management (外部データプレーン管理)" の略です。

   os-net-config プロバイダーを nmstate に設定します。デフォルト値は true です。nmstate プロバイダーの特定の制限により ifcfg プロバイダーを使用する必要がある場合のみ、これを false に変更します。nmstate プロバイダーの利点と制限の詳細は、「デプロイメントのプランニング」の https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/planning_your_deployment/plan-networks_planning#plan-os-net-config_plan-network を参照してください。

   詳細は以下を参照してください。

   • OpenStackDataPlaneNodeSet CR properties
   • ネットワークインターフェイスの設定オプション
   • NFV のカスタムネットワークインターフェイスの例

9. services セクションに、データプレーンノードで実行されるサービスの一覧を追加します。nova を nova -custom-sriov、または nova-custom-ovsdpdk のいずれか、またはその両方に置き換えてください。

   ...
     services:
     - bootstrap
     - download-cache
     - reboot-os
     - configure-ovs-dpdk
     - configure-network
     - validate-network
     - install-os
     - configure-os
     - ssh-known-hosts
     - run-os
     - install-certs
     - ovn
     - neutron-ovn
     - neutron-ovn-igmp
     - neutron-metadata
     - libvirt
     - nova-custom-sriov
     - nova-custom-ovsdpdk
     - telemetry
   ...

10. openstack_preprovisioned_node_set.yaml 定義ファイルを保存します。

11. データプレーンリソースを作成します。

    $ oc create -f openstack_preprovisioned_node_set.yaml -n openstack

12. データプレーンリソースが作成されたことを確認します。

    $ oc get openstackdataplanenodeset -n openstack
    NAME           		STATUS MESSAGE
    openstack-data-plane 	False  Deployment not started

    返されるステータスの意味は、データプレーンの状態 を参照してください。

13. ノードセットの Secret リソースが作成されたことを確認します。

    $ oc get secret | grep openstack-data-plane
    dataplanenodeset-openstack-data-plane Opaque 1 3m50s

14. サービスが作成されたことを確認します。

    $ oc get openstackdataplaneservice -n openstack
    NAME                AGE
    configure-network   6d7h
    configure-os        6d6h
    install-os          6d6h
    run-os              6d6h
    validate-network    6d6h
    ovn                 6d6h
    libvirt             6d6h
    nova                6d6h
    telemetry           6d6h

手順

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

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: openstack-data-plane 

   1

   
     namespace: openstack
   spec:
     tlsEnabled: true
     env:
       - name: ANSIBLE_FORCE_COLOR
         value: "True"

   1

   OpenStackDataPlaneNodeSet CR 名は、一意であり、小文字の英数字と - (ハイフン) または . (ピリオド) のみが含まれ、先頭と末尾は英数字で、最大長 53 文字である必要があります。この例の名前を、セット内のノードを表す名前に更新してください。

2. baremetalSetTemplate フィールドを定義して、ベアメタルノードの設定を記述します。

     preProvisioned: false
     baremetalSetTemplate:
       deploymentSSHSecret: dataplane-ansible-ssh-private-key-secret
       bmhNamespace: <bmh_namespace>
       cloudUserName: <ansible_ssh_user>
       bmhLabelSelector:
         app: <bmh_label>
       ctlplaneInterface: <interface>

   • <bmh_namespace> は、ノードは対応する BareMetalHost CR で定義されている namespace に置き換えます。
   • <ansible_ssh_user> は、Ansible SSH ユーザーのユーザー名に置き換えます。
   • <bmh_label> は、ノードの対応する BareMetalHost CR で定義されているメタデータラベル (例: openstack) に置き換えます。app、workload、nodeName などのメタデータラベルは、ノードにラベル付けするためのキーと値のペアです。対応する BareMetalHost CR 内のラベルと一致する 1 つ以上のラベルに基づいてデータプレーンノードを選択するには、bmhLabelSelector フィールドを設定します。
   • <interface> は、ノードが接続するコントロールプレーンインターフェイス (例: enp6s0) に置き換えます。

3. デフォルトでは、BMO によって openshift-machine-api namespace 内の BareMetalHost CR が管理されます。すべての namespace を監視するように Provisioning CR を更新する必要があります。

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'

4. Ansible がデータプレーンノードに接続できるようにするために作成した SSH 鍵シークレットを追加します。

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>

   • <secret-key> は、データプレーンシークレットの作成 で作成した SSH 鍵の Secret CR の名前 (例: dataplane-ansible-ssh-private-key-secret) に置き換えます。
5. ログを保存するために、RHOCP クラスターの openstack namespace に永続ボリューム要求 (PVC) を作成します。volumeMode を Filesystem に、accessModes を ReadWriteOnce に設定します。NFS ボリュームプラグインを使用する PersistentVolume (PV) からのログのストレージを要求しないでください。NFS は FIFO と互換性がないため、ansible-runner はログを保存するために書き込む FIFO ファイルを作成します。PVC の詳細は、RHOCP ストレージ ガイドの 永続ストレージについて、および デプロイメントのプランニング の Red Hat OpenShift Container Platform クラスターの要件 を参照してください。

6. データプレーンノードの永続的なロギングを有効にします。

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>
       extraMounts:
         - extraVolType: Logs
           volumes:
           - name: ansible-logs
             persistentVolumeClaim:
               claimName: <pvc_name>
           mounts:
           - name: ansible-logs
             mountPath: "/runner/artifacts"

   • <pvc_name> を、RHOCP クラスター上の PVC ストレージの名前に置き換えます。

7. このグループ内のノードセットの共通設定を nodeTemplate セクションに追加します。この OpenStackDataPlaneNodeSet 内の各ノードがこの設定を継承します。

   詳細は以下を参照してください。

   • OpenStackDataPlaneNodeSet CR properties
   • ネットワークインターフェイスの設定オプション
   • NFV のカスタムネットワークインターフェイスの例

8. このノードセット内の各ノードを定義します。

     nodes:
       edpm-compute-0: 

   1

   
         hostName: edpm-compute-0
         networks: 

   2

   
           - name: ctlplane
             subnetName: subnet1
             defaultRoute: true
             fixedIP: 192.168.122.100 

   3

   
           - name: internalapi
             subnetName: subnet1
           - name: storage
             subnetName: subnet1
           - name: tenant
             subnetName: subnet1
         ansible:
           ansibleHost: 192.168.122.100
           ansibleUser: cloud-admin
           ansibleVars: 

   4

   
             fqdn_internal_api: edpm-compute-0.example.com
             edpm_network_config_nmstate: true 

   5

   
       edpm-compute-1:
         hostName: edpm-compute-1
         networks:
           - name: ctlplane
             subnetName: subnet1
             defaultRoute: true
             fixedIP: 192.168.122.101
           - name: internalapi
             subnetName: subnet1
           - name: storage
             subnetName: subnet1
           - name: tenant
             subnetName: subnet1
         ansible:
           ansibleHost: 192.168.122.101
           ansibleUser: cloud-admin
           ansibleVars:
             fqdn_internal_api: edpm-compute-1.example.com

   1

   ノード定義の参照 (例: edpm-compute-0)。ノードセット内の各ノードにノード定義が必要です。

   2

   ノードの IPAM と DNS レコードを定義します。

   3

   ネットワークの予測可能な IP アドレスを指定します。この場合、NetConfig CR でネットワークに定義された割り当て範囲内のアドレスでなければなりません。

   4

   ノードをカスタマイズするノード固有の Ansible 変数。

   注記
   • nodes セクションに定義するノードには、nodeTemplate セクションで設定されているのと同じ Ansible 変数を設定できます。Ansible 変数が特定のノードと nodeTemplate セクション内の両方に設定されている場合は、ノード固有の値が nodeTemplate セクションの値をオーバーライドします。
   • ノードのすべての nodeTemplate Ansible 変数を複製してデフォルトをオーバーライドし、ノード固有の値を設定する必要はありません。設定する必要があるのは、オーバーライドするノードの Ansible 変数だけです。
   • 多くの ansibleVars の名前には edpm が含まれています。これは "External Data Plane Management (外部データプレーン管理)" の略です。

   os-net-config プロバイダーを nmstate に設定します。デフォルト値は true です。nmstate プロバイダーの特定の制限により ifcfg プロバイダーを使用する必要がある場合のみ、これを false に変更します。nmstate プロバイダーの利点と制限の詳細は、「デプロイメントのプランニング」の https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/planning_your_deployment/plan-networks_planning#plan-os-net-config_plan-network を参照してください。

   ノード属性を設定するために使用できるプロパティーの詳細は、OpenStackDataPlaneNodeSet CR のプロパティー を参照してください。

9. services セクションに、データプレーンノードで実行されるサービスの一覧を追加します。nova を nova -custom-sriov、または nova-custom-ovsdpdk のいずれか、またはその両方に置き換えてください。

   ...
     services:
     - bootstrap
     - download-cache
     - reboot-os
     - configure-ovs-dpdk
     - configure-network
     - validate-network
     - install-os
     - configure-os
     - ssh-known-hosts
     - run-os
     - install-certs
     - ovn
     - neutron-ovn
     - neutron-ovn-igmp
     - neutron-metadata
     - libvirt
     - nova-custom-sriov
     - nova-custom-ovsdpdk
     - telemetry
   ...

10. openstack_unprovisioned_node_set.yaml 定義ファイルを保存します。

11. データプレーンリソースを作成します。

    $ oc create -f openstack_unprovisioned_node_set.yaml -n openstack

12. データプレーンリソースが作成されたことを確認します。

    $ oc get openstackdataplanenodeset -n openstack
    NAME           		STATUS MESSAGE
    openstack-data-plane 	False  Deployment not started

    返されるステータスの意味は、「データプレーンの状態」を参照してください。

13. ノードセットの Secret リソースが作成されたことを確認します。

    $ oc get secret -n openstack | grep openstack-data-plane
    dataplanenodeset-openstack-data-plane Opaque 1 3m50s

14. サービスが作成されたことを確認します。

    $ oc get openstackdataplaneservice -n openstack
    NAME                AGE
    configure-network   6d7h
    configure-os        6d6h
    install-os          6d6h
    run-os              6d6h
    validate-network    6d6h
    ovn                 6d6h
    libvirt             6d6h
    nova                6d6h
    telemetry           6d6h

手順

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

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: openstack-data-plane 

   1

   1

   OpenStackDataPlaneDeployment CR 名は一意である必要があり、小文字の英数字、- (ハイフン)、または . (ピリオド) が含まれ、先頭と末尾は英数字である必要があります。この例の名前を、デプロイメント内のノードセットを反映する名前に更新します。

2. デプロイするすべての OpenStackDataPlaneNodeSet CR を追加します。

   spec:
     nodeSets:
       - openstack-data-plane
       - <nodeSet_name>
       - ...
       - <nodeSet_name>
     services:
     ...

   • & lt;nodeSet_name > をデータプレーンのデプロイメントに追加する OpenStackDataPlaneNodeSet CR の名前( openstack_preprovisioned_node_set.yaml または openstack_unprovisioned_node_set.yaml など)に置き換えます。
3. openstack_data_plane_deploy.yaml デプロイメントファイルを保存します。

4. データプレーンをデプロイします。

   $ oc create -f openstack_data_plane_deploy.yaml -n openstack

   デプロイメントの実行中に Ansible ログを表示できます。

   $ oc get pod -l app=openstackansibleee -w
   $ oc logs -l app=openstackansibleee -f --max-log-requests 10

5. データプレーンがデプロイされていることを確認します。

   $ oc get openstackdataplanedeployment -n openstack

   出力例

   NAME                   STATUS   MESSAGE
   openstack-data-plane   True     Setup Complete

6. NodeSet Ready メッセージが表示されるまで、oc get コマンドを繰り返します。

   $ oc get openstackdataplanenodeset -n openstack

   出力例

   NAME                   STATUS   MESSAGE
   openstack-data-plane   True     NodeSet Ready

   返されるステータスの意味は、データプレーンの状態 を参照してください。

   データプレーンがデプロイされていないことをステータスが示している場合は、デプロイメントのトラブルシューティングを行います。詳細は、データプレーンの作成とデプロイのトラブルシューティング を参照してください。

7. Compute ノードを、それが接続されている Compute セルにマップします。

   $ oc rsh nova-cell0-conductor-0 nova-manage cell_v2 discover_hosts --verbose

   追加のセルを作成しなかった場合は、このコマンドによって Compute ノードが cell1 にマップされます。

手順

1. OpenStackClient Pod のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. openstack コマンドを実行します。たとえば、以下のコマンドを使用して default ネットワークを作成できます。

   $ openstack network create default

3. OpenStackClient Pod を終了します。

   $ exit

手順

1. osp-secret シークレットの AdminPassword パラメーターから管理者パスワードを取得します。

   $ oc get secret osp-secret -o jsonpath='{.data.AdminPassword}' | base64 -d

2. Dashboard サービスのエンドポイント URL を取得します。

   $ oc get horizons horizon -o jsonpath='{.status.endpoint}'

3. ブラウザーを開きます。
4. ダッシュボードのエンドポイント URL を入力します。
5. admin のユーザー名と管理者のパスワードを入力してダッシュボードにログインします。

手順

1. ワークステーションから OpenStackClient Pod のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. 特定のポートでポートセキュリティーを無効にするには、以下のコマンドを実行します。

   $ openstack port set --disable-port-security <port-id>

3. ネットワークで作成されるすべての新規ポートで、ポートセキュリティーの有効化を阻止するには、以下のコマンドを実行します。

   $ openstack network set --disable-port-security <network-id>

4. openstackclient Pod を終了します。

   $ exit

手順

1. ワークステーションから OpenStackClient Pod のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. 種別 vlan のネットワークを作成します。

   例

   $ openstack network create trusted_vf_network \
   --provider-network-type vlan --provider-segment 111 \
   --provider-physical-network sriov2 --external --disable-port-security

3. サブネットを作成します。

   例

   $ openstack subnet create --network trusted_vf_network \
     --ip-version 4 --subnet-range 192.168.111.0/24 --no-dhcp \
    subnet-trusted_vf_network

4. ポートを作成します。

   例

   vnic-type オプションを direct に、binding-profile オプションを true に、それぞれ設定します。

   $ openstack port create --network trusted_vf_network \
   --vnic-type direct --binding-profile trusted=true \
   sriov111_port_trusted

5. インスタンスを作成し、それを前のステップで作成した信頼済みポートにバインドします。

   例

   $ openstack server create --image rhel --flavor dpdk \
   --network trusted_vf_network --port sriov111_port_trusted \
   --config-drive True --wait rhel-dpdk-sriov_trusted

6. openstackclient Pod を終了します。

   $ exit

検証

1. インスタンスを作成したコンピュートノード上で、以下のコマンドを入力します。

   $ ip link

   出力例

   7: p5p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
       link/ether b4:96:91:1c:40:fa brd ff:ff:ff:ff:ff:ff
       vf 6 MAC fa:16:3e:b8:91:c2, vlan 111, spoof checking off, link-state auto, trust on, query_rss off
       vf 7 MAC fa:16:3e:84:cf:c8, vlan 111, spoof checking off, link-state auto, trust off, query_rss off

2. VF の信頼ステータスが trust on であることを確認します。上記の出力例には、2 つのポートが含まれる環境の詳細が示されています。vf 6 に trust on のテキストが含まれている点に注意してください。
3. Networking サービス (neutron) ネットワークで port_security_enabled: false を設定した場合、あるいは openstack port create コマンドの実行時に引数 --disable-port-security を含める場合には、スプーフィングの確認を無効にできます。