Red Hat Openstack Platform データプレーンの導入
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 に保存するか、機密部分のみを保存するかは個人の好みの問題になります。ただし、設定を Secret と customServiceConfig に分割する場合は、両方の場所にセクションヘッダー (例: [DEFAULT]) が必要です。
各サービスには特定の設定がある可能性があるため、各サービスの導入プロセスに注意を払う必要があります。
1.1.2. ノードのロール リンクのコピーリンクがクリップボードにコピーされました!
Director デプロイメントでは、4 種類の標準ノードロール (Controller、Compute、Ceph Storage、Swift 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オブジェクト。 -
コンポーネント:
OpenStackControlPlaneのcinder要素など。 -
サービス:
OpenStackControlPlaneのcinder要素内の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 は cinderVolumes の nodeSelector を定義しないため、それぞれのバックエンドで指定する必要があります。
Node Feature Discovery Operator で追加されたラベルを使用して、OpenStack サービスを配置できます。
1.2.1. MachineConfig リンクのコピーリンクがクリップボードにコピーされました!
一部のサービスでは、それらが実行されるホスト上でサービスまたはカーネルモジュールを実行する必要があります (iscsid デーモン、multipathd デーモン、または nvme-fabrics カーネルモジュールなど)。
その場合、MachineConfig マニフェストを使用します。また、nodeSelector を使用して OpenStack サービスを配置するノードを制限している場合は、MachineConfig が適用される場所も制限する必要があります。
MachineConfig を適用できる場所を定義するには、MachineConfig をノードにリンクする MachineConfigPool を使用する必要があります。
たとえば、MachineConfig を type: 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 openstackOSP シークレットを作成します。
その作成手順はさまざまですが、開発者/CI 環境では install_yamls を使用します。
# in install_yamls make input$ADMIN_PASSWORDがosp-secretに設定済みのパスワードと異なる場合は、それに応じてosp-secretのAdminPasswordキーを修正します。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. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
OpenStackControlPlaneCR がすでに存在している。
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' donenot-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-clientがrestricted:latestSecurity 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. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
前の導入手順を完了している。特に以下に注意してください。
- MariaDB インスタンスへのデータベースの移行 は、Pod 化された MariaDB にインポート済みである。
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 が更新され、ソースクラウドの同じバックエンドが利用可能になっているはずです。上記の条件が満たされている場合、導入が完了したものとみなされます。
このガイドでは、以下も前提としています。
-
TripleO環境 (ソースクラウド) が片側で実行されている。 -
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 が更新され、ソースクラウドの同じバックエンドが利用可能になっているはずです。上記の条件が満たされている場合、導入が完了したものとみなされます。
このガイドでは、以下も前提としています。
-
TripleO環境 (ソースクラウド) が片側で実行されている。 -
SNO/CodeReadyContainersが反対側で実行されている。 -
(オプション)
crcとTripleOの両方から、内部/外部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_datadir が GlanceNfsShare 変数で指定されるエクスポート値にマッピングされます。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 環境でチェックする必要がある出力の例を示しています。
次の手順の前提は以下のとおりです。
- Storage ネットワークは OpenStack コントロールプレーンに伝播されている。
-
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/path が nfs-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. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
前の導入手順を完了している。特に以下に注意してください。
- MariaDB インスタンスへのデータベースの移行 は、Pod 化された MariaDB にインポート済みである。
- Identity サービスの導入 をインポートしている。
- Memcached Operator をデプロイしている (ソース環境からインポートする必要があるものはありません)。
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. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
前の導入手順を完了している。特に以下に注意してください。
- MariaDB インスタンスへのデータベースの移行 は、Pod 化された MariaDB にインポート済みである。
- Identity サービスの導入 をインポートしている。
- Placement サービスの導入 をインポートしている。
- Image サービスの導入 をインポートしている。
- OVN データを移行する をインポートしている。
- OpenStack Networking サービスの導入 をインポートしている。
- 必須のサービス固有トポロジー
- OpenStack サービスが停止されている。詳細は、OpenStack サービスを停止する を参照してください。
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 の
novaDB とユーザー名はnova_cell1になります。 -
デフォルトのセルの名前が
cell1になります (マルチセルセットアップでは、代わりに最後のセルとしてインデックスが付けられるはずです)。 -
RabbitMQ トランスポート URL は
guestを使用しなくなります。
-
cell1 の
注記 この時点では、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 の影響をサービスが実行されるノードのみに制限する必要があります。
プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfig で worker を master に置き換える必要がある場合があります。
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 の影響をサービスが実行されるノードのみに制限する必要があります。
プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfig で worker を master に置き換える必要がある場合があります。
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 の影響をサービスが実行されるノードのみに制限する必要があります。
プロセスをテストするためにトイシングルノードデプロイメントを使用している場合は、MachineConfig で worker を master に置き換える必要がある場合があります。
マルチパス構成を使用するように 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]
< . . . >
機密情報を含むボリュームバックエンドの場合は、Secret と CustomServiceConfigSecrets キーを使用することが推奨される点に注意してください。
1.13.7. 設定の準備 リンクのコピーリンクがクリップボードにコピーされました!
デプロイメントマニフェスト全体を使用するのではなく導入する場合は、他のサービスの場合ど登用に対象を絞ったパッチを使用します。このパッチでは、それぞれ固有の設定を使用して異なる cinder サービスを有効にします。
警告: 設定オプションが非推奨になっていたり、削除または追加されている可能性があるため、新しい OpenStack バージョンでもすべての設定オプションが有効であることを確認してください。これは、バックエンドドライバー固有の設定オプションとその他の一般的なオプションの両方に該当します。
導入に向けた cinder 設定の準備には、カスタマイズする方法と手早く行う方法の 2 種類があります。どちらの方法でも Cinder の動作に違いはありませんが、可能な限りカスタマイズすることが推奨されます。
カスタマイズアプローチの概要は次のとおりです。
-
設定のどの部分がすべての cinder サービスに使用できる汎用の設定かを判断し、OpenShift でデプロイした場合に変更される部分 (例:
[dabase]セクションのconnection、[DEFAULT]のtransport_urlとlog_dir、[coordination]セクション全体) を削除します。この設定はcinder: template:レベルのcustomServiceConfigに配置されます (またはSecretに配置され、customServiceConfigSecretsで使用されます)。 -
スケジューラー固有の設定があるか確認し、ある場合はそれを
cinder: template: cinderSchedulerのcustomServiceConfigセクションに追加します。 -
API 固有の設定があるか確認し、ある場合はそれを
cinder: template: cinderSchedulerのcinder: template: cinderAPIセクションに追加します。 -
cinder バックアップがデプロイされている場合は、cinder バックアップに関連する設定オプションを取得し、それらを
cinder: template: cinderBackup:レベルのCustomServiceConfigに追加します (またはSecretに追加して、CustomServiceConfigSecretsで使用します)。今後、複数のレプリカをサポートしやすくするために、[DEFAULT]セクションのhost設定を削除する必要があります。 -
各ドライバーのボリュームバックエンド設定を決定します。cinder Operator はすべてのボリュームサービスに対するグローバルな
customServiceConfigセクションをサポートしないため、この設定には特定のドライバーセクションだけでなく、[backend_defaults]セクションと FC ゾーニングセクションも含まれている可能性があります。各バックエンドにはcinder: template: cinder Volumesの下に独自のセクションがあり、この設定はcustomServiceConfigに配置されます (またはSecretに配置され、CustomServiceConfigSecretsで使用されます)。 使用されている 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 < . . . >外部ファイル: 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
手早く実行できるプロセスの方は、これより簡単です。
-
古いデプロイメントの
cinder.confファイルから詳細 ([dabase]セクションのconnection、[DEFAULT]のtransport_urlとlog_dir、[coordination]セクション全体など) を削除して、非依存設定ファイルを作成します。 -
設定に機密情報が含まれていると仮定して、ファイル全体の変更された内容を
Secretにドロップします。 -
バックエンドごとに cinder ボリュームセクションを作成し、それぞれの
enabled_backendsオプションを追して、すべてのサービスでこのシークレットを参照します。 - カスタム設定の説明で最後の箇条書きとして説明したとおり、外部ファイルを追加します。
手早く実行できる設定のパッチは、次のサンプルのようになります。
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ファイルが作成されており、そのファイル内にMachineConfigとSecretが 1 つずつあります。MachineConfigは99-master-cinder-enable-multipathdと呼ばれ、名前が示すとおりすべての OCP ワーカーノードでマルチパス構成を有効にします。Secretはopenstackcinder-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 cinderv3cinder サービスが実行されていることを確認します。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.16. Bare Metal Provisioning サービスの導入 リンクのコピーリンクがクリップボードにコピーされました!
1.16.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 前の導入手順を完了している。特に、サービスデータベースが Pod 化された MariaDB にインポートされている必要があります。
1.16.2. 変数 リンクのコピーリンクがクリップボードにコピーされました!
現時点で必要なシェル変数はありません。
1.17. Heat の導入 リンクのコピーリンクがクリップボードにコピーされました!
Heat を導入するということは、Heat が無効になっているはずの既存の OpenStackControlPlane CR にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。
導入プロセスが完了すると、ユーザーは Heat、HeatAPI、HeatEngine、および HeatCFNAPI の CR を取得しています。さらに、Keystone 内にエンドポイントが作成されているはずです。これにより、上記のサービスが容易になります。
このガイドでは、以下も前提としています。
-
TripleO環境 (ソースクラウド) が片側で実行されている。 - OpenShift 環境は反対側で実行されています。
1.17.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 前の導入手順を完了している。特に、MariaDB と Keystone が導入されている必要があります。
- 既存の Heat スタックに、Neutron、Nova、Swift などの他のサービスのリソースが含まれている場合があります。Heat を導入する前に、これらのサービスを導入する必要があります。
1.17.2. 手順 - Heat の導入 リンクのコピーリンクがクリップボードにコピーされました!
Heat の導入でも、Keystone と同じパターンを実行します。
osp-secret にパッチを適用して、HeatAuthEncryptionKey と HeatPassword を更新します。これは、既存の TripleO Heat 設定と一致する必要があります。
以下を実行して、既存の auth_encryption_key と service パスワードを取得し、検証できます。
[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 にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。
このガイドでは、以下も前提としています。
-
TripleO環境 (ソースクラウド) が片側で実行されている。 -
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
1.18.3.2. 結果として得られるデータプレーンノード上の Ceilometer IPMI エージェント Pod を検査する リンクのコピーリンクがクリップボードにコピーされました!
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 にパッチを適用して、ソース環境により指定された設定パラメーターを使用してサービスを開始する必要があることを意味します。
このガイドでは、以下も前提としています。
-
TripleO環境 (ソースクラウド) が片側で実行されている。 -
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. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 前の導入手順を完了している。
- 残りのソースクラウドの Compute ホスト上の インフラストラクチャー管理と Compute サービスを停止する。
警告 この手順は、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" doneEDPM ノードの 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/^/ /') EOFssh キーペアの
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 EOFOpenStackDataPlaneDeployment をデプロイします。
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/novaNova 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 EOFNova compute EDPM サービスの準備が完了するまで待機します。
oc wait --for condition=Ready osdpd/openstack-nova-compute-ffu --timeout=5mNova 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_migrationsNova サービスが既存のテスト仮想マシンインスタンスを停止できるか検証します。
${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 PASSNova サービスが既存のテスト仮想マシンインスタンスを開始できるか検証します。
${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
オーケストレーター 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 バックエンドが新しいポートでアクセスできることを確認する必要がありますが、以降のプロセスではポート 8080 で IngressDaemon を有効にする予定です。そのため、各 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 をデプロイする リンクのコピーリンクがクリップボードにコピーされました!
HaProxy は Pacemaker を介して 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. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
画面録画 を使用できます。