技术杂谈-再谈软硬SDN(2)

不好意思,本文有点长,需要阅读10-15分钟。

上一篇文章 得到了很多朋友的反馈, 软硬SDN各自有各自的优势和特点 ,对于之前的文字,有两个反馈。
第一个是文字上的错误,在我的文章里,提到了“据我所知,国内的AWS,Azure和GCP,国内的BAT,软件SDN的方案还是居多”,此处有一个笔误,这里的国内应该改成国外,还有朋友提到,这些互联网企业应该全部是软件SDN的方案,在这里采用这样的理解,针对于云的部分,比如业务开通,迁移,安全功能等建立这些内容,应该是软件SDN来实现,针对于云基础设施里面,关于多厂家硬件交换机的初次部署,自动化配置上线,以及监控的部分,应该是软件自动化来完成,我把这种理解为硬件SDN的提供的功能之一,这也是我为什么说软件SDN方案居多,而没有说全部的原因所在。
第二个是一个叫“二马”网友的留言。
云计算蓬勃发展,技术更新迭代,不仅需要团队持续更新知识体系,也需要组织架构、管理模式作出相应调整,更需要工作思维转变,以前各职能团队自扫门前雪的情况需要突破,比如devops团队,google的SRE,都是为了打破原有原有竖井式职能团队的隔阂,提高团队协作效率。

我觉得这样的思考非常有意义,云的变化,技术往往只是工具,技术之外可能需要的更多。
        
好吧,言归正传,还是那句话,本文从大牛厂商的文章说起,再次强调,本文绝对不是针对或者否定特定厂家,还是前文那句话,结合原文延伸开来,给我们另一个视角去看待,山有南坡北北坡,横看成岭侧成峰而已。

原文链接如下,建议大家耐心看看。
DCN 学院派丨数据中心网络自动部署,软硬SDN如何选择?

本文的上半部分参考是原文的前三个层面,链接如下,温故知新。
技术杂谈-再谈软硬SDN(1)

下半部分,我们从性能开始。

●  谈及性能

创新互联公司服务项目包括新疆网站建设、新疆网站制作、新疆网页制作以及新疆网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,新疆网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到新疆省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!

原文提出:

由于硬SDN在交换机硬件上甚至芯片上来处理,性能上确实远胜软SDN。软SDN依赖的vSwitch也在持续往这个方向努力,比如叠加DPDK,智能网卡卸载等“围魏救赵”方式,性能问题确实得到了一些缓解,各厂家数据普遍提升到十多G,但相比硬SDN能力仍然差距较大。有些卸载技术能否规模商用还没有形成行业共识,有些还处在创新实验阶段,而且引入这些辅助技术时又扩展了软SDN的配套边界和复杂度,当然也增加了成本。

我们必须要肯定的一点,软件SDN单纯从性能上的考量,一定和硬件SDN存在差距,但是,是否硬件“远胜”SDN,那可能就需要用数据来考量。以openstack为例,早期为什么会使用硬件SDN,确实OVS本身的性能确实不让人满意,而硬件可以有效地承担解决这个瓶颈。然而,时过境迁,各种技术类似于DPDK,SR-IOV,以及智能网卡的兴起,软件SDN从未停止性能上追求的脚步,在保留原有灵活性的同时,努力去满足实际业务的需求,而且客观的讲,商用的案例比较一两年前,已经不限于星星之火,如果按照以往标准,硬件SDN性能打5星好评,软件性能一颗星的话,现在把软件达到3.5甚至于4星都有可能,很多网卡,系统厂商的测试指标,以及公有云的商用案例已经说明了这些。

更主要的是:选择任何一个技术,都是综合性的考量,是性能和灵活性均衡的结果,在上云的过程中,我们看到有案例是从软件迁移到硬件,也有案例从硬件迁移到了软件,也有硬件和软件不断地交替实现,恰恰说明了,不管是硬件还是软件,都在性能这个层面上不断的追求进步和完美,如同一个马拉松的历程,虽有短暂的差距,但是都在你追我赶的过程中。

●  开放和集成

文中提到:
企业市场细分市场众多,不同企业对包括服务器的厂家和型号、虚拟化平台、云平台等不同部件也有不同的喜好或经验,二者谁更能匹配这种开放集成的诉求呢?由于软SDN依赖服务器vSwitch,它需要配套底层平台软件,甚至匹配虚拟服务器型号支持。由于不同虚拟层软件的差异性,导致了单个vSwitch产品无法通配所有虚拟层平台而需要独立配套的产品。硬SDN则避免了这些锁定,由于控制点在硬件交换机,能普遍适应下层接入的IT资源生态,如不同厂家服务器和不同虚拟化平台,以及云平台产品。

回到我的看法,如果我们按照整体规划的逻辑,云平台是整体的调度-计算,存储和网络资源,虚拟化平台去承载这些实现,SDN是介于云平台和虚拟化平台之间,对上要可以和云平台有效沟通,对下需要和虚拟化准确实现,从云平台的角度,不管硬件还是软件SDN集成,都是靠API的对接来完成,二者在实现上并无差异,而对虚拟化的平台如openstack,或者k8s或者vmware的集成,软硬件实现的落地点就不一样。

软SDN如下图所示:
技术杂谈-再谈软硬SDN(2)
        
软SDN的目标是可以虚拟化网络层统一部署,来实现一致性的网络联通以及管理,这就意味着,如果你希望实现软件SDN,就需要对软件SDN的适配程度(主要是操作系统以及内核,虚拟化平台),具备一定的了解,同时也要考虑是否支持主流的平台。

硬件SDN如下图所示:
技术杂谈-再谈软硬SDN(2)
    
硬SDN的目标是保持原有的虚拟化网络层不变,通过硬件来实现网络联通和管理。而这也就意味着,如果是用硬件实现,在虚拟化网络层的部分放弃了统一,仍然保留原有的部署,通过硬件交换机来实现对底层虚拟化的适配,相比较而言更为简单。
        
但是并不能说明硬件交换机可以适配所有的平台,能适配所有平台的条件是,虚拟网络层不做任何的SDN动作,可以直接把流量透传上来,而虚拟网络层其实恰恰是执行网络策略相对合理的位置。
       
前面提到,软件SDN的目标是可以在虚拟化网络层里实现统一,也是有条件的统一,他的技术路线一定是先满足大部分的云平台,进而考虑其他虚拟化方式,例如VMware,就需要考虑本身是私有化平台,软件SDN如何去与之适应,要采用什么样的方式与其兼容,这一点的思路和硬件SDN是一样的。
        
因此,谈到开放和集成,两者的目的一致,各自有各自的实现方法,从我的目前的认知来说,各有千秋,说句墙头草和事佬的话,软也好,硬也好,各有各的门道儿。
        
但回到“锁定”这事儿上,让软件SDN背上“锁定”这个锅,可能需要重新琢磨琢磨。
        
前文提到:硬件SDN的控制点在硬件交换机上,基于此我们在追问一下?    
    
谁的硬件交换机呢??
参考一下前面硬件SDN的实现图形,我们假定有三个虚拟化平台,分别为V1,V2和V3,假定硬件厂家为一家A,此时所有的SDN设计都是V1-V3和A的对应,这个逻辑没有问题,但是如果业务规模增长之后,对于硬件交换机的品牌,我们有两种选择:
  1. 依然选择A家,这样可以保证SDN对的一致性。

  2. 选择增加B家,这时带来的复杂的排列组合问题,V1-V3不仅需要和A家的SDN产生对应,也需要对B家的SDN产生对应,如果再加一个C家,组合更多。


由此产生的话题包括:
  1. A家的SDN软件能够兼容B家的硬件吗?

  2. A家的整体SDN可以和B家的整体SDN实现网络侧的对接吗?

  3. 在SDN业务逻辑实现上,其他网络功能设备(如防火墙,路由器)可以是多品牌吗?


这些或许都不是问题,因为我说过,每一家的方案都有自己的优秀之处,用各种技术来将客户的业务逻辑通过硬件SDN的方式呈现出来,就如同房子装修一样,如果想简单易行,那么就找一个装修公司,所有的东西都全部交给他们搞定,或者直接买一个精装修的房子,既有好处,也会有遗憾。
        
这些或者又都是问题,本身硬件SDN其天生的基因就是,软件和硬件紧密集合,这也就决定了你无法在硬件上去灵活的选择,我们不去评价商业利益和厂商策略,至少在技术实现的逻辑上,硬件SDN存在这样的现状,我们不应,也无需回避。
        
而我的观点还是很“中庸”,是否有更合适的“软件”和“硬件”携手的方案呢?我知道理想很丰满,但我们不应因现实的骨感,而放弃对美好事物的追求。上一篇文章提到了AWS为代表的国外云企业,以及阿里云为代表的国内云企业,在他们公用云的设计中,软SDN负责云网络,硬SDN负责设备管理(而且是多厂家的模式),可以作为我们架构设计的一个借鉴,我在京东上预定了本《企业数字化基石》的书,我希望从阿里的描述中学习更多,作为后面文章的参考。

●  成本,以及场景


还是引用原文:
业界不少人认为软硬SDN之争最关键的两点便是可靠性和成本。性能问题最后归到底也可以看为成本的一个部分。在这场赛跑中,一边是软SDN通过服务器成本来置换网络资源,包括性能叠加和规模管理引入的成本。另一边则是网络设备商的硬件能力提升快速消化掉硬SDN的成本。哪个效率曲线跑的快,哪个就更有优势。这一点上,目前硬SDN有明显优势。从实际项目中取得信息看,硬SDN方案交换机已经基本消化了SDN的成本,和非SDN交换机的价格基本一样,这得益于这几年芯片集成能力飞速发展。反观软SDN,vSwitch的数量庞大加上运维年费,价格也并不便宜。

这里关于硬件SDN的描述是非常准确的,尤其提到,随着芯片能力的提升,我把这个话题延伸一下,总结起来可以是这么几句话。

  1. 10GE和25GE光模块的成本下降,使得服务器侧和交换机侧在在网络方面的整体成本下降。

  2. 从一个小技术点分析,VxLAN分布式网关已经成为交换机标配,芯片的快速迭代,使得最低的接入层交换机都可以几乎具备SDN的全部功能。

  3. 所谓的SDN交换机和非SDN交换机,就是功能的支持能力,随着时间的推移,两者一定会趋于一致,如同过去所谓二层交换机和三层交换机的差异一样,但是SDN和非SDN对的交换机价格差异是客观存在,究竟是不是基本一致,差又差了多少,就要看市场的定价如何。


从分析成本而言,成本既包括产品购置的成本,也包括学习的成本,维护的成本,产品更新替代的成本,一个个掰开看, 硬件软件之间,说不定谁贵谁便宜,即便把时间拉长也是如此,我觉得真的需要具体问题具体分析。
        
能够考量成本最直接的方式是什么?回报或许是一个考量,也就是ROI(投资回报率),在企业的IT投资里面,ROI是相对较难评估的,因为IT从来都是花钱的部门,如何评估直接带来经济效益呢?这个话题又太大了。
        
在我看来,除了要讲企业的整体收益纳入到IT的投资回报中之外,还可能有如下几个指标,例如IT规模增加的情况下,IT人员的成本是否线性增加,如果没有增加,也是隐形的收入,所谓没多花钱,就是省钱。再比如与以前业务的IT流程比较(这里说的是传统业务通过IT业务的实现,比如上线新产品,新系统等等),效率是提升了,还是降低了?是更灵活了,还是更复杂了?在朴素一点,IT人员做了这些,业务人员到底有没有感到“舒服”了,自己运维是不是感到“轻松”了?这些隐形的东西,可以在实践中,作为成本考量的一些标准。
        
从成本的话题再回到场景的考量上,文中提到的这个场景的“锚定”,就需要我们进一步反思。
原文提到:
但具体到不同场景上,软SDN展现了其灵活的用武之地。比如在一个不再增长的传统业务数据中心,客户无意过多投资网络改造,而老旧的交换机不支持SDN,这时软件SDN方式用服务器资源置换SDN能力会是一个好的选择。毕竟对一个没有增长的业务不必要去大动干戈。硬币的另一面,如果预期业务要持续增长时,仍然建议采用硬SDN的方式来建设或逐步改造,时间越长回报越大。

在这个说法中,在传统数据中心的场景下,建议使用软件SDN去置换SDN能力,但是前文说道,硬SDN在成本上有明显优势,那为什么在老的数据中心场景下,又建议使用软SDN呢?毕竟SDN这件事,不管软件还是硬件,对于老的数据中心,都可能是“回炉改造”的过程,在前文中并没有提到在传统数据中心和新兴数据中心的成本参考,而在后文又缘何要把软SDN框定在传统数据中心的“藩篱”之内?
        
如果是我的话,我可能要换个说法,各位看是否合适:
        
对于不再增长的传统业务数据中心,业务已经固定,客户无意过多投资网络改造,老旧的交换机不支持SDN(其实这些年,这样的数据中心似乎越来越少了),与其说大动干戈进行改造,不如保持不变,维持原有业务的连通性和逻辑,当新的数据中心建设完成之后,将业务迁移过去,慢慢完成新老交替。
        
而在新的数据中心建设中,投入资源去进行调研和学习,在了解自身能力半径,确定业务发展的思路,云平台的选择,技术发展上的方向之后,综合考虑文中提到性能和灵活性,扩展性和稳定性,开放性和集成度,成本和收益的种种要素。
        
我相信,行业千差万别,技术也层出不穷,但千变万化之中,总有普适性的道理可以遵循,总有常规的逻辑可以分析,总有成功或者失败的案例可供参考,而我们得出的结论并不是硬件SDN和软件SDN谁更是主流。而是这个答案,能否帮助你在实际的业务中达到要求,解决问题,实现增长。

所以你要是问我的答案是什么,对不起,我真的很难直接告诉你,因为我的答案,未必就是你的,我也在不断的学习,不断推翻自己的结论。
        
在这个旅程中,我看到了互联网公司对性能的要求,对灵活性的追捧,也看到了金融行业对稳定性的执着和对创新的渴望,我看到了制造业对物联网,工业互联网的思考,也看到了政府和公众事业,对自我业务IT重塑的决心。
        
数字化医疗,新零售,无人驾驶,5G,各种新的业务场景带来了企业数字化转型的各种可能,这其中,有失有得,有固守,亦有革新,如果你让我究竟SDN的路该如何走,那我们不如找个机会一起坐下来。
聊一聊,看一看……
PS:唉,写到这里,又超了不少字,很多人已经不爱看超过3k字以上的微信文章了,不过我也懒得再去为了分割而分割,文字也是一个记录,仅从记录本身而言,多少字并无关系。下一期打算写一些技术类的文章,还请大家多多监督,避免烂尾。


技术杂谈-再谈软硬SDN(2)

TF Live丨KK/建勋:多云、SDN,还有网工进化论

技术杂谈-再谈软硬SDN(1)

技术杂谈-再谈软硬SDN(2)

技术杂谈-再谈软硬SDN(2)


网站栏目:技术杂谈-再谈软硬SDN(2)
地址分享:http://hbruida.cn/article/pccgce.html