蚊章汇 - 负载均衡
type: channel
link: https://linuxcn.bwsl.wang/tag/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/
items: 利用 DNS SRV 记录为 Postfix 提供负载平衡
items: 负载均衡的初学者指南
items: 用 HAProxy 实现网络流量的负载平衡
items: 流量引导：网络世界的负载均衡解密
items: 在 Linux 上用 DNS 实现简单的负载均衡
items: 开发者定义的应用交付
items: 如何使用 Weave 以及 Docker 搭建 Nginx 反向代理/负载均衡服务器
items: 在 RHEL/CentOS 上为Web服务器架设 “XR”（Crossroads） 负载均衡器
items: 使用 HAProxy 配置 HTTP 负载均衡器

利用 DNS SRV 记录为 Postfix 提供负载平衡
type: item
date: 2023-12-16T01:36:01+08:00
description: 2011 年 3 月，苹果公司提出 RFC 6186，描述了如何利用域名系统服务（DNS SRV）记录来查找电子邮件的提交以及访问服务。现在 Postfix 从 3.8.0 版本开始支持 RFC 中提出的设计。这个新增功能让你可以使用 DNS SRV 记录进行负载分配和自动配置。DNS SRV 记录的形态DNS SRV 记录定义在 RFC 2782 中，它指定在区域文件中，并且包含了服务名称、传输协议规范、优先级、权重、端口，以及提供该服务的主机。_submission._tcp SRV 5 10 50 bruce.my-domain.com. 字段值意义服务名称submission服务名为 submission传输协议规范tcp本服务使用 TCP 协议优先级5服务器优先级设为 5（数值越小，优先级越高）权重10服务器应承担的负载部分端口50服务器监听连接的端口目标bruce.my-domain.com.提供此服务的服务器名称记录解释服务器选择算法客户端应该按照 RFC 2782 中描述的方式解析 SRV 记录。这意味着，首先尝试联系拥有最高优先级（最小的优先级数字）的服务器。如果该服务器无回应，那么重试联系拥有同样或者更低优先级的下一台服务器。当有多台服务器拥有同样优先级的时候，应随机选择其中一台，但是必须确保选择记录的概率符合下列公式：其中 i 是 SRV 记录的标识，k 是具有相同优先级的 SRV 记录的数量。在现实中，这意味着如果你有两台服务器，其中一台的处理能力是另一台的三倍，那么你应该给第一台服务器的权重赋于另一台三倍的值。这样就能保证更强大的服务器会接收到大约 75% 的客户端请求，而另一台接收大约 25% 的请求。这些原则使得 SRV 记录能够同时作为客户端自动配置及在服务器之间分配工作负载的工具。看看以下这个记录的例子：_submission._tcp SRV 0 0 2525 server-one _submission._tcp SRV 1 75 2625 server-two _submission._tcp SRV 1 25 2625 server-three 这里 server-one 总是会被首选来进行联系。如果 server-one 无回应，客户端就会将剩下优先级为 1 的两个记录顺序打乱，生成一个从 0 到 100 的随机数，如果第一条记录的运行总和大于或者等于这个随机数，它就会尝试去联系这个记录。否则，客户端会倒序联系所有服务器。注意，客户端会向它优先成功连接的服务器发送请求。示例配置请考虑以下这种情况。你想为大量的电脑配置 Postfix，使其通过公司的邮件服务器利用 SRV 记录转发外部电邮。为了达到这个目标，你需要在每台电脑的 Postfix 中配置 relayhost 参数，即邮件用户代理（MUA）。如果将 relayhost 参数的值设置为 $mydomain，你的机器将开始为你的域名查找 MX 记录，并尝试按照它们的优先级顺序发送邮件。这种方法虽然有效，但是可能会遇到负载平衡问题。Postfix 会使用优先级最高的服务器，直到其变为无响应才会联系其他备用服务器。此外，如果你在环境中使用了动态分配的端口，你无法指明哪个端口正在被特定的服务器使用。使用 SRV 记录，你可以应对这些挑战，并在需要改变服务器端口的时候维持服务器的平滑运行。区域文件为了使得 DNS 服务器提供信息给客户端，可以参考以下使用服务器 server-one、server-two、server-three 作为中继，并把服务器 server-four 配置为接收测试邮件的区域文件示例。$TTL 3600 @ IN SOA example-domain.com. root.example-domain.com. ( 1571655122 ; 区域文件的序列号 1200 ; 刷新时间 180 ; 发生问题时的重试时间 1209600 ; 过期时间 10800 ) ; 查询失败时的最大缓存时间 ; IN NS ns1 IN A 192.168.2.0 ; ns1 IN A 192.168.2.2 server-one IN A 192.168.2.4 server-two IN A 192.168.2.5 server-three IN A 192.168.2.6 server-four IN A 192.168.2.7 _submission._tcp SRV 0 0 2525 server-one _submission._tcp SRV 1 50 2625 server-two _submission._tcp SRV 1 50 2625 server-three @ MX 0 server-four Postf…

负载均衡的初学者指南
type: item
date: 2022-10-10T01:10:41+08:00
description: 负载均衡就是将资源分配到某一时刻最需要它的地方。当个人电脑刚开始发展的时候，一个家庭可能只有一台（或更少）的电脑。孩子们白天玩电脑游戏，家长们晚上在业务支撑系统上做会计、编程，或者漫游。然而，想象一下今天一个只有一台电脑的家庭，你可以预想到这样会产生什么样的冲突。每个人都想使用电脑，而只有一副键盘和鼠标。随着计算机变得越来越普遍，IT 行业或多或少也出现了同样的情况。对服务和服务器的需求已经增长到了会因为用量过大而停机的程度。幸运的是，我们现在有了负载均衡的概念来帮助我们处理需求。负载均衡是什么？负载均衡是一个通用术语，指的是为了确保高效分配所管理的资源而做的事情。对于 Web 服务器的系统管理员来说，负载均衡通常意味着确保 Web 服务器软件（例如 Nginx）配置了足够的工作节点来处理激增的访客。换言之，如果一个网站突然变得非常受欢迎，其访问者在几分钟内增加了四倍，那么运行服务器的软件必须能够响应每个访问者，并不能让任何访问者发现服务质量下降。对于简单的网站，这就像修改一行配置选项一样简单，但对于具有动态内容的复杂站点，每个用户都有多个数据库查询，这可能是一个严重的问题。这个问题本应随着云计算的发展而解决，但当 Web 应用程序遇到意外激增时，无法扩展也不是不可能。在进行负载均衡时，需要记住的重要一点是，高效地分配资源并不一定意味着平均地分配资源。并非所有任务都在任何时候都需要所有的可用资源。一个智能的负载均衡策略仅在需要资源时才为用户和任务提供资源。这通常是应用程序开发人员的领域，而不是 IT 基础架构的责任。异步应用程序对于确保离开计算机休息的用户不占用服务器上的宝贵资源至关重要。负载均衡是怎么工作的？负载均衡通过在多个计算节点上分配工作负载来避免瓶颈。这些节点可能是数据中心中的物理服务器、云环境中的容器、用于边缘计算而战略性放置的服务器、复杂应用程序框架中的独立 Java 虚拟机（JVM），或在单个 Linux 服务器上运行的守护进程。这个想法是把一个大问题分成几个小任务，并把每个任务分配给一台专用计算机。例如，对于一个要求用户登录的网站，该网站可能托管在服务器 A 上，而登录页面和所有随附的身份验证查询都托管在服务器 B 上。这样，新用户登录帐户时就不会占用其它使用该站点的用户的资源。云计算负载均衡云计算使用 容器，因此通常没有单独的物理服务器来处理不同的任务（实际上，有许多单独的服务器，但它们被聚集在一起作为一个计算“大脑”）。相反，“ 容器荚 pod ” 是由几个容器创建的。当一个容器荚由于其用户或任务负载而开始耗尽资源时，会生成一个相同的容器荚。容器荚共享存储和网络资源，每个容器荚在创建时被分配给一个计算节点。可以根据负载需要创建或销毁容器荚，这样无论有多少用户，用户都可以体验到一致的服务质量。边缘计算边缘计算 在负载均衡时考虑到了现实世界。云计算自然是一个分布式系统，但实际上，云计算的节点通常集中在几个数据中心。用户离运行云计算的数据中心越远，他们为获得最佳服务所必须克服的物理障碍就越多。即使有光纤连接和适当的负载均衡，位于 3000 英里外的服务器的响应时间也可能比仅仅 300 英里外的响应时间长。边缘计算将计算节点带到云计算的“边缘”，试图弥合地理鸿沟，为云计算形成一种卫星网络，因此它也在良好的负载均衡工作中发挥了作用。什么是负载均衡算法？有许多负载均衡策略，它们的复杂性取决于所涉及的技术和需求。负载均衡不必复杂，而且从一开始就负载均衡很重要，即使在使用 Kubernetes 和 Keepalived 这样的专用软件时也是如此。当你可以设计应用程序，自己为它采取简单的预防措施时，不要依赖容器来均衡负载。如果你从一开始就将应用程序设计为模块化和临时性的，那么你将受益于通过巧妙的网络设计、容器编排和其他未来技术带来的负载均衡机会。可以指导应用程序开发人员或网络工程师工作的一些流行算法包括：按顺序将任务分配给服务器（这通常被称为轮询调度）。将任务分配给当前最不繁忙的服务器。将任务分配给具有响应最快的服务器。随机分配任务。举个例子，在分配特别复杂的任务时，可以组合或加权这些原则以分配到组中最强大的服务器。通常使用 编排，这样管理员就不必为负载均衡寻找完美的算法或策略，尽管有时需要由管理员选择使用哪种负载均衡方案组合。预料意料之外负载均衡实际上并不是要确保在整个网络中均匀使用所有资源。负载均衡实际上是确保即使发生意外情况也能提供可靠的用户体验。良好的基础设施可以承受计算机崩溃、应用程序过载、网络流量冲击和用户错误。思考你的服务如何才能具有弹性，并从头开始相应地设计负载均衡策略。via: https://opensource.com/article/21/4/load-balancing作者：Seth Kenlon…

用 HAProxy 实现网络流量的负载平衡
type: item
date: 2022-02-06T19:40:10+08:00
description: 安装、配置和运行 HAProxy，在几个网络或应用服务器之间分配网络流量。不是只有在一个大型公司工作才需要使用负载平衡器。你可能是一个业余爱好者，用几台树莓派电脑自我托管一个网站。也许你是一个小企业的服务器管理员；也许你确实在一家大公司工作。无论你的情况如何，你都可以使用 HAProxy 负载平衡器来管理你的流量。HAProxy 被称为“世界上最快和使用最广泛的软件负载平衡器”。它包含了许多可以使你的应用程序更加安全可靠的功能，包括内置的速率限制、异常检测、连接排队、健康检查以及详细的日志和指标。学习本教程中所涉及的基本技能和概念，将有助于你使用 HAProxy 建立一个更强大的、远为强大的基础设施。为什么需要一个负载平衡器？负载平衡器是一种在几个网络或应用服务器之间轻松分配连接的方法。事实上，HAProxy 可以平衡任何类型的传输控制协议（TCP）流量，包括 RDP、FTP、WebSockets 或数据库连接。分散负载的能力意味着你不需要因为你的网站流量比谷歌大就购买一个拥有几十万 G 内存的大型网络服务器。负载平衡器还为你提供了灵活性。也许你现有的网络服务器不够强大，无法满足一年中繁忙时期的峰值需求，你想增加一个，但只是暂时的。也许你想增加一些冗余，以防一个服务器出现故障。有了 HAProxy，你可以在需要时向后端池添加更多的服务器，在不需要时删除它们。你还可以根据情况将请求路由到不同的服务器。例如，你可能想用几个缓存服务器（如 Varnish）来处理你的静态内容，但把任何需要动态内容的东西，如 API 端点，路由到一个更强大的机器。在这篇文章中，我将通过设置一个非常基本的 HAProxy 环境，使用 HTTPS 来监听安全端口 443，并利用几个后端 Web 服务器。它甚至会将所有进入预定义 URL（如 /api/）的流量发送到不同的服务器或服务器池。安装 HAProxy要开始安装，请启动一个新的 CentOS 8 服务器或实例，并使系统达到最新状态：$ sudo yum update -y 这通常会持续一段时间。在等待的时候给自己拿杯咖啡。这个安装有两部分：第一部分是安装 yum 版本的 HAProxy，第二部分是编译和安装你的二进制文件，用最新的版本覆盖以前的 HAProxy。用 yum 安装，在生成 systemd 启动脚本等方面做了很多繁重的工作，所以运行 yum install，然后从源代码编译，用最新的版本覆盖 HAProxy 二进制：$ sudo yum install -y haproxy 启用 HAProxy 服务：$ sudo systemctl enable haproxy 要升级到最新版本（版本 2.2，截至本文写作为止），请编译源代码。许多人认为从源代码编译和安装一个程序需要很高的技术能力，但这是一个相当简单的过程。首先，使用 yum 安装一些提供编译代码工具的软件包：$ sudo yum install dnf-plugins-core $ sudo yum config-manager --set-enabled PowerTools $ sudo yum install -y git ca-certificates gcc glibc-devel \ lua-devel pcre-devel openssl-devel systemd-devel \ make curl zlib-devel 使用 git 获得最新的源代码，并改变到 haproxy 目录：$ git clone http://git.haproxy.org/git/ haproxy $ cd haproxy 运行以下三个命令来构建和安装具有集成了 Prometheus 支持的 HAProxy：$ make TARGET=linux-glibc USE_LUA=1 USE_OPENSSL=1 USE_PCRE=1 \ PCREDIR= USE_ZLIB=1 USE_SYSTEMD=1 \ EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o" $ sudo make PREFIX=/usr install # 安装到 /usr/sbin/haproxy 通过查询版本来测试它：$ haproxy -v 你应该看到以下输出：HA-Proxy version 2.2.4-b16390-23 2020/10/09 - https://haproxy.org/ 创建后端服务器HAProxy 并不直接提供任何流量，这是后端服务器的工作，它们通常是网络或应用服务器。在这个练习中，我使用一个叫做 Ncat 的工具，它是网络领域的“瑞士军刀”，用来创建一些极其简单的服务器。安…

流量引导：网络世界的负载均衡解密
type: item
date: 2018-12-02T05:17:05+08:00
description: 均衡网络流量的常用技术，它们的优势和利弊权衡。大型的多站点互联网系统，包括内容分发网络（CDN）和云服务提供商，用一些方法来均衡来访的流量。这篇文章我们讲一下常见的流量均衡设计，包括它们的技术手段和利弊权衡。早期的云计算服务提供商，可以提供单一一台客户 Web 服务器，分配一个 IP 地址，然后用一个便于人读的域名配置一个 DNS 记录指向这个 IP 地址，再将 IP 地址通过边界网关协议（BGP）宣告出去，BGP 是在不同网络之间交换路由信息的标准方式。这本身并不是负载均衡，但是能在冗余的多条网络路径中进行流量分发，而且可以利用网络技术让流量绕过不可用的网络，从而提高了可用性（也引起了非对称路由的现象）。简单的 DNS 负载均衡随着来自客户的流量变大，老板希望服务是高可用的。你上线第二台 web 服务器，它有自己独立的公网 IP 地址，然后你更新了 DNS 记录，把用户流量引到两台服务器上（内心希望它们均衡地提供服务）。在其中一台服务器出故障之前，这样做一直是没有问题的。假设你能很快地监测到故障，可以更新一下 DNS 配置（手动更新或者通过软件）删除解析到故障机器的记录。不幸的是，因为 DNS 记录会被缓存，在客户端缓存和它们依赖的 DNS 服务器上的缓存失效之前，大约一半的请求会失败。DNS 记录都有一个几分钟或更长的生命周期（TTL），所以这种方式会对系统可用性造成严重的影响。更糟糕的是，部分客户端会完全忽略 TTL，所以有一些请求会持续被引导到你的故障机器上。设置很短的 TTL 也不是个好办法，因为这意味着更高的 DNS 服务负载，还有更长的访问时延，因为客户端要做更多的 DNS 查询。如果 DNS 服务由于某种原因不可用了，那设置更短的 TTL 会让服务的访问量更快地下降，因为没那么多客户端有你网站 IP 地址的缓存了。增加网络负载均衡要解决上述问题，可以增加一对相互冗余的四层（L4）网络负载均衡器，配置一样的虚拟 IP 地址（VIP）。均衡器可以是硬件的，也可以是像 HAProxy 这样的软件。域名的 DNS 记录指向 VIP，不再承担负载均衡的功能。四层负载均衡器能够均衡用户和两台 web 服务器的连接四层均衡器将网络流量均衡地引导至后端服务器。通常这是基于对 IP 数据包的五元组做散列（数学函数）来完成的，五元组包括：源地址、源端口、目的地址、目的端口、协议（比如 TCP 或 UDP）。这种方法是快速和高效的（还维持了 TCP 的基本属性），而且不需要均衡器维持每个连接的状态。（更多信息请阅读谷歌发表的 Maglev 论文，这篇论文详细讨论了四层软件负载均衡器的实现细节。）四层均衡器可以对后端服务做健康检查，只把流量分发到健康的机器上。和使用 DNS 做负载均衡不同的是，在某个后端 web 服务故障的时候，它可以很快地把流量重新分发到其他机器上，虽然故障机器的已有连接会被重置。当后端服务器的能力不同时，四层均衡器可以根据权重做流量分发。它为运维人员提供了强大的能力和灵活性，而且硬件成本相对较小。扩展到多站点系统规模在持续增长。你的客户希望能一直使用服务，即使是数据中心发生故障的时候。所以你建设了一个新的数据中心，另外独立部署了一套服务和四层负载均衡器集群，仍然使用同样的 VIP。DNS 的设置不变。两个站点的边缘路由器都把自己的地址空间宣告出去，包括 VIP 地址。发往该 VIP 的请求可能到达任何一个站点，取决于用户和系统之间的网络是如何连接的，以及各个网络的路由策略是如何配置的。这就是泛播。大部分时候这种机制可以很好的工作。如果一个站点出问题了，你可以停止通过 BGP 宣告 VIP 地址，客户的请求就会迅速地转移到另外一个站点去。多个站点使用泛播提供服务这种设置有一些问题。最大的问题是，不能控制请求流向哪个站点，或者限制某个站点的流量。也没有一个明确的方式把用户的请求转到距离他最近的站点（为了降低网络延迟），不过，网络协议和路由选路配置在大部分情况下应该能把用户请求路由到最近的站点。控制多站点系统中的入站请求为了维持稳定性，需要能够控制每个站点的流量大小。要实现这种控制，可以给每个站点分配不同的 VIP 地址，然后用简单的或者有权重的 DNS 轮询来做负载均衡。多站点提供服务，每个站点使用一个主 VIP，另外一个站点作为备份。基于能感知地理位置的 DNS。现在有两个问题。第一、使用 DNS 均衡意味着会有被缓存的记录，如果你要快速重定向流量的话就麻烦了。第二、用户每次做新的 DNS 查询，都可能连上任意一个站点，可能不是距离最近的。如果你的服务运行在分布广泛的很多站点上，用户会感受到响应时间有明显的变化，取决于用户和提供服务的站点之间有多大的网络延迟。让每个站点都配置上其他所有站点的 VIP 地址，并宣告出…

在 Linux 上用 DNS 实现简单的负载均衡
type: item
date: 2018-06-25T07:06:28+08:00
description: DNS 轮询将多个服务器映射到同一个主机名，并没有为这里展示的魔法做更多的工作。如果你的后端服务器是由多台服务器构成的，比如集群化或者镜像的 Web 或者文件服务器，通过负载均衡器提供了单一的入口点。业务繁忙的大型电商在高端负载均衡器上花费了大量的资金，用它来执行各种各样的任务：代理、缓存、状况检查、SSL 处理、可配置的优先级、流量整形等很多任务。但是你并不需要做那么多工作的负载均衡器。你需要的是一个跨服务器分发负载的简单方法，它能够提供故障切换，并且不太在意它是否高效和完美。DNS 轮询和使用轮询的子域委派是实现这个目标的两种简单方法。DNS 轮询是将多台服务器映射到同一个主机名上，当用户访问 foo.example.com 时多台服务器都可用于处理它们的请求，使用的就是这种方式。当你有多个子域或者你的服务器在地理上比较分散时，使用轮询的子域委派就比较有用。你有一个主域名服务器，而子域有它们自己的域名服务器。你的主域名服务器将所有的到子域的请求指向到它们自己的域名服务器上。这将提升响应时间，因为 DNS 协议会自动查找最快的链路。DNS 轮询轮询和 旅鸫鸟 robins 没有任何关系，据我相熟的图书管理员说，它最初是一个法语短语，ruban rond、或者 round ribbon。很久以前，法国政府官员以不分级的圆形、波浪线、或者直线形状来在请愿书上签字，以盖住原来的发起人。DNS 轮询也是不分级的，简单配置一个服务器列表，然后将请求转到每个服务器上。它并不做真正的负载均衡，因为它根本就不测量负载，也没有状况检查，因此如果一个服务器宕机，请求仍然会发送到那个宕机的服务器上。它的优点就是简单。如果你有一个小的文件或者 Web 服务器集群，想通过一个简单的方法在它们之间分散负载，那么 DNS 轮询很适合你。你所做的全部配置就是创建多条 A 或者 AAAA 记录，映射多台服务器到单个的主机名。这个 BIND 示例同时使用了 IPv4 和 IPv6 私有地址类：fileserv.example.com. IN A 172.16.10.10 fileserv.example.com. IN A 172.16.10.11 fileserv.example.com. IN A 172.16.10.12 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::10 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::11 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::12 Dnsmasq 在 /etc/hosts 文件中保存 A 和 AAAA 记录：172.16.1.10 fileserv fileserv.example.com 172.16.1.11 fileserv fileserv.example.com 172.16.1.12 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::10 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::11 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::12 fileserv fileserv.example.com 请注意这些示例都是很简化的，解析完全合格域名有多种方法，因此，关于如何配置 DNS 请自行学习。使用 dig 命令去检查你的配置能否按预期工作。将 ns.example.com 替换为你的域名服务器：$ dig @ns.example.com fileserv A fileserv AAA 它将同时显示出 IPv4 和 IPv6 的轮询记录。子域委派和轮询子域委派结合轮询要做的配置会更多，但是这样有一些好处。当你有多个子域或者地理位置比较分散的服务器时，就应该去使用它。它的响应时间更快，并且宕机的服务器不会去响应，因此客户端不会因为等待回复而被挂住。一个短的 TTL，比如 60 秒，就能帮你做到。这种方法需要多台域名服务器。在最简化的场景中，你需要一台主域名服务器和两个子域，每个子域都有它们自己的域名服务器。在子域服务器上配置你的轮询记录，然后在你的主域名服务器上配置委派。在主域名服务器上的 BIND 中，你至少需要两个额外的配置，一个区声明以及在区数据文件中的 A/AAAA 记录。主域名服务器中的委派应该像如下的内容：ns1.sub.example.com. IN A 172.16.1.20 ns1.sub.example.com. IN AAAA f…

开发者定义的应用交付
type: item
date: 2017-09-18T01:10:23+08:00
description: 负载均衡器如何帮助你解决分布式系统的复杂性。原生云应用旨在利用分布式系统的性能、可扩展性和可靠性优势。不幸的是，分布式系统往往以额外的复杂性为代价。由于你程序的各个组件跨网络分布，并且这些网络有通信障碍或者性能降级，因此你的分布式程序组件需要能够继续独立运行。为了避免程序状态的不一致，分布式系统设计应该有一个共识，即组件会失效。没有什么比在网络中更突出了。因此，在其核心，分布式系统在很大程度上依赖于负载平衡——请求分布于两个或多个系统，以便在面临网络中断时具有弹性，并在系统负载波动时水平缩放时。随着分布式系统在原生云程序的设计和交付中越来越普及，负载平衡器在现代应用程序体系结构的各个层次都影响了基础设施设计。在大多数常见配置中，负载平衡器部署在应用程序前端，处理来自外部世界的请求。然而，微服务的出现意味着负载平衡器可以在幕后发挥关键作用：即管理服务之间的流。因此，当你使用原生云程序和分布式系统时，负载均衡器将承担其他角色：作为提供缓存和增加安全性的反向代理，因为它成为外部客户端的中间人。作为通过提供协议转换（例如 REST 到 AMQP）的 API 网关。它可以处理安全性（即运行 Web 应用程序防火墙）。它可能承担应用程序管理任务，如速率限制和 HTTP/2 支持。鉴于它们的扩展能力远大于平衡流量， 负载平衡器 load balancer 可以更广泛地称为 应用交付控制器 Application Delivery Controller （ADC）。开发人员定义基础设施从历史上看，ADC 是由 IT 专业人员购买、部署和管理的，最常见运行企业级架构的应用程序。对于物理负载平衡器设备（如 F5、Citrix、Brocade等），这种情况在很大程度上仍然存在。具有分布式系统设计和临时基础设施的云原生应用要求负载平衡器与它们运行时的基础设施 (如容器) 一样具有动态特性。这些通常是软件负载均衡器（例如来自公共云提供商的 NGINX 和负载平衡器）。云原生应用通常是开发人员主导的计划，这意味着开发人员正在创建应用程序（例如微服务器）和基础设施（Kubernetes 和 NGINX）。开发人员越来越多地对负载平衡 (和其他) 基础设施的决策做出或产生重大影响。作为决策者，云原生应用的开发人员通常不会意识到企业基础设施需求或现有部署的影响，同时要考虑到这些部署通常是新的，并且经常在公共或私有云环境中进行部署。云技术将基础设施抽象为可编程 API，开发人员正在定义应用程序在该基础设施的每一层的构建方式。在有负载平衡器的情况下，开发人员会选择要使用的类型、部署方式以及启用哪些功能。它们以编程的方式对负载平衡器的行为进行编码 —— 随着程序在部署的生存期内增长、收缩和功能上进化时，它如何动态响应应用程序的需要。开发人员将基础设施定义为代码 —— 包括基础设施配置及其运维。开发者为什么定义基础设施？编写如何构建和部署应用程序的代码实践已经发生了根本性的转变，它体现在很多方面。简而言之，这种根本性的转变是由两个因素推动的：将新的应用功能推向市场所需的时间（上市时间）以及应用用户从产品中获得价值所需的时间（获益时间）。因此，新的程序写出来就被持续地交付（作为服务），无需下载和安装。上市时间和获益时间的压力并不是新的，但由于其他因素的加剧，这些因素正在加强开发者的决策权力：云：通过 API 将基础设施定义为代码的能力。伸缩：需要在大型环境中高效运维。速度：马上需要交付应用功能，为企业争取竞争力。微服务：抽象框架和工具选择，进一步赋予开发人员基础设施决策权力。除了上述因素外，值得注意的是开源的影响。随着开源软件的普及和发展，开发人员手中掌握了许多应用程序基础设施 - 语言、运行时环境、框架、数据库、负载均衡器、托管服务等。微服务的兴起使应用程序基础设施的选择民主化，允许开发人员选择最佳的工具。在选择负载平衡器的情况下，那些与云原生应用的动态特质紧密集成并响应的那些人将超人一等。总结当你在仔细考虑你的云原生应用设计时，请与我一起讨论“在云中使用 NGINX 和 Kubernetes 进行负载平衡”。我们将检测不同公共云和容器平台的负载平衡功能，并通过一个宏应用的案例研究。我们将看看它是如何被变成较小的、独立的服务，以及 NGINX 和 Kubernetes 的能力是如何拯救它的。作者简介：Lee Calcote 是一位创新思想领袖，对开发者平台和云、容器、基础设施和应用的管理软件充满热情。先进的和新兴的技术一直是 Calcote 在 SolarWinds、Seagate、Cisco 和 Pelco 时的关注重点。他是技术会议和聚会的组织者、写作者、作家、演讲者，经常活跃在技术社区。via: https://www.oreilly.com/learning/…

如何使用 Weave 以及 Docker 搭建 Nginx 反向代理/负载均衡服务器
type: item
date: 2015-09-05T17:46:00+08:00
description: Hi， 今天我们将会学习如何使用 Weave 和 Docker 搭建 Nginx 的反向代理/负载均衡服务器。Weave 可以创建一个虚拟网络将 Docker 容器彼此连接在一起，支持跨主机部署及自动发现。它可以让我们更加专注于应用的开发，而不是基础架构。Weave 提供了一个如此棒的环境，仿佛它的所有容器都属于同个网络，不需要端口/映射/连接等的配置。容器中的应用提供的服务在 weave 网络中可以轻易地被外部世界访问，不论你的容器运行在哪里。在这个教程里我们将会使用 weave 快速并且简单地将 nginx web 服务器部署为一个负载均衡器，反向代理一个运行在 Amazon Web Services 里面多个节点上的 docker 容器中的简单 php 应用。这里我们将会介绍 WeaveDNS，它提供一个不需要改变代码就可以让容器利用主机名找到的简单方式，并且能够让其他容器通过主机名连接彼此。在这篇教程里，我们将使用 nginx 来将负载均衡分配到一个运行 Apache 的容器集合。最简单轻松的方法就是使用 Weave 来把运行在 ubuntu 上的 docker 容器中的 nginx 配置成负载均衡服务器。1. 搭建 AWS 实例首先，我们需要搭建 Amzaon Web Service 实例，这样才能在 ubuntu 下用 weave 跑 docker 容器。我们将会使用AWS 命令行 来搭建和配置两个 AWS EC2 实例。在这里，我们使用最小的可用实例，t1.micro。我们需要一个有效的Amazon Web Services 账户使用 AWS 命令行界面来搭建和配置。我们先在 AWS 命令行界面下使用下面的命令将 github 上的 weave 仓库克隆下来。$ git clone https://github.com/weaveworks/guides $ cd weave-gs/aws-nginx-ubuntu-simple 在克隆完仓库之后，我们执行下面的脚本，这个脚本将会部署两个 t1.micro 实例，每个实例中都是 ubuntu 作为操作系统并用 weave 跑着 docker 容器。$ sudo ./demo-aws-setup.sh 在这里，我们将会在以后用到这些实例的 IP 地址。这些地址储存在一个 weavedemo.env 文件中，这个文件创建于执行 demo-aws-setup.sh 脚本期间。为了获取这些 IP 地址，我们需要执行下面的命令，命令输出类似下面的信息。$ cat weavedemo.env export WEAVE_AWS_DEMO_HOST1=52.26.175.175 export WEAVE_AWS_DEMO_HOST2=52.26.83.141 export WEAVE_AWS_DEMO_HOSTCOUNT=2 export WEAVE_AWS_DEMO_HOSTS=(52.26.175.175 52.26.83.141) 请注意这些不是固定的 IP 地址，AWS 会为我们的实例动态地分配 IP 地址。我们在 bash 下执行下面的命令使环境变量生效。 . ./weavedemo.env 2. 启动 Weave 和 WeaveDNS在安装完实例之后，我们将会在每台主机上启动 weave 以及 weavedns。Weave 以及 weavedns 使得我们能够轻易地将容器部署到一个全新的基础架构以及配置中， 不需要改变代码，也不需要去理解像 Ambassador 容器以及 Link 机制之类的概念。下面是在第一台主机上启动 weave 以及 weavedns 的命令。ssh -i weavedemo-key.pem ubuntu@$WEAVE_AWS_DEMO_HOST1 $ sudo weave launch $ sudo weave launch-dns 10.2.1.1/24 下一步，我也准备在第二台主机上启动 weave 以及 weavedns。ssh -i weavedemo-key.pem ubuntu@$WEAVE_AWS_DEMO_HOST2 $ sudo weave launch $WEAVE_AWS_DEMO_HOST1 $ sudo weave launch-dns 10.2.1.2/24 3. 启动应用容器现在，我们准备跨两台主机启动六个容器，这两台主机都用 Apache2 Web 服务实例跑着简单的 php 网站。为了在第一个 Apache2 Web 服务器实例跑三个容器， 我们将会使用下面的命令。ssh -i weavedemo-key.pem ubuntu@$WEAVE_AWS_DEMO_HOST1 $ sudo weave run --…

在 RHEL/CentOS 上为Web服务器架设 “XR”（Crossroads） 负载均衡器
type: item
date: 2015-07-23T15:22:00+08:00
description: Crossroads 是一个独立的服务，它是一个用于Linux和TCP服务的开源负载均衡和故障转移实用程序。它可用于HTTP，HTTPS，SSH，SMTP 和 DNS 等，它也是一个多线程的工具，在提供负载均衡服务时，它可以只使用一块内存空间以此来提高性能。首先来看看 XR 是如何工作的。我们可以将 XR 放到网络客户端和服务器之间，它可以将客户端的请求分配到服务器上以平衡负载。如果一台服务器宕机，XR 会转发客户端请求到另一个服务器，所以客户感觉不到停顿。看看下面的图来了解什么样的情况下，我们要使用 XR 处理。安装 XR Crossroads 负载均衡器这里有两个 Web 服务器，一个网关服务器，我们将在网关服务器上安装和设置 XR 以接收客户端请求，并分发到服务器。XR Crossroads 网关服务器：172.16.1.204Web 服务器01：172.16.1.222Web 服务器02：192.168.1.161在上述情况下，我们网关服务器（即 XR Crossroads）的IP地址是172.16.1.204，webserver01 为172.16.1.222，它监听8888端口，webserver02 是192.168.1.161，它监听端口5555。现在，我们需要的是均衡所有的请求，通过 XR 网关从网上接收请求然后分发它到两个web服务器已达到负载均衡。第1步：在网关服务器上安装 XR Crossroads 负载均衡器1. 不幸的是，没有为 crossroads 提供可用的 RPM 包，我们只能从源码安装。要编译 XR，你必须在系统上安装 C++ 编译器和 GNU make 组件，才能避免安装错误。# yum install gcc gcc-c++ make 接下来，去他们的官方网站（https://crossroads.e-tunity.com）下载此压缩包（即 crossroads-stable.tar.gz）。或者，您可以使用 wget 去下载包然后解压在任何位置（如：/usr/src/），进入解压目录，并使用 “make install” 命令安装。# wget https://crossroads.e-tunity.com/downloads/crossroads-stable.tar.gz # tar -xvf crossroads-stable.tar.gz # cd crossroads-2.74/ # make install 安装 XR Crossroads 负载均衡器安装完成后，二进制文件安装在 /usr/sbin 目录下，XR 的配置文件在 /etc 下名为 “xrctl.xml” 。2. 最后一个条件，你需要两个web服务器。为了方便使用，我在一台服务器中创建两个 Python SimpleHTTPServer 实例。要了解如何设置一个 python SimpleHTTPServer，请阅读我们此处的文章 使用 SimpleHTTPServer 轻松创建两个 web 服务器.正如我所说的，我们要使用两个web服务器，webserver01 通过8888端口运行在172.16.1.222上，webserver02 通过5555端口运行在192.168.1.161上。XR WebServer 01XR WebServer 02第2步: 配置 XR Crossroads 负载均衡器3. 所需都已经就绪。现在我们要做的就是配置xrctl.xml 文件并通过 XR 服务器接受来自互联网的请求分发到 web 服务器上。现在用 vi/vim 编辑器打开xrctl.xml文件。# vim /etc/xrctl.xml 并作如下修改。<?xml version="1.0" encoding="UTF-8"?> <configuration> <system> <uselogger>true</uselogger> <logdir>/tmp</logdir> </system> <service> <name>Tecmint</name> <server> 172.16.1.204:8080 <type>tcp</type> <webinterface>0:8010</webinterface> <verbose>yes</verbose> <clientreadtimeout>0</clientreadtimeout> <clientwritetimout>0</clientwritetimeout> <backendreadtimeout>0</backendreadtimeout> <backendwritetimeout>0</backendwritetimeout> </server> <bac…

使用 HAProxy 配置 HTTP 负载均衡器
type: item
date: 2015-01-28T17:06:00+08:00
description: 随着基于 Web 的应用和服务的增多，IT 系统管理员肩上的责任也越来越重。当遇到不可预期的事件如流量达到高峰，流量增大或者内部的挑战比如硬件的损坏或紧急维修，无论如何，你的 Web 应用都必须要保持可用性。甚至现在流行的 devops 和持续交付（CD）也可能威胁到你的 Web 服务的可靠性和性能的一致性。不可预测，不一致的性能表现是你无法接受的。但是我们怎样消除这些缺点呢？大多数情况下一个合适的负载均衡解决方案可以解决这个问题。今天我会给你们介绍如何使用 HAProxy 配置 HTTP 负载均衡器。什么是 HTTP 负载均衡？HTTP 负载均衡是一个网络解决方案，它将进入的 HTTP 或 HTTPs 请求分配至一组提供相同的 Web 应用内容的服务器用于响应。通过将请求在这样的多个服务器间进行均衡，负载均衡器可以防止服务器出现单点故障，可以提升整体的可用性和响应速度。它还可以让你能够简单的通过添加或者移除服务器来进行横向扩展或收缩，对工作负载进行调整。什么时候，什么情况下需要使用负载均衡？负载均衡可以提升服务器的使用性能和最大可用性，当你的服务器开始出现高负载时就可以使用负载均衡。或者你在为一个大型项目设计架构时，在前端使用负载均衡是一个很好的习惯。当你的环境需要扩展的时候它会很有用。什么是 HAProxy？HAProxy 是一个流行的开源的 GNU/Linux 平台下的 TCP/HTTP 服务器的负载均衡和代理软件。HAProxy 是单线程，事件驱动架构，可以轻松的处理 10 Gbps 速率 的流量，在生产环境中被广泛的使用。它的功能包括自动健康状态检查，自定义负载均衡算法，HTTPS/SSL 支持，会话速率限制等等。这个教程要实现怎样的负载均衡在这个教程中，我们会为 HTTP Web 服务器配置一个基于 HAProxy 的负载均衡。准备条件你至少要有一台，或者最好是两台 Web 服务器来验证你的负载均衡的功能。我们假设后端的 HTTP Web 服务器已经配置好并可以运行。在 Linux 中安装 HAProxy对于大多数的发行版，我们可以使用发行版的包管理器来安装 HAProxy。在 Debian 中安装 HAProxy在 Debian Wheezy 中我们需要添加源，在 /etc/apt/sources.list.d 下创建一个文件 "backports.list" ，写入下面的内容deb http://cdn.debian.net/debian wheezy­backports main 刷新仓库的数据，并安装 HAProxy# apt­ get update # apt ­get install haproxy 在 Ubuntu 中安装 HAProxy# apt ­get install haproxy 在 CentOS 和 RHEL 中安装 HAProxy# yum install haproxy 配置 HAProxy本教程假设有两台运行的 HTTP Web 服务器，它们的 IP 地址是 192.168.100.2 和 192.168.100.3。我们将负载均衡配置在 192.168.100.4 的这台服务器上。为了让 HAProxy 工作正常，你需要修改 /etc/haproxy/haproxy.cfg 中的一些选项。我们会在这一节中解释这些修改。一些配置可能因 GNU/Linux 发行版的不同而变化，这些会被标注出来。1. 配置日志功能你要做的第一件事是为 HAProxy 配置日志功能，在排错时日志将很有用。日志配置可以在 /etc/haproxy/haproxy.cfg 的 global 段中找到他们。下面是针对不同的 Linux 发型版的 HAProxy 日志配置。CentOS 或 RHEL:在 CentOS/RHEL中启用日志，将下面的：log 127.0.0.1 local2 替换为：log 127.0.0.1 local0 然后配置 HAProxy 在 /var/log 中的日志分割，我们需要修改当前的 rsyslog 配置。为了简洁和明了，我们在 /etc/rsyslog.d 下创建一个叫 haproxy.conf 的文件，添加下面的内容：$ModLoad imudp $UDPServerRun 514 $template Haproxy,"%msg%\n" local0.=info ­/var/log/haproxy.log;Haproxy local0.notice ­/var/log/haproxy­status.log;Haproxy local0.* ~ 这个配置会基于 $template 在 /var/log 中分割 HAProxy 日志。现在重启 rsyslog 应用这些更改。# s…