服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 从Rackspace迁移到EC2 – EBS vs.实例库
Intereting Posts
自定义身份validation处理程序的mod_auth_form？ ADCS – 如何诊断证书请求被策略模块拒绝的确切原因？ 通过VPN进行应用authentication 为什么在慢速查询日志中设置时间戳？ build议强调可靠性的开源文件系统 没有物理场所的全球公司的Active Directory部署 Rackspace Cloudserver备份选项 每次调用smtp服务器时，所有应用程序都会出现超时错误 使用sendmail发送邮件到Gmail locking后报告的Windows Server 2012 R2 IIS弱密码 WinRM的聆听者并不全是耳朵 如何知道哪个yum版本库* URL *已经安装了一个包？ 远程桌面到多个不同的工作站共享一条DSL线路 是否可以抑制iPerf3中的TCP / IP握手？ Windows 2003上的SQL Server 2008 Reporting Services

从Rackspace迁移到EC2 – EBS vs.实例库

我刚开始使用S3作为我的Django应用程序的图像存储托pipe在Rackspace上。 我不得不看看EC2，因为它很明显，在上传文件的时候会更快地移动文件到S3。 我必须承认这让我感到困惑。

所以如果我使用实例存储前端在哪里我的Django代码驻留？ 它说，如果它重新启动，我失去了我的数据和假设我的代码也是我的数据。 我是否安装EBS卷来存储代码？

对于MySQL后端，我使用EBS支持的实例和实例存储前端，我将开始和停止负载来来去去。

在提出新的前端并closures它们时，如何平衡负载。 我以前使用nginx，但我猜亚马逊有这样的冗余。

我看到有人提到的所有EC2pipe理命令都在哪里运行？ 在实例本身或我的Windows机器上，我曾经开发和testing？

有两种存储可以附加到一个实例：短暂和弹性块存储（EBS）。 顾名思义，临时存储就是临时的 – 只有在实例运行时才存在（如果实例停止或终止，它将被销毁）。 临时存储不能在实例之间“转移”（即从一个实例分离并连接到另一个实例）。 实例存储数据在不停止实例的重新启动之间持续存在（即从控制台运行重新启动）。 EBS存储独立于实例保留，EBS卷可以在实例之间传送（在相同的可用区域内）。 另外，您可以拍摄EBS卷的快照，允许卷内容的压缩图像的差异（即增量）存储（允许您轻松在不同区域创build新卷等）。 有资格使用临时存储的实例可以免费获得。 另一方面，EBS存储由以下两方面计费：a）提供的数量，以及b）I / O使用情况。

Instance-store使用S3来存储AMI数据，并提供临时根目录以及附加的临时存储。 这在任务需要大量临时存储的情况下是很好的，只有很less的数据被永久保存。 一般来说，临时存储对于临时文件和交换空间是有利的。 如果要在临时卷上存储数据，则应该在启动时从“主源”复制该数据，并且数据（在临时磁盘上）不应该是有价值的。 （例如，如果您运行的是应用程序，则可以在外部存储代码，在服务器启动时将最新版本下载到临时磁盘，然后在服务器上本地运行应用程序，并将所有数据存储在其他位置（例如EBS，RDS等））

通常，build议的路线是使用EBS – 既作为根卷，也作为数据的存储介质。 EBS允许您轻松更改实例types，修改根分区大小，备份数据，并且极大地方便了处理问题，因为您可以将EBS卷附加到其他正在运行的实例。 使用EBS，您可以将您的代码直接存储在EBS卷上，并且您所做的任何更改都将持续。 此外，您可以将快照附加到实例，以便启动的所有实例在其所连接的EBS卷上具有相同的数据（即数据是从快照派生的）。 除非您有实体店体系结构的特殊需求，否则EBS就是一个很好的select。

（还有另外一种select，但是对于代码/数据库来说，这通常是不实际的，你可以使用保险丝作为本地文件系统挂载一个S3存储桶 – 优点是不受限制，不可调整的存储空间大量的空间） – 对于上传，图片等来说，这可能是用户贡献的一个很好的select，但是缺点是性能 – 写入S3并不像EBS或临时存储那么快，存在明显的滞后这是应用程序的核心组件无法接受的。）

回顾：代码必须在本地可用 – 将其存储在EBS（推荐），或者将其下载到服务器的临时磁盘（即将您的代码复制到机器以供使用，但驻留在别处）。

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

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

最后，AWS命令可以从任何地方运行 – 它们通过传递给它们的凭据被locking到您的账户中，并且针对特定资源（例如实例，EBS卷等）运行，因为您将指定关联的ID给定的命令。 只有一些需要（本地）访问相关文件的命令（如捆绑/上传AMI）必须从特定的机器（即可访问所需文件的机器）运行。 即使是引用附加到实例的资源的命令（例如，获取EBS卷的快照），也可以从安装了工具的任何机器（相关实例，开发包，另一个实例等）运行。

我将为您轻松实现：始终使用EBS启动实例，忘记实例存储，直到您成为EC2专家。

将您的数据文件保存在附加到实例的单独EBS卷上。 为了运行MySQL，请阅读我多年前为Amazon写的这篇文章。 AMI id的例子已经过时了，但其余的仍然是最好的做法。

http://aws.amazon.com/articles/1663

您可以使用Amazon ELB（弹性负载平衡器）在各个前端服务器之间分配stream量。

EC2命令行工具大多运行在你的本地系统上，尽pipe在某些情况下它对实例有意义。 只要注意你放置AWS证书的地方。