DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开
DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开

应用交付控制器的云中架构

应用交付控制器(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架构的未来发展趋势。

未经允许不得转载:DOIT » 应用交付控制器的云中架构