我正在寻找一种成本效益高的工具来管理 Ec2 上的 Web 应用程序。Rightscale 在大狗看来并为此收费。Scalr 看起来是一种更具成本效益的解决方案，但很难找到任何真实的客户体验。
我正在寻找的关键方面是负载均衡器（http 和 https）以及一种在负载增加时自动使额外的 Web 服务器容量在线以及在负载下降时终止实例的方法。
据我所知，很多人都在这里推出自己的东西。我们正在尝试发布一个应用程序，并且真的不想打太多繁重的系统管理员之战。鉴于性能等的重要性，我很高兴能听到来自该领域的建议和经验。
我是 Scalr 用户，Scalr.net 订阅者，并且已经成为 Scalr 爱好者。我买不起 Rightscale。
Scalr 可以满足您的要求。
Scalr 有三个图像（每个都有 32/64 位版本），加上一个基本（通用）图像：
1) 一个负载均衡器镜像，运行 nginx。高可用性设置需要其中两个。Scalr 将管理您的名称服务，并在它们之间进行循环。如果一个实例出现故障，Scalr 会将其从 DNS 中删除并启动另一个实例。可以运行其他负载均衡器，但默认使用 nginx。
2) 有几个应用服务器镜像可用，运行 Apache/Tomcat/Rails。你在这里设置你的应用程序，无论是 PHP/Perl/Python/Java/Ruby/whatever。nginx 在这些实例之间路由请求，这些实例按唯一用户分组（基于 IP + 浏览器）。Scalr 也监视这些状态，并替换损坏的实例。
3) MySQL 数据库映像，具有自动主/从复制功能。只需部署您的架构，Scalar 就会处理复制并替换已失效的服务器。它还会定期备份您的数据。Scalar 的 DNS 提供主从主机名，因此您可以让您的应用程序从从属读取并写入主控。
所有这些实例类型都将根据负载自动扩展。您从最接近您正在做的事情的基本映像开始，然后为您的应用程序自定义它们。例如，我们在 apache 服务器实例上部署 Perl/Catalyst 应用程序，但我们从 nginx 前端服务器提供静态内容。我们不得不稍微修改我们的应用程序以使用读/写数据库句柄。
总而言之，我们花了大约三周的时间来解决 Scalr 中的错误，以使我们的应用程序达到可靠状态，我相信它在 Scalr 上是高度可用的。他们的支持非常出色，所以这些错误并没有给我带来太多困扰，而且这个系统真的出现了。它正在接近严重的可靠性。
附带说明一下，Scalr 的最佳功能是“同步到所有”功能，它会自动捆绑您的 AMI 并将其重新部署到新实例上——所有这些都不会中断服务。这可以节省您完成冗长的 EC2 映像/AMI 创建过程的时间，否则非常简单的管理任务可能需要 20 分钟。无论您是否扩展服务器场，您都可以使用它 - 即使在单个实例上也非常方便。
我每月向 Scalr.net 支付 50 美元来为我托管该服务，因为我认为它可以节省我的时间和金钱。到目前为止的底线是这样的：在我的最后一次演出中，我们有一个系统人员在我们的高可用性 Linux DB + 应用服务器设置上工作了一年......他未能达到我在三周内达到的那种可靠性. 与滚动我自己的相比，使用 Scalr 所节省的成本是极端的。
话虽如此，如果我负担得起 Rightscale，我会使用 Rightscale。但预付费用和每月 500 美元的费用使这成为不可能。一直在谈论挥舞前期费用以换取挥舞其中包含的咨询，但每月的服务费不会去任何地方。
我应该提一下，目前 sclar.net 的网站已经关闭，所以如果我想管理我的任何服务器场（不要让它们在 atm 上运行），我现在根本做不到。目前尚不清楚缩放是否适用于 scalr.net 订阅者。也就是说……这可能还不是一个成熟的解决方案。这种情况并不经常发生，在今晚之前，我经历过的唯一停机时间是一次几分钟。但是，是的......它现在就下来了，所以我必须提到它:)
我建议在做出决定之前彻底阅读http://groups.google.com/group/scalr-discuss上的支持小组。如果您选择 Scalr，请准备好测试您的设置并解决您在 google 组中遇到的任何问题。
我将对您的问题发表评论，因为给出具体答案有点雄心勃勃。
首先，我看到您的标签上有 haproxy。这绝对是EC2 中证明的最好的负载均衡软件。AWS 论坛中有关于使用 haproxy 的文档和经验。
我无法就 scalr 发表意见，但 Rightscale 正朝着正确的方向发展。RightScale 路线图中最有趣的功能之一是，它们是适用于任何云的管理云系统，而不仅仅是 Amazon 的 EC2。这使得它们在尝试请求负载平衡和升级时非常有前途。
您还可以在 rightscale 上注册一个开发人员免费帐户，您可以测试他们的一些 AMI 和免费脚本，它们非常令人印象深刻。
好吧，这听起来像是我在那里工作或其他什么，但我只是一个云用户，与他们没有任何联系。如果你想到了。
我希望这会有所帮助，至少可以增加讨论。
地理
已经使用 Scalr 大约两个月了，并且已经慢慢地将几个生产应用程序转换到该平台，并取得了良好的效果。我强烈推荐他们快速周转/支持和价值。我希望看到他们提高平台的可用性。
总而言之，非常适合基于所呈现的简单用例的原始海报。
每项服务都有糟糕的一天。AWS 服务可以看到停机时间。但是，仍有用户在 AWS 上运行他们的应用程序。
我在 Scalr.net 上有几个农场，并与 Rightscale 进行了比较。我不必付出一条胳膊和一条腿。
总的来说，服务非常可靠。现在有了脚本引擎，我可以设置自己的脚本来管理我的实例。
问候哈雷姆·哈克
两种服务（rightscale 和 scalr）都很棒。报价不一样，价格也不一样。但它们都是我想要的。关于我们的预算标量符合我的需要。一开始我发现通过一个google group的支持很奇怪，但它非常快速和高效。
他们的解决方案也是开源的（不错），他们的路线图中也有一个 V2 版本，并支持其他提供商。
拭目以待，但到目前为止，我对此感到非常满意
做出正确选择的决定可能并不像每个人预期的那么简单。我见过 Scalr 并听取了关于他们平台的谈话，也听过 RightScale 讨论他们的平台。如果您有一个简单的 SOA（应用服务器 - 数据库服务器 - 文件服务器），那么任何一种选择都适合您的公司。
最终，如果您创建了一些自定义中间件并且您依赖已知的套接字或特定的握手点，您将需要考虑负载平衡和自动缩放，而对于无法管理的问题则回退到您自己的解决方案使用这些服务中的任何一项。
我现在正在研究 Scalr，虽然看起来一切都很好，但我决定继续使用我自己的脚本来实现云管理/扩展。我现在有 8 台服务器，只支付 AWS 费用。我使用 chef（自托管）、nagios 和许多其他工具。我的数据库是mysql和mongodb，负载均衡器是haproxy，应用层是rails。在我需要 100 台服务器之前，我想我会继续编写脚本';-)