如何在相对复杂的基础架构中正确自动扩展AWS EC2 Instances组？

Question

我正在努力在Amazon Cloud上迁移我们的服务器,理由是自动扩展可能性,成本,服务等等.

到目前为止,我正在努力尝试并试图深入研究全功能的文档,但由于没有以前的经验,我有很多问题.

设想的基础设施如下:

                                  +-----+
                                  | ELB |
                                  +--+--+
                                     |
                +--------------------|--------------------+
                |            Auto-Scaling Group           |
                |--------------------|--------------------|
                |                    |                    |
                |  +---------+       |       +---------+  |
                |  | varnish |<------+------>| varnish |  |
                |  +----+----+               +---------+  |
                |       |                         |       |
                +-----------------------------------------+
                        |                         |
                        |                         |
                        |     +------------+      |
                        +---->|Internal ELB|<-----+
                              +------+-----+
                                     |
                +-----------------------------------------+
                |            Auto-Scaling Group           |
                |-----------------------------------------|
                |  +---------+       |       +---------+  |
                |  | Apache  |<------+------>| Apache  |  |
                |  +----+----+               +----+----+  |
                |       |                         |       |
                +-----------------------------------------+
                        |         +-----+         |
                        +-------->| RDS |<--------+
                                  +-----+

换句话说,我会使用Elastic LoadBalancer将流量发送到Varnish实例,Varnish实例又将流量发送到内部Elastic LoadBalancer,后者将流量发送到Apache前端.

就目前而言,我发现了AWS工具,就像CloudFormation服务似乎能够在给定模板的情况下引导实例一样,这看起来很棒,但它似乎只能引导.

有一点经验Puppet(并且考虑到AWS对这个主题的推荐)我喜欢Puppet Master的东西,这是一个很棒的工具.

我的想法可能不可行或不现实,就是使用CloudFormation模板创建一个"Puppet Node Stack" ,它将根据需要配置实例并连接要配置的puppet master.

一旦我有一个堆栈准备好了,我不知道如何配置/创建自动缩放组都Varnish和Apache实例.

CFN似乎有资源配置自动扩展组和策略,所以我想我可以为每个创建两个不同的模板.

但AS功能是否会通过CFN服务运行,然后执行所有init事务(并执行user-data)？

我也在这里和那里读到Puppet可以使用EC2标签,也许一个通用的堆栈模板与相应的标签(如角色)可以做到这一点？

这种架构是否真实可行？你有什么反馈意见吗？

谢谢你的建议.

Answer 1

自动缩放基于启动配置创建新节点.因此,您将拥有两个单独的自动缩放组和两个单独的启动配置.即

"VarnishScalingGroup" : {
  "Type" : "AWS::AutoScaling::AutoScalingGroup",
  "Properties" : {
    "LaunchConfigurationName" : {"Ref" : "VarnishLaunchConfiguration" },
    "LoadBalancerNames" : {"Ref" : "ELB"},
    ...
  }
},
"VarnishLaunchConfiguration" : {
  "Type" : "AWS::AutoScaling::LaunchConfiguration",
  "Properties" : {
    ...
    "UserData" : {
      ....
    },
    "MetaData" : {
      ...
    }
 },
"ApacheScalingGroup" : {
  "Type" : "AWS::AutoScaling::AutoScalingGroup",
  "Properties" : {
    "LaunchConfigurationName" : {"Ref" : "ApacheLaunchConfiguration" },
    "LoadBalancerNames" : {"Ref" : "InternalELB"},
    ...
  }
},
"ApacheLaunchConfiguration" : {
  "Type" : "AWS::AutoScaling::LaunchConfiguration",
  "Properties" : {
    ...
    "UserData" : {
      ....
    },
    "MetaData" : {
      ...
    }
 }

您要添加的另一件事是针对每个扩展组的单独扩展策略,以及要匹配的相应CloudWatch指标.

CloudFormation还可以启动堆栈更新.如果作为你使用cfn-hup的用户数据的一部分,那么它将定期(你决定)检查堆栈元数据的变化 - 然后执行你喜欢的任何内容.我倾向于启动另一个版本的cfn-init - 它将解析和更新任何元数据.

关键点 - 如果你沿着cfn-hup路径走,它将不会再次执行userdata,除非CloudFormation堆栈需要删除并创建新实例.

另外一点,如果要推出LaunchConfiguration的更新,则需要确保LaunchConfiguration还应用了UpdatePolicy.