一、基础知识

本章节主要介绍云管理员整个管理平台的时候会碰到的基础工具和基础的使用,作为全文的一个入门指导。

1.1 kolla & kolla-ansible

kolla:提供准备生产的容器和部署工具,Kolla提供Docker容器,Ansible Playbooks,以在Baremetal或Virtual Machine上部署OpenStack,以实现Kolla的任务。

kolla-ansible: Kolla Ansible是一个与Kolla项目分开的可交付项目。Kolla Ansible在Docker容器中部署OpenStack服务和基础架构组件。

1.1.1 kolla部署节点主要文件目录

/etc/kolla/config/ 部署组件配置目录
/etc/kolla/globals.yml 部署配置文件
/etc/kolla/passwords.yml 平台密码存储
/root/multinode 平台节点清单文件

1.1.2 OpenStack 节点主要文件目录

/etc/kolla/* 平台运行组件配置目录
/var/log/kolla/* 平台各组件日志

1.2 OpenStack CLI(命令行工具)

运维过程中结合使用OpenStack命令行界面(CLI)工具和OpenStack 控制面板进行管理。目前OpenStack采用统一的OpenStack客户端来代替了原有的不同组件的客户端,建议通过采用OpenStack最新客户端。

1.2.1 安装命令行客户端

默认云平台后台是已经安装的

pip install python-openstackclient

1.2.2 获取凭据

要使用命令行工具对你的OpenStack进行管理,则必须具有相应的凭据。到目前为止,获取用于命令行客户端的身份验证凭据的最简单的方法是使用 Horizon控制面板进行下载(推荐方式)

在OpenStack中也可以直接在/etc/kolla/目录下查看admin-openrc.sh身份凭据文件

1.2.3 导入凭据(设置环境变量)

source /etc/kolla/admin-openrc.sh

注意:界面下载的凭据不会把密码保存在文本里面,当你source的时候会提示你输入密码,而kolla会直接在脚本中存储密码,需要妥善保存该文件。

1.2.4 常用命令入口

openstack
cinder
glance
nova
neutron

获取帮助:
1、所有命令均有子命令
2、help 子命令可以获取总帮助页面,如:nova help
3、子命令帮助:openstack cli 和其他命令的子命令帮助格式不同。
openstack <subcommand> --help
如:openstack server --help 
   openstack server create --help
nova help <subcommand>
如:nova help bootcinder help show

1.3 MStack 界面

作为云管理用户,可以使用MStack控制面板管理资源、镜像、网络、存储等。
MStack界面使用手册参见:https://cloud-help.mandao.com/docs/mstack/mstack-operations-user_manual

1.3.1 系统总体架构

所有组件均为容器化部署,运维需要具备一定docker基础

1.3.2 CloudCore(OpenStack 2024.2 基础系统)

OpenStack的基础组件在精选之后被囊括在MStack系统中,包括 Nova、Cinder、Neutron、Octavia、Keystone、Glance组件。将 OpenStack 最核心的组件进行了封装和简化,让用户可以将精力关注在业务上。

  • Keystone 是一个 OpenStack 服务,通过实现实现 OpenStack 的 Identiy API 提供客户端认证、服务终端、多租户的身份认证。官方API
  • Nova 是 OpenStack 最核心的服务,负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统,虚拟机生命周期管理也就是通过 Nova 来实现的。官方API
  • Cinder 提供块存储服务,为运行实例提供稳定的数据块存储服务、提供对 volume 从创建到删除整个生命周期的管理。官方API
  • Neutron 是 OpenStack 核心项目之一,提供云计算环境下的虚拟网络功能
  • OpenStack网络(neutron)管理OpenStack环境中所有虚拟网络基础设施(VNI),物理网络基础设施(PNI)的接入层。 官方API
  • Glance 是 OpenStack 的镜像管理服务。官网API

1.3.3 中间件

MStack中间件让系统内资源、功能互通共享,为系统提供通用服务,包括Rabbitmq、Mariadb、HAProxy、Keepalived、Redis、Memcached组件。

1.4 MStack平台高可用

1.4.1 控制节点高可用

数据库: Galera mariadb 集群
消息对接:RabbitMQ 集群
其他组件:Haproxy + keepalived

1.4.2 网络节点高可用

neutron 组件开启agent ha

1.4.3 存储节点高可用

产品默认存储组件为ceph。通过 ceph 集群的多mon节点、数据多副本机制实现存储高可用。

1.5 MStack 平台入口

平台 默认端口 用户名 密码存放
用户界面 443 admin /
Prometheus 9091 admin /etc/kolla/prometheus-server/prometheus.yml
Grafana 3000 admin /etc/kolla/passwords.yml
RabbitMQ 15672 openstack /etc/kolla/passwords.yml

二、MStack命令行基本操作

MStack后台接入OpenStack 2024.2,全兼容OpenStack 2024.2版命令

2.1 平台信息查看

2.1.1 获取命令帮助

openstack --help
openstack server --help
openstack server create --help
nova help
nova help boot

2.1.2 检查API调用

命令行工具可以通过向其传递--debug标志来显示OpenStack API调用过程。例如:

openstack --debug server list

此示例显示来自客户端的HTTP请求和来自endpoint的响应,通过这个调用关系可以检查服务请求目前的状态,通过这种方式,可以比较快的定位问题的范围。

2.1.3 服务器和服务

作为OpenStack管理员,可以通过使用OpenStack工具来了解OpenStack平台现在的状况。本节主要介绍如何获取平台的目前安装的组件、每个组件服务组成、和当前状态。

  • 首先,可以通过以下命令查看OpenStack云平台运行哪些服务:
openstack service list

输出如下所示:

  • 针对nova服务,可以查看nova组件启用哪些服务,且这些服务的状态:
openstack compute service list

输出如下所示:

可以从上图看出,目前有有3个超融合节点,可以看到nova服务有处于up状态,这表示服务已启动并正在运行,有处于down状态,这些服务现在有异常,需要尽快处理。这里需要说明的是服务的状态可以标识为disable状态,此状态下服务不可用(某一个计算节点disable,则平台的虚拟机不会调度到这个节点,但这个disable节点上的虚拟机仍然可以工作)

  • 其他服务查看:
openstack volume service list
openstack network agent list

可用的服务及为服务配置的Endpoint:

openstack catalog list

输出如下:

2.1.4 网络信息

  • 查看在OpenStack中配置哪些网段,可以使用OpenStack命令行客户端来获取子网:
openstack subnet list

输出:

此输出显示配置了4个网络,每个网络包含255个IP(24位子网掩码)。

  • 查看网络或子网的信息信息,可以使用show子命令
openstack network show <ID or Name>
openstack subnet show <ID or Name>
  • 确定环境中是否有可用的浮动IP,请运行:
openstack floating ip list

这里,15个浮动IP可用,其中4个已经分配给虚拟机,11个未分配,可以分配给虚拟机使用。

2.1.5 用户和项目

  • 查看项目列表,请运行:
openstack project list

输出:

  • 要查看用户列表,请运行:
openstack user list

输出:

2.1.6 实例信息

Openstack 平台内部,虚拟机被称为 实例,对应 openstack CLI 中的 server,也对应页面的 云主机

  • 要查看正在运行的实例的列表,请运行(需管理员权限):
openstack server list --all-projects
  • 当需要查看某个虚拟机的详细的信息(例如:虚拟机运行的节点、规格、安全组等),可以通过一下命令查个各个虚拟机的详细信息:
openstack server show < ID>

例如:

此输出显示名为test-instance,使用m4c8g100g的flavor,并托管在计算节点node23上。

2.2 平台初始化Getting Start

2.2.1 创建项目 project

openstack project create 项目名 --domain default

2.2.2 调整项目配额

新建项目默认配额通常不满足项目需要,需要调整

查看:openstack quota show 项目名
修改:openstack quota set 项目名 --ram 102400  本例为调整项目内存配额为100GB

2.2.3 创建 flavor

虚拟硬件模板在OpenStack中称为“flavor”,定义RAM大小,磁盘,内核数量等。

openstack flavor create 1C2G30G --vcpus 1 --ram 2048 --disk 30

# 1C2G30G 为新建flavor的名字
# ram 容量单位为:MB
# vcpu单位为:core
# disk 单位为:gb

2.2.4 添加镜像 image

OpenStack镜像通常可以被认为是“虚拟机模板”。基本上,镜像包含用于启动的可引导文件系统虚拟机实例。

    openstack image create ubuntu2204 \
        --file ./ubuntu2204.qcow2 \
        --disk-format qcow2 \
        --container-format bare \
        --public

ubuntu2204:镜像名
--disk-format 磁盘格式
--public :公用镜像
--container-format bare 镜像格式
--file ./cirros.raw: 上传的本地文件
  • 镜像属性

创建或修改镜像时,可以使用 –property key=value 参数设置镜像属性
常见属性:
开启nova set-password 管理云主机密码:

--property hw_qemu_guest_agent=yes --property os_type=windows --property os_admin_user=Administrator

2.2.5创建网络 network

openstack network create 网络名称
openstack subnet create 子网名称 --network 网络名称 --subnet-range CIDR网段

# 网络名称:建议规范:net_网段,举例:net_192.168.30.0
# 子网名称:建议规范:sub_网段,举例:sub_192.168.30.0
# CIDR网段:如 192.168.30.0/24

如:

openstack network create net_192.168.30.0
openstack subnet create sub_192.168.30.0 --network net_192.168.30.0 --subnet-range net_192.168.30.0/24

openstack network create可选参数:
--provider-physical-network physnet1     指定provider网络,通常/默认为 physnet1
--provider-segment 1030        指定 VLAN ID,默认随机分配
--external                创建外部网络,无此参数时默认创建 内部网络
--share                    允许其他项目共享网络,无此参数时默认不共享

openstack subnet create可选参数:
--allocation-pool start=192.168.30.1,end=192.168.30.100    默认1-255,前两个为dhcp
--no-dhcp                不开启dhcp ,无此参数时默认开启dhcp
--gateway 192.168.30.254    虚拟机dhcp获取的默认网关
--dns-nameserver 114.114.114.114    虚拟机dhcp获取的dns配置

2.2.6 编辑安全组 security group

在创建云主机时,如果指定的安全组中没有合适的规则,经常会遇到无法从外部访问云主机的问题。
*安全组是一个网络过滤规则的集合,它应用在用户的每一台云主机上,可以保障云主机的网络安全。*
*每个项目在创建时都带有一个名为default的默认安全组,该安全组中的规则只允许云主机的外出流量,拒绝所有传入云主机的流量。创建云主机时如果不指定其他安全组,系统会默认使用default安全组。项目中的成员可以在安全组中添加规则或者新建自己的安全组。*

  • 对安全组的操作

在OpenStack中,对安全组的操作途径有两种,一种是在界面中的“安全组”中可以进行安全组的增、删、改、查;另一种是通过OpenStack的命令行界面(CLI)进行相关操作。下面主要介绍一下如何通过OpenStack CLI对安全组进行操作。
获取您项目下的安全组列表,可以使用以下命令:

openstack security group list

  • 查看安全组的详细信息,可以使用以下命令:
# openstack security group show b86adb2f-3849-4687-9081-eaeff2983917

  • rules中显示了一个安全组所包含的规则,都是“允许”类型的规则。常见的安全组规则参数如下:

    • direction,表示安全组规则应用的方向。ingress代表进入虚拟机的方向,egress代表流出虚拟机的方向。
    • remote_ip_prefix,表示远端主机的IP前缀,根据报文流向作为源地址或目标地址的IP前缀。
    • protocol,表示安全组规则匹配的协议。有效值为“null”,“tcp”,“udp”,“icmp”和“icmpv6”。
    • port_range_min,表示与安全组规则匹配的最小端口号。如果协议是TCP或UDP,则此值必须小于或等于“port_range_max”属性的值。
    • port_range_max,表示与安全组规则匹配的最大端口号。port_range_min属性约束port_ran ge_max属性。
    • ethertype,表示网络类型,必须是“IPv4”或“IPv6”,并且在CIDR中表示的地址必须匹配入口或出口规则。
  • 当创建一个新的安全组时,应该对安全组添加一个功能性的描述,如”allow web traffic from the Internet”。 以下命令创建了一个组名为“global_http”的安全组,用于放行所有web流量:

openstack security group create global_http --description "allow web traffic from the Internet"

  • 创建成功后,会打印该安全组的详细信息,默认只有两个egress规则,我们可以根据需求添加一些规则。使用–help查看帮助信息:
openstack security group rule create --help

  • 为安全组“global_http”添加一条tcp规则:
openstack security group rule create --ingress --ethertype IPv4 --protocol tcp --remote-ip 0.0.0.0/0 global_http

  • 创建后查看规则是否添加成功:
openstack security group show global_http

  • 删除安全组规则时使用OpenStack security group rule delete,指定要删除的安全组规则ID。使用openstack security group delete可以删除整个安全组。
  • 在为允许多台云主机访问的情况创建安全组规则时,可以使用“–remote-group”选项。用户指定一个RemoteGroup(安全组名称),即等于选择了所有使用指定的RemoteGroup安全组的云主机。这种动态选择减少了对单个规则允许多个新成员访问的需要。使用命令创建时要指定“–remote-group”而不是“–remote-ip”。比如:
openstack security group rule create --ingress \
--ethertype IPv4 --protocol tcp \
--remote-group global_http cluster

# "cluster"规则允许任何其他``global-http``安全组的云主机通过ssh访问本机。

2.2.7创建密钥对 keypair

密钥对用于免密登录云主机
可以使用OpenStack keypair create命令生成和注册SSH密钥:

openstack keypair create mykey >mykey.pem

此命令这将创建一个名为“mykey”的密钥对,您可以将其与云主机关联。输出的文件mykey.pem是私钥,它应该保存到一个安全的位置,因为它允许管理员访问mykey并与将其云主机关联。如果已经有公钥,可以用以下命令来向OpenStack注册已存在的key:

openstack keypair create --public-key mykey.pub mykey

查看创建的密钥对:

openstack keypair list

2.2.8云硬盘 volume

云硬盘是可以为云主机添加持久性存储的块设备,一个云硬盘在某一时刻只能挂载到一个云主机,类似于外部硬盘驱动器,它们不是以网络文件系统或对象存储的方式提供共享存储的。OpenStack卷服务无法提供是否可以从云主机中安全卸载云硬盘的信息,如果用户把云硬盘从一个云主机中强行卸载,那么当它再次被写入的时候,就会收到一些文件系统级别的损坏信息和一些来自进程的故障信息(类似云主机正在使用该设备)。
新建云硬盘并将它们挂载到云主机的操作可以通过OpenStack命令行来完成。新建云硬盘时执行如下命令:

openstack volume create volume1 --size 10


这里新建了一个10GB的云硬盘。列出已存在的云硬盘以及他们所挂载到的云主机:

openstack volume list


OpenStack块存储还允许创建云硬盘快照(块级快照),为了保证快照的一致性,最好在云硬盘没有连接到云主机时或者被挂载但是未在使用的时候创建。默认情况下卷服务不会为一块已经被附加到云主机上的云硬盘创建快照的,但也可以强制创建。创建快照的按钮在界面上每个云硬盘的最右边,也可以通过命令行创建。

openstack help snapshot create

2.2.9云主机 server

云主机即OpenStack中的虚拟机。平台内部称为:Instance 或 server

  • 创建云主机

创建云主机需要提前创建或确认以下信息:
flavor:必须
image 或 启动卷:必须
network信息:必须
云主机名称:必须
安全组:可选
密钥对:可选

openstack server create --flavor FLAVOR --image IMAGE_NAME_OR_ID --nic net-id=NETWORK_ID --security-group default SERVER_NAME

这是基本的创建命令,在尝试创建云主机之前,应阅读本节的其余部分。

  • 云主机元数据

对于Compute服务来说,元数据是与云主机关联的键值对的集合。在云主机的生命周期内,用户可以使用Compute API服务从云主机内部或外部随时读取或写入这些键值对。
元数据配置:--property key=valume 可以在同一命令行中使用多个 --property 选项

  • 关联安全组

如前所述,通常需要安全组来控制网络流量到云主机,添加安全组一般在云主机创建时完成。当从界面创建时可以点击选择多个安全组;当从命令行创建时,通过--security-groups`追加带有逗号分隔的多个安全组。还可以为云主机添加和删除安全组,执行命令:

openstack server add security group SERVER SECURITY_GROUP_NAME_OR_ID
openstack server remove security group SERVER SECURITY_GROUP_NAME_OR_ID
  • 绑定浮动IP
openstack floating ip create NETWORK_NAME_OR_ID

一旦分配成功,就可以将浮动IP分配给正在运行的云主机,通过选择“关联”按钮完成,反之通过“解绑”按钮取消云主机的浮动IP。关联或取消浮动IP时请使用以下命令:

openstack server add floating ip SERVER IP_ADDRESS
openstack server remove floating ip SERVER IP_ADDRESS

三、日常运维

3.1 平台状态检查

3.1.1 VIP状态

ssh $VIP

登录后shell命令行提示符显示的主机名为vip所在节点

3.1.2 节点时间同步情况

ansible  -i /root/multinode  all -o -m shell -a 'date'

3.1.3 数据库状态

进入mariadb容器并进入mysql数据库

cat /etc/kolla/passwords.yml |grep ^database
docker exec -it -uroot mariadb bash
mysql -h vip -u root -p

在 mysql 环境下执行以下命令

show status like '%comment';
show status like '%cluster_status';
show status like '%addresses';

3.1.4 rabbitmq 状态

docker exec rabbitmq rabbitmqctl cluster_status
docker exec -it -uroot rabbitmq rabbitmqctl list_queues | grep -vw 0$

3.1.5 平台状态

openstack compute service list
openstack volume service list
openstack network agent list
openstack server list

3.1.6 grafana登录(web页面)

3.1.7 查看容器状态

docker ps -a 

3.2 平台数据库备份


# 登录 部署节点,通常为control01节点
ssh control01
# 查密码
cat /etc/kolla/passwords.yml |grep ^database

# 创建数据库备份目录:
mkdir /opt/backup.mariadb

# 备份
BackupTime=$(date '+%Y%m%d%H%M')
mysqldump -h vip -u root -p --single-transaction --all-databases -r /opt/backup.mariadb/mysql_backup_${BackupTime}.sql

# dump文件备份到另一个节点(保险起见,最好下载到个人电脑或移动硬盘、带库等平台外介质)
scp /opt/backup.mariadb/mysql_backup_${BackupTime}.sql control03:/opt/backup.mariadb/

3.3 计算节点维护

适用于计算节点系统升级、重启、停机维修等场景
1.维护前:禁止新建虚拟机调度到该节点,并填写原因(可选择)
openstack compute service set 节点名 nova-compute --disable --disable-reason "停机原因"
2.维护前:疏散该节点虚拟机
# 执行疏散
nova host-evacuate-live 节点名称
# 可以通过 --max-servers N 指定最大同时疏散数为N
# 检查确认该节点虚拟全部迁出
openstack server list --all --host 节点名称
3.关闭计算节点且完成维护
4.维护后:检查该节点服务是否启动
# 登录被维护的计算节点
ssh computeXX
# 检查服务状态
docker ps -a
# 确保它已成功连接到AMQP服务器
grep AMQP /var/log/kolla/nova/nova-compute.log
5.维护后:检查系统和服务状态,看节点是否恢复
openstack compute service list
openstack network agent list
6.维护后:启用该节点,恢复调度
openstack compute service set 节点名 nova-compute --enable

3.4 集群计划性停机维护

3.4.1 整体停机

  1. 检查所有虚拟机状态为关闭状态,保存运行中的虚拟机列表并生成启动命令

    openstack server list  |grep Running|awk '{print "nova start " $2}' > start_instances.sh
  2. 关闭运行中的虚拟机

    for i in `openstack server list|awk '{print $2}'|grep -iv 'ID';do openstack server stop $i;done`
  3. 检查prmetheus,尽量确保无告警

  4. 备份数据库
    首先使用df命令检查分区使用情况,选择合适地点存放备份,默认存放位置为/data/backup/yyyymmdd
    可以使用以下SQL查看数据库大小:

    use information_schema;
    SELECT CONCAT(ROUND((SUM(DATA_LENGTH)+SUM(INDEX_LENGTH))/1024/1024,2),'MB') AS DATA FROM TABLES;
  5. 在关闭所有虚拟机后,控制节点上执行数据库备份

    docker exec mariadb mysqldump --user=root --password={DB_PASSWORD} --all-databases --single-transaction --flush-logs --master-data=2 | gzip > full_backup_$(date +%Y%m%d_%H%M%S).sql.gz
  6. ceph设置标签
    在控制节点上执行以下命令:

    docker exec -i -u root ceph_mon ceph osd set norebalance
    docker exec -i -u root ceph_mon ceph osd set nobackfill
    docker exec -i -u root ceph_mon ceph osd set noin
    docker exec -i -u root ceph_mon ceph osd set norecover
    docker exec -i -u root ceph_mon ceph osd set noout
  7. 关机前设置masakari中计算节点维护状态打开 (如果部署masakari的话); 执行systemctl stop nova-evacuation.service和systemctl disable nova-evacuation.service关闭nova-evacuation服务避免虚拟机疏散 (如果部署nova-evacuation的话)

  8. 云平台停机维护步骤

  • 关闭计算节点
  • 关闭存储节点
  • 关闭网络节点
  1. 控制节点关机步骤:找到vip所在控制节点,将其余两台控制节点关闭,然后关闭vip所在控制节点。

3.4.2 开机顺序

与停机步骤相反

  1. 开启最后关机的控制节点,开启后检查数据库状态SHOW GLOBAL STATUS LIKE '%WSREP%';,当且仅当wsrep_local_state_comment值为Synced后开启下一台控制节点,逐台开启。

  2. 开启网络节点

  3. 开启存储节点

    # 存储节点开启后,在控制节点上执行以下命令查看osd数量:
    docker exec -i -u root ceph_mon ceph -s
    # 然后使用以下命令取消之前设置的标签:
    docker exec -i -u root ceph_mon ceph osd set rebalance
    docker exec -i -u root ceph_mon ceph osd set backfill
    docker exec -i -u root ceph_mon ceph osd set in
    docker exec -i -u root ceph_mon ceph osd set recover
    docker exec -i -u root ceph_mon ceph osd set out
  4. 开启计算节点

  5. 调整masakari服务中计算节点状态为维护中:在该节点恢复正常后维护模式改为false 。

# 将被force-disable的计算节点重新enable
openstack compute service set --enable   <host> <service>
# 打开nova-evacuation服务
systemctl start nova-evacuation.service
systemctl enable nova-evacuation.service
  1. 检查prometheus,无告警,有则修复

  2. 创建测试虚拟机,测试云平台虚拟机功能是否正常

  3. 开启之前关闭的虚拟机

3.4.3 mariadb人工恢复方法

#检查各个控制节点是否已设置安全引导safe_to_bootstrap =1
ansible -i /root/multinode control -m shell -a 'cat /var/lib/docker/volumes/mariadb/_data/grastate.dat|grep safe_to_bootstrap'

#如果有节点值为1,直接写入下面mariadb_recover_inventory_name处,然后修复,如果没有,手动去修改一个节点的值为1,再修复
关闭所有节点mariadb数据库容器:ansible -i multinode control -m shell -a 'docker stop mariadb'
引导修复:kolla-ansible  mariadb-recovery -e mariadb_recover_inventory_name=<host_ip> -i /root/multinode

3.4.4 rabbitmq人工恢复方法

# 在所有控制节点上执行
ansible -i /root/multinode control -m shell -a 'docker stop rabbitmq'
# 在其中一台节点执行如下命令启动rabbitmq
docker exec rabbitmq rabbitmq-server -detached
# 在剩余节点执行如下命令启动即可
docker restart rabbitmq
# 验证集群状态,执行如下命令
rabbitmqctl cluster_status

3.5 集群整体故障恢复次序

处理系统完全故障(例如数据中心的断电)恢复的常见方式是为每个服务分配优先级,并按顺序恢复。服务恢复优先级列表显示一个示例。

优先级 服务
1 内部网络连接 VIP节点启动
2 消息队列和数据库服务
3 存储服务后端
4 nova、cinder 相关组件
5 用户虚拟机
6 用户虚拟机与公共网络的连接
7 其他组件

使用此优先级列表可确保尽快恢复受用户影响的服务,但只能在稳定环境到位之后恢复。当然,尽管被列为单行项目,但每个步骤都需要大量工作。例如,刚启动数据库后,您应该检查其完整性,或者,在启动nova服务后,您应该验证虚拟机管理程序与数据库匹配并修复任何不匹配。

作者:束鹏  创建时间:2026-02-03 14:25
最后编辑:束鹏  更新时间:2026-03-17 15:59