所以，有一点背景。 我为一家拥有一些非常重要，非公众网站的公司工作。 人民的安全和生计依靠这些熬夜。 我们的宕机时间很less，但总是有灾难性的情况，意味着从裸机恢复。
我们目前的设置是不够的，但我希望看到我认为是潜在的select。 我们将所有内容托pipe在令人难以置信的vSphere设置上。 现在，我们有一个可怕的Ubuntu实例，它托pipe着所有的站点，数据库，资产等等。
我们可以用各种方式进行备份，而vSphere设置的好处之一就是我们可以在异地进行恢复，但是只有一台大型机器意味着恢复时间不是微不足道的。
我可以看到两条道路。
简单的冗余。 从一台机器迁移到一台networking服务器，一台SAN和一台数据库服务器，然后让冗余机器准备好全天，或者能够快速启动。 这是我传统上希望存在的，但是我不知道它对我们有什么帮助。 在场外恢复意味着需要花费数小时才能恢复所有站点，而且恢复的方式似乎很难，我可以优先select最关键的任务。 在内部，使用vSphere，这似乎不是一个巨大的优势。 但是，这很容易维护。
用vSphere分割一切。 每个站点都可以是自己的vSphere实例（或一小组vSphere实例来拆分数据库/资产）。 这意味着更多的工作要维护一些小型服务器，而不是一个单一的小型服务器，但这也意味着我可以轻松地select在灾难性情况下恢复站点A和站点B，并在以后将非任务关键的事情留下。 这也可以让事情在必要的时候明智地分歧，这既是积极的事物，也是消极的事情。
意见？ 我是否忽略了一个明显的select？
利用VMware SRM或至lessVMware复制。 这将大大减less您在辅助数据中心上线所花费的时间。 （Hyper-V副本和HVRM在Microsoft堆栈中是等效的。
将您的前端与后端分开。 这听起来像你需要一个Web层和一个数据库层。
为您的前端投资适当的负载平衡。 这可能意味着安装和configuration一个多站点Netscalar集群，或configuration像HAProxy。
在数据库层中引入冗余。 您没有提及您正在使用的数据库产品，但许多数据库具有高可用性，复制，集群等可用。 用这个。
让你的灾难恢复站点成为一个“温暖的站点”，你有一些不断运行的服务器，比如数据库镜像。 那么你不必在灾难中恢复他们，只要把他们变成活动节点。
vSphere通过将硬件抽象出来，使备份和恢复更容易，但在可用性至关重要的情况下，它无法替代经过validation的真正的HA方法。
没有理由每个网站都有一个vSphere实例。 这不会给你带来什么
我比第一次更经常看到第二个设置，特别是当您的DR站点与主站点不具有相同的容量时。 不过，我认为这个问题对于SF来说并不合适，因为它基于很多的意见（尽pipe我不打算这么说，因为我看到了这个问题的某些价值）。