☰

AWS ELB 作为 Varnish Accelerator 的后端

tag-icon • tag-icon amazon-web-services varnish amazon-elb
AWS ELB 作为 Varnish Accelerator 的后端

我正在 AWS 上进行大规模部署，该部署对正常运行时间要求很高，并且全天负载变化很大。显然，这是 ELB（弹性负载均衡器）和自动扩展的完美用例。

但是，我们也依赖 varnish 来缓存 API 调用。我最初的直觉是构建堆栈，以便 varnish 使用 ELB 作为后端，进而访问 appGroup。

Varnish -> ELB -> AppServers

然而，根据A 很少 来源这是不可能的，因为 ELB 不断改变其 DNS 主机名的 IP 地址，而 Varnish 在启动时会缓存该地址，这意味着 Varnish 不会获取对 IP 的更改。

然而，读了周围的资料后，我发现似乎有人在这么做，所以我想知道有什么解决方法？也许是一个定期重新加载 vcl 的脚本？

如果这真的不是一个好主意，还有其他解决方案吗？

答案1

这绝对是可能的，但需要几个步骤才能让它正常工作！当我们需要这种配置时，我们这样做的方式是：

  • 创建 VPC。您需要在 VPC 中执行此操作，因为您需要在其中创建子网。

  • 在每个可用区中创建一个子网，您将在其中注册 ELB 的实例。您应该划分子网，以便每个子网中都有少量 IP 地址，因为每个 IP 地址都会成为开销。（我们目前使用的子网是 /26）

  • 开始在您的 varnish VCL 中创建 DNS Director 后端。添加您上面创建的 3 个子网。(https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns-director）

  • 将 DNS Director 后端中的主机设置设为 varnish 期望看到的主机名。（例如，如果您的前端服务名为 front-end-service.subdomain.example.com，则将 front-end-service.example.com 作为 VCL 中的主机设置。）

  • 将 DNS Director 中的后缀设置设置为您可以解析的内容。继续上面的示例，您可以轻松地使用“-varnish.example.com”作为后缀。当请求到达 varnish 时，varnish 将查看 HTTP Host 标头，如果名称与 varnish 在 VCL 的 DNS Director Backend 中为 Host 标头设置的名称匹配，varnish 将附加后缀并对主机名执行 DNS 查找，这是将 Host 标头的内容与后缀连接起来的结果。因此，在此示例中，varnish 将对名为“front-end-service.subdomain.example.com-varnish.example.com”的主机执行 DNS 查找

  • 创建负载均衡器后端并将其附加到您创建的每个子网。

  • 将连接结果的 DNS 记录设置为 Amazon 为您的负载均衡器提供的 DNS 名称的 CNAME。

  • 启动 varnish，可选择查看 varnishstat 来验证后端的数量。

  • 通过发出

    curl -H“主机：front-end-service.subdomain.example.com”http://varnish-server-hostname.example.com/whatever-path

  • 使用 varnishlog 观察请求，以验证一切是否正常。

值得注意的是，如果您要将负载均衡器放置在该子网中，AWS 建议您的子网中至少包含 20 个未使用的 IP 地址。（请参阅http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html）

我们最近在一个项目中完成了这项工作，该项目需要 ELB 来满足需求规范，但我们担心如何在管理方面进行扩展，并正在研究基于服务发现的方法以及诸如自动 VCL 更新之类的方法，以及通过 Varnish Agent 之类的工具进行自动 VCL 部署（https://github.com/varnish/vagent2）

但是，如果您不介意管理您的 VPC 子网，上述描述非常有效。

干杯!

答案2

ELB 的部分目的是应对主机中断。即使使用自动扩展和 CloudWatch，如果需要更换死机实例，您也可能需要几分钟的停机时间。

我建议：

[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]

我知道你想尽可能地利用缓存，但是你真的应将负载分散到所有可用区域。这意味着您的堆栈所在的区域 A、B 和 C 中的实例数量相等（因此是 3x Varnish）。这当然会花费更多，但它使您能够在整个可用区中断的情况下生存下来*。削减这笔费用意味着在某个时候您可能需要承担停机时间。这是您要做出的决定，但至少您可以做出明智的决定。

有两个安全组，一个用于 Varnish，一个用于 AppServers。配置每个安全组，以便只有关联的 ELB 才能在适当的端口上访问它。

对于 Varnish 配置，请将 DNS 控制器设置为较低的 TTL。将其设置为 Amazon 为后端 ELB 提供的 CNAME 的 TTL 的相等值（或一半）。这足以让 Varnish 保持最新状态。

* 如果您想要获得极致的可用性，请使用具有多区域、多可用区冗余的 Route53。

答案3

Varnish 实际上可以充当负载均衡器。你应该尝试一下Varnish -> AppServers。

只需将每个应用服务器定义为 Varnish 配置中的控制器的后端即可。

您甚至可以添加探测器来检查后端可用性，当请求过程中一个服务器失败时重试切换到另一个服务器等。

您的 Varnish 实例托管在哪里？ASW 也是吗？您可以尝试 Varnish 哈希管理器，并将 Varnish 托管在与应用程序相同的服务器上。每个实例将处理它应该处理的请求，并将其他请求转发到正确的后端。每个唯一 URL 只会缓存在 1 个（可用）服务器上，并且您的缓存内存将乘以 Varnish 实例的数量，同时缓存未命中将受到限制。

相关内容