实现跨云应用——基于DNS的负载均衡

“公有云可以作为传统IT资源的延展,能帮助客户应对不断变化的需求”——这是我们在向客户介绍公有云产品时经常说的一句话。我们来看一个具体的需求:

某客户有一个web站点,部署在自有的数据中心(on-premises),在某些未计划高峰时期(假设是促销季),现有数据中心的基础设施资源不足以支撑突增的访问量。在这种情况下,公有云如何帮助客户拓展本地数据中心的处理能力从而满足峰值业务需求?

这个嘛,easy,客户只要将现有的web站点迁移到公有云上可以啦,什么横向扩展、按需付费、冗余存储等一大堆“云特性”就都齐全了。轻松搞定客户需求。然后,客户问了这样一个问题:应用(Web站点)都迁移到公有云上去了,我们现有的数据中心咋不?关闭?闲置?这是我们赖以生存的核心应用,都“飘在云端”总感觉有些不踏实呀...

看起来本来顺理成章的故事变得充满变数,其实这种情况是完全合理的:

  • 因为迁移到公有云而废弃或者闲置现有的基础设施,而且还要做大规模的应用迁移(以及围绕应用迁移而产生的一系列工作量和成本),这对客户而言是无法接受的。使用云计算到底是省钱还是更费钱?是提升工作效率还是更折腾?
  • 因为法律、合规等因素,客户不可能将所有的应用和数据都搬到到公有云上。但是客户也的确存在使用公有云的需求。例如:医院不可能把所有的病人数据和诊疗数据都保存到公有云上,但是可以通过公有云来提供检查报告/检验结果查询或者是预约挂号服务;企业不会将财务数据保存在公有云上,但是可以通过公有云提供对账、报表或者查询服务。
  • 尽管公有云的安全与合规程度远高于某些客户自有的IT基础设施,但信任并非是短期内就可以建立起来的。就像我们完全有理由认为把钱存到银行也不是百分百安全一样——银行倒闭了咋办?

针对上述问题,我们可以使用“DNS负载均衡”来解决!

现在的DNS服务也不再是傻傻的只管将域名解析为IP地址了。很多提供域名相关服务的供应商都推出了智能DNS服务。与传统的DNS解析服务相比,智能DNS服务增加了以下功能:

  • DNS权重负载均衡:默认的DNS负载均衡是轮询,即DNS服务器会平均的将请求分发到每个A记录。这样虽然实现了最简单的负载均衡,但是用户无法控制负载分发策略。DNS权重负载均衡就是在默认的DNS负载均衡机制上加入了权重值,用户可以通过权重值来设置分发到每个节点(A记录)上的请求数量,以此实现“能者多劳”——处理能力强的节点多承载一些负载。
  • 来源智能解析:根据客户请求的来源(所在位置或者接入线路),返回对应的解析值(IP地址)。例如:用户将一个应用分别部署在中国和美国,在域名解析服务中给同一个域名设置2条不同的A记录,分别对应到中国和美国的应用地址(公网IP地址)。这样就能实现中国客户访问部署在中国的应用,外国客户访问部署在美国的应用,所有用户均使用相同的域名来访问应用。

国内外提供智能域名解析服务的厂商有:DNSPod,CloudXNS,万网,Akamai等。用户也可以选择使用F5的软件硬件混合方案搭建自己的智能DNS解析服务。

万网的来源智能解析

DNSPod的DNS权重设置

除了上述智能DNS解析服务,Microsoft Azure和AWS也提供了类似的服务。在Microsoft Azure中,智能DNS解析服务是Traffic Manager Profile,注意不是Traffic Manager。Traffic Manager只能支持部署在Windows Azure上的应用。而Traffice Manager Profile可以支持外部的endpoint,即:可以在Microsoft Azure和本地数据中心之间进行DNS负载均衡,支持性能,权重和优先级3中负载分发算法。

不过在endpoint区域选择中,是没有中国大陆的。部署在中国的大陆的应用只能选择东南亚或者东亚。

另外,Traffic Manager Profile目前只在国际版的Microsoft Azure上提供,中国版的Windows Azure只有Traffic Manager。

在AWS国际版上,Route 53即智能DNS解析服务,与Microsoft Azure的Traffic Manager Profile相比,Route 53的区域划分更细致,而且支持中国大陆(CN)。

借助DNS负载均衡,我们就可以轻松实现一个混合云应用部署方案,让客户切实体验到云的优势。

诚祝:新年快乐!2016腾云而跃,一帆风顺,万事如意!

时间: 2024-07-30 13:46:16

实现跨云应用——基于DNS的负载均衡的相关文章

实现基于DNS的负载均衡

转自:http://blog.sina.com.cn/s/blog_4e424e2101000c3g.html 如果你有一个很受欢迎的Web站点,你会发现当请求的连接数增加时,服务器的响应延时也会随之增加.虽然你可以增加RAM.升级处理器.使用更快的驱动器及总线,这在短期内会有一定的帮助,但最终会发现一台服务器无法完成需要的任务. 使用多台服务器平衡负载是一个不错的想法,你可以在你的服务器池中随意增加多台服务器来提高服务器的性能和增强网络的稳定性.如果你的服务器池中有多台服务器,当一台down机

基于Apache+Tomcat负载均衡的两种实现方法

Apache+Tomcat实现负载均衡的两种实现方法 如果我们将工作在不同平台的apache能够实现彼此间的高效通信,因此它需要一种底层机制来实现--叫做apr Apr的主要目的就是为了其能够让apache工作在不同的平台上,但在linux上安装apache的时候通常都是默认安装的 [[email protected] ~]#rpm -qi aprName                 :apr                                        Relocation

基于LVS实现负载均衡

LVS-NAT模型: 工作原理:将内部地址转化为Internets上可用的外部地址.NAT的工作原理是报文头(目标地址.源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的.由此,可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务. 实验环境:3台虚拟机,其中一台做Director Server配备2个网卡,另外2台是Real Server 操作步骤: 一:在Real Server上: 1:RIP1:# if

云计算设计模式(十七)——基于队列的负载均衡模式

云计算设计模式(十七)——基于队列的负载均衡模式 使用队列,作为一项任务,它调用才能顺利间歇重物,可能会以其他方式导致失败的服务或任务超时服务之间的缓冲区.这个模式可以帮助最小化峰中的可用性和响应需求为任务和服务的影响. 背景和问题 许多解决方案在云中涉及运行调用服务的任务.在这种环境下,如果一个服务进行间歇重物,它可能会导致性能或可靠性问题 一个服务可以是一个组件,它是相同的溶液作为利用它的任务的一部分,或者它可以是第三方服务提供访问经常使用的资源,如高速缓存或存储服务.如果相同的服务是由多个

使用nginx sticky实现基于cookie的负载均衡

在多台后台服务器的环境下,我们为了确保一个客户只和一台服务器通信,我们势必使用长连接.使用什么方式来实现这种连接呢,常见的有使用nginx自带的ip_hash来做,我想这绝对不是一个好的办法,如果前端是CDN,或者说一个局域网的客户同时访问服务器,导致出现服务器分配不均衡,以及不能保证每次访问都粘滞在同一台服务器.如果基于cookie会是一种什么情形,想想看, 每台电脑都会有不同的cookie,在保持长连接的同时还保证了服务器的压力均衡,nginx sticky值得推荐. 如果浏览器不支持coo

使用nginx sticky实现基于cookie的负载均衡【转】

在多台后台服务器的环境下,我们为了确保一个客户只和一台服务器通信,我们势必使用长连接.使用什么方式来实现这种连接呢,常见的有使用nginx自带的ip_hash来做,我想这绝对不是一个好的办法,如果前端是CDN,或者说一个局域网的客户同时访问服务器,导致出现服务器分配不均衡,以及不能保证每次访问都粘滞在同一台服务器.如果基于cookie会是一种什么情形,想想看, 每台电脑都会有不同的cookie,在保持长连接的同时还保证了服务器的压力均衡,nginx sticky值得推荐. 如果浏览器不支持coo

[转][网站、云服务与虚拟机]弄清负载均衡的机制

转自:http://blog.csdn.net/shaunfang/article/details/9091491 Azure为网站.云服务和虚拟机都提供了免费的负载均衡能力.关于负载均衡我们需要注意的一点就是它对Session的处理.一般来说,传统的负载均衡器有一种叫session粘滞(sticky)的机制,也就是会根据用户的session信息将用户请求转发到固定的一台机器上,这样,如果应用程序在服务器端存储session信息,那么用户与服务器交互就会顺畅,否则,就会发生用户session丢失

用haproxy结合keepalived实现基于LNMP的负载均衡和高可用

今天我们讲haproxy结合keepalived实现LNMP的负载均衡和高可用,现在的公司大部分都基于haproxy实现负载均衡.下面以一个事例去给大家详细讲解如何去实现: 一.用haproxy结合keepalived实现基于lnmp的负载均衡和高可用服务,要求: (1)实现动静分离,图片和css,js都分离到专门的静态服务器上 (2)只允许172.17网段用户访问 (3)对于动态请求,要求实现基于cookie的会话保持 整体架构如下: 1.实验前需要关闭防火墙和selinux,以及同步时间.

Nginx基于TCP的负载均衡的配置例子

原文:https://blog.csdn.net/bigtree_3721/article/details/72833955 nginx-1.9.0 已发布,该版本增加了 stream 模块用于一般的 TCP 代理和负载均衡. The ngx_stream_core_module module is available since version 1.9.0. This module is not built by default, it should be enabled with the -