awt中的rabbitmq自动扩展群集:管理扩展事件

问题描述 投票:0回答:1

我正在使用自动扩展组和负载均衡器(用于管理控制台Web访问和消息路由)在AWS上部署Rabbitmq(3.8.0)。

用于rabbitmq自动扩展的peer-discovery-aws插件似乎非常有用,可以使新节点自动加入集群。 (尽管我们只能使自动缩放模式起作用)。

目标组运行状况检查将杀死在amq端口上没有响应的实例(5672),然后自动伸缩组将替换它。当一个节点出现故障时,这非常好。当CPU使用率超过某个阈值时,伸缩策略也可以用于增加群集大小(尽管我不知道这是否是现实的用例)。

所以我们在测试中遇到了几种情况,我不确定该如何解决:

  1. 我们有一个问题,在整个集群的所有节点上,rabbitmqctl应用程序都死了。伸缩组杀死了无响应的实例,然后将其替换为新实例。新实例将不会自动加入群集,因为其余实例也已失效。当自动伸缩组杀死最后一个实例时,由于新实例无法加入,所有存储的消息都丢失了。所以这个问题是:万一扩展事件终止了最后一个群集节点,我该如何持久保存数据? (我的假设是使用外部EBS卷来存储消息,并在启动时将其附加,但是当该实例终止时,该卷也将终止,而不是附加到新实例-我有一种尝试的感觉重新发明Erlang应该做的HA轮)。

  2. 另一个(相关)问题是:当我用rabbitmqctl start_app重新启动服务时;然后关闭新实例,伸缩组将替换新实例(因为旧实例现在正在通过运行状况检查)-不管出于什么原因,新实例都无法加入群集。终止的原始实例仍被“记住”为群集节点。因此,当第二个新实例出现并尝试加入集群时,该应用程序在原始节点上崩溃了。 (这是奇怪的行为-但我重复了三遍)。因此问题2是:当群集节点被自动伸缩组终止时,如何自动从群集中删除该节点,以便替换群集节点可以自动加入群集? (似乎我应该做的是编写一个服务,该服务在每个群集节点上运行,并使用aws cli连续监视其他群集节点的状态,以及当一个“终止”时(此状态仅持续几分钟实例消失)-在发生故障的节点上运行remove node命令)。还是我要重新发明Erlang车轮?

  3. 最终的问题是:我们最初使用Terraform部署了新的集群和资源。 rabbitmq节点以“已初始化”状态开始,没有队列或交换,仅配置了admin用户和默认密码等进行配置。我们从现有集群中导出json配置文件,然后将其导入到新集群中,然后更改群集名称恢复为原始名称。当我们准备退役旧集群时,只需将消息穿插并交换负载均衡器的DNS名称,便可以通过这种方式进行蓝绿色的部署升级。问题是:当新节点通过自动缩放实例化时,它处于初始状态,直到它加入集群为止。负载均衡器将路由到任何节点,因为它不知道该节点是否在RabbitMQ集群中。因此,任何生产者或消费者都无法向“初始状态”节点进行身份验证,这很好。但是,Web控制台将交替路由到旧群集节点或新群集节点。管理员密码不同于两个节点。 (即,直到所有节点都加入后才能管理集群)。问题3:我需要一种方法来告诉Amazon ALB不要将15672(Web控制台)流量路由到尚未加入集群的节点。看来这应该是一个简单的问题,但这对我们的管理员造成了破坏。

amazon-web-services amazon-ec2 rabbitmq cluster-computing autoscaling
1个回答
0
投票

免责声明我从没使用过RabbitMQ或设置自动缩放功能

1)-您可以将EFS用于共享的辅助数据存储[1]。 EFS的性能确实比EBS差,因此您需要测试它是否特别适用于RabbitMQ。-您还可以在实例上附加一个辅助EBS卷,但这会带来很多烦人的问题,您必须编写脚本以解决这些问题(EBS特定于AZ,运行状况检查中的竞争条件将替代旧实例,及时启动新实例,AZ故障,实例全部移出了AZ等)。

2)-您可以将终止生命周期挂钩[2]添加到组中。这将触发一个事件,并使实例在ASG决定终止该实例之后但在其实际终止之前的短时间内保持挂起状态。每当此生命周期挂钩启动时,您就可以触发CloudWatch Event。 CW事件可以触发诸如Lambda或SSM Runbook之类的东西,它们可以调用该命令从群集中注销实例。-如果您从群集注销实例时不需要实例仍在运行,则在ASG实例终止时也有一个CloudWatch事件[3],因此您可以触发该事件而无需设置生命周期挂钩ASG。

3)-ALB刚刚针对进行蓝/绿部署的人员发布了一项新功能,您可以将2个目标组连接到一个侦听器操作,并权衡每个目标组应获得的流量[4]。将旧实例/ ASG附加到一个目标组,将新实例/ ASG附加在另一目标组上。在新节点启动并运行之前,请勿将流量发送给它们。-另外,如果您通常需要这样做,而不仅仅是在部署过程中,则可以利用ELB运行状况检查。将自定义运行状况检查路径设置为默认情况下不存在的页面。配置完实例后,您要向其发送流量(我假设它是一个自动过程吗?)在该运行状况检查路径上创建一个文件,以便它开始通过运行状况检查,并且ALB将发送该实例流量。 (我假设您现在有2个与ASG关联的不同目标组,分别针对两种流量的两种端口/类型,每个都有自己的运行状况检查)。这样做时,请确保ASG的运行状况检查宽限期足够长,以使实例不会由于运行不正常而终止。

[1] https://docs.aws.amazon.com/efs/latest/ug/mount-fs-auto-mount-onreboot.html

[2] https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html

[3] https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html#terminate-successful

[4] https://aws.amazon.com/blogs/aws/new-application-load-balancer-simplifies-deployment-with-weighted-target-groups/

© www.soinside.com 2019 - 2024. All rights reserved.