Amazon EC2，将节点加入现有集群的最快方式

Question

我是亚马逊 AWS 的新手。很多时候我听说人们生成实例并几乎立即将它们置于负载均衡器后面并放入现有集群中。

在传统的受管机器世界中，这将包括配置硬件、安装操作系统、在机器上配置网络，一旦网络可用，使用您选择的工具（例如 CFengine、Puppet 或 Chef）来引导机器。它的类。

似乎存在能够在 Amazon EC2 中启动和运行特定类别的服务器的“快捷方式”。如果我的服务器上运行了一个特定的堆栈，例如 erlang、tomcat6 等。让这些堆栈启动并运行并连接到亚马逊负载均衡器的最快方法是什么？从网络到软件堆栈再到内核调优？它是创建 AMI 然后针对新实例运行 Puppet 之类的工具的组合吗？

任何的想法

Answer 1

简短的回答：

这取决于您的应用程序 - AMI 始终是起点，您在实例启动时需要多少自定义实例将决定除了简单的“负载均衡器后面的自动缩放实例”示例之外您还需要什么。

不是那么简短的答案：

EC2 上的实例与 VPS 非常相似——事实上，它们是虚拟机（亚马逊使用 Xen 虚拟化）。我看到 VPS 和“云”服务器之间的主要区别在于易于部署——在“云”中配置和添加十几个实例或几百 GB 的存储应该是一项微不足道的任务。

由于亚马逊使用虚拟机，他们拥有这些机器的“图像”。这些图像引用存储并包含对默认内核的引用（您可以更改）。此映像的内容通常用于创建附加到实例的根卷。

您在很大程度上无法使用 Amazon 提供的（相当多的）内核——编译自己的内核通常不是一种选择——但您可以设置大多数参数并利用可用的内核模块来实现您想要的。一旦您创建了自己的 AMI，您从中启动的所有实例都将相同（除了您让 AMI 运行以自定义自身的任何脚本）。这使它成为几乎所有情况的起点。

事物的“虚拟”性质有一些明确的好处。例如，您可以通过简单地停止实例、分离根卷、附加新卷并启动实例备份来切换根卷。同样，您可以通过停止实例、修改实例属性并再次启动实例来更改实例类型。

当您启动一个实例时，您需要指定（除其他外）实例类型（例如 m1.large）和 AMI。这意味着您的实例将使用该 AMI 上保存的所有内容启动 - 预配置的操作系统、您安装的任何软件等。此外，AMI（或 ec2-run-instances 命令）可以引用额外的存储 - 临时或EBS 支持。对于额外的 EBS 存储卷，这些可以从现有快照创建并在实例启动时附加到您的实例。（有趣的是，这些快照的内容是“延迟”加载的——这意味着您可以在快照完全加载之前访问它们上的数据，这在加载大量卷时是有利的）。

考虑最简单的场景——一个所有机器都等价的集群——首先，假设我们正在为一个静态站点提供服务。EC2 将让您垂直扩展（更强大的实例）和水平扩展（更多实例）。所以，我们从最小的实例开始——一个 t1.micro，我们发现最终它无法处理负载。我们现在可以在弹性负载均衡器 (ELB) 后面添加第二个实例。因此，传入的请求将进入 ELB（设计时应考虑到冗余和可扩展性——它应该自动添加更多资源以满足对其的需求）——并将其路由到其中一个实例，该实例将处理请求并通过负载均衡器返回它。

为了使流程更加自动化，我们可以使用 Amazon 的自动缩放——本质上，使用触发器（Cloudwatch 指标的值），您可以动态添加和删除实例（就像手动启动实例一样，您可以指定实例类型和 AMI新实例）。此外，这些实例可以（它们不一定）与基于某些指标（例如 CPU 负载、RAM 使用或某些其他自定义变量）的变化自动增长或缩小集群的 ELB 相关联。

现在 - 关于上述场景的几乎所有内容都是“不好的做法” - 您可能不应该从 t1.micro 水平扩展，因为它们是功能不足的实例 - 所以您首先要增加实例大小；ELB 的成本远高于（保留的）t1.micro 的成本，因此在这种情况下（经济上）不切实际；如果您在 AWS 上为静态站点提供服务，您只需使用 S3 并完全放弃实例的费用和麻烦，但重点是一个说明。

让我们举一个更复杂的例子——一个 PHP/MySQL 站点（例如 Wordpress）。首先，我们将数据库与 Web 服务器分开 - 所以让我们从每个实例开始 - 我们现在可以独立扩展每个实例。可以说，我们可以使用 Amazon 的 RDS（尽管我个人更喜欢维护自己的 MySQL 设置）而不是自己托管 MySQL，这将简化额外 MySQL 实例的部署（......当然是有代价的）。我们的网络服务器都提供相同的内容，但现在内容可能会发生变化。存储在数据库中的更改（例如新文章、评论等）不是问题 - 所有服务器都从同一个数据库实例读取。理想情况下，您将代码存储在某个中心位置（例如 S3），并且每个实例在启动时都会拉取它。静态资产可以从 CDN 提供服务，这样您就可以避免在本地处理分布式文件系统。（ELB 可以处理粘性会话，但最好是简单地集中存储会话（例如 Memcached），以便所有实例都可以访问它们 - 请记住，请求可以在任何实例上结束）。

（AWS 确实有 Elastic Beanstalk - 它应该处理某些类应用程序（例如 PHP/MySQL）所需的资源的配置 - 但我没有个人经验）。

对于更复杂的设置，您可以将用户数据传递给实例，并且有一些方法可以获取您正在运行的所有实例的列表（并且您可以根据需要标记您的实例以将它们分组）。您可以在消息队列中处理任务（Amazon 版本是 Simple Queue Service...或者如果您愿意，可以使用开源版本），以便确保您的集群只处理每个请求一次。当然，您也可以使用典型的高可用性工具（例如 Heartbeat/Corosync、Pacemaker 等）来控制您的集群——这将使所有节点“知道”彼此，并让您控制运行的资源每个节点。添加分布式文件系统（例如 Gluster），您可以处理大多数情况。

除此之外，您仍然可以使用您提到的相同工具。上面的大多数想法都是基于多次部署相同的 AMI（您自定义 AMI，并启动它的多个副本 - 每个副本都应该配备处理自己的基本配置（例如，提取最新代码等）） . 如果您的实例将经常更改，或者您有一个更大的集群（例如，将更改部署到所有节点会出现问题），或者您的节点不相似 - 那么您可以选择部署节点配置管理软件（例如 Puppet、Chef 等）。

您还可以执行另一个步骤 - 即配置您自己的“虚拟专用网络” - 本质上，允许您使用 NAT 创建一些面向私人和一些面向公共的实例，并控制私有 IP 地址和网络接口（例如，您可以在单个实例上有多个接口）。

最后，你如何部署你的应用程序很大程度上取决于应用程序的需求——每个节点需要共享什么信息，你的集群中有多少节点，哪些节点相互依赖。最简单的场景始终是每个节点可以相互独立运行，并且发送到任何节点的请求将产生相同的结果……启动一个实例，自定义它，创建您的 AMI，并在 ELB 后面自动扩展它. 所有其他场景都需要一些计划来设计可以有效扩展的东西。

鉴于上述情况，我觉得指出另一面很重要——AWS 是一项很棒的服务——因为进入门槛很低——你基本上可以免费学习它（他们确实有一个免费套餐）——你就可以可以根据您的需求进行扩展。但是，AWS 上的每一件事都要收费——运行实例的小时数、存储的 GB 数量、磁盘上的 I/O 数量、您对 S3 发出的请求数量、（传出）您使用的带宽 - 一切。不可预见的事情很容易在相当短的时间内积累大量账单。AWS 绝对不是所有问题的解决方案，它也并非没有局限性（例如，其网络上没有广播/多播数据包）。

（好吧，这最终比我打算写的几行要多一些......）