Cli*_*ath 12 amazon-ec2 amazon-web-services elastic-load-balancer
我有一个Web应用程序,它运行在Amazon AWS Elastic Load Balancer后面,附带3个实例.该应用程序有一个/refresh端点来重新加载参考数据.每当有新数据可用时都需要运行,每周发生几次.
我一直在做的是为所有实例分配公共地址,并独立刷新(使用ec2-url/refresh).我同意迈克尔对不同主题的回答,ELB背后的EC2实例不应允许直接公开访问.现在我的问题是我如何elb-url/refresh拨打电话到达负载均衡器后面的所有实例?
如果我可以从多个实例收集HTTP响应,那就太好了.但我现在不介意盲目刷新.
小智 8
我解决这个问题的方法之一是
这个解决方案的关键胜利是
希望这很有用.
您无法通过负载均衡器发出这些请求,因此您必须打开实例的安全组以允许来自 ELB 以外的源的传入流量。但这并不意味着您需要将其开放给所有直接流量。您可以简单地将安全组中的 IP 地址列入白名单,以允许来自特定计算机的请求。
如果您不想向这些服务器添加公共 IP 地址,则需要curl在 VPC 内的 EC2 实例上运行类似命令的内容。在这种情况下,您只需打开安全组以允许来自 VPC 中存在的某些服务器(或服务器组)的流量。
虽然考虑到应用程序和环境的限制,这可能是不可能的,但值得注意的是,在AWS ELB后面运行的实例的最佳实践应用程序体系结构(特别是如果它们是AutoScalingGroup的一部分)确保实例不是有状态的.
我们的想法是通过添加新实例来扩展,或通过删除实例来扩展,而不会影响数据完整性或性能.
一种选择是更改应用程序以将参考数据重新加载的结果存储到实例外数据存储中,例如缓存或数据库(例如Elasticache或RDS),而不是内存中.
如果应用程序能够做到这一点,那么您只需要refresh在单个服务器上命中端点 - 它将重新加载参考数据,进行任何分析和操作以有效地以适合的方式存储它应用程序,将其存储到数据存储,然后所有实例都可以通过共享数据存储访问刷新的数据.
虽然延迟增加会增加数据存储的往返,但对于应用程序的一致性来说通常是值得的 - 在当前模型下,如果一个服务器在刷新参考数据时落后于其他服务器,如果ELB如果没有使用粘性会话,则通过ELB的请求将返回不一致的数据,具体取决于它们分配给哪个服务器.
我以不同的方式解决了这个问题,没有在安全组中开放新的流量,也没有诉诸 S3 等外部资源。它的灵活性在于它会动态通知通过 ECS 或 ASG 添加的实例。
ELB 的目标组提供定期运行状况检查的功能,以确保其背后的实例处于活动状态。这是您的服务器响应的 URL。端点可以包括最新配置的时间戳参数。TG 中的每台服务器都会在配置的Interval阈值内收到健康检查 ping。如果 ping 的参数发生变化,则表示刷新。
URL 可能如下所示:
/is-alive?last-configuration=2019-08-27T23%3A50%3A23Z
上面我传递了 UTC 时间戳2019-08-27T23:50:23Z
接收请求的服务将检查内存中的状态是否至少与时间戳参数一样新。如果没有,它将刷新其状态并更新时间戳。由于您的状态已刷新,下一次运行状况检查将导致无操作。
实施说明
如果刷新状态可能需要比间隔窗口或 TG 运行状况超时更长的时间,则需要将其卸载到另一个线程,以防止并发更新或彻底的服务中断,因为运行状况检查需要立即返回。否则该节点将被视为离线。
如果您为此目的使用流量端口,请确保 URL 的安全,使其无法被猜测。任何公开暴露的内容都可能受到 DoS 攻击。
| 归档时间: |
|
| 查看次数: |
4780 次 |
| 最近记录: |