【问题标题】:Use Application Autoscaling Group with ELB Healthchecks将应用程序自动缩放组与 ELB 运行状况检查一起使用
【发布时间】:2019-03-17 21:21:33
【问题描述】:

是否有人成功使用应用程序自动缩放组进行 ELB 运行状况检查。它一遍又一遍地替换实例。有没有办法防止这种情况发生?

我的模板是这样的:

Resources:
  ECSAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AvailabilityZones:
        - Fn::Select:
          - '0'
          - Fn::GetAZs:
            Ref: AWS::Region
        - Fn::Select:
         - '1'
         - Fn::GetAZs:
             Ref: AWS::Region
      - Fn::Select:
         - '2'
         - Fn::GetAZs:
             Ref: AWS::Region
     VPCZoneIdentifier:
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet1
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet2
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet3
    HealthCheckGracePeriod: !Ref ASGHealthCheckGracePeriod
    HealthCheckType: !Ref ASGHealthCheckType
    LaunchTemplate:
      LaunchTemplateId: !Ref ECSLaunchTemplate
      Version: 1
    MetricsCollection:
      - Granularity: 1Minute
    ServiceLinkedRoleARN:
     !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling
    DesiredCapacity: !Ref ASGDesiredCapacity
    MinSize: !Ref ASGMinSize
    MaxSize: !Ref ASGMaxSize
    TargetGroupARNs:
    - Fn::ImportValue: !Sub ${EnvironmentName}-WebTGARN
      Fn::ImportValue: !Sub ${EnvironmentName}-DataTGARN
      Fn::ImportValue: !Sub ${EnvironmentName}-GeneratorTGARN
    TerminationPolicies:
    - OldestInstance

Launch 模板如下所示:

ECSLaunchTemplate:
  Type: AWS::EC2::LaunchTemplate
  Properties:
    LaunchTemplateName: ECSLaunchtemplate
    LaunchTemplateData:
      ImageId: !FindInMap [AWSRegionToAMI, !Ref "AWS::Region", AMI]
      InstanceType: !Ref InstanceType
      SecurityGroupIds:
      - Fn::ImportValue: !Sub ${EnvironmentName}-ECSInstancesSecurityGroupID
    IamInstanceProfile:
        Arn:
          Fn::ImportValue:
            !Sub ${EnvironmentName}-ecsInstanceProfileARN
    Monitoring:
      Enabled: true
    CreditSpecification:
      CpuCredits: standard
    TagSpecifications:
     - ResourceType: instance
       Tags:
       - Key: "keyname1"
         Value: "value1"
    KeyName:
      Fn::ImportValue:
        !Sub ${EnvironmentName}-ECSKeyPairName
    UserData:
      "Fn::Base64": !Sub
        - |
          #!/bin/bash
          yum update -y
          yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
          yum update -y aws-cfn-bootstrap hibagent
          /opt/aws/bin/cfn-init -v --region ${AWS::Region} --stack ${AWS::StackName} --resource ECSLaunchTemplate --region ${AWS::Region}
          /opt/aws/bin/cfn-signal -e $? --region ${AWS::Region} --stack ${AWS::StackName} --resource ECSAutoScalingGroup
          /usr/bin/enable-ec2-spot-hibernation
          echo ECS_CLUSTER=${ECSCluster} >> /etc/ecs/ecs.config
         PATH=$PATH:/usr/local/bin
        - ECSCluster:
            Fn::ImportValue:
              !Sub ${EnvironmentName}-ECSClusterName

负载均衡器配置如下所示:

ApplicationLoadBalancerInternet:
   Type: AWS::ElasticLoadBalancingV2::LoadBalancer
   Properties:
     Name: !Sub ${EnvironmentName}-${Project}-ALB-Internet
     IpAddressType: !Ref ELBIpAddressType
     Type: !Ref ELBType
     Scheme: internet-facing
     Subnets:
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet1
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet2
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet3
     SecurityGroups:
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-ALBInternetSecurityGroupID

如前所述,它与 EC2 健康检查工作正常,但当我切换到 ELB 健康检查时,实例正在耗尽,ASG 启动一个新实例。

谢天谢地

【问题讨论】:

  • 更换实例有问题吗?如果你愿意,你可以使用容器,所以它只是替换容器图像
  • 是的,但仍然没有任何意义。我想知道这些实例出了什么问题,因为如果每 5 分钟更换一次,肯定是有问题。
  • 如果您在应用程序自动缩放中使用了哪种应用程序? Application Autoscaling - Resource Type
  • 您应该提供您的模板以供我们帮助。我的猜测是您的 ELB 无法联系您的实例进行健康检查,因此它一直将它们标记为不健康并被替换。 5 分钟听起来像是 300 秒的默认连接耗尽。
  • @tyron,我已经添加了模板,谢谢处理这个话题。一个

标签: amazon-cloudformation


【解决方案1】:
  • 我会这样排除故障:
    1. 删除此堆栈。
    2. 编辑您的模板并将 ASG 运行状况检查类型更改为 ELB(暂时)。
    3. 从 CLI 或控制台创建新堆栈。我推荐 CLI,因为您可能需要重新创建它,而且它比控制台更简单/更快。 最重要的步骤是在堆栈失败时启用“Disable-Rollback”功能,否则您将无法找出失败的原因
    4. 我相信您还将创建一些 IAM 资源作为此模板的一部分,因此示例 CLI 命令将如下供您快速参考: aws cloudformation create-stack --stack-name Name-of-your-stack --template-body file://template.json --tags Key=Name,Value=Your_Tag_Value --profile default --region region --capabilities CAPABILITY_NAMED_IAM --disable-rollback yes
    5. 有关 CAPABILITY_NAMED_IAM 要求的更多信息,请参阅this SO answer。
    6. 现在,当您创建堆栈时,它仍然会失败,但现在我们可以对其进行故障排除。我们在步骤 2 中将运行状况检查类型保留为 ELB 的原因是,我们实际上希望 ASG 替换运行状况检查失败的实例,我们可以在控制台的 ASG 的“活动历史记录选项卡”中找到原因。
    7. 很有可能您会看到比 CloudFormation 返回的更有意义的消息。
    8. 既然您有该错误消息,请将 ASG 的运行状况检查类型从控制台更改为 EC2,因为我们不希望 ASG 启动 EC2 实例的“启动和终止”循环。李>
    9. 现在,登录到您的 EC2 实例并查找访问日志以及来自您的 ELB 运行状况检查的命中。在 httpd 中,成功的运行状况检查会获得 HTTP 408。
    10. 另外请注意,如果 ELB 健康检查类型是 TCP:80,那么您的服务器上没有任何端口冲突,并且如果您选择了 HTTP:80,那么您已经指定了路径/文件以及您的 ping 目标。
    11. 由于您的脚本也包含一些用户数据,请同时查看 /var/log/cfn-init.log 和其他条目以了解任何错误消息。一个简单的选择是,grep error /var/log/*
    12. 现在,此时,您只需要确保 ELB 运行状况检查成功并且 ELB 后面的实例“投入使用”,最重要的步骤是 记录所有故障排除步骤,因为您从未知道,在您尝试的许多步骤中,哪一步实际上修复了此运行状况检查。
    13. 一旦找到原因,只需将其放入模板中即可。我看到很多模板在第 8 步出错。
    14. 此外,不要错过再次将 ASG 健康检查更改为 ELB。

【讨论】:

    猜你喜欢
    • 2017-02-22
    • 2016-01-25
    • 2015-02-04
    • 2019-02-21
    • 2019-08-07
    • 2016-01-21
    • 2013-12-01
    • 1970-01-01
    • 2014-04-20
    相关资源
    最近更新 更多