最佳实践：使用Asp.net和Microsoft SQL 2005在两个物理站点之间实现负载平衡/实现高可用性的最佳方式是什么？

我想如果你想做一些可靠的事情，并且没有大量的运输费用，你需要两个数据中心之间的专用连接（我们这样做，并且通过互联网备份vpn路由，路由成本更高，以防出现问题专用链接）。

真正的出发点是要说明宕机时间的业务成本是多less – 您需要考虑是否有必要增加冷，热，热故障切换的成本。 如果不了解更多的信息，很难对可用的不同选项给予很好的指导。

我们为客户设置的最便宜的解决scheme是多个只读数据库（日志传送通常是足够的） – 然后，对于数据库的任何更新将这些数据发送到主服务器 – 在主服务器closures的代码中带有“标志” （在停电时自动触发）。 如果该标志被设置，我们不允许以一些用户友好的方式写入。

有时像“admin.example.com”这样的设置可以在单个服务器/单个sql服务器上用于所有更新 – 特别是在您有一个客户群进行更新的情况下，以及基本上查看所有内容的“用户”客户发布（房地产清单，例如这个模型非常适合）。

至于专用链接，而不是VPN – 如果您位于两个连接良好的数据中心，则可能不会担心它们之间的stream量，并且stream量将小于专用链接。 但是，使用VPN连接而不是局域网会显着降低性能，尤其是在您使用“chatty”sql应用程序（大量小型查询）的情况下。 尽pipeVPN倾向于使用TCP而不是UDP，这大大增加了等待时间，但是专用或VPN都会有所下降。

至于DNS：在每个位置设置DNS服务器，所以你有多余的DNS，你可以让每个DNS点只有本地服务器，而不是循环（这种方式，如果一个DNS服务器无法到达，你承担的Web服务器在那个位置也下了）。 否则，只需进行基本的循环，您可以报告下降位置的“A”logging。

这些东西不仅仅是一个简单的设置，你需要花费一些时间来计划使其正常工作。 第二个地方通常我告诉人们至less预算3倍的单一位置成本 – 特别是在计划阶段 – 加上程序员有时间实施必要的改变。

我们有一些更好的select，我们在同一附近的两栋build筑物之间拆分客户（在Equinix Ashburn（DC）有几座build筑物）。 我们运行我们在build筑物之间分开的骨干连接 – 这使得我们可以在build筑物之间进行故障转移，但是还可以利用局域网进行规划。 如果你只需要2-8台服务器就可以find像我们这样的人来设置它，并且协助规划将比自己做的更便宜。

东海岸/西海岸数据中心的拆分几乎总是有4-8个服务器的预算/复杂性。

祝你好运。

如何负载平衡到EC2，将花费比第二个数据中心less？