在不太遥远的过去，数据中心内的流量转发是简单的。一个IP地址将与另一个IP地址实现通讯。这些地址属于端点——裸金属主机或虚拟机与其他裸露的金属主机或虚拟机实现通讯。这些IP地址之间的路径被称为数据中心交换机，就像路由和桥接表中的入口。

如果某位工程师需要解决两个IP端点之间的性能低下或异常问题时，一种很好的办法就是观察两者之间的这些表单。等价多路径与多机架链路聚合为这一过程增加了复杂性，但总的来说，运行维护人员可以精确地找出任何指定的数据中心会话的路径。

多个端点之间的通讯流会有些复杂。网络地址转换，加密或打通是很少存在的。这些类型的功能往往位于数据中心的边缘，与可信边界外部的设备进行联系。

这个时代流行简单，是因为需求简单。

现代数据中心
由于商业需求的变化，现代数据中心网络架构已经变得不一样。曾经相对简单的数据中心，现在已成为运行的应用程序的统一的基础设施平台。数据中心作为一个整体运行；它是应用程序交付的引擎。

越来越多的基础设施面向开发者和他们的应用程序透明。某一完整意义上的现代基础设施应该是开发人员所部署应用程序的抽象。资源池按需分配，而开发者不必担心基础设施的问题。基础设施不仅只是运行那么简单。

现代数据中心还需要用分布式的办法处理安全问题，采取通过工作负载的创建和取消相结合的方式。不再需要通过某一集中的、物理防火墙来执行增强的安全策略。相反，某一集中的安全策略是结构化的，并且安全管理人员将有关的策略安装到受影响的主机、虚拟机或容器上。增强这样的策略没有基础设施检查的要求，也没有难懂的路由需求。

站在更高的视角上，我们一直在描述私有云架构。以这种方式分散物理基础设施使得与公有云的协同变得更加简便。因此，混合云架构越来越受欢迎，大家期待着公有云工作负载能像私有云工作负载那样拥有相同的安全性和连通性。

分层
随着混合云架构成为新的常态，最需要注意的是这些趋势对网络的影响。数据中心不再是简单的实现某一IP与另一IP的通讯，当遇到问题是使用路由和桥接表进行协调这么简单。

基础设施建设机制是借助复杂的网络赋予现代中心的灵活性。驱动这种复杂性的是工作负载的分离、服务策略增强以及安全性等需求。因此，现代数据中心看起来更像是一份多层蛋糕，而并非只是IP地址的海洋。

在我们多层蛋糕的底端是服务承载网络。这一网络是所有其他网络服务所需承载的基础。这也是广大网络工程师最为熟悉的网络。当他们仔细检查着自己的路由和桥接表，他们就会看到服务承载网络，也是数据中心的基础。

凭借服务承载网络本身，并不能满足混合云的所有需求。不断增长的需求是分离，主要针对多租户的情况。单一租户可能是某一应用程序，或者某一业务单元或某一客户。

某一租户的通信与其他租户的通信是通过虚拟可扩展局域网隔离（Virtual Extensible LAN，VXLAN）封装技术进行分离的。同一段通信是封装在某一VXLAN包中，以封装的形式在网络中传输，并在到达传输目的地后解除封装。VXLAN是一种二层覆盖方式，它位于服务承载网络的顶端。

它不仅提供分离的流量，VXLAN同时还可以用来在特定网络间进行流量的路由规划。让我们来讨论下，数据中心需要在特定的防火墙和负载均衡器间推送流量的问题吧。在现代网络中，防火墙和负载平衡器很可能以虚拟网络功能方式工作，可能集成在数据中心的任意地区。为了到达目的地而精确地规划，VXLAN封装还能够用来打通设备与设备之间的通信流，直到联通所有需要的设备。

防火墙规则在我们的覆盖和底层蛋糕中形成另外一层。*策略管理器为每一台主机插入防火墙策略。每个主机都会有自己的一套策略来管理和转发设备中的信息。这被称为微分段，这是一种在规模化数据中心环境下能够保证安全的可行办法。

容器是增加网络复杂性的又一通配符。容器网络是一项新兴的技术，由命名空间、代理服务器和网络地址转换所管理，使不同容器之间的通讯就像与外界一样容易进行，即使对方并不在相同网络层级上。

运维人员的麻烦

对于运行维护人员来说，伴随着数据中心网络架构而来的复杂性是一大潜在问题。大多数网络问题都涉及到连通性或网络性能。本应该连通的两个端点却因为某种问题无法实现，或者两个端点虽然是连通状态，但讯通性能远不如预期则是另外一类问题。

用数据包走查方法(the packet walk method)来解决连接问题。从某台网络设备到另一台网络设备，按照数据包达到目的地的路径实际发送数据。当实际的IP端点已知时，这一方法将直抵关键。

在现代数据中心领域，底层网络用来传输VXLAN或其他覆盖包。最重要的是，我们追加防火墙的策略，也许网络地址转换或代理服务，数据包走查方法变得更加困难，并解决细节问题。要诊断一个连通性问题，运维人员需要知道的数据包的源头和目的地，包括容器，虚拟机或裸金属主机、防火墙的策略管理、数据包、数据包封装以及所遵循的服务链条。

假设运维人员工作在某一扁平化的IT公司，并了解应用程序数据流，可以很大程度上避免问题。然而，这并不容易。在桥接和路由表中查找媒体访问控制和IP地址只是一个更为详细的故障排除过程的某一小部分。再加上，现代基础设施(中的工作流信息)往往是短暂的，运维人员可以解决过去发生的问题但却无法重建。

性能的挑战更加难以诊断。网络设备的数量，接触特定的会话可能涉及某一虚拟的操作系统、虚拟机管理程序的切换、虚拟防火墙、顶端机架交换机、主干交换机以及然后再反向排查通向另一端点的所有路径。

当某些工作负载位于公有云，事情会变得更加复杂。把基础设施或平台当作某项服务等于意味着增加高延迟和额外的通信贯通追加到我们的故障排除方程中。

业界的回应

我们被IP问题困住了。并且因为我们在IP被困住的同时需要额外的功能，我们停留在这里。覆盖给我们引导和分离通信的能力，这一功能非常重要。有了它，我们可以把自己的基础设施看作是只需要增加和降低容量的资源池。然后我们把它加入到环境中，成为我们解决网络复杂性问题的办法。

网络业界已经开始采取不同的方法来接受这一挑战。首先是接受。如果我们认同复杂性问题仍然存在，那么我们将提供工具，帮助我们能够发现或可视化网络上发生的问题。例如，思科在其应用程序为中心基础设施平台上为运维人员提供解决端到端的连通性问题的增强性工具。VMware最近完成了对Arkin的收购，这一可视化工具可将相关工作负载对应的防火墙策略和VXLAN分离，用图形化界面(Graphic User Interface，GUI)搭配自然语言搜索引擎的方式进行展示。

越来越多有效的故障排除和可视化工具的出现，有效地支撑了现代数据中心平台。然而，部分人士反对由创建转发方案所带来的复杂性，(他们认为)如果有可能，应尽力避免覆盖的发生。

例如，在Romana.io开源项目依赖于一个分层的IP寻址方案，结合基于主机的防火墙规则来创建分割以及中心安全策略。开源Project Calico与Romana.io原理接近。Romana.io Project Calico项目都致力于提供转发方案，面向大型数据中心同时还能兼顾处理安全和分离的需求，而在这一过程中他们不会进行覆盖。

也许最大的问题并不是关于如何处理网络的复杂性，而是关乎谁应该如何支持解决方案。有一种想法认为，自动化的应用将降低人工成本。作为一名从业20年的IT基础设施老司机，我并不同意这种看法。伴随着巨大的复杂性而来的是更加迫切的技术支持需求。当魔术不再有效时，公司并不想与他们的供应商那样暂时搁置问题。他们会希望有了解系统的专业人士能随时准备好解决发生的各类问题。

本文转自d1net（转载）