首先，我们必须定义我们正在谈论的虚拟环境是公共云，私有云，NFV或这三个的组合。
我们只想先接触NFV，即“ 网络功能虚拟化 ”。
NFV并不是真正的云解决方案，它只是标准硬件“服务器”上网络功能的虚拟化。NFV使用组件和构建块作为云，但是在应用方面存在很大差异。
NFV应用仍然是这些需要大量RAM和CPU资源的大型单片应用。这些应用程序不像云应用程序那样呼吸。
原因，是对于真正的云应用程序，您需要实体之间的无状态连接，而当今的电信协议根本不是无状态的。
当核心基础架构也是5G时，我们将看到真正推出5G时发生的变化，但这将持续一段时间。 我们将在这种大型单片应用中保留很长时间。
什么是探针？ 实际上，Probe是一个反汇编程序，它读取网络信息并将其传输回原始输入“元数据”。 但是众所周知，拆卸的最低要求将是与组装相同的资源量。 因此，探针是一种非常灵活的饥饿设备。
探针供应商的目的是从这些设备中获得尽可能多的性能。 为了获得最佳性能，重要的是要避免使用探头上不需要的任何其他功能。 这就是Windows作为探测操作系统从未成功的原因。
探针要获得相关流量，需要Cubro提供的智能网络可见性解决方案。 在传统网络中，我们使用网络分路器（TAP），聚合器和NPB“网络数据包代理”将相关数据提供给探针。 在大规模网络环境中，这可能是一个复杂的安装，但通常是一个优势，因为这样的系统可以为不同的目的提供不同的探测系统。
在现代网络中，结合了真实和虚拟环境，它要复杂得多。 如果我们在NFV环境中，则不再需要物理链接，而虚拟网络链接可以在真实的物理网络上传输，但可以封装在其他网络层中。
有三个选项可以解决此问题：
1）使用现代化的可视化方法，该方法可为您提供满足所有监视需求所需的所有网络信息。
2）尝试使用虚拟探针
这种方法听起来很简单。 由于复杂的可视化需求，我们可以在与虚拟网络设备相同的管理程序上运行探针。 尽管这听起来像是一个完美的主意，但是如果您深入研究，就会遇到一些严重的问题。
- 我们知道探针是一种非常消耗资源的设备。 在相同的硬件上运行这样的设备肯定会降低虚拟网络设备的性能。 通过使用更大的服务器硬件可能可以弥补此问题，但始终存在限制。
- 如何将受监控的流量馈送到虚拟探针？ 这是由虚拟分路器TAP完成的，但虚拟TAP不是TAP。 这是一个软件，可复制流量并通过隧道将其发送到探测软件。在相同的硬件上也会发生这种情况。 现在，我们有了网络功能本身，分路器TAP和探针——这意味着硬件必须多次处理同一数据包！
- 从一般物理学方法中我们知道，为了获得精确和可信赖的测量结果，测量设备永远不应成为被测系统本身的一部分。
- 如今，安全性已成为流行语。 如何才能保证这个探测“软件”不会以任何方式被破坏呢？ 使用硬件探针，可以通过网络完成与探针之间的通信，并且可以监视该网络。在同一虚拟机管理程序上运行应用程序的情况下，几乎不可能跟踪软件在做什么。
除了上面提到的针对移动网络中任何虚拟探测方法的四个要点外，还有一些技术要点使虚拟探测并不是真正的好解决方案。 我只提到了几点，但如果你深入研究，就会发现还有更多的问题。
a：在LTE网络中，有些协议消息是加密的。 为了解密这些消息，需要首先解密来自另一个协议栈的消息。 对于探针来说，要几乎同时处理所有这些不同的消息以取得良好的结果是一个极为关键的挑战。
利用硬件探针，可视化系统通常将所有这些不同的消息实时地（少于1ms）提供给探针。这是一种确定性的方法——每个数据包都以相同的延迟传输到探针。 在虚拟系统上，这要复杂得多，因为不同层上的许多不同软件必须相互协作才能完成这项工作，而且我们都知道软件按照定义不是确定性的。
b：LTE和5G中的流量增长和负载平衡也是虚拟移动探针的一大矛盾。 在vEPC中，有许多服务器用于运行GW应用程序。 如今，随着网络流量达到TB级，很容易需要十台或更多服务器来处理该流量。 这些服务器已经是最大负载处理它们的原始工作，没有用于探针的资源。 第二个挑战是负载平衡。 碰巧会话从一个虚拟GW移动到另一虚拟GW。 在这种情况下，必须将流量重新路由到会话已开始的探针。 如果不是，那么以后的关联将会非常复杂。
3）使用Cubro解决方案
overlay监控和可视化自动化方法可以解决可视化节点上的挑战。 一旦实现这一点，您就可以使用高达1 TB的高性能探针来解决性能问题，并获得经济高效且可持续的解决方案。
Written by: Christian Ferenz, CEO, Cubro Network Visibility
