【问题标题】:Rails hosting advice - EngineYard, Heroku, EC2Rails 托管建议 - EngineYard、Heroku、EC2
【发布时间】:2013-04-23 22:29:03
【问题描述】:

我正在为需要 99.9999999999% 正常运行时间保证的客户开发一个非常敏感的应用程序。

这是一个带有 MySQL 数据库的 Rails 应用程序。由于维护要求低且易于运行,我正在考虑将其托管在 EngineYard 上。

由于正常运行时间问题,Heroku 似乎不是完美的解决方案。

EC2 也可以是一个很好的解决方案,但它可能需要太多的工作来安装和维护。

我的问题是:如何使用 EngineYard、Heroku、EC2 或您建议的任何其他 Rails 托管来制作冗余系统?我是否需要在世界不同地方复制 2 个实例?请告知最好的方法。

问候。

【问题讨论】:

  • 您需要一种每年下降不超过 31ns 的服务?
  • 了解 Heroku 是基于 EC2 构建的。
  • 99.9999999999% ?用 Erlang 编写 - 非常接近。
  • Heroku 是基于 EC2 构建的,但如果他们犯了错误,一切都会失败。恕我直言,这不是很好。
  • 如果 Amazon 出错了,那么 EC2 和 Heroku 就会宕机,如果 Heroku 出错,那么 Heroku 就会宕机。只有在亚马逊犯错时,安永才会倒闭。

标签: ruby-on-rails web-applications hosting


【解决方案1】:

每个人都想要 100% 的正常运行时间,但实现它几乎是不可能的。由于停机时间可能由链条中的任何环节引起,通常有几十个,要达到如此高的标准,您需要购买镀金的一切。本质上,你将不得不花一大笔钱。 99% 正常运行时间(意味着您的站点每年大约有 88 小时不可用)与 99.9% 正常运行时间(不到十小时)之间的差异相当大,从那里到 99.99% 之间的差异甚至更高,容忍度低于一整年的小时。

超过 99.99% 根本不切实际。除非他们不诚实,否则没有人会签署这样的保证,该协议充满了警告以至于无法执行,或者不介意一直提供大量信用。例如,Amazon EC2 的 SLA 为 99.99%。

我在 Linode 等提供商上收集的指标显示正常运行时间约为 99.97% 到 99.99%。有时您会看到 100% 正常运行时间的数据中心,但这只是网络级别,并未考虑可能导致服务器离线的间歇性内部故障。

选择像 Engine Yard 这样的托管托管服务提供商可能是适合您的解决方案,因为它可以最大限度地减少您对随机事件的影响,但它本身并不会为您带来如此长的正常运行时间。他们非常擅长维护系统层,但他们修复或解决您的应用程序中的错误的能力非常有限,并且与其他人一样,他们会遇到与 EC2 相同的间歇性网络问题。

您应该关注两种可靠性。一个是可用性,它纯粹是衡量客户使用应用程序的可能性。另一个是数据完整性,它衡量在给定任意数量的灾难场景时数据被保留的可能性。

大多数人会接受应用程序可能会在短时间内经常出现故障,但人们拒绝接受数据可能会时不时丢失。

获得“99.9999999999%”的数据保留率并不难,但您需要详细规划备份、复制和恢复策略,并且必须定期锻炼您的系统以确保它们正常工作设计的。

如果您几乎无法控制互联网上通常不完整的路由、服务器硬件的缺陷率、数据中心的电源等等,您确实可以大量控制自己的备份策略。

【讨论】:

  • 我完全同意您的帖子,但 99% 的正常运行时间相当于 87.6 小时的停机时间,而 99.9% 的停机时间相当于将近 9 小时,这在某些情况下是不可接受的。
  • 你的数学似乎比我的更准确。相应更正。谢谢!
  • 99.9999999999 是 100 亿分之一,这意味着您的网站运行 310 年会停机一秒钟。没有人能判断一个网站是否关闭了一秒钟。
  • @TomAndersen Experience 表示,这正是该公司首席执行官第二次上网站向投资者展示,然后打电话抱怨你糟糕的服务。
【解决方案2】:

EY 使用一家名为 TerraMark 的公司进行托管,这是一些非常重要的托管基础​​设施。在你列出的 3 个中,我会和他们一起去。

对于正常运行时间,您希望查看数据的主/从复制、自动故障转移,并且您希望尽可能构建冗余。高可用性是一个相当复杂的话题,并且与 IT 相关而不是开发,我建议在 serverfault.com 上询问从哪里开始。

【讨论】:

  • 安永云托管使用EC2
猜你喜欢
  • 1970-01-01
  • 2011-05-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-29
  • 2013-07-29
  • 2011-01-03
  • 1970-01-01
相关资源
最近更新 更多