amazon-web-services - AWS AutoScalingGroup HealthCheckType 'ELB' 过早考虑实例 "InService"

Question

我正在尝试让 AutoScalingRollingUpdate 在我的自动缩放组上工作，方法是让新实例上线，然后仅在新实例接受流量时，终止旧实例。 AutoScalingRollingUpdate 似乎就是为此目的而设计的。

我将 AutoScalingGroup 的 HealthCheckType 设置为“ELB”。我还将 ELB 上的 HealthCheck 设置为需要:

• 3 次成功请求“健康”
• 10 次针对“不健康”的请求失败
• 无宽限期(零、0)

现在，从 ELB 的角度来看，当新实例上线时，它们在几分钟内不会处于服务状态，这正是我所期望的。然而，从 AutoScalingGroup 的角度来看，它们几乎立即被视为处于服务状态，因此，我的 AutoScalingGroup 在新实例实际准备好接收流量之前就停止了运行状况良好的实例。我很困惑为什么当 HealthCheckType 显式设置为“ELB”时，ASG 会先于 ELB 认为实例是健康的。

我尝试过设置宽限期，但这根本不会改变任何事情。事实上，我删除了 300 秒的宽限期，因为我认为实例可能在宽限期内隐式“InService”或其他什么情况。

我知道我可以在滚动更新策略上设置 PauseTime，但这很脆弱，因为有时当实例上线时会发生故障，并且它们在完成配置之前就被删除和替换，所以有时 ，可能会超出 PauseTime 窗口。另外，我想尽量减少我的应用同时运行两个不同版本的时间。

    ... ELB stuff ...

    "HealthCheck": {
      "HealthyThreshold": "3",
      "UnhealthyThreshold": "10",
      "Interval": "30",
      "Timeout": "15",
      "Target": {
        "Fn::Join": [
          "",
          [
            {"Fn::Join": [":", ["HTTP", {"Ref": "hostPort"}]]},
            {"Ref": "healthCheckPath"}
          ]
        ]
      }
    },

   ... ASG Stuff ...

  {
    ... snip ...

    "HealthCheckType": "ELB",
    "HealthCheckGracePeriod": "0",
    "Cooldown": "300"
  },
  "UpdatePolicy" : {
    "AutoScalingRollingUpdate" : {
      "MinInstancesInService" : "1",
      "MaxBatchSize" : "1"
    }
  }

Answer 1

首先，根据我们使用 CloudFormation 的经验，ASG HealthCheckType 和 HealthCheckGracePeriod 主要在 CloudFormation 事件范围之外使用。只要将新实例添加到 ASG 中，这些属性就会发挥作用。这可以在 CloudFormation 更新期间进行，也可以在 Auto Scaling 事件期间或 self 修复事件期间进行。在后一种情况下，将 HealthCheckGracePeriod 设置为一个值非常重要，该值应在考虑 ELB 运行状况检查之前为新实例提供足够的时间上线。

看来您最感兴趣的功能是当您使用修改后的启动配置运行 CloudFormation 更新时调用的 UpdatePolicy。神奇的属性是 WaitOnResourceSignals，它强制 ASG 在认为更新成功之前等待成功信号。

  "UpdatePolicy" : {
    "AutoScalingRollingUpdate" : {
      "MinInstancesInService" : "1",
      "MaxBatchSize" : "1",
      "PauseTime" : "PT15M",
      "WaitOnResourceSignals" : "true"
    }
  },

当 WaitOnResourceSignals 属性设置为 true 时，PauseTime 属性将变为超时。如果ASG在15分钟的PauseTime内没有收到信号，则认为更新失败，新实例被终止。一旦 ASG 收到成功信号，ASG 运行状况检查就会开始发挥作用，除非 HealthCheckGracePeriod 尚未过期。我们通常将 HealthCheckGracePeriod 设置为与 PauseTime 相同的值。这确保了在实例有机会发送信号或达到 PauseTime 超时之前我们永远不会开始使用 ELB 运行状况检查。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html

通常，成功信号会按照 cfn-init 引导脚本从 ASG 启动配置的 UserData 中发送到 ASG。

"UserData"       : { "Fn::Base64" : { "Fn::Join" : ["", [
     "#!/bin/bash -xe\n",
     "yum update -y aws-cfn-bootstrap\n",

     "/opt/aws/bin/cfn-init -v ",
     "         --stack ", { "Ref" : "AWS::StackName" },
     "         --resource LaunchConfig ",
     "         --configsets full_install ",
     "         --region ", { "Ref" : "AWS::Region" }, "\n",

     "/opt/aws/bin/cfn-signal -e $? ",
     "         --stack ", { "Ref" : "AWS::StackName" },
     "         --resource WebServerGroup ",
     "         --region ", { "Ref" : "AWS::Region" }, "\n"
]]}}

这对于许多情况来说已经足够了，但有时当我们将成功信号发送回 ASG 时实例可能仍然没有准备好。例如，我们可能想要等待后台进程加载数据或等待应用程序服务器启动。如果我们的 ELB 运行状况检查针对的是需要我们的应用程序运行的 URL，则尤其如此。在这些情况下，我们希望延迟成功信号，直到我们的实例准备就绪。以下示例展示了如何创建启动配置配置集以延迟信号，直到 ELB API 返回实例的“InService”状态。

  "verify_instance_health" : {
    "commands" : {
      "ELBHealthCheck" : {
        "command" : { "Fn::Join" : ["", [ 
          "until [ \"$state\" == \"\\\"InService\\\"\" ]; do ",
          "  state=$(aws --region ", { "Ref" : "AWS::Region" }, " elb describe-instance-health ",
          "              --load-balancer-name ", { "Ref" : "ElasticLoadBalancer" }, 
          "              --instances $(curl -s http://169.254.169.254/latest/meta-data/instance-id) ",
          "              --query InstanceStates[0].State); ",
          "  sleep 10; ",
          "done"
        ]]}
      }
    }
  }

请参阅此论坛以获取更多信息和使用 ELB 运行状况检查的完整示例 - https://forums.aws.amazon.com/ann.jspa?annID=2741

注意:这些示例还要求您在 ASG 创建期间使用 ASG CreationPolicy 属性来接收信号。过去，WaitCondition 和 WaitConditionHandle 资源用于接收信号，但不再推荐使用这些资源。 Count 属性是创建时应接收的信号数量。该值应等于 ASG MinSize 数字。

  "CreationPolicy" : {
    "ResourceSignal" : {
      "Timeout" : "PT15M",
      "Count"   : "2"
    }
  },

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-creationpolicy.html