幕雪

haproxy配置详解核心要素、步骤与常见配置示例


【haproxy配置】是什么？

HAProxy配置，简单来说，就是一份文本文件，它包含了所有指令和参数，告诉HAProxy软件如何监听网络请求、如何将这些请求转发到后端的服务器集群、如何处理服务器故障、如何优化性能以及如何应用安全策略。这份配置是HAProxy工作的“大脑”和“蓝图”。

它定义了几个核心部分：

  • 全局设置 (global): 影响HAProxy进程整体的行为，比如用户和组、最大连接数、守护进程模式、日志配置等。
  • 默认设置 (defaults): 为后续定义的frontend、backend或listen部分提供默认参数，避免重复设置。可以有多个defaults块。
  • 监听器 (frontend 或 listen): 定义HAProxy监听的网络地址（IP:端口）和协议（TCP/HTTP），并接收传入的连接请求。Frontend用于HTTP/HTTPS等需要应用ACL规则的场景，listen则更通用，可以处理TCP或简单的HTTP转发。
  • 后端服务器集合 (backend): 定义一组真实的服务器（如Web服务器、应用服务器、数据库），HAProxy会将接收到的请求按照负载均衡算法转发到这些服务器上。它也包含健康检查、会话保持等设置。

【haproxy配置】为什么重要？

配置是HAProxy发挥其核心功能的唯一途径。没有正确的配置，HAProxy无法理解如何处理流量。配置的重要性体现在：

  • 实现负载均衡： 配置定义了使用哪种算法（如轮询、最少连接、IP哈希）将请求分发到多台服务器，这是HAProxy最基本的功能。
  • 提供高可用性： 配置中的健康检查机制允许HAProxy自动检测后端服务器的健康状况，并将故障服务器从服务中移除，确保流量只发送到健康的服务器上，从而提高服务的可用性。
  • 优化性能： 通过配置TCP/HTTP参数、连接池、缓存等，可以减少延迟、提高吞吐量。配置SSL卸载也能减轻后端服务器的负担。
  • 增强安全性： 配置ACLs（访问控制列表）可以根据请求的各种属性（如源IP、路径、Header）进行过滤、阻止或重定向，实现基本的访问控制和安全策略。
  • 实现复杂的路由和转发： 利用ACLs和条件语句，可以根据请求的特性将流量导向不同的后端服务器集合，实现基于内容的路由、多租户隔离等复杂场景。
  • 提供监控和日志： 配置日志输出和统计接口，便于监控流量、性能以及进行故障排查。

总而言之，详细且准确的配置是保证应用服务稳定、高效、安全运行的关键。

【haproxy配置】在哪里？

HAProxy的主要配置文件通常位于特定路径，但具体位置可能因操作系统和安装方式的不同而略有差异：

  • 默认位置： 在大多数基于Debian/Ubuntu或Red Hat/CentOS的Linux发行版中，HAProxy的主配置文件通常位于：

    /etc/haproxy/haproxy.cfg

  • 其他文件： 大型或复杂的配置可能会被分解成多个文件，然后使用 `include` 指令在主配置文件中引用。这些文件通常放在 `/etc/haproxy/conf.d/` 或类似目录下。
  • 日志文件： HAProxy的日志输出位置由配置文件中的 `log` 参数决定，常见配置是发送到syslog，syslog的日志文件位置通常在 `/var/log/syslog`、`/var/log/messages` 或 `/var/log/daemon.log`，具体取决于syslog的配置。
  • 统计页面： 如果在配置中启用了统计（stats）页面，它将通过HAProxy自身监听的一个地址和端口提供，例如在配置中指定 `stats enable` 和 `stats uri /haproxy?stats` 后，可以通过 `http://haproxy_ip:stats_port/haproxy?stats` 访问。

当需要修改配置时，你需要编辑位于 `/etc/haproxy/haproxy.cfg` 或其引用的其他文件。

【haproxy配置】需要多少成本？

HAProxy本身的核心配置和软件是完全免费且开源的，遵循GPLv2许可协议。这意味着你可以自由地下载、安装、使用和修改HAProxy，无需支付软件授权费用。

然而，成本可能产生于以下方面：

  • 硬件/云资源成本： 运行HAProxy需要服务器资源（CPU、内存、网络流量），这会产生硬件购置或云服务（如AWS EC2, Google Cloud GCE,阿里云ECS等）的使用费用。
  • 维护和管理成本： 配置、部署、监控和维护HAProxy需要具备相应的技术知识和人力投入。
  • HAProxy Enterprise： HAProxy Technologies公司提供一个商业版本 HAProxy Enterprise，它在开源版本的基础上增加了企业级特性（如高级模块、集中管理、专业支持等）。使用这个版本需要支付相应的许可费用。但对于许多标准负载均衡需求，开源版本的配置功能已经足够强大。

因此，单就“HAProxy配置”这项工作而言，其本身并没有直接的财务成本，主要成本在于承载HAProxy运行的环境和维护人员的劳动。

【haproxy配置】如何编写和加载？

编写和加载HAProxy配置是一个相对标准化的流程：

  1. 编写配置：

    • 使用任何文本编辑器打开配置文件，例如 `nano /etc/haproxy/haproxy.cfg` 或 `vim /etc/haproxy/haproxy.cfg`。
    • 配置文件的语法是指令-参数对，通常每行一个指令。以 `#` 开头是注释。
    • 配置主要由 `global`、`defaults`、`frontend`/`listen`、`backend` 这几个块组成。每个块内部包含针对该块的特定指令。
    • 指令和参数众多，需要查阅HAProxy官方文档以了解它们的具体用途和语法。
  2. 检查配置语法：

    • 在加载新配置之前，务必检查其语法是否正确，避免服务启动失败。
    • 使用命令 `haproxy -c -f /etc/haproxy/haproxy.cfg` 来检查。
    • 如果语法正确，会输出 “Configuration file is valid”。如果存在错误，会指示错误所在的行号和类型。
  3. 加载配置：

    • 加载配置有两种主要方式：重启和热加载（reload）。
      • 重启 (Restart): 停止HAProxy进程，然后启动新进程加载新配置。这会导致现有连接中断。适用于配置了全局参数或defaults参数的修改，或者只是测试阶段。命令通常是 `sudo systemctl restart haproxy`。
      • 热加载 (Reload): HAProxy启动一个新的进程加载新配置，然后平滑地将流量切换到新进程，同时等待旧进程处理完现有连接后退出。这是生产环境中推荐的方式，不会中断用户连接。适用于修改了frontend或backend等不影响全局行为的参数。命令通常是 `sudo systemctl reload haproxy`。
    • 根据你的操作系统和HAProxy的安装方式，也可能使用 `service haproxy restart` 或 `service haproxy reload` 命令。

记住，先检查语法 (`-c`)，再根据修改内容选择重启 (`restart`) 或热加载 (`reload`) 是安全高效的配置更新流程。

【haproxy配置】常见怎么配置？

HAProxy配置的灵活性很高，可以应对各种复杂的场景。以下是一些最常见的配置示例和概念：

基本的HTTP负载均衡

这是最基础的配置，监听一个端口，将HTTP请求分发到后端的Web服务器集群。

global
    log 127.0.0.1 local0 notice
    maxconn 4096

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server webserver1 192.168.1.10:80 check
    server webserver2 192.168.1.11:80 check

  • `global`: 配置日志发送到本地syslog。
  • `defaults`: 设置默认模式为HTTP，启用HTTP日志，设置连接、客户端、服务器超时时间。
  • `frontend http_front`: 监听所有网络接口的80端口。
  • `default_backend http_back`: 所有到达此前端的请求都转发到名为 `http_back` 的后端。
  • `backend http_back`: 定义后端服务器集群。
  • `balance roundrobin`: 使用轮询算法分发请求。
  • `server webserver1 … check`: 定义一个后端服务器，指定其名称、IP和端口，并启用健康检查 (`check`)。

TCP负载均衡（例如数据库或SSH）

将流量直接在TCP层转发，不检查HTTP内容。

listen mysql_cluster
    bind *:3306
    mode tcp
    balance leastconn
    server db1 192.168.1.20:3306 check port 3306
    server db2 192.168.1.21:3306 check port 3306

  • `listen mysql_cluster`: 使用listen块简化配置，同时定义前端和后端。
  • `bind *:3306`: 监听3306端口。
  • `mode tcp`: 指定工作在TCP模式。
  • `balance leastconn`: 使用最少连接算法。
  • `server … check port 3306`: 对后端服务器进行TCP端口健康检查。

配置健康检查

确保流量只发送到健康可用的服务器。`check` 参数启用默认的TCP健康检查。可以进行更详细的配置：

backend app_servers
    balance roundrobin
    server srv1 192.168.1.30:80 check
    server srv2 192.168.1.31:80 check inter 2000 rise 2 fall 3

backend http_app_servers
    balance roundrobin
    mode http
    option httpchk GET /healthz
    server srv3 192.168.1.32:80 check
    server srv4 192.168.1.33:80 check

  • `check inter 2000 rise 2 fall 3`: 指定健康检查间隔（2000ms），连续成功2次认为UP，连续失败3次认为DOWN。
  • `option httpchk GET /healthz`: 在HTTP模式下，执行GET请求到`/healthz`路径来判断服务器健康状况（期望返回2xx或3xx状态码）。

配置会话保持 (Session Persistence)

确保同一用户的请求总是被发送到同一台后端服务器。

backend sticky_app
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server srvA 192.168.1.40:80 cookie A check
    server srvB 192.168.1.41:80 cookie B check

  • `cookie SERVERID insert indirect nocache`: HAProxy会在响应中插入名为SERVERID的cookie，其值是后端服务器的cookie参数定义的值（A或B）。后续请求带着这个cookie时，HAProxy会将其路由回对应的服务器。`insert` 表示由HAProxy插入cookie，`indirect` 表示只有HAProxy生成的cookie才会用于stickiness，`nocache` 防止客户端或代理缓存响应。
  • `server … cookie A`: 为这个服务器定义一个cookie值。

其他会话保持方法包括 `appsession` (基于应用生成的cookie/参数) 和 `source` (基于客户端源IP)。

配置ACLs (Access Control Lists) 和条件转发

根据请求的各种属性进行灵活的路由和控制。

frontend http_in
    bind *:80

    # Define ACLs
    acl is_mobile hdr(User-Agent) -i mobile
    acl is_admin_path path_beg /admin
    acl from_trusted_ip src 192.168.10.0/24

    # Use ACLs for routing
    use_backend admin_servers if is_admin_path from_trusted_ip
    use_backend mobile_servers if is_mobile
    default_backend default_web_servers

backend admin_servers
    server admin1 192.168.1.50:80 check

backend mobile_servers
    server mobile1 192.168.1.60:80 check
    server mobile2 192.168.1.61:80 check

backend default_web_servers
    server web1 192.168.1.70:80 check
    server web2 192.168.1.71:80 check

  • `acl `: 定义一个ACL规则。上面例子定义了基于User-Agent、路径前缀和源IP的ACL。
  • `use_backend if [AND ]`: 如果指定的ACL（或多个ACL组合）匹配，则将请求发送到对应的后端。
  • 请求会按照 `use_backend` 语句的顺序进行匹配，如果都不匹配，则使用 `default_backend`。

配置SSL/TLS终止 (SSL Offloading)

HAProxy接收加密的HTTPS请求，解密后将普通HTTP请求发送到后端服务器。

frontend https_front
    bind *:443 ssl crt /etc/ssl/private/mydomain.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend http_back

backend http_back
    mode http
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

  • `bind *:443 ssl crt /etc/ssl/private/mydomain.pem`: 监听443端口，启用SSL，并指定证书文件路径（PEM格式，包含私钥和证书链）。
  • `reqadd X-Forwarded-Proto:\ https`: 添加一个Header，告知后端服务器原始请求是HTTPS。

配置HTTP到HTTPS重定向

将所有HTTP请求强制重定向到HTTPS。

frontend http_in
    bind *:80
    redirect scheme https if !{ ssl_fc }

frontend https_in
    bind *:443 ssl crt /etc/ssl/private/mydomain.pem
    # … other HTTPS configs …
    default_backend my_app

  • `redirect scheme https if !{ ssl_fc }`: 如果前端连接不是SSL连接（`!{ ssl_fc }`是一个HAProxy内置的ACL），则重定向到相同的URL但使用HTTPS scheme。

这些只是HAProxy配置功能的冰山一角。还有许多高级配置选项，如速率限制、Caching、Header操作、日志格式定制、Runtime API等，都需要参考官方文档来详细学习和应用。编写高质量的HAProxy配置需要对TCP/IP、HTTP协议有一定理解，并耐心查阅文档进行调试。


haproxy配置