マルチノードOpenStackCharmsデプロイメントガイド0.0.1.dev223-13--OpenStack構成が高可用性になった後、openstackダッシュボードにログインできません

参照ドキュメント:
「openstackhacluster apache2サービスが実行されていない、SSL証明書名が間違っている」

セクション10で高可用性をデプロイした後、openstack-dashboardにログインできないことが判明し、「認証中にエラーが発生しました。後でもう一度やり直してください。」というプロンプトが表示されました。

キーストーンステータスの表示:

juju status keystone
Model      Controller       Cloud/Region    Version  SLA          Timestamp
openstack  maas-controller  mymaas/default  2.8.7    unsupported  15:54:28+08:00

App                    Version  Status  Scale  Charm         Store       Rev  OS      Notes
keystone               18.0.0   active      3  keystone      local         0  ubuntu
keystone-hacluster              active      3  hacluster     jujucharms   74  ubuntu
keystone-mysql-router  8.0.23   active      3  mysql-router  local         0  ubuntu

Unit                        Workload  Agent  Machine  Public address  Ports     Message
keystone/0*                 active    idle   0/lxd/2  10.0.2.101      5000/tcp  Unit is ready
  keystone-hacluster/0*     active    idle            10.0.2.101                Unit is ready and clustered
  keystone-mysql-router/0*  active    idle            10.0.2.101                Unit is ready
keystone/1                  active    idle   1/lxd/7  10.0.2.117      5000/tcp  Unit is ready
  keystone-hacluster/1      active    idle            10.0.2.117                Unit is ready and clustered
  keystone-mysql-router/1   active    idle            10.0.2.117                Unit is ready
keystone/2                  active    idle   2/lxd/7  10.0.2.118      5000/tcp  Unit is ready
  keystone-hacluster/2      active    idle            10.0.2.118                Unit is ready and clustered
  keystone-mysql-router/2   active    idle            10.0.2.118                Unit is ready

Machine  State    DNS         Inst id              Series  AZ       Message
0        started  10.0.0.159  node4                focal   default  Deployed
0/lxd/2  started  10.0.2.101  juju-1584e6-0-lxd-2  focal   default  Container started
1        started  10.0.0.156  node2                focal   default  Deployed
1/lxd/7  started  10.0.2.117  juju-1584e6-1-lxd-7  focal   default  Container started
2        started  10.0.0.157  node1                focal   default  Deployed
2/lxd/7  started  10.0.2.118  juju-1584e6-2-lxd-7  focal   default  Container started

查看image:
openstack image list
Certificate did not match expected hostname: 10.0.7.12. Certificate: {'subject': ((('commonName', 'juju-1584e6-0-lxd-2.maas'),),), 'subjectAltName': [('DNS', 'juju-1584e6-0-lxd-2.maas'), ('IP Address', '10.0.2.101')]}
Failed to discover available identity versions when contacting https://10.0.7.12:5000/v3. Attempting to parse version from URL.
+--------------------------------------+-------+--------+
| ID                                   | Name  | Status |
+--------------------------------------+-------+--------+
| dfaeaebc-64d2-4996-96be-6475b6d06e17 | focal | active |
+--------------------------------------+-------+--------+

通信にはVIPアドレスを使う必要があるのではないかと思ったので、最初はVIPの問題だと思いました。
しかし、障害が再現されたとき、以前のapacheの使用不可プロンプトが表示されたことがわかり
、以前のapache2の使用不可の問題がバグであることが疑われました。

コミュニティのデバッグ情報によると、この問題の原因はsslチェーンの問題が原因です。VIPを使用してopenstackダッシュボードでHAの高可用性を拡張した後、コンテナーはca-cartを使用する必要がありますが、VIPディレクトリでは証明書コンテンツが空です。

証明書を再配信するには、juju run-action --wait vault / 0reissue-certificatesまたはrun-action--wait vault / Leaderreissue-certificatesを使用する必要があります。

しかし、証明書を再送信した後、障害の約90%を解決できます。これは、今回は残念なことに10%です。

残りの2番目の方法は、クレジット証明書を手動で転送することです。一般的なコマンドは次のとおりです。

sudo ln -s /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas cert_10.10.20.201
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ ls -la
total 28
dr-xr-xr-x 2 root root 4096 Jul 21 19:23 .
drwxr-xr-x 3 root root 4096 Jul 21 18:18 ..
lrwxrwxrwx 1 root root   60 Jul 21 19:23 cert_10.10.20.201 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   60 Jul 21 18:20 cert_10.10.40.126 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   60 Jul 21 18:20 cert_172.16.1.247 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
-rw-r----- 1 root root 3175 Jul 21 18:20 cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 18:20 key_10.10.40.126 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 18:20 key_172.16.1.247 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
-rw-r----- 1 root root 1678 Jul 21 18:20 key_eth2.juju-70b05d-3-lxd-10.maas
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ sudo ln -s /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas cert_10.10.40.201
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ sudo ln -s /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas key_10.10.40.201
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ sudo ln -s /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas key_10.10.20.201
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ ls -la
total 32
dr-xr-xr-x 2 root root 4096 Jul 21 19:24 .
drwxr-xr-x 3 root root 4096 Jul 21 18:18 ..
lrwxrwxrwx 1 root root   60 Jul 21 19:23 cert_10.10.20.201 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   60 Jul 21 18:20 cert_10.10.40.126 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   60 Jul 21 19:23 cert_10.10.40.201 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   60 Jul 21 18:20 cert_172.16.1.247 -> /etc/apache2/ssl/horizon/cert_eth2.juju-70b05d-3-lxd-10.maas
-rw-r----- 1 root root 3175 Jul 21 18:20 cert_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 19:24 key_10.10.20.201 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 18:20 key_10.10.40.126 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 19:24 key_10.10.40.201 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
lrwxrwxrwx 1 root root   59 Jul 21 18:20 key_172.16.1.247 -> /etc/apache2/ssl/horizon/key_eth2.juju-70b05d-3-lxd-10.maas
-rw-r----- 1 root root 1678 Jul 21 18:20 key_eth2.juju-70b05d-3-lxd-10.maas
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ sudo systemctl start apache2
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
ubuntu@juju-70b05d-3-lxd-10:/etc/apache2/ssl/horizon$ sudo systemctl status apache2
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2020-07-21 19:24:27 UTC; 4s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 139830 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 139834 (apache2)
      Tasks: 107 (limit: 38355)
     Memory: 32.8M
     CGroup: /system.slice/apache2.service
             ├─139834 /usr/sbin/apache2 -k start
             ├─139835 (wsgi:horizon)    -k start
             ├─139836 (wsgi:horizon)    -k start
             ├─139837 (wsgi:horizon)    -k start
             ├─139838 (wsgi:horizon)    -k start
             ├─139839 /usr/sbin/apache2 -k start
             └─139840 /usr/sbin/apache2 -k start

Jul 21 19:24:27 juju-70b05d-3-lxd-10 systemd[1]: Starting The Apache HTTP Server...
Jul 21 19:24:27 juju-70b05d-3-lxd-10 apachectl[139833]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/default-ssl.conf:3
Jul 21 19:24:27 juju-70b05d-3-lxd-10 systemd[1]: Started The Apache HTTP Server.

3番目の方法は、作成者が怠惰に使用した関連ユニットを削除してから、関連ユニットを再デプロイすることです。

メインのキーストーンユニットを削除し、新しいユニットを追加します。新しく追加したキーストーンユニットが追加されていないことが判明すると、openstackダッシュボードは通常の状態に戻ります。

しばらくすると、openstackダッシュボードに再度ログオンできなくなります。バックグラウンドを確認した後、Keystoneはエンドポイントを更新しています。しばらくすると、openstackダッシュボードにログオンできます。


20210326日更新:

現在、SSL配信プロセスにバグがあり、修正されていないことが深刻に疑われています。

最初にインフラストラクチャの高可用性を展開した後、ボールトのブロックを解除し、次のテストの後に結論を出す必要があります。

おすすめ

転載: blog.csdn.net/m0_49212388/article/details/114074572