技术杂谈-再谈软硬SDN（1）-创新互联
以下文章来源于微信公众号：网络里卖艺的小青年 ，作者KkBLuE
汕尾ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！ 我曾 在SDNLAB和TF中文社区联合举办的直播活动上做 了一次分享， 讨论到软件SDN和硬件SDN的话题，巧合的是，看到国内大牛厂家也在讨论软硬之路，于是就有了本文的第一篇，文章比较长，需要阅读5-10分钟。 【直播回顾】TF Live丨KK/建勋：多云、SDN，还有网工进化论
DCN 学院派丨数据中心网络自动部署，软硬SDN如何选择？
强烈建议，对软件SDN不了解的同学一定读一下，里面有很多中肯之语，但是里面很多语句也有待商榷，因此摘录一下，说说自己的看法。撰文之前，先说几点声明：（1）选取本文绝非针对特定厂家，任何厂家均有优秀之处，值得学习的东西太多太多。 （2）软硬SDN的讨论一直是长期话题，本人目的绝非否定硬件SDN，而是阐述本人所见所感，供大家参考。 （3）没有绝对完美的方案，只有适合与不适合，所有IT和网络的进步，都是原有技术方案的认知积累和不断反思创新的结果。
请先看完原文之后在看本文，再次强调：本文不会否定原文任何观点，而是为各位读者补充提供另外一个视角，去看待SDN而已。
首先，从自动化能力的灵活性来看，自动化程度更多取决于不同厂家对网络业务的理解能力和逻辑抽象水平，与软硬方式相关性并不那么高。比如在SDN的业务发放上，北美厂商沿用一贯简单的多级表单的方式来下发业务逻辑。而国内厂家基本已经使用图形化交互的方式，抽象层次更高、逻辑理解更直接，这一点值得为国内厂家点赞。而目前逐步兴起的意图网络，硬SDN厂商可用基于IT业务语言来自动化网络的配置，甚至可以做到事前校验、事后验证等更高的自动化水平。软SDN厂商则相对落后。 DCN 学院派丨数据中心网络自动部署，软硬SDN如何选择？
特别认同这句话，自动化程度更多取决于不同厂家对网络业务的理解能力和逻辑抽象水平这句话，看每个厂家的方案，都能体会到背后研发人员功底和水平，也正因如此，从讨论技术实现本身的角度，我更倾向于国内厂商和国外厂商都各有可取之处，所谓文无第一，武无第二，萝卜白菜，各有所爱。但是本文中以SDN业务发放的举例，用来讨论网络自动化程度更为合适，用来讨论硬件SDN和软件SDN的比较上，略有脱节。 我们不妨换个角度，从数据中心对SDN的诉求角度而言，大家追求的目标是都是文中提到的IT业务语言到网络设备配置的实现，这里的诉求一个层面是管理配置界面的实现，是否逻辑通顺，是否界面整洁美观，是否满足基本需求，另一个层面才是配置的实现由软件还是硬件来完成。如果我们用SDN软件管理界面的喜好程度，去评价软硬SDN哪个更强的话，有一定道理但并非全貌。 管理配置界面的水平和能力，恰恰也是体现了不同厂家对业务的理解，而自动化程度的实现，恰恰取决于底层的实现，究竟是软件还是硬件呢？文中对的第二段恰好给出了比较。
软SDN在于其业务开发全部依赖于软件实现，更灵活、迭代更快，能力可以不依赖于硬件快速更新。但实际商用时也有严格的版本策略，并且需要考虑将对性能影响严重的特性如加密、封装卸载在网卡上。总体而言，软件方式身段更灵活一点，但因为完全依赖CPU也面临较多约束。所以在这一点上，更应该侧重考察的是，不同厂家不论软硬方式，其在自动化能力上表现出的不同眼界和实践水平。 DCN 学院派丨数据中心网络自动部署，软硬SDN如何选择？
本文的观点十分中肯，软件更加灵活，其实是否全部依赖CPU有待商榷，提到的CPU会有较多约束，只看到结论，如何证明这个结论，我需要进一步去学习研究。其实太灵活，意味着对掌控的人的要求更高，我想，任何一个技术的尝试，最终是都达到效果，与有使用者的能力半径，技术的实现逻辑，方法都有关系。当选择硬件产品的时候，会参考彩页，看端口，看功能支持，同样的道理，当选择软件方案的时候，我们同样需要考虑版本适配，性能考量，做到知己知彼。两者参考的方面不同，但是背后的逻辑是一样的，更重要的是，看看业务对网络的需求在哪里。
其次，从网络的可扩展性来看，二者能力不分伯仲。二者均可以构筑大规模的SDN网络，包括支持跨域多DC的级联网络。软SDN可以灵活牺牲服务器资源来置换网络资源，所以在租户、VPC等规格上可能会超过硬SDN在交换机上的硬件资源限制，然而当前主流交换机规格基本不存在瓶颈，所以这个优势无法体现到实际项目价值中。暂且认为二者在此打成平手。 DCN 学院派丨数据中心网络自动部署，软硬SDN如何选择？
网络的扩展性，粗浅的说，取决于如下要素，性能，弹性，功能支持。
性能：泛指吞吐，转发，以及相关的表项支撑
弹性：泛指自动化程度，扩展程度，网络设备能否随业务快速的变化
功能支持：除了网络中的功能支持之外，在虚拟化或者说云的DC里面，也增加了诸如NAT，FW，以及相应的服务链的支持。
从我的角度来看，扩展性是一个综合工程，如果套用木桶理论的话，前文提到的这些，都是木桶中的每一个木板，而扩展性如何，取决于最短的哪块，要评价，估计在写几万字都写不完，我们还是简单粗暴，列出如下两个问题：
软件SDN比硬件SDN灵活，但是性能不如硬件SDN，硬件SDN的性能毋庸置疑，那么软件的性能到底如何？能否满足需求？是否我们还是用早期软件SDN的性能的早期印象，从而看待现在的软件SDN的性能？
硬件SDN不如软件SDN灵活，那么硬件SDN在灵活性方面，有哪些是可取之处，哪些又是天然不足，还有哪些可以后续不足呢?
大概真的没有十全十美的方案，真正落地的使用，都是客观技术和主观喜好的综合。很早以前，我有两个工作选择，问一个前辈怎么办，前辈说你拿一张纸吧，题目就是两个工作A和B，然后A写清楚好的有哪些，不好的有哪些，B写清楚好的有哪些，不好的有哪些，最好在加上自己现在的工作，不敢保证你选的对不对，但至少有过思考，可能选错了，也不后悔~
谈及软SDN和硬SDN，道理大概也是如此吧。
但是，技术人员总有追求完美的欲望，如果我们把SDN的功能拆解，部分功能交给软件完成，部分功能交给硬件完成，采用结合的方案，扬长避短，可能会有更有意思的话题出现，这个话题我们可以在后面的文章进一步讨论。
第三，在实际的网络部署中，可靠、稳定是重中之重。没有人会容忍一个频繁掉链子的网络。这一点硬SDN天然具备更佳的身位，其从早期一路积累的商用可靠性能力有巨大优势。而软SDN通过vSwitch也提供了故障切换的能力，但作为业务软件依然受限于软件特有的可靠性问题。此外，软SDN会给网络运维团队带来新的挑战，运维边界需要延伸到服务器内部，服务器运维在网络和业务团队部分叠合，存在冲突的可能。所以我们看到，敢于使用软SDN的基本是互联网厂家，自身拥有较强的技术能力来克服这个问题也是一个重要原因。 DCN 学院派丨数据中心网络自动部署，软硬SDN如何选择？
网络的稳定性，一直以来，任何人都毋庸置疑，越是贴近市场的业务，越是敏感，越是赚钱的业务，越是不容有失，这一点，我们可以看到互联网公司，运营商，金融企业，以及其他大型企业，都有对稳定性的渴求，而稳定性，恰恰又是另外一个木桶。
而这个木桶里，除了包含硬件的稳定性之外，还包括网络的高可用设计，故障恢复的机制等等，可能硬件运行没有问题，可一个生成树成环就让网工死去活来的。对于硬件SDN和软件SDN稳定性和可靠性谁更优异，如果没有充分的案例和素材，我本人不敢做出评价，希望看过这本文的兄弟姐妹可以给我更多素材。
正如文中所说，互联网厂家敢于使用软SDN，想必他们对稳定性方面有自己的看法，找机会和互联网的兄弟们聊聊，据我所知，国内的AWS，Azure和GCP，国内的BAT，软件SDN的方案还是居多，结合我前面的说法，其实他们的技术能力和掌控能力有关系，这又是一个新的话题，这里就不多说。
文中引出的一个话题更吸引大家的关注，并非技术的实现，而是管理的边界，简而言之，当使用软SDN的时候，因为执行点在服务器，那么该谁管呢？扩展点说，谁来配置，谁来维护？粗俗点说，出事了，谁管？
必须承认的是，运维的冲突，是客观存在的现象，但我们稍作反思，这是一个管理的问题？还是技术的问题？
云带给行业的改变，不止于业务形态，技术的改变，对于组织架构，管理模式，分工协作，也都带来改变。
恰恰是市场需要企业的业务具备敏捷性，才引发了企业的业务要求IT的敏捷性，也正是因为有了IT的敏捷性需求，才会有云的兴起，而正是有了云的兴起，才会有网络和业务的关联度如此之高。因此，以前是IT组织下各司其职的各个部门，现在正是需要一起坐下来，重新制定战略和业务分工，我们看到很多的客户在IT内部，专门成了云业务部门，核心的原因，就是希望打破原有的壁垒，让整个IT有机结合起来。
但是组织的变革也势必带来挑战，管理的权限，能力的学习，部门之间如何携手，这里有太多的思考，而这个冲突，我更倾向于是管理的思考，未来企业IT的掌舵人以及所有从业人员的思考，而软硬SDN的稳定性讨论方面，我们更多还是需要关注在技术实现和设计架构上。
一不小心，3000多字，数字化转型，云计算，SDN从来就不是单一的问题，更多的角度，会带来我们更多的思考，华为的这篇文章，帮助我们看到了实现SDN的各种可能，我的文字，希望提供另外一个角度，更倾向于引出更多的思考，而不是武断的得出结论，言辞也一定局限之处，希望能和同道更多的交流学习，我们下期再会。
没有冬天不会过去，没有春天不会到来!
【直播回顾】TF Live丨KK/建勋：多云、SDN，还有网工进化论
本文题目：技术杂谈-再谈软硬SDN（1）-创新互联
文章路径：http://ybzwz.com/article/csocop.html
