吴德新：大家下午好，我是海云捷迅的吴德新。今天很高兴有机会跟大家分享一下我们基于OpenStack构建企业私有云在产品化这个方向积累的一些经验。
今天介绍的内容分两个部分，第一是产品架构，第二是产品特点。
从产品架构来说，首先说一下为什么我们的产品架构会设计成我们后面会提到的这个形态，首先看一下企业客户对OpenStack的需求分析。大家知道OpenStack是一个非常大规模的社区，它不是一个单一的项目，也不是一个开箱即用的产品，当企业用户基于OpenStack构建私有云的时候一定会碰到如下需求，比如软硬件选型、架构设计、性能调优、运维支撑等。在硬件和软件的选择上要根据需求做相应的选择。大家知道OpenStack每个项目、每个组件可能都是这种插件化、模块化，后端都有不同驱动的实现，需要根据整体云平台的需求设计来做软件的实现。在架构设计方面，在前期也要考虑既要满足当前以最小的资源能够把云平台落地，同时也要考虑后期业务增长之后扩容的需求。怎么能够做到云平台本身的横向扩展，这部分在前期设计的时候也要特别考虑。在性能调优这部分，需要考虑整个全栈参数综合的调优，因为OpenStack整个技术栈涉及到OpenStack本身、虚拟化以及操作系统、内核、计算、存储、网络等等组件，涉及到的参数成百上千，整体上怎样能够给客户提供一个最优的软硬件结合的性能，这个需要从整体上去做调优。另外一部分是运维支撑，我们都知道一个云项目最终的落地或者成败与否，最大的关键点不在于初期的部署，更重要的是后期的运营运维，需要有良好的运营运维的支持。基于这样的一些需求的分析，我们设计了新一代的基于SaaS的私有云架构，从这个架构来看，最大的差异化是我们的云管平台是一个多租户的模型，大家肯定会说，OpenStack本身就是一个多租户的，在一个平台可以管理多的资源池。我们的差异在什么地方，主要的区别在于我们都非常熟悉OpenStack里，对每个客户，在这一个云管平台上可以管理多个不同的账号体系，客户A下面可能有他的子账号，他这个企业里面所有账号都在这个资源池里面可见，客户B是在他的AB这两个资源池可见，但是客户A的账号没办法访问客户B的资源，这就说明我们云管本身是一个SaaS平台，可以支撑多个企业同时注册上来。云管这里面包括的功能主要包括资源使用的自服务门户、监控和运维、应用商店、计量和计费，通过统一云管理平台功能，把每个资源池部署在分别独立的本地的数据中心。从部署模式上来看，这两种模式我们都统一管理起来，实现集中的运维。同时我们这个也可以支持在数据中心把云管平台部署在数据中心和计算资源池融合在一起，很多中小企业客户可能是受网络连接的条件限制，所以他需要把云管部署在数据中心里。
现在看一下产品特点，产品总结起来主要有三个方面的特点，第一个是简单，第二个是融合，第三个是企业级特性。简单主要是考虑因为OpenStack本身是非常复杂的，在落地的时候需要很多运维人员掌握OpenStack相关的技能，在落地时会碰到很多困难，所以我们会把产品设计得更加简单，更容易让我们的合作伙伴来把OpenStack落地。第二个是融合，企业客户可能会有多个资源池，他可能有以前的已经建设好的项目需要统一管理，我们需要有融合这个特点。第三个是企业级特性。首先看我们的部署方式，大家都了解OpenStack的部署是非常复杂的，涉及到的背景也非常多，节点角色非常复杂。看一下我们的部署是怎样实现的。我们会把我们预装的镜像支持工厂预安装的方式，可以在服务器出厂的时候就把我们需要安装的软件在工厂预装好，这样可以尽量减少在客户现场部署需要花费的时间。可以看到有一些宣传提到说可以实现开箱即用，实际上在我们看来这是很难实现的，因为OpenStack里面涉及到存储网、租户网、管理网这些网络配置，包括VLAN设置，这些设置需要在客户的现场环境才能确认，如果你预先设计好这些配置，很可能到了现场和客户现有的网络环境是冲突的，这非常麻烦的。所以我们把基本的安装包在服务器上安装好，在客户现场通过插一个U盘，来实现最小化的配置，向云管注册，然后下发配置，把整个部署起来，使用U盘的原因有两个方面，第一个是硬件不是我们能控制的，我们可以把这个镜像放在U盘里，用这个U盘来把镜像拷贝到服务器上。第二，因为我们安装的服务器本身是没有图形适配系统的，这个操作起来可能会不太友好，我们在U盘里预装一个图形适配系统。整个部署可以在10分钟之内完成，前期的操作系统和软件包都已经安装好，后期就是部署OpenStack这些支撑服务，可以做到极简部署。部署方式支持U盘方式，也支持PXE方式，在一些小规模项目里可以使用多U盘部署，即使手工的方式部署效率也非常高。但是在大规模项目里，通过网络的方式把镜像推送到服务器上。这个是配置界面，我们的配置会把OpenStack相关其他的能够预设的参数都预设好，只有把和客户环境相关的这些暴露出来，让用户去选择，比如你的网络、外网、集群网、存储网、租户网，这些网络的CIDR和他的VLAN地址这些，让用户选择输入，存储的副本数由用户选择输入。对部署实施人员的要求，你只需要懂得Linux上面的网络IP地址的含义，能做网络规划就可以完成这个部署实施，这样可以最大程度降低对实施人员的要求。
从运维来看，我们实现了以下几个工作，第一个是容器化OpenStack服务，通过容器化解决OpenStack运维当中的一些问题。我们知道传统的OpenStack都会涉及到先部署三个管理节点，然后再部署计算节点这样一个方案，我们按照这个方案的部署会有一些问题。第一个，可能有些客户最开始上云的时候他的规模没那么大，比如他一共是十个节点甚至更少，他用于三个节点做管理节点、做控制节点，他觉得他的资源有浪费。另外一点，当我们把这三个节点部署成管理节点之后，当你后期业务增长，OpenStack服务没办法支撑整个集群的压力的时候，这个时候再扩容也是比较麻烦的操作。还有OpenStack，默认的参数和CPU是相关的，这样就会造成实际上你的云的压力没有那么大的情况下，你启动的nova、cinder这些进程非常多，浪费了非常多的内存和CPU的资源。我们会降低道路非常小的数量，让它满足当前规模的压力要求。接下来集中配置管理，我们都了解OpenStack有非常多的配置参数，特别是有一些参数是在计算节点生效，如果要修改在计算节点的参数，把所有计算节点的都修改一遍，需要集中配置的管理工具。把固定的配置、代码固定下来，这样不管在什么环境下都可以是一致性的表现，把这些可变的让用户配置的配置放在外边。我们在做运维在做配置变更的时候就非常容易去更新OpenStack的配置参数。第三个是升级，大家知道升级是非常麻烦的事情，我们做了容器化之后可以解决几个问题。第一个，我们把代码、配置能够固化，这样我们可以保证我们研发同事在他们研发环境测试好的代码就可以在测试环境、生产环境有一个一致性的表现，不会再出现因为它依赖的库在操作系统上有不一致的现象，会在我们自己测试是可以正常通过，但到客户现场不能正常通过的现象。另外Docker本身支撑分层的镜像管理，在升级的时候可以只做增量的升级，修改了哪部分服务、哪部分代码、哪部分配置，这是它升级的优势。当然有一些客户他可能没有网络连接，没办法连接到，只能通过线下的全量的去升级。还有服务高可用，上一位嘉宾介绍了高可用的方案，因为我们是用容器来运行OpenStack服务，之前的这套高可用的技术已经不再适用。我们会基于它去检查OpenStack服务的api，来看它是不是能正常工作，如果不能正常工作，会有服务保活机制，如果重启失败，服务会漂移。我们这个OpenStack服务可以在任意一个节点上运行，因为它的代码、它的依赖已经是在容器里，或者它的配置是在中心这个地方，它不是耦合在这个物理服务器上的。所以它可以更好的保证高可用性。可以看这张图，整个控制底层会有一个集中的控制平面，由它去调度OpenStack的这些服务，会对这些服务做健康检查，如果发生了故障之后会有事件流的处理，去判断这个事件需要抛到云管平台去通知客户，还是说交给我们内部运维机器人来处理，这个运维机器人也是我们为了提高运维自动化来设置的一个组件，它首先是要通过分布式控制平面去做一个选举，如果一个节点挂掉之后，他会在另外一个节点拿到这个投票，成为leader。他会承担几部分工作，第一，故障的自动处理、自愈，另外是配置变更，我们通常在做配置管理的时候会用到一些配置自动化的技术，比如像Ansible。运维方面我们还做了一些其他的工作，包括生命周期的管理，包括监控告警，监控告警这部分给大家介绍的是我们使用的监控方案是和社区使用的是不同的，第一个我们会使用串口的方式来使用数据，而不是使用网络，这样有两个好处，第一是在客户的虚拟机网卡流量上，监控不会产生额外的负担，另外不会对网络拓扑产生依赖。因为它的数据是从串口方式走到计算节点，然后统一交到监控后台来做数据存储和展示。如果说你走网络的方式，需要所有的被监控的虚拟机都能够连到监控服务上。在日志分析上我们底层集成了集群，针对OpenStack做分析过滤，同时我们设置了日志收集的，由于一些异常情况，当集群解体的时候，利用集群软件去收集日志的时候，我们需要有每个节点的故障排除工具。还利用分布式控制平面，有一个定时任务，自动备份整个集群的原数据包括所有项目的数据库的配置。最后是Bob这样一个设计，当我们预置好的配置，对用户来说是完全透明的，在界面上执行添加节点、删除节点就可以了。
使用方面，第一个，镜像上传，很多场景下我们是通过浏览器上传镜像，但是有一些网络条件比较差的情况下，浏览器上传镜像浏览器会经常卡死，我们做了一个后台上传镜像，我们可以做到你把一个镜像拷到任何一台服务器指定的目录下，它会自动检测这个镜像的操作系统版本，不需要用户知道OpenStack命令，也不需要做其他的人为干预。另外我们做了一个镜像制作，因为在国内客户里使用云的时候，很多还是希望自己能够通过ISO去制作镜像，而不是原生的或者从官网上下载在云上的镜像。用户需要有这样一个工具来支撑，所以我们在平台上也开发了这样一个特性，用户可以在平台上选择制作镜像，先把ISO上传上去，按照他想做的定制去安装操作系统，装好操作系统、装好虚拟机之后再转化成一个镜像。另外我们做了一键VPC，OpenStack里面网络环境非常复杂，一个对OpenStack不太熟悉的客户在使用这个平台的时候，可能一下子不知道该怎么下手，可能涉及到创建交换机，创建子网，要创建路由器，要做绑定，设置网关，等等操作，非常复杂，我们会把这些参数提取出来，让用户一键完成这些操作。另外我们也做了自动化快照，能让客户对虚拟机实现周期性的自动保护他业务的状态，保证他业务的连续性，一旦他有操作故障、误操作，可以随时恢复虚拟机的状态。还有快照回滚，这个功能熟悉虚拟化的肯定了解在VMware上有这种功能，但是在OpenStack或者在云上对这个使用习惯是不太一样，因为云更强调的是我们要做快照，要持续保护你业务的状态，但是当发生故障的时候，应该是可以删除重建的，可以从外部去恢复这个镜像，和原来是一样的。可是我们的客户在使用的时候会有一些问题，第一个他的IP和业务是耦合在一起的，他需要恢复成原来的IP地址，第二他在使用的时候，新建一个虚拟机，要审批操作，比如在原来的主机上做恢复更方便，另外从操作来说也是更方便。
第二个特点是融合，首先是部署方面我们是一个融合。我们做了一个管理的融合，我们要保证用户对管理资源，消耗最小的资源，同时保证它的弹性。我们设计出来一个所谓的全对称的架构，我们看到每个节点上跑的，从最底层是分布式控制，由Cluster Agent组成，会由Ceph OVS组成网络，最上层是用户使用的计算业务的虚拟机。我们要实现这样的一个大的融合，需要做的事情是要能保证用户虚拟机的业务使用资源和平的资源能隔离开，要做统一的资源调度，我们底层的调度框架要知道OpenStack在这上面资源的使用，同时OpenStack本身Nova要对应资源的预留。这样一个架构就可以实现我们前面提到的，我们在增加节点的时候或者在发生故障的时候，这些服务实际上都是可以灵活的自动的在不同节点之间漂移。发生故障之后，总是可以保证两个实例，而不是像传统的高可用方案，当你一个节点发生故障的时候，你是可以保证你业务的可用性，但是你整体的性能其实是降级的，因为你原来是两个实例提供，现在只有一个实例。
我们也在高可用方面做了很多工作，特别是我们计算节点高可用，我们会在底层，刚才提到分布式控制层面会做一个分布式的，会检测到哪些故障节点，会做迁移，根据不同的故障采取不同的动作。另外在我们的平台上，在权限管理方面提供了非常丰富的，支持四级权限管理。针对私有云的客户也有这种计量计费的需求，需要统计各个部门、各个分支机构在资源上的使用，也有中心建云各个分支机构使用也需要计费，我们平台也支持这种计量，同时支持设置单价，给线下计费提供依据。
我们要有差异化的地方或者希望给大家传递的一个信息，第一个是我们的交付方式，我们实际上实现了一个OpenStack as a Service的交付方式，可以把OpenStack预装到服务器上，可以通过U盘的方式交付。第二是我们产品化的方向是解决企业客户上云的问题，我们希望能够把产品做到简单，能够有融合管理的个性，能够让用户去管理他现有的生产。同时我们提供一些企业级的，比如高可用、权限管理等等。
谢谢大家。