你驻足于春色中,于那独一无二的春色之中.
这并不是一篇手把手教你部署多节点OpenStack的文章，但是如果你正打算部署一套多节点Openstack，本文可以给你提供一点个人的心得。
部署的第一步就是选好版本，这个专门写给和我一样刚接触Openstack的人。
https://releases.openstack.org/
在这里可以看到已经release的版本，不同的版本在不同系统上的安装难度不同，比如常见的M和L版对于Ubuntu 16.04的支持就不是很好，这时候使用O和N版部署就会更加轻松。
另外，官方文档中的中文版只有M和L版，而且个人感觉使用一些跳转时不够便捷。
网络上能够查找的资料中单节点部署做测试的较多，即便是多节点，大多数也是在虚拟机环境下完成，当然，真正有条件接触大规模物理机部署场景的大牛很多都是对云计算有深入了解的，不需要再在网络查阅过多资料。那么对于和我一样的新手来说，小规模多物理节点部署Openstack又需要注意哪些点呢？
Openstack不同的服务都以组件的方式提供API接口服务，这意味着你可以将不同服务任意拆分到不同的物理机器上，出于网络访问性能的考虑，有一些组件默认应该安装到一起，比如向所有组件提供功能的数据库、分布队列、缓存一般都在控制节点上，提供认证服务的keystone、提供网络服务的neutron、提供镜像服务的glance也会一并安装在控制节点上，通常计算服务和存储服务会被分布到其他物理机上，那么这时就涉及到是横向分配服务，还是纵向分配服务的问题。
横向分配是指计算节点只运行nova，存储节点只运行swift和cinder，这是Openstack官网上给出的范例。
而这里的纵向分配是指包括控制节点在内的所有物理主机都安装完整的计算服务和存储服务
两种方式的区别在于，横向分配易于单组件安装，并且方便管理，当安装或运行过程中出现错误时可以根据错误的情形快速定位到故障物理主机，但是每台物理主机只运行特定一种服务的话，一旦某一类服务的主机出现故障，就会影响整个云服务的使用。
而纵向分配的方式增加了管理成本，一旦出现故障需要对每一台主机都进行排查，但是这样部署的话，控制节点可以自己一人完成所有云计算逻辑，和任意其他主机都能组成扩展性的计算逻辑，如果有多台主机宕机时，只要保证控制节点健壮，就能持续提供云服务。
多物理节点部署时，物理主机的网络拓扑是需要重点考虑的问题。因为单主机或者虚拟机模拟的情况下网络都可以随意修改，但是真实环境的部署无法很方便的改变网络环境。
一个看起来最舒服的方式就是每台主机拥有三张网卡，一个网络用于提供安装时的广域网，一个网络用来主机之间通信，一个网络分配给云服务的浮动IP使用，另外最后一个网络也需要能够访问广域网。用户需要能够访问到Dashboard和浮动IP网络即可，这样用户就可以通过Dashboard申请资源并且通过浮动IP访问内部虚拟机。
当然，这样意味着多张网卡、多条线路等问题。这时就可以根据实际需要对这三个网络进行合并，这样，合并方式就多种多样，甚至于极端情况下，三个网络都用一个物理网段都是可以的。首先该物理网段可以上网，其中前几个IP分配给物理机进行服务通信，后几十个IP分配给浮动IP，注意这时候物理网关和控制节点中的虚拟网关之间的关系和IP流量走向关系，必要时候需要人为设置同一网段中不同IP段的路由，只要能够把单网络这种大家都混在一起的模式理清，其他方式就问题不大了。
官档一般是提供及时、稳定、可行的操作步骤，但是历史上Openstack的官档好像出现过漏掉步骤的现象。
跟着官档的好处在于，你可以一个模块一个模块的构建整个云计算网络，从配置到日志一步一步调试，能够根据官档顺利搭完一整套Openstack，差不多就从小白进阶到新手了 ：）
在进行配置文件编写的过程中，还可以帮助我们了解不同组件之间的调用关系，唯一的不足是，多台物理机这样一个一个来，很容易出现疏忽错误。
Devstack可以看成是部署脚本的整合，只需提供网络和口令配置，就可以套用脚本模板自动化执行，用这个脚本可以比较轻松的构建云服务，而且实验性质的多节点搭建也是支持的。而且可以快速的卸载，但是毕竟这不是官方推荐的部署模式。
比较热门的部署方式，结合playbook部署模式，将每一个服务独立生成为Docker镜像，支持主从机器的大规模部署。而且国内有陈沙克老师提供的CentOS镜像帮助节省很多工作。
个人来说比较支持这种Docker部署的方式，因为部署起来更加，干净。Docker之间的关系是相互关联，对于出问题的部署，直接将Docker删除或者在Docker中调试。并会对本来的机器产生太大的环境污染，唯一需要的考虑的是Docker的性能问题，但是好像有性能测试显示Docker对性能的影响并不大。