Windows 亚马逊EC2容量及；工作流问题

我希望你们中有使用亚马逊EC2经验的人能提供一些建议……当然，这是主观的，这很好，我很确定你们的客户估计会比我的好

我计划将我客户的所有网站从共享托管环境迁移到AmazonEC2。它们都是流量非常低的网站（最繁忙的网站每天接收大约50名独立访客）。大约有8个站点，但随着我承担更多项目和托管更多站点，我可能会扩展这一点……目前的容量规划是针对12个站点

每个站点都在ASP.Net（Umbraco CMS）上运行，并且需要一个SQL Server数据库

我的想法如下：

设置一个小实例（1.7gb RAM，1个EC2计算单元），并在该服务器上运行IIS和SQL Server Express

设置2个微实例（每个613MB Ram，最多2个EC2计算单元）——一个用于IIS，另一个用于SQL Server

你认为哪种安排最符合我的要求。我已经开始用Server2008、SQLServerExpress等设置一个微实例，发现它不能满足内存需求，因此考虑扩展。我总是可以在一个小实例上进行配置，然后导出AMI并在之后在一个微实例中启动它，并且每次需要对服务器进行任何重大更改时都可以这样做。我想我甚至可以在一个备用的小点实例上执行所有更新等，然后在Micro中切换该AMI的负载，并跨多个实例传输IP地址，因此我不需要在生产服务器上做太多工作。我认为，如果我将所有网站数据文件存储在EBS卷上，那么在服务器之间移动主机应该相当容易，停机时间最少，而不必在生产服务器上工作

我很想知道你们的想法，以及你们在升级、windows更新、软件安装等活动中采用的策略

你认为我需要什么能力来满足我的需求

干杯

---

Greg

首先，Server2008在Micro实例提供的613MB RAM中表现不佳。它在运行，但它是一只狗，而且它的叫声越大，你在上面叠加的服务（IIS、SSE等）越多。我们在2008年使用的是小型服务器，事实上，一旦繁重的工作完成，操作系统准备好使用，我们通常会以中等规模进行环境配置，并缩小到小型。然而，Server2003在微型机上似乎更容易呼吸——但我们仍然在更大的实例上进行配置并缩小规模

我们在Server2003/IIS6上运行一个微流量低的网站，Server2008/SS安装在一个共享的、独立的小实例上。我们还运行了一台服务器2008/IIS7微构建，但这只是为了提醒自己为什么不更广泛地使用它

大型网站在中小型实例中运行Server2008/IIS7，但几乎始终使用共享的单独SS实例来提供数据库服务。我们尽量不部署多个SS安装，因为这会使维护和备份更加复杂

---

当然，将内容和配置存储在EBS卷上是一种很好的做法，除非您希望在实例消失时重建整个系统。定期快照您的实例也是一种很好的做法，因为您可以从基线AMI启动一个新实例，并将快照作为启动卷交换进来，以便在发生灾难时快速恢复。

非常好的信息Jonners，谢谢。那么，您认为一个运行IIS和SS的小实例就足以容纳十几个站点吗？如果我需要两个小实例，很遗憾，它可能会太贵：（关于快照，我并不完全了解……如果我有一个实例以EBS作为其根驱动器运行，我对其进行快照，然后使用AMI启动一个新实例，我如何将快照作为引导卷锯入？哦，快照是否占用EBS驱动器的全部大小（因此，如果它是30gb的ebs驱动器，并且我拍摄了快照，那么我是否需要为60gb的ebs存储付费？）一个小实例将愉快地运行Server 2003+IIS6+SSE，直到流量工作负载增加-然后您将需要升级。它也将运行Server 2008+IIS7+SSE，但升级点将更快地影响您，因为配置需要更多资源。给定一个EBS备份的实例（即AMI是一个EBS备份的映像，而不是S3备份的映像）您可以停止VM，识别它正在使用的卷，并对其进行快照。然后，您可以重新启动实例并继续。稍后，无论是出于设计还是不幸，实例都会死亡—您现在可以启动一个新实例，停止它，分离卷，从以前拍摄的快照中创建一个新卷，将其作为/dev/sda1重新连接到停止的实例，然后重试重新启动它。我们的estate management工具会自动执行此操作，但在它存在之前，我们是通过控制台手动完成的。关于快照存储消耗-它们是来自上一个快照的增量。来自。。。"Amazon EBS提供将数据的时间点快照备份到Amazon S3以进行持久恢复的功能。Amazon EBS快照是增量备份，这意味着仅保存自上次快照以来已更改的设备上的数据块。如果您的设备具有100 Gb的数据，但自上次快照以来仅更改了5 Gb的数据r最后一个快照，只有额外的5 GB快照数据将存储回Amazon S3”。