本篇我们从开放的高性能硬件架构、软件系统与硬件平台的分离与解耦、DevOps工具、RESTful API、容器架构、内存数据库Redis、与主流Cloud OS——OpenStack的完全集成这几个方面聊聊星融Asterfusion云网络的开放性。 一、开放的高性能硬件架构 传统网络硬件平台的架构,因受生产者的商业模式、设计理念等限制,通常采用私有的架构,为使用者提供一个网络黑盒,并且与其上层网络操作系统紧密耦合,将使用者牢牢锁定在该平台之上。基于这样的网络架构来设计的IT系统,用户在日常运维、故障定位、备件更换、网络扩容、升级换代等方面都需要高昂的成本🙄。 星融Asterfusion云网络则采用完全不同的理念与架构,来设计其高速网络硬件平台。如图1: 图1,开放的高性能交换硬件平台 星融Asterfusion硬件平台的优势: ✅ 开放的架构 系统采用简洁、开放的架构设计,又基于业界成熟的BMC(Baseboard Management Controller)、COME(Computer-On-Module Express)、第三方的高性能可编程交换芯片等方案,来构建模块化的系统。 ✅ 业界知名商业交换芯片高速交换子系统采用业界知名的交换芯片设计,用户不仅可以享受海量出货芯片的成本红利,还能拥有完全透明开放的架构,不携带任何硬件层面的专利与锁定,与前面提到的“专有芯片+私有硬件”的方案形成了鲜明的对比。 ✅ 可编程交换芯片 星融Asterfusion紧密跟随网络领域最先进的技术发展动向,采用可编程的交换芯片作为交换子系统的核心,使用户的需求在硬件转发层面被快速响应,让云的快速迭代不再受18-24个月的ASIC开发周期的限制。 ✅ 功能丰富的高性能交换系统 星融Asterfusion的云网络不但能够为云中业务提供丰富接口类型(10G/25G/40G/100G)、全线速的转发,而且还能够在硬件网络上为云中业务提供L4SLB(Layer 4 Server Load Balancing,四层服务器负载均衡)、1:1 NAT(1:1 Network Address Translation,一对一网络地址转换)等功能。 💡😎值得一提的是,星融Asterfusion云网络的整体架构设计完全遵循了业界最领先,公司已经广泛部署和使用的Scale-wide架构(按需自由扩展架构),将原本封闭在大型机架式网络设备中的CLOS交换架构开放到网络拓扑设计当中去,帮助用户在只采用盒式网络设备的前提下仍然能够搭建出大规模的扁平化云网络,使用户在享受高性能、按需自由扩展的同时,最大限度地降低云网络的TCO(Total Cost of Ownership,总拥有成本)。 图2,基于Scale-wide架构的大规模Asterfusion云网络 例如,在图2中, 1、位于Leaf层的128台(64对)CX532P,每台的32个100G接口被分成两组,16个向下接入服务器,16个向上接进Spine层,并且通过使用100G-25G的1-to-4 Breakout功能,将所有100G接口拆分成64个下行25G接口和64个上行25G接口,通过上行25G接口分别接入到Spine层的64台CX532P。 2、位于Spine层的64台CX532P,每台的32个100G接口通过使用100G-25G的1-to-4 Breakout功能,将所有100G接口拆分成128个下行25G接口,接入Leaf层的128台(64对)CX532P。 3、数据中心的每台服务器通过双25G链路分别连接到一对Leaf层的CX532P的下行25G接口,组成高可靠的接入层,每台Leaf层的CX532P的64个25上行接口分别上行到64台Spine层的CX532P,这64台Spine层CX532P总共能够接入128台(64对)Leaf层CX532P。 4、这样的Spine-Leaf网络模块,总共能够提供128 x 64 = 8,192个25G接入接口,可以为4,096台服务器提供双25G上行的高可靠(接入层Active-Active热备和负载分担)和高性能(1:1收敛比,全线速)接入方案,整网提供204.8T的交换容量和8,192,000虚拟计算节点的支撑能力,即每服务器50G的上行接入能力和1:1000的虚拟化比。 二、软件系统与硬件平台的分离与解耦 图3,彻底解耦的软件系统与硬件平台 星融Asterfusion在AsterNOS中全面集成了SAI,在硬件平台的设计中也选择了多款支持SAI的可编程交换芯片。 因此,在星融Asterfusion云网络中,软件系统与硬件平台是完全分离解耦的架构。 正如图3所示,AsterNOS不仅能够运行在任何支持SAI接口的硬件平台之上,Asterfusion硬件平台也能够运行所有支持SAI接口的操作系统。 最终将用户从传统网络“软件系统与硬件平台紧密耦合”的黑盒中解放出来。😎 当然,对于中小规模、不具备自行开发能力、不具备软硬系统集成能力的客户,推荐选择星融Asterfusion的“AsterNOS + Asterfusion硬件平台”一体化解决方案,来降低部署的复杂度,加快部署的速度。
网络操作系统中各个控制模块需要多种形式的交互,来交换信息、同步状态、协同工作。 在传统的网络操作系统中(如图4所示),这种模块间的交互往往通过直接建立点到点连接的方式进行,从而在各个模块之间形成了一张全连接的交互网络(Full-mesh)。 这种架构的网络操作系统有着很多弊端😕, ⚫模块之间紧密耦合,架构复杂,其中一个模块出现问题,就会影响系统整体的稳定性; ⚫操作系统内部的各种状态信息分散。 ⚫操作系统自身的备份复杂程度及风险很高。 ⚫传统网络操作系统的架构非常不利于扩展。 图4,软件模块解耦的网络操作系统 图5,AsterNOS系统架构 AsterNOS将标准Linux内核之上的容器环境开放给了第三方应用。 😎也就是说,任何曾经运行于x86虚拟化世界中的运维管理工具都可以直接运行在AsterNOS上。在不带来任何额外开发工作量的前提下,为云网络的自动化运维管理提供与原有方法完全一致的体验,大幅提升云网络运维效率。 举个栗子🌰, 在基于“软件模拟虚拟网络”的云中,为了获取每个租户的虚拟网络的流量统计信息,管理员需要在每一台物理x86服务器上安装自动统计与收集工具,再将所有这些工具的统计结果全部汇聚到Cloud OS;而一张面向公众运营的云中,物理x86服务器的数量是以数千、数万为单位计算的,所以这样一个简单的运维需求在“软件模拟虚拟网络”的云中所带来的复杂度及管理流量的压力可想而知😥。 但是在AsterNOS的云网络中,每一个这样的运维工具只需要运行在每个ToR(Top of Rack,架顶)交换机上即可,而ToR交换机的数量相比物理x86服务器来说,只有其1/50左右。 五、Asterfusion云网络支持DevOps DevOps是一种新型的软件产品交付模型,它将与软件产品生命周期过程中的各个相关部门(例如研发、测试、运营等)以一种空前的方法连接了起来,并且对他们的沟通、协作等提出了更敏捷、更快速、更频繁的要求。 🌰例如,互联网时代的软件产品一般都要求版本以天为单位快速迭代更新,继而测试部门也要按照相同的节奏完成产品质量保证所必须的工作。同样,运营部门也需要快速地更新升级运营环境以保证业务系统的正常运行及良好的用户体验。 对于网络来说,DevOps模型的大规模普及意味着网络也要在如此频繁、快速的迭代过程中具备灵活、敏捷及自动的调整能力。 Asterfusion云网络能够很好地支持在开发、测试、生产环境中广泛部署的NETCONF、Ansible等DevOps工具。 六、Asterfusion云网络通过RESTful API开放所有能力 相较于其他架构,REST因简洁、高效、弹性、开放等特性被越来越多的应用系统所采用,经过十多年的发展,已经成为基于Web应用系统的事实标准。 相应地,如果一个系统提供的API(Application Programming Interface,应用软件编程接口)符合REST架构风格,通过这样的API,这个系统能够与其他REST系统完成软件编程级的对接,这样的API就被称为RESTful API。 在云计算时代,一个系统是否能够提供RESTful API,直接决定其是否开放、是否能被融入到云中。 星融Asterfusion云网络系统正是通过一系列RESTful API将网络的能力全部开放出来,从而将云网络完全融入到云计算软件定义、弹性调度、按需扩展、自动运维的世界中。 |
免责声明:本网站内容由网友自行在页面发布,上传者应自行负责所上传内容涉及的法律责任,本网站对内容真实性、版权等概不负责,亦不承担任何法律责任。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。