对RightScale和Scalr进行动态Ec2实例管理的任何想法

时间:2008-12-14 14:51:35

标签: amazon-ec2 scalability haproxy rightscale scalr

我正在寻找一种经济高效的工具来管理Ec2上的网络应用。 Rightscale似乎是大狗并为它收费。 Scalr看起来像一个更具成本效益的解决方案,但很难找到任何真正的客户体验..

我正在寻找的关键方面是负载均衡器(http和https)以及一种在负载增加时自动引入在线额外Web服务器容量以及在负载下降时终止实例的方法。

据我所知,很多人都在这里推销自己的东西。我们正试图发布一个应用程序,并不是真的想要打太多沉重的系统管理员战斗。鉴于表演等的重要性,我很高兴听到有关该领域的建议和经验。

8 个答案:

答案 0 :(得分:16)

我是Scalr用户,Scalr.net订阅者,并且已成为Scalr爱好者。我不可能买得起Rightscale。

Scalr可以按你的要求做。

Scalr有三个图像(每个图像有32/64位版本),还有一个基本(通用)图像:

1)负载均衡器图像,运行nginx。高可用性设置需要其中两个。 Scalr将管理您的名称服务,并在它们之间进行循环。如果一个发生故障,Scalr将从DNS中删除它并启动另一个实例。可以运行其他负载均衡器,但nginx是默认值。

2)有几个应用程序服务器映像可用,运行Apache / Tomcat / Rails。您可以在此处设置应用程序,无论是PHP / Perl / Python / Java / Ruby等等。 nginx在这些实例之间路由请求,这些实例按唯一用户(基于IP +浏览器)分组。 Scalr也会监视这些内容,并替换损坏的实例。

3)MySQL数据库映像,具有自动主/从复制功能。只需部署您的架构,Scalr处理复制并替换已失效的服务器。它还会定期备份您的数据。 Scalr的DNS提供主机和从机主机名,因此您可以从从机读取您的应用程序并写入主机。

所有这些实例类型都将根据负载自动扩展。您从最接近您正在进行的基本图像开始,然后根据您的应用程序自定义它们。例如,我们在apache服务器实例上部署Perl / Catalyst应用程序,但我们提供来自nginx前端服务器的静态内容。我们不得不稍微修改我们的应用程序以使用读/写数据库句柄。

总而言之,花了大约三个星期的时间来处理Scalr中的错误,使我们的应用程序进入可靠的状态,我相信它在Scalr中具有很高的可用性。他们的支持是惊人的,所以这些错误并没有给我带来太大的麻烦,系统真的出现了。它接近严重的可靠性。

作为旁注,Scalr的最佳功能是“全部同步”功能,该功能可自动捆绑您的AMI并在新实例上重新部署它 - 所有这些都不会中断服务。这样可以节省您完成冗长的EC2映像/ AMI创建过程的时间,否则可以使非常简单的管理任务耗时20分钟。无论是否扩展服务器场,都可以使用它 - 即使在单个实例上也非常方便。

我每月向Scalr.net支付50美元来为我提供服务,因为我觉得它节省了我的时间和金钱。到目前为止,最重要的是:在我的最后一次演出中,我们有一个系统人员在我们高度可用的Linux DB + app服务器设置上工作了一年......他未能达到我在三周内实现的那种可靠性。与滚动我自己相比,使用Scalr节省的费用是极端的。

所有这一切,如果我能负担得起Rightscale,我会使用Rightscale。但前期费用和每月500美元使得这不可能。人们一直在谈论挥动前期费用以换取其所包含的咨询服务,但每月的服务费不会随处发生。

我应该提一下,目前sclar.net的网站已关闭,所以如果我想管理我的任何服务器场(没有它们),我现在根本就不能。目前尚不清楚缩放是否适用于scalr.net订阅者。也就是说......这可能还不是一个成熟的解决方案。这种情况经常发生,在今晚之前,我所经历的唯一停机时间是一次几分钟。但是,是的......它现在正在向下,所以我必须提到它:)

在做出决定之前,我建议您在http://groups.google.com/group/scalr-discuss仔细阅读支持小组。如果您选择Scalr,请准备好测试您的设置并解决您在Google群组中遇到的任何问题。

答案 1 :(得分:3)

我会评论你的问题,因为给出一个具体的答案是有点雄心勃勃的。

首先,我看到你的标签上有haproxy。这绝对是EC2中最好的负载平衡软件已证实。 AWS论坛中有关于haproxy使用的文档和经验。

我无法就scalr给你一个意见,但是Rightscale正朝着正确的方向发展。 RightScale路线图中最有趣的功能之一是它们是适用于任何云的mgmt云系统,而不仅仅是亚马逊的EC2。这使得它们在尝试请求负载平衡和需要升级时非常有前途。

此外,您可以在版权规模上注册开发者免费帐户,并且可以测试他们的一些AMI和免费脚本,它们非常令人印象深刻。

嗯,这可能听起来像我在那里工作或者其他什么,但我只是一个云用户,没有与他们联系。如果那是你的想法。

我希望这会有所帮助,至少会增加讨论。

地理

答案 2 :(得分:2)

现在已经在Scalr工作了大约两个月,并且已经将几个生产应用程序慢慢转移到平台上并取得了良好的效果。我强烈建议他们快速转身/支持和价值。我希望看到它们提高平台的可用性。

总而言之,基于简单的用例,它非常适合原始海报。

答案 3 :(得分:1)

决定正确的选择可能不像每个人所期望的那样干燥和干燥。我见过并听过Scalr关于他们平台的谈话,并听取了RightScale讨论他们的平台。如果您有一个简单的SOA(App Server - 数据库服务器 - 文件服务器),那么任何一种选择都适合您的公司。

最终,如果您已经创建了一些自定义中间件并依赖于已知的套接字或特定点来进行握手,则需要考虑负载平衡和自动扩展功能,并回归到您自己的解决方案中。用这些服务中的任何一种来管理。

答案 4 :(得分:1)

两种服务(权利规模和scalr)都很棒。报价不一样,价格也不一样。但它们都是我想要的。重新考虑我们的预算标准符合我的需求。我发现谷歌小组的支持在开始时非常奇怪,但它非常快速有效。

他们的解决方案也是开源的(不错),他们的路线图中也有V2,并支持其他提供商。

等等看,但直到现在,我对它很满意

答案 5 :(得分:1)

每项服务都有糟糕的一天。 AWS服务可以看到停机时间。但是,仍然有用户在AWS上运行他们的应用程序。

我在Scalr.net上有几个农场并与Rightscale进行了比较。我不需要支付一条胳膊和一条腿。

总的来说,服务非常可靠。现在使用脚本引擎,我可以设置自己的脚本来管理我的实例。

关心 Hareem Haque

答案 6 :(得分:0)

我现在正在研究Scalr虽然看起来都不错,但我决定继续使用自己的脚本来实现云管理/扩展。我现在有8台服务器,只支付AWS费用。我使用厨师(自托管),nagios和许多其他工具。我的数据库是mysql和mongodb,负载均衡器是haproxy,app层是rails。直到我需要100台服务器,我想我会保留脚本'; - )

答案 7 :(得分:0)