Red Hat Openstack Platform データプレーンの導入


Red Hat OpenStack Services on OpenShift 18.0

Red Hat OpenStack Platform 17.1 オーバークラウドに Red Hat OpenStack Services on OpenShift 18.0 データプレーンを導入

OpenStack Documentation Team

概要

既存の Red Hat OpenStack Platform 17.1 オーバークラウドを、Red Hat OpenStack Services on OpenShift 18.0 データプレーンに移行できます。

開発者プレビュー

これは 開発者プレビュー リリースです。開発者プレビューリリースには、ソフトウェアの次のバージョンリリースに組み込まれる予定のプレビュー機能が含まれています。開発者プレビューバージョンは、すべての機能が実装およびテストされる前に公開されるため、一部の機能が欠落しているか、不完全であるか、期待どおりに動作しない可能性があります。Red Hat は、開発者プレビューリリースを使用し、そのフィードバックをご提供いただけるようお客様にお願いしています。

開発者プレビュービルドには次の制約と制限があります。

  • 実稼働環境での使用は許可されていません。
  • インストールと使用は、Red Hat 製品サポートの対象外です。
  • 開発者プレビューバージョンへのアップグレード、開発者プレビューバージョンからのアップグレード、または開発者プレビューバージョン間のアップグレードはサポートされません。

開発者プレビューのサポート範囲について、詳細は 開発者プレビューのサポート範囲 - Red Hat カスタマーポータル を参照してください。

第1章 OpenStack の導入

1.1. 新規デプロイメントのプランニング

Director でデプロイされた OpenStack のインストール時と同様に、Pod 化された OpenStack へのアップグレード/移行には、ノードのロール、ネットワークトポロジー、ストレージなど、環境のさまざまな側面を計画する必要があります。

このドキュメントでは計画の一部について説明していますが、プロセス全体を確実に理解するために、プロセスを開始する前に導入ガイド全体を一読することが推奨されます。

1.1.1. サービス設定

Director と Operator のデプロイメントには、サービス設定に関連する根本的な違いがあります。

Director のデプロイメントでは、サービス設定の多くは Director 固有の設定オプションによって抽象化されます。1 つの Director オプションにより複数のサービスが変更され、ドライバー (Cinder など) をサポートするために Director コードベースへのパッチ適用が必要になる可能性があります。

Operator デプロイメントではこのアプローチが変更され、インストーラー固有の知識が減少し、可能な限り OpenShift および OpenStack サービス固有の知識を活用します。

そのため、OpenStack サービスには OpenShift デプロイメント用の実用的なデフォルトが設定され、人間のオペレーターは、バックエンド設定などをはじめとする必要な設定を指定したり、デフォルトをオーバーライドしたりするための設定スニペットを指定します。

そうすることで、サービス固有の設定ファイル (cinder.conf など) と人間のオペレーターがマニフェストで指定する内容との距離が短縮されます。

これらの設定スニペットは、マニフェストで使用可能なさまざまな customServiceConfig セクションのオペレーターに渡され、その後、次のレベルで使用可能なサービスに階層化されます。具体的には、Cinder の最上位レベル (spec: cinder: template:) で設定すると、その設定はすべての cinder サービスに適用されます。たとえば、すべての cinder サービスで有効にするには、次のようにします。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      customServiceConfig: |
        [DEFAULT]
        debug = True
< . . . >

cinder サービスの 1 つ (スケジューラーなど) のみに対して設定する場合は、代わりに cinderScheduler セクションを使用します。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderScheduler:
        customServiceConfig: |
          [DEFAULT]
          debug = True
< . . . >

OpenShift では、cinder ストレージアレイへの認証情報などの機密情報を CR に保存することは推奨されません。そのため、ほとんどの OpenStack オペレーターは、OpenShift の Secrets をサービスの機密設定パラメーターとして使用し、それを customServiceConfigSecrets セクション (customServiceConfig に類似) で参照して使用するメカニズムがあります。

customServiceConfigSecrets で渡される Secret 参照の内容は、customServiceConfig と同じフォーマットになります。つまり、1 つ以上のセクションと設定オプションを含むスニペットです。

サービス設定に機密情報が含まれている場合、すべての設定を Secret に保存するか、機密部分のみを保存するかは個人の好みの問題になります。ただし、設定を SecretcustomServiceConfig に分割する場合は、両方の場所にセクションヘッダー (例: [DEFAULT]) が必要です。

各サービスには特定の設定がある可能性があるため、各サービスの導入プロセスに注意を払う必要があります。

1.1.2. ノードのロール

Director デプロイメントでは、4 種類の標準ノードロール (ControllerComputeCeph StorageSwift Storage) がありましたが、Pod 化された OpenStack では、OpenShift 内または外部のどこで実行されているかにより区別されます。

Director OpenStack を導入すると、Compute ノードが直接の外部ノードになるため、追加の計画はあまり必要ありません。

導入される多くのデプロイメントでは、Controller ノードについての計画が必要です。なぜなら、コントローラーサービスを実行できる OpenShift ノードが多数存在するため、どのノードをどのように使用するか決定し、それらのノードでサービスを実行するための準備を完了する必要があるからです。

ほとんどのデプロイメントでは、master ノードで OpenStack サービスを実行すると、OpenShift クラスターに重大な悪影響を及ぼす可能性があります。そのため、OpenStack サービスは master ノード以外に配置することが推奨されます。

OpenStack Operator は、デフォルトで任意のワーカーノードに OpenStack サービスをデプロイしますが、それがすべてのデプロイメントに最適であるとは限りませんし、そうすると機能しないサービスが存在する可能性もあります。

デプロイメントを計画する際は、OpenStack デプロイメント上のサービスはすべて異なり、要件お大きく異なる点に留意してください。

Cinder コンポーネントを見ると、サービスごとに要件が異なることが明確です。cinder-scheduler は、メモリー、ディスク、ネットワーク、CPU の使用率が極めて小さい軽量サービスです。cinder-api サービスは、リソースのリスト要求によりネットワーク使用率が高くなります。cinder-volume サービスは、操作の多くがデータパス上で行われるため (オフラインボリューム移行、イメージからのボリューム作成など)、ディスクとネットワークの使用率が高くなります。cinder-backup サービスは、メモリー、ネットワーク、CPU (データ圧縮用) に対する要件が高いサービスです。

Glance コンポーネントと Swift コンポーネント、および RabbitMQ サービスと Galera サービスはデータパス内にあります。

これらの要件を考慮すると、他のワークロードに影響を与えることがないように、これらのサービスが OpenShift ワーカーノード全体に関与しないようにすることが望ましいでしょう。軽量サービスが関与することを気にしない場合でも、重いサービスについては特定のインフラストラクチャーノードセットに固定することを検討してください。

ファイバーチャネル (FC) Cinder バックエンドを使用している場合、HBA を備えた OpenShift ホスト上で実行するためには、cinder-volume、cinder-backup、さらには glance (Cinder をバックエンドとして使用している場合) サービスも必要となるため、ハードウェア関連の制限も考慮する必要があります。

OpenStack Operator を使用すると、どの OpenShift ノードがどの OpenStack サービスを実行できるかをノードラベルを使用して定義できるため、OpenStack サービスを実行する場所に高い柔軟性が生まれます。ラベルを使用して OpenStack サービスの配置を定義する方法の詳細は、ノードセレクターについて を参照してください。

1.1.3. ストレージ

OpenStack デプロイメントのストレージは、サービス自体に必要なストレージと、サービスが管理する OpenStack ユーザー用に使用するストレージの 2 種類に区別できます。

前述したとおり、これらの要件に基づき OpenShift ノードが選択される可能性があり、サービスをデプロイする前に OpenShift ノードでいくつかの準備を行う必要性が生じる可能性もあります。

1.1.3.1. Cinder 要件

Cinder サービスには、サービスが使用するローカルストレージと OpenStack ユーザー要件があります。

ローカルストレージは、たとえば、イメージからボリュームを作成する操作のグランスイメージをダウンロードする際に使用されます。これは、同時操作があり、cinder ボリュームキャッシュを使用しない場合に大量になる可能性があります。

Operator を使用してデプロイされた OpenStack では、変換ディレクトリーの場所を (追加のボリューム機能を使用して) NFS 共有に設定できます。これは、以前は手動で行う必要がありました。

それが導入であり、現行デプロイメントと同じものを使用していることから Cinder バックエンドに関して考慮する必要がないと思われる場合でも、それほど単純ではない可能性があるため、評価は必要です。

まず、Cinder バックエンドが使用しているトランスポートプロトコル (RBD、iSCSI、FC、NFS、NVMe-oF など) を確認する必要があります。

使用しているすべてのトランスポートプロトコルを把握した後、Cinder サービスを配置する際に (ノードロールのセクションで説明したとおり) それらのプロトコルを考慮していること、適切なストレージトランスポート関連バイナリーが OpenShift ノード上で実行されていることを確認できます。

各ストレージトランスポートプロトコルの詳細は、ブロックストレージサービスの導入 を参照してください。

1.2. ノードセレクターについて

OpenStack サービスを配置できるノードは、さまざまな理由から制限する必要があります。

  • ハードウェア要件: システムメモリー、ディスク容量、コア、HBA
  • 他の OpenShift ワークロードに対する OpenStack サービスの影響を制限するため。
  • OpenStack サービスの併設を回避するため。

これを実現するために OpenStack Operator が提供するメカニズムが、ラベルの使用です。

OpenShift ノードにラベルを付けるか既存ラベルを使用し、OpenStack マニフェストの nodeSelector フィールドでそのラベルを使用します。

OpenStack マニフェストの nodeSelector フィールドは、標準の OpenShift nodeSelector フィールドに準じます。追加情報は、OpenShift ドキュメント を参照してください。

このフィールドは、OpenStack マニフェストのすべてのレベルに存在します。

  • デプロイメント: OpenStackControlPlane オブジェクト。
  • コンポーネント: OpenStackControlPlanecinder 要素など。
  • サービス: OpenStackControlPlanecinder 要素内の cinderVolume 要素など。

これにより、最小限の繰り返しで OpenStack サービスの配置を細かく制御できます。

nodeSelector の値は、上書きされない限り次のレベルに伝播されます。つまり、デプロイメントレベルの nodeSelector 値がすべての OpenStack サービスに影響します。

たとえば、ラベル type: openstack を 3 つの OpenShift ノードに追加します。

$ oc label nodes worker0 type=openstack
$ oc label nodes worker1 type=openstack
$ oc label nodes worker2 type=openstack

OpenStackControlPlane では、そのラベルを使用して上記の 3 つのノードにすべてのサービスを配置できます。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  secret: osp-secret
  storageClass: local-storage
  nodeSelector:
    type: openstack
< . . . >

特定のサービスに対してセレクターを使用できます。たとえば FC を使用しており、ノードのサブセットに HBA しかない場合は、cinder ボリュームとバックアップサービスを特定のノードに配置する必要があることがあります。次の例では、ラベル fc_card: true があることを前提としています。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  secret: osp-secret
  storageClass: local-storage
  cinder:
    template:
      cinderVolumes:
          pure_fc:
            nodeSelector:
              fc_card: true
< . . . >
          lvm-iscsi:
            nodeSelector:
              fc_card: true
< . . . >
      cinderBackup:
          nodeSelector:
            fc_card: true
< . . . >

現在、Cinder Operator は cinderVolumesnodeSelector を定義しないため、それぞれのバックエンドで指定する必要があります。

Node Feature Discovery Operator で追加されたラベルを使用して、OpenStack サービスを配置できます。

1.2.1. MachineConfig

一部のサービスでは、それらが実行されるホスト上でサービスまたはカーネルモジュールを実行する必要があります (iscsid デーモン、multipathd デーモン、または nvme-fabrics カーネルモジュールなど)。

その場合、MachineConfig マニフェストを使用します。また、nodeSelector を使用して OpenStack サービスを配置するノードを制限している場合は、MachineConfig が適用される場所も制限する必要があります。

MachineConfig を適用できる場所を定義するには、MachineConfig をノードにリンクする MachineConfigPool を使用する必要があります。

たとえば、MachineConfigtype: openstack ラベルでマークした 3 つの OpenShift ノードに制限するには、次のように MachineConfigPool を作成します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: openstack
spec:
  machineConfigSelector:
    matchLabels:
      machineconfiguration.openshift.io/role: openstack
  nodeSelector:
    matchLabels:
      type: openstack

それを MachineConfig で使用します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: openstack
< . . . >

MachineConfig および MachineConfigPools の詳細は OpenShift のドキュメントを参照 してください。

警告: OpenShift ノードに MachineConfig を適用すると、ノードが再起動されます。

1.3. バックエンドサービスのデプロイ

以下は、基本的なバックエンドサービスがデプロイされ、すべての OpenStack サービスが無効になっている OpenStackControlPlane CR の作成手順です。これは、Pod 化されたコントロールプレーンの基盤となります。

後続の手順では、元のデータベースをインポートし、その後 Pod 化された OpenStack コントロールプレーンサービスを追加します。

1.3.1. 前提条件

  • 導入するクラウドが稼働しており、OpenStack Wallaby リリース上にある。
  • test という名前の仮想マシンインスタンスがソースクラウド上で実行されており、その Floating IP が FIP 環境変数に設定されている。このテスト仮想マシンは、ヘルパースクリプトを使用して作成できます。
  • openstack-operator はデプロイされているが、OpenStackControlPlaneデプロイされていない

    開発者/CI 環境の場合、OpenStack Operator は、install_yamls リポジトリー内で make openstack を実行することでデプロイできます。

    多くの場合、実稼働環境ではデプロイメント方法が異なります。

  • 要求できる空き PV がある (MariaDB および RabbitMQ 用)。

    install_yamls ドリブンの開発者/CI 環境の場合は、make crc_storage を実行していることを確認してください。

1.3.2. 変数

  • Pod 化されたデプロイメントに必要な管理者パスワードを設定します。これは、元のデプロイメントの管理者パスワードなどの場合があります。

    ADMIN_PASSWORD=SomePassword

    既存の OpenStack デプロイメントパスワードを使用するには、以下を実行します。

    ADMIN_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' AdminPassword:' | awk -F ': ' '{ print $2; }')
  • 元のデプロイメントと一致するようにサービスパスワード変数を設定します。Pod 化された環境ではデータベースパスワードが異なる場合がありますが、サービスアカウントパスワードの同期は必須の手順です。

    たとえば、TripleO Standalone を備えた開発者環境では、次のようにパスワードを展開できます。

    AODH_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' AodhPassword:' | awk -F ': ' '{ print $2; }')
    CEILOMETER_METERING_SECRET=$(cat ~/tripleo-standalone-passwords.yaml | grep ' CeilometerMeteringSecret:' | awk -F ': ' '{ print $2; }')
    CEILOMETER_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' CeilometerPassword:' | awk -F ': ' '{ print $2; }')
    CINDER_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' CinderPassword:' | awk -F ': ' '{ print $2; }')
    GLANCE_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' GlancePassword:' | awk -F ': ' '{ print $2; }')
    HEAT_AUTH_ENCRYPTION_KEY=$(cat ~/tripleo-standalone-passwords.yaml | grep ' HeatAuthEncryptionKey:' | awk -F ': ' '{ print $2; }')
    HEAT_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' HeatPassword:' | awk -F ': ' '{ print $2; }')
    IRONIC_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' IronicPassword:' | awk -F ': ' '{ print $2; }')
    MANILA_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' ManilaPassword:' | awk -F ': ' '{ print $2; }')
    NEUTRON_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' NeutronPassword:' | awk -F ': ' '{ print $2; }')
    NOVA_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' NovaPassword:' | awk -F ': ' '{ print $2; }')
    OCTAVIA_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' OctaviaPassword:' | awk -F ': ' '{ print $2; }')
    PLACEMENT_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' PlacementPassword:' | awk -F ': ' '{ print $2; }')

1.3.3. 事前チェック

1.3.4. 手順 - バックエンドサービスデプロイメント

  • Pod 化されたコントロールプレーンのデプロイ先となる OpenShift namespace を使用していることを確認します。

    oc project openstack
  • OSP シークレットを作成します。

    その作成手順はさまざまですが、開発者/CI 環境では install_yamls を使用します。

    # in install_yamls
    make input
  • $ADMIN_PASSWORDosp-secret に設定済みのパスワードと異なる場合は、それに応じて osp-secretAdminPassword キーを修正します。

    oc set data secret/osp-secret "AdminPassword=$ADMIN_PASSWORD"
  • osp-secret のサービスアカウントパスワードを、元のデプロイメントのサービスアカウントパスワードと一致するように設定します。

    oc set data secret/osp-secret "AodhPassword=$AODH_PASSWORD"
    oc set data secret/osp-secret "CeilometerMeteringSecret=$CEILOMETER_METERING_SECRET"
    oc set data secret/osp-secret "CeilometerPassword=$CEILOMETER_PASSWORD"
    oc set data secret/osp-secret "CinderPassword=$CINDER_PASSWORD"
    oc set data secret/osp-secret "GlancePassword=$GLANCE_PASSWORD"
    oc set data secret/osp-secret "HeatAuthEncryptionKey=$HEAT_AUTH_ENCRYPTION_KEY"
    oc set data secret/osp-secret "HeatPassword=$HEAT_PASSWORD"
    oc set data secret/osp-secret "IronicPassword=$IRONIC_PASSWORD"
    oc set data secret/osp-secret "ManilaPassword=$MANILA_PASSWORD"
    oc set data secret/osp-secret "NeutronPassword=$NEUTRON_PASSWORD"
    oc set data secret/osp-secret "NovaPassword=$NOVA_PASSWORD"
    oc set data secret/osp-secret "OctaviaPassword=$OCTAVIA_PASSWORD"
    oc set data secret/osp-secret "PlacementPassword=$PLACEMENT_PASSWORD"
  • OpenStackControlPlane をデプロイします。DNS、MariaDB、Memcached、および RabbitMQ サービスのみ有効にしてください。その他のサービスは、すべて無効にする必要があります。

    oc apply -f - <<EOF
    apiVersion: core.openstack.org/v1beta1
    kind: OpenStackControlPlane
    metadata:
      name: openstack
    spec:
      secret: osp-secret
      storageClass: local-storage
    
      cinder:
        enabled: false
        template:
          cinderAPI: {}
          cinderScheduler: {}
          cinderBackup: {}
          cinderVolumes: {}
    
      dns:
        template:
          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
          options:
          - key: server
            values:
            - 192.168.122.1
          replicas: 1
    
      glance:
        enabled: false
        template:
          glanceAPIs: {}
    
      horizon:
        enabled: false
        template: {}
    
      ironic:
        enabled: false
        template:
          ironicConductors: []
    
      keystone:
        enabled: false
        template: {}
    
      manila:
        enabled: false
        template:
          manilaAPI: {}
          manilaScheduler: {}
          manilaShares: {}
    
      mariadb:
        enabled: false
        templates: {}
    
      galera:
        enabled: true
        templates:
          openstack:
            secret: osp-secret
            replicas: 1
            storageRequest: 500M
          openstack-cell1:
            secret: osp-secret
            replicas: 1
            storageRequest: 500M
    
      memcached:
        enabled: true
        templates:
          memcached:
            replicas: 1
    
      neutron:
        enabled: false
        template: {}
    
      nova:
        enabled: false
        template: {}
    
      ovn:
        enabled: false
        template:
          ovnDBCluster:
            ovndbcluster-nb:
              dbType: NB
              storageRequest: 10G
              networkAttachment: internalapi
            ovndbcluster-sb:
              dbType: SB
              storageRequest: 10G
              networkAttachment: internalapi
          ovnNorthd:
            networkAttachment: internalapi
            replicas: 1
          ovnController:
            networkAttachment: tenant
    
      placement:
        enabled: false
        template: {}
    
      rabbitmq:
        templates:
          rabbitmq:
            override:
              service:
                metadata:
                  annotations:
                    metallb.universe.tf/address-pool: internalapi
                    metallb.universe.tf/loadBalancerIPs: 172.17.0.85
                spec:
                  type: LoadBalancer
          rabbitmq-cell1:
            override:
              service:
                metadata:
                  annotations:
                    metallb.universe.tf/address-pool: internalapi
                    metallb.universe.tf/loadBalancerIPs: 172.17.0.86
                spec:
                  type: LoadBalancer
    
      ceilometer:
        enabled: false
        template: {}
    
      autoscaling:
        enabled: false
        template: {}
    EOF

1.3.5. 事後チェック

  • MariaDB が稼働していることを確認します。

    oc get pod openstack-galera-0 -o jsonpath='{.status.phase}{"\n"}'
    oc get pod openstack-cell1-galera-0 -o jsonpath='{.status.phase}{"\n"}'

1.4. Ceph バックエンドを設定する

元のデプロイメントで、いずれかのサービス (Glance、Cinder、Nova、Manila など) に Ceph Storage バックエンドを使用している場合、導入したデプロイメントでも必ず同じバックエンドを使用し、それに応じて CR を設定する必要があります。

1.4.1. 前提条件

  • OpenStackControlPlane CR がすでに存在している。

1.4.2. 変数

以下の手順で使用するシェル変数を定義します。値はサンプルです。環境に適した値を使用してください。

CEPH_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100"
CEPH_KEY=$($CEPH_SSH "cat /etc/ceph/ceph.client.openstack.keyring | base64 -w 0")
CEPH_CONF=$($CEPH_SSH "cat /etc/ceph/ceph.conf | base64 -w 0")

1.4.3. Manila に合わせて "openstack" ユーザーの機能を変更する

TripleO 環境では、Manila の CephFS ドライバーは独自のキーペアを使用するように設定されています。便宜上、すべての OpenStack サービスで使用できるように、openstack ユーザーを変更します。

次に示す 2 つの理由から、サービス全体で同じユーザーを使用します。

  • Manila サービスとの対話に必要なユーザー機能は大幅にシンプルになったため、RHOSP 18 での安全性もさらに向上しました。
  • 共通の ceph シークレット (キーリングと ceph 設定ファイル) を作成し、そのシークレットを必要とするすべてのサービスに伝播する方が簡単です。
$CEPH_SSH cephadm shell
ceph auth caps client.openstack \
  mgr 'allow *' \
  mon 'allow r, profile rbd' \
  osd 'profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=images, allow rw pool manila_data'

1.4.4. Ceph バックエンド設定

Ceph 設定を含む ceph-conf-files シークレットを作成します。

oc apply -f - <<EOF
apiVersion: v1
data:
  ceph.client.openstack.keyring: $CEPH_KEY
  ceph.conf: $CEPH_CONF
kind: Secret
metadata:
  name: ceph-conf-files
  namespace: openstack
type: Opaque
EOF

ファイルの内容は次のようになります。

---
apiVersion: v1
kind: Secret
metadata:
  name: ceph-conf-files
  namespace: openstack
stringData:
  ceph.client.openstack.keyring: |
    [client.openstack]
        key = <secret key>
        caps mgr = "allow *"
        caps mon = "profile rbd"
        caps osd = "profile rbd pool=images"
  ceph.conf: |
    [global]
    fsid = 7a1719e8-9c59-49e2-ae2b-d7eb08c695d4
    mon_host = 10.1.1.2,10.1.1.3,10.1.1.4

OpenStackControlPlane CR の extraMount を設定します。

oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  extraMounts:
    - name: v1
      region: r1
      extraVol:
        - propagation:
          - CinderVolume
          - CinderBackup
          - GlanceAPI
          - ManilaShare
          extraVolType: Ceph
          volumes:
          - name: ceph
            projected:
              sources:
              - secret:
                  name: ceph-conf-files
          mounts:
          - name: ceph
            mountPath: "/etc/ceph"
            readOnly: true
'

1.4.5. Ceph FSID を取得する

一部の OpenStack サービスで Ceph バックエンドを使用するように設定するには、FSID 値が必要になる場合があります。次のように、設定から値を取得します。

CEPH_FSID=$(oc get secret ceph-conf-files -o json | jq -r '.data."ceph.conf"' | base64 -d | grep fsid | sed -e 's/fsid = //')

1.5. OpenStack サービスを停止する

導入を開始する前に、OpenStack サービスを停止する必要があります。

これは、DB が新しいデプロイメントにコピーされた後のリソース変更によって、データプレーンを導入するために移行されたデータに不整合が発生することを回避するための重要な手順です。

一部のサービスは短い非同期操作のみを実行するため、簡単に停止できます。しかし、その他のサービスは同期操作や長時間の操作を実行することから、操作を中断ではなく完了する必要があるため、正常に停止することが少し複雑になります。

すべてのサービスを正常に停止することは簡単ではなく、このガイドの範疇にはあたらないため、以下で説明する手順では強制メソッドを使用し、サービス内のいくつかの項目を確認するための推奨方法を説明します。

ただし、データベース、RabbitMQ、HAProxy ロードバランサーなどのインフラストラクチャー管理サービス、および Nova compute サービスやコンテナー化されたモジュラー libvirt デーモンなどは停止しないよう注意してください。

1.5.1. 変数

次の手順で使用するシェル変数を定義します。ここで使用する値はサンプルで、シングルノードのスタンドアロンディレクターデプロイメントを指します。環境に適した値を使用してください。

CONTROLLER1_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100"
CONTROLLER2_SSH=""
CONTROLLER3_SSH=""

この例では、ansible の代わりに ssh コマンドで ssh 変数を使用して、実行場所に依存しない命令を作成します。ただし、適切なホストを使用している場合は、ansible コマンドを使用して同じ結果を得ることができます。たとえば、サービスを停止するには以下を実行します。

. stackrc ansible -i $(which tripleo-ansible-inventory) Controller -m shell -a "sudo systemctl stop tripleo_horizon.service" -b

1.5.2. 事前チェック

OpenStack サービスはいつでも停止できますが、環境が望ましくない状態になる可能性があります。その場合でも、他のサービスを必要とする長時間実行される操作がないことを確認する必要があります。

進行中のインスタンスのライブマイグレーション、ボリュームのマイグレーション (オンラインまたはオフライン)、ボリュームの作成、バックアップの復元、アタッチ、デタッチなどがじっこうされていないことを確認してください。

openstack server list --all-projects -c ID -c Status |grep -E '\| .+ing \|'
openstack volume list --all-projects -c ID -c Status |grep -E '\| .+ing \|'| grep -vi error
openstack volume backup list --all-projects -c ID -c Status |grep -E '\| .+ing \|' | grep -vi error
openstack share list --all-projects -c ID -c Status |grep -E '\| .+ing \|'| grep -vi error
openstack image list -c ID -c Status |grep -E '\| .+ing \|'

サービストポロジー固有の設定も、ライブで収集するために必要なサービスを停止する前に収集します。これは、導入後の値を比較するために後で必要になります。

1.5.3. コントロールプレーンサービスウを停止する

OpenStack サービスはいつでも停止できますが、環境が望ましくない状態になる可能性があります。進行中の操作がないことを確認する必要があります。

1 - すべてのコントローラーノードに接続します。2 - コントロールプレーンサービスを停止します。3 - コントロールプレーンサービスが停止していることを確認します。

OSP 17.1 の cinder-backup サービスは、pacemaker の下で Active-Passive または Active-Active として実行されている可能性があるため、実行状況を確認してから停止する必要があります。

これらの手順は、前に定義した環境変数と関数に依存する Simple スクリプトを使用して自動化できます。

# Update the services list to be stopped
ServicesToStop=("tripleo_horizon.service"
                "tripleo_keystone.service"
                "tripleo_cinder_api.service"
                "tripleo_cinder_api_cron.service"
                "tripleo_cinder_scheduler.service"
                "tripleo_cinder_backup.service"
                "tripleo_glance_api.service"
                "tripleo_manila_api.service"
                "tripleo_manila_api_cron.service"
                "tripleo_manila_scheduler.service"
                "tripleo_neutron_api.service"
                "tripleo_nova_api.service"
                "tripleo_placement_api.service"
                "tripleo_nova_api_cron.service"
                "tripleo_nova_api.service"
                "tripleo_nova_conductor.service"
                "tripleo_nova_metadata.service"
                "tripleo_nova_scheduler.service"
                "tripleo_nova_vnc_proxy.service"
                "tripleo_aodh_api.service"
                "tripleo_aodh_api_cron.service"
                "tripleo_aodh_evaluator.service"
                "tripleo_aodh_listener.service"
                "tripleo_aodh_notifier.service"
                "tripleo_ceilometer_agent_central.service"
                "tripleo_ceilometer_agent_compute.service"
                "tripleo_ceilometer_agent_ipmi.service"
                "tripleo_ceilometer_agent_notification.service"
                "tripleo_ovn_cluster_northd.service")

PacemakerResourcesToStop=("openstack-cinder-volume"
                          "openstack-cinder-backup"
                          "openstack-manila-share")

echo "Stopping systemd OpenStack services"
for service in ${ServicesToStop[*]}; do
    for i in {1..3}; do
        SSH_CMD=CONTROLLER${i}_SSH
        if [ ! -z "${!SSH_CMD}" ]; then
            echo "Stopping the $service in controller $i"
            if ${!SSH_CMD} sudo systemctl is-active $service; then
                ${!SSH_CMD} sudo systemctl stop $service
            fi
        fi
    done
done

echo "Checking systemd OpenStack services"
for service in ${ServicesToStop[*]}; do
    for i in {1..3}; do
        SSH_CMD=CONTROLLER${i}_SSH
        if [ ! -z "${!SSH_CMD}" ]; then
            echo "Checking status of $service in controller $i"
            if ! ${!SSH_CMD} systemctl show $service | grep ActiveState=inactive >/dev/null; then
                echo "ERROR: Service $service still running on controller $i"
            fi
        fi
    done
done

echo "Stopping pacemaker OpenStack services"
for i in {1..3}; do
    SSH_CMD=CONTROLLER${i}_SSH
    if [ ! -z "${!SSH_CMD}" ]; then
        echo "Using controller $i to run pacemaker commands"
        for resource in ${PacemakerResourcesToStop[*]}; do
            if ${!SSH_CMD} sudo pcs resource config $resource; then
                ${!SSH_CMD} sudo pcs resource disable $resource
            fi
        done
        break
    fi
done

1.6. MariaDB インスタンスにデータベースを移行する

このドキュメントでは、元の OpenStack デプロイメントから OpenShift クラスター内の MariaDB インスタンスにデータベースを移動する方法について説明します。

注記 このサンプルシナリオでは、単純なシングルセルのセットアップについて説明します。実稼働環境での使用に推奨されるマルチスタックトポロジーでは、セル DB レイアウトが異なり、異なる命名スキームを使用する必要があります (ここでは説明しません)。

1.6.1. 前提条件

  • 前の導入手順が正常に実行されたことを確認する。

    • この時点で、OpenStackControlPlane リソースが作成されている。
    • Pod 化された MariaDB と RabbitMQ が稼働している。それ以外の Pod 化されたコントロールプレーンサービスは稼働していない。
    • 必要なサービス固有のトポロジーがある。
    • OpenStack サービスが停止されている。詳細は、OpenStack サービスを停止する を参照してください。
    • 以下の間でネットワークルーティングが可能である。

      • 導入ホストと元の MariaDB。
      • 導入ホストと Pod 化された MariaDB。
      • 今後、このルーティング要件が変更される可能性もある点に注意してください。たとえば、元の MariaDB から Pod 化された MariaDB へのルーティングが必要になる場合などです。
  • Podman パッケージがインストールされている。

1.6.2. 変数

以下の手順で使用するシェル変数を定義します。値はサンプルです。環境に適した値を使用してください。

PODIFIED_MARIADB_IP=$(oc get svc --selector "mariadb/name=openstack" -ojsonpath='{.items[0].spec.clusterIP}')
PODIFIED_CELL1_MARIADB_IP=$(oc get svc --selector "mariadb/name=openstack-cell1" -ojsonpath='{.items[0].spec.clusterIP}')
PODIFIED_DB_ROOT_PASSWORD=$(oc get -o json secret/osp-secret | jq -r .data.DbRootPassword | base64 -d)

# The CHARACTER_SET and collation should match the source DB
# if the do not then it will break foreign key relationships
# for any tables that are created in the future as part of db sync
CHARACTER_SET=utf8
COLLATION=utf8_general_ci

MARIADB_IMAGE=registry.redhat.io/rhosp-dev-preview/openstack-mariadb-rhel9:18.0
# Replace with your environment's MariaDB Galera cluster VIP and backend IPs:
SOURCE_MARIADB_IP=192.168.122.99
declare -A SOURCE_GALERA_MEMBERS
SOURCE_GALERA_MEMBERS=(
  ["standalone.localdomain"]=192.168.122.100
  # ...
)
SOURCE_DB_ROOT_PASSWORD=$(cat ~/tripleo-standalone-passwords.yaml | grep ' MysqlRootPassword:' | awk -F ': ' '{ print $2; }')

1.6.3. 事前チェック

  • Galera データベースクラスターのメンバーがオンラインであり、同期されていることを確認します。

    for i in "${!SOURCE_GALERA_MEMBERS[@]}"; do
      echo "Checking for the database node $i WSREP status Synced"
      sudo podman run -i --rm --userns=keep-id -u $UID $MARIADB_IMAGE mysql \
        -h "${SOURCE_GALERA_MEMBERS[$i]}" -uroot "-p$SOURCE_DB_ROOT_PASSWORD" \
        -e "show global status like 'wsrep_local_state_comment';" |\
        grep -qE '\bSynced\b'
    done
  • not-OK のソースデータベース数を取得します。

    podman run -i --rm --userns=keep-id -u $UID $MARIADB_IMAGE \
        mysql -h "$SOURCE_MARIADB_IP" -uroot "-p$SOURCE_DB_ROOT_PASSWORD" -e 'SHOW databases;'
  • 元の DB で mysqlcheck を実行して、not-OK のものを探します。

    . ~/.source_cloud_exported_variables
    test -z "$PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK"  || [ "$PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK" = " " ]
  • Pod 化された DB への接続をテストします (データベースを表示)。

    oc run mariadb-client --image $MARIADB_IMAGE -i --rm --restart=Never -- \
        mysql -rsh "$PODIFIED_MARIADB_IP" -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" -e 'SHOW databases;'
    oc run mariadb-client --image $MARIADB_IMAGE -i --rm --restart=Never -- \
        mysql -rsh "$PODIFIED_CELL1_MARIADB_IP" -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" -e 'SHOW databases;'

1.6.4. 手順 - データをコピーする

注記: 後でインポートした Nova サービスを、スーパーコンダクターアーキテクチャーに移行する必要があります。そのためには、セル DB 内の古いサービスレコードを cell1 から削除します。新しいレコードは、Nova サービスの Operator が指定する別のホスト名で登録されます。コンピュートエージェントを除くすべての Nova サービスには内部状態がないため、そのサービスレコードは安全に削除できます。以前の default セルの名前を cell1 に変更する必要があります。

  • DB ダンプを保存する一時フォルダーを作成し、次の手順の作業ディレクトリーとして使用します。

    mkdir ~/adoption-db
    cd ~/adoption-db
  • 元のデータベースのダンプを作成します。

    podman run -i --rm --userns=keep-id -u $UID -v $PWD:$PWD:z,rw -w $PWD $MARIADB_IMAGE bash <<EOF
    
    # Note Filter the information and performance schema tables
    # Gnocchi is no longer used as a metric store, skip dumping gnocchi database as well
    mysql -h ${SOURCE_MARIADB_IP} -u root "-p${SOURCE_DB_ROOT_PASSWORD}" -N -e 'show databases' | grep -E -v 'schema|mysql|gnocchi' | while read dbname; do
        echo "Dumping \${dbname}"
        mysqldump -h $SOURCE_MARIADB_IP -uroot "-p$SOURCE_DB_ROOT_PASSWORD" \
            --single-transaction --complete-insert --skip-lock-tables --lock-tables=0 \
            "\${dbname}" > "\${dbname}".sql
    done
    
    EOF
  • データベースを、.sql ファイルから Pod 化された MariaDB に復元します。

    # db schemas to rename on import
    declare -A db_name_map
    db_name_map["nova"]="nova_cell1"
    db_name_map["ovs_neutron"]="neutron"
    
    # db servers to import into
    declare -A db_server_map
    db_server_map["default"]=${PODIFIED_MARIADB_IP}
    db_server_map["nova_cell1"]=${PODIFIED_CELL1_MARIADB_IP}
    
    # db server root password map
    declare -A db_server_password_map
    db_server_password_map["default"]=${PODIFIED_DB_ROOT_PASSWORD}
    db_server_password_map["nova_cell1"]=${PODIFIED_DB_ROOT_PASSWORD}
    
    all_db_files=$(ls *.sql)
    for db_file in ${all_db_files}; do
        db_name=$(echo ${db_file} | awk -F'.' '{ print $1; }')
        if [[ -v "db_name_map[${db_name}]" ]]; then
            echo "renaming ${db_name} to ${db_name_map[${db_name}]}"
            db_name=${db_name_map[${db_name}]}
        fi
        db_server=${db_server_map["default"]}
        if [[ -v "db_server_map[${db_name}]" ]]; then
            db_server=${db_server_map[${db_name}]}
        fi
        db_password=${db_server_password_map["default"]}
        if [[ -v "db_server_password_map[${db_name}]" ]]; then
            db_password=${db_server_password_map[${db_name}]}
        fi
        echo "creating ${db_name} in ${db_server}"
        container_name=$(echo "mariadb-client-${db_name}-create" | sed 's/_/-/g')
        oc run ${container_name} --image ${MARIADB_IMAGE} -i --rm --restart=Never -- \
            mysql -h "${db_server}" -uroot "-p${db_password}" << EOF
    CREATE DATABASE IF NOT EXISTS ${db_name} DEFAULT CHARACTER SET ${CHARACTER_SET} DEFAULT COLLATE ${COLLATION};
    EOF
        echo "importing ${db_name} into ${db_server}"
        container_name=$(echo "mariadb-client-${db_name}-restore" | sed 's/_/-/g')
        oc run ${container_name} --image ${MARIADB_IMAGE} -i --rm --restart=Never -- \
            mysql -h "${db_server}" -uroot "-p${db_password}" "${db_name}" < "${db_file}"
    done
    oc exec -it openstack-galera-0 -c galera -- mysql --user=root --password=${db_server_password_map["default"]} -e \
        "update nova_api.cell_mappings set name='cell1' where name='default';"
    oc exec -it openstack-cell1-galera-0 -c galera -- mysql --user=root --password=${db_server_password_map["default"]} -e \
        "delete from nova_cell1.services where host not like '%nova-cell1-%' and services.binary != 'nova-compute';"

1.6.5. 事後チェック

次の出力を、トポロジー固有の設定と比較します。

  • データベースが正しくインポートされたことを確認します。

    . ~/.source_cloud_exported_variables
    
    # use 'oc exec' and 'mysql -rs' to maintain formatting
    dbs=$(oc exec openstack-galera-0 -c galera -- mysql -rs -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" -e 'SHOW databases;')
    echo $dbs | grep -Eq '\bkeystone\b'
    
    # ensure neutron db is renamed from ovs_neutron
    echo $dbs | grep -Eq '\bneutron\b'
    echo $PULL_OPENSTACK_CONFIGURATION_DATABASES | grep -Eq '\bovs_neutron\b'
    
    # ensure nova cell1 db is extracted to a separate db server and renamed from nova to nova_cell1
    c1dbs=$(oc exec openstack-cell1-galera-0 -c galera -- mysql -rs -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" -e 'SHOW databases;')
    echo $c1dbs | grep -Eq '\bnova_cell1\b'
    
    # ensure default cell renamed to cell1, and the cell UUIDs retained intact
    novadb_mapped_cells=$(oc exec openstack-galera-0 -c galera -- mysql -rs -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" \
      nova_api -e 'select uuid,name,transport_url,database_connection,disabled from cell_mappings;')
    uuidf='\S{8,}-\S{4,}-\S{4,}-\S{4,}-\S{12,}'
    left_behind=$(comm -23 \
      <(echo $PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS | grep -oE " $uuidf \S+") \
      <(echo $novadb_mapped_cells | tr -s "| " " " | grep -oE " $uuidf \S+"))
    changed=$(comm -13 \
      <(echo $PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS | grep -oE " $uuidf \S+") \
      <(echo $novadb_mapped_cells | tr -s "| " " " | grep -oE " $uuidf \S+"))
    test $(grep -Ec ' \S+$' <<<$left_behind) -eq 1
    default=$(grep -E ' default$' <<<$left_behind)
    test $(grep -Ec ' \S+$' <<<$changed) -eq 1
    grep -qE " $(awk '{print $1}' <<<$default) cell1$" <<<$changed
    
    # ensure the registered Nova compute service name has not changed
    novadb_svc_records=$(oc exec openstack-cell1-galera-0 -c galera -- mysql -rs -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" \
      nova_cell1 -e "select host from services where services.binary='nova-compute' order by host asc;")
    diff -Z <(echo $novadb_svc_records) <(echo $PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES)
  • 事前/事後チェックで、Pod の mariadb-clientrestricted:latest Security Context Constraints に関連する Pod セキュリティー警告を返した可能性があります。これはデフォルトの Security Context Constraints によるものであり、これがアドミッションコントローラーによる Pod の作成を妨げることはありません。有効期間が短い Pod に関する警告が表示されますが、機能には影響しません。詳細は、Pod のセキュリティー標準と警告 を参照してください。

1.7. OVN データを移行する

このドキュメントでは、OVN Northbound データベースおよび Southbound データベースを、元の OpenStack デプロイメントから OpenShift クラスター内で実行されている ovsdb-server インスタンスに移動する方法について説明します。

1.7.1. 理由

Pod 化された Neutron ML2/OVN ドライバーと OVN Northd サービスが起動時にデータベースを再構築するという意見もありますが、大規模な既存クラスター上での再構築は時間がかかる可能性があります。以下の手順を実行することで、データ移行を高速化し、OpenFlow テーブルの内容が不完全であることが原因で派生するデータプレーンの不要な中断を回避できます。

1.7.2. 前提条件

  • 前の導入手順が正常に実行されたことを確認する。

    • この時点で、OpenStackControlPlane リソースが作成されている。
    • 元のクラスターの NetworkAttachmentDefinition CRD がすでに定義されている。具体的には、openstack/internalapi ネットワークが定義されている。
    • Pod 化された MariaDB と RabbitMQ がすでに実行されている可能性がある。Neutron と OVN は実行されていない。
    • 元の OVN は、Pod 化されたバージョン以前のバージョンである。
    • 元の Neutron Server と OVN Northd サービスが停止されている。
    • 以下の間でネットワークルーティングが可能である。

      • 導入ホストと元の OVN。
      • 導入ホストと Pod 化された OVN。

1.7.3. 変数

以下の手順で使用するシェル変数を定義します。値はサンプルです。環境に適した値を使用してください。

STORAGE_CLASS_NAME=crc-csi-hostpath-provisioner
OVSDB_IMAGE=registry.redhat.io/rhosp-dev-preview/openstack-ovn-base-rhel9:18.0
SOURCE_OVSDB_IP=172.17.1.49

SOURCE_OVSDB_IP の実際の値は、Puppet によって生成された設定から取得できます。

grep -rI 'ovn_[ns]b_conn' /var/lib/config-data/puppet-generated/

1.7.4. 手順

  • OVN DB のコピーディレクトリーと導入ヘルパー Pod を準備します (OVN データベースのサイズに合わせてストレージリクエストを選択します)。
oc apply -f - <<EOF
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ovn-data
spec:
  storageClassName: $STORAGE_CLASS_NAME
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: ovn-copy-data
  annotations:
    openshift.io/scc: anyuid
  labels:
    app: adoption
spec:
  containers:
  - image: $OVSDB_IMAGE
    command: [ "sh", "-c", "sleep infinity"]
    name: adoption
    volumeMounts:
    - mountPath: /backup
      name: ovn-data
  securityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop: ALL
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - name: ovn-data
    persistentVolumeClaim:
      claimName: ovn-data
EOF
  • Pod が起動するまで待機します。
oc wait --for=condition=Ready pod/ovn-copy-data --timeout=30s
  • OVN データベースをバックアップします。
oc exec ovn-copy-data -- bash -c "ovsdb-client backup tcp:$SOURCE_OVSDB_IP:6641 > /backup/ovs-nb.db"
oc exec ovn-copy-data -- bash -c "ovsdb-client backup tcp:$SOURCE_OVSDB_IP:6642 > /backup/ovs-sb.db"
  • インポートする前に、Pod 化された OVN データベースサービスを開始します。
oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  ovn:
    enabled: true
    template:
      ovnDBCluster:
        ovndbcluster-nb:
          dbType: NB
          storageRequest: 10G
          networkAttachment: internalapi
        ovndbcluster-sb:
          dbType: SB
          storageRequest: 10G
          networkAttachment: internalapi
'
  • OVN DB Pod が実行フェーズに達するまで待ちます。
oc wait --for=jsonpath='{.status.phase}'=Running pod --selector=service=ovsdbserver-nb
oc wait --for=jsonpath='{.status.phase}'=Running pod --selector=service=ovsdbserver-sb
  • clusterIP サービスネットワーク上で Pod 化された OVN IP アドレスを取得します。
PODIFIED_OVSDB_NB_IP=$(oc get svc --selector "statefulset.kubernetes.io/pod-name=ovsdbserver-nb-0" -ojsonpath='{.items[0].spec.clusterIP}')
PODIFIED_OVSDB_SB_IP=$(oc get svc --selector "statefulset.kubernetes.io/pod-name=ovsdbserver-sb-0" -ojsonpath='{.items[0].spec.clusterIP}')
  • バックアップファイルのデータベーススキーマをアップグレードします。
oc exec ovn-copy-data -- bash -c "ovsdb-client get-schema tcp:$PODIFIED_OVSDB_NB_IP:6641 > /backup/ovs-nb.ovsschema && ovsdb-tool convert /backup/ovs-nb.db /backup/ovs-nb.ovsschema"
oc exec ovn-copy-data -- bash -c "ovsdb-client get-schema tcp:$PODIFIED_OVSDB_SB_IP:6642 > /backup/ovs-sb.ovsschema && ovsdb-tool convert /backup/ovs-sb.db /backup/ovs-sb.ovsschema"
  • データベースのバックアップを Pod 化された OVN データベースサーバーに復元します。
oc exec ovn-copy-data -- bash -c "ovsdb-client restore tcp:$PODIFIED_OVSDB_NB_IP:6641 < /backup/ovs-nb.db"
oc exec ovn-copy-data -- bash -c "ovsdb-client restore tcp:$PODIFIED_OVSDB_SB_IP:6642 < /backup/ovs-sb.db"
  • Pod 化された OVN データベースにバックアップからのオブジェクトが含まれていることを確認します。以下はその例です。
oc exec -it ovsdbserver-nb-0 -- ovn-nbctl show
oc exec -it ovsdbserver-sb-0 -- ovn-sbctl list Chassis
  • 最後に、OVN northbound および southbound データベースの同期を維持する ovn-northd サービスを開始できます。
oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  ovn:
    enabled: true
    template:
      ovnNorthd:
        networkAttachment: internalapi
'
  • OVN データベースのバックアップを使用して、ovn-data Pod と永続ボリューム要求を削除します (削除する前にスナップショットを作成することを検討してください)。
oc delete pod ovn-copy-data
oc delete pvc ovn-data

1.8. Identity サービスの導入

1.8.1. 前提条件

1.8.2. 変数

(現時点で必要なシェル変数はありません。)

1.8.3. 事前チェック

1.8.4. fernet キーをコピーする

  • fernet キーを含む keystone シークレットを作成します。

    oc apply -f - <<EOF
    apiVersion: v1
    data:
      CredentialKeys0: $($CONTROLLER1_SSH sudo cat /var/lib/config-data/puppet-generated/keystone/etc/keystone/credential-keys/0 | base64 -w 0)
      CredentialKeys1: $($CONTROLLER1_SSH sudo cat /var/lib/config-data/puppet-generated/keystone/etc/keystone/credential-keys/1 | base64 -w 0)
      FernetKeys0: $($CONTROLLER1_SSH sudo cat /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys/0 | base64 -w 0)
      FernetKeys1: $($CONTROLLER1_SSH sudo cat /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys/1 | base64 -w 0)
    kind: Secret
    metadata:
      name: keystone
      namespace: openstack
    type: Opaque
    EOF

1.8.5. 手順 - Keystone の導入

  • OpenStackControlPlane にパッチを適用して Keystone をデプロイします。

    oc patch openstackcontrolplane openstack --type=merge --patch '
    spec:
      keystone:
        enabled: true
        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
    '
  • 導入されたデプロイメントで openstack コマンドを使用するためのエイリアスを作成します。

    alias openstack="oc exec -t openstackclient -- openstack"
  • まだ古いコントロールプレーンを指している古いサービスとエンドポイント (Keystone サービスとエンドポイントを除くすべて) を消去します。

    openstack endpoint list | grep keystone | awk '/admin/{ print $2; }' | xargs ${BASH_ALIASES[openstack]} endpoint delete || true
    
    for service in aodh cinderv3 glance manila manilav2 neutron nova placement swift; do
      openstack service list | awk "/ $service /{ print \$2; }" | xargs ${BASH_ALIASES[openstack]} service delete || true
    done

1.8.6. 事後チェック

  • Keystone エンドポイントが定義され、Pod 化された FQDN を指していることを確認します。

    openstack endpoint list | grep keystone

1.9. OpenStack Networking サービスの導入

Neutron を導入するということは、Neutron が無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。

手順を完了すると、NeutronAPI サービスが実行され、Keystone endpoints が更新され、ソースクラウドの同じバックエンドが利用可能になっているはずです。上記の条件が満たされている場合、導入が完了したものとみなされます。

このガイドでは、以下も前提としています。

  1. TripleO 環境 (ソースクラウド) が片側で実行されている。
  2. SNO/CodeReadyContainers が反対側で実行されている。

1.9.1. 前提条件

  • 前の導入手順を完了している。特に、MariaDB と Keystone、および OVN データの移行 が導入されている必要があります。

1.9.2. 手順 - Neutron の導入

Keystone と同じパターンを Neutron Adoption でも実行します。

OpenStackControlPlane にパッチを適用して Neutron をデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  neutron:
    enabled: true
    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
      networkAttachments:
      - internalapi
'

1.9.3. 事後チェック

1.9.3.1. 結果として得られる Neutron Pod を検査する
NEUTRON_API_POD=`oc get pods -l service=neutron | tail -n 1 | cut -f 1 -d' '`
oc exec -t $NEUTRON_API_POD -c neutron-api -- cat /etc/neutron/neutron.conf
1.9.3.2. Neutron API サービスが Keystone に登録されていることを確認する
openstack service list | grep network
openstack endpoint list | grep network

| 6a805bd6c9f54658ad2f24e5a0ae0ab6 | regionOne | neutron      | network      | True    | public    | http://neutron-public-openstack.apps-crc.testing  |
| b943243e596847a9a317c8ce1800fa98 | regionOne | neutron      | network      | True    | internal  | http://neutron-internal.openstack.svc:9696        |
| f97f2b8f7559476bb7a5eafe3d33cee7 | regionOne | neutron      | network      | True    | admin     | http://192.168.122.99:9696                        |
1.9.3.3. サンプルリソースを作成する

ユーザーがネットワーク、サブネット、ポート、またはルーターを作成できるかテストできます。

openstack network create net
openstack subnet create --network net --subnet-range 10.0.0.0/24 subnet
openstack router create router

1.10. Image サービスの導入

Glance を導入するということは、Glance が無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。

手順を完了すると、GlanceAPI サービスが実行され、Keystone endpoints が更新され、ソースクラウドの同じバックエンドが利用可能になっているはずです。上記の条件が満たされている場合、導入が完了したものとみなされます。

このガイドでは、以下も前提としています。

  1. TripleO 環境 (ソースクラウド) が片側で実行されている。
  2. SNO/CodeReadyContainers が反対側で実行されている。
  3. (オプション) crcTripleO の両方から、内部/外部 Ceph クラスターにアクセスできる。

1.10.1. 前提条件

  • 前の導入手順を完了している。特に、MariaDB と Keystone が導入されている必要があります。

1.10.2. 手順 - Glance の導入

Glance の導入でも、Keystone と同じパターンを実行します。

1.10.2.1. ローカルストレージバックエンドを使用する

Glance をローカルストレージバックエンド (Ceph ではない) でデプロイする必要がある場合は、OpenStackControlPlane にパッチを適用して Glance をデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  glance:
    enabled: true
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      storageClass: "local-storage"
      storageRequest: 10G
      glanceAPIs:
        default:
          replicas: 1
          type: single
          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
'
1.10.2.2. NFS バックエンドを使用する

TripleO をベースとするソースクラウドが NFS バックエンドで Glance を使用する場合、OpenStackControlPlane にパッチを適用して Glance をデプロイする前に、ネットワークに関連するいくつかの前提条件を検証することが重要です。ソースクラウドで、オーバークラウドが Glance バックエンドを設定するために使用する NFS パラメーターを確認します。特に、TripleO heat テンプレートの中から次の変数を見つけます。通常、これらの変数は /usr/share/openstack-tripleo-heat-templates/environments/storage/glance-nfs.yaml[glance-nfs.yaml] によって提供されるデフォルトコンテンツのオーバーライドです。

GlanceBackend: file

GlanceNfsEnabled: true

GlanceNfsShare: 192.168.24.1:/var/nfs

上の例では、最初の変数が示すように、Glance には NFS バックエンドの概念がありません。これは Cinder と異なる点です。このシナリオでは File ドライバーが使用され、その裏では通常 /var/lib/glance/images を指す filesystem_store_datadirGlanceNfsShare 変数で指定されるエクスポート値にマッピングされます。GlanceNfsShare が、導入された OpenStack コントロールプレーンに伝播されるはずのネットワークを介してエクスポートされない場合、管理者 (人間) は nfs-server を停止してエクスポートを storage ネットワークに再マッピングするという追加アクションを実行する必要があります。通常このアクションは、ソースコントローラーノードで Glance サービスが停止すると発生します。Pod 化されたコントロールプレーンでは、network isolation diagram のように、Glance はストレージネットワークに接続され、関連付けられた NetworkAttachmentsDefinition CR を介して伝播されます。その結果の Pod には、このネットワークを介して Image サービストラフィックを処理するための適切な権限がすでに与えられています。デプロイされた OpenStack コントロールプレーンでは、次のコマンドを使用して NodeNetworkConfigPolicy (nncp) と NetworkAttachmentDefinition (net-attach-def) の両方をチェックすることで、ネットワークマッピングが TripleO ベースの環境にデプロイされたものと一致することを確認できます。

$ oc get nncp
NAME                        STATUS      REASON
enp6s0-crc-8cf2w-master-0   Available   SuccessfullyConfigured

$ oc get net-attach-def
NAME
ctlplane
internalapi
storage
tenant

$ oc get ipaddresspool -n metallb-system
NAME          AUTO ASSIGN   AVOID BUGGY IPS   ADDRESSES
ctlplane      true          false             ["192.168.122.80-192.168.122.90"]
internalapi   true          false             ["172.17.0.80-172.17.0.90"]
storage       true          false             ["172.18.0.80-172.18.0.90"]
tenant        true          false             ["172.19.0.80-172.19.0.90"]

上記は、伝播されたネットワークに問題がないことを確認するために、OpenShift 環境でチェックする必要がある出力の例を示しています。

次の手順の前提は以下のとおりです。

  1. Storage ネットワークは OpenStack コントロールプレーンに伝播されている。
  2. Glance は Storage ネットワークに到達し、ポート 2049 を介して nfs サーバーに接続できる。

上記の条件が満たされる場合、Glance サービスを導入し、既存の NFS 共有に接続された新しい default GlanceAPI インスタンスを作成できます。

cat << EOF > glance_nfs_patch.yaml

spec:
  extraMounts:
  - extraVol:
    - extraVolType: Nfs
      mounts:
      - mountPath: /var/lib/glance/images
        name: nfs
      propagation:
      - Glance
      volumes:
      - name: nfs
        nfs:
          path: /var/nfs
          server: 172.17.3.20
    name: r1
    region: r1
  glance:
    enabled: true
    template:
      databaseInstance: openstack
      customServiceConfig: |
         [DEFAULT]
         enabled_backends = default_backend:file
         [glance_store]
         default_backend = default_backend
         [default_backend]
         filesystem_store_datadir = /var/lib/glance/images/
      storageClass: "local-storage"
      storageRequest: 10G
      glanceAPIs:
        default:
          replicas: 1
          type: single
          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
EOF

注記:

glance_nfs_patch.yaml 内の nfs/server IP アドレスを nfs-server に到達するために使用される IP に置き換え、nfs/pathnfs-server 内のエクスポートされたパスを指していることを確認します。

OpenStackControlPlane にパッチを適用し、NFS バックエンドを使用して Glance をデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch-file glance_nfs_patch.yaml

GlanceAPI がアクティブな場合、単一の API インスタンスが表示されます。

$ oc get pods -l service=glance
NAME                      READY   STATUS    RESTARTS
glance-default-single-0   3/3     Running   0

Pod の説明では次の報告が表示される必要があります。

Mounts:
...
  nfs:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    {{ server ip address }}
    Path:      {{ nfs export path }}
    ReadOnly:  false
...

次のコマンドを実行してマウントポイントを再確認することもできます。

oc rsh -c glance-api glance-default-single-0

sh-5.1# mount
...
...
{{ ip address }}:/var/nfs on /var/lib/glance/images type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.18.0.5,local_lock=none,addr=172.18.0.5)
...
...

openstack image create コマンドを実行し、NFS ノード上で uuid がエクスポートされたディレクトリーに作成されたことを再確認できます。

以下はその例です。

$ oc rsh openstackclient
$ openstack image list

sh-5.1$  curl -L -o /tmp/cirros-0.5.2-x86_64-disk.img http://download.cirros-cloud.net/0.5.2/cirros-0.5.2-x86_64-disk.img
...
...

sh-5.1$ openstack image create --container-format bare --disk-format raw --file /tmp/cirros-0.5.2-x86_64-disk.img cirros
...
...

sh-5.1$ openstack image list
+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 634482ca-4002-4a6d-b1d5-64502ad02630 | cirros | active |
+--------------------------------------+--------+--------+

nfs-server ノードでは、同じ uuid がエクスポートされた /var/nfs にあります。

$ ls /var/nfs/
634482ca-4002-4a6d-b1d5-64502ad02630
1.10.2.3. Ceph ストレージバックエンドを使用する

Ceph バックエンドを使用している場合は、customServiceConfig パラメーターを使用して、適切な設定を GlanceAPI インスタンスに注入する必要があります。

Ceph 関連のシークレット (ceph-conf-files) が openstack namespace に作成されていること、および OpenStackControlPlane CR の extraMounts プロパティーが適切に設定されていることを確認してください。これらのタスクについては、前の導入手順 Ceph バックエンドの設定 で説明しています。

cat << EOF > glance_patch.yaml
spec:
  glance:
    enabled: true
    template:
      databaseInstance: openstack
      customServiceConfig: |
        [DEFAULT]
        enabled_backends=default_backend:rbd
        [glance_store]
        default_backend=default_backend
        [default_backend]
        rbd_store_ceph_conf=/etc/ceph/ceph.conf
        rbd_store_user=openstack
        rbd_store_pool=images
        store_description=Ceph glance store backend.
      storageClass: "local-storage"
      storageRequest: 10G
      glanceAPIs:
        default:
          replicas: 1
          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
EOF

OpenStackControlPlane にパッチを適用して、Ceph バックエンドで Glance をデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch-file glance_patch.yaml

1.10.3. 事後チェック

1.10.3.1. OpenStack CLI から Glance サービスをテストする

結果として得られる Glance Pod を検査します。

GLANCE_POD=`oc get pod |grep glance-default-external-0 | cut -f 1 -d' '`
oc exec -t $GLANCE_POD -c glance-api -- cat /etc/glance/glance.conf.d/02-config.conf

[DEFAULT]
enabled_backends=default_backend:rbd
[glance_store]
default_backend=default_backend
[default_backend]
rbd_store_ceph_conf=/etc/ceph/ceph.conf
rbd_store_user=openstack
rbd_store_pool=images
store_description=Ceph glance store backend.

oc exec -t $GLANCE_POD -c glance-api -- ls /etc/ceph
ceph.client.openstack.keyring
ceph.conf

Ceph シークレットは適切にマウントされています。ここで OpenStack CLI に移動し、サービスがアクティブであり、エンドポイントが適切に更新されていることを確認します。

(openstack)$ service list | grep image

| fc52dbffef36434d906eeb99adfc6186 | glance    | image        |

(openstack)$ endpoint list | grep image

| 569ed81064f84d4a91e0d2d807e4c1f1 | regionOne | glance       | image        | True    | internal  | http://glance-internal-openstack.apps-crc.testing   |
| 5843fae70cba4e73b29d4aff3e8b616c | regionOne | glance       | image        | True    | public    | http://glance-public-openstack.apps-crc.testing     |
| 709859219bc24ab9ac548eab74ad4dd5 | regionOne | glance       | image        | True    | admin     | http://glance-admin-openstack.apps-crc.testing      |

以前にソースクラウドにリストしたイメージが、導入されたサービスで利用できることを確認します。

(openstack)$ image list
+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| c3158cad-d50b-452f-bec1-f250562f5c1f | cirros | active |
+--------------------------------------+--------+--------+
1.10.3.2. イメージのアップロード

導入したサービス上でイメージが作成できるかテストできます。

(openstack)$ alias openstack="oc exec -t openstackclient -- openstack"
(openstack)$ curl -L -o /tmp/cirros-0.5.2-x86_64-disk.img http://download.cirros-cloud.net/0.5.2/cirros-0.5.2-x86_64-disk.img
    qemu-img convert -O raw /tmp/cirros-0.5.2-x86_64-disk.img /tmp/cirros-0.5.2-x86_64-disk.img.raw
    openstack image create --container-format bare --disk-format raw --file /tmp/cirros-0.5.2-x86_64-disk.img.raw cirros2
    openstack image list
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   273  100   273    0     0   1525      0 --:--:-- --:--:-- --:--:--  1533
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 15.5M  100 15.5M    0     0  17.4M      0 --:--:-- --:--:-- --:--:-- 17.4M

+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+
| Field            | Value                                                                                                                                      |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+
| container_format | bare                                                                                                                                       |
| created_at       | 2023-01-31T21:12:56Z                                                                                                                       |
| disk_format      | raw                                                                                                                                        |
| file             | /v2/images/46a3eac1-7224-40bc-9083-f2f0cd122ba4/file                                                                                       |
| id               | 46a3eac1-7224-40bc-9083-f2f0cd122ba4                                                                                                       |
| min_disk         | 0                                                                                                                                          |
| min_ram          | 0                                                                                                                                          |
| name             | cirros                                                                                                                                     |
| owner            | 9f7e8fdc50f34b658cfaee9c48e5e12d                                                                                                           |
| properties       | os_hidden='False', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros', owner_specified.openstack.sha256='' |
| protected        | False                                                                                                                                      |
| schema           | /v2/schemas/image                                                                                                                          |
| status           | queued                                                                                                                                     |
| tags             |                                                                                                                                            |
| updated_at       | 2023-01-31T21:12:56Z                                                                                                                       |
| visibility       | shared                                                                                                                                     |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+

+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 46a3eac1-7224-40bc-9083-f2f0cd122ba4 | cirros2| active |
| c3158cad-d50b-452f-bec1-f250562f5c1f | cirros | active |
+--------------------------------------+--------+--------+


(openstack)$ oc rsh ceph
sh-4.4$ ceph -s
r  cluster:
    id:     432d9a34-9cee-4109-b705-0c59e8973983
    health: HEALTH_OK

  services:
    mon: 1 daemons, quorum a (age 4h)
    mgr: a(active, since 4h)
    osd: 1 osds: 1 up (since 4h), 1 in (since 4h)

  data:
    pools:   5 pools, 160 pgs
    objects: 46 objects, 224 MiB
    usage:   247 MiB used, 6.8 GiB / 7.0 GiB avail
    pgs:     160 active+clean

sh-4.4$ rbd -p images ls
46a3eac1-7224-40bc-9083-f2f0cd122ba4
c3158cad-d50b-452f-bec1-f250562f5c1f

1.11. Placement サービスの導入

1.11.1. 前提条件

1.11.2. 変数

(現時点で必要なシェル変数はありません。)

1.11.3. 手順 - Placement の導入

  • OpenStackControlPlane にパッチを適用して Placement をデプロイします。

    oc patch openstackcontrolplane openstack --type=merge --patch '
    spec:
      placement:
        enabled: true
        apiOverride:
          route: {}
        template:
          databaseInstance: openstack
          secret: osp-secret
          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
    '

1.11.4. 事後チェック

  • Placement エンドポイントが定義され、それが Pod 化された FQDN を指していること、および Placement API が応答することを確認します。

    alias openstack="oc exec -t openstackclient -- openstack"
    
    openstack endpoint list | grep placement
    
    
    # Without OpenStack CLI placement plugin installed:
    PLACEMENT_PUBLIC_URL=$(openstack endpoint list -c 'Service Name' -c 'Service Type' -c URL | grep placement | grep public | awk '{ print $6; }')
    oc exec -t openstackclient -- curl "$PLACEMENT_PUBLIC_URL"
    
    # With OpenStack CLI placement plugin installed:
    openstack resource class list

1.12. Compute サービスの導入

注記 このサンプルシナリオでは、単純なシングルセルのセットアップについて説明します。実稼働環境での使用に推奨されるマルチスタックトポロジーでは、セル DB レイアウトが異なり、異なる命名スキームを使用する必要があります (ここでは説明しません)。

1.12.1. 前提条件

1.12.2. 変数

以下の手順で使用するシェル変数とエイリアスを定義します。値はサンプルです。環境に適した値を使用してください。

alias openstack="oc exec -t openstackclient -- openstack"

1.12.3. 手順 - Nova の導入

注記: この手順では、Nova Metadata がそれぞれのセルレベルではなくトップレベルにデプロイされていることを前提としています。そのため、ここに示す例でも同じ方法でインポートしています。ソースデプロイメントにセルごとのメタデータデプロイメントがある場合は、必要に応じて以下のパッチを調整します。Metadata サービスは cell0 では実行できません。

  • OpenStackControlPlane にパッチを適用して Nova をデプロイします。

    oc patch openstackcontrolplane openstack -n openstack --type=merge --patch '
    spec:
      nova:
        enabled: true
        apiOverride:
          route: {}
        template:
          secret: osp-secret
          apiServiceTemplate:
            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
            customServiceConfig: |
              [workarounds]
              disable_compute_service_check_for_ffu=true
          metadataServiceTemplate:
            enabled: true # deploy single nova metadata on the top level
            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
            customServiceConfig: |
              [workarounds]
              disable_compute_service_check_for_ffu=true
          schedulerServiceTemplate:
            customServiceConfig: |
              [workarounds]
              disable_compute_service_check_for_ffu=true
          cellTemplates:
            cell0:
              conductorServiceTemplate:
                customServiceConfig: |
                  [workarounds]
                  disable_compute_service_check_for_ffu=true
            cell1:
              metadataServiceTemplate:
                enabled: false # enable here to run it in a cell instead
                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
                customServiceConfig: |
                  [workarounds]
                  disable_compute_service_check_for_ffu=true
              conductorServiceTemplate:
                customServiceConfig: |
                  [workarounds]
                  disable_compute_service_check_for_ffu=true
    '
  • Nova コントロールプレーンサービスの CR の準備が整うまで待機します。

    oc wait --for condition=Ready --timeout=300s Nova/nova

    ローカル Conductor サービスはセルごとに開始され、スーパーコンダクターは cell0 で実行されます。disable_compute_service_check_for_ffu は、外部データプレーンがインポートされ、Nova Compute サービスの fast-forward アップグレードが実行されるまで、インポートされたすべての Nova サービスで必須である点に注意してください。詳細は、EDPM の導入 を参照してください。

1.12.4. 事後チェック

  • Nova エンドポイントが定義され、Pod 化された FQDN を指し、 Nova API が応答することを確認します。

    openstack endpoint list | grep nova
    openstack server list

次の出力を、トポロジー固有の設定と比較します。

  • スーパーコンダクターに cell1 の存在をクエリーし、それを導入前の値と比較します。

    . ~/.source_cloud_exported_variables
    echo $PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS
    oc rsh nova-cell0-conductor-0 nova-manage cell_v2 list_cells | grep -F '| cell1 |'

    以下の変化が予想されます。

    • cell1 の nova DB とユーザー名は nova_cell1 になります。
    • デフォルトのセルの名前が cell1 になります (マルチセルセットアップでは、代わりに最後のセルとしてインデックスが付けられるはずです)。
    • RabbitMQ トランスポート URL は guest を使用しなくなります。

注記 この時点では、Nova コントロールプレーンサービスは既存の Nova コンピュートワークロードを制御しません。その検証が可能になるのは、EDPM の導入が完了した後です。詳細は、EDPM の導入 を参照してください。

1.13. Block Storage サービスの導入

Director でデプロイされた Cinder サービスを OpenStack に導入する場合、必ずしも単純なプロセスではないため、ある程度の検討が必要です。

通常、導入プロセスには以下が含まれます。

  • 既存の制限を確認します。
  • cinder サービスの配置を検討します。
  • ボリュームおよびバックアップサービスを実行する OpenShift ノードを準備します。
  • 既存の cinder.conf ファイルに基づきマニフェストを作成します。
  • Cinder をデプロイします。
  • 新規デプロイメントを検証します。

このガイドでは、ほとんどの状況でこれらの手順を完了できるだけの知識を提供しますが、それでも OpenStack サービスがどのように機能するか、および Cinder 設定ファイルの構造に関する知識は必要です。

1.13.1. 制限事項

現時点で、このガイドラインや Operator に関連する、言及すべき制限がいくつかあります。

  • すべての cinder ボリュームに対するグローバルな nodeSelector は存在せず、バックエンドごとに指定する必要があります。これは、今後変更される可能性があります。
  • すべての cinder ボリュームに対するグローバルな customServiceConfig または customServiceConfigSecrets 存在せず、バックエンドごとに指定する必要があります。これは、今後変更される可能性があります。
  • 現時点では、ボリュームデータがコンピュートノードに保存される LVM バックエンドの導入について、このプロセスでは説明されていません。今後、文書化される可能性があります。
  • RHEL に含まれていないカーネルモジュールを必要とする Cinder バックエンドのサポートは、Operator でデプロイされた OpenStack ではテストされていないため、このガイドでは言及していません。
  • 現時点で、DCN/Edge デプロイメントの導入については、このガイドでは説明されていません。

1.13.2. 前提条件

  • 前の導入手順を完了している。特に、cinder サービスが停止され、サービスデータベースが Pod 化された MariaDB にインポートされている必要があります。
  • Storage ネットワークが OpenShift クラスター上に適切に設定されている。

1.13.3. 変数

事前チェックのために前の手順で定義した CONTROLLER1_SSH を使用します。新しい環境変数を定義する必要はありません。

1.13.4. 事前チェック

cinder.conf ファイルの内容が必要です。ファイルをダウンロードしてローカルでアクセスできるようにします。

$CONTROLLER1_SSH cat /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf > cinder.conf

1.13.5. OpenShift の準備

新規デプロイメントのプランニング で説明したように、OpenShift に OpenStack をデプロイする前に、ネットワークの準備が完了していること、ノードの選択していること、OpenShift ノードに必要な変更が加えられていることを確認する必要があります。Cinder ボリュームおよびバックアップサービスについては、この 3 点すべてについて慎重に検討する必要があります。

1.13.5.1. ノードの選択

cinder ボリュームおよびバックアップサービスを実行できる OpenShift ノードを制限する必要がある場合もあります。

特定の cinder サービスに対してノードを選択する必要がある場合を示す最適な例としては、LVM ドライバーを使用して Cinder をデプロイする場合が挙げられます。このシナリオでは、ボリュームが保存されている LVM データは特定のホストにのみ存在するため、その特定の OpenShift ノードに cinder-volume サービスを固定する必要があります。他の OpenShift ノードでサービスを実行しても機能しません。nodeSelector はラベルでのみ機能するため、OpenShift ホストノード名を使用して LVM バックエンドを制限することはできず、一意のラベル、既存ラベル、または新しいラベルを使用して識別する必要があります。

$ oc label nodes worker0 lvm=cinder-volumes
apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  secret: osp-secret
  storageClass: local-storage
  cinder:
    enabled: true
    template:
      cinderVolumes:
        lvm-iscsi:
          nodeSelector:
            lvm: cinder-volumes
< . . . >

ノードセレクターについて で説明したとおり、ラベルの使用が必要な場合の例としては、FC ストレージを使用しており、かつすべての OpenShift ノードに HBA カードがない場合が挙げられます。このシナリオでは、すべて (FC に限定しない) の cinder ボリュームバックエンドとバックアップサービスを制限する必要があります。

cinder バックエンド、その設定、および Cinder の使用状況に応じて、大量の I/O を伴うネットワーク集中型の cinder ボリュームサービスや、ネットワークだけでなくメモリーや CPU も集中的に使用する cinder バックアップサービスを利用できます。これは、OpenShift 操作者 (人間) にとって懸念事項となる可能性があり、これらのサービスが他の OpenShift ワークロードに干渉しないようにするために、nodeSelector を使用する必要がある場合もあります。ノード選択の詳細は、ノードセレクターについて を参照してください。

cinder ボリュームを実行するノードを選択する際は、イメージからボリュームを作成する操作で glance メージをダウンロードする際に cinder-volume もローカルストレージを使用する可能性があり、同時操作を行う際に cinder-bolume キャッシュを使用しないと、かなりの空き領域が必要になる可能性がある点に注意してください。

一時イメージ用に十分なローカルディスク領域を持つノードがない場合は、イメージ用にリモート NFS の場所を使用できます。Director デプロイメントではこれを手動で設定する必要がありましたが、Operator を使用すると、追加のボリューム機能 () extraMounts を使用して自動的に設定できます。

1.13.5.2. トランスポートプロトコル

ストレージトランスポートプロトコルの仕様により、OpenShift 側でいくつかの変更が必要になる可能性があります。これはベンダーが文書化する必要がありますが、ここではさまざまなトランスポートプロトコルの指針として使用できる一般的な手順をいくつか提供します。

enabled_backends 設定オプションにリストされている cinder.conf ファイル内のバックエンドセクションを確認して、そのバックエンドで使用されているトランスポートストレージプロトコルを特定します。

トランスポートプロトコルは、バックエンドに応じて以下の方法で見つけることができます。

  • volume_driver 設定オプションを確認します。ここには、RBD、iSCSI、FC などのプロトコル自体が含まれている可能性があります。
  • target_protocol 設定オプションを確認します。
警告

MachineConfig を使用して OpenShift ノードに変更を加えるたびに、ノードは再起動されます。その点に留意して操作してください。

1.13.5.2.1. NFS

NFS に対する操作は必要ありません。追加の変更を加えなくても、OpenShift は NFS バックエンドに接続できます。

1.13.5.2.2. RBD/Ceph

ノードを準備するために RBD/Ceph で必要な操作はありません。追加の変更を加えなくても、OpenShift は Ceph バックエンドに接続できます。ただし、認証情報と設定ファイルをサービスに提供する必要があります。

1.13.5.2.3. iSCSI

iSCSI ボリュームに接続するには、ボリュームおよびバックアップサービスが実行される予定の OpenShift ホスト上で iSCSI イニシエーターが実行されている必要があります。展示点で Linux Open iSCSI イニシエーターはネットワーク namespace をサポートしていないため、通常の OpenShift の使用、OpenShift CSI プラグイン、OpenStack サービスためにサービスのインスタンスを 1 つだけ実行する必要があります。

OpenShift ノードで iscsid まをだ実行していない場合は、次のような MachineConfig を適用する必要があります。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-enable-iscsid
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - enabled: true
        name: iscsid.service

ラベルを使用して cinder サービスが実行されているノードを制限している場合は、ノードセレクターについて で説明されているとおり MachineConfigPool を使用して、MachineConfig の影響をサービスが実行されるノードのみに制限する必要があります。

プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfigworkermaster に置き換える必要がある場合があります。

1.13.5.2.4. FC

何もしなくても FC ボリュームは機能しますが、cinder ボリュームと cinder バックアップサービスは HBA を備えた OpenShift ホストで実行する必要があります。そのため、HBA を持たないノードがある場合は、[ノード選択セクション] (#node-selection) で説明されているとおり、ラベルを使用してサービスが実行される場所を制限する必要があります。

これは、FC を使用する仮想化された OpenShift クラスターの場合、仮想マシン内のホストの HBA も公開する必要があることを意味します。

1.13.5.2.5. NVMe-oF

NVMe-oF ボリュームに接続するには、nvme カーネルモジュールが OpenShift ホストにロードされている必要があります。

ボリュームおよびバックアップサービスが実行される予定の OpenShift ノードに nvme-fabrics モジュールをまだロードしていない場合は、次のような MachineConfig を適用する必要があります。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-load-nvme-fabrics
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modules-load.d/nvme_fabrics.conf
          overwrite: false
          # Mode must be decimal, this is 0644
          mode: 420
          user:
            name: root
          group:
            name: root
          contents:
            # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397.
            # This is the rfc2397 text/plain string format
            source: data:,nvme-fabrics

ラベルを使用して cinder サービスが実行されているノードを制限している場合は、ノードセレクターについて で説明されているとおり MachineConfigPool を使用して、MachineConfig の影響をサービスが実行されるノードのみに制限する必要があります。

プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfigworkermaster に置き換える必要がある場合があります。

nvme-fabrics モジュールをロードするだけで、トランスポート固有のモジュール (tcp、rdma、fc) が必要に応じてロードされます。

NVMe-oF ボリュームを使用する実稼働デプロイメントでは、マルチパス構成の使用が推奨されます。NVMe-oF ボリュームの場合、OpenStack は ANA と呼ばれるネイティブマルチパス構成を使用します。

OpenShift ノードが再起動され、nvme-fabrics モジュールのロードが開始されると、ホストをチェックすることで、オペレーティングシステムが設定されて ANA をサポートしていることを確認できます。

cat /sys/module/nvme_core/parameters/multipath
重要

ANA は Linux マルチパス構成のデバイスマッパーを使用しません。しかし現在の OpenStack コードでは、Nova でマルチパス構成を使用するにはコンピュートノード上の multipathd が実行されている必要があるため、必ず マルチパス構成セクション に記載されているコンピュートノードのマルチパス構成部分に従ってください。

1.13.5.2.6. マルチパス構成

iSCSI および FC プロトコルの場合は、次の 4 つからなるマルチパス構成の使用が推奨されます。

  • OpenShift ホストを準備する
  • Cinder サービスを設定する
  • Nova コンピュートを準備する
  • Nova サービスを設定する

OpenShift ホストを準備するには、次のような MachineConfig を使用して、Linux マルチパスデバイスマッパーが OpenShift ホスト上で設定および実行されていることを確認する必要があります。

# Includes the /etc/multipathd.conf contents and the systemd unit changes
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    service: cinder
  name: 99-master-cinder-enable-multipathd
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/multipath.conf
          overwrite: false
          # Mode must be decimal, this is 0600
          mode: 384
          user:
            name: root
          group:
            name: root
          contents:
            # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397.
            # This is the rfc2397 text/plain string format
            source: data:,defaults%20%7B%0A%20%20user_friendly_names%20no%0A%20%20recheck_wwid%20yes%0A%20%20skip_kpartx%20yes%0A%20%20find_multipaths%20yes%0A%7D%0A%0Ablacklist%20%7B%0A%7D
    systemd:
      units:
      - enabled: true
        name: multipathd.service

ラベルを使用して cinder サービスが実行されているノードを制限している場合は、ノードセレクターについて で説明されているとおり MachineConfigPool を使用して、MachineConfig の影響をサービスが実行されるノードのみに制限する必要があります。

プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfigworkermaster に置き換える必要がある場合があります。

マルチパス構成を使用するように cinder サービスを設定するには、すべてのバックエンドセクションと、バックアップサービスの [DEFAULT] セクションで、use_multipath_for_image_xfer 設定オプションを有効にする必要があります。ただし、Pod 化されたデプロイメントではこれがデフォルトであるため、この操作は必要ありません。つまり、use_multipath_for_image_xfer = false を設定してオーバーライドしない限り、サービスが OpenShift ホスト上で実行されていればマルチパス構成は機能します。

1.13.6. 設定

新規デプロイメントのプランニング で説明されているように、Cinder は、インストーラーによって定義された不明瞭な設定パラメーターではなく、設定スニペットを使用して設定されます。

Cinder ボリュームバックエンドの推奨デプロイ方法が変更されたことで古い制限が排除され、柔軟性が向上し、操作全般が改善されました。

Director を使用してデプロイする場合、以前はすべてのバックエンドで 1 つの Cinder ボリュームサービスを実行していました (各バックエンドは独自のプロセスで実行されます)。このデプロイ方法は今もサポートされていますが、推奨はされません。バックエンドごとにボリュームサービスを使用するデプロイメントモデルは優れているため、この方法が推奨されます。

つまり、LVM と Ceph バックエンドの場合は、cinderVolume に 2 つのエントリーが存在することになります。また、制限のセクションで説明したように、すべてのボリュームサービスにグローバルデフォルトを設定することはできないため、それぞれに対してグローバルデフォルトを定義する必要があります。以下はその例です。

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    enabled: true
    template:
      cinderVolume:
        lvm:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [lvm]
< . . . >
        ceph:
          customServiceConfig: |
            [DEFAULT]
            debug = True
            [ceph]
< . . . >

機密情報を含むボリュームバックエンドの場合は、SecretCustomServiceConfigSecrets キーを使用することが推奨される点に注意してください。

1.13.7. 設定の準備

デプロイメントマニフェスト全体を使用するのではなく導入する場合は、他のサービスの場合ど登用に対象を絞ったパッチを使用します。このパッチでは、それぞれ固有の設定を使用して異なる cinder サービスを有効にします。

警告: 設定オプションが非推奨になっていたり、削除または追加されている可能性があるため、新しい OpenStack バージョンでもすべての設定オプションが有効であることを確認してください。これは、バックエンドドライバー固有の設定オプションとその他の一般的なオプションの両方に該当します。

導入に向けた cinder 設定の準備には、カスタマイズする方法と手早く行う方法の 2 種類があります。どちらの方法でも Cinder の動作に違いはありませんが、可能な限りカスタマイズすることが推奨されます。

カスタマイズアプローチの概要は次のとおりです。

  1. 設定のどの部分がすべての cinder サービスに使用できる汎用の設定かを判断し、OpenShift でデプロイした場合に変更される部分 (例: [dabase] セクションの connection[DEFAULT]transport_urllog_dir[coordination] セクション全体) を削除します。この設定は cinder: template: レベルの customServiceConfig に配置されます (または Secret に配置され、customServiceConfigSecrets で使用されます)。
  2. スケジューラー固有の設定があるか確認し、ある場合はそれを cinder: template: cinderSchedulercustomServiceConfig セクションに追加します。
  3. API 固有の設定があるか確認し、ある場合はそれを cinder: template: cinderSchedulercinder: template: cinderAPI セクションに追加します。
  4. cinder バックアップがデプロイされている場合は、cinder バックアップに関連する設定オプションを取得し、それらを cinder: template: cinderBackup: レベルの CustomServiceConfig に追加します (または Secret に追加して、CustomServiceConfigSecrets で使用します)。今後、複数のレプリカをサポートしやすくするために、[DEFAULT] セクションの host 設定を削除する必要があります。
  5. 各ドライバーのボリュームバックエンド設定を決定します。cinder Operator はすべてのボリュームサービスに対するグローバルな customServiceConfig セクションをサポートしないため、この設定には特定のドライバーセクションだけでなく、[backend_defaults] セクションと FC ゾーニングセクションも含まれている可能性があります。各バックエンドには cinder: template: cinder Volumes の下に独自のセクションがあり、この設定は customServiceConfig に配置されます (または Secret に配置され、CustomServiceConfigSecrets で使用されます)。
  6. 使用されている cinder ボリュームドライバーにカスタムベンダーイメージが必要か確認します。必要な場合は、OpenStack Cinder エコシステムページ に記載されているベンダーの指示からイメージの場所を見つけ、containerImage キーを使用して特定のドライバーセクションの下にイメージを追加します。たとえば、Pure Storage アレイがあり、ドライバーがすでに OSP18 で認定されている場合は、次のようになります。

    spec:
      cinder:
        enabled: true
        template:
          cinderVolume:
            pure:
              containerImage: registry.connect.redhat.com/purestorage/openstack-cinder-volume-pure-rhosp-18-0'
              customServiceConfigSecrets:
                - openstack-cinder-pure-cfg
    < . . . >
  7. 外部ファイル: Cinder サービスは、たとえばカスタムポリシー、認証情報の保存、ストレージアレイに接続するための SSL CA バンドルなどで外部ファイルを使用することがあります。これらのファイルを、適切なコンテナーで利用できるようにする必要があります。そのためには、Secrets または ConfigMap を使用して情報を OpenShift に保存し、次に extraMounts キーを保存します。たとえば、ceph-conf-files という名前の Secret に保存されている Ceph 認証情報の場合、OpenstackControlPlane の最上位の extraMounts にパッチを適用します。

    spec:
      extraMounts:
      - extraVol:
        - extraVolType: Ceph
          mounts:
          - mountPath: /etc/ceph
            name: ceph
            readOnly: true
          propagation:
          - CinderVolume
          - CinderBackup
          - Glance
          volumes:
          - name: ceph
            projected:
              sources:
              - secret:
                  name: ceph-conf-files

    ただし、サービス固有の場合 (例: API ポリシー) は、該当するサービス上で直接実行します。この例では、my-cinder-conf と呼ばれる ConfigMap から追加するポリシーを参照する cinder API 設定を含めます。これは、ポリシーの内容を含む policy キーを持っています。

    spec:
      cinder:
        enabled: true
        template:
          cinderAPI:
            customServiceConfig: |
               [oslo_policy]
               policy_file=/etc/cinder/api/policy.yaml
          extraMounts:
          - extraVol:
            - extraVolType: Ceph
              mounts:
              - mountPath: /etc/cinder/api
                name: policy
                readOnly: true
              propagation:
              - CinderAPI
              volumes:
              - name: policy
                projected:
                  sources:
                  - configMap:
                      name: my-cinder-conf
                      items:
                        - key: policy
                          path: policy.yaml

手早く実行できるプロセスの方は、これより簡単です。

  1. 古いデプロイメントの cinder.conf ファイルから詳細 ([dabase] セクションの connection[DEFAULT]transport_urllog_dir[coordination] セクション全体など) を削除して、非依存設定ファイルを作成します。
  2. 設定に機密情報が含まれていると仮定して、ファイル全体の変更された内容を Secret にドロップします。
  3. バックエンドごとに cinder ボリュームセクションを作成し、それぞれの enabled_backends オプションを追して、すべてのサービスでこのシークレットを参照します。
  4. カスタム設定の説明で最後の箇条書きとして説明したとおり、外部ファイルを追加します。

手早く実行できる設定のパッチは、次のサンプルのようになります。

   spec:
     cinder:
       enabled: true
       template:
         cinderAPI:
           customServiceConfigSecrets:
             - cinder-conf
         cinderScheduler:
           customServiceConfigSecrets:
             - cinder-conf
         cinderBackup:
           customServiceConfigSecrets:
             - cinder-conf
         cinderVolume:
           lvm1:
             customServiceConfig: |
               [DEFAULT]
               enabled_backends = lvm1
             customServiceConfigSecrets:
               - cinder-conf
           lvm2:
             customServiceConfig: |
               [DEFAULT]
               enabled_backends = lvm2
             customServiceConfigSecrets:
               - cinder-conf
1.13.7.1. 設定生成ヘルパーツール

Operator を使用してデプロイするための適切な Cinder 設定ファイルの作成は、特にそれが初めての場合、複雑になることがあります。そのため、cinder.conf ファイルからドラフトファイルを作成できるヘルパーツールを使用できます。

このツールは自動化ツールとして使用するものではありません。主に、要点を理解するために使用でき、潜在的な落とし穴や注意事項を指摘することもあります。

重要

このツールを使用するには、PyYAML Python パッケージがインストールされている必要があります (pip install PyYAML)。

この cinder-cfg.py スクリプト は、デフォルトで現在のディレクトリーから cinder.conf ファイルを読み取り (--config オプションが使用されている場合を除く)、ファイルを現在のディレクトリーに出力します (--out-dir オプションが使用されている場合を除く)。

出力ディレクトリーには、OpenStackControlPlane CR に適用する Cinder 固有の設定パッチを含む cinder.patch ファイルが置かれますが、いくつかの Secrets および MachineConfigs を含む cinder-prereq.yaml ファイルという追加ファイルも置かれる場合があります。

Ceph バックエンドのデフォルトに明示的に入出力を設定する呼び出しの例:

$ python cinder-cfg.py --config cinder.conf --out-dir ./
WARNING:root:Cinder is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the podified cinder services using "extraMounts" or remove the option.

WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a asecret and then use the extra volumes to make them available in all the services that would need them.

WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred in this case ['cinder']. Dropping that configuration.

WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!!

Output written at ./: cinder.patch

このスクリプトはいくつかの警告を出力して、手動で実行する必要がある事柄 (カスタムポリシーの追加や Ceph 設定ファイルの提供など)や、service_user の削除方法の変更を知らせます。

複数のバックエンドを使用する (そのうちの 1 つが 3PAR FC) の場合は、次の例のようになります。

$ python cinder-cfg.py --config cinder.conf --out-dir ./
WARNING:root:Cinder is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the podified cinder services using "extraMounts" or remove the option.

ERROR:root:Backend hpe_fc requires a vendor container image, but there is no certified image available yet. Patch will use the last known image for reference, but IT WILL NOT WORK

WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a asecret and then use the extra volumes to make them available in all the services that would need them.

WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred, in this case ['cinder']. Dropping that configuration.

WARNING:root:Configuration is using FC, please ensure all your OpenShift nodes have HBAs or use labels to ensure that Volume and Backup services are scheduled on nodes with HBAs.

WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!!

Output written at ./: cinder.patch, cinder-prereq.yaml

この場合、追加のメッセージがあります。以下に、それぞれの説明をリストしています。

  • 1 つのメッセージは、そのバックエンドドライバーに外部ベンダーの依存関係が必要であり、標準のコンテナーイメージは機能しないことを示します。残念ながら、このイメージはまだ利用できないため、参照用に出力パッチファイルで古いイメージを使用しています。このイメージは、後で使用可能になった時点で、自分でビルドしたイメージや Red Hat 公式イメージに置き換えることができます。その場合は、cinder.patch ファイルで確認できます。

          cinderVolumes:
          hpe-fc:
            containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0
  • FC メッセージは、そのトランスポートプロトコルでは、cinder サービスが実行されているノード上に特定の HBA カードが存在する必要があることを通知します。
  • その場合は cinder-prereq.yaml ファイルが作成されており、そのファイル内に MachineConfigSecret が 1 つずつあります。MachineConfig99-master-cinder-enable-multipathd と呼ばれ、名前が示すとおりすべての OCP ワーカーノードでマルチパス構成を有効にします。Secretopenstackcinder-volumes-hpe_fc と呼ばれ、機密情報 (認証情報) が含まれることから 3PAR バックエンド設定が含まれています。cinder.patch ファイルは次の設定を使用します。

       cinderVolumes:
          hpe-fc:
            customServiceConfigSecrets:
            - openstackcinder-volumes-hpe_fc

1.13.8. 手順 - Cinder の導入

cinder サービスの停止、OpenShift ノードの準備、OpenStack Operator とベア OpenStack マニフェストのデプロイ、データベースの移行、Cinder サービス設定を使用したパッチマニフェストの準備が完了していると仮定すると、パッチを適用し、Operator が変更を適用して Cinder サービスをデプロイするまで待機します。

パッチマニフェストをファイルに書き込み (例: cinder.patch)、それを次のように適用することが推奨されます。

oc patch openstackcontrolplane openstack --type=merge --patch-file=cinder.patch

たとえば開発ガイドの RBD デプロイメントの場合、cinder.patch は次のようになります。

spec:
  extraMounts:
  - extraVol:
    - extraVolType: Ceph
      mounts:
      - mountPath: /etc/ceph
        name: ceph
        readOnly: true
      propagation:
      - CinderVolume
      - CinderBackup
      - Glance
      volumes:
      - name: ceph
        projected:
          sources:
          - secret:
              name: ceph-conf-files
  cinder:
    enabled: true
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      cinderAPI:
        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: 1
        customServiceConfig: |
          [DEFAULT]
          default_volume_type=tripleo
      cinderScheduler:
        replicas: 1
      cinderBackup:
        networkAttachments:
        - storage
        replicas: 1
        customServiceConfig: |
          [DEFAULT]
          backup_driver=cinder.backup.drivers.ceph.CephBackupDriver
          backup_ceph_conf=/etc/ceph/ceph.conf
          backup_ceph_user=openstack
          backup_ceph_pool=backups
      cinderVolumes:
        ceph:
          networkAttachments:
          - storage
          replicas: 1
          customServiceConfig: |
            [tripleo_ceph]
            backend_host=hostgroup
            volume_backend_name=tripleo_ceph
            volume_driver=cinder.volume.drivers.rbd.RBDDriver
            rbd_ceph_conf=/etc/ceph/ceph.conf
            rbd_user=openstack
            rbd_pool=volumes
            rbd_flatten_volume_from_snapshot=False
            report_discard_supported=True

サービスがデプロイされると、古いスケジューラーとバックアップサービスを削除する必要があります。これらは停止していることが示され、その他は起動していることが示されます。

openstack volume service list

+------------------+------------------------+------+---------+-------+----------------------------+
| Binary           | Host                   | Zone | Status  | State | Updated At                 |
+------------------+------------------------+------+---------+-------+----------------------------+
| cinder-backup    | standalone.localdomain | nova | enabled | down  | 2023-06-28T11:00:59.000000 |
| cinder-scheduler | standalone.localdomain | nova | enabled | down  | 2023-06-28T11:00:29.000000 |
| cinder-volume    | hostgroup@tripleo_ceph | nova | enabled | up    | 2023-06-28T17:00:03.000000 |
| cinder-scheduler | cinder-scheduler-0     | nova | enabled | up    | 2023-06-28T17:00:02.000000 |
| cinder-backup    | cinder-backup-0        | nova | enabled | up    | 2023-06-28T17:00:01.000000 |
+------------------+------------------------+------+---------+-------+----------------------------+

この場合、ホスト standalone.localdomain のサービスを削除する必要があります。

oc exec -it cinder-scheduler-0 -- cinder-manage service remove cinder-backup standalone.localdomain
oc exec -it cinder-scheduler-0 -- cinder-manage service remove cinder-scheduler standalone.localdomain

現在はレプリカが 1 つあるため行っていませんが、この機会に Active-Active をサポートするようめに設定を変更したため、バックアップサービスの名前は残していません。

これで Cinder サービスが実行され、DB スキーマの移行が完了したため、DB データ移行の適用に進むことができます。データ移行は次のアップグレード前に実行できるため、必ずしもこのタイミングでデータを移行する必要はありませんが、導入の場合はこのタイミングで行うことが最適です。そうすることで、デプロイメント上で実稼働ワークロードを実行する前に問題がないか確認できます。

DB データ移行は、次のコマンドで実行できます。

oc exec -it cinder-scheduler-0 -- cinder-manage db online_data_migrations

1.13.9. 事後チェック

チェックを実行する前に、openstack コマンドが OpenShift コントロールプレーンに接続できるように、適切なクラウド設定を行う必要があります。

openstack エイリアスが定義されていることを確認します。

alias openstack="oc exec -t openstackclient -- openstack"

これで、一連のテストを実行して、古いデータベースの内容がデプロイメントで使用されていることを確認できます。

  • Cinder エンドポイントが定義され、Pod 化された FQDN を指していることを確認します。

    openstack endpoint list --service cinderv3
  • cinder サービスが実行されていることを確認します。API は表示されませんが、応答があれば API が起動していると判断できます。

    openstack volume service list
  • 古いボリュームタイプ、ボリューム、スナップショット、バックアップが存在することを確認します。

    openstack volume type list
    openstack volume list
    openstack volume snapshot list
    openstack volume backup list

設定が機能していることを確認するには、次の基本操作が推奨されます。

  • イメージからボリュームを作成して、glance への接続が機能していることを確認します。

    openstack volume create --image cirros --bootable --size 1 disk_new
  • 接続されている古いボリュームを新しいバックアップにバックアップします。以下に例を示します。

    openstack --os-volume-api-version 3.47 volume create --backup backup restored

nova と cinder はまだ接続されていないため、イメージから新しいボリュームを使用して nova インスタンスを起動したり、古いボリュームの接続解除を試みることはしません。

1.14. OpenStack ダッシュボードの導入

1.14.1. 前提条件

  • 前の導入手順を完了している。特に、Memcached と keystone はすでに導入されている必要があります。

1.14.2. 変数

(現時点で必要なシェル変数はありません。)

1.14.3. 手順 - Horizon の導入

  • OpenStackControlPlane にパッチを適用して Horizon をデプロイします。

    oc patch openstackcontrolplane openstack --type=merge --patch '
    spec:
      horizon:
        enabled: true
        apiOverride:
          route: {}
        template:
          memcachedInstance: memcached
          secret: osp-secret
    '

1.14.4. 事後チェック

  • Horizon インスタンスが正常にデプロイされ、準備が完了していることを確認します。
oc get horizon
  • ダッシュボードにアクセスでき、ステータスコード 200 が返されることを確認します。
PUBLIC_URL=$(oc get horizon horizon -o jsonpath='{.status.endpoint}')
curl --silent --output /dev/stderr --head --write-out "%{http_code}" "$PUBLIC_URL/dashboard/auth/login/?next=/dashboard/" | grep 200

1.15. Shared File Systems サービスの導入

OpenStack Manila は、Shared File Systems サービスです。OpenStack ユーザーに、ファイル共有を作成および管理するためのセルフサービス API を提供します。ファイル共有 (または単に "共有") は、任意の数のクライアントによる同時読み取り/書き込みアクセスのためにビルドされます。これとm基盤となるストレージが本質的に持つ弾力性と組み合わさることで、Shared File Systems サービスは RWX ("read write many") 永続ストレージを必要とするクラウド環境において欠かせないサービスになっています。

1.15.1. ネットワーク

OpenStack のファイル共有は、ネットワーク経由で直接アクセスされます。したがって、共有ファイルシステム用の正常かつ持続可能なオーケストレーションレイヤーを作成するためには、クラウドのネットワーキングを計画することが不可欠です

Manila がサポートするストレージネットワークの抽象概念には 2 つのレベルがあります。1 つはユーザーがそれぞれのファイル共有のネットワークを直接制御するレベルで、もう 1 つは OpenStack 管理者がストレージネットワークを設定するレベルです。ここで重要なのは、Red Hat OpenStack Platform 17.1 のネットワークが、導入後の新しいクラウドのネットワークプランと一致していることです。これが一致することで、コントロールプレーンで軽度の中断が発生した場合でも、テナントワークロードは導入プロセスを通じてストレージとの接続を維持できます。Manila のコントロールプレーンサービスは、データパスにありません。また、API、スケジューラー、共有マネージャーサービスをシャットダウンしても、既存の共有ファイルシステムへのアクセスには影響しません。

通常、ストレージとストレージデバイス管理ネットワークは分離されています。Manila サービスには、ストレージデバイス管理ネットワークへのアクセスのみ必要です。たとえば、デプロイメントで Ceph クラスターが使用された場合、"ストレージ" ネットワークは Ceph クラスターのパブリックネットワークを指し、Manila の共有マネージャーサービスはそれにアクセスできる必要があります。

1.15.2. 前提条件

  • manila systemd サービス (api、cron、スケジューラー) が停止していることを確認する。詳細は、OpenStack サービスを停止する を参照してください。
  • manila pacemaker サービス (("openstack-manila-share") が停止していることを確認する。詳細は、OpenStack サービスを停止する を参照してください。
  • データベースの移行が完了していることを確認する。詳細は、データベースを MariaDB インスタンスに移行する を参照してください。
  • manila-share サービスがデプロイされる予定の OpenShift ノードが、ストレージシステムが配置されている管理ネットワークにアクセスできることを確認する。
  • manila サービスを導入する前に、keystone や memcached などのサービスが利用可能であることを確認する。
  • テナントドリブンネットワーキングが有効 (driver_handles_share_servers=True) になっている場合、manila サービスを導入する前に neutron がデプロイされていることを確認する。

1.15.3. 手順 - Manila の導入

1.15.3.1. RHOSP 17.1 デプロイメントから設定をコピーする

CONTROLLER1_SSH 環境変数が 未定義 の場合、それを定義します。次に、参照用に RHOSP 17.1 から設定ファイルをコピーします。

$CONTROLLER1_SSH cat /var/lib/config-data/puppet-generated/manila/etc/manila/manila.conf | awk '!/^ *#/ && NF' > ~/manila.conf

RHOSP 17.1 以降に記録された設定変更と併せて、この設定を確認します。すべてを新しいクラウド環境に導入する必要はありません。

  • manila Operator は、データベース関連の設定 ([database])、サービス認証 (auth_strategy[keystone_authtoken])、メッセージバス設定 (transport_urlcontrol_exchange)、デフォルトペースト設定 (api_paste_config)、サービス間通信設定 (` , `[nova][cinder][glance] [oslo_messaging_*]) をセットアップできます。つまり、これらはすべて無視できます。
  • osapi_share_listen 設定は無視します。RHOSP 18 では、OpenShift のルートと ingress に依存します。
  • ポリシーのオーバーライドに注意してください。RHOSP 18 では、manila にはセキュアなデフォルト RBAC が同梱されており、オーバーライドは必要ない可能性があります。Oslo ポリシージェネレーター ツールを使用して、RBAC のデフォルトを確認してください。カスタムポリシーが必要な場合は、それを ConfigMap として指定する必要があります。次の仕様サンプルは、manila-policy という ConfigMappolicy.yaml というファイルの内容を使用して設定する方法を示しています。
  spec:
    manila:
      enabled: true
      template:
        manilaAPI:
          customServiceConfig: |
             [oslo_policy]
             policy_file=/etc/manila/policy.yaml
        extraMounts:
        - extraVol:
          - extraVolType: Undefined
            mounts:
            - mountPath: /etc/manila/
              name: policy
              readOnly: true
            propagation:
            - ManilaAPI
            volumes:
            - name: policy
              projected:
                sources:
                - configMap:
                    name: manila-policy
                    items:
                      - key: policy
                        path: policy.yaml
  • Manila API サービスの場合、manila: template: manilaAPIcustomServiceConfig セクションに enabled_share_protocols オプションを追加する必要があります。
  • スケジューラーのオーバーライドがある場合は、それを manila: template: manilaSchedulercustomServiceConfig セクションに追加します。
  • RHOSP 17.1 で複数のストレージバックエンドドライバーが設定されている場合は、RHOSP 18 のデプロイ時にそれらを分割する必要があります。各ストレージバックエンドドライバーは、manila-share サービスの独自インスタンスを使用する必要があります。
  • ストレージバックエンドドライバーにカスタムコンテナーイメージが必要な場合は、RHOSP エコシステムカタログ で検索し、manila: template: manilaShares: <custom name> : containerImage 値を設定します。次の例は、カスタムコンテナーイメージを使用する複数のストレージバックエンドドライバーを示しています。
  spec:
    manila:
      enabled: true
      template:
        manilaAPI:
          customServiceConfig: |
            [DEFAULT]
            enabled_share_protocols = nfs
          replicas: 3
        manilaScheduler:
          replicas: 3
        manilaShares:
         netapp:
           customServiceConfig: |
             [DEFAULT]
             debug = true
             enabled_share_backends = netapp
             [netapp]
             driver_handles_share_servers = False
             share_backend_name = netapp
             share_driver = manila.share.drivers.netapp.common.NetAppDriver
             netapp_storage_family = ontap_cluster
             netapp_transport_type = http
           replicas: 1
         pure:
            customServiceConfig: |
             [DEFAULT]
             debug = true
             enabled_share_backends=pure-1
             [pure-1]
             driver_handles_share_servers = False
             share_backend_name = pure-1
             share_driver = manila.share.drivers.purestorage.flashblade.FlashBladeShareDriver
             flashblade_mgmt_vip = 203.0.113.15
             flashblade_data_vip = 203.0.10.14
            containerImage: registry.connect.redhat.com/purestorage/openstack-manila-share-pure-rhosp-18-0
            replicas: 1
  • パスワード、ホスト名、ユーザー名などの機密情報を指定する場合は、OpenShift シークレットと customServiceConfigSecrets キーの使用が推奨されます。以下に例を示します。
cat << __EOF__ > ~/netapp_secrets.conf

[netapp]
netapp_server_hostname = 203.0.113.10
netapp_login = fancy_netapp_user
netapp_password = secret_netapp_password
netapp_vserver = mydatavserver
__EOF__

oc create secret generic osp-secret-manila-netapp --from-file=~/netapp_secrets.conf -n openstack
  • customConfigSecrets は、任意のサービスで使用できます。以下は、上記で作成したシークレットを使用した設定例です。
  spec:
    manila:
      enabled: true
      template:
        < . . . >
        manilaShares:
         netapp:
           customServiceConfig: |
             [DEFAULT]
             debug = true
             enabled_share_backends = netapp
             [netapp]
             driver_handles_share_servers = False
             share_backend_name = netapp
             share_driver = manila.share.drivers.netapp.common.NetAppDriver
             netapp_storage_family = ontap_cluster
             netapp_transport_type = http
           customServiceConfigSecrets:
             - osp-secret-manila-netapp
           replicas: 1
    < . . . >
  • いずれかのサービスに追加のファイルを指定する必要がある場合は、extraMounts を使用できます。たとえば ceph を使用する場合は、Manila の ceph ユーザーのキーリングファイルと、利用可能な ceph.conf 設定ファイルが必要です。これらは、以下の例のように extraMounts を使用してマウントされます。
  • RHOSP 17.1 の場合と同様に、バックエンドの名前 (share_backend_name) が残ることを確認します。
  • manilaAPI サービスと manilaScheduler サービスのレプリカ数を 3 に設定することが推奨されます。manilaShares サービスのレプリカ数は、1 に設定する必要があります。
  • manilaShares セクションで、適切なストレージ管理ネットワークが指定されていることを確認します。次の例では、CephFS バックエンドドライバーを備えた manilaShares インスタンスを storage ネットワークに接続します。
1.15.3.2. manila コントロールプレーンをデプロイする

OpenStackControlPlane にパッチを適用して Manila をデプロイします。以下は、ネイティブ CephFS を使用する例です。

cat << __EOF__ > ~/manila.patch
spec:
  manila:
    enabled: true
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      manilaAPI:
        replicas: 3
        customServiceConfig: |
          [DEFAULT]
          enabled_share_protocols = cephfs
        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
      manilaScheduler:
        replicas: 3
      manilaShares:
        cephfs:
          replicas: 1
          customServiceConfig: |
            [DEFAULT]
            enabled_share_backends = tripleo_ceph
            [tripleo_ceph]
            driver_handles_share_servers=False
            share_backend_name=tripleo_ceph
            share_driver=manila.share.drivers.cephfs.driver.CephFSDriver
            cephfs_conf_path=/etc/ceph/ceph.conf
            cephfs_auth_id=openstack
            cephfs_cluster_name=ceph
            cephfs_volume_mode=0755
            cephfs_protocol_helper_type=CEPHFS
          networkAttachments:
              - storage
__EOF__
oc patch openstackcontrolplane openstack --type=merge --patch-file=~/manila.patch

1.15.4. 事後チェック

1.15.4.1. 結果として得られる manila サービス Pod を検査する
oc get pods -l service=manila
1.15.4.2. Manila API サービスが Keystone に登録されていることを確認する
openstack service list | grep manila
openstack endpoint list | grep manila

| 1164c70045d34b959e889846f9959c0e | regionOne | manila       | share        | True    | internal  | http://manila-internal.openstack.svc:8786/v1/%(project_id)s        |
| 63e89296522d4b28a9af56586641590c | regionOne | manilav2     | sharev2      | True    | public    | https://manila-public-openstack.apps-crc.testing/v2                |
| af36c57adcdf4d50b10f484b616764cc | regionOne | manila       | share        | True    | public    | https://manila-public-openstack.apps-crc.testing/v1/%(project_id)s |
| d655b4390d7544a29ce4ea356cc2b547 | regionOne | manilav2     | sharev2      | True    | internal  | http://manila-internal.openstack.svc:8786/v2                       |
1.15.4.3. リソースを検証する

サービスの健全性をテストします。

openstack share service list
openstack share pool list --detail

既存のワークロードを確認します。

openstack share list
openstack share snapshot list

さらにリソースを作成できます。

openstack share create cephfs 10 --snapshot mysharesnap --name myshareclone

1.16. Bare Metal Provisioning サービスの導入

1.16.1. 前提条件

  • 前の導入手順を完了している。特に、サービスデータベースが Pod 化された MariaDB にインポートされている必要があります。

1.16.2. 変数

現時点で必要なシェル変数はありません。

1.17. Heat の導入

Heat を導入するということは、Heat が無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。

導入プロセスが完了すると、ユーザーは HeatHeatAPIHeatEngine、および HeatCFNAPI の CR を取得しています。さらに、Keystone 内にエンドポイントが作成されているはずです。これにより、上記のサービスが容易になります。

このガイドでは、以下も前提としています。

  1. TripleO 環境 (ソースクラウド) が片側で実行されている。
  2. OpenShift 環境は反対側で実行されています。

1.17.1. 前提条件

  • 前の導入手順を完了している。特に、MariaDB と Keystone が導入されている必要があります。
  • 既存の Heat スタックに、Neutron、Nova、Swift などの他のサービスのリソースが含まれている場合があります。Heat を導入する前に、これらのサービスを導入する必要があります。

1.17.2. 手順 - Heat の導入

Heat の導入でも、Keystone と同じパターンを実行します。

osp-secret にパッチを適用して、HeatAuthEncryptionKeyHeatPassword を更新します。これは、既存の TripleO Heat 設定と一致する必要があります。

以下を実行して、既存の auth_encryption_keyservice パスワードを取得し、検証できます。

[stack@rhosp17 ~]$ grep -E 'HeatPassword|HeatAuth' ~/overcloud-deploy/overcloud/overcloud-passwords.yaml
  HeatAuthEncryptionKey: Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2
  HeatPassword: dU2N0Vr2bdelYH7eQonAwPfI3

コントローラーの 1 つで、これが実際に使用されている値であることを確認します。

[stack@rhosp17 ~]$ ansible -i overcloud-deploy/overcloud/config-download/overcloud/tripleo-ansible-inventory.yaml overcloud-controller-0 -m shell -a "grep auth_encryption_key /var/lib/config-data/puppet-generated/heat/etc/heat/heat.conf | grep -Ev '^#|^$'" -b
overcloud-controller-0 | CHANGED | rc=0 >>
auth_encryption_key=Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2

このパスワードは base64 でエンコードし、osp-secret に追加する必要があります。

❯ echo Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2 | base64
UTYwSGo4UHFickROdTJkRENieUlRRTJkaWJwUVVQZzIK

❯ oc patch secret osp-secret --type='json' -p='[{"op" : "replace" ,"path" : "/data/HeatAuthEncryptionKey" ,"value" : "UTYwSGo4UHFickROdTJkRENieUlRRTJkaWJwUVVQZzIK"}]'
secret/osp-secret patched

OpenStackControlPlane にパッチを適用して Heat をデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch '
spec:
  heat:
    enabled: true
    apiOverride:
      route: {}
    template:
      databaseInstance: openstack
      secret: osp-secret
      memcachedInstance: memcached
      passwordSelectors:
        authEncryptionKey: HeatAuthEncryptionKey
        database: HeatDatabasePassword
        service: HeatPassword
'

1.17.3. 事後チェック

すべての CR が "Setup Complete" の状態であることを確認します。

❯ oc get Heat,HeatAPI,HeatEngine,HeatCFNAPI
NAME                           STATUS   MESSAGE
heat.heat.openstack.org/heat   True     Setup complete

NAME                                  STATUS   MESSAGE
heatapi.heat.openstack.org/heat-api   True     Setup complete

NAME                                        STATUS   MESSAGE
heatengine.heat.openstack.org/heat-engine   True     Setup complete

NAME                                        STATUS   MESSAGE
heatcfnapi.heat.openstack.org/heat-cfnapi   True     Setup complete
1.17.3.1. Heat サービスが Keystone に登録されていることを確認する
 oc exec -it openstackclient -- openstack service list -c Name -c Type
+------------+----------------+
| Name       | Type           |
+------------+----------------+
| heat       | orchestration  |
| glance     | image          |
| heat-cfn   | cloudformation |
| ceilometer | Ceilometer     |
| keystone   | identity       |
| placement  | placement      |
| cinderv3   | volumev3       |
| nova       | compute        |
| neutron    | network        |
+------------+----------------+
❯ oc exec -it openstackclient -- openstack endpoint list --service=heat -f yaml
- Enabled: true
  ID: 1da7df5b25b94d1cae85e3ad736b25a5
  Interface: public
  Region: regionOne
  Service Name: heat
  Service Type: orchestration
  URL: http://heat-api-public-openstack-operators.apps.okd.bne-shift.net/v1/%(tenant_id)s
- Enabled: true
  ID: 414dd03d8e9d462988113ea0e3a330b0
  Interface: internal
  Region: regionOne
  Service Name: heat
  Service Type: orchestration
  URL: http://heat-api-internal.openstack-operators.svc:8004/v1/%(tenant_id)s
1.17.3.2. Heat エンジンサービスが稼働していることを確認する
 oc exec -it openstackclient -- openstack orchestration service list -f yaml
- Binary: heat-engine
  Engine ID: b16ad899-815a-4b0c-9f2e-e6d9c74aa200
  Host: heat-engine-6d47856868-p7pzz
  Hostname: heat-engine-6d47856868-p7pzz
  Status: up
  Topic: engine
  Updated At: '2023-10-11T21:48:01.000000'
- Binary: heat-engine
  Engine ID: 887ed392-0799-4310-b95c-ac2d3e6f965f
  Host: heat-engine-6d47856868-p7pzz
  Hostname: heat-engine-6d47856868-p7pzz
  Status: up
  Topic: engine
  Updated At: '2023-10-11T21:48:00.000000'
- Binary: heat-engine
  Engine ID: 26ed9668-b3f2-48aa-92e8-2862252485ea
  Host: heat-engine-6d47856868-p7pzz
  Hostname: heat-engine-6d47856868-p7pzz
  Status: up
  Topic: engine
  Updated At: '2023-10-11T21:48:00.000000'
- Binary: heat-engine
  Engine ID: 1011943b-9fea-4f53-b543-d841297245fd
  Host: heat-engine-6d47856868-p7pzz
  Hostname: heat-engine-6d47856868-p7pzz
  Status: up
  Topic: engine
  Updated At: '2023-10-11T21:48:01.000000'
1.17.3.3. Heat スタックが再び表示されることを確認する

ネットワーク、サブネット、ポート、またはルーターを作成できるかテストします。

❯ openstack stack list -f yaml
- Creation Time: '2023-10-11T22:03:20Z'
  ID: 20f95925-7443-49cb-9561-a1ab736749ba
  Project: 4eacd0d1cab04427bc315805c28e66c9
  Stack Name: test-networks
  Stack Status: CREATE_COMPLETE
  Updated Time: null

1.18. Telemetry サービスの導入

Telemetry を導入するということは、Telemetry サービスが無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。

このガイドでは、以下も前提としています。

  1. TripleO 環境 (ソースクラウド) が片側で実行されている。
  2. SNO/CodeReadyContainers が反対側で実行されている。

1.18.1. 前提条件

  • 前の導入手順を完了している。MariaDB、Keystone、EDPM は導入済みのはずです。

1.18.2. 手順 - Telemetry の導入

OpenStackControlPlane にパッチを適用して Ceilometer サービスをデプロイします。

cat << EOF > ceilometer_patch.yaml
spec:
  ceilometer:
    enabled: true
    template:
      customServiceConfig: |
        [DEFAULT]
        debug=true
      secret: osp-secret
EOF

OpenStackControlPlane にパッチを適用して Ceilometer サービスをデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch-file ceilometer_patch.yaml

1.18.3. 事後チェック

1.18.3.1. 結果として得られる Ceilometer Pod を検査する
CEILOMETETR_POD=`oc get pods -l service=ceilometer | tail -n 1 | cut -f 1 -d' '`
oc exec -t $CEILOMETETR_POD -c ceilometer-central-agent -- cat /etc/ceilometer/ceilometer.conf
podman ps | grep ceilometer-ipmi
1.18.3.3. 有効なポールスターを検査する
oc get secret ceilometer-config-data -o jsonpath="{.data['polling\.yaml']}"  | base64 -d
1.18.3.4. 要件に応じてポールスターを有効にする
cat << EOF > polling.yaml
---
sources:
    - name: pollsters
      interval: 300
      meters:
        - volume.size
        - image.size
        - cpu
        - memory
EOF

oc patch secret ceilometer-config-data  --patch="{\"data\": { \"polling.yaml\": \"$(base64 -w0 polling.yaml)\"}}"

1.19. 自動スケーリングの導入

自動スケーリングを導入するということは、Aodh サービスが無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。

このガイドでは、以下も前提としています。

  1. TripleO 環境 (ソースクラウド) が片側で実行されている。
  2. SNO/CodeReadyContainers が反対側で実行されている。

1.19.1. 前提条件

  • 前の導入手順を完了している。MariaDB、Keystone、Heat、Telemetry は導入済みのはずです。

1.19.2. 手順 - 自動スケーリングの導入

OpenStackControlPlane にパッチを適用して自動スケーリングサービスをデプロイします。

cat << EOF > aodh_patch.yaml
spec:
  autoscaling:
    enabled: true
    prometheus:
      deployPrometheus: false
    aodh:
      customServiceConfig: |
        [DEFAULT]
        debug=true
      secret: osp-secret
      passwordSelectors:
      databaseUser: aodh
      databaseInstance: openstack
      memcachedInstance: memcached
EOF

OpenStackControlPlane にパッチを適用して Aodh サービスをデプロイします。

oc patch openstackcontrolplane openstack --type=merge --patch-file aodh_patch.yaml

1.19.3. 事後チェック

1.19.3.1. 自動スケーリングサービスが有効になっている場合は Aodh Pod を検査する
AODH_POD=`oc get pods -l service=aodh | tail -n 1 | cut -f 1 -d' '`
oc exec -t $AODH_POD -c aodh-api -- cat /etc/aodh/aodh.conf
1.19.3.2. Aodh API サービスが Keystone に登録されているか確認する
openstack endpoint list | grep aodh
| 6a805bd6c9f54658ad2f24e5a0ae0ab6 | regionOne | aodh      | network      | True    | public    | http://aodh-public-openstack.apps-crc.testing  |
| b943243e596847a9a317c8ce1800fa98 | regionOne | aodh      | network      | True    | internal  | http://aodh-internal.openstack.svc:9696        |
| f97f2b8f7559476bb7a5eafe3d33cee7 | regionOne | aodh      | network      | True    | admin     | http://192.168.122.99:9696                     |
1.19.3.3. サンプルリソースを作成する

アラームを作成できるかテストできます。

openstack alarm create \
--name low_alarm \
--type gnocchi_resources_threshold \
--metric cpu \
--resource-id b7ac84e4-b5ca-4f9e-a15c-ece7aaf68987 \
--threshold 35000000000 \
--comparison-operator lt \
--aggregation-method rate:mean \
--granularity 300 \
--evaluation-periods 3 \
--alarm-action 'log:\\' \
--ok-action 'log:\\' \
--resource-type instance

1.20. インフラストラクチャー管理と Compute サービスを停止する

EDPM の導入を開始する前に、ソースクラウド上の Compute、libvirt、ロードバランシング、メッセージング、およびデータベースのサービスを必ず停止します。Compute ホスト上のモジュラー libvirt デーモンのリポジトリーも無効にする必要があります。

この手順の後、ソースクラウドのコントロールプレーンを廃止できます。これにより、クラウドコントローラー、データベース、メッセージングノードのみが停止されます。引き続き機能する必要があるノードは、コンピュート、ストレージ、またはネットワーカーのロールを実行しているノードです (Tripleo Heat テンプレートでカバーされる設定可能なロールの場合)。

1.20.1. 変数

以下の手順で使用するシェル変数を定義します。コンピュートノード名、IP ペアのマップを定義します。ここで示す値はサンプルであり、シングルノードのスタンドアロンディレクターデプロイメントを参照しています。ご使用の環境に適した値を使用してください。

EDPM_PRIVATEKEY_PATH="~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa"
declare -A computes
computes=(
  ["standalone.localdomain"]="192.168.122.100"
  # ...
)

ssh コマンドのこれらの ssh 変数は、実行場所に依存しない命令を作成するために、ansible の代わりに使用されます。ただし、適切なホストにいる場合は、Ansible コマンドを使用して同じ結果を得ることができます (例: サービスを停止する)。

. stackrc
ansible -i $(which tripleo-ansible-inventory) Compute -m shell -a "sudo systemctl stop tripleo_virtqemud.service" -b

1.20.2. 残りのサービスを停止する

すべてのコンピュートホストから、競合するリポジトリーとパッケージ (スタンドアロン TripleO を使用する開発セットアップの場合) を削除します。それらのホストが External DataPlane Managed (EDPM) ノードとして導入され、モジュラー libvirt デーモンが podman コンテナーで稼働しなくなった場合に、libvirt パッケージをインストールするためにこれが必要になります。

これらの手順は、前に定義した環境変数と関数に依存する Simple スクリプトを使用して自動化できます。

ComputeServicesToStop=(
                "tripleo_nova_compute.service"
                "tripleo_nova_libvirt.target"
                "tripleo_nova_migration_target.service"
                "tripleo_nova_virtlogd_wrapper.service"
                "tripleo_nova_virtnodedevd.service"
                "tripleo_nova_virtproxyd.service"
                "tripleo_nova_virtqemud.service"
                "tripleo_nova_virtsecretd.service"
                "tripleo_nova_virtstoraged.service")

PacemakerResourcesToStop=(
                "galera-bundle"
                "haproxy-bundle"
                "rabbitmq-bundle")

echo "Disabling systemd units and cleaning up for compute services"
for i in "${!computes[@]}"; do
    SSH_CMD="ssh -i $EDPM_PRIVATEKEY_PATH root@${computes[$i]}"
    for service in ${ComputeServicesToStop[*]}; do
        echo "Stopping the $service in compute $i"
        if ${SSH_CMD} sudo systemctl is-active $service; then
            ${SSH_CMD} sudo systemctl disable --now $service
            ${SSH_CMD} test -f /etc/systemd/system/$service '||' sudo systemctl mask $service
        fi
    done
done

echo "Stopping pacemaker services"
for i in {1..3}; do
    SSH_CMD=CONTROLLER${i}_SSH
    if [ ! -z "${!SSH_CMD}" ]; then
        echo "Using controller $i to run pacemaker commands"
        for resource in ${PacemakerResourcesToStop[*]}; do
            if ${!SSH_CMD} sudo pcs resource config $resource; then
                ${!SSH_CMD} sudo pcs resource disable $resource
            fi
        done
        break
    fi
done

1.21. EDPM の導入

1.21.1. 前提条件

警告 この手順は、EDPM 導入手順における "復帰不能点" です。EDPM がデプロイされ、Pod 化されたコントロールプレーンがそれを制御するようになった後は、ソースコントロールプレーンとデータプレーンサービスを再度有効にしないでください。

1.21.2. 変数

以下の Fast-forward アップグレード手順で使用するシェル変数を定義します。FIP を、ソースクラウドで事前に作成した test 仮想マシンの Floating IP アドレスに設定します。コンピュートノード名、IP ペアのマップを定義します。値はサンプルです。環境に適した値を使用してください。

PODIFIED_DB_ROOT_PASSWORD=$(oc get -o json secret/osp-secret | jq -r .data.DbRootPassword | base64 -d)

alias openstack="oc exec -t openstackclient -- openstack"
FIP=192.168.122.20
declare -A computes
export computes=(
  ["standalone.localdomain"]="192.168.122.100"
  # ...
)

1.21.3. 事前チェック

  • IPAM が設定されていることを確認します。
oc apply -f - <<EOF
apiVersion: network.openstack.org/v1beta1
kind: NetConfig
metadata:
  name: netconfig
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
      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: StorageMgmt
    dnsDomain: storagemgmt.example.com
    subnets:
    - name: subnet1
      allocationRanges:
      - end: 172.20.0.250
        start: 172.20.0.100
      cidr: 172.20.0.0/24
      vlan: 23
  - 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
EOF

1.21.4. 手順 - EDPM の導入

  • OSP 17 への、ステーブルコンピュート UUID 機能のバックポート が導入されるまでの 一時的な修正 です。

    各コンピュートノードでは、コンピュートサービスの UUID を取得し、それを /var/lib/nova/ ディレクトリーのステーブル compute_id ファイルに書き込みます。

    for name in "${!computes[@]}";
    do
      uuid=$(\
        openstack hypervisor show $name \
        -f value -c 'id'\
      )
      echo "Writing $uuid to /var/lib/nova/compute_id on $name"
      ssh \
        -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa \
        root@"${computes[$name]}" \
        "echo $uuid > /var/lib/nova/compute_id"
    done
  • EDPM ノードの ssh 認証シークレット を作成します。

    oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
        name: dataplane-adoption-secret
        namespace: openstack
    data:
        ssh-privatekey: |
    $(cat ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa | base64 | sed 's/^/        /')
    EOF
  • ssh キーペアの nova-migration-ssh-key シークレットを生成します。

    cd "$(mktemp -d)"
    ssh-keygen -f ./id -t ecdsa-sha2-nistp521 -N ''
    oc get secret nova-migration-ssh-key || oc create secret generic nova-migration-ssh-key \
      -n openstack \
      --from-file=ssh-privatekey=id \
      --from-file=ssh-publickey=id.pub \
      --type kubernetes.io/ssh-auth
    rm -f id*
    cd -
  • Nova Compute Extra Config サービスを作成します。

    oc apply -f - <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: nova-compute-extraconfig
      namespace: openstack
    data:
      19-nova-compute-cell1-workarounds.conf: |
        [workarounds]
        disable_compute_service_check_for_ffu=true
    ---
    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneService
    metadata:
      name: nova-compute-extraconfig
      namespace: openstack
    spec:
      label: nova.compute.extraconfig
      configMaps:
        - nova-compute-extraconfig
      secrets:
        - nova-cell1-compute-config
        - nova-migration-ssh-key
      playbook: osp.edpm.nova
    EOF

    シークレット nova-cell<X>-compute-config は、各 cell<X> に対して自動生成されます。このシークレットと nova-migration-ssh-key は、Nova に関連付けられた各カスタム OpenStackDataPlaneService で指定する必要があります。

  • OpenStackDataPlaneNodeSet をデプロイします。

    oc apply -f - <<EOF
    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneNodeSet
    metadata:
      name: openstack
    spec:
      networkAttachments:
          - ctlplane
      preProvisioned: true
      services:
        - bootstrap
        - download-cache
        - configure-network
        - validate-network
        - install-os
        - configure-os
        - run-os
        - libvirt
        - nova-compute-extraconfig
        - ovn
        - neutron-metadata
      env:
        - name: ANSIBLE_CALLBACKS_ENABLED
          value: "profile_tasks"
        - name: ANSIBLE_FORCE_COLOR
          value: "True"
      nodes:
        standalone:
          hostName: standalone
          ansible:
            ansibleHost: ${computes[standalone.localdomain]}
          networks:
          - defaultRoute: true
            fixedIP: ${computes[standalone.localdomain]}
            name: CtlPlane
            subnetName: subnet1
          - name: InternalApi
            subnetName: subnet1
          - name: Storage
            subnetName: subnet1
          - name: Tenant
            subnetName: subnet1
      nodeTemplate:
        ansibleSSHPrivateKeySecret: dataplane-adoption-secret
        managementNetwork: ctlplane
        ansible:
          ansibleUser: root
          ansiblePort: 22
          ansibleVars:
            service_net_map:
              nova_api_network: internal_api
              nova_libvirt_network: internal_api
    
            # edpm_network_config
            # Default nic config template for a EDPM compute node
            # These vars are edpm_network_config role vars
            edpm_network_config_override: ""
            edpm_network_config_template: |
               ---
               {% set mtu_list = [ctlplane_mtu] %}
               {% for network in role_networks %}
               {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
               {%- endfor %}
               {% set min_viable_mtu = mtu_list | max %}
               network_config:
               - type: ovs_bridge
                 name: {{ neutron_physical_bridge_name }}
                 mtu: {{ min_viable_mtu }}
                 use_dhcp: false
                 dns_servers: {{ ctlplane_dns_nameservers }}
                 domain: {{ dns_search_domains }}
                 addresses:
                 - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
                 routes: {{ ctlplane_host_routes }}
                 members:
                 - type: interface
                   name: nic1
                   mtu: {{ min_viable_mtu }}
                   # force the MAC address of the bridge to this interface
                   primary: true
               {% for network in role_networks %}
                 - type: vlan
                   mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
                   vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
                   addresses:
                   - ip_netmask:
                       {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
                   routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
               {% endfor %}
    
            edpm_network_config_hide_sensitive_logs: false
            #
            # These vars are for the network config templates themselves and are
            # considered EDPM network defaults.
            neutron_physical_bridge_name: br-ctlplane
            neutron_public_interface_name: eth0
            role_networks:
            - InternalApi
            - Storage
            - Tenant
            networks_lower:
              External: external
              InternalApi: internal_api
              Storage: storage
              Tenant: tenant
    
            # edpm_nodes_validation
            edpm_nodes_validation_validate_controllers_icmp: false
            edpm_nodes_validation_validate_gateway_icmp: false
    
            timesync_ntp_servers:
            - hostname: clock.redhat.com
            - hostname: clock2.redhat.com
    
    
            edpm_ovn_controller_agent_image: registry.redhat.io/rhosp-dev-preview/openstack-ovn-controller-rhel9:18.0
            edpm_iscsid_image: registry.redhat.io/rhosp-dev-preview/openstack-iscsid-rhel9:18.0
            edpm_logrotate_crond_image: registry.redhat.io/rhosp-dev-preview/openstack-cron-rhel9:18.0
            edpm_nova_compute_container_image: registry.redhat.io/rhosp-dev-preview/openstack-nova-compute-rhel9:18.0
            edpm_nova_libvirt_container_image: registry.redhat.io/rhosp-dev-preview/openstack-nova-libvirt-rhel9:18.0
            edpm_ovn_metadata_agent_image: registry.redhat.io/rhosp-dev-preview/openstack-neutron-metadata-agent-ovn-rhel9:18.0
    
            edpm_bootstrap_command: |
              subscription-manager register --username <subscription_manager_username> --password <subscription_manager_password>
              subscription-manager release --set=9.2
              subscription-manager repos --disable=*
              subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms --enable=openstack-dev-preview-for-rhel-9-x86_64-rpms
              podman login -u <registry_username> -p <registry_password> registry.redhat.io
    
            gather_facts: false
            enable_debug: false
            # edpm firewall, change the allowed CIDR if needed
            edpm_sshd_configure_firewall: true
            edpm_sshd_allowed_ranges: ['192.168.122.0/24']
            # SELinux module
            edpm_selinux_mode: enforcing
            plan: overcloud
    
            # Do not attempt OVS 3.2 major upgrades here
            edpm_ovs_packages:
            - openvswitch3.1
    EOF
  • OpenStackDataPlaneDeployment をデプロイします。

    oc apply -f - <<EOF
    apiVersion: dataplane.openstack.org/v1beta1
    kind: OpenStackDataPlaneDeployment
    metadata:
      name: openstack
    spec:
      nodeSets:
      - openstack
    EOF

1.21.5. 事後チェック

  • すべての Ansible EE Pod が Completed ステータスになっているか確認します。

      # watching the pods
      watch oc get pod -l app=openstackansibleee
      # following the ansible logs with:
      oc logs -l app=openstackansibleee -f --max-log-requests 10
  • データプレーンノードセットが Ready ステータスになるまで待機します。

      oc wait --for condition=Ready osdpns/openstack --timeout=30m

1.21.6. Nova compute サービスの Wallaby から Antelope への Fast-forward アップグレード

EDPM ansible と Kubernetes Operator によって個別に管理されるため、導入中は Nova サービスのローリングアップグレードは実行できません。Nova コントロールプレーンサービスとのロックステップがあります。Nova サービスの Operator と OpenStack データプレーンの Operator は、Nova サービスに対して [upgrade_levels]compute=auto を設定することで、アップグレードが相互に独立して実行されるようにします。Nova コントロールプレーンサービスは、CR にパッチが適用された直後に変更を適用します。Nova compute EDPM サービスは、後で ansible デプロイメントを使用して同じ設定変更をキャッチアップします。

注記: Nova compute EDPM サービスの FFU 回避策設定に関わる追加のオーケストレーションは、今後変更される可能性があります。

  • cell1 Nova compute EDPM サービスのバージョンが更新されるまで待機します (しばらく時間がかかる場合があります)。

      oc exec openstack-cell1-galera-0 -c galera -- mysql -rs -uroot -p$PODIFIED_DB_ROOT_PASSWORD \
          -e "select a.version from nova_cell1.services a join nova_cell1.services b where a.version!=b.version and a.binary='nova-compute';"

    上記のクエリーは、完了基準として空の結果を返す必要があります。

  • Nova コントロールプレーンサービスの FFU 前の回避策を削除します。

      oc patch openstackcontrolplane openstack -n openstack --type=merge --patch '
      spec:
        nova:
          template:
            cellTemplates:
              cell0:
                conductorServiceTemplate:
                  customServiceConfig: |
                    [workarounds]
                    disable_compute_service_check_for_ffu=false
              cell1:
                metadataServiceTemplate:
                  customServiceConfig: |
                    [workarounds]
                    disable_compute_service_check_for_ffu=false
                conductorServiceTemplate:
                  customServiceConfig: |
                    [workarounds]
                    disable_compute_service_check_for_ffu=false
            apiServiceTemplate:
              customServiceConfig: |
                [workarounds]
                disable_compute_service_check_for_ffu=false
            metadataServiceTemplate:
              customServiceConfig: |
                [workarounds]
                disable_compute_service_check_for_ffu=false
            schedulerServiceTemplate:
              customServiceConfig: |
                [workarounds]
                disable_compute_service_check_for_ffu=false
      '
  • Nova コントロールプレーンサービスの CR の準備が整うまで待機します。

      oc wait --for condition=Ready --timeout=300s Nova/nova
  • Nova compute EDPM サービスの FFU 前の回避策を削除します。

      oc apply -f - <<EOF
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: nova-compute-ffu
        namespace: openstack
      data:
        20-nova-compute-cell1-ffu-cleanup.conf: |
          [workarounds]
          disable_compute_service_check_for_ffu=false
      ---
      apiVersion: dataplane.openstack.org/v1beta1
      kind: OpenStackDataPlaneService
      metadata:
        name: nova-compute-ffu
        namespace: openstack
      spec:
        label: nova.compute.ffu
        configMaps:
          - nova-compute-ffu
        secrets:
          - nova-cell1-compute-config
          - nova-migration-ssh-key
        playbook: osp.edpm.nova
      ---
      apiVersion: dataplane.openstack.org/v1beta1
      kind: OpenStackDataPlaneDeployment
      metadata:
        name: openstack-nova-compute-ffu
        namespace: openstack
      spec:
        nodeSets:
          - openstack
        servicesOverride:
          - nova-compute-ffu
      EOF
  • Nova compute EDPM サービスの準備が完了するまで待機します。

      oc wait --for condition=Ready osdpd/openstack-nova-compute-ffu --timeout=5m
  • Nova DB オンライン移行を実行して FFU を完了します。

      oc exec -it nova-cell0-conductor-0 -- nova-manage db online_data_migrations
      oc exec -it nova-cell1-conductor-0 -- nova-manage db online_data_migrations
  • Nova サービスが既存のテスト仮想マシンインスタンスを停止できるか検証します。

    ${BASH_ALIASES[openstack]} server list | grep -qF '| test | ACTIVE |' && openstack server stop test
    ${BASH_ALIASES[openstack]} server list | grep -qF '| test | SHUTOFF |'
    ${BASH_ALIASES[openstack]} server --os-compute-api-version 2.48 show --diagnostics test | grep "it is in power state shutdown" || echo PASS
  • Nova サービスが既存のテスト仮想マシンインスタンスを開始できるか検証します。

    ${BASH_ALIASES[openstack]} server list | grep -qF '| test | SHUTOFF |' && openstack server start test
    ${BASH_ALIASES[openstack]} server list | grep -F '| test | ACTIVE |'
    ${BASH_ALIASES[openstack]} server --os-compute-api-version 2.48 show --diagnostics test --fit-width -f json | jq -r '.state' | grep running

1.22. 導入のトラブルシューティング

このドキュメントには、直面する可能性のあるさまざまな問題とその解決方法に関する情報が含まれています。

1.22.1. 認証の欠落が原因の ErrImagePull

デプロイされたコンテナーは、プライベートコンテナーレジストリーからイメージをプルします。これにより、次のような認証エラーが返される可能性があります。

Failed to pull image "registry.redhat.io/rhosp-rhel9/openstack-rabbitmq:17.0":
rpc error: code = Unknown desc = unable to retrieve auth token: invalid
username/password: unauthorized: Please login to the Red Hat Registry using
your Customer Portal credentials.

以下は、エラーが発生した Pod の例です。

  Normal   Scheduled       3m40s                  default-scheduler  Successfully assigned openstack/rabbitmq-server-0 to worker0
  Normal   AddedInterface  3m38s                  multus             Add eth0 [10.101.0.41/23] from ovn-kubernetes
  Warning  Failed          2m16s (x6 over 3m38s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling         2m5s (x4 over 3m38s)   kubelet            Pulling image "registry.redhat.io/rhosp-rhel9/openstack-rabbitmq:17.0"
  Warning  Failed          2m5s (x4 over 3m38s)   kubelet            Failed to pull image "registry.redhat.io/rhosp-rhel9/openstack-rabbitmq:17.0": rpc error: code  ... can be found here: https://access.redhat.com/RegistryAuthentication
  Warning  Failed          2m5s (x4 over 3m38s)   kubelet            Error: ErrImagePull
  Normal   BackOff         110s (x7 over 3m38s)   kubelet            Back-off pulling image "registry.redhat.io/rhosp-rhel9/openstack-rabbitmq:17.0"

この問題を解決するには、公式 Red Hat コンソールサイト から有効なプルシークレットを取得し、そのプルシークレットを Kubernetes API (サービスノード) にアクセスできるマシンのローカルに保存してから、次のコマンドを実行する必要があります。

oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location.json>

前のコマンドを実行すると、すべてのクラスターのコンピュートノードで認証情報が利用可能になります。その後、以下を実行して新しい Pod のデプロイメントをトリガーし、コンテナーイメージをプルします。

kubectl delete pod rabbitmq-server-0 -n openstack

Pod はイメージを正常にプルできるはずです。どのコンテナーレジストリーにどの種類の認証が必要かについて、詳しくは 公式ドキュメント を参照してください。

第2章 Ceph の移行

2.1. Ceph RBD の移行

このシナリオでは、HCI または専用ストレージノードのいずれかで Ceph 5 以降であると仮定すると、OpenStack コントロールプレーンに存在するデーモンを既存の外部 RHEL ノード (通常は、HCI 環境の場合はコンピュートノード、その他のユースケースでは専用ストレージノード) に移動または移行する必要があります。

2.1.1. 要件

  • Ceph 5 以降、および cephadm/orchestrator による管理。
  • Ceph NFS (ganesha) が、TripleO ベースのデプロイメントから cephadm に移行されている。
  • Ceph パブリックネットワークとクラスターネットワークの両方が、TripleO 経由でターゲットノードに伝播されている。
  • Ceph Mons は IP を保持しているす (コールドマイグレーションを避けるため)。

2.1.2. シナリオ: コントローラーノードから mon と mgr を移行する

最初の POC は、ceph デーモンに関して、コントローラーノードを正常にドレインして別のノードに移動できることの証明を目的としています。POC の最初のターゲットは RBD のみです。つまり、mon および mgr デーモンのみを移動します。この POC は、mon、mgrs、osds のみを含む ceph クラスターをデプロイし、移行を開始する前にお客様が置かれる環境をシミュレートすることを目的としています。最初の POC の目標は、以下を確認することです。

  • mon IP アドレスを Ceph Storage ノードに移動して保持できる。
  • 既存のコントローラーノードをドレインしてシャットダウンできる。
  • 追加のモニターを既存のノードにデプロイし、管理者が Ceph クラスターの管理と Day2 オペレーションの実行に使用できる _admin ノードとして昇格できる。
  • 移行中もクラスターの稼働を維持できる。
2.1.2.1. 前提条件

Ceph パブリックネットワークとクラスターネットワークの両方を使用できるように、ストレージノードは storage ネットワークと storage_mgmt ネットワークの両方を持つように設定する。

この手順は、TripleO とのやり取りが必要な唯一の手順です。17 以降では、スタックの更新を実行する必要はありません。ただし、bare-metal ノードで os-net-config を実行し、追加のネットワークを設定するために実行する必要があるコマンドがあります。

CephStorageNodes の metalsmith.yaml でネットワークが定義されていることを確認します。

  - name: CephStorage
    count: 2
    instances:
      - hostname: oc0-ceph-0
        name: oc0-ceph-0
      - hostname: oc0-ceph-1
        name: oc0-ceph-1
    defaults:
      networks:
        - network: ctlplane
          vif: true
        - network: storage_cloud_0
            subnet: storage_cloud_0_subnet
        - network: storage_mgmt_cloud_0
            subnet: storage_mgmt_cloud_0_subnet
      network_config:
        template: templates/single_nic_vlans/single_nic_vlans_storage.j2

次に、以下を実行します。

openstack overcloud node provision \
  -o overcloud-baremetal-deployed-0.yaml --stack overcloud-0 \
  --network-config -y --concurrency 2 /home/stack/metalsmith-0.yam

ストレージネットワークがノード上で実行されていることを検証します。

(undercloud) [CentOS-9 - stack@undercloud ~]$ ssh heat-admin@192.168.24.14 ip -o -4 a
Warning: Permanently added '192.168.24.14' (ED25519) to the list of known hosts.
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
5: br-storage    inet 192.168.24.14/24 brd 192.168.24.255 scope global br-storage\       valid_lft forever preferred_lft forever
6: vlan1    inet 192.168.24.14/24 brd 192.168.24.255 scope global vlan1\       valid_lft forever preferred_lft forever
7: vlan11    inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\       valid_lft forever preferred_lft forever
8: vlan12    inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\       valid_lft forever preferred_lft forever
2.1.2.2. 2 つの既存 CephStorage ノード上で mon と mgr を移行する

コントローラーノード上の mon/mgr を使用して、デフォルトのロールをベースに ceph 仕様を作成します。

openstack overcloud ceph spec -o ceph_spec.yaml -y  \
   --stack overcloud-0     overcloud-baremetal-deployed-0.yaml

Ceph クラスターをデプロイします。

 openstack overcloud ceph deploy overcloud-baremetal-deployed-0.yaml \
    --stack overcloud-0 -o deployed_ceph.yaml \
    --network-data ~/oc0-network-data.yaml \
    --ceph-spec ~/ceph_spec.yaml

注記:

OSP によって生成された ceph クラスターの記述である ceph_spec.yaml は、これ以降のプロセスで、cephadm がデーモンのステータス/情報を更新するために必要な基本テンプレートとして使用されます。

クラスターのステータスを確認します。

[ceph: root@oc0-controller-0 /]# ceph -s
  cluster:
    id:     f6ec3ebe-26f7-56c8-985d-eb974e8e08e3
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum oc0-controller-0,oc0-controller-1,oc0-controller-2 (age 19m)
    mgr: oc0-controller-0.xzgtvo(active, since 32m), standbys: oc0-controller-1.mtxohd, oc0-controller-2.ahrgsk
    osd: 8 osds: 8 up (since 12m), 8 in (since 18m); 1 remapped pgs

  data:
    pools:   1 pools, 1 pgs
    objects: 0 objects, 0 B
    usage:   43 MiB used, 400 GiB / 400 GiB avail
    pgs:     1 active+clean
[ceph: root@oc0-controller-0 /]# ceph orch host ls
HOST              ADDR           LABELS          STATUS
oc0-ceph-0        192.168.24.14  osd
oc0-ceph-1        192.168.24.7   osd
oc0-controller-0  192.168.24.15  _admin mgr mon
oc0-controller-1  192.168.24.23  _admin mgr mon
oc0-controller-2  192.168.24.13  _admin mgr mon

次のセクションの目的は、oc0-controller-{1,2} デーモンを oc0-ceph-{0,1}cephadm に以降することです。これは、cephadm を使用してこの種の移行を実行できることを実証する非常に基本的なシナリオです。

2.1.2.3. oc0-controller-1 を oc0-ceph-0 に移行する

SSH で controller-0 に接続します。

cephadm shell -v /home/ceph-admin/specs:/specs

SSH で ceph-0 に接続します。

sudo “watch podman ps”  # watch the new mon/mgr being deployed here

(オプション) ソースノードで mgr がアクティブな場合、以下を実行します。

ceph mgr fail <mgr instance>

cephadm シェルから、oc0-controller-1 のラベルを削除します。

    for label in mon mgr _admin; do
           ceph orch host rm label oc0-controller-1 $label;
    done

不足しているラベルを oc0-ceph-0 に追加します。

[ceph: root@oc0-controller-0 /]#
> for label in mon mgr _admin; do ceph orch host label add oc0-ceph-0 $label; done
Added label mon to host oc0-ceph-0
Added label mgr to host oc0-ceph-0
Added label _admin to host oc0-ceph-0

oc0-controller-1 ノードをドレインし、強制的に削除します。

[ceph: root@oc0-controller-0 /]# ceph orch host drain oc0-controller-1
Scheduled to remove the following daemons from host 'oc0-controller-1'
type                 id
-------------------- ---------------
mon                  oc0-controller-1
mgr                  oc0-controller-1.mtxohd
crash                oc0-controller-1
[ceph: root@oc0-controller-0 /]# ceph orch host rm oc0-controller-1 --force
Removed  host 'oc0-controller-1'

[ceph: root@oc0-controller-0 /]# ceph orch host ls
HOST              ADDR           LABELS          STATUS
oc0-ceph-0        192.168.24.14  osd
oc0-ceph-1        192.168.24.7   osd
oc0-controller-0  192.168.24.15  mgr mon _admin
oc0-controller-2  192.168.24.13  _admin mgr mon

mon ノードが 3 つしかなく、ノードのドレインが期待どおりに機能しない (コンテナーが残る) 場合は、controller-1 に SSH で接続し、ノード内のコンテナーを強制的にパージします。

[root@oc0-controller-1 ~]# sudo podman ps
CONTAINER ID  IMAGE                                                                                        COMMAND               CREATED         STATUS             PORTS       NAMES
5c1ad36472bc  registry.redhat.io/ceph/rhceph@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4  -n mon.oc0-contro...  35 minutes ago  Up 35 minutes ago              ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mon-oc0-controller-1
3b14cc7bf4dd  registry.redhat.io/ceph/rhceph@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4  -n mgr.oc0-contro...  35 minutes ago  Up 35 minutes ago              ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mgr-oc0-controller-1-mtxohd

[root@oc0-controller-1 ~]# cephadm rm-cluster --fsid f6ec3ebe-26f7-56c8-985d-eb974e8e08e3 --force

[root@oc0-controller-1 ~]# sudo podman ps
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
注記

クラスターの一部ではなくなったノード上で cephadm の rm-cluster を実行すると、すべてのコンテナーが削除され、ファイルシステムがクリーンアップされます。

oc0-controller-1 をシャットダウンする前に、(同じネットワーク上の) IP アドレスを oc0-ceph-0 ノードに移動します。

mon_host = [v2:172.16.11.54:3300/0,v1:172.16.11.54:6789/0] [v2:172.16.11.121:3300/0,v1:172.16.11.121:6789/0] [v2:172.16.11.205:3300/0,v1:172.16.11.205:6789/0]

[root@oc0-controller-1 ~]# ip -o -4 a
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
5: br-ex    inet 192.168.24.23/24 brd 192.168.24.255 scope global br-ex\       valid_lft forever preferred_lft forever
6: vlan100    inet 192.168.100.96/24 brd 192.168.100.255 scope global vlan100\       valid_lft forever preferred_lft forever
7: vlan12    inet 172.16.12.154/24 brd 172.16.12.255 scope global vlan12\       valid_lft forever preferred_lft forever
8: vlan11    inet 172.16.11.121/24 brd 172.16.11.255 scope global vlan11\       valid_lft forever preferred_lft forever
9: vlan13    inet 172.16.13.178/24 brd 172.16.13.255 scope global vlan13\       valid_lft forever preferred_lft forever
10: vlan70    inet 172.17.0.23/20 brd 172.17.15.255 scope global vlan70\       valid_lft forever preferred_lft forever
11: vlan1    inet 192.168.24.23/24 brd 192.168.24.255 scope global vlan1\       valid_lft forever preferred_lft forever
12: vlan14    inet 172.16.14.223/24 brd 172.16.14.255 scope global vlan14\       valid_lft forever preferred_lft forever

oc0-ceph-0 上で以下を実行します。

[heat-admin@oc0-ceph-0 ~]$ ip -o -4 a
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
5: br-storage    inet 192.168.24.14/24 brd 192.168.24.255 scope global br-storage\       valid_lft forever preferred_lft forever
6: vlan1    inet 192.168.24.14/24 brd 192.168.24.255 scope global vlan1\       valid_lft forever preferred_lft forever
7: vlan11    inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\       valid_lft forever preferred_lft forever
8: vlan12    inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\       valid_lft forever preferred_lft forever
[heat-admin@oc0-ceph-0 ~]$ sudo ip a add 172.16.11.121 dev vlan11
[heat-admin@oc0-ceph-0 ~]$ ip -o -4 a
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
5: br-storage    inet 192.168.24.14/24 brd 192.168.24.255 scope global br-storage\       valid_lft forever preferred_lft forever
6: vlan1    inet 192.168.24.14/24 brd 192.168.24.255 scope global vlan1\       valid_lft forever preferred_lft forever
7: vlan11    inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\       valid_lft forever preferred_lft forever
7: vlan11    inet 172.16.11.121/32 scope global vlan11\       valid_lft forever preferred_lft forever
8: vlan12    inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\       valid_lft forever preferred_lft forever

oc0-controller-1 の電源をオフにします。

古い IP アドレスを使用して、oc0-ceph-0 に新しい mon を追加します。

[ceph: root@oc0-controller-0 /]# ceph orch daemon add mon oc0-ceph-0:172.16.11.121
Deployed mon.oc0-ceph-0 on host 'oc0-ceph-0'

oc0-ceph-0 ノード内の新しいコンテナーを確認します。

b581dc8bbb78  registry.redhat.io/ceph/rhceph@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4  -n mon.oc0-ceph-0...  24 seconds ago  Up 24 seconds ago              ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mon-oc0-ceph-0

cephadm シェルで、既存の ceph_spec.yaml をバックアップし、仕様を編集して oc0-controller-1 エントリーを削除し、oc0-ceph-0 に置き換えます。

cp ceph_spec.yaml ceph_spec.yaml.bkp # backup the ceph_spec.yaml file

[ceph: root@oc0-controller-0 specs]# diff -u ceph_spec.yaml.bkp ceph_spec.yaml

--- ceph_spec.yaml.bkp  2022-07-29 15:41:34.516329643 +0000
+++ ceph_spec.yaml      2022-07-29 15:28:26.455329643 +0000
@@ -7,14 +7,6 @@
 - mgr
 service_type: host
 ---
-addr: 192.168.24.12
-hostname: oc0-controller-1
-labels:
-- _admin
-- mon
-- mgr
-service_type: host
 ----
 addr: 192.168.24.19
 hostname: oc0-controller-2
 labels:
@@ -38,7 +30,7 @@
 placement:
   hosts:
   - oc0-controller-0
-  - oc0-controller-1
+  - oc0-ceph-0
   - oc0-controller-2
 service_id: mon
 service_name: mon
@@ -47,8 +39,8 @@
 placement:
   hosts:
   - oc0-controller-0
-  - oc0-controller-1
   - oc0-controller-2
+  - oc0-ceph-0
 service_id: mgr
 service_name: mgr
 service_type: mgr

結果として得られる仕様を適用します。

ceph orch apply -i ceph_spec.yaml

 The result of 12 is having a new mgr deployed on the oc0-ceph-0 node, and the spec reconciled within cephadm

[ceph: root@oc0-controller-0 specs]# ceph orch ls
NAME                     PORTS  RUNNING  REFRESHED  AGE  PLACEMENT
crash                               4/4  5m ago     61m  *
mgr                                 3/3  5m ago     69s  oc0-controller-0;oc0-ceph-0;oc0-controller-2
mon                                 3/3  5m ago     70s  oc0-controller-0;oc0-ceph-0;oc0-controller-2
osd.default_drive_group               8  2m ago     69s  oc0-ceph-0;oc0-ceph-1

[ceph: root@oc0-controller-0 specs]# ceph -s
  cluster:
    id:     f6ec3ebe-26f7-56c8-985d-eb974e8e08e3
    health: HEALTH_WARN
            1 stray host(s) with 1 daemon(s) not managed by cephadm

  services:
    mon: 3 daemons, quorum oc0-controller-0,oc0-controller-2,oc0-ceph-0 (age 5m)
    mgr: oc0-controller-0.xzgtvo(active, since 62m), standbys: oc0-controller-2.ahrgsk, oc0-ceph-0.hccsbb
    osd: 8 osds: 8 up (since 42m), 8 in (since 49m); 1 remapped pgs

  data:
    pools:   1 pools, 1 pgs
    objects: 0 objects, 0 B
    usage:   43 MiB used, 400 GiB / 400 GiB avail
    pgs:     1 active+clean

mgr を更新して警告を修正します。

ceph mgr fail oc0-controller-0.xzgtvo

この時点で、クラスターはクリーンになっています。

[ceph: root@oc0-controller-0 specs]# ceph -s
  cluster:
    id:     f6ec3ebe-26f7-56c8-985d-eb974e8e08e3
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum oc0-controller-0,oc0-controller-2,oc0-ceph-0 (age 7m)
    mgr: oc0-controller-2.ahrgsk(active, since 25s), standbys: oc0-controller-0.xzgtvo, oc0-ceph-0.hccsbb
    osd: 8 osds: 8 up (since 44m), 8 in (since 50m); 1 remapped pgs

  data:
    pools:   1 pools, 1 pgs
    objects: 0 objects, 0 B
    usage:   43 MiB used, 400 GiB / 400 GiB avail
    pgs:     1 active+clean

oc0-controller-1 は削除され、電源がオフになりました。その痕跡は ceph クラスターには残されません。

同じアプローチと同じ手順を適用して、oc0-controller-2 を oc0-ceph-1 に移行できます。

2.1.2.4. 画面録画:

2.1.3. 有用なリソース

2.2. Ceph RGW の移行

このシナリオでは、HCI または専用ストレージノードのいずれかで Ceph 5 以降であると仮定すると、OpenStack Controller ノードに存在する RGW デーモンを既存の外部 RHEL ノード (通常は、HCI 環境の場合はコンピュートノード、その他のユースケースでは CephStorage ノード) に移行されます。

2.2.1. 要件

  • Ceph 5 以降、および cephadm/orchestrator による管理。
  • アンダークラウドは引き続き利用可能、TripleO によるノードとネットワークの管理。

2.2.2. Ceph デーモンのカーディナリティー

Ceph 5 以降 では、複数のデーモンを同じノード内に配置する方法に 厳しい制約 が適用されます。結果として得られるトポロジーは、使用可能なハードウェアと、廃止されるコントローラーノードに存在する Ceph サービスの数により異なります。次のドキュメントでは、RGW コンポーネントの移行 (および、サービスがデプロイされる spec placement をコントローラーノードが表現する一般的な TripleO シナリオで、Ceph Ingress デーモン を使用して HA モデルを維持するため) に必要な手順について説明します。一般的なルールとして、移行できるサービスの数は、クラスター内の使用可能なノードの数により異なります。次の図は、RGW と RBD のみ (ダッシュボードなし) を表示するシナリオで 3 ノード以上を必要とする CephStorage ノード上における、Ceph デーモンの分布を示しています。

|    |                     |             |
|----|---------------------|-------------|
| osd | mon/mgr/crash      | rgw/ingress |
| osd | mon/mgr/crash      | rgw/ingress |
| osd | mon/mgr/crash      | rgw/ingress |

ダッシュボードがあり、Manila がない場合は、4 ノード以上が必要です (ダッシュボードにフェイルオーバーはありません)。

|     |                     |             |
|-----|---------------------|-------------|
| osd | mon/mgr/crash | rgw/ingress       |
| osd | mon/mgr/crash | rgw/ingress       |
| osd | mon/mgr/crash | dashboard/grafana |
| osd | rgw/ingress   | (free)            |

ダッシュボードと Manila がある場合は、5 ノード以上が必要です (ダッシュボードにはフェイルオーバーがありません)。

|     |                     |                         |
|-----|---------------------|-------------------------|
| osd | mon/mgr/crash       | rgw/ingress             |
| osd | mon/mgr/crash       | rgw/ingress             |
| osd | mon/mgr/crash       | mds/ganesha/ingress     |
| osd | rgw/ingress         | mds/ganesha/ingress     |
| osd | mds/ganesha/ingress | dashboard/grafana       |

2.2.3. 現在のステータス

(undercloud) [stack@undercloud-0 ~]$ metalsmith list


    +------------------------+    +----------------+
    | IP Addresses           |    |  Hostname      |
    +------------------------+    +----------------+
    | ctlplane=192.168.24.25 |    | cephstorage-0  |
    | ctlplane=192.168.24.10 |    | cephstorage-1  |
    | ctlplane=192.168.24.32 |    | cephstorage-2  |
    | ctlplane=192.168.24.28 |    | compute-0      |
    | ctlplane=192.168.24.26 |    | compute-1      |
    | ctlplane=192.168.24.43 |    | controller-0   |
    | ctlplane=192.168.24.7  |    | controller-1   |
    | ctlplane=192.168.24.41 |    | controller-2   |
    +------------------------+    +----------------+

controller-0 に SSH で接続し、pacemaker のステータスを確認します。これにより、RGW の移行を開始する前に必要な情報を特定できます。

Full List of Resources:
  * ip-192.168.24.46	(ocf:heartbeat:IPaddr2):     	Started controller-0
  * ip-10.0.0.103   	(ocf:heartbeat:IPaddr2):     	Started controller-1
  * ip-172.17.1.129 	(ocf:heartbeat:IPaddr2):     	Started controller-2
  * ip-172.17.3.68  	(ocf:heartbeat:IPaddr2):     	Started controller-0
  * ip-172.17.4.37  	(ocf:heartbeat:IPaddr2):     	Started controller-1
  * Container bundle set: haproxy-bundle

[undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp17-openstack-haproxy:pcmklatest]:
    * haproxy-bundle-podman-0   (ocf:heartbeat:podman):  Started controller-2
    * haproxy-bundle-podman-1   (ocf:heartbeat:podman):  Started controller-0
    * haproxy-bundle-podman-2   (ocf:heartbeat:podman):  Started controller-1

ストレージネットワークの範囲を特定するには、ip コマンドを使用します。

[heat-admin@controller-0 ~]$ ip -o -4 a

1: lo	inet 127.0.0.1/8 scope host lo\   	valid_lft forever preferred_lft forever
2: enp1s0	inet 192.168.24.45/24 brd 192.168.24.255 scope global enp1s0\   	valid_lft forever preferred_lft forever
2: enp1s0	inet 192.168.24.46/32 brd 192.168.24.255 scope global enp1s0\   	valid_lft forever preferred_lft forever
7: br-ex	inet 10.0.0.122/24 brd 10.0.0.255 scope global br-ex\   	valid_lft forever preferred_lft forever
8: vlan70	inet 172.17.5.22/24 brd 172.17.5.255 scope global vlan70\   	valid_lft forever preferred_lft forever
8: vlan70	inet 172.17.5.94/32 brd 172.17.5.255 scope global vlan70\   	valid_lft forever preferred_lft forever
9: vlan50	inet 172.17.2.140/24 brd 172.17.2.255 scope global vlan50\   	valid_lft forever preferred_lft forever
10: vlan30	inet 172.17.3.73/24 brd 172.17.3.255 scope global vlan30\   	valid_lft forever preferred_lft forever
10: vlan30	inet 172.17.3.68/32 brd 172.17.3.255 scope global vlan30\   	valid_lft forever preferred_lft forever
11: vlan20	inet 172.17.1.88/24 brd 172.17.1.255 scope global vlan20\   	valid_lft forever preferred_lft forever
12: vlan40	inet 172.17.4.24/24 brd 172.17.4.255 scope global vlan40\   	valid_lft forever preferred_lft forever

この例では、以下が適用されます。

  • vlan30 は、新しい RGW インスタンスが CephStorage ノード上で起動される必要があるストレージネットワークを表します。
  • br-ex は、現在の環境で haproxy にフロントエンド仮想 IP が割り当てられている外部ネットワークを表します。

2.2.4. 前提条件: フロントエンドネットワーク (コントローラーノード) を確認する

以前 haproxy にあったネットワークを特定し、それを (TripleO 経由で) CephStorage ノードに伝播します。このネットワークは、Ceph が所有し、RGW サービスのエントリーポイントとして使用される新しい仮想 IP を予約するために使用されます。

SSH で controller-0 に接続し、ceph_rgw セクションが見つかるまで現在の HaProxy 設定を確認します。

$ less /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg

...
...
listen ceph_rgw
  bind 10.0.0.103:8080 transparent
  bind 172.17.3.68:8080 transparent
  mode http
  balance leastconn
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  http-request set-header X-Forwarded-Port %[dst_port]
  option httpchk GET /swift/healthcheck
  option httplog
  option forwardfor
  server controller-0.storage.redhat.local 172.17.3.73:8080 check fall 5 inter 2000 rise 2
  server controller-1.storage.redhat.local 172.17.3.146:8080 check fall 5 inter 2000 rise 2
  server controller-2.storage.redhat.local 172.17.3.156:8080 check fall 5 inter 2000 rise 2

HaProxy フロントエンドとして使用されているネットワークを再確認します。

[controller-0]$ ip -o -4 a

...
7: br-ex	inet 10.0.0.106/24 brd 10.0.0.255 scope global br-ex\   	valid_lft forever preferred_lft forever
...

前のセクションで説明したように、controller-0 を確認するということは、Ceph Storage ノードには存在しない外部ネットワークを使用してサービスを公開することを示しており、それを TripleO 経由で伝播する必要があります。

2.2.5. HaProxy フロントエンドネットワークを CephStorage ノードに伝播する

ceph-storage ネットワークインターフェイスの定義に使用される NIC テンプレートを変更し、新しい config セクションを追加します。

---
network_config:
- type: interface
  name: nic1
  use_dhcp: false
  dns_servers: {{ ctlplane_dns_nameservers }}
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ ctlplane_host_routes }}
- type: vlan
  vlan_id: {{ storage_mgmt_vlan_id }}
  device: nic1
  addresses:
  - ip_netmask: {{ storage_mgmt_ip }}/{{ storage_mgmt_cidr }}
  routes: {{ storage_mgmt_host_routes }}
- type: interface
  name: nic2
  use_dhcp: false
  defroute: false
- type: vlan
  vlan_id: {{ storage_vlan_id }}
  device: nic2
  addresses:
  - ip_netmask: {{ storage_ip }}/{{ storage_cidr }}
  routes: {{ storage_host_routes }}
- type: ovs_bridge
  name: {{ neutron_physical_bridge_name }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  use_dhcp: false
  addresses:
  - ip_netmask: {{ external_ip }}/{{ external_cidr }}
  routes: {{ external_host_routes }}
  members:
  - type: interface
    name: nic3
    primary: true

さらに、metalsmith が使用する baremetal.yaml ファイルに 外部 ネットワークを追加し、--network-config オプションを渡して overcloud node provision コマンドを実行します。

- name: CephStorage
  count: 3
  hostname_format: cephstorage-%index%
  instances:
  - hostname: cephstorage-0
  name: ceph-0
  - hostname: cephstorage-1
  name: ceph-1
  - hostname: cephstorage-2
  name: ceph-2
  defaults:
  profile: ceph-storage
  network_config:
      template: /home/stack/composable_roles/network/nic-configs/ceph-storage.j2
  networks:
  - network: ctlplane
      vif: true
  - network: storage
  - network: storage_mgmt
  - network: external
(undercloud) [stack@undercloud-0]$

openstack overcloud node provision
   -o overcloud-baremetal-deployed-0.yaml
   --stack overcloud
   --network-config -y
  $PWD/network/baremetal_deployment.yaml

CephStorage ノード上の新しいネットワークを確認します。

[root@cephstorage-0 ~]# ip -o -4 a

1: lo	inet 127.0.0.1/8 scope host lo\   	valid_lft forever preferred_lft forever
2: enp1s0	inet 192.168.24.54/24 brd 192.168.24.255 scope global enp1s0\   	valid_lft forever preferred_lft forever
11: vlan40	inet 172.17.4.43/24 brd 172.17.4.255 scope global vlan40\   	valid_lft forever preferred_lft forever
12: vlan30	inet 172.17.3.23/24 brd 172.17.3.255 scope global vlan30\   	valid_lft forever preferred_lft forever
14: br-ex	inet 10.0.0.133/24 brd 10.0.0.255 scope global br-ex\   	valid_lft forever preferred_lft forever

ここで、RGW バックエンドの移行を開始し、その上に Ingress を構築できます。

2.2.6. RGW バックエンドを以降する

カーディナリティー図と一致させるために、cephadm ラベルを使用して、特定のデーモンタイプをデプロイする必要があるノードのグループを参照します。

cephstorage ノードに RGW ラベルを追加します。

for i in 0 1 2; {
    ceph orch host label add cephstorage-$i rgw;
}
[ceph: root@controller-0 /]#

for i in 0 1 2; {
    ceph orch host label add cephstorage-$i rgw;
}

Added label rgw to host cephstorage-0
Added label rgw to host cephstorage-1
Added label rgw to host cephstorage-2

[ceph: root@controller-0 /]# ceph orch host ls

HOST       	ADDR       	LABELS      	STATUS
cephstorage-0  192.168.24.54  osd rgw
cephstorage-1  192.168.24.44  osd rgw
cephstorage-2  192.168.24.30  osd rgw
controller-0   192.168.24.45  _admin mon mgr
controller-1   192.168.24.11  _admin mon mgr
controller-2   192.168.24.38  _admin mon mgr

6 hosts in cluster

オーバークラウドのデプロイメント中に、手順2 (external_deployment_steps) で RGW が適用され、cephadm 互換仕様が ceph_mkspec ansible モジュールから /home/ceph-admin/specs/rgw に生成されます。RGW 仕様を見つけてパッチを適用し、ラベルアプローチを使用して適切な配置を指定し、Ceph Ingress Daemon (*) との競合を避けるために rgw バックエンドポートを 8090 に変更します。

[root@controller-0 heat-admin]# cat rgw

networks:
- 172.17.3.0/24
placement:
  hosts:
  - controller-0
  - controller-1
  - controller-2
service_id: rgw
service_name: rgw.rgw
service_type: rgw
spec:
  rgw_frontend_port: 8080
  rgw_realm: default
  rgw_zone: default

仕様にパッチを適用してコントローラーノードをラベルキーで置き換えます。

---
networks:
- 172.17.3.0/24
placement:
  label: rgw
service_id: rgw
service_name: rgw.rgw
service_type: rgw
spec:
  rgw_frontend_port: 8090
  rgw_realm: default
  rgw_zone: default

(*) cephadm_check_port

オーケストレーター CLI を使用して、新しい RGW 仕様を適用します。

$ cephadm shell -m /home/ceph-admin/specs/rgw
$ cephadm shell -- ceph orch apply -i /mnt/rgw

これにより再デプロイがトリガーされます。

...
osd.9                     	cephstorage-2
rgw.rgw.cephstorage-0.wsjlgx  cephstorage-0  172.17.3.23:8090   starting
rgw.rgw.cephstorage-1.qynkan  cephstorage-1  172.17.3.26:8090   starting
rgw.rgw.cephstorage-2.krycit  cephstorage-2  172.17.3.81:8090   starting
rgw.rgw.controller-1.eyvrzw   controller-1   172.17.3.146:8080  running (5h)
rgw.rgw.controller-2.navbxa   controller-2   172.17.3.66:8080   running (5h)

...
osd.9                     	cephstorage-2
rgw.rgw.cephstorage-0.wsjlgx  cephstorage-0  172.17.3.23:8090  running (19s)
rgw.rgw.cephstorage-1.qynkan  cephstorage-1  172.17.3.26:8090  running (16s)
rgw.rgw.cephstorage-2.krycit  cephstorage-2  172.17.3.81:8090  running (13s)

この時点で、新しい RGW バックエンドが新しいポートでアクセスできることを確認する必要がありますが、以降のプロセスではポート 8080IngressDaemon を有効にする予定です。そのため、各 RGW ノード (CephStorage ノード) で SSH 接続を実行し、CephStorage ノードの 8080 ポートと 8090 ポートの両方への接続を許可する iptables ルールを追加します。

iptables -I INPUT -p tcp -m tcp --dport 8080 -m conntrack --ctstate NEW -m comment --comment "ceph rgw ingress" -j ACCEPT

iptables -I INPUT -p tcp -m tcp --dport 8090 -m conntrack --ctstate NEW -m comment --comment "ceph rgw backends" -j ACCEPT

for port in 8080 8090; {
    for i in 25 10 32; {
       ssh heat-admin@192.168.24.$i sudo iptables -I INPUT \
       -p tcp -m tcp --dport $port -m conntrack --ctstate NEW \
       -j ACCEPT;
   }
}

コントローラーノード (例: controller-0) から、rgw バックエンドへのアクセス (curl) を試みます。

for i in 26 23 81; do {
    echo "---"
    curl 172.17.3.$i:8090;
    echo "---"
    echo
done

以下のようになるはずです。

---
Query 172.17.3.23
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>
---

---
Query 172.17.3.26
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>
---

---
Query 172.17.3.81
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>
---
2.2.6.1. 注記

RGW バックエンドが CephStorage ノードに移行される場合、internalAPI ネットワークはありません (これは HCI の場合は当てはまりません)。伝播された外部ネットワークを指すように、RGW keystone エンドポイントを再設定します (前のセクションを参照)。

[ceph: root@controller-0 /]# ceph config dump | grep keystone
global   basic rgw_keystone_url  http://172.16.1.111:5000

[ceph: root@controller-0 /]# ceph config set global rgw_keystone_url http://10.0.0.103:5000

2.2.7. Ceph IngressDaemon をデプロイする

HaProxyPacemaker を介して TripleO によって管理されます。この時点で 3 つの実行中のインスタンスが古い RGW バックエンドを指すため、機能しない間違った設定となります。Ceph Ingress Daemon をデプロイするのであれば、まず既存の ceph_rgw 設定を削除し、TripleO が作成した設定をクリーンアップし、サービスを再起動して他のサービスがこの変更の影響を受けないことを確認する必要があります。

各コントローラーノードで SSH を実行し、/var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg から次のセクションを削除します。

listen ceph_rgw
  bind 10.0.0.103:8080 transparent
  mode http
  balance leastconn
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  http-request set-header X-Forwarded-Port %[dst_port]
  option httpchk GET /swift/healthcheck
  option httplog
  option forwardfor
   server controller-0.storage.redhat.local 172.17.3.73:8080 check fall 5 inter 2000 rise 2
  server controller-1.storage.redhat.local 172.17.3.146:8080 check fall 5 inter 2000 rise 2
  server controller-2.storage.redhat.local 172.17.3.156:8080 check fall 5 inter 2000 rise 2

haproxy-bundle を再起動し、開始されたことを確認します。

[root@controller-0 ~]# sudo pcs resource restart haproxy-bundle
haproxy-bundle successfully restarted


[root@controller-0 ~]# sudo pcs status | grep haproxy

  * Container bundle set: haproxy-bundle [undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp17-openstack-haproxy:pcmklatest]:
    * haproxy-bundle-podman-0   (ocf:heartbeat:podman):  Started controller-0
    * haproxy-bundle-podman-1   (ocf:heartbeat:podman):  Started controller-1
    * haproxy-bundle-podman-2   (ocf:heartbeat:podman):  Started controller-2

プロセスが 8080 にバインドされていないことを再確認します。

[root@controller-0 ~]# ss -antop | grep 8080
[root@controller-0 ~]#

この時点で Swift CLI は失敗するはずです。

(overcloud) [root@cephstorage-0 ~]# swift list

HTTPConnectionPool(host='10.0.0.103', port=8080): Max retries exceeded with url: /swift/v1/AUTH_852f24425bb54fa896476af48cbe35d3?format=json (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fc41beb0430>: Failed to establish a new connection: [Errno 111] Connection refused'))

CephStorage ノード上で Ceph IngressDaemon のデプロイを開始できます。

HaProxy と Keepalived に必要なイメージを設定します

[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_haproxy registry.redhat.io/rhceph/rhceph-haproxy-rhel9:latest
[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_keepalived registry.redhat.io/rhceph/keepalived-rhel9:latest

ingress 仕様を準備し、cephadm にマウントします。

$ sudo vim /home/ceph-admin/specs/rgw_ingress

次の内容を貼り付けます。

---
service_type: ingress
service_id: rgw.rgw
placement:
  label: rgw
spec:
  backend_service: rgw.rgw
  virtual_ip: 10.0.0.89/24
  frontend_port: 8080
  monitor_port: 8898
  virtual_interface_networks:
    - 10.0.0.0/24

生成された仕様をマウントし、オーケストレーター CLI を使用して適用します。

$ cephadm shell -m /home/ceph-admin/specs/rgw_ingress
$ cephadm shell -- ceph orch apply -i /mnt/rgw_ingress

Ingress がデプロイされるまで待機し、結果として得られるエンドポイントをクエリーします。

[ceph: root@controller-0 /]# ceph orch ls

NAME                 	PORTS            	RUNNING  REFRESHED  AGE  PLACEMENT
crash                                         	6/6  6m ago 	3d   *
ingress.rgw.rgw      	10.0.0.89:8080,8898  	6/6  37s ago	60s  label:rgw
mds.mds                   3/3  6m ago 	3d   controller-0;controller-1;controller-2
mgr                       3/3  6m ago 	3d   controller-0;controller-1;controller-2
mon                       3/3  6m ago 	3d   controller-0;controller-1;controller-2
osd.default_drive_group   15  37s ago	3d   cephstorage-0;cephstorage-1;cephstorage-2
rgw.rgw   ?:8090          3/3  37s ago	4m   label:rgw
[ceph: root@controller-0 /]# curl  10.0.0.89:8080

---
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>[ceph: root@controller-0 /]#
—

上記の結果は、IngressDaemon からバックエンドにアクセスできることを示しています。つまり、Swift CLI を使用してバックエンドと対話する準備がほぼ整ったことを意味します。

2.2.8. オブジェクトストアのエンドポイントを更新する

引き続きエンドポイントは pacemaker が所有する古い仮想 IP を指していますが、他のサービスでも使用されており、同じネットワーク上で新しい仮想 IP を予約しているため、次のアクションを実行する前にオブジェクトストアエンドポイントを更新する必要があります。

現在のエンドポイントをリストします。

(overcloud) [stack@undercloud-0 ~]$ openstack endpoint list | grep object

| 1326241fb6b6494282a86768311f48d1 | regionOne | swift    	| object-store   | True	| internal  | http://172.17.3.68:8080/swift/v1/AUTH_%(project_id)s |
| 8a34817a9d3443e2af55e108d63bb02b | regionOne | swift    	| object-store   | True	| public	| http://10.0.0.103:8080/swift/v1/AUTH_%(project_id)s  |
| fa72f8b8b24e448a8d4d1caaeaa7ac58 | regionOne | swift    	| object-store   | True	| admin 	| http://172.17.3.68:8080/swift/v1/AUTH_%(project_id)s |

Ingress 仮想 IP を指すエンドポイントを更新します。

(overcloud) [stack@undercloud-0 ~]$ openstack endpoint set --url "http://10.0.0.89:8080/swift/v1/AUTH_%(project_id)s" 95596a2d92c74c15b83325a11a4f07a3

(overcloud) [stack@undercloud-0 ~]$ openstack endpoint list | grep object-store
| 6c7244cc8928448d88ebfad864fdd5ca | regionOne | swift    	| object-store   | True	| internal  | http://172.17.3.79:8080/swift/v1/AUTH_%(project_id)s |
| 95596a2d92c74c15b83325a11a4f07a3 | regionOne | swift    	| object-store   | True	| public	| http://10.0.0.89:8080/swift/v1/AUTH_%(project_id)s   |
| e6d0599c5bf24a0fb1ddf6ecac00de2d | regionOne | swift    	| object-store   | True	| admin 	| http://172.17.3.79:8080/swift/v1/AUTH_%(project_id)s |

internal と admin に対しても同じアクションを実行します。移行したサービスをテストします。

(overcloud) [stack@undercloud-0 ~]$ swift list --debug

DEBUG:swiftclient:Versionless auth_url - using http://10.0.0.115:5000/v3 as endpoint
DEBUG:keystoneclient.auth.identity.v3.base:Making authentication request to http://10.0.0.115:5000/v3/auth/tokens
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 10.0.0.115:5000
DEBUG:urllib3.connectionpool:http://10.0.0.115:5000 "POST /v3/auth/tokens HTTP/1.1" 201 7795
DEBUG:keystoneclient.auth.identity.v3.base:{"token": {"methods": ["password"], "user": {"domain": {"id": "default", "name": "Default"}, "id": "6f87c7ffdddf463bbc633980cfd02bb3", "name": "admin", "password_expires_at": null},


...
...
...

DEBUG:swiftclient:REQ: curl -i http://10.0.0.89:8080/swift/v1/AUTH_852f24425bb54fa896476af48cbe35d3?format=json -X GET -H "X-Auth-Token: gAAAAABj7KHdjZ95syP4c8v5a2zfXckPwxFQZYg0pgWR42JnUs83CcKhYGY6PFNF5Cg5g2WuiYwMIXHm8xftyWf08zwTycJLLMeEwoxLkcByXPZr7kT92ApT-36wTfpi-zbYXd1tI5R00xtAzDjO3RH1kmeLXDgIQEVp0jMRAxoVH4zb-DVHUos" -H "Accept-Encoding: gzip"
DEBUG:swiftclient:RESP STATUS: 200 OK
DEBUG:swiftclient:RESP HEADERS: {'content-length': '2', 'x-timestamp': '1676452317.72866', 'x-account-container-count': '0', 'x-account-object-count': '0', 'x-account-bytes-used': '0', 'x-account-bytes-used-actual': '0', 'x-account-storage-policy-default-placement-container-count': '0', 'x-account-storage-policy-default-placement-object-count': '0', 'x-account-storage-policy-default-placement-bytes-used': '0', 'x-account-storage-policy-default-placement-bytes-used-actual': '0', 'x-trans-id': 'tx00000765c4b04f1130018-0063eca1dd-1dcba-default', 'x-openstack-request-id': 'tx00000765c4b04f1130018-0063eca1dd-1dcba-default', 'accept-ranges': 'bytes', 'content-type': 'application/json; charset=utf-8', 'date': 'Wed, 15 Feb 2023 09:11:57 GMT'}
DEBUG:swiftclient:RESP BODY: b'[]'

オブジェクトストレージに対して tempest テストを実行します。

(overcloud) [stack@undercloud-0 tempest-dir]$  tempest run --regex tempest.api.object_storage
...
...
...
======
Totals
======
Ran: 141 tests in 606.5579 sec.
 - Passed: 128
 - Skipped: 13
 - Expected Fail: 0
 - Unexpected Success: 0
 - Failed: 0
Sum of execute time for each test: 657.5183 sec.

==============
Worker Balance
==============
 - Worker 0 (1 tests) => 0:10:03.400561
 - Worker 1 (2 tests) => 0:00:24.531916
 - Worker 2 (4 tests) => 0:00:10.249889
 - Worker 3 (30 tests) => 0:00:32.730095
 - Worker 4 (51 tests) => 0:00:26.246044
 - Worker 5 (6 tests) => 0:00:20.114803
 - Worker 6 (20 tests) => 0:00:16.290323
 - Worker 7 (27 tests) => 0:00:17.103827

2.2.9. 関連情報

画面録画 を使用できます。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る