1
2
3
4
5
6
7
作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

Overcloud概述

Overcloud 可是个厉害的角色，它就像是一个“超级英雄”，专门用来搞定生产环境里的虚拟机和超大规模的 Web 应用部署。想象一下，你有一个庞大的云平台，需要快速、高效地部署各种资源，Overcloud 就是你的得力助手。

Red Hat 支持的 Overcloud 是由 Undercloud Director 节点用 TripleO 部署服务搭建起来的。简单来说，Undercloud 就像是一个“大管家”，负责把 Overcloud 的各个节点安排得明明白白。

部署模板

这些 Overcloud 节点可不是普通的家伙，它们都有自己的“超能力”，也就是它们的角色。每个节点都被配置成特定的角色，比如控制器、计算节点或者存储节点，这样它们就能各司其职，把整个云平台搞得井井有条。

这些角色的定义可不是随便写的，它们都藏在一个很酷的地方——/usr/share/openstack-tripleo-heat-templates/roles 目录里。这个目录就像是一个“宝库”，里面藏着所有节点角色的秘密配方。

查看默认的角色和已部署的角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
(undercloud) [stack@director ~]$ ls /usr/share/openstack-tripleo-heat-templates/roles/
BlockStorage.yaml       ComputeHCI.yaml             ComputeRBDEphemeral.yaml          ControllerOpenstack.yaml            DistributedCompute.yaml  Novacontrol.yaml
CellController.yaml     ComputeInstanceHA.yaml      ComputeRealTime.yaml              ControllerSriov.yaml                HciCephAll.yaml          ObjectStorage.yaml
CephAll.yaml            ComputeLiquidio.yaml        ComputeSriovIB.yaml               ControllerStorageDashboard.yaml     HciCephFile.yaml         README.rst
CephFile.yaml           ComputeLocalEphemeral.yaml  ComputeSriovRT.yaml               ControllerStorageNfs.yaml           HciCephMon.yaml          Standalone.yaml
CephObject.yaml         ComputeOvsDpdkRT.yaml       ComputeSriov.yaml                 Controller.yaml                     HciCephObject.yaml       Telemetry.yaml
CephStorage.yaml        ComputeOvsDpdkSriovRT.yaml  Compute.yaml                      Database.yaml                       IronicConductor.yaml     UndercloudMinion.yaml
ComputeAlt.yaml         ComputeOvsDpdkSriov.yaml    ControllerAllNovaStandalone.yaml  DistributedComputeHCIScaleOut.yaml  Messaging.yaml           Undercloud.yaml
ComputeDVR.yaml         ComputeOvsDpdk.yaml         ControllerNoCeph.yaml             DistributedComputeHCI.yaml          NetworkerSriov.yaml
ComputeHCIOvsDpdk.yaml  ComputePPC64LE.yaml         ControllerNovaStandalone.yaml     DistributedComputeScaleOut.yaml     Networker.yaml
(undercloud) [stack@director ~]$ ls /usr/share/openstack-tripleo-heat-templates/roles/ | wc -l
52
(undercloud) [stack@director ~]$ grep '^- name:' ~/templates/roles_data.yaml
- name: Controller
- name: Compute
- name: CephStorage
- name: ComputeHCI

Controller

Controller 节点就像是整个云平台的“大脑”，它负责掌控全局。它加载了所有核心服务，是整个控制平面的核心。它提供各种服务的 API 接口，处理数据库操作、消息传递，还负责网络相关的工作。简单来说，Controller 节点就像是一个指挥官，指挥着整个云平台的运作。

Compute

Compute 节点就是标准的计算节点，它的主要任务是作为虚拟机的“宿主”，运行那些已经部署好的虚拟机实例和堆栈。你可以把它想象成一个“超级房东”，为虚拟机提供运行的“房子”，确保它们能够正常运行。

CephStorage

CephStorage 节点是专门用来做存储的“仓库”。它使用容器化的红帽 Ceph 存储服务器，并且配备了多个对象存储磁盘（OSD）。这些磁盘就像是一个个“保险箱”，用来存储数据，确保数据的安全性和高效访问。

ComputeHCI

ComputeHCI 节点有点像一个“多面手”，它结合了计算和存储的功能。它不仅是一个计算节点，可以运行虚拟机，还具备 Ceph OSD 的功能，可以存储数据。这种超融合基础架构的设计让它在资源利用上更加高效，就像是一个“二合一”的设备，既节省空间又提高效率。

OpenStack 常见服务

块存储服务（Cinder）

Cinder 是 OpenStack 的块存储服务，它提供持久化的块存储设备给虚拟机使用。你可以把它想象成一个“硬盘分配器”，它能为虚拟机分配独立的存储空间，确保数据的安全性和持久性。

镜像服务（Glance）

Glance 是镜像服务，它负责存储和管理虚拟机的镜像文件。这些镜像文件就像是虚拟机的“模板”，包含了操作系统和预装软件。Glance 确保这些模板安全存储，并且可以随时被用来创建新的虚拟机。

编排服务（Heat）

Heat 是 OpenStack 的编排服务，它通过 YAML 模板定义和管理资源的部署。你可以把它想象成一个“自动化工程师”，它可以根据预定义的模板自动创建和配置虚拟机、网络和其他资源。

仪表板服务（Horizon）

Horizon 是 OpenStack 的 Web 仪表板，它提供了一个图形化界面，让用户可以轻松管理云资源。你可以把它想象成一个“控制台”，通过它，用户可以创建虚拟机、管理网络、查看资源使用情况等。

身份服务（Keystone）

Keystone 是 OpenStack 的身份服务，它负责用户的身份验证和授权。你可以把它想象成一个“门卫”，它确保只有经过授权的用户才能访问云资源。

OpenStack 联网服务（Neutron）

Neutron 是 OpenStack 的联网服务，它负责管理虚拟网络。你可以把它想象成一个“网络工程师”，它负责创建虚拟网络、子网、路由器等，确保虚拟机之间可以正常通信。

计算服务（Nova）

Nova 是 OpenStack 的计算服务，它负责管理虚拟机的生命周期。你可以把它想象成一个“虚拟机管理员”，它负责创建、启动、停止和删除虚拟机。

消息传递服务（Oslo）

Oslo 是 OpenStack 的消息传递服务，它提供了一个通用的消息传递框架，用于组件之间的通信。你可以把它想象成一个“邮递员”，它确保各个服务之间的消息能够快速、准确地传递。

对象存储（Swift）

Swift 是 OpenStack 的对象存储服务，它提供了一个可扩展的存储解决方案，用于存储大量的对象数据。你可以把它想象成一个“大型仓库”，它能够安全地存储大量的文件和数据。

裸机恢复服务（Ironic）

Ironic 是 OpenStack 的裸机恢复服务，它负责管理和部署物理服务器。你可以把它想象成一个“硬件管理员”，它能够远程控制物理服务器的电源，并进行操作系统安装和配置。

文件共享服务（Manila）

Manila 是 OpenStack 的文件共享服务，它提供了一个共享文件系统，多个虚拟机可以同时访问。你可以把它想象成一个“共享文件柜”，它允许不同的用户和虚拟机共享和访问文件。

负载平衡服务（Octavia）

Octavia 是 OpenStack 的负载平衡服务，它负责在多个虚拟机之间分配网络流量，确保服务的高可用性。你可以把它想象成一个“交通警察”，它能够智能地分配流量，确保网络的顺畅运行。

管理 Overcloud

列出overcloud节点

先看看都有哪些overcloud节点

1
2
3
4
5
6
7
8
9
10
(undercloud) [stack@director ~]$ openstack server list
+--------------------------------------+-------------+--------+------------------------+----------------+-----------+
| ID                                   | Name        | Status | Networks               | Image          | Flavor    |
+--------------------------------------+-------------+--------+------------------------+----------------+-----------+
| 6d712d0a-cb71-4cdc-93dc-f2d69ffc520b | controller0 | ACTIVE | ctlplane=172.25.249.56 | overcloud-full | baremetal |
| b4410745-55a6-490a-baab-803ea4eb9e64 | computehci0 | ACTIVE | ctlplane=172.25.249.54 | overcloud-full | baremetal |
| b87aaecb-3726-4afc-ab81-43d6a62ca7f0 | compute1    | ACTIVE | ctlplane=172.25.249.53 | overcloud-full | baremetal |
| 0d1b6dc2-361c-4276-9ee4-dd2dd387d075 | compute0    | ACTIVE | ctlplane=172.25.249.59 | overcloud-full | baremetal |
| 3f690637-f062-4f7c-baa6-88ab794bac17 | ceph0       | ACTIVE | ctlplane=172.25.249.58 | overcloud-full | baremetal |
+--------------------------------------+-------------+--------+------------------------+----------------+-----------+

Overcloud 服务⾼可⽤性

在高可用性的 Overcloud 部署里，Overcloud 是由一群控制器节点组成的“超级团队”。RHOSP Director 在每个控制器节点上都安装了一套重复的 OpenStack 组件，然后把它们当作一个整体来管理。这就像是给每个节点都配备了相同的“超能力”，确保整个系统即使遇到问题也能正常运行。

红帽 OpenStack 平台用了一些很酷的技术来保证高可用性。它用 Pacemaker 来管理集群资源，就像是有一个“超级管理员”在时刻盯着，确保每个资源都能正常工作。如果某个节点出了问题，Pacemaker 就会迅速介入，把任务分配给其他节点。

还有 HAProxy，它是个“超级交通警察”，负责在多个节点之间分配网络流量，确保服务的高可用性。而 MariaDB Galera 则是个“超级数据库”，它通过复制数据，确保数据的安全性和一致性。

为了让 OpenStack 客户端能够访问这些服务，Pacemaker 为每个资源都设置了一个虚拟 IP 地址。这就像是给每个服务配了一个“超级地址”，客户端只需要找到这个地址，就能顺利访问服务。如果某个控制器节点出了问题，这个虚拟 IP 地址就会自动跳转到其他健康的节点上，确保服务不会中断。

不过呢，咱们这个课堂环境有点特殊，为了节约资源，我们只有一个控制器节点。虽然只有一个节点，但 Pacemaker 依然会正常工作，确保我们的系统稳定运行。

如果你想看看 Pacemaker 的状态，可以用 pcs status 命令。这个命令会列出常规的 Pacemaker 信息、虚拟 IP 地址、服务状态和其他相关信息。简单来说，它就像是一个“体检报告”，能让你清楚地了解整个集群的健康状况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
[root@controller0 ~]# pcs status
Cluster name: tripleo_cluster
Cluster Summary:
  * Stack: corosync
  * Current DC: controller0 (version 2.0.3-5.el8_2.1-4b1f869f0f) - partition with quorum
  * Last updated: Mon Jan  1 12:21:49 2024
  * Last change:  Mon Jan 24 14:09:44 2022 by root via crm_resource on controller0
  * 5 nodes configured
  * 22 resource instances configured

Node List:
  * Online: [ controller0 ]
  * GuestOnline: [ galera-bundle-0@controller0 ovn-dbs-bundle-0@controller0 rabbitmq-bundle-0@controller0 redis-bundle-0@controller0 ]

Full List of Resources:
  * Container bundle: galera-bundle [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-mariadb:pcmklatest]:
    * galera-bundle-0   (ocf::heartbeat:galera):        Master controller0
  * Container bundle: rabbitmq-bundle [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-rabbitmq:pcmklatest]:
    * rabbitmq-bundle-0 (ocf::heartbeat:rabbitmq-cluster):      Started controller0
  * Container bundle: redis-bundle [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-redis:pcmklatest]:
    * redis-bundle-0    (ocf::heartbeat:redis): Master controller0
  * ip-172.25.249.50    (ocf::heartbeat:IPaddr2):       Started controller0
  * ip-172.25.250.50    (ocf::heartbeat:IPaddr2):       Started controller0
  * ip-172.24.1.51      (ocf::heartbeat:IPaddr2):       Started controller0
  * ip-172.24.1.50      (ocf::heartbeat:IPaddr2):       Started controller0
  * ip-172.24.3.50      (ocf::heartbeat:IPaddr2):       Started controller0
  * ip-172.24.4.50      (ocf::heartbeat:IPaddr2):       Started controller0
  * Container bundle: haproxy-bundle [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-haproxy:pcmklatest]:
    * haproxy-bundle-podman-0   (ocf::heartbeat:podman):        Started controller0
  * Container bundle: ovn-dbs-bundle [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-ovn-northd:pcmklatest]:
    * ovn-dbs-bundle-0  (ocf::ovn:ovndb-servers):       Master controller0
  * ip-172.24.1.52      (ocf::heartbeat:IPaddr2):       Started controller0
  * Container bundle: openstack-cinder-volume [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-cinder-volume:pcmklatest]:
    * openstack-cinder-volume-podman-0  (ocf::heartbeat:podman):        Started controller0
  * Container bundle: openstack-manila-share [cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-manila-share:pcmklatest]:
    * openstack-manila-share-podman-0   (ocf::heartbeat:podman):        Started controller0

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

访问 Overcloud 上的服务

先将环境变量切换到overcloud才能访问

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
(undercloud) [stack@director ~]$ source overcloudrc
(overcloud) [stack@director ~]$ env | grep OS_
OS_IMAGE_API_VERSION=2
OS_AUTH_URL=http://172.25.250.50:5000
OS_CLOUDNAME=overcloud
OS_REGION_NAME=regionOne
OS_PROJECT_NAME=admin
OS_PROJECT_DOMAIN_NAME=Default
OS_USER_DOMAIN_NAME=Default
OS_IDENTITY_API_VERSION=3
OS_AUTH_TYPE=password
OS_NO_CACHE=True
OS_COMPUTE_API_VERSION=2.latest
OS_PASSWORD=redhat
PS1=${OS_CLOUDNAME:+($OS_CLOUDNAME)} [\u@\h \W]\$
OS_USERNAME=admin
OS_VOLUME_API_VERSION=3

看看overcloud里部署了什么服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
(overcloud) [stack@director ~]$ openstack service list
+----------------------------------+-----------+----------------+
| ID                               | Name      | Type           |
+----------------------------------+-----------+----------------+
| 0932e03c896a4e73b905b81a0e4e8b02 | cinderv2  | volumev2       |
| 1b5a14e5ff2d4d988dcbb7d1a31aa257 | panko     | event          |
| 1e50893246094c05b0b8b5028efa65d6 | heat      | orchestration  |
| 20ee8664c18146639e207d1dd833066b | heat-cfn  | cloudformation |
| 2ed07d8f7afd4126b279bd273d029962 | gnocchi   | metric         |
| 31442049b55040d5bb52589e0fd1b31f | nova      | compute        |
| 446c6d0b77a74d05a491393c8d4cc106 | keystone  | identity       |
| 76870267b75a4d0bb70772f586730659 | neutron   | network        |
| 8413046b29f44285a772a8bbd172dbd8 | manilav2  | sharev2        |
| bb7a5e08aad345a489ce0207684ae402 | swift     | object-store   |
| c970fbfbc71a49008760c6d9a6f3ee91 | aodh      | alarming       |
| cc386f44375343d19e1fc78e8e78db35 | cinderv3  | volumev3       |
| cddaafd6d76b424b946a8fdb47a8ed12 | manila    | share          |
| d799151c504541edacd68a08324d37c0 | glance    | image          |
| e15d67325321405b854447a92bfe866f | octavia   | load-balancer  |
| f8ebce21244748c09b20df6e9c939b73 | placement | placement      |
+----------------------------------+-----------+----------------+

看看overcloud的网络信息

eth0有249段的置备网络，br-ex拥有外部网络250网段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@controller0 ~]# ip -br address
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             172.25.249.56/24 172.25.249.50/32 fe80::5054:ff:fe00:f901/64
eth1             UP             fe80::5054:ff:fe01:1/64
eth2             UP             fe80::5054:ff:fe02:fa01/64
eth3             UP             fe80::5054:ff:fe03:1/64
eth4             UP             fe80::5054:ff:fe04:1/64
ovs-system       DOWN
br-prov1         UNKNOWN        fe80::5054:ff:fe03:1/64
genev_sys_6081   UNKNOWN        fe80::90f2:c5ff:fe42:a3ca/64
o-hm0            UNKNOWN        172.23.3.42/16 fe80::f816:3eff:fecd:dfd4/64
br-int           UNKNOWN        fe80::40e:d7ff:fe34:2944/64
br-ex            UNKNOWN        172.25.250.1/24 172.25.250.50/32 fe80::5054:ff:fe02:fa01/64
br-prov2         UNKNOWN        fe80::5054:ff:fe04:1/64
vlan10           UNKNOWN        172.24.1.1/24 172.24.1.51/32 172.24.1.50/32 172.24.1.52/32 fe80::ce8:c3ff:fe62:6f05/64
vlan20           UNKNOWN        172.24.2.1/24 fe80::d45d:caff:fe1f:4b5d/64
vlan40           UNKNOWN        172.24.4.1/24 172.24.4.50/32 fe80::84eb:a7ff:fe6d:657d/64
vlan50           UNKNOWN        172.24.5.1/24 fe80::581f:bdff:fed0:428b/64
vlan30           UNKNOWN        172.24.3.1/24 172.24.3.50/32 fe80::105b:8bff:fe61:2f9d/64
br-trunk         UNKNOWN        fe80::5054:ff:fe01:1/64

查看服务容器配置

1
2
3
4
5
6
7
8
[root@controller0 ~]# podman ps --format "table {{.Names}} {{.Status}}"
Names                              Status
openstack-manila-share-podman-0    Up 2 hours ago
openstack-cinder-volume-podman-0   Up 2 hours ago
ovn-dbs-bundle-podman-0            Up 2 hours ago
haproxy-bundle-podman-0            Up 2 hours ago
rabbitmq-bundle-podman-0           Up 2 hours ago
...

使⽤ podman inspect 命令来检查容器化服务的容器主机配置

可以看到很多细节

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@controller0 ~]# podman inspect keystone | jq .[].HostConfig.Binds
[
  "/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro,rprivate,rbind",
  "/etc/puppet:/etc/puppet:ro,rprivate,rbind",
  "/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro,rprivate,rbind",
  "/var/lib/config-data/puppet-generated/keystone:/var/lib/kolla/config_files/src:ro,rprivate,rbind",
  "/var/log/containers/keystone:/var/log/keystone:rw,rprivate,rbind",
  "/dev/log:/dev/log:rw,rprivate,nosuid,rbind",
  "/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro,rprivate,rbind",
  "/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro,rprivate,rbind",
  "/var/log/containers/httpd/keystone:/var/log/httpd:rw,rprivate,rbind",
  "/etc/localtime:/etc/localtime:ro,rprivate,rbind",
  "/etc/pki/ca-trust/source/anchors:/etc/pki/ca-trust/source/anchors:ro,rprivate,rbind",
  "/var/lib/kolla/config_files/keystone.json:/var/lib/kolla/config_files/config.json:ro,rprivate,rbind",
  "/etc/hosts:/etc/hosts:ro,rprivate,rbind"
]

容器化服务的配置管理

不要进入到容器中改配置文件，不让容器一旦restart，你改的就丢失了，你要去物理机上改，改完再restart容器生效

配置文件路径为：/var/lib/config-data/puppet-generated/服务/etc

除了手工vim修改外，也可以用crudini命令

1
2
3
4
5
6
7
8
9
10
11
[root@controller0 puppet-generated]# podman exec -it keystone crudini --get /etc/keystone/keystone.conf DEFAULT debug
False
[root@controller0 puppet-generated]# crudini --get keystone/etc/keystone/keystone.conf DEFAULT debug
False
[root@controller0 puppet-generated]# crudini --set keystone/etc/keystone/keystone.conf DEFAULT debug True
[root@controller0 puppet-generated]# crudini --get keystone/etc/keystone/keystone.conf DEFAULT debug
True
[root@controller0 puppet-generated]# podman restart keystone
8f5f7908f01d3500d412c3168da68f0eec736e6e10c535a342c0778b884ae7c5
[root@controller0 puppet-generated]# podman exec -it keystone crudini --get /etc/keystone/keystone.conf DEFAULT debug
True

⽇志⽂件存储在 /var/log/containers/服务中

1
2
3
4
5
6
7
8
9
[root@controller0 puppet-generated]# cd /var/log/containers/keystone/
[root@controller0 keystone]# ls
keystone.log  keystone.log.1
[root@controller0 keystone]# tail -n 5 keystone.log
2024-01-01 12:46:08.651 25 DEBUG keystone.server.flask.request_processing.req_logging [req-10652ad7-b1da-410f-ba9d-b88a7bb4cb36 - - - - -] SCRIPT_NAME: `` log_request_info /usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/req_logging.py:28
2024-01-01 12:46:08.651 25 DEBUG keystone.server.flask.request_processing.req_logging [req-10652ad7-b1da-410f-ba9d-b88a7bb4cb36 - - - - -] PATH_INFO: `/v3` log_request_info /usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/req_logging.py:29
2024-01-01 12:46:08.652 25 DEBUG keystone.server.flask.request_processing.req_logging [req-3e36b5eb-1dee-4354-96b7-d3a2d872d9db - - - - -] REQUEST_METHOD: `GET` log_request_info /usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/req_logging.py:27
2024-01-01 12:46:08.652 25 DEBUG keystone.server.flask.request_processing.req_logging [req-3e36b5eb-1dee-4354-96b7-d3a2d872d9db - - - - -] SCRIPT_NAME: `` log_request_info /usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/req_logging.py:28
2024-01-01 12:46:08.652 25 DEBUG keystone.server.flask.request_processing.req_logging [req-3e36b5eb-1dee-4354-96b7-d3a2d872d9db - - - - -] PATH_INFO: `/v3` log_request_info /usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/req_logging.py:29

较为实时的内存日志位于：/var/log/containers/stdouts

这些较为实时的日志除了cat tail之外，也可以podman logs xxxx

1
2
3
4
5
6
7
8
9
10
11
[root@controller0 stdouts]# tail keystone.log
2024-01-01T12:43:56.191771909+00:00 stderr F ++ . /usr/local/bin/kolla_httpd_setup
2024-01-01T12:43:56.191906902+00:00 stderr F ++++ whoami
2024-01-01T12:43:56.193585090+00:00 stderr F +++ [[ root == \r\o\o\t ]]
2024-01-01T12:43:56.193585090+00:00 stderr F +++ [[ rhel =~ debian|ubuntu ]]
2024-01-01T12:43:56.193585090+00:00 stderr F +++ rm -rf '/var/run/httpd/*' '/run/httpd/*' '/tmp/httpd*'
2024-01-01T12:43:56.199485843+00:00 stdout F Running command: '/usr/sbin/httpd -DFOREGROUND'
2024-01-01T12:43:56.199495470+00:00 stderr F +++ [[ rhel = centos ]]
2024-01-01T12:43:56.199495470+00:00 stderr F ++ ARGS=-DFOREGROUND
2024-01-01T12:43:56.199495470+00:00 stderr F + echo 'Running command: '\''/usr/sbin/httpd -DFOREGROUND'\'''
2024-01-01T12:43:56.199495470+00:00 stderr F + exec /usr/sbin/httpd -DFOREGROUND

查看 Controller 节点上的 Ceph 服务

1
2
3
4
[root@controller0 stdouts]# podman ps --format "{{.Names}}" | grep ceph
ceph-mds-controller0
ceph-mon-controller0
ceph-mgr-controller0
1
2
3
4
[root@controller0 stdouts]# systemctl list-units | grep ceph
ceph-mds@controller0.service          loaded active     running         Ceph MDS
ceph-mgr@controller0.service          loaded active     running         Ceph Manager
ceph-mon@controller0.service          loaded active     running         Ceph Monitor

看看有哪些存储池

1
2
3
4
5
6
7
8
9
10
[root@controller0 stdouts]# systemctl status ceph-mon@controller.service
● ceph-mon@controller.service - Ceph Monitor
   Loaded: loaded (/etc/systemd/system/ceph-mon@.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
[root@controller0 stdouts]# podman exec ceph-mon-controller0 ceph osd pool ls
vms
volumes
images
manila_data
manila_metadata

看看ceph集群是否健康

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@controller0 stdouts]# podman exec ceph-mon-controller0 ceph -s
  cluster:
    id:     96157d2f-395f-4a54-8a19-b6042465100d
    health: HEALTH_OK

  services:
    mon: 1 daemons, quorum controller0 (age 2h)
    mgr: controller0(active, since 2h)
    mds: cephfs:1 {0=controller0=up:active}
    osd: 6 osds: 6 up (since 2h), 6 in (since 3y)

  task status:
    scrub status:
        mds.controller0: idle

  data:
    pools:   5 pools, 320 pgs
    objects: 2.37k objects, 18 GiB
    usage:   24 GiB used, 96 GiB / 120 GiB avail
    pgs:     320 active+clean

后续学习了Ceph课程后，可以了解更多ceph命令，我们这里是OpenStack内容为主哦