OpenStack核心组件与部署实战：从架构到拉起虚拟机

1. 先搞清楚OpenStack到底是个什么东西1.1 一句话定义和核心价值OpenStack是开源界最出名的云计算管理平台。它的定位很直白把你手头一堆物理服务器、硬盘、交换机这些裸设备通过软件方式打包成一套可以自助申请、自动分配、按需回收的云资源池。你不需要再一台一台去装系统、配网络、分存储而是通过一个统一的界面或者API几分钟就能拉起一台虚拟机、申请一块硬盘、划分一段虚拟网络。它解决的问题本质上就是“基础设施即服务”也就是常说的IaaS。这套东西从2010年诞生到现在中间经历了各种大风大浪期间很多人喊过“OpenStack已死”但它到今天仍然是很多企业和运营商搭建私有云、混合云底座的实际选择。它最核心的价值不是某一个组件多好用而是它定义了一套相对完整、开放、可插拔的云管理标准。换句话说你不需要被某一家厂商的生态绑死计算节点坏了可以换网络组件不行可以替换成别的开源方案底层存储也可以用多种后端。这种解耦和开放的特性很多商业产品给不了。1.2 谁在用什么场景下用它抛开营销话术OpenStack真正落地的场景主要是三类。第一类是私有云。很多公司出于数据安全、合规要求不方便把内部业务放到公共云上但是又想要公共云那种自助申请资源的体验于是用OpenStack搭建内部私有云。开发者提交一个申请单云平台自动分配一台带指定CPU、内存、磁盘规格的虚拟机走完审批流程后直接可用。这里面比较典型的部门是企业的研发测试部门他们对资源的诉求是“快”和“灵活”而OpenStack恰好能解决这个问题。第二类是NFV也就是网络功能虚拟化。运营商和通信设备厂商把传统的路由器、防火墙、负载均衡等网络功能从专用硬件搬到了标准x86服务器上用OpenStack作为承载平台来统一管理这些虚拟化网元。这类场景对网络性能和资源调度稳定性要求极高能留下来的基本都是经过大量生产环境验证的。第三类是超大规模互联网公司的内部云平台。很多头部互联网公司内部其实跑着规模庞大的OpenStack集群只是对外不宣传。他们基于OpenStack做二次开发替换掉不适合自己规模的组件形成为内部业务服务的定制化云平台。1.3 核心概念项目、用户、角色、租户开始碰OpenStack之前先把几个绕不开的概念搞清楚不然后面看命令行会一头雾水。项目在OpenStack里就是资源的容器。你可以在一个项目里创建虚拟机、网络、存储卷项目之间默认是隔离的。旧文档里经常叫“租户”其实就是同一个东西新版本统一改成项目了。用户就是登录账号一个用户可以属于多个项目。角色用来控制权限同一个用户在不同项目里可能拥有不同角色比如在一个项目里是管理员在另一个项目里只能是普通成员。可以用小区物业来类比。项目就好比一个小区用户是业主角色决定你在小区里是普通住户还是物业经理。普通住户只能使用自己的房子物业经理能调整小区公共资源。这套权限模型贯穿所有OpenStack服务理解了它后面用图形界面和命令行都会顺手很多。2. OpenStack的八块积木核心组件逐个拆2.1 计算服务NovaAll in One的虚拟机管家Nova负责虚拟机的全生命周期管理创建、删除、关机、开机、迁移、调整规格全是它的活。它不直接操作底层虚拟化而是通过驱动调用底层的Hypervisor比如KVM、QEMU、VMware甚至也能接容器运行时。Nova内部还分了好几个子服务API服务接收请求Scheduler服务负责调度Conductor服务负责数据库操作和复杂逻辑Compute服务跑在每台计算节点上真正管理本机的虚拟机实例。这里有一个容易被新手忽略的点Nova的调度器默认是按内存和CPU核数来筛选计算节点的。它并不是只挑空闲最多的机器而是会先根据你指定的过滤器过滤掉不满足条件的节点再按权重算法选一台。我记得自己第一次搭集群时两台配置一样的计算节点结果所有虚拟机都挤到其中一台去了。后来查RFC才知道Scheduler默认的随机权重会引入随机因子目的是避免多台并发创建时把请求都打到同一台机器上。实际使用中可以用命令行工具手动指定某台计算节点发起创建这在排障时特别有用。2.2 网络服务Neutron虚拟网络的编织者Neutron是整个OpenStack里面最复杂、最容易踩坑、也最值得研究的组件。它提供了虚拟网络、子网、路由器、安全组、负载均衡、防火墙这些网络资源。默认支持VLAN、VXLAN、GRE等多种网络类型。多节点部署时网络数据流量会区分成管理网络、数据网络、外部网络和存储网络配置不当就会导致虚拟机网络不通。新手最常遇到的场景叫“Flat网络”和“VXLAN网络”。Flat网络直接把物理网络的某个网段桥接给虚拟机用配置简单性能好但隔离性一般适合做管理网段。VXLAN网络则是通过隧道封装实现大规模租户隔离适合多租户云环境。生产环境里两种网络通常同时用管理API走Flat租户实例走VXLAN。2.3 存储相关Cinder块存储和Swift对象存储Cinder负责给虚拟机提供块存储设备类似给它加一块云硬盘。它不是自己存数据而是通过后端驱动对接各种存储系统比如用LVM、Ceph、NFS等。Cinder的厉害之处在于支持快照和克隆我经常利用这个能力做开发测试环境的批量复制。给一台装好基础软件的虚拟机做快照之后每次新开环境直接从快照克隆比从头装系统省太多时间。Swift是对象存储服务用来存图片、备份、日志这类非结构化数据。它的设计思路和市面上很多对象存储类似通过一致性哈希把数据分散存储在多台服务器上支持数据多副本冗余。如果你们公司已经有Ceph那Swift不一定需要单独部署因为Ceph天然提供对象存储网关OpenStack可以直接对接。大部分场景下中小集群单独搭Swift不如直接用Ceph来得省心。2.4 辅助组件们Keystone、Glance、Horizon、HeatKeystone是身份认证中心所有OpenStack服务在接收请求之前都会先向Keystone校验令牌。它还维护了服务目录也就是某个服务在集群里的具体地址。一些新手在配置文件里写了错误的服务地址登录后界面上看着一切正常但虚拟机一直创建失败日志里报的却是认证过期这类问题多半就是服务目录注册错误导致的。Glance是镜像服务专门管操作系统镜像。你上传一个ISO或者qcow2镜像文件它负责存起来并且提供查询接口。Nova创建虚拟机的时候会从Glance拉取镜像。这里面的关键细节是镜像格式尽量统一为qcow2因为qcow2支持稀疏文件和快照比raw格式省磁盘空间也更容易做后续的镜像定制。Horizon是图形化管理界面适合刚上手的人使用鼠标点点点就能完成大部分操作。但它功能全面性始终不如命令行毕竟是网页应用很多底层参数调整不了。Heat是自动化编排服务用模板描述一组云资源及其依赖关系可以一键拉起一整套路带负载均衡、安全组的业务环境。我个人觉得Heat学习成本虽不算低但它让基础设施真正做到了“代码化”愿意投入的人值得好好研究。辅助组件里还有几个容易被忽略但很实用的比如Ceilometer负责计量监控Barbican管密钥和证书Magnum管容器集群Designate管DNS。它们不是每个部署都必装但可以根据实际需求灵活加入。核心思路还是那句话OpenStack是一套积木需要哪个功能就加哪个组件。3. 从架构到落地部署一套OpenStack要准备什么3.1 节点怎么划分控制、计算、网络、存储生产环境里通常会把节点分成控制节点、计算节点、网络节点和存储节点。控制节点跑API服务、数据库、消息队列、认证服务这些核心管控组件计算节点只跑Nova-Compute和虚拟化管理器专门运行用户虚拟机网络节点负责虚拟路由、浮动IP、防火墙等网络功能存储节点根据你的后端方案决定是否需要单独部署。以我自己的经验最小可用的测试环境至少需要2台物理机或虚拟机一台当控制节点兼网络节点一台当计算节点。内存和CPU规格不用太高控制节点8GB内存加4核CPU基本能跑起来计算节点则取决于你要开的虚拟机数量和规格。如果只有一台机器也可以用DevStack做单节点体验但撑不起多节点的真实场景仅限本地学习。节点之间的网络规划是个被很多人低估的坑。管理网络用于组件之间通信数据网络承载虚拟机流量外部网络负责和外界连通存储网络最好单独跑存储数据流量。现实中很多团队把管理网络和数据网络混在一个网段看起来省事一旦出现流量风暴整个云平台都在抖动根本分不清是管理面出问题还是数据面出问题。最稳妥的做法是把网络讲清楚即使物理上共用交换机也尽量用不同VLAN把多种流量隔开。3.2 部署工具的选型对比部署工具是新手最容易纠结的地方。社区里主流的部署方案有Kolla-Ansible、TripleO、OpenStack-Ansible、DevStack这四类。DevStack就是手动部署的“玩具版”全部服务跑在一台机器上脚本一键搞定适合第一次了解和测试环境不适合生产。Kolla-Ansible是当前社区最活跃的方案把每个服务都容器化用Ansible来自动编排部署。它最大的好处是升级和回滚相对方便因为底层是Docker容器服务隔离性好环境一致性高。缺点是你的节点都得装Docker而且如果镜像拉不下来内网环境下部署会很痛苦。TripleO在早些年很流行它的思路是用OpenStack部署OpenStack先用一个短暂的undercloud再通过它部署正式的overcloud学习曲线较陡新项目不要轻易尝试。OpenStack-Ansible是把所有服务以LXC容器方式部署很多运营商老环境在用文档相对齐全但是玩的人少出问题能查到的资料不如Kolla多。实际选型我给的建议很直接如果团队已经有熟练使用Ansible的人无脑推荐Kolla-Ansible如果只是临时搭一套演示环境用DevStack如果是运营商那种有专门维护团队和固定运维规范的环境才考虑OpenStack-Ansible。3.3 最小环境部署实操Kolla-Ansible方式我以Kolla-Ansible为例说一个比较标准的部署流程。准备阶段先在所有节点上装好操作系统关闭防火墙和SELinux配置好主机名解析确保节点间可以免密登录。然后把时间同步做好我不止一次遇到过因为节点间时间差了几分钟结果Keystone令牌校验全部失败的情况。建议每台机器配好NTP服务统一指向同一个时间源。接着安装Kolla-Ansible的依赖。你需要Python环境、Ansible、和几个相关的Python包。这一步建议用虚拟环境别直接装在系统Python里不然以后升级版本或者安装其他Python工具时容易冲突。重要文件是globals.yml它定义了所有部署的关键变量。你需要在这个文件里指定镜像仓库地址、虚拟网络类型、存储后端类型、网卡接口名称等。网络接口名称一定要写对我就曾经因为把eth0填成了ens160导致部署时网络配置错误所有节点相互发现不了。配置完成后执行kolla-genpwd生成随机密码保存在passwords.yml里。这个文件要好好保管后面任何服务的管理员登录密码都在里面。然后用kolla-ansible bootstrap-servers初始化节点环境把Docker、相关依赖装好。接着kolla-ansible precheck做环境预检查很多配置错误在这一步就会报出来。最后kolla-ansible deploy开始正式部署。deploy完成后你会看到一目了然的输出说明各个容器状态。这时候再用kolla-ansible post-deploy生成一个管理员环境变量文件往里面填入认证地址、项目名、用户名、密码这些信息。后续用命令行操作时都需要先source这个文件它相当于你的“云平台通行证”。整个过程第一次跑可能会遇到不少小问题但只要网络是通的、配置没填错整体并不算难。真正麻烦的是后面每天的运维。4. 实操环节从创建网络到拉起一台虚拟机4.1 认证先了解Keystone的交互打开命令行操作OpenStack第一步不是创建任何资源而是搞定认证。认证之后你的终端环境里会有几个关键的环境变量OS_AUTH_URL、OS_PROJECT_NAME、OS_USERNAME、OS_PASSWORD。这组变量指向Keystone的地址以及你所在的项目和账号。实际使用中会发现一件很有意思的事所有服务在认证时拿到的令牌是有有效期的默认可能是一小时过期后命令行会报401错误。解决办法也简单重新执行环境变量文件就行。为了少踩这个坑我最开始是把环境变量文件写成了一个shell函数每次要操作云平台时先执行一下函数刷新变量。命令行还有一个技巧值得提openstack命令本身支持--debug参数它能打印出完整的HTTP请求和响应内容。当某个API调用失败时开启debug看具体是哪个端点在报错比看服务端日志更直接。4.2 创建一个基本网络拓扑虚拟机的网络配置几乎决定了它能不能正常访问外网、能不能和其他虚拟机互通。所以创建虚拟机之前先确认网络上已经有完整的“网络-子网-路由器”三层结构。第一步创建网络。命令很简单openstack network create demo-net这样会得到一个VXLAN类型的内部网络默认租户间隔离。第二步在这个网络上创建子网openstack subnet create demo-subnet --network demo-net --subnet-range 192.168.100.0/24。子网只是定义了一个私有网段虚拟机即使在这个网段拿到了IP仍然出不到外网。原因是没有路由。所以要创建一个虚拟路由器把内部网络接到外部网络上去openstack router create demo-router然后把子网接口和外部网关分别接上。这套流程做完才算是给了虚拟机一条能通向外界的路径。很多新手创建完网络直接就建虚拟机配了IP却无法上网然后在安全组和防火墙那里折腾半天其实就是忽略了这个虚拟路由器。4.3 创建虚拟机实例有了网络之后创建虚拟机实例就顺理成章了。需要事先准备三样东西镜像、规格、密钥对。镜像从Glance查询用openstack image list找到可用的镜像名称。规格决定了CPU和内存大小用openstack flavor list查看。密钥对是用来登录Linux虚拟机的SSH密钥如果你不喜欢用密码登录可以提前生成或者使用已有的公钥。创建命令大概是这样的openstack server create --flavor m1.tiny --image cirros --network demo-net --key-name mykey my-first-instance创建完成后用openstack server list查看状态。一开始可能是BUILD它会有一段等待过程。如果卡在BUILD状态太久说明底层创建可能出现问题这时候要去查看计算节点的Nova日志。等待虚拟机状态变为ACTIVE后下一步是找到它的控制台或通过浮动IP访问它。在没有浮动IP之前你只能在OpenStack网络内部访问这台机器。想从外部SSH进去需要绑定浮动IP。4.4 浮动IP与安全组浮动IP的本质是给虚拟机再配置一个外部网络的地址。创建浮动IP的过程相当于在你外部网络的地址池里占用一个地址openstack floating ip create external-net然后把浮动IP关联到实例openstack server add floating ip my-first-instance 203.0.113.10。但浮动IP绑定上去以后外部访问还是无法直达因为安全组默认会拒绝所有入站流量。安全组本质上是虚拟防火墙规则。你需要允许SSH的22端口放行openstack security group rule create --proto tcp --dst-port 22 default这里有个细节要注意安全组规则默认没有限制来源IP意味着所有人都能尝试SSH登录你的虚拟机。生产环境务必把来源IP限制到你自己的办公网段否则你的虚拟机就暴露在公网上了。放行SSH规则后你就可以用密钥从外部登录了。整个过程就是把网络搭好、把虚拟机建起来、把访问入口打开、把安全组放行这四步顺下来一台OpenStack上“能登录、能上外网”的虚拟机就真正跑起来了。5. 踩坑记录与常见问题速查5.1 部署阶段最经常翻车的地方部署阶段翻车率最高的地方我总结下来是三个时间同步、DNS解析、Docker镜像下载失败。时间同步在前面已经提过这里重点说说DNS。Kolla-Ansible在初始化节点时需要能访问镜像仓库和系统源。很多内网环境没有配置内部DNS节点之间解析彼此主机名靠的是/etc/hosts但对外访问仓库就不知道怎么走了。解决方式很朴素在所有节点的/etc/resolv.conf里写上可用的上游DNS同时确认镜像仓库域名能解析。给个直接的教训我见过一个团队部署过程中所有检查都通过了但docker pull一直超时最后排查了一下午才发现是公司防火墙限制了访问公共容器镜像仓库。解决办法是临时放通该域名或提前使用离线镜像包导入。Docker镜像下载失败的问题在生产环境尤其常见。如果你的部署环境无法访问外网建议提前在一台能联网的机器上docker pull所有Kolla镜像然后导出成tar包拷贝进去。还可以在globals.yml里把docker_registry改成你们内部的镜像仓库地址部署前先把镜像推送到内网仓库节点从内网拉取。5.2 运行阶段虚拟机各种不正常的排查思路虚拟机创建成功了但网络不通是运行阶段最常见的现象。我分享一个比较高效的排查路径。先确认虚拟机控制台里能看到IP。如果虚拟机内部看不到IP大概率是网卡没有激活或者DHCP没获取到地址先看OpenStack给实例注入的元数据和网络配置是否正确。虚拟机内部IP是通的但外部访问不了接着查路由和安全组。看虚拟路由器上有没有对应的浮动IP映射安全组规则是不是放行了端口。有一个实用技巧直接在计算节点的网络命名空间里抓包。比如用ip netns list找到路由器的命名空间然后用tcpdump -i qrouter-xxx抓包看有没有包进来、有没有回包。这一步能快速确认问题出在OpenStack网络层还是出在虚拟机内部防火墙。还有一种情况创建虚拟机时选择了错误的规格内存超卖导致虚拟机长时间处于启动状态。Nova默认允许内存超卖某次我负责的测试环境里有人一口气开了七八台2GB内存的虚拟机而物理机总共只有16GB内存结果所有虚拟机都慢得像蜗牛。控制节点上查看Nova调度日志里面会明确写出物理节点可用内存不足的拒绝原因。5.3 性能问题的几个常见根源跑了一段时间后虚拟机磁盘读写慢、网络延迟高这类性能问题会逐渐冒出来。磁盘性能瓶颈通常出在存储后端。如果Cinder后端是LVM而且你只有一块物理磁盘那这台机器上所有虚拟机的磁盘IO都在争抢同一块盘性能必然恶化。条件允许的话尽量用多块物理磁盘做LVM条带化或者直接上Ceph这类分布式存储。网络性能问题往往和VXLAN封装有关。VXLAN虽然好配置但每个数据包都要额外封装几十字节的头处理封装和解封装需要在CPU上执行如果物理机的网卡不支持硬件卸载大规模实例场景下性能会明显下降。这里有一个优化方向是使用SR-IOV或者DPDK但这属于进阶玩法了先把基础排障学好更重要。5.4 日志排障时最该看的东西OpenStack排障不看日志基本等于盲人摸象。每个服务都有独立的日志文件这里我给出最常查的几个位置。计算节点的Nova日志在/var/log/nova/nova-compute.log创建虚拟机异常的信息基本都记录在这里。网络节点的Neutron日志在/var/log/neutron/目录下还有一个特别关键的日志在/var/log/neutron/neutron-openvswitch-agent.log如果你用OpenvSwitch做虚拟交换机这个日志能帮你定位大量网络问题。控制节点的Keystone日志和Horizon的HTTP访问日志也会在排障时给你线索。我看日志的习惯是先搜ERROR和WARNING级别的关键字再从上下文时间点慢慢往回看。时间戳一定要对清楚因为OpenStack的组件会异步通信可能A服务十秒前就报错了B服务十秒后才感知到。如果只看当前日志很容易漏掉真正的问题根源。6. 写在最后的个人体会用OpenStack这些年我最深的体会是它的学习曲线确实陡文档质量参差不齐组件之间的关系也比较复杂。但一旦你理解了几条核心脉络——资源是分项目管理的、所有服务都走Restful API、一切状态都可以从数据库和日志中追踪——后面碰到的任何问题都会有迹可循不再像刚开始那样完全看不透。如果你正准备入坑我的建议是别一上来就追求部署生产环境。先在虚拟机里用DevStack跑一遍把界面、命令行摸熟再把网络和存储的概念理清最后才用Kolla-Ansible搭建一个多节点环境。这个过程走完你基本就算半个OpenStack运维了。