- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

金鱼哥RHCA回忆录：CL210红帽OpenStack平台架构--介绍overcloud

金鱼哥发表于 2022/07/12 18:04:55 2022/07/12

【摘要】第一章红帽OpenStack平台架构--介绍overcloud

🎹 个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区·专家博主
📚个人资质：CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必须努力🔥

🎈支持我：可点赞👍、可收藏⭐️、可留言📝

云上（overcloud）节点使用专用的、隔离的供应网络从云下（undercloud）节点部署。在构建时，overcloud是一个具有许多交互组件的生产基础设施。Red Hat OpenStack Director还执行诸如向上和向下扩展的更新和升级、变更管理和遵从性等活动。因此，在安装overcloud之后，不打算卸载或唾弃undercloud系统。目前，undercloud可以安装一个栈名为overcloud的单一overcloud

overcloud通常由预定义的角色组成，比如控制器、计算和不同的存储角色。每个缺省角色都包含一组由用于部署overcloud的业务流程模板定义的服务。这些角色在/usr/share/openstack-tripleo-heat-templates/roles_data.yaml模板文件中定义。

(overcloud) [stack@director ~]$ grep '^- name:' /usr/share/openstack-tripleo-heat-templates/roles_data.yaml
- name: Controller
- name: Compute
- name: BlockStorage
- name: ObjectStorage
- name: CephStorage

红帽OpenStack平台也提供了一个预定义的自定义角色，名为ComputeHCI，它在超融合节点上部署计算服务和Ceph OSD服务。要使用ComputeHCI角色，您需要生成一个自定义的包含此角色的roles_data.yaml文件，以及计划在overcloud部署中使用的所有其他角色。

📜overcloud包含了9个主要模块

📑Identity Service (keystone)

📑Image Service (glance)

📑Compute Service (nova)

📑Bare Metal Service (ironic)

📑Orchestration Service (heat)

📑Object store (swift)

📑Block Storage（cinder）

📑OpenStack Networking Service (neutron)

📑Dashboard（horizon）

📜控制器节点上的其他支持服务

Overcloud控制器节点还提供其他服务

📑测量及数据收集服务(ceilometer)

数据收集服务监视消息总线，以获取由不同的OpenStack服务(如计算、镜像、块存储、编排、标识等)发送的数据。然后，各种插件对消息进行处理，将其转换为事件和示例。计量数据由通知和轮询代理收集。轮询代理运行在所有的云上节点上，轮询OpenStack基础设施资源(比如hypervisor)，以便在通知总线上发布计量表。通知代理在控制器节点上运行，侦听OpenStack通知总线上的通知，并将它们转换为计量事件和示例。

📑度量服务(gnocchi)

度量服务是一个时间序列数据库，用于存储由数据收集服务发布的度量和资源。对时间序列数据库进行了优化，用于处理包含按时间戳索引的数字数组的数据。度量服务提供了一个REST API来创建或编辑度量数据，以及洞察云使用、计费、放置、退款和容量规划。

📑负载均衡服务(octavia)

负载均衡服务允许将流量分配到两个或多个实例，以便多层体系结构能够管理动态流量负载。这个服务被设计来创建一个独立的负载均衡组件，以取代原来的网络服务器(neutron)LBaaS项目，它是基于HAProxy的。提供以虚拟机、容器或裸机服务器(统称为amphorae)的形式管理负载均衡服务，这些服务按需进行调整，提供更强的水平伸缩性。使用OpenStack网络、compute、image、identity和messaging服务在overcloud的控制器节点和计算节点上运行。

📑共享文件系统服务(manila)

共享文件存储服务是一种安全的File-Share-as-a-Service（文件共享即服务）。它使用NFS和CIFS协议来共享文件系统。可以将其配置为在单节点后端或跨多个节点运行。

📑工作流服务(mistral)

工作流服务用于定义称为工作流的复杂多步骤流程中的一组任务和关系。工作流是容错的，因此，如果任务执行在一个节点上的某个点崩溃，那么系统的另一个活动节点可以自动接管，并从它停止的同一点继续。工作流服务为overcloud上需要的常见操作(如rotating Fernet keys)，提供了预先构建的工作流。

📑通讯服务(zaqar)

通讯服务提供了在其应用程序的各种组件之间发送消息的能力。它是一个高效的通讯引擎，在设计时考虑了可伸缩性和安全性。其他OpenStack组件与消息传递服务集成，以便向最终用户显示事件，并与运行在overcloud的客户端通信。

📜计算节点上的OpenStack核心服务

overcloud 计算节点承载启动实例所需的核心服务。计算节点上默认配置的核心服务描述如下:

📑OpenStack网络服务(neutron)

计算节点上的网络服务运行Open vSwitch代理，它创建节点的虚拟网桥。该服务还可以为在计算节点上启动的实例提供元数据服务。

📑计算服务(nova)

OpenStack计算服务支持许多管理程序，比如KVM、QEMU和其他许多管理程序。计算节点运行一个名为nova-compute的工作进程，该进程通过hypervisor APls创建和终止虚拟机实例。

📜计算HCI节点上的OpenStack核心服务

计算HCI（Hyper Converged Infrastructure超级聚合基础设施）节点是一个超级聚合节点，它通过配置Ceph OSD和计算服务提供计算和存储服务。这些节点包含Ceph OSD服务并充当实际存储。节点运行一个计算守护进程，该守护进程负责通过hypervisor APls创建和终止虚拟机实例。

📜Ceph存储节点上的OpenStack核心服务

Red Hat Ceph存储节点为虚拟机实例、镜像、块存储和临时存储提供存储。这些节点包含Ceph OSD服务并充当实际存储。大多数Ceph存储节点使用多个磁盘。Ceph监视器服务在控制器节点上运行。

📜块存储节点上的OpenStack核心服务

块存储节点由使用集成后端管理块存储的创建和删除的块卷服务组成。可以在overcloud上配置和部署集成后端。集成后端包括Red Hat Ceph存储和Dell EqualLogic、Dell存储中心和NetApp设备的单一后端配置。将请求调度和路由到适当节点的块存储调度器服务驻留在控制器节点上。块存储API服务也部署在控制器节点上。

📜使用底层云（undercloud）管理上层云（overcloud）

底层云上的工作流服务可以管理多个部署计划和堆栈。在未来的版本中，undercloud将能够安装、访问和管理多个overclouds。当前支持的正在进行的活动包括：

监控 undercloud 的运行状况。
从 overcloud 收集和存储指标。
验证和缺省新节点以进行 overcloud 扩展。
节点、组件和场景的性能测试。
执行次要的版本更新，比如安全修复。
执行自动化的主要版本升级到红帽 OpenStack 平台。
自动伸缩或替换 HA控制器、存储节点和计算节点。
管理基础设施节点的平台级访问，包括电源管理。

overcloud部署将每个注册节点创建为标准服务器角色或自定义角色之一。要通过SSH访问overcloud服务器，请使用来自undercloud的openstack server list命令，并使用undercloud管理员的凭证来查找所需节点的IP地址：

(undercloud) [stack@director ~]$ openstack server list -c Name -c Status -c Networks
+-------------+--------+------------------------+
| Name        | Status | Networks               |
+-------------+--------+------------------------+
| compute1    | ACTIVE | ctlplane=172.25.249.55 |
| compute0    | ACTIVE | ctlplane=172.25.249.54 |
| computehci0 | ACTIVE | ctlplane=172.25.249.59 |
| controller0 | ACTIVE | ctlplane=172.25.249.57 |
| ceph0       | ACTIVE | ctlplane=172.25.249.58 |
+-------------+--------+------------------------+

使用heat-admin用户浏览这些服务器，vercloud部署过程使用相同的Linux用户帐户来使用SSH访问和配置系统：

(undercloud) [stack@director ~]$ ssh heat-admin@172.25.249.57
Warning: Permanently added '172.25.249.57' (ECDSA) to the list of known hosts.
[heat-admin@controller0 ~]$

在高可用性overcloud部署中，overcloud由集群中的多个控制器节点组成。RHOSP Director在每个控制器节点上安装一组OpenStack组件，并将它们管理为单个服务。Red Hat OpenStack平台使用Pacemaker作为集群资源管理器，HAProxy用于负载均衡集群服务，MariaDB Galera用于数据库复制。Pacemaker管理的每个资源设置一个虚拟IP地址，OpenStack客户端使用该地址请求访问服务。如果分配给该IP地址的控制器节点失败，该IP地址将被重新分配给另一个控制器。

在教室环境中，overcloud在集群中部署一个控制器节点。您可以使用pcs status命令来列出一般起pacemaker信息、虚拟IP地址、服务和其他pacemaker信息。

[heat-admin@controller0 ~]$ sudo pcs status 
Cluster name: tripleo_cluster
Stack: corosync
Current DC: controller0 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Thu Oct 15 03:54:03 2020
Last change: Thu Jan 30 10:15:03 2020 by root via cibadmin on controller0

5 nodes configured
21 resources configured

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

Full list of resources:

 Docker container: rabbitmq-bundle [172.25.249.200:8787/rhosp13/openstack-rabbitmq:pcmklatest]
   rabbitmq-bundle-0	(ocf::heartbeat:rabbitmq-cluster):	Started controller0
 Docker container: galera-bundle [172.25.249.200:8787/rhosp13/openstack-mariadb:pcmklatest]
   galera-bundle-0	(ocf::heartbeat:galera):	Master controller0
 Docker container: redis-bundle [172.25.249.200:8787/rhosp13/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
 Docker container: haproxy-bundle [172.25.249.200:8787/rhosp13/openstack-haproxy:pcmklatest]
   haproxy-bundle-docker-0	(ocf::heartbeat:docker):	Started controller0
 Docker container: ovn-dbs-bundle [172.25.249.200:8787/rhosp13/openstack-ovn-northd:latest]
   ovn-dbs-bundle-0	(ocf::ovn:ovndb-servers):	Master controller0
 Docker container: openstack-cinder-volume [172.25.249.200:8787/rhosp13/openstack-cinder-volume:pcmklatest]
   openstack-cinder-volume-docker-0	(ocf::heartbeat:docker):	Started controller0
 Docker container: openstack-manila-share [172.25.249.200:8787/rhosp13/openstack-manila-share:pcmklatest]
   openstack-manila-share-docker-0	(ocf::heartbeat:docker):	Stopped
…………

📜访问Overcloud上的服务

当overcloud安装完成时，它在用户的主目录下创建overcloudrc身份环境文件，该文件带有访问overcloud的管理凭证。您可以使用OpenStack CLI客户端overcloudrc源文件来与overcloud服务交互。

在教室环境中，overcloudrc文件中的OS_AUTH_URL环境变量被设置为在overcloud上运行的身份服务的公共端点。身份服务公共端点是被确认用于访问服务的虚拟IP地址。教室环境对overcloud上的OpenStack服务的所有公共端点使用非SSL。

(overcloud) [stack@director ~]$ openstack endpoint list -c 'Service Type' -c Interface -c URL
+----------------+-----------+-------------------------------------------------+
| Service Type   | Interface | URL                                             |
+----------------+-----------+-------------------------------------------------+
| load-balancer  | public    | http://172.25.250.50:9876                       |
| network        | admin     | http://172.24.1.50:9696                         |
| sharev2        | public    | http://172.25.250.50:8786/v2/%(tenant_id)s      |
| volumev3       | public    | http://172.25.250.50:8776/v3/%(tenant_id)s      |
| identity       | public    | http://172.25.250.50:5000                       |
| metric         | public    | http://172.25.250.50:8041                       |
| event          | admin     | http://172.24.1.50:8977                         |
| orchestration  | public    | http://172.25.250.50:8004/v1/%(tenant_id)s      |
| share          | public    | http://172.25.250.50:8786/v1/%(tenant_id)s      |
| share          | admin     | http://172.24.1.50:8786/v1/%(tenant_id)s        |
| event          | public    | http://172.25.250.50:8977                       |
| compute        | admin     | http://172.24.1.50:8774/v2.1                    |
| volume         | internal  | http://172.24.1.50:8776/v1/%(tenant_id)s        |
| share          | internal  | http://172.24.1.50:8786/v1/%(tenant_id)s        |
| placement      | public    | http://172.25.250.50:8778/placement             |
| placement      | internal  | http://172.24.1.50:8778/placement               |
| alarming       | public    | http://172.25.250.50:8042                       |
| volumev2       | internal  | http://172.24.1.50:8776/v2/%(tenant_id)s        |
| orchestration  | admin     | http://172.24.1.50:8004/v1/%(tenant_id)s        |
| volume         | admin     | http://172.24.1.50:8776/v1/%(tenant_id)s        |
| sharev2        | internal  | http://172.24.1.50:8786/v2/%(tenant_id)s        |
| cloudformation | public    | http://172.25.250.50:8000/v1                    |
| metric         | admin     | http://172.24.1.50:8041                         |
| identity       | admin     | http://172.25.249.50:35357                      |
| object-store   | admin     | http://172.24.3.50:8080                         |
| image          | admin     | http://172.24.1.50:9292                         |
| volumev2       | admin     | http://172.24.1.50:8776/v2/%(tenant_id)s        |
| object-store   | internal  | http://172.24.3.50:8080/v1/AUTH_%(tenant_id)s   |
| network        | internal  | http://172.24.1.50:9696                         |
| network        | public    | http://172.25.250.50:9696                       |
| cloudformation | admin     | http://172.24.1.50:8000/v1                      |
| compute        | public    | http://172.25.250.50:8774/v2.1                  |
| orchestration  | internal  | http://172.24.1.50:8004/v1/%(tenant_id)s        |
| alarming       | internal  | http://172.24.1.50:8042                         |
| identity       | internal  | http://172.24.1.50:5000                         |
| event          | internal  | http://172.24.1.50:8977                         |
| cloudformation | internal  | http://172.24.1.50:8000/v1                      |
| load-balancer  | admin     | http://172.24.1.50:9876                         |
| placement      | admin     | http://172.24.1.50:8778/placement               |
| alarming       | admin     | http://172.24.1.50:8042                         |
| image          | public    | http://172.25.250.50:9292                       |
| image          | internal  | http://172.24.1.50:9292                         |
| volumev2       | public    | http://172.25.250.50:8776/v2/%(tenant_id)s      |
| load-balancer  | internal  | http://172.24.1.50:9876                         |
| volumev3       | internal  | http://172.24.1.50:8776/v3/%(tenant_id)s        |
| volumev3       | admin     | http://172.24.1.50:8776/v3/%(tenant_id)s        |
| compute        | internal  | http://172.24.1.50:8774/v2.1                    |
| volume         | public    | http://172.25.250.50:8776/v1/%(tenant_id)s      |
| object-store   | public    | http://172.25.250.50:8080/v1/AUTH_%(tenant_id)s |
| metric         | internal  | http://172.24.1.50:8041                         |
| sharev2        | admin     | http://172.24.1.50:8786/v2/%(tenant_id)s        |
+----------------+-----------+-------------------------------------------------+

📜查看overcloud上的网络服务

Red Hat OpenStack Platform Director网络使用PXE引导部署新节点，并在裸机服务器上编排overcloud安装。在默认的overcloud部署中，将服务分配给已配置的供应网络。然而，Director可以将overcloud网络流量划分为几个独立的网络。这些隔离的网络可以配置为使用不同的网络接口，也可以使用vlan隔离。在教室环境中，公共网络配置在一个单独的网络接口上，而内部overcloud网络使用vlan进行隔离。供应网络用于节点的电源管理。课堂环境中的网络流量类型描述如下：

查看overcloud配置的网络接口。eth0口是172.25.249.0供应网络；br-ex 网桥是172.25.250.0公共网络。

[heat-admin@controller0 ~]$ ip addr | egrep 'eth0|br-ex'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.25.249.57/24 brd 172.25.249.255 scope global eth0
    inet 172.25.249.50/32 brd 172.25.249.255 scope global eth0
13: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 172.25.250.1/24 brd 172.25.250.255 scope global br-ex
    inet 172.25.250.50/32 brd 172.25.250.255 scope global br-ex

br-trunk网桥包含内部OpenStack网络流量的独立vlan。

[heat-admin@controller0 ~]$ sudo ovs-vsctl show
6c237e8b-5014-42f1-9ac4-cc7728797597
    Bridge br-trunk
        fail_mode: standalone
        Port "eth1"
            Interface "eth1"
        Port "vlan30"
            tag: 30
            Interface "vlan30"
                type: internal
        Port "vlan40"
            tag: 40
            Interface "vlan40"
                type: internal
        Port "vlan50"
            tag: 50
            Interface "vlan50"
                type: internal
        Port "vlan20"
            tag: 20
            Interface "vlan20"
                type: internal
        Port br-trunk
            Interface br-trunk
                type: internal
        Port "vlan10"
            tag: 10
            Interface "vlan10"
                type: internal

运行以下命令以确保网络处于活动状态，并且有正在积极侦听IP地址的服务。在下面的输出中，ip命令显示了存储VLAN (vlan30)接口正在侦听的ip地址。netstat命令显示在存储VLAN接口上监听的进程。侦听的进程VLAN接口是：Ceph monitor, Ceph MDS，和Ceph manager，还有一个ntp进程监听端口123。

[heat-admin@controller0 ~]$ ip addr show vlan30
17: vlan30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether ba:86:bd:54:05:f1 brd ff:ff:ff:ff:ff:ff
    inet 172.24.3.1/24 brd 172.24.3.255 scope global vlan30
       valid_lft forever preferred_lft forever
    inet 172.24.3.50/32 brd 172.24.3.255 scope global vlan30
       valid_lft forever preferred_lft forever
    inet6 fe80::b886:bdff:fe54:5f1/64 scope link 
       valid_lft forever preferred_lft forever
[heat-admin@controller0 ~]$ sudo netstat -lntup | grep 172.24.3.1
tcp        0      0 172.24.3.1:6789         0.0.0.0:*           LISTEN      47574/ceph-mon      
tcp        0      0 172.24.3.1:6800         0.0.0.0:*           LISTEN      49752/ceph-mds      
tcp        0      0 172.24.3.1:8080         0.0.0.0:*           LISTEN      5475/python2        
tcp        0      0 172.24.3.1:6801         0.0.0.0:*           LISTEN      45579/ceph-mgr      
udp        0      0 172.24.3.1:123          0.0.0.0:*                           756/ntpd

📜理解OPENSTACK容器化服务

在Red Hat OpenStack Platform 13中，控制平面服务运行在容器中，这些容器提供方法将每个服务保持在其独立的命名空间中，并且不相互依赖。Red Hat通过Red Hat容器目录提供了一组预构建的容器映像。容器映像从Red Hat客户门户提取并存储在Director节点的镜像存储库中。

📑使用OpenStack服务容器

Kolla是一个将OpenStack部署到容器中的项目。它包含每个OpenStack服务的容器镜像和配置，以及用于编排容器化服务的多个选项。Red Hat OpenStack平台使用Kolla容器配置来构建大多数容器镜像，并使用RHOSP Director来部署它们。

在Red Hat OpenStack Platform 13中，所有的OpenStack服务都运行在容器中。使用以下命令列出服务容器、容器使用的容器镜像以及它们在控制器节点上的状态：

[heat-admin@controller0 ~]$ sudo docker ps --format="{{.Names}}\t{{.Image}}\t{{.Status}}"
openstack-cinder-volume-docker-0	172.25.249.200:8787/rhosp13/openstack-cinder-volume:pcmklatestUp 21 hours
ovn-dbs-bundle-docker-0	172.25.249.200:8787/rhosp13/openstack-ovn-northd:latest	Up 21 hours
ceph-mds-controller0	172.25.249.200:8787/rhceph/rhceph-3-rhel7:latest	Up 21 hours
ceph-mon-controller0	172.25.249.200:8787/rhceph/rhceph-3-rhel7:latest	Up 21 hours
ceph-mgr-controller0	172.25.249.200:8787/rhceph/rhceph-3-rhel7:latest	Up 21 hours
haproxy-bundle-docker-0	172.25.249.200:8787/rhosp13/openstack-haproxy:pcmklatest	Up 21 hours
redis-bundle-docker-0	172.25.249.200:8787/rhosp13/openstack-redis:pcmklatest	Up 21 hours
galera-bundle-docker-0	172.25.249.200:8787/rhosp13/openstack-mariadb:pcmklatest	Up 21 hours
rabbitmq-bundle-docker-0	172.25.249.200:8787/rhosp13/openstack-rabbitmq:pcmklatest	Up 21 hours
………

使用以下命令检查容器化服务的容器主机配置。下面的输出列出了容器存放配置文件的目录和容器存储日志的目录。进一步查看容器主机配置，容器化服务上的/var/lib/kolla/config_files/src目录映射到主机操作系统上的/var/lib/config-data/puppet-generated/nova/。类似地，容器上的/var/log/nova目录映射到主机操作系统上的/var/log/containers/nova。

[heat-admin@controller0 ~]$ sudo docker inspect nova_scheduler --format "{{json .HostConfig.Binds}}" | jq .
[
  "/var/log/containers/nova:/var/log/nova",
  "/var/lib/kolla/config_files/nova_scheduler.json:/var/lib/kolla/config_files/config.json:ro",
  "/etc/localtime:/etc/localtime:ro",
  "/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro",
  "/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro",
  "/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro",
  "/dev/log:/dev/log",
  "/etc/puppet:/etc/puppet:ro",
  "/var/lib/config-data/puppet-generated/nova/:/var/lib/kolla/config_files/src:ro",
  "/run:/run",
  "/etc/hosts:/etc/hosts:ro",
  "/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro",
  "/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro"
]

📑容器化服务的配置管理

overcloud部署过程使用编排模板作为输入，将puppet定义的配置更改注入到容器镜像中。docker-puppet.py脚本管理部署在overcloud上的每个容器化服务的配置文件生成和引导。该工具存在于Director节点上的/usr/share/openstack-tripleo-heat-templates/docker/docker-puppet.py目录中。该工具重新生成一个初始容器，其中安装了服务二进制文件和puppet 安装。然后在overcloud部署期间将服务配置写入主机操作系统。在对正在初始化和确认的服务容器进行引导时，将启动另一个容器，以执行与服务容器交互所需的任务，例如创建标识服务端点和启动服务容器所需的用户。docker-puppet.py脚本的限制是，它只能与Puppet一起使用，并且与编排服务紧密集成。

使用paunch实用程序，您还可以使用TripleO服务模板中的配置数据启动和管理容器。这也可以用于引导一个容器化的OpenStack服务。paunch实用程序也可以在TripleO之外用于启动和执行容器配置管理。

paunch实用程序使用YAML配置数据来启动和管理容器。操作由paunch使用docker命令执行。不能使用paunch命令更改不是由paunch创建的容器。该实用程序可以通过paunch CLl或安装python包获得。

paunch实用程序为正在运行的容器设置标签。paunch要求容器有一个标签，以确定对哪个容器执行操作。如果标签没有被设置，那么paunch不知道容器的状态。

paunch实用程序使用幂等行为。当配置没有改变时，等幂行为使容器运行。如果容器的配置发生了变化，那么整个容器将被替换。等幂行为意味着即使在修改容器的配置时也可以使用相同的 --config-id。

直接在容器内进行的更改在重新启动时不会持久。为了确保更改是持久的，将编辑配置中的相关参数。paunch实用程序读取配置文件以重新创建容器。

所有非HA容器化的服务都由paunch实用程序管理。HA服务容器如HAProxy, Galera，和RabbitMQ是由Pacemaker创建和管理的。使用以下命令确定特定的容器服务是否由paunch服务管理：

[root@controller0 ~]# docker inspect nova_api -f "{{.Config.Labels.managed_by}}"
paunch

paunch调试命令允许您在多给定的容器上执行特定的操作。这可用于启动带有自定义配置文件的容器、转存特定容器的配置文件，或获取用于启动容器的命令。在下面的输出中，使用paunch实用程序获取用于启动nova调度器容器的命令。

[root@controller0 ~]# paunch debug --file /var/lib/tripleo-config/hashed-docker-container-startup-config-step_4.json   --container nova_scheduler --action print-cmd
docker run --name nova_scheduler-x9wv8s6i --detach=true --env=KOLLA_CONFIG_STRATEGY=COPY_ALWAYS --env=TRIPLEO_CONFIG_HASH=4510751d43f78312ffac5081d2aeb5f1 --net=host --health-cmd=/openstack/healthcheck --privileged=false --restart=always --volume=/etc/hosts:/etc/hosts:ro --volume=/etc/localtime:/etc/localtime:ro --volume=/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro --volume=/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro --volume=/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro --volume=/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro --volume=/dev/log:/dev/log --volume=/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro --volume=/etc/puppet:/etc/puppet:ro --volume=/var/log/containers/nova:/var/log/nova --volume=/var/lib/kolla/config_files/nova_scheduler.json:/var/lib/kolla/config_files/config.json:ro --volume=/var/lib/config-data/puppet-generated/nova/:/var/lib/kolla/config_files/src:ro --volume=/run:/run 172.25.249.200:8787/rhosp13/openstack-nova-scheduler:latest

📑管理容器化服务配置

容器化服务的配置文件存储在/var/lib/config-data/puppet-generated/service/etc/service中，例如/var/log/config-data/puppet-generated/keystone/etc/keystone中。这条规则的例外是aodh容器，其配置文件位于/var/lib/config-data/puppet-generated/aodh/目录中。

一个常见的管理技巧是修改容器内的配置，然后使用SIGHUP信号重新加载配置更改。这些更改是短暂的，当重新启动容器时，原始的配置将被恢复。

要对配置进行持久更改，必须在容器的bind mount目录中进行。下面的命令展示了如何对配置文件进行更改，以使其在/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf文件中持久存在。

[root@controller0 ~]# docker exec -u root keystone crudini --get /etc/keystone/keystone.conf DEFAULT debug
False
[root@controller0 ~]# crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf DEFAULT debug
False
[root@controller0 ~]# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf DEFAULT debug True
[root@controller0 ~]# docker restart keystone
keystone
[root@controller0 ~]# docker exec -u root keystone crudini --get /etc/keystone/keystone.conf DEFAULT debug
True

📑另一种最直接的方式（课外）

[root@controller0 ~]# vim /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 
[root@controller0 ~]# docker restart keystone
keystone
[root@controller0 ~]# docker exec -u root keystone crudini --get /etc/keystone/keystone.conf DEFAULT debug
False

📑查看容器服务日志文件

容器化的服务日志文件存储在/var/log/containers/service中，例如/var/log/containers/cinder。容器还保留基于内存的日志结构，用于存储容器的控制台STDOUT活动。使用docker日志服务来查看容器的控制台活动，例如docker logs keystone。

📜查看存储节点

集成Red Hat OpenStack平台和Red Hat Ceph存储提供了一个高度可伸缩和冗余的对象、块和文件存储解决方案。新的共享文件系统服务与CephFS驱动程序接口，提供了统一的存储平台。Red Hat OpenStack平台现在支持合并计算和存储功能，以减少给定工作负载所需的服务器总数，提高效率并降低成本。

超融合的基础设施在私有云和网络功能虚拟化(NFV)基础设施中作为核心和边缘工作负载越来越普遍。这些平台提供配置的、软件定义的计算和存储资源，以及统一的管理接口，所有这些都运行在经济的、工业标准的硬件上。

📑在控制器节点上查看Ceph服务

Ceph存储服务现在被容器化了。过去在Ceph存储节点上运行的所有Ceph命令现在都在控制器节点上运行。列出controllero节点上的Ceph容器。

[root@controller0 ~]# docker ps --format "{{.Names}}" | grep ceph
ceph-mds-controller0
ceph-mon-controller0
ceph-mgr-controller0

Ceph容器使用systemd脚本来管理容器。在下面的输出中，您可以看到实际的监视器服务命名为ceph-mon@controller0.service：

[root@controller0 ~]# 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
  system-ceph\x2dmds.slice                 loaded active active    system-ceph\x2dmds.slice
  system-ceph\x2dmgr.slice                 loaded active active    system-ceph\x2dmgr.slice
  system-ceph\x2dmon.slice                loaded active active    system-ceph\x2dmon.slice
[root@controller0 ~]# systemctl status ceph-mon@controller0.service 
● ceph-mon@controller0.service - Ceph Monitor
   Loaded: loaded (/etc/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-10-14 06:52:27 UTC; 1 day 5h ago
  Process: 45606 ExecStopPost=/usr/bin/docker stop ceph-mon-%i (code=exited, status=0/SUCCESS)
  Process: 46469 ExecStartPre=/usr/bin/docker rm ceph-mon-%i (code=exited, status=1/FAILURE)
 Main PID: 46506 (docker-current)
   CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@controller0.service
           └─46506 /usr/bin/docker-current run --rm --name ceph-mon-controller0 --net=host --memory=...

Oct 15 12:31:58 controller0 docker[46506]: cluster 2020-10-15 12:31:56.365317 osd.5 osd.5 172.24.... ok
…………

使用systemctl命令重新启动控制器节点上的Ceph容器。

要列出OSDs，请使用来自控制器节点的ceph osd Is命令。

[root@controller0 ~]# ceph osd ls
0
1
2
3
4
5

要验证集群的状态，使用ceph status命令。

[root@controller0 ~]# ceph status
  cluster:
    id:     fe8e3db0-d6c3-11e8-a76d-52540001fac8
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum controller0
    mgr: controller0(active)
    mds: cephfs-1/1/1 up  {0=controller0=up:active}
    osd: 6 osds: 6 up, 6 in
 
  data:
    pools:   7 pools, 416 pgs
    objects: 748 objects, 5655 MB
    usage:   6310 MB used, 107 GB / 113 GB avail
    pgs:     416 active+clean

要检查集群的可用数据存储，请使用ceph df命令。

[root@controller0 ~]# ceph df 
GLOBAL:
    SIZE     AVAIL     RAW USED     %RAW USED 
    113G      107G        6310M          5.41 
POOLS:
    NAME                ID     USED      %USED     MAX AVAIL     OBJECTS 
    images              1      5655M      5.37        99705M         727 
    metrics             2          0         0        99705M           0 
    backups             3          0         0        99705M           0 
    vms                 4          0         0        99705M           0 
    volumes             5          0         0        99705M           0 
    manila_data         6          0         0        99705M           0 
    manila_metadata     7       3189         0        99705M          21

📑查看Ceph存储和计算HCI节点上的Ceph服务

Ceph存储和计算HCI节点包含了OSDs。目录上列出Ceph容器
[root@ceph0 ~]# docker ps --format '{{ .Names}}' | grep ceph
ceph-osd-ceph0-vdc
ceph-osd-ceph0-vdb
ceph-osd-ceph0-vdd

[root@computehci0 ~]# docker ps --format '{{ .Names}}' | grep ceph
ceph-osd-computehci0-vdc
ceph-osd-computehci0-vdb
ceph-osd-computehci0-vdd

📜课本练习

[student@workstation ~]$ lab architecture-overcloud setup 
Setting up workstation for lab exercise work:

 . Verifying node reachable: director..........................  SUCCESS
 . Verifying node reachable: controller0.......................  SUCCESS
 . Verifying node reachable: compute0..........................  SUCCESS
 . Verifying node reachable: computehci0.......................  SUCCESS

章节内容已有相关演示，不再进行实验操作。

💡总结

RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶🤪。

以上就是【金鱼哥】对 第一章红帽OpenStack平台架构–介绍overcloud 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾红帽认证专栏系列：
RHCSA专栏：戏说 RHCSA 认证
RHCE专栏：戏说 RHCE 认证
此文章收录在RHCA专栏：RHCA 回忆录

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！

点赞
收藏
关注作者

0/1000

抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认取消

加入云驻计划，成为创作者

华为云周边好礼
免费体验产品
特殊身份标识
线下官方门票
内部专家零距离
与10000+优质创作者共同成长

立即加入