1. 部署前的规划与架构设计1.1 节点划分与资源评估很多人一上来就急着安装结果装到一半发现磁盘不够、内存爆掉或者网络配置一塌糊涂。OpenStack部署真正考验人的不是命令本身而是前期规划。它就像装修房子先把水电布局想清楚再动工。先算资源。一个最小的可用生产环境至少需要三台节点控制节点、计算节点、存储节点也可以合并。控制节点跑核心服务比如认证、镜像、网络管理、调度等内存至少16GB推荐32GB计算节点跑虚拟机实例内存根据业务需求来但最低8GB起步CPU要支持虚拟化VT-x/AMD-V存储节点提供块存储和对象存储磁盘容量按业务数据量规划建议至少SSD做缓存HDD做存储。如果只是想测试可以一台机器用虚拟化嵌套跑三个节点但性能会打折。磁盘分区也要提前设计。系统盘和数据盘分开控制节点系统盘建议100GB计算节点系统盘建议50GB存储节点系统盘50GB另加数据盘。分区时/boot给1GBswap按内存大小给/分区用LVM方便后续扩容。网络规划上我强烈建议至少配置两块网卡一块管理网络用于API通信、内部组件通信一块数据网络用于虚拟机流量、存储流量。如果条件允许再加一块外部网络网卡。千万不能用管理网去跑业务流量不然只要虚拟机一多管理API就卡成幻灯片。1.2 网络方案选型OpenStack网络是坑最多的模块也是选型时最容易纠结的地方。常用的有几个方案Flat网络最简单所有虚拟机都在一个共享L2网段类似家里的路由器直接分IP。适合测试环境。VLAN网络基于物理交换机上的VLAN隔离租户网络需要交换机支持VLAN但灵活性和扩展性够用很多企业在用。OVSGRE/VXLAN通过隧道封装实现租户隔离不依赖物理VLAN适合多租户场景但配置复杂性能损耗相对较高。OVN新一代虚拟网络方案整合了Open vSwitch和OVN控制器功能更完善性能也更好是社区主推的方向。选型时问自己几个问题租户数量多大是否需要租户间隔离底层网络基础设施是否支持VLAN如果只是内部私有云几十个租户以内VLAN完全够用如果想做公有云或大规模虚拟化VXLAN/OVN更合适。我个人的建议是生产环境优先考虑OVN社区支持力度大问题少一些。1.3 环境准备与版本选择版本选择直接决定你踩坑的深度。最忌讳用最新的版本做生产也不建议用太老的版本会有大量已知bug和不安全漏洞。建议选择当前社区的稳定版本比如最近的稳定版具体版本号自己查官方文档命名规则是字母排序。在部署前先去官网看该版本的release notes了解新特性、废弃功能、已知问题。操作系统方面建议选用主流Linux发行版比如基于Debian或RHEL体系的。需要注意的是不同发行版对OpenStack的支持程度不同有些发行版有官方源有些要装第三方源。我推荐用发行版自带的包管理器安装这样依赖关系好解决后续升级也方便。不要自己从源码编译除非你想深入开发。时间同步一定要在安装前搞定集群内所有节点统一使用NTP同步。控制节点可能还需要配置DNS确保节点之间能通过主机名互相访问。主机名最好提前规划比如controller、compute01、storage01写成/etc/hosts别用IP直接访问服务否则后续证书和服务注册会有各种奇葩问题。2. 核心组件的部署要点2.1 认证服务Keystone先搞定身份再谈别的OpenStack所有组件之间的交互都要通过Keystone认证。部署顺序上Keystone必须第一个装因为其他组件启动时要向Keystone注册endpoint。安装Keystone时有几个关键点容易出错。第一数据库初始化。需要建一个专门的数据库和用户并授权。这里要注意密码策略建议用强密码但别用特殊字符太多因为后续命令行中很多地方要填密码特殊字符会带来转义问题。第二Fernet key生成。Keystone使用Fernet key做token加密需要生成一个key并在所有节点上保持同步如果你做多控制节点高可用这个key必须复制到每个节点。第三服务注册。创建服务实体和API endpoint时endpoint的URL要一致建议用管理网域名不要用IP这样以后证书配置和负载均衡都好做。验证Keystone是否正常很简单用admin用户请求一下token。常见错误是401 Unauthorized多半是密码错误或Fernet key不一致。还有403 Forbidden可能是role没有分配好。初次安装时别忘了引导admin项目、admin用户、admin角色以及创建service项目。2.2 镜像服务Glance上传镜像前先想好格式Glance负责管理虚拟机镜像。安装很简单主要是数据库、配置文件、注册endpoint。真正需要注意的环节在镜像格式和上传流程上。支持的镜像格式有很多但生产中最常用的是qcow2和raw。qcow2支持快照、压缩、COW写时复制上传快使用方便raw格式性能最好但不支持快照。如果对性能有极致要求可以用raw存存储qcow2做镜像分发。还有一点上传前要确认镜像是否支持virtio驱动特别是Windows镜像否则后面启动实例时网卡和磁盘认不到。Glance的存储后端可以配置为本地目录、Ceph等。如果用了Ceph需要导入Ceph的key并配置pools。这里我要提个醒Glance存Ceph后虚拟机启动时如果能直接通过Ceph克隆镜像到Cinder会比先下载镜像再转换快得多。这也是我偏爱Ceph做后端的理由。2.3 计算服务Nova调度、虚机和状态的幕后管家Nova是整个OpenStack里逻辑最复杂的组件。它由多个子服务组成nova-api接收API请求nova-scheduler决定把虚拟机放在哪个计算节点上nova-compute在计算节点上真正创建和运行实例nova-conductor负责数据库访问和协调。部署Nova配置项特别多但核心配置就那么几块数据库连接所有服务统一用数据库用户连接注意字符集。消息队列Nova组件之间通过消息队列通信常用RabbitMQ。如果消息队列挂了整个Nova就瘫痪。生产环境一定要做消息队列的高可用。认证方式配置Keystone连接信息和管理用户。compute节点配置设置虚拟化类型默认KVM配置vCPU、内存、磁盘的分配超卖比例。比如CPU超卖比设为41内存设为1.51但要监控好避免物理资源耗尽。libvirtNova-compute依赖libvirt管理虚拟机。需要配置/etc/nova/nova-compute.conf中的libvirt类型默认是kvm但如果CPU不支持虚拟化只能降级为qemu性能差很多。一个常见的坑是Nova-compute启动后OpenStack里看不到可用计算资源。检查思路是先看nova-compute日志确认它是否注册成功然后看nova-conductor有没有把compute信息同步到数据库最后在控制节点执行openstack compute service list看服务状态。如果是down多半是时间不同步、消息队列连接失败或者配置文件权限问题。2.4 网络服务Neutron让虚拟机接入真实世界Neutron是部署过程中最让人头疼的组件也是虚拟机能否真正用起来的关键。它涉及多个Agentneutron-server提供APIneutron-dhcp-agent分配IPneutron-l3-agent做路由和NATneutron-metadata-agent处理元数据还有Open vSwitch或者Linux Bridge的机制。部署时先配置数据库、认证、消息队列这些基础项。然后需要选择二层机制如果之前选了OVS或OVN要安装对应的Agent。控制节点上需要启动dhcp、l3、metadata agent计算节点上至少要启动二层Agent比如ovs-agent。记得在每个节点上配置openvswitch创建好br-int、br-ex等虚拟交换机。网络配置里最容易出问题的有三个地方。一是网卡混杂模式。计算节点上的数据网络网卡比如eth1要开启混杂模式否则虚拟机流量过不了。用ip link set eth1 promisc on但最好写进持久化配置避免重启失效。二是外网桥接。如果用provider网络需要把外部网络网卡桥接到br-ex上。桥接时物理网卡的IP要移到bridge上如果直接配置错外部网络就断了。我的办法是在一个维护窗口里用临时脚本先配置br-ex验证通了再写持久化。三是DHCP命名空间。Neutron的DHCP默认绑在命名空间里不同网络有不同命名空间。如果虚拟机拿不到IP先看ip netns exec qdhcp-xxx ip a里有没有分配IP再看dhcp-agent日志。3. 自动化部署工具对比与选择3.1 三个工具的真实差异手把手手动部署OpenStack确实能学到很多东西但效率太低还容易出错。实际工作中基本都是用自动化工具部署。常见的选择有工具定位优点缺点DevStack开发测试环境部署一条命令拉起来适合功能测试不适合生产无高可用依赖网络PackStack面向单节点或较少节点的快速部署简单适合评估环境定制性弱网络方案受限生产环境慎用Kolla-Ansible容器化部署生产级基于Docker/K8s组件隔离支持高可用配置清晰学习曲线陡要求有Docker和Ansible基础我个人的建议是测试和学习用DevStack快速验证和POC用PackStack生产环境用Kolla-Ansible。如果你想搭建一套能实际支撑业务的云平台直接学Kolla-Ansible它是目前社区最活跃的部署项目之一。3.2 基于Kolla-Ansible的部署实操下面是我部署时一个经过验证的流程以三节点controller compute1 compute2 为例。准备阶段在所有节点安装Python、Docker、Ansible。Ansible版本需要和Kolla-Ansible匹配在官方文档里有明确版本对应表。在控制节点安装Kolla-Ansible通过pip安装即可。准备目标节点清单文件也就是inventory。我习惯放在/etc/kolla/inventory下定义[control]和[compute]组并填好节点IP、SSH用户名、sudo权限设置。编辑全局配置/etc/kolla/globals.yml。这里面要改的项目很多我最关注几个kolla_base_distro决定基础镜像是哪个发行版建议选较新的稳定版。kolla_internal_vip_address虚拟IP用于高可用需要分配给控制节点所在的物理网络一个空闲IP。network_interface管理网络接口名。neutron_external_interface外部网络接口名。openstack_release要部署的OpenStack版本。enable_haproxy: yes如果想做控制节点高可用就开HAProxy。enable_ceph: yes如果用Ceph做存储还要配置Ceph相关项。执行阶段生成密码文件。使用kolla-genpwd工具自动生成所有服务的密码。也可以手动修改注意一致性。通过kolla-ansible prechecks检查系统环境。这一步会检查网络、时间同步、内存、磁盘等。如果有问题会直接报错。执行kolla-ansible deploy。这一步会拉取镜像启动所有容器。耗时取决于网络和机器性能首次部署可能需要20到60分钟。部署完成后生成/etc/kolla/admin-openrc.sh这是OpenStack管理员的认证文件。执行kolla-ansible post-deploy然后在控制节点上安装OpenStack客户端命令。验证阶段用openstack service list查看服务是否注册用openstack compute service list查看计算服务是否正常用openstack network list查看网络是否创建。如果启动一个测试虚拟机还能成功SSH进去说明部署基本成功。3.3 容器内部组件日志怎么查Kolla-Ansible把组件跑在容器里排查问题的方式跟传统部署不太一样。常用的命令# 查看所有容器状态 docker ps -a # 查看某服务日志 docker logs nova_conductor 21 | tail -100 # 进入容器执行命令 docker exec -it nova_api bash # 查看keystone容器里是否配置正确 docker exec -it keystone bash -c openstack endpoint list日志默认存在/var/log/kolla/service/下每个服务会按日志文件写入。排查问题时优先看对应容器日志或宿主机上的日志文件。比如Nova创建虚拟机失败就同时看nova-compute和nova-conductor的日志很可能通过日志直接找到原因。4. 常见问题与排查技巧实录4.1 虚拟机拿不到IP地址现象用命令行创建实例后状态为ACTIVE但openstack console log show里看到网卡状态是DOWN或者没有DHCP请求。排查路径看Neutron网络状态openstack network list确认网络、子网、端口都正常。在控制节点查看DHCP命名空间ip netns exec qdhcp-XXXX ip a确认DHCP地址池里的IP有没有被分配。看dhcp-agent日志docker logs neutron_dhcp_agent如果有“DHCP request received”就没问题。看计算节点的二层网络执行ovs-vsctl show确认数据网桥是否正常物理网卡是否在桥上。最常见的原因是混淆了“管理网络”和“数据网络”。如果计算节点没有把数据网络网卡桥接好虚拟机网卡即使起来了二层流量也无法到达DHCP服务。另外检查安全组规则如果没放行DHCPUDP 67/68也会导致拿不到IP。4.2 实例创建超时或报错No valid host现象创建虚拟机卡在SCHEDULING阶段或者提示“No valid host was found”。排查思路openstack hypervisor list看计算节点是否在列表中。如果为空说明nova-compute没有正常上报。看nova-scheduler日志通常会输出为什么没有可用主机。常见原因是计算节点的资源不足比如内存、磁盘、CPU不满足flavor规格。检查一下宿主机可用内存和磁盘不要只看配额。检查flavor参数比如VCPU、内存、磁盘是否设置合理。默认flavor可能配置为内存512MB但宿主机真的没有这么多内存。如果是在Kolla容器环境还要确认nova_compute容器是否启动成功以及它能否连接消息队列。4.3 Dashboard登录后白屏或登不上现象打开Horizon页面输入账号密码后页面一直是空白或报错。排查路径看Dashboard容器日志检查连接Keystone是否超时。确认浏览器能访问到Keystone的endpoint。在页面所在机器上执行curl http://vip:35357/v3看能否返回JSON。检查Session存储Horizon默认使用本地的文件或Memcached。如果配置了Memcached确保Memcached服务正常。常见的是因为vip配置错误Dashboard访问了不存在的IP。检查globals.yml中的kolla_internal_vip_address并确保该IP在控制节点的网卡或者HAProxy上正常绑定。4.4 Cinder块存储卷无法挂载现象创建了卷并挂载到实例但实例内看不到块设备或者看到设备但无法格式化。原因很可能是卷的驱动程序配置错了。如果你用的是LVM作为Cinder后端需要在存储节点上配置一个卷组名称比如cinder-volumes。用vgcreate cinder-volumes /dev/sdb创建然后修改cinder.conf里的volume_group cinder-volumes。还有一个容易被忽略的问题Cinder做LVM后端时lvm_type可能被设置为thin而你并没有创建thin pool导致卷创建失败。我的建议是如果没把握就用普通卷组不配thin。如果卷创建成功但挂载后实例里需要重启才出现通常是因为virtio驱动问题或者实例操作系统没有安装好相应的块设备驱动。Windows实例尤其常见请在镜像里预先安装virtio驱动。5. 我个人沉淀的操作心得部署过几套OpenStack之后我最大的感受是这个系统所有组件都是彼此关联的。网络不通Nova调度会出错Keystone认证慢所有组件都跟着遭殃。所以在部署前一定要把基础环境每个细节都验证好。一个小技巧部署完成后先不要急着创建虚拟机。建议按顺序验证一遍openstack endpoint list确认所有服务的endpoint都是可达的。在控制节点上直接curl每个endpoint确认网络层是通的。创建一个最简单的flavor比如1VCPU/1G/10G创建一个测试网络和子网启动一个Cirros之类的轻量级镜像。确认控制台能打开然后SSH登录测试外网连通性。创建一块Cinder卷挂载上去测试块存储的读写。这一套走下来平台才算是真正跑通了。之后再加业务虚拟机遇到问题时也会更有把握。另外强烈建议把部署过程的每一步记录下来包括配置文件的修改、密码的管理、网络的拓扑。OpenStack的配置非常分散一旦出问题没有文档就只能靠回忆。我每次部署完都会写一页简单的部署备忘把每个组件的关键配置项和当时的拓扑图整理起来。后续排障时能省一半时间。还有一点是关于升级和扩容。不要跳过任何一个版本的release notes。OpenStack组件之间的版本兼容性很强跨版本升级如果没处理好网络层插件可能会全盘崩溃。扩容计算节点相对简单只要保证新节点的时间同步、网络、认证信息一致然后再由Kolla-Ansible执行扩容部署即可但一定要在业务低峰期做。OpenStack部署没有一劳永逸的银弹它需要你不断去理解其架构和组件交互。但只要用心把底层原理搞透部署配置其实都是水到渠成的事。希望这篇总结能帮你少踩一些坑。