使用 NGINX Plus 对 AWS Auto Scaling 组进行负载平衡

云的最有益功能之一是能够自动扩展计算实例的数量。 使用 AWS 自动扩缩，您可以更改 自动扩缩组根据计划或需求，手动或自动进行。 自动扩展可以通过将实例数量调整为适合当前工作负载的正确数量来帮助降低成本。 此外，Auto Scaling 还会重新启动失败的实例，从而增强应用的弹性。

使用自动缩放时，负载均衡至关重要。 AWS 通过将其内置负载均衡器（弹性负载均衡器 (ELB)，现正式称为 Classic Load Balancer，以及application负载均衡器 (ALB)）与 Auto Scaling 相集成，提供 Auto Scaling 组实例的负载均衡。 NGINX Plus为任何云环境（包括 AWS）提供高级云负载均衡，并支持 AWS Auto Scaling 组。

选择 NGINX Plus 作为内置 AWS 云负载均衡器的替代或补充有三个主要原因：

1. NGINX Plus 提供了 ELB 和 ALB 所缺乏的多种高级功能。
2. AWS 负载均衡器（尤其是 ALB）的定价模型很复杂，因此很难预测成本。 NGINX Plus 定价很简单，无论您是直接从我们这里购买 NGINX Plus 订阅，还是从AWS Marketplace运行预构建的 NGINX Plus 实例，均按固定的小时费率计费。
3. NGINX Plus 不会将您与特定于平台的 API 绑定，而是允许您在多个云平台之间重复使用负载均衡配置。

要了解 NGINX Plus 与 AWS 内置解决方案的比较（以及协同工作方式），请阅读我们关于ELB和ALB 的博客文章。

在这篇博文中，我们展示了两种配置 NGINX Plus 来平衡 Auto Scaling 组负载的方法，并解释了何时使用每种方法：

1. 在 ELB 前面使用 NGINX Plus
2. 将 NGINX Plus 与 NGINX, Inc. 提供的集成软件一起使用

阅读完这篇博文后，您将准备在 AWS 上部署 NGINX Plus，为 Auto Scaling 组提供高级负载均衡。

示例 AWS Auto Scaling 环境

我们使用示例应用环境来说明使用 NGINX Plus 对 Auto Scaling 组进行负载平衡的两种方法。 我们的后端 Web应用由两个服务组成 - Backend One 和 Backend Two - 每个服务都公开在端口 80 上。 每项服务都有一个由多个应用实例组成的 Auto Scaling 组。 负载均衡器根据请求 URI 将客户端请求路由到适当的后端：

• /backend‑one的请求转到 Backend One。
• /backend‑two的请求转到后端二。

当我们扩展应用自动扩展组（自动或手动）时，必须更新负载均衡器配置以反映新的应用实例数量。 内置的 AWS 负载均衡器会自动执行此操作。 对于 NGINX Plus，我们需要使用上面提到的方法之一（ELB 前面的 NGINX Plus，或带有集成软件的 NGINX Plus）将扩展事件传播到配置。

响应扩展事件来更新 NGINX Plus 配置的另一种方法是使用外部服务注册表。 NGINX Plus 支持与提供DNS 接口的服务发现系统集成，例如Consul 。 在这篇博文中，我们重点介绍不依赖于外部系统且易于设置和使用的解决方案。

在 ELB 前面使用 NGINX Plus

如果您已经在使用 Auto Scaling 组和 ELB，那么将 NGINX Plus 的一些高级功能引入您的应用的最简单方法是将 NGINX Plus 放置在 ELB 云负载均衡器前面，如下图所示：

在这种情况下，NGINX Plus 充当一个或多个 ELB 的代理/负载平衡器。 NGINX Plus 使用其高级路由功能，根据请求 URI 将请求转发到适当的 ELB。然后，ELB 将请求传递给 Auto Scaling 组中的一个实例。 在这种配置下，ELB 提供了扩展支持。

这是 NGINX Plus 配置。

解析器 169.254.169.253 有效 = 10 秒；上游后端一 {区域后端一 64k；用于后端一的 ELB 服务器 DNS 名称解析；}上游后端二 {区域后端二 64k；用于后端二的 ELB 服务器 DNS 名称解析；}服务器 {监听 80；位置 /后端一 {proxy_set_header 主机 $host；proxy_pass http://backend-one；}位置 /后端二 {proxy_set_header 主机 $host；proxy_pass http://backend-two；} }

• resolver指令定义 NGINX Plus 用于解析内部 ELB 实例的 DNS 名称的 DNS 服务器。 这是 AWS DNS 服务器的 IP 地址。

• 我们创建两个上游块，每个与我们的服务相对应的 Auto Scaling 组一个，后端一和后端二。 我们通过对流量进行负载平衡的 ELB 的 DNS 名称来识别 Auto Scaling 组。

  使用resolve参数，我们告诉 NGINX Plus 定期重新解析名称 - 频率由上一个项目符号中讨论的resolver指令的有效参数设置。 这里我们设置为10秒，因为ELB的IP地址经常会变化。

  zone指令分配内存（此处最多 64 KB）用于存储已解析的 IP 地址。

• 我们定义一个监听端口80的虚拟服务器。 位置块告诉 NGINX Plus 将/backend‑one的请求传递给 Backend One Auto Scaling 组的 ELB，将/backend‑two 的请求传递给 Backend Two Auto Scaling 组的 ELB。

如您所见，此方法易于设置和使用，特别是如果您已经在使用 ELB。 然而，它存在几个缺点：

• 有限的负载均衡选项。 由于 NGINX Plus 将请求传递给 ELB，而不是直接传递给后端实例，因此 ELB 正在进行负载均衡。 因此，您无法利用 NGINX Plus 更复杂的负载均衡算法和会话持久选项。
• 冗余。 NGINX Plus 可以进行负载均衡，因此 ELB 是多余的——我们使用它只是因为它与 Auto Scaling 原生集成。
• 有限的协议支持。 与 NGINX Plus 不同，ELB 不支持 WebSocket 和 UDP。

下一种方法不依赖于 ELB，因此不存在这些缺点。

使用 NGINX Plus 与集成软件

使用此方法，您可以与 NGINX Plus 一起安装其他集成软件。 该软件（ nginx-asg-sync ）持续监控 Auto Scaling 组。 当它发现发生扩展事件时，它会从 NGINX Plus 配置中添加或删除后端实例。 如图所示， nginx-asg-sync通过 AWS Auto Scaling API 了解 Auto Scaling 组的变化。

要使用集成软件，请执行以下步骤：

1. 设置对 AWS API 的访问权限
2. 安装集成软件
3. 配置 NGINX Plus
4. 配置集成软件

这些说明假设后端的自动缩放组已经存在。 他们还假设 NGINX Plus 在 Amazon Linux AMI 上运行。

步骤 1 – 设置对 AWS API 的访问权限

与 Auto Scaling API 的通信需要身份验证，因此您必须提供nginx-asg-sync的凭证。 AWS 使用 IAM 角色来处理凭证，因此您需要在启动 NGINX Plus 实例之前为其创建一个角色。 有关分步说明，请参阅 AWS 文档中的Amazon EC2 的 IAM 角色。

1. 创建一个 IAM 角色并将预定义的AmazonEC2ReadOnlyAccess策略附加到它。 此策略允许对 EC2 API 进行只读访问。
2. 启动 NGINX Plus 实例时，将此 IAM 角色添加到该实例。

第 2 步 - 安装集成软件

要安装集成软件，请从nginx-asg-sync GitHub 存储库下载适用于您的操作系统的软件包，并将其安装在运行 NGINX Plus 的实例上。

• 对于 Amazon Linux、CentOS 和 RHEL：

  $ sudo rpm -i软件包名称.rpm
  

• 对于 Ubuntu：

  $ sudo dpkg -i软件包名称.deb
  

有关完整的安装说明，请参阅 GitHub 上的文档。

步骤 3 - 配置 NGINX Plus

集成软件使用动态重新配置和实时活动监控API 更新 NGINX Plus 配置。 为了使软件正常工作，您必须配置这些 API 并声明必要的上游组：

• 配置 API 端点以进行动态重新配置和实时活动监控。 集成软件使用这些端点来从上游组中添加和删除后端实例。
• 为每个 Auto Scaling 组创建一个上游块。 不要在块中定义任何服务器，因为nginx-asg-sync会响应扩展事件自动添加和删除它们。

下面的示例代表我们的简单的 Web应用的配置：

上游后端一 { 区域后端一 64k;
状态 /var/lib/nginx/state/backend-one.conf;
}

上游后端二 {
区域后端二 64k;
状态 /var/lib/nginx/state/backend-two.conf;
}

服务器 {
监听 80;

状态区域后端;

位置 /backend-one {
proxy_set_header 主机 $host;
proxy_pass http://backend-one;
}

位置 /backend-two {
proxy_set_header 主机 $host;
proxy_pass http://backend-two;
}
}

服务器 {
监听 8080;

根 /usr/share/nginx/html;

位置 = / {
返回 302 /status.html;
}

位置 = /status.html {}

位置 /status {
access_log off;
status;
}

位置 /upstream_conf {
upper_conf;
}
}

• 与 ELB 示例一样，我们声明两个上游组 - backend‑one和backend‑two ，它们对应于我们的 Auto Scaling 组。 但是，这里我们不会向上游组添加任何服务器，因为服务器将由nginx‑aws‑sync添加。 state指令命名存储动态配置服务器列表的文件，使其能够在 NGINX Plus 重启后继续存在。
• 我们定义一个监听端口80的虚拟服务器。 与 ELB 示例相比，NGINX Plus 将/backend‑one的请求直接传递给 Backend One 组的实例，将/backend‑two的请求直接传递给 Backend Two 组的实例。

• 我们定义第二个虚拟服务器监听 8080 端口并在其上配置 NGINX Plus API：

  • 即时 API 可在127.0.0.1:8080/upstream_conf上获取
  • 状态 API 可在127.0.0.1:8080/status上访问

步骤 4——配置集成软件

集成软件在/etc/nginx文件夹中的aws.yaml文件中配置。 对于我们的应用，我们定义以下配置：

区域：us-west-2upstream_conf_endpoint：http://127.0.0.1:8080/upstream_conf
status_endpoint：http://127.0.0.1:8080/status
sync_interval_in_seconds： 5
上游：
- 名称：backend-one
autoscaling_group：backend-one-group
端口： 80
种类：http
- 名称：backend-two
autoscaling_group：backend-two-group
端口： 80
种类：http

• 区域键定义了我们部署应用的AWS 区域。
• upper_conf_endpoint和upper_status_endpoint键定义 NGINX Plus API 端点，我们在步骤 3中配置了它。
• sync_interval_in_seconds键定义同步间隔： nginx-asg-sync每 5 秒检查一次扩展更新。

• 上游键定义上游组的列表。 对于每个上游组我们指定：

  • name – 我们在步骤 3 中为上游块指定的名称。
  • autoscaling_group – 相应 Auto Scaling 组的名称。
  • 端口– 我们的后端服务公开的端口。
  • kind – NGINX Plus 负载平衡到后端应用的流量的协议，这里是http 。 如果应用使用 TCP/UDP，请指定流。

编辑aws.yaml文件后，重新启动软件：

$ sudo 重启 nginx-asg-sync

测试负载平衡和扩展

在上述步骤中，我们配置了 NGINX Plus 来为我们的应用实现 Auto Scaling 组的负载平衡。 现在我们可以测试它了。 NGINX Plus 将带有/backend‑one URI 的请求分发给 Backend One 组的实例，将带有/backend‑two URI 的请求分发给 Backend Two 组的实例。

我们可以看到，在扩展 Auto Scaling 组时，NGINX Plus 如何选择新实例。 首先，我们访问实时活动监控仪表板，可通过 NGINX Plus 实例的 8080 端口上的/status.html访问。 在“上游”选项卡上，我们可以看到 Auto Scaling 组中的实例：

现在，我们通过更改 Auto Scaling 组的容量将 Backend One 组从 3 个实例扩展到 5 个实例。 新实例启动后， nginx-asg-sync将其添加到 NGINX Plus 配置中。 很快，新的实例就会出现在仪表板上：

使NGINX Plus高可用性

到目前为止，我们仅启动了一个 NGINX Plus 实例。 但是，为了获得高可用性，我们建议为 NGINX Plus 本身创建一个 Auto Scaling 组，并在 NGINX Plus 实例前使用 ELB。 除了 ELB，您还可以使用Route 53将流量路由到 NGINX Plus 实例。 我们使用 ELB 的部署图如下所示：

选择正确的方法

那么，哪种配置 NGINX Plus 来平衡 Auto Scaling 组负载的方法更适合您？ 下表简要比较了两者：

概括

AWS Auto Scaling 的优点是可以根据需求水平调整应用程序实例的数量。 NGINX Plus 提供高级负载平衡功能，可与 AWS Auto Scaling 组结合使用。

与您的 AWS Auto Scaling 组一起尝试 NGINX Plus – 开始您的30 天免费试用或联系我们讨论您的使用案例。