当网络虚拟化不足以解决问题时 我们怎么办？

咨询师Glen Kemp分享了一位客户在遇到平台Bug之后重新评估网络虚拟化好处的案例。

任何新技术或现有技术的迭代都会使事件变得更快、更便宜或减少运营花费。服务器虚拟化肯定能产生这些结果，而现在网络虚拟化正在吸引越来越多的关注。然而，一些最新项目证明了虚拟化案例并不一定是这样的。

按照我作为一名安全和IT咨询师的经验，我曾经看到过一些客户跟随潮流购买了安全虚拟化产品，将许多服务都整合到一个平台上。这样可以显著节省电源和减少维护费用。这一切都很好：合唱队在看不见的地方高唱赞歌，告诉人们新技术是如何让生活变得更好。

但是，它并不适用于一些情况——至少一开始是不适合的。

这就是我要说的。有这样一个例子，一个客户在使用虚拟化框架不久之后，就遇到了一个严重的平台Bug。问题的细节并不重要，但是它的影响却很大。在虚拟化 之前，这种问题的影响范围很有限，但是共享平台的层叠故障导致许多个业务单元发生中断。这个问题很难修复，它需要安装几个补丁才能让平台保持稳定运行。但 是，所造成的损失已经成定局。对于管理层而言，他们对于网络虚拟化的信任已经完全消失。因此，他们提议对网络进行全面更新；这时我开始参与项目。这个计划 是完全更换平台，逐渐减小组织对于共享物理基础架构的依赖。

这不是我第一次见证同类项目的发生。我已经看到过几个案例了，客户选择从虚拟化网络功能(VNF)退回到相对更为常规的网络设计。表面上，在分布式集群上运行VNF应该可以实现令人期盼的成本节约。然而，我发现它也一样会显著增加系统的复杂性，特别是在监控和管理方面。

不小心的话虚拟化系统就可能影响其他运营

所有虚拟化的核心都藏着一种妥协，用户只能减轻它的影响却无法完全消除它。虚拟化系统共享着物理资源，即使有资源保护、调度及其他“软”控制，虚拟化系统 仍然会对各自产生负面影响。在很多时候，它们并不会互相干扰，只要有恰当的系统管理，许多系统都可以共享相同的硬件。对于大多数最终用户而言，共享资源可 以减少运营成本。

服务器、网络和安全虚拟化技术都共享一个致命要害：每一个节点（交换机或虚拟实例）都有的软件系统。它可能是虚拟机管理程序、共享控制面板或集群协议。网络/服务器/安全等组件的运行依赖于这些服务。这本身没有问题，因为到达临界点之前它们都是完全可靠的。

要记住IT运营的两个不变事实：有Bug，也会有补丁（接下去就是人终究有死和必须交税）。如果运气好，问题的根源和影响都会被修复。硬件和软件供应商会 在后续的升级和自动恢复中改进产品，但是有时候这些过程不可避免地会出现错误。在上面的客户案例中，问题跟踪后发现是由于内存泄漏引起的——任何供应商都 可能（也确实）会有这样的问题。但是，一定上层作了决策，我们也不得不实施决议的计划。

让虚拟链路重新变成物理链路

迁移网络的短期影响是可以预见的：需要使用大量的铜线和机架将虚拟链路重新变成物理链路。除了这些大件的工程问题，还有许多并行流程可用于零碎部件。在完 成更换之后，由于“技术水平发展”，基础架构的总容量实际上会比以前增加了。然而，由于有更多的处理器和接口，因此跟踪通过基础架构的流量会变得更加困 难。

在虚拟化环境中，一个集群通常等同于一个管理接口。在物理环境中，几十个不同的管理接口部署在一起会形成一种巨大的管理难题。虽然可以使用一些元素管理工 具来创建跨越物理基础架构的策略，但是它们还无法完全解决所有的管理问题。例如，对于管理员基于角色的访问控制作一点点小修改都会向80台设备发送请求。 为了解决这些模板型问题，使用自动化工具是理所当然的方法。然而，由于组织的管理层已经抛弃了像虚拟化这样的“成熟”技术，因此可以想像他们对于 NetOps风格的系统管理的态度（不会太好）。

同时，有一些小问题取代了用户的大问题；客户选择对抗100只小马，而不是一只小马。毫无疑问，这个公司在放弃网络虚拟化的好处之后是在逆流而上；但是在 这个案例中，可用性压倒（几乎）了所有其他的问题。人们其实没有必要害怕到放弃虚拟化，但是也需要一定的执著力。而且，人们必须要有一定的克制力，接受让 许多硬件和软件闲置的事实，然后骑着小马去迎接挑战。