EC2 平均正常运行时间？
好奇 99.95% 的正常运行时间到底意味着什么； 每个月真的会减少7分钟吗？ 请发布您在 EC2 上的最长/平均正常运行时间，谢谢。
Curious as to 99.95% uptime REALLY means; Is it really going to go down 7 minutes a month? Please post your longest/average uptimes on EC2, thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
通常正常运行时间按年计算。 因此，如果您签订了 99.95% 的服务水平协议，这意味着：
如果在一年的服务期间发生中断，并且您的系统停机时间超过该值，那么您有责任赔偿。
至于你的问题，我有一台在 EC2 中不间断运行的服务器大约 3 个月了。 我想说他们的正常运行时间很好，但如果您有一个关键任务应用程序，您肯定需要一个故障转移解决方案。 良好的正常运行时间仅意味着他们能够快速响应中断。 如果您没有做好应对停机的准备，即使 99.9999% 的正常运行时间也无法拯救您。
Usually uptime is calculated in a yearly basis. So if you have a Service Level Agreement for 99.95% this means:
If during a year of service there is an outage and your system is down for more than that, then you are liable for compensation.
As of your question, I have a server running unstopped in EC2 for about 3 months now. I would say that their uptime is good, but if you have a mission critical application you definitely need to have a fail-over solution. A good uptime only means that they will be able to respond to an outage quickly. Even a 99.9999% uptime won't be able to save you if you aren't prepared for an outage.
仔细阅读 SLA (http://aws.amazon.com/ec2-sla/)他们只将“区域不可用”视为停机时间，而且仅当该区域连续停机 5 分钟时才将其视为停机时间。
根据我的计算，这意味着任何少于 4 分钟的停机时间都不可计算。 此外，如果他们确实违反了 SLA，那么他们只会在您停机时间最长的月份的 %10 内受到影响。
因此，如果他们一月份都停业，而您的账单为 100 美元，他们就会向您的账户扣除 10 美元的信用额。
我很难让我的老板相信这是一个具有这样 SLA 的严肃产品。
Read the SLA carefully (http://aws.amazon.com/ec2-sla/) they only count "Region Unavailable" as downtime, and what is more they only count it as downtime if the region is down for 5 consecutive minutes.
By my count this mean any downtime of less then 4 minutes is not countable. Also if they do break the SLA they are only in for %10 of the month in which you had largest downtime bill.
So if they where down for all of January and your bill was $100 they would apply a $10 credit to your account.
I would have a hard time convensing my boss that this is a serious product with a SLA like that.
SLA 毫无用处。 它们仅衡量公司愿意承担多少风险，与实际正常运行时间无关。 我见过当公司知道无法满足 SLA 以便完成销售时，会提出 SLA，并给予严厉处罚。
我的一个客户的 EC2 正常运行时间超过 400 天，另一个客户的 EC2 正常运行时间超过 300 天（根据网络脉冲测量），这是迄今为止我合作过的最可靠的服务。
SLA's are useless. They only measure how much risk the company is willing to take on and have no bearing on actual uptime. I've seen SLA's, with heavy penalties, offered when the company knew the could not meet the SLA in order to land the sale.
I have one client with 400+ days of EC2 uptime and another with 300+ days as measured by web pulse, this is by far the most reliable service I've worked with.
对于我在美国东部可用区运行的单个实例，9 个月，0 停机时间。
For my single instance running in the US-East availability zone, 9 months, 0 downtime.
自从 Amazon 转而提供 SLA 以来，我从未遇到过任何失败的实例。 当我过去遇到实例停机时，亚马逊总是会发送一条消息，通知我该实例在实际消失之前已降级，因此我有时间启动一个新实例。
不过，前面的答案提出了一个很好的观点； EC2 的服务模型要求，如果您不准备长时间停机，则需要编写应用程序来处理到新服务器的故障转移。
Since Amazon switched to provide an SLA, I've never had an instance go down on me. When I've had instances go down in the past, Amazon has always sent a message informing me that the instance is degraded before it actually disappeared, so I've had time to start up a new instance.
The previous answer makes a good point, though; EC2's service model dictates that you write your apps to handle failover to a new server if you're not prepared for extended down time.
查看 AWS 服务运行状况仪表板可以让您很好地了解当前或过去的任何问题。 我的经验是，AWS 的正常运行时间优于大多数“传统”托管选项（甚至是成熟的冗余 RackSpace 设置...）。
然而，仅仅使用 AWS 来提高正常运行时间就像为钥匙串买一辆汽车（好吧，几乎..;)）。 使用 AWS 的架构的最大好处是可扩展（无需前期成本）。
Checking out the AWS Service Health Dashboard will get you a good idea of any current or past issues. My experience is that the AWS uptime is better than most "traditional" hosting options (even full-blown redundant RackSpace setup...).
However, simply going with AWS for uptime is like getting a car for the keychain (ok, almost.. ;)). With an architecture utilizing AWS the big benefit is scaling (without upfront costs).
SLA...保证正常运行时间...
这些都是非常好的口号。 但是，当服务器在一小时内不可用（2012 年 3 月 1 日，在欧盟地区）并且客户端开始呼叫时，它们仍然有 300 天的正常运行时间，这对您没有任何帮助。
当闪电击中他们在欧盟的三分之一的数据中心时，我们都发现他们没有异地冗余，他们拥有 3 个数据中心这一事实并不意味着什么。
人们一定喜欢“性能下降”这句话，它实际上意味着：“祈祷灾难过去后你的数据仍然可用”。
我仍在尝试寻找有关所有数据中心可用性百分比的任何官方/非官方统计数据。
到目前为止还没有运气...
SLA... Guaranteed uptime...
These are all very nice taglines. But when the servers aren't available for an hour (March 1, 2012, in the EU region) and the clients start calling, then it won't help you that they still have a 300 days uptime.
And when the lightning struck 1 out of 3 of their datacenters in the EU, we all found out that they have no off-site redundancies, and the fact that they have 3 datacenters doesn't mean a thing.
One must love the phrase "degraded performance", that actually means: "cross your fingers and pray that your data will still be available after the catastrophe passes".
I'm still trying to look for any official/non-official statistics about the availability percentages of all of their datacenters.
No luck thus far...
我在 EC2 上从未出现过停机情况，但是，我会保留本地备份并制作机器的每日映像，并将它们移植到另一个可用区域，以防万一。 如果某台机器无法通过电话呼叫我的所有设备，我会使用 twilio 来提醒我。 然后我可以登录 EC2 并启动另一个可用区中的机器； 最坏的情况是我要休息几分钟。
就我而言，这可能非常糟糕，因为我的机器正在进行 24/7 外汇交易。
我的规则是：了解停机的潜在成本，并愿意在假设它会发生的情况下在冗余方面投入大量资金 - 因为它会发生。
也就是说，EC2 从未让我失望过。 我的服务器不在该国自然灾害多发的地区，这可能会有所帮助。 如果您处于地震区、龙卷风带或潜在的飓风路径，停机确实是不可避免的。
I've never had downtime on EC2, however, I do keep local backups and make daily images of my machines and port them to another availability zone, just in case. I use twilio to alert me if a machine is unreachable with a phone call to all my devices. Then I can just log in to EC2 and fire up a machine in another availability zone; worst case I'll be down for a few minutes.
Which in my case, is potentially pretty sucky, because my machines are doing 24/7 Forex trading.
My rule: know the potential cost of downtime, and be willing to invest that much in redundancy assuming it will happen - because it will.
That said, EC2 has never let me down. Helps probably that my servers are not in an area of the country where natural disasters are common. If you're in an earthquake zone, tornado alley, or a potential hurricane path, downtime truly is an inevitability.