如何应对混合云网络的复杂性？

在经过一番艰苦努力的之后，我最终调试解决了一个非常棘手的混合云网络问题。

虚拟私有云（VPC）提供了一个包含免费虚拟机(VM)使用时间的培训项目，学生可以跟随一位现场讲师学习，而不需要花时间去安装产品。但是，大量的短暂存在亚马逊云服务(AWS)虚拟机使我的主控机很难保持对它们的可靠控制。它们可能无法访问我最喜欢的亚马逊简单队列服务(SQS)，使用几百个这种服务会控制我的Elastic Compute Cloud(EC2)费用支出。

和许多很好的混合云一样，VPC的私有地址空间已经通过AWS Direct Connect链接到我的数据中心，从而对外展现为单个内聚的网络。问题是，虽然数据中心内所有系统都可以看到SQS正常工作，但是在亚马逊EC2本身的虚拟机却无法看到。似乎并没有魔法般的虚拟机实例访问权限组合可以做到这一点，尽管可以肯定它们可以自动获得核心AWS服务的访问权限。

这个解决方案最终会包含路由功能。在解决这个问题，我突然发现了云管理中有一个新的网络复杂性问题。这个问题不仅存在于传统云网络中，也存在于现在所谓的混合加混合网络（Hybrid-Hybrid Networks, HHN）。

混合加混合网络（Hybrid-hybrid networks）指的是什么？

当前企业IT推崇的云应用主要是基础架构即服务(IaaS)。实际上，IT正在将数据中心内物理机架上的服务器迁移到云中的虚拟机上。当然，我们需要保证Exchange服务器仍然能够将授权请求转发回到本地的Active Directory，这样管理员才能使用AWS Direct Connect、Azure Virtual Network或其他技术创建持久链接。一旦完成了这一步，你就得到了一个纯粹的混合云。

但是，如果你是一些真实云服务的早期采用者，如存储、云数据库、队列、转码等，又会如何呢？如果是这样，那么即使你的所有服务器仍然在机架中，你也已经进入云了。例如，如果你知道数据库名称，但是不能访问它所在的主机，那么你只是其中一个用户。一旦你开始将一些使用云服务的服务器迁移到云中虚拟机上，你就会遇到一种前所未有的网络复杂性，从而制造出一些不同的东西：混合加混合云。

结果：网络增加了而非减少了

对于早期采用者，IaaS应该不需要动太多脑筋。你的业务已经使用了很多的云服务，将大量系统迁移到混合云和IaaS上，可以更好地分配服务和用户，从而提升服务交付质量。因此你只需要关注于最后的用户接口问题。同时，服务器与后台系统之间的繁重网络流量也会得到很大的改进。可是，这个结果并不一定会如期出现。更坏的是，我们喜欢使用的调试工具可能并不支持IaaS基础架构。（我在期盼着NetFlow的到来。）

云基础架构的不透明性意味着你不会连接到虚拟交换机，也不会检查访问控制列表(ACL)，而且你不会查看NetFlow或检查防火墙配置中的原始ACL。你看不懂配置面板的内容，里面有继承的JSON策略/角色块和其他一些复杂信息。解决方法是回归一下，回想以前初涉IT时候的场景。以前，高级管理员不会随便给你root权限，因此你必须想一些办法绕过这个问题。

首先，先记住因为所有来自同一个供应商的服务并一定位于同一个位置，否则网络复杂性也不会成为一个问题。当这些使用云服务的应用部署在机架上时，它们会使用服务的地理路由前端。无论数据中心在什么位置，这个服务都会生成最高效的路由。如果现在决定将一个服务器迁移到位于悉尼的一个虚拟机上，那么它可能会对运行在弗吉尼亚的服务性能产生影响。确实，这里仍有一个意想不到的云网络问题：你仍然必须用Visio画出服务的拓扑图。

其次，要使用手头已有的工具。你可能无法访问IaaS平台的VSwitch，但是IaaS服务器仍然有操作系统和NIC，而且你可以安装深度数据包检测传感器，从云服务器的角度观察流量。

最后，你仍然在数据中心内保留VPC分界点的总体可见性，而且你想象不到的是，你会发现问题就出现在这个位置。

固化路由的一个特殊方法 在我的HHN中，我添加一些特殊的虚拟机实例角色限制，保护网络安全性不受学生虚拟机的影响。也就是说，我将所有流量转发回数据中心，然后我在这里通过信任的Palo Alto防火墙管理外出的互联网请求。这通常不会成为一个问题，但是我还将AWS服务调用限制在数据中心一个特定子网中。防火墙会接收到来自这些服务的大量请求，但是它们却来自于AWS VPC空间中一些不可信的新私有子网。防火墙会执行它的本职功能——阻挡流量。在EC2仪表析出现红色警报之后，解决方法实际上是很简单的。

在将虚拟机迁移到云的过程中，只需要记住关键点并不是考虑基础架构。这里仍然有许多规划和故障修复要做。固定的网络和旧式检测方法比以前更加重要，特别是在我们进入混合加混合加混合网络之后。这个问题会在我们实现IPv6之前到来。