网站开发对显卡的要求,游戏网站怎么建设,开公司要多少钱才能注册,什么是网站模板摘要#xff1a; 摘要#xff1a;2017年12月20日在北京云栖大会上#xff0c;阿里云高级技术专家梵叶在计算与网络分论坛上做了主题分享《双十一丝般顺滑体验背后#xff1a;阿里云洛神网络虚拟化系统揭秘》。为大家介绍了洛神系统的发展过程#xff0c;系统架构#xff…摘要 摘要2017年12月20日在北京云栖大会上阿里云高级技术专家梵叶在计算与网络分论坛上做了主题分享《双十一丝般顺滑体验背后阿里云洛神网络虚拟化系统揭秘》。为大家介绍了洛神系统的发展过程系统架构高可用性设计和虚拟交换机等重要组件。
摘要2017年12月20日在北京云栖大会上阿里云高级技术专家梵叶在计算与网络分论坛上做了主题分享《双十一丝般顺滑体验背后阿里云洛神网络虚拟化系统揭秘》。为大家介绍了洛神系统的发展过程系统架构高可用性设计和虚拟交换机等重要组件。首次向外界全面揭开洛神网络虚拟化系统的神秘面纱。本文是这次讲演的文字整理。
客观的说今年双11的体验还是不错的。我自己作为例子之前几年的双11的0点时候我自己的购物车的一波提交一般瞬间进入了排队状态但今年我的体验明显不同一波就成功了。双11的底层技术实际上是建立在网络产品的基础之上的接下来我要给大家分享的主题就是双11的这一切我们是如何做到的。我会把阿里巴巴双11上云叫做大象在云上跳舞。为啥说是大象呢因为双11的量是在是太大了想要完美支持双11真的不是容易的事情尤其是双11零点的峰值。大家都知道AWS的ELB的预热面对这样的峰值挑战一定是无力的。这里有几个数字分享给大家。首先是关于两个结果的一个是100%的流量比例都是在云上的一个是32.5万笔每秒的交易峰值。这个交易峰值是什么概念呢大家知道么2009年的时候第一次双11交易峰值是200笔每秒在这个大量的交易下云网络稳如泰山。另外三个关于极限性能的值一个是单一网络的ECS数量这个是10w台。之前我刚好到深圳拜访一个客户这个客户是自己在家里用Openstack搭云网络玩的这个客户刚好给我吐槽说自己搞了100个计算结点结果控制器就跪了。另外一个是160G的负载均衡实例的带宽我相信这个值已经超过了绝大多数的硬件负载均衡器。最后一个是10分钟扩容上千台ECS。这个举个例子这个弹性的扩容能力在鹿晗曝光恋情的当天发挥了重要的作用。不是所有的云计算公司都有机会承受双11的洗礼可能除了阿里云以外的任何一个云计算厂商都没有经历过这样的体验。但尽管阿里巴巴是一个非常极致和奇葩的客户但除了阿里巴巴之外阿里云上面还有数以百万计的客户满足一个客户的需求服务一个客户也许总是容易的可以为这个客户完全定制系统但同时服务百万级的客户则绝对不是一件容易的事情。首先云上客户最关心的一定是可用性谁也不想上了云以后服务一天到晚的宕机所以可用性是云上客户的命根子。除了可用性之外易用性也是一个非常重要的特点。之前用户想要拉根专线组件一张网络要考虑机房供电机位交换机路由器网络架构机房实施等等各种事项但在云上组建网络用户需要的是只需要点击一下网络就会按照用户需要的样子创建起来但是如果要用户点击无数下那也许用户就要爆粗口了。搞定了可用性易用性用户这个时候关心的就是弹性和性能这两个和用户体验息息相关也是也是用户降低成本的大杀器。这里双11就是一个很好的例子当用户需要资源的时候资源准备的时间用户希望是0当用户不需要资源的时候资源销毁的时候用户也希望是0。至于性能关系到用户希望用最少的钱达到最高的效果这个也是非常关键的。最后一个就是智能这个怎么理解呢举个例子刚才我们提到的用户需要资源和销毁资源的过程用户本质上是这些动作希望自动完成的当用户线上出现问题的时候用户希望系统本身自动处理掉。阿里云网络产品是如何满足用户的呢从表面来看我们实际上就是靠一套基于API的SDN调度系统来创建和删除资源来保证的。而这些产品的背后就是洛神系统。洛神系统来源于中国的古典神话我们希望我们的网络产品和河运的槽道一样能够通畅的连接资源。洛神也不是一天建成的。第一代洛神的网络是出现在2011年这个时候用户感知到网络的方式是通过给定的公网和私网用户无法自己定义网络在这个架构下面网络实际上是不存在虚拟化的都是物理网络的地址直通到VM里面搞定的网络和网络之间也不存在物理的隔离所有的地址都是一个地址平面里面因此这个时候网络的隔离的ACL等功能都是在物理交换机上上线的这个阶段我们称为洛神的经典网络时期这个阶段网络基本上没有弹性。第二代洛神的网络出现在2014年这个时候用户可以自定义自己的网络了用户的拓扑地址都完全可以自己定义这个阶段我们叫做洛神的vpc阶段在这个阶段里面由于用户有了一张网络那么一定出现了这张网络如何联通internet联通线下IDC和联通其他网络的问题。这样这个阶段里面洛神的产品设计得到了极大的丰富各种不同的产品都出现了。第三代洛神出现在2016年其实第三代洛神是关于智能调度和用户体验的演进。当用户的网络越来越庞大的时候用户一定需要一个更好的方式让他云上的资源和云下的资源能够直接联通。当用户的资源原来越多的时候用户也一定需要一个更好的方式来管理这些资源比如带宽流量等等。当用户在全球部署服务的时候用户一定希望来自全球的访问具备智能的调度和就近的接入。当用户越来越依赖于云上那么用户一定希望云上的感受不是仅仅是业务的使用而是不断提升的可视化可运维性和不断的附加值的产生。这个就是第三代洛神智能洛神。好的接下来我们来看下现在的洛神架构是如何支撑这些丰富的特性的。和传统的SDN的架构一样洛神的系统架构也做了控制和转发的分离。数据面位于左下角在洛神的数据面里面包含了常见的计算节点上面的虚拟交换机这个是数据包在计算结点上面的第一道关卡。除此之外的数据面的重要的角色是网关网关在洛神中有两个主要功能一个是承载常见的网络功能虚拟化单元也就是我们常说的NFV。另外一个连接两张不同平面的网络例如连接公网和线下的IDC。数据面相当于是洛神系统里面数据包流动的载体那么控制数据包流动的就是控制平台。洛神的控制平台同样包含几个部分一个是对于设备的管理这里包含了对主要的数据面组件虚拟交换机和网关的管理负责了配置从控制器到设备的下发。另外一个重要的组件是虚拟网络管理负责了vpc本身的地址分配vpc内的路由配置等等功能。除此之外了另外两个关键的组件是本地路由控制器和全局路由控制器。当洛神不再是一个数据中心内部的网络而是变成了一张跨机房甚至跨地域的全球网络的时候这两个控制器就起到了关键的作用一个负责数据中心范围内的网络互连和路由计算一个负责全球范围内的网络互连和路由计算。洛神除了数据面和控制面之外还有一个主要的组成部分就是运营平面。虚拟网络的数据面和控制面在源源不断的产生数据包括各种运行时的状态异常的报警日志有效的处理和消费这些数据是整体系统稳定的基础。因此运营平面的一个非常重要的功能。另外一个点是网络产品的运营数据的处理这一部分功能也是在运营平台支撑的。整体来看数据平台控制平台和运营平台组成了洛神系统。当然洛神系统也不仅仅只是支撑了阿里云的网络产品阿里云云产品的底层网络都是由洛神系统来提供支撑。大家可能比较清楚的是阿里云整体的虚拟化协议栈飞天系统
洛神就是其中的虚拟网络组件。接下来我来详细给大家分享下洛神系统的主要的关键设计。我们认为对于公共云服务的底层技术稳定性和可用性是优先级最高的因此我先来介绍下洛神系统在可用性方面的设计。当阿里云的某一个数据中心云机房开始部署的时候洛神系统作为最底层的系统在物理设施部署完成之后会第一个进行部署。这个时候大家看到这个机房里面有计算集群网关和控制平台。计算集群上面有我们的虚拟交换机组件。在只有一个云机房的情况下我们是没有办法做到跨机房的容灾的。但是对于数据面和控制面的关键结点都是集群部署的单台服务结点的问题不会对用户产生任何的影响同时vm的宿主机当出现宕机等严重问题的时候可以在机房范围内进行迁移迁移本身也不会对vm的网络属性和连通性产生任何的影响。当第二个云机房第三个云机房建设起来的时候每个云机房里面都会部署集群的网关和控制器结点而且随着机房的增多会自动在云机房里面形成环形的备份关系。当一个新的机房建设起来洛神系统部署之后会自动加入到这个备份链里面。这样当某一个机房的关键结点由于异常出现问题的时候都可以自动在秒级切换到备份机房由备份机房的洛神系统来提供服务。这个就尽可能保证了首先单台设备的故障不会引发影响而某个机房的所有结点发生问题也可以在很快的时间内恢复用户的业务。洛神系统可用性的另外一个重要的设计是在于运营平面而运营平面本身也是洛神系统智能和数据化的关键设计。大家如果把洛神系统看成一个整体的交换机那么从特性上来看洛神系统是一个支持流跟踪的交换机具有各种丰富的策略。洛神系统的下面是物理网络的设备和交换机通过洛神系统的流标记的能力和基于policy的策略可以同时在物理网络和虚拟网络里面具备流的染色特定报文的镜像采样trace等的能力流量采集的数据等等这些动作产生的日志都会通过SLS采集到jstorm做实时计算如果流量有异常会产生报警和日志给到管理员部分报警可以触发故障的自动处理和恢复。还有一部分数据也会离线同步到ODPS进行更丰富的计算进而产生数据报表和用户画像给到用户也可以给到用户一张炫酷的大屏。这个本质上就是数据化的能力。介绍完了可用性的关键设计接下来我们看下数据面的虚拟交换机。做过虚拟交换机的同学都知道虚拟交换机在云网络里面是分布最为广泛的每台宿主机上面都有一个虚拟交换机虚拟交换机是vm进出网络的第一道门。在洛神系统里面虚拟交换机因为其分布式的角色承担了大部分的复杂业务逻辑。网关作为多租户的设备复杂业务逻辑的风险一定是更大的所以这个是虚拟交换机的第一个关键设计。洛神的虚拟交换机也是和普通的交换机一样实现了快慢速的分离这种设计会极大的提升性能。另外一个设计是业务逻辑的抽象在洛神虚拟交换机里面抽象了常见的网络的处理逻辑通过简单的使用policy的匹配-action的触发可以配置出各种复杂的逻辑。这个意味着很多复杂的功能实现最终是不需要修改代码的基于policy修改配置即可。在虚拟交换机的业务逻辑下面是一个vswtich的baseOS层有了这个层面一个是可以适配不同的虚拟化技术甚至物理机所以大家看到像KVMXEN容器物理机等等都是靠一套vswtich来支撑的。另外一个是适配不同的底层平台X86,ARM,MIPS都可以运行。这个使得对于版本的管理是最为高效的而对vswitch的规模来说版本管理真的是要命的。看完了vswitch我们来看下整体的数据面。洛神系统支撑的网络产品今年发布了好几个性能的值包括ECS性能等都还是满高的很多友商也紧跟着发布了类型的性能。现在来看洛神系统的数据面其实最简单的比喻就是洛神系统的数据面本身就是一台巨大的交换机。大家都知道交换机的转发芯片对数据包的处理都是pipeline的硬件处理永远不会停下来那洛神的数据面也是如此。从一个数据包进入洛神系统开始到出去洛神系统的整个过程经历了洛神系统里面的各个组件都是不会被打断的这样只处理一件事情的数据面一定是高效的。还有洛神系统的网络永远不会因为维护而中断这意味着洛神里面的所有组件都支持热升级。热升级对用户只有100-500ms的流量中断基本不感知。另外洛神系统里面的关键组件vswitch大家都知道这个组件的变更由于规模问题是非常棘手的。但洛神的vswtich已经建立了完整的自动发布机制包括了CI在里面所以整体的效率提升是非常显著的。回到之前的管理10w台物理机的问题上其实洛神解决这个问题的方案也不复杂。单个网络里面放10W台虚拟机最大的问题是虚拟机的位置表的规模的问题。很多的SDN解决方案都是将配置直接下发到vswitch的这种解决方案当vm迁移或者新建销毁的时候带来的配置的变化的量是巨大的。为了解决这个问题我们先是设计了一个自学习的协议用于流量产生的时候来触发对vm位置表的自学习。同时维护一张带超时的位置表。之后创建一个高速的cache用于快速的响应学习的请求。做了这些事情之后我们发现现在达到10w的vm的数量的压力其实也不是太大。点击查看原文
