由于混合云服务和容器的普及，现如今的数据中心网络比以往任何时候都更加难以被破解。但是如若遵循一条简单的路径，IT人员就可以成功。

在不太遥远的过去，数据中心内的流量转发其实很简单。一个IP地址能够与另一个IP地址互相通信。这些地址属于端点——裸机主机或虚拟机与其他裸机主机或虚拟机的通信。这些IP地址之间的路径被称为数据中心交换机的路由和桥接表中的条目。

如果一位工程师需要解决两个IP端点之间糟糕的性能或奇怪的行为，一个很好的出发点是通过查看这些表来了解构建两者之间的路径。等价多路径和多机架链路聚合增加了这个过程的复杂性，但总的来说，运营商们可以精确地找出任何给定的数据中心通信经过的确切路径。

几乎没有使端点之间的流量复杂化。网络地址转换，加密或隧道很少出现。这些类型的功能往往位于数据中心边缘，与可信边界外的设备进行通信。

彼时的数据中心网络是很简单的，因为需求也很简单。

现代数据中心

现代数据中心网络架构看起来有所不同，因为业务需求已经发生了改变。曾经相对简单的数据中心现在已然成为应用程序运行的统一基础架构平台。数据中心作为一个整体运行;其是应用程序交付的引擎。

越来越多的基础架构对开发人员及他们的应用程序而言是透明的。彻底的现代基础设施是开发人员在其之上部署应用程序的抽象。资源池是按需分配的，开发人员不必担心基础设施的问题。相反，基础设施只是工作。

现代数据中心还以分布式方式处理安全性，与动态的和拆除的工作负载相协调。不再需要通过中央物理防火墙来强制实施 安全策略。相反，构建一个中央安全策略，并且一款安全管理器将该策略的相关部分安装在受影响的主机、虚拟机或容器上。没有基础设施瓶颈阻塞点，也没有难懂的路由要求来实施这样的策略。

在一个较高的层面上，我们一直在描述私有云架构。以这种方式抽象的物理基础设施允许一个更简单的与公共云的合作。因此，混合云架构越来越受欢迎，其使得公众云工作负载具备了与私有云工作负载相同的安全性和连接性。

分层

随着混合云架构成为新常态，重要的是要注意这些趋势对数据中心网络的影响。数据中心不再像以前那样简单的是一个IP地址与另一个IP地址之间的通信了，当在出现故障时，路由和桥接表将协商离开。

提供现代数据中心灵活性的基础架构机制依赖于复杂的网络。推动这种复杂性是对工作负载隔离，实施服务策略和安全性的需要。因此，现代数据中心看起来更像一个层层的蛋糕，而不是大量的IP地址。

在我们的层级蛋糕的底部是底层网络。这个网络是所有其他网络服务的基础。这也是对网络工程师们而言最熟悉的网络。当他们进入他们的路由和桥接表时，他们就看到了底层网络——数据中心的基础。

然而，底层网络本身并不能提供混合云所需要的一切。一个日益增长的需求是隔离的，其被称为多租户。一个租户可以是一款应用程序，也可以是一个业务单位或一个客户。

一个租户的流量通过虚拟可扩展LAN(VXLAN)封装技术与其他租户的流量隔离。来自一个段的流量被封装在VXLAN分组中，在该包装器中通过网络交付并且在另一侧被解封装。 VXLAN是第二层——覆盖层，其在我们的基础底层之上。

其不仅提供流量的隔离，而且VXLAN还可以用于通过网络上的特定路径路由流量。假设数据中心需要通过特定的防火墙和负载均衡器转发流量。在现代网络中，防火墙和负载平衡器可能作为虚拟化网络功能而存在，可能存在于数据中心的任何地方。要将流量精确地路由到需要去的地方，VXLAN封装可用于将流量流从设备传输到设备，直到它们遍历了所有必需的设备。

在我们的叠加层和底层蛋糕中，防火墙规则形成了另一层。一个中央策略管理器主机插入防火墙规则。每个主机最终都有自己的一组规则，用于控制进出设备的转发。被称为微分段，这是一个确保可扩展数据中心的安全的实用方法。

增加了更多的网络复杂性的通配符是容器。容器集装箱式网络是一项新兴的技术，由命名空间、代理服务器和网络地址的转换使容器能够与彼此以及外部进行沟通工作，这是另一层。

数据中心操作运营人员们的麻烦

现代数据中心网络架构所带来的复杂性对于数据中心操作运营人员们而言是一个潜在的问题。大多数网络问题都与连接或性能有关。两个终端应该能够连接但却未能连接是一类问题。但两个终端连接之后不能按预期快速的实现通信则是一类不同的问题。

使用数据包走查方法(the packet walk method)来排除连接问题。从一个网络设备到另一个网络设备，遵循数据包到达其目的地所需的路径。当实际IP端点已知时，这是直接的。

在现代数据中心中，底层用于传输VXLAN或其他覆盖包。除此之外，我们添加防火墙规则，然后可能添加网络地址转换或代理服务;数据包走查方法变得更加困难和充满细微差别。为了诊断连接问题，数据中心操作运营人员们需要知道数据包的来源和目的地——包括容器，虚拟机或裸机主机，管理该数据包的防火墙策略，数据包封装和要遵循的服务链。

假设操作运营人员了解应用程序的流程，并且是在一家扁平化结构的IT企业中工作，这并不是那么糟糕。但是，这也并不容易。在桥接和路由表中查找介质访问控制和IP地址只是更精细的故障排除过程的一小部分。除此之外，现代基础设施通常是短暂的，操作运营人员们可以解决过去过的难题，但却无法重建。

性能挑战甚至更难诊断。管理既定通信的网络设备的绝对数量可能涉及一款虚拟操作系统、一个虚拟管理程序软交换、一个虚拟防火墙、机架顶部交换机、脊柱交换机，然后反向一直到另一端点。

当某些工作负载在公共云服务中时，问题将变得更加复杂。将基础设施或平台即服务放在其中意味着添加高延迟和额外的隧道到我们的故障排除过程。

业界的响应

我们被IP问题所困住了。由于我们坚持使用IP，同时需要额外的功能，覆盖层就在此发挥其作用了。覆盖层让我们能够引导和隔离流量，而且该功能很重要。借助该功能，我们可以将我们的基础设施作为资源池，随意添加和减少容量。这个问题成为管理我们添加到我们的环境中的网络复杂性的问题之一。

而网络行业已经通过几种方式来应对了这一挑战了。第一是接受。如果我们认可复杂性的存在，那么我们将提供工具，使我们能够发现或可视化网络上正在发生的事情。例如，思科为运营商们提供了增强的工具，以便在基于应用程序的基础设施平台上解决端到端连接问题。VMware公司最近收购了初创公司Arkin，Arkin公司提供了一款可视化的工具，将与防火墙策略以及VXLAN分段相关联的工作负载，在GUI中与自然语言搜索引擎配合使用。

有效的故障排除和可视化工具已然成为现代数据中心平台中越来越重要的优势。然而，一些人则反对通过创建避免覆盖的转发方案(如果可能的话)来对该复杂性作出反应。

例如，Romana.io开源项目依赖于分层IP寻址方案，结合基于主机的防火墙规则来创建分段和中央安全策略。开源项目Calico也是类似的。 Romana.io和Project Calico都很有趣，因为它们提供了转发方案，能够规模化扩展到大型数据中心，同时仍然能够处理安全和分段需求，而且在这一过程中不会进行覆盖。

也许最大的问题并不是如何处理网络的复杂性，而是关于所支持的解决方案。有一种想法是，自动化的应用将降低人工成本。作为一名在IT基础设施业界有着20年经验的老手，我并不认为这样。巨大的复杂性当然需要有很大的技术支持需求。当这方面的魔法消失时，企业组织不会希望像他们的供应商那样暂时搁置问题。他们会想要有专业人士准确的知道系统的相关问题，并做好准备修复。

本文作者：佚名

来源：51CTO