别再硬啃官方文档了！用CentOS 7和Stein版手把手带你部署OpenStack（附避坑清单）

从零构建OpenStack Stein实验环境：CentOS 7实战指南与避坑手册

当两台闲置服务器遇上OpenStack，技术宅的快乐就这么简单。这不是又一篇官方文档的复刻，而是一位踩过所有坑的实践者，为你梳理出的最短学习路径。我们将用最少的命令、最清晰的步骤，在CentOS 7上构建一个真正可用的Stein版本实验环境——即使你从未接触过云计算平台。

1. 环境准备：别让基础配置毁了你的实验

OpenStack对硬件并不苛刻，但软件依赖却像多米诺骨牌。我建议使用两台x86服务器（或虚拟机），每台至少4核CPU、8GB内存、100GB磁盘。实际测试中发现，内存不足是服务启动失败的首要原因。

1.1 系统初始化配置

先在所有节点执行这些基础操作，能避免80%的后续问题：

# 关闭NetworkManager（与OpenStack网络服务冲突） systemctl stop NetworkManager systemctl disable NetworkManager # 设置SELinux为permissive模式（调试完成后再考虑严格模式） setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config # 清空默认防火墙规则（后期再按需开放） systemctl stop firewalld systemctl disable firewalld

提示：生产环境不建议禁用防火墙，但实验环境优先保证服务连通性

1.2 时间同步的隐藏陷阱

OpenStack服务对时间同步极其敏感，但NTP配置不当会导致认证失败等诡异问题。推荐按以下顺序配置：

1. 控制节点作为NTP服务器：

   yum install -y chrony cat <<EOF > /etc/chrony.conf server ntp.aliyun.com iburst allow 192.168.100.0/24 # 根据实际网络修改 local stratum 10 EOF systemctl enable --now chronyd

2. 计算节点同步控制节点时间：

   sed -i 's/^server.*/server controller iburst/g' /etc/chrony.conf systemctl restart chronyd

验证同步状态时，别只看chronyc sources，还要检查各节点间的实际偏差：

# 在控制节点执行 chronyc tracking | grep "Leap status"

2. 核心服务部署：避开那些"理所当然"的配置误区

官方文档的安装顺序其实暗藏玄机。经过数十次部署测试，我发现这个顺序能最大限度减少服务依赖问题：

2.1 数据库配置的魔鬼细节

MySQL的这三个配置项，直接影响后续服务稳定性：

[mysqld] default-storage-engine = innodb innodb_file_per_table = on collation-server = utf8_general_ci character-set-server = utf8

安装后务必执行：

mysql_secure_installation

注意：回答安全问卷时，密码强度策略可能阻止简单密码，但实验环境可暂时降低要求

2.2 RabbitMQ的隐形门槛

消息队列服务看似简单，但这两个参数必须调整：

# 增加文件描述符限制 echo "ulimit -n 102400" >> /etc/profile.d/rabbitmq.sh # 修改连接心跳时间（防止云平台操作超时） cat <<EOF > /etc/rabbitmq/rabbitmq.conf heartbeat = 60 default_vhost = / EOF

验证服务时，别满足于systemctl status，应该实际测试消息收发：

rabbitmqadmin list queues name messages

3. 网络部署：Neutron的"死亡沼泽"突围指南

OpenStack网络服务堪称新手坟场，以下配置方案在Stein版本实测通过：

3.1 双网卡拓扑结构

推荐采用这种经济实用的网络方案：

+-------------------+ | 控制节点 | | | | ens33: 192.168.100.10 (管理网) | ens34: 10.0.0.10 (Provider网络) +---------+---------+ | +---------+---------+ | 计算节点 | | | | ens33: 192.168.100.20 (管理网) | ens34: 10.0.0.20 (Provider网络) +-------------------+

3.2 网络服务配置速查表

不同网络类型的关键参数对比：

配置Provider网络的具体命令：

openstack network create --share --external \ --provider-physical-network provider \ --provider-network-type flat provider

4. 验证与排错：从"能用"到"好用"的关键步骤

部署完成只是开始，真正的考验在于服务联动测试。这套验证流程能发现95%的隐藏问题：

4.1 服务健康检查清单

1. 认证服务：

   openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue

2. 镜像服务：

   openstack image create --file cirros-0.5.2-x86_64-disk.img \ --container-format bare --disk-format qcow2 cirros

3. 计算服务：

   nova service-list | grep -v ":-)"

4. 网络服务：

   neutron agent-list -c alive -c binary -c host

4.2 常见错误速查手册

当遇到服务异常时，按这个顺序排查：

1. 日志位置：

   • /var/log/keystone/keystone.log
   • /var/log/nova/nova-api.log
   • /var/log/neutron/server.log

2. 高频错误代码：

   • HTTP 401：检查Keystone endpoint和token
   • HTTP 403：确认用户权限和项目配额
   • HTTP 404：验证服务URL和端口

3. 服务启动顺序： 如果遇到依赖问题，按这个顺序重启服务：

   systemctl restart mariadb rabbitmq-server memcached systemctl restart openstack-keystone httpd systemctl restart openstack-glance-api systemctl restart openstack-nova-* systemctl restart neutron-*

在控制台看到Horizon登录页面只是开始，真正的胜利是成功启动第一个实例。当那个小小的cirros虚拟机终于响应ping请求时，你会明白这些繁琐的配置都值得。记住，每个OpenStack专家都经历过无数次service xxx restart的折磨——区别只在于，他们知道哪些错误可以安全忽略。