关于用于动态 Ec2 实例管理的 RightScale 和 Scalr 的任何想法
我正在寻找一种经济高效的工具来管理 Ec2 上的 Web 应用程序。 Rightscale 似乎是个大狗，并为此收费。 Scalr 看起来是一个更具成本效益的解决方案，但很难找到任何真正的客户体验。
我正在寻找的关键方面是负载均衡器（http 和 https）以及一种自动将额外的 Web 服务器容量作为负载提供在线的方法当负载下降时增加并终止实例。
据我所知，很多人都在这里推出自己的东西。 我们正在尝试发布一个应用程序，并且真的不想进行太多繁重的系统管理战斗。 考虑到性能等的重要性，我很高兴听到来自该领域的建议和经验。
I'm looking for a cost effective tool for managing an web app on Ec2. Rightscale seems to the big dog and charges for it. Scalr looks like a more cost effective solution but it's hard to find out any real customer experiences..
The key aspects I'm looking for is a load balancer (http and https) and a way to automatically bring online additional web servers capacity as load increases as well as terminate the instances when load falls off.
From what I can tell, lots of people are rolling their own stuff here. We're trying to release an app and don't really want to have to fight too many heavy sys admin battles. Given the importance of performance etc I'd be grateful to hear advise and experiences from the field on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我是 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 + 应用程序服务器设置上工作了一年......他未能实现我在三周内实现的那种可靠性。 与我自己使用 Scalr 相比，使用 Scalr 可以节省大量资金。
话虽这么说，如果我买得起 Rightscale，我会使用 Rightscale。 但预付费用和每月 500 美元的费用让这一切变得不可能。 有人说要放弃预付费用，以换取放弃其中包含的咨询服务，但每月的服务费却不会消失。
我应该提到的是，目前 sclar.net 的网站已关闭，因此如果我想管理我的任何服务器场（不要将它们放在 atm 上），我现在根本做不到。 目前尚不清楚扩展是否对 scalr.net 订阅者有效。 也就是说……这也许还不是一个成熟的解决方案。 这种情况并不经常发生，今晚之前我经历过的唯一的停机时间是一次几分钟。 但是，是的......它现在已经关闭了，所以我必须提到它:)
我建议彻底阅读 http://groups.google.com/group/scalr-discuss，然后再做出决定。 如果您选择 Scalr，请准备好测试您的设置并解决您在 Google 群组中遇到的任何问题。
I am a Scalr user, a Scalr.net subscriber, and have become a Scalr enthusiast. I cannot possibly afford Rightscale.
Scalr can do what you ask.
Scalr has three images (each with 32/64 bit versions), plus a base (generic) image:
1) A load balancer image, running nginx. A highly available setup requires two of these. Scalr will manage your nameservice, and round robin between them. If one goes down, Scalr will remove it from DNS and bring up another instance. It is possible to run other load balancers, but nginx is the default.
2) Several application server images are available, running Apache/Tomcat/Rails. You setup your application here, be it PHP/Perl/Python/Java/Ruby/whatever. nginx routes requests between these instances grouped by unique user (based on IP + browser). Scalr monitors these for upness too, and replaces broken instances.
3) A MySQL database image, with automatic master/slave replication. Just deploy your schema, and Scalr handles replication and replaces defunct servers. It will also backup your data periodically. Scalr's DNS provides master and slave hostnames, so you can have your app read from the slaves and write to the master.
All of these instance types will auto-scale based on load. You start with the base image closest to what you're doing, and then you customize them for your application. For instance, we deploy our Perl/Catalyst app on the apache server instances but we serve static content from the nginx front-end servers. We had to modify our application slightly to use read/write database handles.
All in all, it took about three weeks of working through bugs in Scalr to get our application to a reliable state where I am confident that it IS highly available with Scalr. Their support was phenomenal, so the bugs didn't bother me too much, and the system is really coming along. It is approaching serious reliability.
As a side note, the best feature of Scalr is the 'Synchronize to All' feature, which auto-bundles your AMI and re-deploys it on a new instance - all without a service interruption. This saves you the time of going through the lengthy EC2 image/AMI creation process, which can otherwise make very simple admin tasks take 20 minutes. You can use this whether you are scaling your server farm or not - it would be very handy even on a single instance.
I pay Scalr.net $50 a month to host the service for me because I think it saves me time and money. The bottom line so far is this: at my last gig, we had a systems guy working on our highly available Linux DB + app server setup for a year... and he failed to achieve the kind of reliability that I achieved in three weeks. The savings by using Scalr as compared to rolling my own are extreme.
All that being said, if I could afford Rightscale, I would be using Rightscale. But the up-front fee and $500 a month make that impossible. There has been talk of waving the up-front fee in exchange for waving the consulting that it includes, but the monthly service fee isn't going anywhere.
I should mention that at the moment, sclar.net's website is down, so if I wanted to manage any of my server farms (don't have them up atm), I simply couldn't right now. It is not clear whether scaling is working for scalr.net subscribers right now, or not. Which is to say... this is perhaps not a mature solution yet. This doesn't happen often, before tonight the only downtime I've experienced were in periods of a few minutes at a time. But yeah... its down RIGHT NOW, so I must mention it :)
I would suggest a thorough reading of the support group at http://groups.google.com/group/scalr-discuss before making your decision. If you pick Scalr, be prepared to test your setup and work through any issues you have on the google group.
我将对你的问题发表评论，因为给出具体答案有点雄心勃勃。
首先，我看到你的标签上有 haproxy。 这绝对是 EC2 中经过验证的最好的负载均衡软件。 AWS论坛上有关于haproxy使用的文档和经验。
我无法给你关于 scalar 的意见，但 Rightscale 正在朝着正确的方向发展。 RightScale 路线图中最有趣的功能之一是，它们是适用于任何云的管理云系统，而不仅仅是 Amazon EC2。 这使得它们在尝试请求负载平衡和需要升级时非常有前途。
您还可以在 rightscale 上注册开发人员免费帐户，并且可以测试他们的一些 AMI 和免费脚本，它们非常令人印象深刻。
好吧，这听起来像是我在那里工作或其他什么，但我只是一个云用户，与他们没有联系。 如果你有这样的想法。
我希望这会有所帮助，至少增加讨论。
地理
I will comment on your question, since giving a concrete answer is a little ambitious.
First, I see that you have haproxy on your tags. That is definitely the best load balancing software proven in EC2. There is documentation and experiences in the AWS forums on the use of haproxy.
I am unable to give you an opinion on scalr, but Rightscale is going the right direction. One of RightScale most interesting features in their roadmap is that they are a mgmt cloud system for any cloud not just EC2 of Amazon. That makes them very promising when trying to request load balancing and upscaling in need.
Also you can signup for a developer free account on rightscale and you can test some of their AMI and free scripts, they are pretty impressive.
Well, this might sound like I am working there or something, but I am a just a cloud user, no connection with them. If that crosses your mind.
I hope this helps, at least adds to the discussion.
Geo
使用 Scalr 已有大约两个月的时间，并已慢慢将多个生产应用程序过渡到该平台，并取得了良好的效果。 我强烈推荐他们快速周转/支持和价值。 我希望看到他们提高平台的可用性。
总而言之，基于所呈现的简单用例，非常适合原始海报。
Been on Scalr for about two months now and have slowly transitioned several production applications to the platform with good results. I strongly recommend them for quick turn around/support and value. I would like to see them improve availability of their platform.
All in all, a good fit for the original poster based on the simple use case presented.
每项服务都有糟糕的一天。 AWS 服务会出现停机时间。 然而，仍然有用户在AWS上运行他们的应用程序。
我在 Scalr.net 上有一些农场，并与 Rightscale 进行了比较。 我不需要付钱。
总体来说，服务非常可靠。 现在，通过脚本引擎，我可以设置自己的脚本来管理我的实例。
带着敬意
哈里姆·哈克
Every service has a bad day. AWS services see down time. However, there are still users running their apps on AWS.
I have a few farms on Scalr.net and compared to Rightscale. I don't have to pay an arm and a leg.
Overall, service is very reliable. And now with the scripting engine i can setup my own scripts to govern my instances.
With Regards
Hareem Haque
这两种服务（rightscale 和 scalar）都很棒。 报价不一样，价格也不一样。 但它们都是我一直在寻找的。 关于我们的预算标量符合我的需要。 一开始我发现通过谷歌小组提供的支持非常奇怪，但它非常快速和高效。
他们的解决方案也是开源的（不错），并且他们的路线图中也有 V2 并支持其他提供商。
等等看，但到目前为止，我对此感到非常满意
Both services (rightscale and scalr) are great. The offer is not the same and the price is not the same too. But they are both what I was looking for. Regaring our budget scalr fits my needs. I found the support through a google group very strange at the beginning, but it is very fast and efficient.
Their solution is also open source (not bad) and they also have a V2 in their roadmap with support to other providers.
Wait and see, but til now, I'm very happy with it
做出正确的选择可能并不像每个人期望的那么简单。 我见过 Scalr 并听过他们关于他们平台的演讲，也听过 RightScale 讨论他们的平台。 如果您有一个简单的 SOA（应用程序服务器 - 数据库服务器 - 文件服务器），那么任一选择都适合您的公司。
最终，如果您创建了一些自定义中间件，并且依赖于已知的套接字或特定的握手点，则您将需要考虑负载平衡和自动扩展，并针对无法管理的内容使用您自己的解决方案使用这些服务之一。
Deciding on the right choice may not be as cut and dry as everyone expects. I have met with and heard talks from Scalr about their platform and have also listened to RightScale discuss their platform. If you have a simple SOA (App Server - Database Server - File Server), then either choice will be right for your company.
Ultimately, if you have created some custom middleware and you rely on known sockets or specific points for handshakes, you will need to consider load-balancing and auto-scaling what you can and fall back to your own solutions for what can't be managed with either of these services.
有些人说自动缩放不会没有解决问题
Some people say that automatic scaling won't solve the problem
我现在正在研究 Scalr，虽然一切看起来都不错，但我决定继续使用自己的脚本来实现云管理/扩展。 我现在有 8 台服务器，只支付 AWS 费用。 我使用 Chef（自托管）、nagios 和许多其他工具。 我的数据库是mysql和mongodb，负载均衡器是haproxy，应用层是rails。 在我需要数百台服务器之前，我想我会继续编写脚本;-)
I am looking into Scalr right now and although it all looks good, I decided to continue with my own scripting for the purpose of cloud management / scaling. I have 8 servers right now and am paying only the AWS fees. I use chef (self-hosted), nagios, and a lot of other tools. My databases are mysql and mongodb, load balancer is haproxy, app layer is rails. Until I need 100s of servers, I think I will just keep scriptin' ;-)