应用案例实践OpenStack建立1000+台实体伺服器数据中心Youtube视频

我是 Terry,今天很高兴有这个机会

代表创云数据的团队,

跟各位先进Youtube视频分享 OpenStack 应用案例

那首先呢

未来的 40 分钟,我希望跟大家分享三个题目

第一个叫做建立大型的 OpenStack 私有云

第二个是如何有效率地监控 OpenStack

第三个是关於混合云的应用案例

首先,我们就来讨论一下第一个,

怎麽去建立一个 OpenStack 大型的公有云

那我想呢,大家都很好奇说这个 User 到底是谁

然後用了这麽多、建了这麽多的这个实体伺服器,

答案就是它:楚天云

楚天云呢,它是座落在中国大陆的湖北省

然後它的行业应用别比较特别一点,

是属於政务云的应用

它的建设年份是在 2016 年

数据中心的规模是使用到实体的伺服器,800 台以上

总共用到了 6 套的 OpenStack,

然後存储的总容量是 2PB

那接下来我们带各位到湖北省看一看

湖北省呢,总人口数 6100万人左右,

然後它的省内的行政区有 17 个,

然後政府单位有 52 个

那为什麽湖北省政府想利用 OpenStack

建立数据中心呢?

原因是他们想要利用云端的技术结合不同的资料库,

然後协助湖北省发展他们当地的经济

接下来呢,我们就来看看湖北省

6 个 Region 的设计长什麽样子

首先我们先看 Region 1 跟 Region 2,

我们叫 R1 跟 R2 的 Topology

R1R2呢,它负责的业务有三个:

第一个,是政务外网的接入;

第二个,是异地备援中心的连接

第三个,是提供给 52 个政府单位

它的计算以及存储的资源使用

接下来,大家应该觉得说我要看 R3 跟 R4

很抱歉没有 R3 跟 R4,

因为 R3 跟 R4 涉及到比较敏感的部分,

所以今天没有办法跟各位分享

那我们看看 R5 的部分,R5 是给楚天云的研发人员的

开发以及测试的使用 Region

那他们开发主要是在开发 SaaS 层,

就是 Software as a Service 的这个地方的开发

以及开发完毕之後上线前的测试的部分

他们用 R5 这个 Region 来做测试

R6 呢,最主要是刚刚提到数据库,

那有四大数据库,第一个就是人口资料

经济的资料库,

大家知道中国大陆每五年就会发展一个

他们的经济政策,那所谓「宏观经济资料库」

就是他们会把国家的这个经济发展目标

订在这个地方,结合不同数据库,然後这些数据,

会帮助湖北省政府发展他们的当地的策略

那 R6 除了这个部分以外呢,

它也同时了兼顾了数据的备援的工作

接下来,我们看看 OpenStack

怎麽面对这个 6 个不同 Region的挑战

那挑战很多,我今天跟大家分享三个项目

第一个就是关於快速自动化的部署

第二个,是虚拟机的高可用性

第三个呢,就是 SDN 以及 OpenStack 的整合

首先我们来看看:快速跟自动化的部署

第一个,我请大家看一下这个大型部署 14 个节点

并不是代表我们的 OpenStack 或是说我们的版本

一定要使用到 14 个节点

在中小企业应用我们可以把它缩减成为 4 个节点

意思就是说你可以一个 2U 4 个节点的伺服器,

就可以搭建完成一个 OpenStack 使用

那也因为会有这样的快速跟自动化的部署

我这边稍微说明一下,我们的部署团队不到 20 个人,

部署时间不到一个月,有 800 台以上的伺服器

那部署的人员需要做什麽事情呢?

我们到数据中心的时候,其实是空荡荡的一个空间,

它必须从拆箱、上架、布线、上电、部署云平台,到测试

这些工作必须在一个月内完成

那我们一定需要自动化部属的工具来协助我们

我这边讲的自动化部属工具不是大家所熟悉的 Ansible 这一类的部署工具

我们是利用了一个作业系统,我们把它裁减,

我们姑且叫他 MiniOS

那 MiniOS执行的工作有两个

第一个就是说,判定这个节点

是属於计算节点,还是存储节点

这是一般的资料库使用的部分

其实在处理掉 800 台的伺服器之後,

一定难免会有人为的疏失

所以呢,我们 MiniOS 它可以自动判别伺服器的角色,

然後减少人为的错误的部分

第二个部分就是在存储节点

我们在这个案例里面,我们的 Ceph 有使用到 RAID 卡的设计

那当然不见得每一家的存储节点需要用到 RAID 卡

只是这个案例用到 RAID 卡

那大家知道 RAID 卡的 initialization 需要时间

所以呢,我们 MiniOS 在部署完毕,在搭建云平台之前

它会自动先把 RAID 做初始化,好处是可以缩短交付时间

接下来我们看看虚拟机高可用性的部分

这个地方是非常重要的一个部分

大家都知道社区版本 OpenStack 并没有提供虚拟机高可用性的功能

那在这个部分呢,我们去年在部署楚天云的时候呢

我们用大家最常用的方式叫 IPMI

IPMI 的方式来做部署,大家可以看到这个逻辑流程

就是当 IPMI 故障

代表说这个实体服务器相对也故障了

在这种情况底下我们用执行虚拟机疏散的指令

然後我们在整个搭建的过程中,有个情况就是说

有些人呢,会自己去拔 IPMI 的线

或是网路线故障

这时候呢,并不是 IPMI 故障,是 IPMI 侦测不到

在这种情况底下,我们一样是执行 VM 的这个 evacuate 这个指令

将虚拟机疏散到其它的伺服器节点上面去

那我这边要特别强调说在半数以上

伺服器故障的时候我们这个 VM evacuate 不会执行,为什麽呢?

因为当一个数据中心半数的(服务器)伺服器故障的时候,

代表可能是遭到断电、停电、或是有天灾的发生

为了做灾害控管,这时候我们并不会执行任何的虚拟机疏散,

直到伺服器恢复了正常的时候,我们的服务才会自动恢复正常

那这个地方是我们去年在虚拟机高可用性

搭建在楚天云上面的做法

但是这样的方法是可行的,只是太粗糙了

所以今年呢,我们稍微做把虚拟机高可用性做了一些修改

我们在 NOVA,就是在计算的 Controller里面,

我们多加了一个叫做 HA Stack 的模组

这个模组呢,我们增加了几个功能

第一个我们增加了 SanLock

第二个增加了集群管理

第三个我们增加了网路侦测

第四个我们加了 QEMU 的 Client Agent (QEMU-GA)

那每一个增加的功能都有它的工作

第一个,我举一个例子,SanLock

大家知道的 linux 常用的这个软体的部分

它是防止脑裂的机制

然後集群管理呢,或是多网路侦测

我们是提供完整的虚拟机的高可用性的策略

第三个就是 QEMU 的 Client Agent 是相当成熟的开源软体

它最主要是侦测虚拟机是否异常

也因为我们加了 HA Stack,那我也增加了这麽多的新的软体

那我这边特别强调,就是说在上一页的这个逻辑流程呢

我们只要是拔线或是 IPMI 侦测不到的时候,

我们就执行虚拟机的疏散

我说这样的做法可行,但是太粗糙

也因为增加了 HA Stack,我们今天多加了一个流程

叫做 check other networks

那它有不同的网路的失效的情况处理

那我们侦测哪些网路呢?

有管理网路、有存储网路、有租户网路

那我这边举个比较特别的例子

就是说当管理网路跟租户网路都不通的时候

可是,它的存储网路却是通的

我这边写 HA 的动作叫「低服务类型」

什麽意思呢?

如果这个 OpenStack 是使用在一般办公室的环境

或是在研发环境,这通常租户网路非常重要

当这种情况发生的时候

那我们的平台会发出告警的机制

通知维运的人员去做 VM 的疏散,

或是做 VM 的 Migration

可是如果这个 VM 是在做数据分析的工作

它用的、依赖的是存储网路,这时候只是发出告警

维运的人员也知道,这个地方有出现异常

但是,因为它是做数据分析的作业,仰赖的是存储网路

这时候不用急着做 VM 的疏散或是迁移

直到工作做完,维运人员再做下一个动作

因此呢我们加了 HA Stack 之後,在虚拟机高可用性,

大家可以看到我们提供的策略变多了

然後这个细致度变得更高了,

这是我们今年的做法

第三个题目,就是关於 SDN 跟 OpenStack 整合

那我这边有列出了各种不同的在楚天云遇到的难点

我今天时间的关系没办法一一的说明

我今天要说明的是 SDN,为什麽需要

SDN?

因为 SDN 呢,大家想看看,

在这个环境下有 800 台以上的伺服器,有这麽多的租户

一旦有个租户要求他的网路配置去做修改的时候呢

那如果没有 SDN 控制器

我们的维运人员必须到每一台交换机去更改设定,帮他改权限

这时候我们会浪费这维运人员的工作效率

如果这时候你多了 SDN 控制器,

那 SDN 会自动下发配置,然後配置下发完毕之後

它会回覆给 Neutron

在这种情况底下,可以减少维运人员的工作

loading,速度也加快了

也因为这样子,我们楚天云案例让我们了解到说

其实 SDN 的商机其实是越来越重要

如果在这个数据中心越来越蓬勃发展的同时

所以呢,今年我们创云数据就成立了一个 Project

去自行开发 SDN 的控制器

简单来说呢,SDN 控制器

我们可以去减少维运人员的 loading

同时它可以增加可程式化的逻辑,或是服务的部分

可以加快我们这整个平台的使用

那这个地方是我在 SDN,我们今年创云数据的规划

接下来呢,我们看看也因为我们楚天云的部分

我们难免会跟其它的人做比较

这个是去年中国数据中心联盟举办的一个活动

总共有七家厂商来参加评比,

其中不乏各位可能听过的一些知名厂商

那创云数据在各个不同的资源调度效率的评比里面,

其实得到的分数不是第一名就是第二名

我这边想要强调的是批量创建跟删除虚拟机的重要性

因为这个地方我们快了平均值将近 30%

为什麽呢?如果今天你应用我们云平台在订票系统

那如果忽然间流量暴增的时候,

如果你的批量创建虚拟机的效率越高

那代表这个主办单位它的订票效率就越高

所以我特别强调在批量创建跟删除虚拟机的效率

其实我们得到非常好这个的成绩

也因为有这样子优良的数据,或是杰出的数据

那我们去年整个团队所努力的楚天云在中国大陆有一个选拔,

叫做 2016 年的 OpenStack 杰出(卓越)案例

楚天云是当选了当年度的 OpenStack 卓越案例

那在 总共有10个卓越案例,

那唯一一个是唯有这个楚天云是政务云

也因为它的杰出案例,变成是当地政府作为一个政务云杰出的标竿

接下来我们谈一谈怎麽去有效的监控 OpenStack

其实监控 OpenStack 这个话题呢,我们先来看看

有些人觉得 OpenStack 很复杂,

有些人可能觉得 OpenStack 很不稳定

为什麽呢?

我把几个问题可以区分成几个点来看

第一个叫做搭建云平台

第二个叫故障分析,第三个是高节点应用,例如说

资源调度、裸机服务、或是容器的技术

最後一个是升级补丁

那因为每一个人员对 OpenStack 的了解程度不一

所以有些人觉得它很简单、有些人觉得它很复杂

那因为他们每个人对於 OpenStack 的了解程度当然会有不一的情况

那了解程度跟监控有什麽关系呢?

我这边举个例子来看

那这边,左边是土星火箭,它是阿波罗13号的太空载具

右边是哥伦比亚号太空梭

那这两个太空载具都可以载各位上太空

那请问哪一个太空载具大家会有比较多的信心?

我们看看它的驾驶舱

左边是阿波罗13号的驾驶舱

右边是哥伦比亚号的驾驶舱

我想大家都看得到它的差异

差异在哪里呢?其实是监管的数据变多了

控制的按钮变多了

那监管的数据和控制的按钮,其实就是监控两个字的意义

也因为这样子,我相信各位在选择太空载具大家都会选择是右边的哥伦比亚号,因为它给你的信心度增加

所以我们看看,如果在搭建云平台的同时我们也增加了监控的这个模组

那因为你增加了监控模组

当故障发生的时候,有监控的模组告诉你资源的使用,

或是说哪些的服务停止了

可以让你对 OpenStack 复杂度跟信心度增加了

如果你要使用高级的功能

它可以告诉你资源的使用度,那你也知道说

怎麽去使用这些高级的功能

甚至到升级补丁的情况,这些监控的模组告诉你说

这个 OpenStack 是否稳定、不稳定是不是该升级

那监控的数据,其实监控的模组对於

OpenStack 复杂度跟稳定性有一定程度的帮助

也因为这样子,OpenStack 呢,这个社区他也注意到

监控一直是一个 OpenStack 难点,那所以在 OpenStack

有一个叫做 Monasca 的 project

我这边呢,帮各位把重点用红字标出来

它有几个特性,第一个叫 multi-tenant,第二个是 high scalable,第三个 high performant,第四个 streaming alarm engine and notification engine

简单来说就是它提供了多租户、高扩充性、然後具有高效能,以及它有实时告警的功能

那这个部分呢,我们就利用了这个 Monasca 的 project,我们就开发自己的监控工具

我们叫他 “StackCascade”

那这个部分是我们去年在楚天云监控的做法,就是大家可以看到这边是 OpenStack 的 Portal,我们叫它 Horizon

我们透过一个跳转的机制可以进来我们的 StackCascade 的 Dashboard

里面有个 Data Source 的一个模组,最主要是接收 Zabbix 跟 Elastic Search 的资料源

那这些部分我们可以监控到实体机,实体的设备、虚拟机的部分

那在 M 版以後更有 Gnocchi 这个模组出现,可以由 Ceilometer 提供资料给 Gnocchi

那这整个作法呢,我想是在座各位如果使用 OpenStack 常见的这个监控的做法

那 StackCascade 做法稍微做一些调整,我们自行开发 StackCascade Engine

我们 Leverage monasca 一些部份的资源,我们也开发了 StackCascade 的 Engine

那 Agent 是收集资料,Engine是做实时的告警以及做资料的分析

那这些我们最主要就是要提供 OpenStack 提升 OpenStack 监控的功能以及服务的效率

那这个部分,我们目前楚天云是在白色部分

右边是我们计划的部分,我们希望在年底能够完成一部份 StackCascade 的功能,然後将楚天云的监控予以提升

那关於 StackCascade 的架构或是更多的特色呢,

接下来我想要把时间交给创云数据的架构师

林俊成 Jim

Jim 他等一下会分享 StackCascade 这个架构的特色,以及它的特性

他也会同时跟大家分享在开发 StackCascade 的时候,他面临到的一些困难,以及怎麽用混合云的方式来解决这个问题

让我们来欢迎 林俊成,这次的Youtube视频分享到这里结束。