到目前为止，我一直在一个单一的（云或VPS）实例上build立我的项目。 总是相同的例程：安装LAMP，让它备份mysql的转储，保护SSH，让它运行多年，没有太多的维护。
这些都是小项目，从来没有任何问题。
这些项目现在变得越来越大，我刚刚在Rackspace发生硬件故障。 4小时的停机，客户端等待。 等等
所以，这是我的问题： 我需要学习如何获得下一个“级别”？
我应该开始分裂的东西了：一个单独的数据库服务器，一个单独的networking服务器等。我应该学习如何快速部署一个新的云实例宕机？ 我应该是…我还没有想到的东西…？
这取决于你的应用程序如何关键。 您可以设置HA（高可用性）configuration，使您的集群规模增加一倍（价格的两倍），并在发生任何问题时自动进行故障切换。
至于分裂服务器，这可能是一个好主意。 例如，您可以有两个负载平衡的前端节点为您的网页提供服务。 如果您发现其中一台服务器出现任何问题，则可以在检查问题的同时将失败的节点从负载平衡器中取出。 与此同时，所有stream量将继续由剩余的节点服务。
您应该制定高可用性（HA）和灾难恢复（DR）策略。
1. Build for server failure 云中的实例 – 就像在典型的数据中心一样 – 是短暂的。 您需要为服务器故障做好准备。 构build服务器故障始于devise无状态的应用程序，这些应用程序通过服务器或服务重新启动或重新启动来恢复
设置自动缩放，以便您的应用程序可以根据一组性能指标响应dynamicstream量模式。 设置数据库镜像，主/从configuration和/或启动以确保数据完整性和最小的停机时间。 使用dynamicDNS和静态IP，以便应用程序基础架构的组件始终具有正确的上下文。
2. Build for zone failure
有时，不仅仅是单一的服务器出现故障 – 有电源故障，networking中断和雷击。 您需要确保您的应用程序已准备好用于区域故障。 区域（amazon web services将它们称为“可用区域”）是不同的位置，它们被devise成与其他区域中的故障隔离。
在至less两个区域的每个应用程序层中分布服务器。 跨区域复制数据。