分享

Neutron 系列 (11): Neutron 是如何实现负载均衡器虚拟化的【基础篇】

本帖最后由 eying 于 2016-1-13 17:02 编辑
问题导读:


1.负载均衡的概念是什么?
2.
High Availability Proxy是什么?










1. 基础知识


1.1 负载均衡的概念

  负载均衡(Load Balancing)是将来访的网络流量在运行相同应用的多个服务器之间进行分发的一种核心网络服务。它的功能由负载均衡器(load balancer)提供。负载均衡器可以是一个硬件设备,也可以由软件实现。它充当反向代理,在多个服务器之间分发网络或者应用流量。它常用来增加应用的访问容量(并发用户数)和可靠性,它也会通过降低服务器的负载来提高应用的总体性能。

1.png

(1)负载均衡器的分类

负载均衡器一般可以分为两类:第4层负载均衡器和第7层负载均衡器。

第 4 层负载平衡器:基于网络和传输层协议(IP,TCP,FTP,UDP等)来均衡负载。

3.png

第7层的负载均衡器:基于应用层协议比如 HTTP, SMTP, SNMP, FTP, Telnet 等均衡负载。比如对 HTTP 来说,第七层的负载均衡器能根据应用的特定数据比如 HTTP 头,cookies 或者应用消息中的数据来做进一步的请求分发。

4.png

(2)负载分发算法

两种类型的负载均衡器都能接收请求,然后根据特定的算法将请求分发到特定的服务器。一些行业标准的算法是:

  • 轮询 (Round robin):轮流分发到各个(活动)服务器
  • 加权轮循 (Weighted round robin):每个服务器有一定的加权(weight),轮询时考虑加权。
  • 最少连接 (Least connections):转发到有最少连接数的服务器
  • 最少响应时间 (Least response time):转发到响应时间最短的服务器

(3)可靠性和可用性

负载均衡器通过监控应用的健康状态来确保可靠性和可用性,并且只转发请求到能及时做出响应的服务和应用。

(4)Session persistence (会话保持)

会话保持表示在一个会话期间,转发一个用户的请求到同一个后端服务器。这对购物车或者付款类的请求非常重要。 常用的方法包括:

  • Source IP:相同来源的请求转发到同一个服务器
  • HTTP Cookie:该模式下,loadbalancer 为客户端的第一次连接生成 cookie,后续携带该 cookie 的请求会被某个 member 处理
  • APP Cookie:该模式下,依靠后端应用服务器生成的 cookie 决定被某个 member 处理

(5)常见的开源软件负载均衡器

  • HAProxy
  • Linux Virtual Servers (LVS) - 包括在许多Linux发行版中的简单快速的4层负载均衡软件
  • Nginx - 一个快速可靠的web服务器也能当作代理和负载均衡器使用。它常常和 HAProxy一起用于缓存和压缩。

1.2 High Availability Proxy(HAProxy)

    HAProxy 是个著名的开源的软件 TCP(四层)/HTTP(七层) 负载均衡器和代理(proxy)软件,可以运行在 Linux,Solaris 和 FreeBSD 等系统上。它最常用的用途是通过在多个服务器(比如 web服务器,应用,数据库等)之间分发负载来改善一个服务器系统的性能和可靠性。目前,它已经被许多大公司采用,包括GitHub, Imgur, Instagram, and Twitter 等。它类似 Nginx 的,采用了单进程和事件驱动模型;它使用的内存量低而且稳定,能够处理大量并发请求。这篇文章 讲述了怎样使用 HAProxy。

主要概念:

  • Frontend:定义请求如何被转发到 backend。
  • Backend:一组接收转发的请求的服务器。其定义包括分发算法和一组服务器的地址和端口。

支持的分发算法:

  • Round robin:平均的将网络流量分发到多个 member。
  • Source IP:从某一个特定 IP 发来的网络请求,总是发到特定的 member。
  • Least connections:将收到的网络请求,发给当前负载均衡池中连接数最少的 member。如果所有的 member 连接数一样,则遵循 Round robin 的方式。

一个 HAProxy + Keepalived 配置实例:

2.png

Health Check(健康检查):

    HAProxy 使用 Health Check 来确定一个 backend server 能不能接收转发的请求。这避免了在服务器不可用时需要手工删除它。默认的 Health Check 是试着去和一个server 建立一个 TCP 连接,比如,检查该 backend server 是否在配置的 IP 和 端口上监听。你可以指定 health check 方法,包括 tcp,http,ping 等。

    当一个 backend server 检查失败时,它就无法接受请求了,它就会自动被禁用,请求也不会被转发到该服务器上,直到它重新变为可用。如果一个 backend 内的所有服务器都 health check 失败,其对应的服务就会变得不可用。

配置文件:

HAProxy 的核心在于其配置文件(etc/haproxy/haproxy.cfg)。Neutron 的 LBaas 其实也就是生成了该配置文件,然后由 HAProxy 去执行。

[mw_shl_code=applescript,true]global #全局配置,基本不需要修改
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL).
        ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend localnodes #where HAProxy listens to connections
    bind *:80              #HAProxy 在所有网卡的 80 端口上监听 HTTP 请求
    mode http              #监听 HTTP 请求,这时它作为一个七层负载均衡器
    default_backend nodes  #所使用的后端服务器

backend nodes #Where HAPoxy sends incoming connections
    mode http          #转发 HTTP 包给后端服务器
    balance roundrobin #分发算法
    option forwardfor  #在 HTTP 头中添加 X-Forwarded-For 头,使得后端服务器可以获取原始请求的来源地址
    http-request set-header X-Forwarded-Port %[dst_port] #在 HTTP 头中添加 X-Forwarded-Port 头从而使得后端服务器可以知道原始的 HTTP Port
    http-request add-header X-Forwarded-Proto https if { ssl_fc } #在使用 SSL 时添加 X-Forwarded-Proto头
    option httpchk HEAD / HTTP/1.1\r\nHost:localhost #使用 health check 来检查后端服务器的可达性
    server web01 127.0.0.1:9000 check #后端服务器。”check“表示做 health check。
    server web02 127.0.0.1:9001 check
    server web03 127.0.0.1:9002 check

listen stats *:1936 #用于监控 HAProxy
    stats enable
    stats uri /
    stats hide-version
    stats auth someuser:password[/mw_shl_code]




相关内容:


neutron系列:Neutron 所实现的虚拟化网络(1)


neutron系列:Neutron 所实现的虚拟化网络(2)

neutron系列:使用 Open vSwitch + VLAN 组网(3)

neutron系列:使用 Open vSwitch + VLAN 组网(4)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网 (5)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网(6)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(7)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(9)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(10)

Neutron 系列 (11): Neutron 是如何实现负载均衡器虚拟化的【基础篇】

Neutron 系列 (12): Neutron 是如何实现负载均衡器虚拟化的【提高篇】

Neutron 系列 (13): Neutron 是如何实现虚机防火墙的 【上】

Neutron 系列 (14): Neutron 是如何实现虚机防火墙的 【下】

Neutron 系列 (15): OpenStack 是如何实现 Neutron 网络 和 Nova虚机 防火墙的

Neutron 系列(16):虚拟专用网(VPN)虚拟化

Neutron 系列 (17): Neutron 分布式虚拟路由【上】

Neutron 系列 (18): Neutron 分布式虚拟路由【下】

Neutron系列(19):Neutron L3 Agent HA 之 虚拟路由冗余协议(VRRP)【上】

Neutron系列(20):Neutron L3 Agent HA 之 虚拟路由冗余协议(VRRP)【下】

Neutron系列(21):OpenStack 高可用和灾备方案 [OpenStack HA and DR]【上】

Neutron系列(22):OpenStack 高可用和灾备方案 [OpenStack HA and DR]【下】








没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条