赖羿明：各位下午好，首先请允许我先自我介绍一下，我来自联通云数据有限公司云计算与大数据研发部，我的名字叫赖羿明，现在就职于我们联通云公司的高级项目经理职位，我也很荣幸能跟随我们联通云数据公司跟了很多行业和政企大的项目，也使我成长颇多。同时对我们整个开源云计算这个行业以及我们沃云自身都有一个更深的了解。今天跟大家分享的题目是沃云平台高可用实践分享。
当下无论各位的企业还是政府，他们自身都有很强的动力，去将自己原有的IT信息系统往云上部署。上云整体来讲是个趋势，除了国家政策驱动之外，采用云计算与虚拟化的技术，确实会为使用者和租户带来明显的好处。首先会明显提升IT基础设施资源的利用率，通过虚拟化的技术我们可以大幅度提高单台CPU、内存还有存储使用率，可以用更少的投资做更多的事。同时针对更多的中小企业来讲，他们通过购买第三方的公有云的平台资源，可以减少各种非核心的IT基础设施的投资，他们将可以更加专心专注于自己的业务。第二点，云计算具有部署灵活和可扩展性高的特点，应用运行在云计算的各种虚拟化的设备中，本身与物理机是解耦合的，可以方便的实现资源的管理和调度的调配，同时也可以实现资源的快速交付开通、按需扩展规模。第三点，提高我们整个IT环境管理的效率，利用虚拟化的工具和统一的云平台监管的平台，我们可以对云资源实现统一的调配和调度，提升整体的管理效率。四是借助云平台，借助整个虚拟化的各种技术，可以有效提升服务应用的可靠性、服务的连续性。比如说一般来讲我们的云平台，我们的计算节点都会以集群的形式对外提供服务，单台节点挂掉之后，我们可以很方便的利用我们的云技术，将所有的寄宿在这台宕掉的主机中迁移到健康的虚机中，来保证业务的高可用性和业务的连续性。
除了上云会带来一些新的技术和实现的改变，更重要会带来管理模式的改变。在传统企业的信息化的建设上，如果采用这种传统的方式，或者说这种烟囱式的模式，通常每一套应用系统均要部署一套属于自己的服务器、硬件平台、数据库以及中间件。根据我跟过的许多项目来讲，他们原则有关的这些信息化系统如果采用烟囱化的方式建，基本上很难进行统一的管理，同时他们每个系统由于是单独建设，会有自己单独的规划、单独的需求，很难做到系统之间的互联互通。采用购买云服务的方式，我们就相当于为整个部门进行一个统一的资源的分配、资源的管理，当业务部门想要构建自己的应用系统平台的时候，我们直接从统一的管理平台将各种可需要的资源以服务的方式交付给他，实现这种灵活、快速的部署，就由这种传统分散的效率低下的管理模式变成了集中高效统一的管理模式。
同时采用云化之后，对整个平台运维也提出了更高的要求。首先我们所有的云平台建设实际上都要以客户的业务为驱动，客户购买云服务肯定想专注于自己的业务应用，更多的钻研自己的业务为出发点。在应用往下这层，他们不想过多投入精力。作为一个云服务商，我们构建云平台，势必要把越来越多靠近业务侧的一些组件、通用的功能纳入我们提供服务的范围内，要将越来越多靠近业务侧的东西变成我们标准化、模块化的服务，去提供给用户，去实现业务的快速交付、灵活部署，提供一个可靠的支撑的IT环境，也就是说我们的云服务商势必要从提供传统的通用的IaaS层向提供PaaS服务和SaaS服务进行转换，越贴近于SaaS层，建的云平台的等级越高，对于我们整个平台的可用性和运维都提出了更高的要求。同时由于我们采用的是这种大集中式的建设方式，集中化的提高会带来大管理、大运维，整体来看对我们的运维和平台的高可靠性提出了更高的要求。
我现在再来说一下我们联通所谓坚持选择这种开源的路线，我们这个沃云平台是依托于当年我们联通研究院的一项项目，他们当时对市面上主流的开源的云计算无论是底层的虚拟化技术还是云管理平台开源的软件，最终确定使用OpenStack加KVM来满足我们沃云发展的需求。用OpenStack+KVM，首先我们得到几点好处，一是开放，OpenStack是一个庞大的稳定的开源社区，也可以通过开源的方式去解除这个厂家的锁定。同时我们通过OpenStack，我们可以提供平台型的解决方案，我们通过OpenStack+KVM的方式，不光搭建我们的公有云资源池，也同时为我们的客户搭建私有云或者专享云的解决方案。同时采用了开源的方案，我们可以减少许多license的支出，是一个低投资低成本的方式。同时OpenStack自己本身所有的接口都是标准化的，二次开发的难度下降。同时各位组件具有松耦合的特性，我们在专享云中可以根据客户的各类需求进行灵活的调配。同时还有易用性。这个图是我们沃云平台使用了各类的开源组件，左边主要用的OpenStack内部的组件，首先是比较重要的Nova、cinder、neutron、MySQL等等这些内部的组件，除了OpenStack内部的这些功能服务的组件，我们还融合了很多其他的开源的组件，去丰富我们沃云平台的功能，比如我们利用haproxy实现高可用和负载均衡，vyatta提供VPN，Zabbix实现整个云平台对物理资源和虚拟资源统一管理监控的平台，还有很多，不一一赘述。
在我们沃云理解的云环境的HA或者这个高可用，主要是分三个层次，首先是应用层的HA。它可以包含应用级的双活、主备或者数据级的备份，或者说虚拟机层面的高可用。往下一层就是所谓的云控制服务和IaaS层的HA，实际上就是云的高可用。最底层是硬件以及基础设施的高可用，包含基础的网络、基础的各类硬件设施以及机房环境条件的高可用。本次我跟大家分享的主要是云环境、云平台的高可用。
说了这么多高可用，先说一下高可用到底是什么，有些关键的概念。首先高可用的定义，在本地单个组件发生故障的情况下，能够继续访问应用的能力。这种服务的能力一般来讲我们可以用服务的SLA或者这个服务的可用性来描述。这个服务的可用性一般来讲我们可以用这个服务是有几个9的可靠性来描述，比如四个9，某项服务的可用性达到99.99%，意味着在一年当中这项服务只有52.56分钟是不可用的。如果更高一个层面，比如说99.999%，就证明这个服务一年中不可用的时间只有5分钟左右9个个数越多，可靠性越高。什么叫服务的不可用，首先应用无法访问，服务终端，应用访问缓慢，无法持续对外提供这种服务。这个不可用实际上协调分两类，首先是计划中和非计划中的，计划中，由于我们定期的对硬件软件进行升级而造成的计划内的对外服务不可用的形式，一种是计划外，软硬件突发的故障导致的不可用。从整体高可用的目标上来讲，我们当然希望这个云平台所有的服务是一直可用的，物理层面也是一直没有宕机的。但现实中这个问题一定会存在，所以我们在高可用这个层面上来讲，我们实际的目标实际上是要降低故障发生的频率，也要降低单次故障发生的时间，降低故障所波及的范围，同时尽量通过我们云平台各类高可用的技术，让客户对平台发生的故障是没有感知的。
针对高可用我们也是有两种通用的切换维度，首先是RTO，业务恢复时间目标，RPO数据恢复时间目标，针对这种本地的服务的HA，我们主要看重的是业务恢复时间的维度。高可用框架背景下，我们的服务分为两类，一个是有状态服务，一个是无状态服务，有状态的服务，他的下一次服务的请求是依赖于上一次服务请求关联的关系。无状态的服务，每次服务请求与请求之间，相互之间没有强联系。这种服务的分类是我们采用何种高可用的方案有着很大影响，对于我们HA的实现方案的种类，我们分两种，一种是所谓的Active/Passive，一般来讲需要主备的方式，另外还有一种叫Active/Active，如果是两台就是双活，如果是多台就是多活。
整体介绍一下我们沃云使用OpenStack的这些组件这些架构，我们主要在OpenStack里面使用的组件是neutron、nova、glance、ironic、trove等，glance为虚机、数据库提供镜像服务，ironic是我们新纳过来的一个组件，是用来提供整个沃云平台里物理机及服务的需求。我们现在拥有RDS服务有RDS for MySQL。
基于沃云OpenStack底层的架构，我们实际上是对原生的三节点的部署方式进行了一种小的调整，原生OpenStack三节点部署，我们需要部署一个控制节点，一个计算节点和一个网络节点，针对于虚机整个云平台东西向流量，由于虚机都是分布于多个计算节点之中，所以说东西向的流量就会由不同的计算节点互相之间进行流通。但是如果是想进行南北向通信，所有的流量都会集中到我们所谓的网络节点中。如果当这个云平台的规模非常大之后，所有的南北向的流量都会集中流向网络节点再向上，这个网络节点就会成为我们整个资源池整个平台中一个性能的瓶颈。为了消除这个瓶颈，我们做了一个简单的改动，在原生架构之上，我们将独立部署的网络节点进行了消除，我们将其内含的所有的组件分布部署在计算节点中，这样每个计算节点有了南北向流量通信的能力，从而为我们整个沃云的架构稳定性和可靠性都有提升。
介绍一下我们现在整体的沃云平台里高可用实现的这些事情。首先针对云平台中不同的组件，我们肯定是要根据不同的实现的策略去实现我们所谓的高可用。但是我们也一定要确定一个实现的规则和实现高可用的原则。第一个，定增加冗余节点，无论在硬件上还是云平台的软件上，防止出现单节点的故障。第二个是我们要因地制宜的根据不同的服务采用比较成熟的failover故障恢复的技术。我们在高可用的方案实践上，我们尽量要采取多活的方式加负载均衡这种方式，类似于集群的方式去实现。如果我们实现困难，再利用所谓的主备的方式实现服务的高可用。同时我们也尽量在平台中使用OpenStack原生技术，实现困难无法便捷实现功能的时候，我们再引入外部工具。
首先我向大家介绍的是我们沃云平台针对我们OpenStack管理节点高可用的实践。整体来讲，我们主要做了这么几件事情，我们用了三台物理节点构成集群，使用MySQL Galera这个插件，同时用RabbitMQ构建集群，用haproxy进行负载均衡。我们对管理节点高可用，我们采取的所谓的高可用的方式是想采取多组多活的方式，我们一定要在物理节点冗余的选择上采取奇数。同时用MySQL Galera这个插件去实现MySQL数据库的集群化，多机读写，保证三台管理节点和数据库数据的一致性。相似的RabbitMQ，消息队列也是一样的，我们也是跨三个节点部署这个集群，然后去保证三台节点中消息队列和镜像信息的一致性。虚拟IP，我们引入了Keepalived引入了对外服务的虚拟的IP，通过它我们可以做到这个虚拟的IP在三台管理节点的网卡中进行自由灵活的调度分配，遇到故障之后可以进行漂移。在管理节点中，同样也会运行很多OpenStack的api的服务，在我们这个平台里这些组件基本上都是无状态的，我们会在每一台管理节点中都部署相同的服务，通过Haproxy进行集群的负载。
这张图展示了一下我们整个管理节点所用到的所有的组件，无论是keepalived还是Haproxy等，整体上我们做到了管理节点上的多组多活。
到了网络组件，首先介绍一下L3，我们采用的是社区里面提供的原生的VRRP方案，虚拟路由协议的方案，我们也通过引入keepalived去实现vrouter高可用。在两台计算节点上，我们分别启一个vrouter，通过心跳监测，当备vrouter接收不到主vrouter，就认为主的宕掉了，它就起来去服务。网络组件另一个是DHCP Agent HA，实现起来还是比较方便的，在我们实践中，一般在多个网卡的控制节点去部署多个DHCP的Agent，为了为某个租户的网络提供多个DHCP的服务，去实现所谓的高可用。
接下来是计算节点高可用，我们首先肯定是计算节点发生之后之后，我们的处理方法，要将故障计算节点上的虚拟机都灵活的漂移到健康的宿主机中。但是我们实现的方式是这样，我们将比如每三台或每五台计算节点，我们在这个资源池内划成三个或五个为一组，检查管理网、存储网和业务网的连通性。比如说compute1这个节点，通过业务网络一直pin compute2和compute3，如果发现一直pin不通，它的虚拟访问不到网络，服务出问题，也就说明compute1出了问题，这个时候要出发我们自己相应的虚拟机迁移机制，将虚机往健康的宿主机上去迁移，实现所谓计算节点高可用。
说到存储节点，我这边主要介绍一下我们Cinder-volume服务高可用。首先我们也是引入casemaker，采用主备的方式，我们的策略是在每个沃云资源池AZ部署多个cinder-volume服务，以这种主备的方式实现cinder-volume服务的高可用。
针对整体高可用实践的总结，首先通过我们之前这些分析和角度，这对于云平台来讲，高可用性、高运维度是云平台本身一个亮点的东西，它也是在构建我们云生产环境中必须具有的能力。我们平时在客户进行交流的时候，我们肯定会或多或少放大云能够提供的带来的好处，高可用是在我们沃云构建中考虑得非常多的一件事情。在选择高可用这个模式方面，我们尽量是以多组多活的方式为主。我们基于OpenStack原生的功能以及对自身服务的特性进行二次开发，实现了云管理节点高可用、网络组件高可用以及存储和计算节点高可用。
以上我提到的所有的功能已经广泛应用于我们沃云平台，已经服务了我们绝大多数客户。一些非常早期的客户我们也将会通过我们云平台迭代升级来实现上述的这些功能。
再简单说一下我们通过沃云平台现在已经服务了哪些客户和实现了哪些案例。我们的案例主要包括五大省级的政务云。沃云平台，我们云公司提供了从顶层设计调研规划开始，一直到应用的部署迁移，以及私有云应用部署的一套的解决方案。我们除了深耕政务云，我们也着力打造教育云，通过OpenStack开放特性，我们也实现了物理平台和虚拟化平台混合部署的架构。同时我们还做外企的车联云的平台，通过我们的平台与第三方云平台API的调测，我们提供异构混合云的部署，承载国际客户车联信息化的平台。同时我们也为很多省份的环保云平台做过成功案例，首先他们使用公有云、私有云混合部署，通过我们沃云平台提供大数据的服务能力的支撑。对于企业这块，我们也有公有云，通过我们公有云按需付费、按量使用的方式，我们为很多中小企业也进行了服务的支撑。针对政务云来讲，我们深耕细作，于今年3月也率先推出了沃云电子政务云的白皮书，在这个白皮书里面我们推出了电子政务云很多标准化、模块化的产品以及对流量的模型，以及云网一体化总体架构进行了说明，我们云公司希望通过对我们这个云平台深耕细作以及对这个行业的深入了解，要从一个行业的参与者变成一个规则的制定者。
我今天的分享到此结束，谢谢大家!