你好,游客 登录 注册 发布搜索
背景:
阅读新闻

云计算核心技术架构论坛(一):构建高可用、高扩展、易运维的云架构

[日期:2015-06-11] 来源:CSDN  作者:周建丁 [字体: ]

  在6月4日下午举行的“云计算核心技术架构论坛(一)”中,IBM中国智慧云平台与OpenStack首席架构师杨海明,新浪云计算总负责人、SAE创始人丛磊,百度开放云资深架构师杨毅,青云QingCloud系统工程师杨锦涛、英特尔云计算和大数据解决方案架构师胡潇和七牛云存储首席架构师李道兵等六位讲师从架构解析、平台实践、技术研发、应用实践等不同多方面分享了如何构建一个高可用、高扩展、易于运维的云架构,以支持企业享受云计算服务的需求。

  IBM中国智慧云平台与OpenStack首席架构师杨海明:开放云架构+企业增强

  第一位讲师是IBM中国智慧云平台与OpenStack首席架构师杨海明,他首先表示:构建企业云平台的三种方式中,仅仅使用OpenStack、KVM等多款大型开源软件搭建,可能前期部署上线比较快,后期维护却是一个噩梦;而如果采用传统的商用方案,对业务需求变化的响应又比较慢;因此,比较合理的的方式是中间方案——开放架构加上独特的企业增强实现。

  IBM云计算平台全面支持开放标准,包括OpenStack、Docker、CloudFoundry等。杨海明介绍了IBM努力的五个方向:基于Power及OpenPower构造开放的云、基于Power Linux提供开放及高性能的云平台、致力于OpenStack云之间的开放互通、致力于Container技术的开放性和基于Bluemix构建生态体系。

  

 

  IBM中国智慧云平台与OpenStack首席架构师杨海明

  杨海明表示,POWER架构支持利用GPU和FPGA加速提升云平台及其上层数据库和应用的性能,并且全面支持Ubuntu、Red Hat、SUSE等Linux平台,PowerKVM增强则通过分核技术实现在同一个核心上同时调度多个VM,可以深度挖掘P8多线程性能。OpenStack云之间的开放互通,IBM从三个方向着手:开放、模块化设计,多供应商协作,以及快速创新。IBM通过支持OpenStack基金会官方互操作性测试认证,解决各OpenStack生态系统的可移植性,实现更灵活的资源配置和计费标准。OpenStack的多云管理,不仅整合IBM、HP、Mirantis的OpenStack,还整合了VMware,通过SDC、SDS、SDN及物理资源和虚拟资源的集成管理,将所有的私有环境、MSP以及公有云资源动态组合统一管理,从而走向混合云。

  

 

  基于OpenStack的动态混合云

  在Kilo版本,IBM实现的OpenStack企业环境增强主要包括:

  Bare Metal(Ironic)的增强以及和专业集群管理工具的集成

  文件系统(Manila)以及统一存储系统的集成

  企业Scheduling Service的集成

  企业内部安装部署的增强

  企业级资源管理的增强(Power,Mainframe,VMware)

  杨海明认为,同时支持物理机和VM是Docker,为PowerLinux Cloud创新带来了很好的技术支持:

  类似于虚拟机,但几乎没有性能开销

  具备更高的资源利用率

  更好的性能- 创建一个新的容器所需时间为毫秒级

  可以向管理虚拟机一样管理容器

  杨海明最后强调:云一定是开放的环境,不仅是一层开放,而是每个层面都需要开放。第二,只用开放架构可以实现很好的想法,但是你要推动真实生产环境,因为企业真实生产环境应用一定是与开源要求不相符,你的专业知识其实更重要。

  新浪云计算总负责人、SAE创始人丛磊:云计算核心运维体系

  新浪云计算总负责人、SAE创始人丛磊认为,运维是云计算的核心,但中国企业云环境下运维一个平台非常困难,原因如下:

  ⽤用户不可预知性

  业务不可预知性

  服务多样性

  资源共享性

  早期夸⼤大导致⽤用户理解偏差

  丛磊表示,运维的职责在于对服务可靠(SLA)、业务质量(Performance)、成本优化(Cost)的保证,他介绍了SAE在这三个层面的实践经验。

  

 

  新浪云计算总负责人、SAE创始人丛磊

  保证服务的SLA有两个要点:做到整个平台资源(包含软件、硬件和人)的可管理和可监控。人的管理方面,要建立好值班制度、奖惩制度、权限分配和跟踪以及运维培训。丛磊认为,云计算平台一切的故障来源于“变更”,包括硬件的变更(机器&设备上线、下线、报修、更新、搬迁)和软件的变更管理(服务上线、下线、配置变更、扩容)。所有硬件的上线、下线包括保修都是严格按照路径走,机器下线时先断网非常重要,先保持外界孤岛隔离,如果没有问题再执行机器下线流程。软件变更,应该有非常严谨的流程判断是否正确,不是说刷几个页面和APP,应该看整个平台的状态,还要确保升级在十秒钟可以回滚,所有领导都要签字。此外,还要建立故障管理体系,包括故障处理、故障升级制度、故障总结等。

  资源监控分三层:平台、服务和业务层。平台监控包括平台里的系统、网络、内存、登陆权限等。SAE监控页面几百个,以Zabbix为主,通过Zabbix对平台硬件资源进行监控。所有业务200、500比例都会做峰值变化的报警。还要对所有服务的API监控,所有服务都是API,有一套机制定时获取所有服务的API,并且判断它是成功还是失败的。对服务做状态监控,包括PID、日志健康、GC波动等。不仅要看PID在不在,而是要知道复制服务日志是否刷新,同时要判断进程里是不是有阻塞,有没有卡的情况。而且要看整个服务的操作数量和时长,服务不会突然挂了。

  

 

  通过Zabbix对平台硬件资源进行监控

  丛磊特别指出监控的一个误区:监控API、日志、系统参数,但没有从业务层监控。他表示,要从实际用户角度做监控,做好用户监控、请求路径追踪、全生命周期监控。SAE 整个业务从用户注册、登陆、认证审核通过,到用户创建第一个APP,到APP的销毁,再到最后的退出,都有一个定期模拟。有一个机器人把定期流程走一遍,一旦有问题就会报警。

  报警注意的几个方面,包括重点解决“报不出来”和“报警过滥”,区分SLA和故障报警,分等级(邮件=>私信=>短信=>电话),以及建⽴立报警逻辑链(SAE正在努力的一个方面)。

  服务质量方面,关注SLA排行榜、服务质量分析、定期极端测试和工单激励。成本优化目的在于降低单位服务的成本,包括通过虚拟化、定制机型、业务混跑等方式实现,并让每个开发⼈人员了解业务的成本和效率,避免资源滥用。

  最后,丛磊分享了小团队做大运维的四个要点:

  原则:敢于说不

  内外一体,不对任何人做特殊支持

  对用户负责,不对老板负责

  不做分工,全栈式运维

  百度开放云资深架构师杨毅:百度开放云虚拟网络实践

  百度开放云资深架构师杨毅分享了百度开放云服务基础组件之一——虚拟网络部分的技术实践。杨毅表示,计算和存储的service化基本都有现成的标准和方案,但网络service化并不成熟,现在的NFV和SDN,都只能解决云计算网络里的部分问题(例如Virtual Private Cloud对网络提出更高的要求),不能实现完完全全的Network as a service。

  杨毅会从技术选型、工程实践等方面详细介绍了在实现百度开放云的网络服务过程中所做的一些选择和思考。

  

 

  百度开放云资深架构师杨毅

  技术选型分为控制平面和数据平面的技术。

  控制平面:

  Neutron:业界通用的API,可插拔的plugin架构设计

  SDN & OpenFlow:集中控制,软件定义,这个作为补充来使得网络更为灵活健壮

  数据平面:

  选择了社区目前最成熟的KVM和OpenvSwitch方案来实现单机网络虚拟化及虚拟接入功能,没有选择物理交换机来做接入的原因主要是考虑到软件开发更为可控,当然在feature开发成熟后会充分利用硬件offload技术来提升性能。

  选择了Vxlan来实现overlay的大二层技术,这样的一个好处是不需要改变现有物理网络结构,并且提供良好的租户隔离和可扩展性。Vxlan对比nvgre/stt:L2-in-UDP,更好的利用多路径hash。

  最后选用了DPDK来实现一些x86下的高性能网络设备,这个一方面是团队之前有一些经验积累,另一方面讲也几乎是业界标配。

  

 

  百度开放云网络服务控制平面架构图

  工程实践,杨毅会从性能优化、稳定性和可扩展性三方面来展开描述。

  性能优化的基本方法论:建立基线,包括测试的case和衡量的指标;这是很关键的一个环节;后续就是不停的迭代,跑基线测试,手机数据,分析结果,应用优化手段,再测试看指标。性能优化永无止境,根据实际需求来确定目标。

  具体到虚拟网络里,从整个网络路径来看:

  在VM也就是guest这一层面,对virtio/vhost进行了优化,采用zero copy/polling/多核多队列来优化虚拟网卡的性能;

  在Overlay,也就是物理Host这一层面,考虑到Vxlan的特性,打开了网卡的UDP多队列支持,考虑到overlay会使得数据包超过以太网的MTU,在分片特别是vxlan协议分片的offload支持方面做了不少工作;

  采用dpdk实现一些高性能的网络Middle Box组件,例如vrouter/vswitch,在userspace进行网络处理的方式,比在kernel实现性能要高出不少,同时也更灵活,开发更为方面,不用考虑与标准协议栈路径兼容。

  在稳定性方面,百度一般用SLA这个指标来衡量服务的可用性。杨毅认为,SLA是云服务最大挑战。SLA的计算方法:可用性 = (MTBF / (MTBF + MTTR)) X 100,其中MTBF代表了服务在两次中断之间能够正常提供服务的平均时间;而MTTR代表了服务中断后的平均恢复时间。

  从这个公式来看,一方面要减少失败次数,另一方面要降低失败后的恢复时间。常见的方案包括通过多组硬件来实现冗余,软件去除SPF单点问题等。

  百度开放云的实际工程实践中,硬件上,物理机上联采用双网卡bonding + switch 2虚1技术来保证高可用,在软件方案上,没有采取社区提供的L3-HA/DVR等方案,原因是经过评估,发现社区的这些方案首先都比较复杂,引入很多新的组件,增加了不少的运维难度;其次在规模较大,例如vRouter数目增多的情况下,会有不少的bug;百度最终做的稳定性改进包括:

  实现热升级机制来避免正常升级时的服务中断,使得快速迭代成为可能;

  通过引入OpenFlow和SDN Controller,通过推拉结合的方式,在计算节点由于流表没有正确配置导致无法正确转发数据包的时候,找Controller去拉一次流表;来解决MQ通信不可靠的问题;

  使用ecmp的方式,实现了bvrouter集群,彻底解决vRouter的单点问题;并且也解决了vRouter的收敛比问题

  实际部署了OpenStack后,百度就发现其很难扩展:

  首先API Server自身无状态,可以简单的靠增加API Server来提升可扩展性,但实际上多个API Server之间的锁/并行处理有很多bug

  其次元数据存储在DB;DB自身的读写可扩展性也成问题

  MQ也可能成为瓶颈,在节点规模超过500台的时候问题凸显

  社区提供的Cell配置比较复杂

  百度在可扩展性方面,有这些设计原则:

  控制平面:尽量本地化处理;简化状态。

  数据平面:去除掉可能成为瓶颈的路径,例如vRouter,DHCP;消除收敛比;要单播不要广播。

  杨毅最后分享了一个心得:不用硬磕单集群的可扩展性,公有云的特性,决定了可以按user做partition。

  青云QingCloud系统工程师杨锦涛:青云QingCloud存储实践

  青云QingCloud系统工程师杨锦涛介绍了QingCloud在存储系统的设计思路,最终在架构呈现出的形态,以及在最终产品上做的产品,包括块存储、共享存储和对象存储。

  

 

  青云QingCloud系统工程师杨锦涛

  青云存储在物理设备层面做了区分,采用了SSD、SAS、SATA,向用户提供高性能的块存储,以及大容量块存储,以及超高性能块存储。共享存储是将提供的块设备以传统企业存储方式暴露出来,现在的做法是以Storage的方式暴露给用户。在块设备基础上还做了对象,对象存储可以直接跑在物理资源上,也可以跑在虚拟机上。块存储、共享存储、对象存储三者实现融合,也就是说,块存储可以是DAS、共享存储或者对象存储。

  

 

  青云存储系统架构图

  杨锦涛认为,当前开源分布式存储系统非常有名三个项目GlusterFS、Ceph和Sheepdog,以分布式方式提供块存储,但仍然没有解决传统存储方案的集中网络带宽瓶颈,但在公有云上,所有计算资源都要通过网络通道,很难满足带宽需求,即便满足,调配每个计算资源也非常麻烦。青云块存储的设计,除了Software Defined,在性能和容量方面也都要满足,另外还要兼容传统企业运营方案。最终的方案,在本身设计上做融合,包括访问路径的融合,整个存储系统就近访问,但存储系统在逻辑上仍然是分布式系统。

  共享存储的设计,是为了满足传统企业运营需求,目前提供Storage方式,下一步要做NAS,像SAMBA以及CIFS。

  对象存储的设计, 由于不知道用户存什么样的数据,也不知道数据的大,所以要解决一个通用问题。青云第一个做法是多区域路线,另外解决类型不限、数目不限、容量最大。结构对象存储的总体架构,第一级有Load区域,根据用户请求进行重立项,或者是进行解析。上面GATEWAT方面都是可以任意进行扩展。区域里面存储的架构,最上面LB和LI这层可以进行任意水平扩展,下层为了解决索引的问题,做了分布式索引集群,可以看到做了一级和二级索引。为了防止大量的小文件之下索引数据甚至比实际存储数据还要大,需要做合并,前提是对同一个用户存储空间里的数据进行存储,不会跨用户也不会跨存储空间进行合并。

  

 

  青云对象存储架构

  杨锦涛最后介绍了青云存储的Roadmap,包括如下八个方面:

  CDN

  图形图像处理,音视频处理

  QingCloud各类存储服务的融合

  与QingCloud其他服务的集成

  与客户存储环境的结合

  客户端

  更廉价的存储硬件

  与开源项目的集成

  总体而言,青云存储的设计思路就是:统一硬件架构;折衷的分布式存储系统;多维产品设计。

  英特尔云计算和大数据解决方案架构师胡潇:英特尔视频云

  英特尔云计算和大数据解决方案架构师胡潇介绍了英特尔在视频互联网应用以及视频云计算的技术,帮助大家了解用今天已有的技术更好实现与视频相关的云计算,涉及在线视频、云化图形图像技术和视觉内容分析等。

  

 

  英特尔云计算和大数据解决方案架构师胡潇

  通过GPU虚拟化技术,英特尔从性能、功能和共享三个层面支持云化图形图像,有三个典型思路。

  API Forwarding:把API转到Backned,可以把Graphics发过来的API进行处理,然后再返回。最大的限制是功能非常受限,而且兼容性是很大的麻烦,因为你需要兼容各种各样的API。

  Graphics Driver:虚拟机初始化配制时就要配制好哪一个虚拟机可以独占CPU,可支持在云计算中的各个客户的档次和等级,非VIP的虚拟机共享GPU,VIP客户可以独占GPU。

  全功能的GPU虚拟化:有两个虚拟机上面的图形驱动,控制流和控制IO,转发到Hypervisor层,可以轮寻小块转发到CPU,让CPU进行处理,性能更好,不影响VM上不同的协议。

  

 

  英特尔媒体云架构

  可以利用现有公有云或者是私有云软件架构结合英特尔在Graphics虚拟化,以OpenStack为例,可以在Nova节点之上用Xen Hypervisor或者KVM Hypervisor。

  视觉内容分析方面,英特尔做了IDLF深度学习框架,以及高性能编解码辅助大规模复杂视频分析。IDLF项目可以帮助你搭建网络,支持使用各种不同计算的框架、架构,包括CPU指令,包括GPU指令,同时基于平台级做了代码优化。视觉分析会利用到GPU能力,如果要解决图象和视频实时性分析要求,要搭建流式处理框架做实时性视频分析,不同阶段仍然要用Graphics 编解码的能力,使得流式分析可以承载视频业务。

  七牛云存储首席架构师李道兵:云存储助力视频监控产业发展

  七牛云存储首席架构师李道兵分享云存储如何解决短视频行业的痛点。当前短视频产品疯狂增长,主要痛点在于数据上传、数据存储、数据处理集群、数据分发等方面,但随着SSD的广泛应用,数据库的处理能力已经提升了2-3个数量级,架构瓶颈反而容易出在数据存储层面。

  

 

  七牛云存储首席架构师李道兵

  李道兵表示,云存储的发展已经足够成熟,围绕数据的大部分需求都能够解决。很多云存储都提供音视频处理服务,而且由于云存储本身处理容量大,可以应对峰值冲击。例如云存储可以设计过审查用的转码: 七牛做到双倍速,分辨率150x150, 去掉声音,降低码率,10s的视频只需40KB左右;可以智能调度优化CDN,避免CDN故障时服务不可用;可以用多域名甚至IP下载来避免域名劫持。

  他还表示,未来的世界,数据越来越重要,例如收集网页变成搜索功能来满足用户,收集用户的搜索和访问行为变成广告投放引擎来满足客户。

收藏 推荐 打印 | 录入:Cstor | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款