云ADC公私皆宜 应用交付控制器云中架构

　　应用交付控制器(ADC)如何在架构方面更好地适应云计算?是公有云提供商还是用户自身应该对云中ADC行使控制权?本文为你提供了中肯的建议。

　　应用交付控制器(ADC)对于数据中心的流畅运行十分关键，它提供了包括服务器负载平衡、监控服务器和应用健康、保护数据中心免遭分布式拒绝服务(DDOS)攻击、执行SSL加解密等关键功能。通过管理连接、运行专用应用脚本和提升应用速度，应用交付控制器可提高服务器运行效率。ADC就如同粘合剂一样，将数据中心网络和应用层粘合在一起。

　　即便应用转向公有云，它们仍然需要使用ADC所提供的所有服务。如果在转向公有云时不使用关键的ADC功能，应用和服务将处于风险之中。以下叙述基于这样的情况：在使用混合云解决方案时，应用的一部分位于云上，另一部分则位于企业数据中心上。

　　二层架构各有所长

　　在公有云上，ADC的最佳架构是双层结构，ADC的功能大致被分为两个层此。第一层由公有云提供商提供，负责处理服务器负载平衡(SLB)，将不同的客户流量定向至运行应用的虚拟服务器群上。

　　这是一个基本的SLB功能，它并没有根据服务器负载和延时等因素对定向流量进行进一步细化。云服务提供商的ADC仅是将流量转向至支持应用的虚拟机群上。云提供商的ADC是抵御攻击者的第一道防线，同时，这一层的ADC还负责执行SSL加解密功能。

　　除了提供认证服务外，ADC还能够对流量进行压缩或解压缩，但是这需要与客户进行协调。由于第一层的ADC保护云数据中心免遭攻击，因此常常被称之为"看门狗"ADC。同时由于它监视着整个云网络，因此也被称为网络ADC。

　　硬件解决方案是第一层ADC的最佳方案，因为这层ADC需要最高的性能以处理大流量负载。SSL处理在专门的硬件中能够被很好地执行，而只有硬件ADC才能胜任这一任务。在ADC发展初期，SSL处理是在软件中进行的，但是业内很快就发现随着流量的增加，软件解决方案无法跟上发展步伐，同时延时程度也变得无法接受。此外，硬件解决方案具有足够的实力，来击退大型DDoS攻击，并执行看门狗功能。

　　第一层ADC不执行其它的ADC的功能存在着多个原因。其中，性能是最主要的因素。看门狗ADC需要集中性能以定向流量、执行SSL，应对应用攻击。运行单个客户的脚本等额外功能，会导致ADC速度下降，并且会占用原本用于执行看门狗功能的性能。对不同客户脚本间的相互作用的顾虑也是一个因素。运行客户脚本将导致变化控制和问题处置复杂化。此外，将不同的客户目标缓存在相同的ADC上将产生安全漏洞。出于这些原因，第一层ADC应当将性能集中在几个关键应用上，将客户的具体任务留至下一层进行处理。

　　第二层ADC也被称为租户ADC，它位于特定客户的虚拟机和应用前端。所有客户的应用既可以共有一个ADC，每个应用也可以单独有一个ADC。第二层ADC主要负责执行具体的SLB功能，负责根据实时反应时间和负载等情况为单个虚拟机提供负载平衡，还向企业反馈服务器的健康信息。在执行诸如目标缓存和服务器卸载等应用加速功能的同时，第二层ADC还负责运行应用特定脚本。同时，它也是抵御攻击的第二条防线。

　　一个ADC仅负责一个客户或一个应用，在执行上述功能时具有一些优势。其中最大的优势在于可以让客户控制ADC。企业能够控制脚本升级的时机，如果当中出现问题，企业能够迅速进行补救。第二层ADC还可将客户或应用相互隔离起来。在ADC失效的情况下(例如，当应用被迁移至其他的云提供商那里，所有的缓存信息消失时)，其可提供更高的安全性，。

　　企业可能希望第二层ADC能够与他们数据中心的ADC匹配。其实，第一层的ADC的品牌是否和企业自己使用的ADC品牌相同并不重要。原因在于，第一层ADC对于企业来说是透明的，并且仅仅执行一些通用功能。第二层ADC则不同，其品牌最好与企业使用的ADC品牌相同，因为这样可以简化整合和运行工作，同时脚本能够从企业数据中心的ADC无缝地流向云。尽管企业使用的ADC品牌与第二层ADC品牌是否相同并不是必须的，但是保持品牌的一致性还是一个值得考虑的问题。

　　第二层ADC的控制权之争

　　云提供商已经开始在他们的服务列表中将第二层ADC作为一种额外的服务选项。客户可选择包括：在单独的服务器或者虚拟分区的服务器上运行软件ADC，专门的硬件ADC，或是在硬件上ADC隔离出来的分区。目前，专门的硬件ADC仅有为数不多的几个厂商可提供，因为准备不同品牌的ADC将使得云提供商的运营复杂化，同时费用也非常昂贵。

　　目前日益普及的选择是使用在服务器上运行的软件ADC。这一选择允许云提供商在性能和厂商品牌方面提供更多的可能。目前提供这一虚拟化选项的主要ADC厂商包括A10、Array、思杰、Coyote Point、F5、Kemp、Radware，以及通过收购Zeus 加入这一市场的Riverbed。博科也计划在2012年上半年推出其软件ADC产品。

　　目前在第二层ADC上使用软件ADC并不存在重大缺陷。因为在第二层ADC所负责的任务并不涉及重大性能问题。所有的ADC厂商都声称性能不是问题，同时所有的证据也表示这似乎是可信的。

　　目前还不清楚云提供商是否将提供丰富的ADC解决方案品牌。他们很可能仅提供一些受市场青睐的厂商的解决方案。此外，目前也不清楚他们将允许在第二层ADC上向企业提供多大程度的定制，以及他们将向企业转交多少ADC控制权。

　　对选项和控制权进行限制的问题将催生出另一个选项--"带来你自己的"(Bring Your Own) ADC选项。企业将他们在自己数据中心上使用的软件版ADC作为一个应用迁移到公有云的虚拟机上。这一选项可让企业彻底地控制第二层ADC，同时允许企业让云ADC适应由众多ADC厂商提供的全球负载平衡功能，以及部署他们已有的定制服务。目前的主要问题是企业如何让自己的ADC适应公有云提供商的基础设施。

　　尽管云提供商可能更喜欢客户选择他们服务列表中的选项，但是他们也会通过克服技术配置问题允许客户"带来自己的"ADC。在签署协议前，应当确认云提供商允许客户带来多少"自己的ADC"。

　　在选择第二层ADC时应当参考以下几个标准。首先，在为你的数据中心选择一个ADC时应当全面考虑这些标准。不要想当然地以为软件ADC与硬件ADC有着相同的功能。尽管确实许多软件ADC与硬件ADC不相上下，但是这一点并无法保证。此外，ADC的性能应当容易扩展。许多软件ADC在性能上低于它们的硬件版本，在使用云时应当考虑到吞吐量的影响。如果不清楚所需要的吞吐量，那么应当寻找能够很容易扩展为更大吞吐量的解决方案，并了解成本与吞吐量间的关系。

　　云中ADC "公""私"皆宜

　　选择公有云提供商的一个标准是，应当清楚他们部署ADC架构的情况，以及能否很容易地与企业自身的ADC需求整合在一起。ADC并不是"可有可无"的，而是支持企业应用的关键因素。

　　针对公有云的ADC架构基础知识同样适用于私有云，尤其是大型数据中心。双层解决方案为数据中心扩展提供了更高的灵活性。将每个应用脚本隔离在专用的ADC中，可以让确定问题根源所在和升级变得更加容易。对于公有云和私有云来说，双层解决方案代表着ADC架构的未来发展趋势。