从 Rackspace 迁移到 EC2 - EBS 与实例存储

Question 1

有两种存储可以附加到实例：临时存储和弹性块存储 (EBS)。顾名思义，临时存储是临时的 - 并且仅在实例运行时存在（如果实例停止或终止，它将被销毁）。临时存储不能在实例之间“转移”（即从一个实例分离并附加到另一个实例）。实例存储数据在重新启动后仍然存在，而不会停止实例（即从控制台运行重新启动）。EBS 存储独立于实例而存在，并且 EBS 卷可以在实例之间转移（在同一可用区域内）。此外，您可以拍摄 EBS 卷的快照，从而允许对卷内容的压缩映像进行差异（即增量）存储（允许您轻松地在不同区域创建新卷等）。符合临时存储条件的实例无需额外费用即可获得它。另一方面，EBS 存储按 a) 预置量和 b) I/O 使用量计费。

Instance-store 使用 S3 来存储 AMI 数据，并提供临时根以及额外的临时存储。当任务需要大量临时存储，并且只有极少量数据需要永久保留时，这种方法非常有用。通常，临时存储适用于临时文件和交换空间。如果您将数据存储在临时卷上，则可能应在启动时从“主源”复制数据，并且数据（在临时磁盘上）应该没有价值。（例如，如果您正在运行应用程序，则可以将代码存储在外部，在服务器启动时将最新版本下载到临时磁盘，然后在服务器上本地运行该应用程序，所有数据存储在其他地方（例如 EBS、RDS 等））

通常，建议使用 EBS - 既作为根卷，又作为数据存储介质。EBS 允许您轻松更改实例类型、修改根分区大小、备份数据，并且由于您可以将 EBS 卷附加到其他正在运行的实例，因此大大方便了处理问题。使用 EBS，您可以将代码直接存储在 EBS 卷上，并且您所做的任何更改都将保留。此外，您可以将快照附加到实例，这样启动的所有实例在其附加的 EBS 卷上都会有相同的数据（即数据来自快照）。除非您有从实例存储架构中受益的特定需求，否则 EBS 是最佳选择。

（还有另一种选择，但对于代码/数据库来说，这通常不切实际。您可以使用 fuse 将 S3 存储桶挂载为本地文件系统 - 优点是无限的、未配置的存储（即您的文件可以增长而无需预先分配一定量的空间） - 这对于上传、图片等可能是用户贡献的内容非常有用。缺点是性能 - 写入 S3 的速度远不及 EBS 或临时存储，存在明显的滞后，这使得应用程序的核心组件无法接受。）

回顾：代码必须在本地可用 - 要么将其存储在 EBS 上（推荐），要么将其下载到服务器的临时磁盘（即，您的代码被复制到机器上以供使用，但驻留在其他地方）。

对于 MySQL，如果您要管理自己的 MySQL，则需要 EBS 卷，或者可以使用 Amazon 的 RDS。有些人已经注意到，运行自己的 MySQL 服务器可以以更低的成本获得更好的性能。这里使用 EBS 的原因是，维护临时磁盘上运行的不断变化的数据库的最新备份将极其困难。这意味着，如果您使用临时磁盘并且实例崩溃，您将丢失自上次备份以来的所有数据，这通常是不可接受的。数据库实际上不能存储在 S3 上，因为性能不足以实现此目的。

AWS 提供“弹性负载均衡器”，可在您与之关联的实例之间分配负载。它能够在区域之间分配负载，并尝试避免单点故障和单个实例的限制（例如网络 I/O）。它不支持“静态”IP（在 AWS 上称为弹性 IP），因此您必须使用 CNAME 来访问它（即您无法将 ELB 映射到您的根域）。此外，源 IP 通常设置为 ELB IP，这意味着您需要使用“X-Forwarded-For”标头进行日志/分析。如果您愿意，您仍然可以使用 nginx 或 HAproxy 作为负载均衡器，但是请记住，这会导致所有网络流量都通过该单个实例，如果您的应用程序需要高带宽，这通常会成为瓶颈。但是，与 AWS 上的其他所有内容一样，您需要按使用量付费 - ELB 既按其运行时间计费，也按通过它们的数据计费。

最后，AWS 命令可以从任何地方运行 - 它们通过您传递给它们的凭据输入到您的帐户中，并针对特定资源（例如实例、EBS 卷等）运行，因为您将为给定命令指定关联的 ID。只有少数命令（例如捆绑/上传 AMI）需要（本地）访问相关文件，必须从特定计算机（即有权访问所需文件的计算机）运行。即使是引用附加到实例的资源的命令（例如拍摄 EBS 卷的快照）也可以从安装了工具的任何计算机（相关实例、您的开发箱、另一个实例等）运行。

Answer