OpenStack高可用集群实施案例.pdf

OpenStack高可用集群实施案例

1

1.规划与部署

本次分享提炼自我们在某企业部署OpenStack高可用集群的实际案例，初期平台面向公网给部分部门提

供虚拟化基础设施，但仍属于私有云。其中我借鉴了以往操作比如oVirt（RHEV）、VMWare、Citrix

等项目的经验。考虑到时间关系，本次内容将以方法为主，减少细节描述。还有本次涉及到的工具多以开

源形式呈现，尽量不涉及到产品，以方便大家集成或开发。

架构简图可参考如下，稍后我们会就其中细节进行讲解。两个架构图的区别在于控制节点的高可用方式。

2

1.1.基本环境

3

因为客户网络环境复杂，为了节省部署时间与减少返工率，我们需要在去现场之前准备好以下三种安装方

式：

lPXELiveCD

l定制系统安装盘

l安装包与安装脚本

第一种方式即在用户网络环境下使用现场人员笔记本或者客户服务器启动PXE服务，配置好系统架构（服

务器MAC地址、网络配置、存储配置、对应的OpenStack模块与角色、定制包、系统微调与优化措施

等），然后开始全自动安装，功能与Mirantis类似，但对网络要求低很多。

第二种方式既是采用定制的系统安装盘，里面需要准备尽可能多的存储设备与网络设备的驱动，以尽可能

适配客户服务器与实施人员的自带存储设备。

第三种方式作为前两种方式的替补选项，主要是因为某些客户环境中安装非标系统需要走很多流程，我们

提前让客户准备好操作系统，再到现场安装。如果给你准备的系统是RHEL、SUSE或者其他标准Linux

系统的倒还好，如果他有情怀地花了一两天给你现编译上了Gentoo甚至给你准备了一台小机，那就没办

法了（开玩笑，尚未遇到过这样的客户，在进厂之前要把基本环境沟通清楚）。另外，它也可以作为以上

两种安装方式失败后的最佳选项。

4

这几种方式也不能说孰优孰劣，从效率上来说我推荐第一种，但针对难以定制的商业虚拟化我们就只能采

取手动安装的方式了。

题外话：很多所谓“5分钟装完IaaS”的“神话”都不把服务器从启动到改BIOS配BMC/IPMI的时间算

进去。

1.2.网络规划

这一步骤优先级最高，我们必须在动手之前就按照功能区域把网络进行划分，包括管理、网管、存储、租

户、显示、迁移等。当然，很多情况下没必要划分太细，因为我们要根据用户网络环境和软件特性对他们

进行规划，规划太细发现最后配置难以实现，“一把梭”规划发现用户一上来就喊卡。

一般来说，客户的物理网络主要以VLAN为主，其他情况暂不讨论。对于非核心层的虚拟化而言，我们看

到的多是untagged网络，所以规划时要时刻留意网关与掩码；而对于核心层的虚拟化，那么我们很有可

能得到一堆tagged网络，都由我们自己与客户商讨规划。

在网络硬件上，仅就虚拟化层面而言，KVM系列的要求不高，而VMWare的FT则要求较为苛刻，万兆、

IB等都是标配（题外话：KVM的FT功能尚不稳定）。如果涉及到下面要讲到的“超融合”，那么万兆专

用存储网络真的是标配了。如果应用层面涉及到诸如Oracle之类的应用，那我们很可能就要使用网络设

备透传了，也可看规划选择性地走RDMA。

5

当然，在现场时我们很有可能遇到交换机是全新并且客户网管也不太会配置的情况，虽然极少但也是有的。

秉着专业事儿交给专业人来干的原则，咱们可以等，等网管把交换机配好（客户沟通妥善时自带网管技能

也行）。

网络规划时，我们在最大限度保证带宽的同时，要给予整体充分的可扩展性。这次项目中，为了给予客户

享受科技带来的便利，比如OpenStackNeutron便利网管、实现NFV导流、FabricNetwork、Packet

BrokenNetwork、减少网络单点故障率等等，我给客户推荐了几台SDN交换机与其Neutron主机集成，

然后可以在OpenDayLight里开发应用程序并与OpenStackDashboard结合呈现出看起来高大上的界

面和功能，最大限度地利用OVS。（这里要感谢上海同悦信息龙未来先生协助开发的应用）

1.3.存储规划

如果用户那有现成的存储设备那就最好不过了，但也有利有弊。好处是减少了我们的运维负担，关键时刻

也可以“甩锅”；坏处就是现有存储很可能限制我们平台的能力，也存在潜在的兼容性风险。

6

由于软件定义存储的风行，尤其是VMWare带来的业界领导作用，客户有可能想当然地认为虚拟化层面

的存储就该我们自己负责。那没办法了，要么找个通