基于流量的转发并不适合现有硬件的微流量设计
我想现在大家应该都清楚了，基于流量的转发并不适合现有的硬件。为大流量设计的交换机，例如转发入口（NEC交换机、数据中心交换机等）可能是个例外
，但即使他们无法处理反应式流媒体安装所需的巨大流更新率，我们当然希望虚拟交换机性能更好，但不幸的是，事实并非如此。
定义
基于流的转发有时被定义为单个传输层会话的转发（有时称为微流量），许多事实表明这种方法无法扩展，其他人将基于流的转发定义为任何地址转发，我不'不知道这些定义与 MPLS 类 (FEC) 有何不同，也不知道为什么我们需要使用新的和令人困惑的词来定义它们。
Open中的微流转发
Open的原始版本基于理想微流的典型转发架构：内核转发模块执行微流转发并将所有未知数据包发送到用户模式守护进程，然后执行数据包检查（使用转发条目或其他转发规则），并为内核模块集线器发现的数据流安装微流条目。
如果你还记得5000，你可能对交换机有一些不愉快的回忆武汉服务器运维，但是这个方案的问题应该是硬件和CPU的性能不佳。事实证明，虚拟交换机也好不了多少。
深入挖掘Open发现了一个有趣的东西：流量驱逐，一旦内核模块达到微流量的峰值，它就会抛出之前的流量武汉服务器运维，直到你意识到默认峰值是2500微流量，这足够一个网络服务器。，而对于托管 50 或 100 台虚拟机，数量级肯定太低了。
微流量缓存非常小，没有明显的效果，毕竟一个 web 服务器可以轻松处理 10,000 个会话，而一些基于 Linux 的负载均衡器可以控制每台服务器多一个数量级的会话，可以增加默认的 OVS流量，有人会奇怪为什么默认值这么低？
我无法说明这可能的原因，但我怀疑它与单位流量计数有关 - 流量计数器必须定期从内核模块转到用户模式守护程序。在相对较短的时间间隔内，在用户内核插槽之间复制数千个流量计数器会占用大量 CPU 空间。
怎么修？
还不够明显吗？放下所有基于微流量转发的概念包袱，用传统的方式来做，这就是OVS在1.11版本中所做的。OVS 1.11 在内核模块中部署兆位流量，然后从内核重定向流量。发送到用户模式代理（这很重要，因为内核转发条目几乎可以与用户模式条目完全匹配）。
毫不奇怪，没有一个虚拟机使用基于微流量的转发。、Cisco Nexus 1000V 和 IBM 的 5000V 根据目的地的 MAC 地址做出转发决策，Hyper-V 并根据目的地的 IP 地址做出转发决策，甚至 NSX 用于分布式和核心内第 3 层转发模块。
上一篇: 武汉it公司选择磊丁网的原因是什么？