阿里云负载均衡高可用部署

阿里云负载均衡高可用部署

1、负载均衡产品高可用支持

当前,负载均衡支持如下特性来实现业务的高可用性。更多相关信息,请参阅负载均衡产品文档

  • 集群化部署

如下图所示,负载均衡系统中四层负载均衡(LVS)服务、七层负载均衡(Tengine)服务和控制系统等关键组件都采用集群化部署,以提高扩展性和可用性。

  • 多可用区部署

负载均衡支持多可用区部署,以实现同Region下的跨机房容灾。通过该特性可实现当整个机房故障时,负载均衡能在较短时间内,将前端访问流量切换到同一地域下的其它可用区,以恢复服务能力。

注:相应负载均衡实例在所对应主备可用区后端都必须部署了实例,才能保障负载均衡实例主备切换后业务不中断。

如下图所示,如果相应Region配置了负载均衡多可用区支持。那么在创建实例的时候,可以选择实例所需的主、备可用区。

  • 会话保持

负载均衡会话保持可以使来自同一客户端的相关访问请求,分发到后端同一台ECS上进行数据交互和处理,以保障同一会话交互的连续性。

针对7层(HTTP协议和HTTPS协议)服务,负载均衡系统是基于Cookie的会话保持。负载均衡系统提供了两种Cookie处理方式:

  • Cookie植入:表示直接由负载均衡系统来分配和管理对客户端进行的Cookie植入操作,用户在进行配置时需要指定会话保持的超时时间。
  • Cookie重写:表示负载均衡系统会根据用户自定义Cookie名称来分配和管理对客户端进行的Cookie植入操作,便于用户识别和区分自定义的Cookie名称,从而有选择的针对后端应用服务器上不同的应用设定会话保持规则;用户在进行配置时需要指定相应的Cookie名称。针对多个域名配置不同会话保持规则的实现方法点击这里查看。

各类协议的会话保持,均可根据实际需要选择开启或关闭。

经典网络实例的UDP协议暂不支持查看源地址。

  • 健康检查

负载均衡通过健康检查来避免后端ECS故障对负载均衡整体服务的影响。用户开启健康检查功能后,当后端某台ECS健康检查出现问题后,负载均衡会将新请求转发到其它健康检查正常的ECS上,而当该ECS恢复正常运行时,负载均衡会将新请求自动恢复到该ECS上,以提供负载均衡整体服务的可用性。

注:负载均衡后端必须至少配置2台及以上服务器,才能保障单台ECS异常时,前端请求能被分发到其它正常服务器上。

  • HTTPS协议支持

负载均衡支持创建HTTPS协议监听,以满足用户安全加密传输数据的需求,提高业务安全性和可用性。

负载均衡提供了对提供证书的集中管理和存储,并在前端请求时自动进行加解密处理。用户无需再将证书上传到后端ECS进行手工配置。用户上传到证书管理系统的私钥都会加密存储。

2、负载均衡高可用配置最佳实践

建议用户在负载均衡使用和配置过程中采用如下措施以提高负载均衡业务可用性:

  • 将负载均衡后端服务器部署在同一地域后端不同可用区内,然后结合负载均衡多可用区特性实现本地容灾
    :跨可用区访问会增加访问延迟,需要根据业务敏感性进行评估。
  • 开启负载均衡后端ECS的健康检查,以便实现负载均衡对异常ECS自动进行隔离或恢复。
  • 负载均衡后端最少配置2台及以上ECS。这样才能在其中某一台出现异常的时候,将前端访问调度到其它正常ECS,否则单台ECS故障,会导致负载均衡业务整体不可用。
  • 在业务层面配置自动重联机制,从而在访问请求落到异常的负载均衡后端ECS时,客户端能够自动重联,以便负载均衡将新的请求调度到正常ECS,进而提高业务可用性。
  • 业务层面超时时间必须在负载均衡当前各协议服务的超时时间之内,具体超时时间可参考:《负载均衡各监听连接超时设置是什么?》。

3、负载均衡高可用常见架构

负载均衡常见的高可用部署架构说明如下。

  • 本地容灾

负载均衡可以结合后端ECS及RDS、OSS等底层公共服务资源以实现业务的本地容灾。

方案优点:

  • 部署简单。
  • 低成本。
  • 同城容灾自动侦测、自动切换。
  • 容灾切换业务无感知.

方案缺点:

  • 无法解决异地容灾问题。

 

如上图所示,简要说明如下:

1)     负载均衡实例后端ECS同时分布在A、B可用区。

2)     创建负载均衡实例的时候选择多可用区支持,设置可用区A为主实例,可用区B为备实例。

3)     负载均衡后端ECS均为无状态ECS,业务数据存储在后端RDS、OSS等公共服务资源内。

4)     正常情况下,客户端请求被调度到主负载均衡,进而分发到后端A、B可用区内的所有ECS上。

5)     当系统侦测到可用区A因故障无法访问时,自动将客户端请求调度到可用区B上的负载均衡备份实例上。

6)     可用区B内的负载均衡和ECS继续为前端提供服务。

  • 异地容灾

负载均衡自身目前不支持异地容灾,需要结合外部智能DNS解析等手段来实现异地容灾。

用户在不同地域购买负载均衡实例(本身已配置本地容灾)后,将最终业务访问域名配置智能DNS解析。最终根据客户端地理位置、链路质量等因素将访问请求动态解析到不同区域的负载均衡实例上。

方案优点:

  • 异地容灾,实现更高业务可用性。
  • 容灾切换业务无感知。

方案缺点:

  • 更高的成本。
  • 需要结合外部应用联动。
  • 需要了解业务分布、访问源分布等业务属性后配置定制策略。

如上图所示,简要说明如下:

  •  DR(直连路由)模式

当前负载均衡调度策略只支持加权轮询和加权最小连接数两种模式,可以通过如下方式实现自定义的DR(直连路由)模式,以实现通过指定域名进行访问的流量最终落在后端指定ECS(或端口)上的效果。

方案优点:

  • 可按业务所需实现访问链路绑定。
  • 低成本。

方案缺点:

  • 配置复杂,维护复杂。

如上图所示,说明如下:

1)     用户将不同的域名解析到同一个负载均衡的公网地址,但设置不同A记录,比如:sitea.test.com和siteb.test.com 。

2)     在负载均衡后端绑定两台或多台安装了HAProxy软件的ECS用作访问代理。

3)     购买其它服务器用于最终业务承载并部署相应业务,并通过配置VirtualHost对不同域名的访问请求做相应处理。

4)     在前述HAProxy服务器上配置转发规则,分别将来自sitea.test.com和siteb.test.com的访问请求转发到后端指定服务器(或端口)。

  • 多级负载均衡

如果有部分业务只在内部访问而同时又需要避免单点(比如数据库访问代理等),则可以部署多级负载均衡。

方案优点:

  • 低成本。
  • 实现简单,业务逻辑清晰。
  • 更高的安全性:私网负载均衡对公无法访问,保护内部敏感应用。同时,还可在私网实例上设置访问控制白名单,进一步提高安全性。

方案缺点:

1)     多级转发会对性能有影响。

如上图所示,说明如下:

1)同时创建多个公网负载均衡实例和私网负载均衡实例。

2)公网负载均衡实例面向最终用户提供服务,私网负载均衡实例为后端服务提供高可用。

3)公网负载均衡实例后端ECS上,将后端服务的调用指向私网负载均衡实例。

Comments are closed.