每个网站 1 个 EC2 实例 - 使用 EC2 在 Amazon 云上管理多个网站

eri*_*icn 7 lamp web-server wordpress amazon-ec2 amazon-web-services

我正在管理多个网站,大多数基于 WordPress,并且都基于 LAMP 堆栈。我正在将所有网站迁移到亚马逊云。我是 AWS 的新手,我的计划是从我最小的网站开始一个一个地移动网站。

我的问题是我应该将我的所有网站放在 1 个 EC2 实例上还是将 1 个网站放在 1 个单独的实例上?

这可能听起来很愚蠢,因为在传统的网络托管环境中,任何人肯定会选择后者。我对前者有想法的原因是:

  • 可重复使用的 LAMP 堆栈
    • 我可以使用 LAMP 堆栈生成我自己的 AMI,以便我可以将其重复用于不同的网站吗?我不去社区 AMI 的原因是
      • 我只是不知道该用哪个
      • 作为一个对 Linux 或 LAMP 堆栈不太了解的人,我想要我需要的东西,不多也不少
  • 成本:将每个站点放在 1 个单独的大型实例上与将每个站点放在较小的实例上。我不认为应该是这种情况,但我认为问这个没有害处
  • 难以管理多个实例

可扩展性

我敢肯定,在几个月后,我将需要比现在多 3 倍的计算能力(新站点已启动,现在我有 6 个,届时我将有 10 个;现有站点的流量增长迅速)。不管怎样,假设我决定进行水平缩放,例如使用我目前正在使用的相同类型的 3 个实例。

所以我进一步的问题是,这种情况将如何影响我决定是否应该分离我的站点或将所有站点放在 1/1 组 EC2 实例上?

我知道这可能与我仍在阅读的 Amazon 云上的垂直和水平扩展之间的差异有关。这也可能与有关虚拟机/服务器的知识有关,我对此完全是个白痴,但不介意在必要时了解更多信息。但是,我想我应该问一下,因为这可能会影响我应该使用 Amazon 云的方向。如果你觉得我很懒惰,应该先做功课,请随意给我一巴掌:)

非常感谢所有帮助!

免责声明:请告知是否应将其发布在 superuser.com 或任何 stackexchange 站点上。谢谢

cyb*_*x86 10

首先,一些原始数据取自S. Ostermann 等人,2010 年

基本实例规格:

+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
|   Name    |  ECUs   | RAM  | Archi |  I/O  | Disk | Cost  |    Reserve    | Reserved Cost |
|           | (Cores) | [GB] | [bit] | Perf. | [GB] | [$/h] | [$/y], [$/3y] | [$/h]         |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
| m1.small  | 1 (1)   | 1.7  | 32    | Med   | 160  | 0.1   | 325, 500      | 0.03          |
| m1.large  | 4 (2)   | 7.5  | 64    | High  | 850  | 0.4   | 1300, 200     | 0.12          |
| m1.xlarge | 8 (4)   | 15   | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
| c1.medium | 5 (2)   | 1.7  | 32    | Med   | 350  | 0.2   | 650, 1000     | 0.06          |
| c1.xlarge | 20 (8)  | 7    | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
Run Code Online (Sandbox Code Playgroud)

基本性能/成本分析:

+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
|    System     | Peak Perf. |   HPL    | STREAM | RandomAc. | Latency | Bandw. | GFLOP/ECU | GFLOPS/$ |
|               | [GFLOPS]   | [GFLOPS] | [GBps] | [MUPs]    | [µs]    | [GBps] |           |          |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
| m1.small      | 4.4        | 1.96     | 3.49   | 11.6      | -       | -      | 1.96      | 19.6     |
| m1.large      | 17.6       | 7.15     | 2.38   | 54.35     | 20.48   | 0.7    | 1.79      | 17.9     |
| m1.xlarge     | 35.2       | 11.38    | 3.47   | 168.64    | 17.87   | 0.92   | 1.42      | 14.2     |
| c1.medium     | 22         | 3.91     | 3.84   | 46.73     | 13.92   | 2.07   | 0.78      | 19.6     |
| c1.xlarge     | 88         | 51.58    | 15.65  | 249.66    | 14.19   | 1.49   | 2.58      | 64.5     |
| 16x m1.small  | 70.4       | 27.8     | 11.95  | 77.83     | 68.24   | 0.1    | 1.74      | 17.4     |
| 16x c1.xlarge | 1408       | 425.82   | 16.38  | 207.06    | 45.2    | 0.75   | 1.33      | 33.3     |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
Run Code Online (Sandbox Code Playgroud)

实际性能通常低于理论性能的 50%。一组可能值得怀疑的值是 c1.medium 的值,它们与预期结果(例如带宽)不太一致。

对于典型工作负载,EC2 的主要成本是实例成本 - 其他成本(带宽、预置存储等)通常不到总成本的 25%。人们并不期望性能能够完美地扩展——这从上面的数据中可以明显看出。尤其是在横向扩展方面,似乎随着您添加更多计算容量,效率会显着下降。

鉴于上述情况,并记住除了原始计算性能之外还有其他因素(例如 I/O 性能、内存等),因此垂直扩展是最经济的方法是理所当然的。

不幸的是,除了场景的经济性之外,还有其他考虑因素。可靠性是关键。对于单个实例,该实例的故障会破坏您的整个设置。一种可能的解决方案可能是自动缩放(即保持实例计数为 1),但是单个实例仍然容易出现在给定可用区等中可能发生的问题。

在某些时候,有必要横向扩展 - 问题只是何时是理想时间之一。我可能会建议: - 至少垂直扩展几个实例大小(如果您从 t1.micro 开始,则更是如此) - 将您的数据库分开到单独的实例(因为它们的扩展方式与您的 Web 服务器的扩展方式不同)-水平扩展,直到有一点冗余 - 垂直扩展,直到达到最大实例大小 - 之后水平扩展(最初可能使用较小的实例)

回到手头的问题 - 每个实例(或每组实例)运行一个网站总是会更昂贵。除了较高的固定成本(例如,每个网站一个负载均衡器,而不仅仅是一个负载均衡器),您将无法有效地利用您的实例(即,一个网站可能会在其他网站出现高负载时出现高负载)大多数情况下是空闲的 - 这意味着您有一些实例超载,而另一些则闲置)。在后勤方面,问题可能并不像人们想象的那么严重——主要问题归结为独立管理一切(您可以使用一些配置管理工具(例如 Puppet/Chef)来避免这种情况,但这通常不是一个步骤直到您的设置变得更大一些)。

另一方面,EC2 实例的一个限制是您只能为给定实例分配一个公共 IP 地址(这对某些 SSL 设置有一些影响)。

您当然可以生成自己的 AMI - 实际上这是相当标准的做法。我通常从亚马逊的 Linux AMI 开始因为我发现它是一个开销最少的(资源很容易,而且速度很快)和 AWS 支持最好的(它定期更新等) - 我更喜欢 RHEL/CentOS 发行版(亚马逊的 Linux 是基于)到 Debian/Ubuntu 是另一个流行的选择。自定义实例后,您可以拍摄 EBS 卷的快照并注册 AMI - 传递快照 ID 作为根卷所基于的映像。理论上,您可以更多地自定义您的操作系统,甚至可以构建您自己的发行版(但仍使用 Amazon 内核)——但是,除非您有一个非常具体的用例,否则这不太可能特别有益。我个人对运行 Wordpress 的偏好,

最后,再次解决缩放问题。除了上面讨论的问题的基本经济学之外,困难归结为使多个实例“出现”为一个。这包括确保每个实例都提供相同的数据、实例之间的负载平衡,以及可能处理 PHP 会话等细节。如果每个站点都在自己的一组实例上运行,这将更加困难 - 但可能不会有很大的差距(因为您希望将功能配置到您的 AMI 中)。然而,多个实例确实意味着一个更复杂的系统,以及更多需要关注的事情。(在 ServerFault 上有很多关于此主题的问题,例如thisthis , or this - 如果您需要有关如何扩展特定设置的详细信息,请将其作为另一个问题提出)。

作为总结性评论 - 除非您的设置特别需要单个站点在其自己的实例/集群上运行(例如截然不同的配置/要求),否则我倾向于在单个实例/集群上运行多个站点,因为它更简单规模、更经济、更高效,更符合“云计算”的精神(即共享资源)。

参考: