企业官网建设流程全解析

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 计算服务Nova：All 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、Heat

Keystone是身份认证中心，所有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运维了。