使用VMware NSX从硬件提升网络性能存在一些问题，即哪个团队应该在发生网络故障时介入其中。

技术进步可以扰乱它们的实现和IT行业的采纳方式。

就拿服务器虚拟化举例吧。虚拟服务器带有虚拟交换机，使“烟囱式服务器”管理员处理网络或与其相关的事情时很不爽。对于坚持服务器、存储和网络团队三种竖井模型的企业来说，服务器虚拟化迫使服务器与网络工程师不得不商议一个新的界定标准。物理网络并未发生多大改变，但所有虚拟的东西（Cisco Nexus 1000 v除外）都成为服务器团队的职责范围。

存储也类似。虚拟机文件系统让存储抽象出来，存储管理员完全丢失了他们支持的工作负载的踪迹。SAN团队不会参与部署每一台新服务器，服务器虚拟化看到虚拟机实例出现，而不给存储工程师提供反馈。

在这两种情况下，VMware vCenter Server为管理虚拟化服务器和抽象存储提供了一致性的环境。因为服务模式是集中服务，服务器团队自然承担了责任。

当虚拟化是服务几种，服务器团队想当然成为该技术的拥有者。团队之间有清晰的划分———网络团队提供VLAN(虚拟局域网)，存储团队提供LUN(逻辑单元号)。前提是企业只允许有MBA学位的人来掌控。

NSX提出难题

当虚拟化成为网络中心时会发生什么?如果没有虚拟化x86服务器，我们该虚拟化网络吗?提及VMware NSX平台时，企业的水就给搅浑了。

当你拥有核心技术硬件，就要承担责任。但存在一个问题：在NSX中实现网络虚拟化是以网络为中心的，并非由服务器驱动。你无需将NSX加载到已有的交换机基础架构上，而是建立在现有vSphere部署之上。所以管理虚拟网络，你必须记住三件事：

基于角色的访问控制(RBAC)是一把双刃剑

你可能想通过实施RBAC，将运维职责划分为两个或以上的同等部分，以此解决服务器与网络之间的争论。VMware NSX促进这种配置，内置角色从只读审计师到拥有至高权限的企业管理者。但请注意：狭隘来说，NSX在管理访问过程中，可能最后加强服务器与网络的冲突，而不是采用矩阵型，或混合的操作方法。记住，支持现代基础架构的技术在发生变化，所以你的工程师团队也应该发生转变。

让团队进行故障诊断和操作培训，而不是简单地在组织结构图使用使用RBAC覆盖。不仅可以确保运营问题在物理或虚拟网络得到快速解决，而且在与NSX合作时你会给团队一个通用词汇表。

以全新的高度看待网络问题

我不会讲一个冗长可笑的IT问题将其归咎于“网络”。

但我将会时刻提醒你为什么我们喜欢指责网络：因为在如今的基础设施中，网络是大家都有的。我们很随意地使用网络术语，它可能代表着几乎任何东西，从断开的电缆到网关协议列表。

VMware NSX，类似其他覆盖解决方案，在物理网络上增加了虚拟化网络层。这项技术听起来不怎么样，但对运营团队来说，网络覆盖的影响有价值的，尤其是诊断与故障排除。一旦网络工程师的工具失去覆盖网络的可见性，传统故障诊断方法的开放系统会发生冲突。NSX工程师的故障排除可能阻碍低能见度及底层实体网络基础设施的健康。

最糟糕的情况是：物理网络团队和虚拟网络团队相互指责：“我们的网络是完好的，一定是他们的网络出现问题。”

通过部署一个完善的监控产品检查物理网络和虚拟网络的健康，可以避免这种情况的发生。如果选择Cisco或VMware销售的产品，或选择第三方厂商作为客观性能和健康信息的来源，就会获得效益。除了消除指责，这样做会聚焦于工程师解决问题根源的事件。

了解你的问题

很容易认可NSX，但请务必注意最初购买的原因。也许你想要改善的安全问题处于网络的复杂地带，也许你想应用期待已久的vSphere网络，或者你想更侧重于赋予虚拟化工程师控制配置网络、防火墙和政策的权利，尽可能快速而方便地配置虚拟机。

简单来说，你可以很容易地判定在NSX的成功实现和操作方面，哪个团队能取得最大利益，它就应该负责运作。