4

サーバーを Amazon Cloud に移行する作業を行っています。その理由は、明らかに、自動スケーリングの可能性、コスト、サービスなどです。

これまでのところ、私は熱心に実験し、フル機能のドキュメントに飛び込もうとしていますが、以前の経験がないため、多くの質問があります.

想定されるインフラストラクチャは次のとおりです。

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

つまり、Varnish インスタンスにトラフィックを送信する Elastic LoadBalancer があり、Varnish インスタンスはトラフィックを内部の Elastic LoadBalancer に送信し、トラフィックを Apache フロントエンドに送信します。

今のところ、CloudFormationテンプレートを指定してインスタンスをブートストラップできるように見えるサービスのような AWS ツールを発見しました。これは素晴らしいようですが、ブートストラップしかできないようです。

少し経験がありPuppet(そしてこの件に関して AWS の推奨を受けている)、私は素晴らしいツールである Puppet Master に飛び込みました。

実行可能または現実的ではないかもしれない私の考えは、テンプレートを使用して「Puppet Node Stack」を作成するCloudFormationことです。これにより、必要に応じてインスタンスが構成され、プロビジョニングされる puppet マスターが接続されます。

スタックの準備ができたら、とインスタンスの両方の Auto-Scaling グループを構成/作成する方法を考えています。VarnishApache

CFN には Auto Scaling グループとポリシーを構成するためのリソースがあるようです。そのため、それぞれに 2 つの異なるテンプレートを作成できると思います。

しかし、AS 機能は CFN サービスを介して実行され、すべての init 処理 (および実行user-data) を実行しますか?

私はまた、PuppetがEC2タグを利用できることをあちこちで読みました.おそらく、対応するタグ(ロールなど)を持つ汎用スタックテンプレートでうまくいくでしょうか?

このアーキテクチャは現実的で実行可能ですか? フィードバックはありますか？

アドバイスありがとうございます。

4

2 に答える 2

5

自動スケーリングは、起動構成に基づいて新しいノードを作成します。したがって、2 つの個別の Auto Scaling グループと 2 つの個別の起動構成を持つことになります。すなわち

"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 パスをたどると、CloudFormation スタックが新しいインスタンスを削除して作成する必要がない限り、ユーザーデータを再度実行することはありません。

もう 1 つのポイントとして、LaunchConfiguration の更新をロールアウトする場合は、LaunchConfiguration にも UpdatePolicy が適用されていることを確認する必要があります。

于 2013-08-13T22:35:27.847 に答える
2

「Puppet ノード スタック」を使用する代わりに、パペットを使用してマシンをプロビジョニングし、AMI を作成できるパッカー ( http://www.packer.io/ ) などのツールを使用して、AMI を事前に構築することを検討することをお勧めします。次に、プロビジョニングされた AMI を cloudformation テンプレートに追加します。

Peter H. が言うように、cloudformation はスタックの更新を処理できます。そのため、パペットのセットアップに変更を加えると、新しい AMI を構築し、cloudformation で起動設定を更新できます。自動スケーリングは、新しいインスタンスの自動スケーリングに新しい AMI を使用して開始されます。

Cloudformation から puppet を取り出すことで、インフラストラクチャとサーバー構成の間の懸念事項を分離できます。

すでに Apache/Varnish がセットアップされているビルド済みの AMI を使用すると、スケールアップがより迅速に行われます。

マスターレスのパペット設定にも利点があります。すなわち。分散型、障害点として puppetmaster がないなど。https://serverfault.com/questions/408261/pros-and-cons-of-a-decentralized-puppet-architectureを参照

于 2013-12-03T12:32:59.797 に答える