什么时候能够为网站引入高可用性？
高可用性选项有很多文章。 但是，现在是时候从单一服务器切换到高可用性configuration的时候了。
请考虑我的情况：
http://www.postjobfree.com是24/7网站与重要的交通：
http://www.similarweb.com/website/postjobfree.com
目前，我在单台服务器上运行它：IIS 7.0 Web服务器和SQL Server 2008都在相同的硬件框上运行。
偶尔会有（〜每月一次）~5分钟的停机时间，通常是由某些Windows Server更新所需的重新启动引起的。 通常停机时间是安排在夜间发生的。 尽pipe如此，它仍然令人不快，因为Google Bot和一些用户在晚上仍然活跃。
目前的网站收入约为8千美元/月。
我考虑切换到双服务器configuration（两台Web服务器的Web场和两台硬件服务器上托pipe的两台SQL Server的群集）。
优点：
1）高可用性（理论上没有停机时间）。 即使其中一台服务器出现故障 – 另一台服务器也将接pipe。
2）没有数据丢失：没有SQL集群，在硬件故障（我们每天做备份）的情况下，多达一天的数据可能会丢失。
缺点：
1）更多的努力来设置和维护这样的configuration。
2）更高的托pipe成本。 而不是600美元/月，这将是约1200美元/月。
你会推荐什么？
简短的回答：当停机时间或者风险增加的时候，你花费的比你花费的钱多得多。
这基本上是一个经济决定。 举个例子。 8千美元/月意味着2小时的停机将花费你22美元。 如果您可以configuration您的系统，使您可以在2小时内从头开始到function齐全的站点，那么高可用性只会使您获得高于此function的22个function。
换句话说，除非/在给定的月份里有54个小时的不可预见的停机时间，否则可以省钱。
您的利益相关者/商业人士（可能是您！）必须决定
收入损失很容易量化：其余的在这里不能回答抱歉…
我认为大多数用户可以处理一些预定的停机时间。 考虑到易趣在周五晚上有每周更新，然后周围的投标有时不起作用。 我的（澳大利亚主要的）银行的网上银行每周都安排了几个小时的停电。 Twitter一直在线下线。 Heroku / EC2最近倒了好几天。
我会保持这种观点，如果你只是每个月只说5分钟，那么作为一个系统pipe理员你做的很好。
您已经提到Google是索引方面的一个因素，但也可能值得考虑延迟/网站响应对SEO的影响。 这是一个黑盒子，所以很难量化 – 尽pipe马特·卡茨 （ Matt Cutts）认为这是值得的， 但这是一个值得一看的东西。 正如其他人所说，我更关心声誉。
请记住，房屋署和安全一样，不是一个产品，而是一个过程。
例如，数据库复制只能让您到达数据库的每个镜像都能够自行继续运行的地步，但是在更换失败的组件之后，您还需要一个重新同步的策略。
以订单系统为例：客户提交订单，在处理过程中，将订单信息存储在数据库的本地副本中后，他所谈论的物理系统失败。 不耐烦的是，客户再次按下“提交”，并被导向另一台接受订单的服务器。 如果您的数据库通过简单地重新播放另一端上缺less的INSERT语句来重新同步，则该命令将被复制，这可能不是您想要的。
正如@Slartibartfast所说，这一切都归结为一个经济决定，但是我build议你也计划在未来几年。 如果您希望需要适当的HA设置，那么现在就是为筹备工作拨出资源的好时机。
当你考虑这个问题时，我认为你考虑设置一个“失败鲸鱼”页面。
有很多方法可以做到这一点，但route53和s3的aws组合在我的小网站上运行良好。
我使用healthchecks设置域，以便在发生故障时，DNS将用户发送给坐在s3中的静态html页面; 成本几乎没有。
根据我的经验，您的网站上说“抱歉的事情已经坏了，但我们正在努力”对用户造成了一个不同的世界。 你甚至可以和用户沟通的Twitter账号甚至更好。
这对于缓解可能是停电最重要的影响的“声誉损失”来说是漫长的。
请参阅： https ： //aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/以获取设置指南。
DynDns的社交故障转移http://dyn.com/managed-dns/social-failover/是一种类似的东西。
您可以推出自己的健康检查程序，然后编写DNS更改脚本，只要您的DNSlogging具有较低的TTL值，并且可以通过某种方式以编程方式操作它们。
你有没有考虑过使用类似EC2的东西，这将让你灵活扩展，也消除你的缺点？ 如果使用EC2是最重要的经济决策，但是至less可以考虑。
为避免数据丢失，您应该查看群集之前的Raidconfiguration。 您还应configuration故障转移IP，以便在发生灾难时从一台服务器切换到另一台服务器，而无需等待DNS传播。