pps数据无法回答“哪种SDN解决方案更好”,你需要考虑这些



  • 作者:Umberto Manferdini 译者:TF编译组

    原文链接:
    https://iosonounrouter.wordpress.com/2020/04/28/which-sdn-solution-is-better-what-i-learned/

    最近我参与了一个项目,我们在Tungsten Fabric(注:原文为Contrail,本文将以功能一致的Tungsten Fabric替换)集群中部署了虚拟移动网络。移动链虚拟网络的功能类似于Packet Gateway和TCP优化。

    同时,该项目还使用另一个SDN解决方案部署和测试了相同的应用程序链。Tungsten Fabric是L3 SDN解决方案,而另一个是L2 SDN解决方案。

    于是有个大问题跳了出来:哪个方案更好?

    如何看待pps性能数据

    通常,我们倾向于通过性能来回答这个问题。例如“嗯,A方案可以达到10M pps,而B方案只能达到7M pps,所以……”。

    毫无疑问,这很重要,它会对整体解决方案产生影响。例如,如果一种解决方案比另一种快两倍,则可以将虚拟机的数量减少一半(假设虚拟机可以处理所有流量),从而节省了服务器,减少了要管理的设备数量,缩减了许可费用(取决于许可模型)等等……

    是的,pps所代表的性能很重要,而且将永远如此……但是,这并不是全部!

    我认为,在某些情况下,pps所代表的的性能会变得根本不重要。

    考虑在某个计算节点上的情况。通常,你会将它通过以链路聚合(LAG)方式多归属到两个叶子节点(Leaves)的链路连接到IP Fabric。该LAG链路为你提供的总带宽为N*X,其中X是你使用的接口类型(通常为10G或40G)。假设我们使用由2x10G制成的LAG。还要考虑平均数据包的大小(700B)。

    现在,A方案可以达到10M pps性能。通过一些简单的数学运算,我们得到10^7 pps * 710^28 b = 56 Gbps!很高!B方案仅达到7M pps,从而提供约39 Gbps的带宽。在这种情况下,多出来的3M pps将不起作用。因为两种方案都能填充我的LAG,这对我来说足够了……至少在使用平均数据包大小的情况下是这样。

    如果是比较小的数据包(46B),则A方案将达到3.6 Gbps,B方案B仅为2.5 Gbps。这里,我们离LAG 100%的利用率还差得很远,因此pps就更为重要。但问题是,我们是否有必要考虑只有小数据包的网络?

    我们应该确定平均数据包大小,并查看使用这两种解决方案的速度。如果两者都允许达到100%的LAG利用率,那么比较pps并不能帮助我们确定最佳的SDN解决方案。

    “仅仅看原始性能数字还不够”,于是我开始思考其它方面起什么作用,并且是否可以告诉我们A方案和B方案哪个更好。

    为了解决这个问题,我分析了体系架构的各个方面,并从“解决方案角度”而非“纯粹性能角度”进行了研究。

    Overlay的角色

    Tungsten Fabric通过overlay mesh在计算节点之间运行,并且连往SDN网关。MPLSoUDP 或 VxLAN隧道用于承载VM流量。

    这些隧道将发送到虚拟机或从虚拟机发出的实际流量“隐藏”起来。在vRouter内部,每个虚拟网络均配置为众所周知的VRF。就像经典VPN一样,向每个VRF分配MPLS标签,并且VM数据包以封装在DC Fabric中的方式传播(MPLSoUDP是新的MPLSoMPLS,而IP Fabric是新的主干)。

    结果,IP Fabric看不到实际的流量,它只能看到MPLSoUDP(或VxLAN流量)。在这些数据包内部,通过不同的MPLS标签标识了不同的虚拟网络,但这对fabric是完全透明的。

    e1e5df9b-4ed7-43c9-932c-4c86372fab09-image.png

    从fabirc的角度来看这意味着什么?主要是,你只需要配置与Tungsten Fabric数据平面网络关联的单个VLAN。在这个VLAN内有MPLSoUDP,正如我们所说,它隐藏了所有虚拟网络。

    与之不同的是,其它的SDN解决方案使用了另一种方法。不同的虚拟网络作为不同的VLAN退出计算节点。计算节点面向fabric的接口,就像一个经典的中继端口。这意味着每个虚拟网络都成为IP Fabric上的一个VLAN。没有overlay隐藏这种“复杂性”,一切都在那里!

    bdc1eedf-aa7e-44de-8026-9bf8e89b9399-image.png

    归根结底,VM和SDN GW之间的端到端通信在两种情况下均有效,但成本又是多少呢?

    成本与效用

    不要仅仅考虑端点是否可以通信,还要考虑一下配置工作和服务创建的工作量。

    通过使用Tungsten Fabric,你可以一开始就在fabric上创建控制数据平面VLAN。然后,在创建移动链时,不需要在fabric上进行任何更改。

    另一方面,在没有Tungsten Fabric的情况下,每次创建新服务(移动链或其它)时,都必须在SDN和IP Fabric上都配置网络。

    这意味着复杂性增加,出错的几率增加,需要更多的工具实现自动配置(除非你可以接受手动配置fabirc……使用Tungsten Fabric时不建议你这么做),并且通常来说,业务投产并开始从中盈利的周期更长。归根到底,钱永远是很重要的事情。

    这是第一个方面,它帮助我们理解了,当我们以超越纯pps数值来看问题时,两个SDN解决方案会有怎样的不同。

    我说过计算节点使用LAG连接到IP Fabric。理想情况下,你是希望在LAG成员之间平衡流量的。

    使用Tungsten Fabric时,这已经是事实了,我们能够在测试过程中观察到它。

    相反,另一个SDN解决方案使用LAG模式,其中基于源地址对传出流量进行哈希处理。结果,这导致了流量的不均衡。这也意味着不可能完全利用所有LAG带宽。

    从这个角度来看,实际的pps数量的影响甚至更小,甚至不可能100%地使用LAG。

    a306a485-411b-45d1-904c-6f499c7e716b-image.png

    比较结果表明,Tungsten Fabric解决方案能够提供更好的资源利用率,这意味着整个DC基础架构的投资回报率更高。

    路由功能的不同

    正就像我们在电信云中一样,处理移动核心应用程序时,虚拟机不是通常在企业中的那种虚拟机:Web服务器、数据库、前端等……用例不同,因此工作负载也不同。这里的虚拟机使用所需的路由!路由对于交换路由并提供快速收敛至关重要。例如,P-Gateway需要路由至通告地址池。

    Tungsten Fabric原生使用BGP:它使用BGP进行内部通信,使用BGP与SDN GW进行通信,并且将BGP与虚拟机一起使用。最后一个用例通常称为BGPaaS,在VM和vRouter之间建立BGP会话。

    这是可能的,因为Tungsten Fabric是L3 SDN控制器,因此它具有L3功能并且可以识别L3。

    那么,L2 SDN解决方案又有什么不同?

    让我们考虑一个用例:SGi网络。该网络是P-Gateway出口网络。该网络又连接到移动链的下一个元素:在我们的示例中,是TCP优化VNF。

    P-Gateway通过BGP通告用户池……但是去到谁那里呢?

    在Tungsten Fabric当中,P-Gateway通过BGPaaS与TF建立BGP会话。BGPaaS还用于通过TF和TCP优化器之间的另一个BGPaaS会话,将这些路由重新发布到TCP优化器。

    一切都在Tungsten Fabric内部解决和管理了……请记住这一点。

    同样的问题,其它解决方案又是如何面对的呢?

    由于VNF的限制,无法在P-Gateway和TCP优化器之间创建直接会话。结果就是,需要有中间对等节点。由于这是虚拟机之间的对话,因此客户不想让流量流出fabric……因此fabric必须进行路由。这意味着在Spine设备上配置BGP。此外,为了优化流量,P-Gateway发送了数千条“小”路由,所有这些路由都需要在Spine上存储和管理。

    将路由功能迁移到Spine,意味着给本来不作为这个目的的设备带来巨大负担。Spine应该是简单地转发数据包的交换机。在这种情况下,它变成了一个路由器……但是它性能足以成为路由器吗?如果你购买了性能优异的路由器,那么答案是肯定的。而这意味着增加CAPEX,并且花了更多的钱购买功能更强大、价格更高的设备来作为Spine。这是可以接受的吗?没有绝对的答案,但我认为多数时候是“不”会是一个正确的答案。

    另一方面,使用Tungsten Fabric时在fabric上看不到路由:只是在带Tungsten Fabric隧道的单个VLAN上转发数据包。所有这些“小”路由仍然存在,但它们只存在于vRouter上(vRouter作为一种L3设备比交换机更适合这一场景)。那些“小”路由将被进一步通告给SDN GW——这是一个非常合理的路由器,对吗?

    配置上的差别

    b0269625-2b4b-4ecd-8754-79c827f9106f-image.png

    如图所示,在使用Tungsten Fabric时,fabric不参与到控制平面。利用TF内部信号机制,一切都在Tungsten Fabric级别进行管理。

    从fabric上卸下控制平面还意味着更容易创建服务。就像我们之前谈论VLAN时所说的那样,创建服务时不需要在fabric上进行其它配置。整个服务是通过简单地定义一个列出所需虚拟资源的模板(Heat模板)来创建的。如果没有Tungsten Fabric,则需要在fabric上同时具有Heat模板和其它配置……以及我们之前提到的所有后果和考虑因素。

    类似的路由考虑因素都可以对SDN GW执行。在这里,我们考虑的是TCP优化器的出口侧,它发布地址池给SDN GW(此处Fabric仅提供L2)。

    如果没有Tungsten Fabric,则需要配置多个BGP会话(N个TCP优化器和M个SDN GW,即N*M个BGP会话)。

    而在Tungsten Fabric当中,我们可以利用控制节点和SDN GW之间的基础设施BGP会话。在这个会话中,Tungsten Fabric为其所有的虚拟网络发布路由。然后,SDN GW根据VRF中已配置的路由目标将其导入(记得吗?Tungsten Fabric只是DC中的VPN ...)。

    这个过程将会是这样的:VM通过BGPaaS将路由发布到Tungsten Fabric,然后TF通过单个BGP会话将路由重新发布到SDN GW。如果你添加了更多虚拟网络或更多BGPaaS会话,与SDN GW的会话数量也不会改变:始终为1!

    在这种情况下,差异不在于配置的大小层面。两种情况下,你都需要在SDN GW上进行一些配置:是配置一堆VRF,还是一堆路由实例和BGP会话。

    此处的区别在于SDN GW上运行的BGP会话的数量,这可能会影响我们所不能低估的可扩展性。

    fc539453-bb40-4f52-9b14-92f3a22d81c9-image.png

    我们可以看到,Tungsten Fabric和SDN GW之间只有一个BGP会话,而在vRouter和TF控制器之间有多个XMPP(类似BGP协议)。的确如此,但这是Tungsten Fabric体系架构的一部分。Tungsten Fabric启动并运行后,它将自动处理所有这些XMPP内容,对用户是完全透明的。

    从运营人员的角度来看,你只需配置一次Tungsten Fabric-SDN_GW BGP会话,然后就可以在部署应用程序时创建BGPaaS对象。

    运营的视角

    到目前为止,我们已经看到了Tungsten Fabric在服务提供及配置上的优势。当然,SDN解决方案也可以从实际运营的角度进行比较。

    为了获得更高的性能,计算节点使用DPDK进行部署。

    没有Tungsten Fabric的话,很难监视特定的虚拟机接口。

    那么,如果使用Tungsten Fabric,将有一组cli工具,包括类似tcpdump的工具,它们可以识别在dpdk端口上运行的特定VM端口并嗅探通过该端口的流量。

    在故障排除的情景中,使用Tungsten Fabric的解决方案会更加友好。

    故障排除还包含镜像实现的问题。

    TF vRouter支持内置镜像。你可以在一个给定的虚拟机接口上有选择地镜像数据包,并将该流量发送到外部分析器(DPI)。

    如果没有Tungsten Fabric就没法实现了,镜像不得不依赖在IP Fabric上配置的临时解决方案。这意味着给IP Fabric加上了额外的负担,增加了其整体复杂性。

    运营不仅意味着进行故障排除,还意味着监视集群中发生的事情。

    除了OpenStack本地提供的所有元素外,Tungsten Fabric还提供了一个名为Analytics的组件,该组件通过REST API为运营人员提供了大量信息,并能够实时接收警报,以便在出现问题时迅速做出反应。

    这有助于在Tungsten Fabric基础架构上实现更好的控制。

    在这种情况下,基于Tungsten Fabric的SDN解决方案,实际上丰富了由另一个基于L2 SDN的解决方案提供的工具集。

    总之,从更广泛的角度比较这两种解决方案,得出了一些有趣的观点。

    Tungsten Fabric允许使用更薄的IP Fabric——只需要较少的配置更改,并且可以更加专注于其主要目标:以无阻塞并且冗余的方式转发数据包。

    此外,所有与应用程序相关的路由都从fabric上移除了,避免了购买更昂贵的交换机来满足路由所带来的需求的风险。

    节省CPAEX也可以节省OPEX,因为它具有“更稳定的fabric配置”,所需的时间更少。

    由于所有配置都只限于Tungsten Fabric和SDN GW(如果需要),因此可以更快地实施服务。

    同时,基于Tungsten Fabric提供的其它工具,故障排除和监视整个基础设施变得更加容易,这使运营工作更加轻松,因为不再需要为所有事情构建或购买定制化工具,而又降低了成本,。

    “哪种解决方案更好?”一个看起来很简单的问题,实际上包含了很多方面和考虑因素,仅仅比较原始pps数值的做法极易产生误导。

    以上,我主要介绍了由Tungsten Fabric的优点和Tungsten Fabric驱动的解决方案提供的优势。我是站在TF一边的,所以,我得承认我并不是中立的。

    无论如何,我想表达的核心观点是,对比涉及整个DC的SDN控制器之类的复杂解决方案,或者不限于此的方案,不能简化为仅对pps数值进行简单比较。


Log in to reply