2

对于具有不太大的 SQL 服务器数据库（大约 10Gb）的 ASP Net Web 应用程序，您会推荐什么？

我只是想知道，配置 Amazon EC2 实例以在紧急情况下托管您的应用程序是个好主意吗？

在这种情况下，保持数据库更新的最佳方法是什么（日志传送？手动备份恢复？）以及更改 dns 设置的最简单和最快的方法是什么？

编辑：可接受的停机时间在 4 到 6 小时之间，这就是为什么我考虑使用 Amazon ec2 选项，因为与租用辅助服务器相比，它的成本更低。

4

4 回答 4

3

更新- 刚刚看到你的评论。带有日志传送功能的 Amazon EC2 绝对是必经之路。不要使用镜像，因为这通常假定另一个备用数据库可用。如果您将 TTL 设置为该值，则更改 DNS 的时间不应超过 1/2 小时。这将使您有时间集成任何待处理的日志。可能一周左右打开一次服务器，只是为了集成待处理的日志（或者更少，以避免增加每小时的成本。）

您的主要托管位置应在所有级别都有冗余：

  • 多个互联网连接，
  • 多个防火墙设置为故障转移，
  • 多个集群网络服务器，
  • 多个集群数据库服务器，
  • 如果您存储文件，请使用 SAN 或 Amazon S3，
  • 每台服务器都应该有某种形式的 RAID，具体取决于服务器的用途，
  • 每台服务器都可以有多个 PSU 连接到单独的电源/断路器，
  • 外部和内部服务器监控软件，
  • 停电时自动启动的发电机，以及备用发电机。

在大多数故障情况下，这将使您在主要位置运行。

然后在远程位置设置一个服务器，该服务器使用日志传送保持更新，并将其包含在您的部署脚本中（在更新您的正常生产服务器之后......）该国另一端的托管服务器非常适合这些目的。为了最大限度地减少不得不切换到辅助位置的停机时间，请将 DNS 记录上的 TTL 保持在您认为合适的水平。

当然，如此多的硬件会变得很陡峭，因此您需要确定什么值得停机 1 秒、1 分钟、10 分钟等，并相应地进行调整。

于 2009-02-01T03:44:45.353 回答
2

这完全取决于您的停机时间要求。如果为了不失去数十亿美元的业务，你必须在几秒钟内得到支持，那么你做的事情就会有很大不同，如果你有一个每月可以赚到 1000 美元的网站，而且它的收入停一天也不会受到太大影响。

我知道这不是一个特别有用的答案，但这是一个很大的领域，有很多变量，如果没有更多信息，几乎不可能推荐一些真正适合你情况的东西（因为我们真的不知道你的情况是）。

于 2009-02-01T03:24:56.250 回答
2

坚如磐石的灾难恢复策略的起点是首先计算出服务器/平台停机对业务的真正成本。

以下文章将帮助您开始正确的路线。

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1038783.html

如果您需要进一步的指导，好的旧谷歌可以提供更多的阅读。

这种性质的项目需要您与关键业务决策者合作，并且您需要与他们沟通停机时间的相关成本以及业务影响。您可能需要与多个业务部门协作才能收集所需的信息。然后，您需要共同决定什么是您的业务可接受的停机时间。只有这样，您才能设计出满足这些要求的 DR 策略。

您还会发现，进行此练习可能会突出您的平台当前配置在高可用性方面的缺点，这可能还需要作为一个备用项目进行审查。

从所有这些中删除的关键点是，关于什么是可接受的停机时间的决定不是由 DBA 单独决定，而是提供必要的信息和专家知识，以便做出现实的决定。您的任务是实施可以满足业务需求的策略。

不要忘记通过执行测试场景来测试您的 DR 策略，以验证您的恢复时间并练习该过程。如果到了需要实施 DR 策略的时候，您可能会面临压力，您的手机会频繁响起，人们会像蚊子一样在您周围徘徊。已经磨练并练习了您的 DR 响应，您可以有信心控制情况，实施恢复将是一个顺利的过程。

祝你的项目好运。

于 2009-02-01T13:49:58.283 回答
0

我没有使用不同的第三方工具，但我体验过 cloudendure，至于你得到的副本，我可以说它是一个非常高端的产品。复制是在非常小的时间间隔内完成的，这使得您的副本非常可靠，但我可以看到您不需要在几秒钟内备份您的网站，因此也许要求报价或与不同的供应商脱身可能会有所帮助。

于 2017-04-27T19:16:15.803 回答