作者：Umberto Manferdini 译者：TF编译组
最近我参与了一个项目，我们在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 * 7*10^2*8 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是完全透明的。
从fabirc的角度来看这意味着什么？主要是，你只需要配置与Tungsten Fabric数据平面网络关联的单个VLAN。在这个VLAN内有MPLSoUDP，正如我们所说，它隐藏了所有虚拟网络。
与之不同的是，其它的SDN解决方案使用了另一种方法。不同的虚拟网络作为不同的VLAN退出计算节点。计算节点面向fabric的接口，就像一个经典的中继端口。这意味着每个虚拟网络都成为IP Fabric上的一个VLAN。没有overlay隐藏这种“复杂性”，一切都在那里！
归根结底，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。
比较结果表明，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——这是一个非常合理的路由器，对吗？
配置上的差别
如图所示，在使用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会话的数量，这可能会影响我们所不能低估的可扩展性。
我们可以看到，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数值进行简单比较。
