我有一个带有 SQL Server 的 VM 和一个使用不超过 50 个用户的应用程序。如果我的虚拟机或数据中心出现问题,我不需要零停机应用程序,但我至少需要确保我可以在 30 分钟内再次使应用程序可用。
第一种方法:使用具有 2 个 VM 的可用性集实际上不起作用,因为我的 SQL Server 位于同一个 VM 中,我认为可用性集不会处理我的 SQL Server 数据的实时复制,它只会关心关于 Web 应用程序本身而不是持久数据(如果我错了,请告诉我),所以上面的声明 AV Set 不适合我。此外,由于有 2 个虚拟机,它会贵一倍。
第二种方法:将 Recovery Site 与灾难恢复一起使用 我正在阅读不会保证零数据丢失,因为复制的最低频率是 1 小时,因此您必须准备好处理 1 小时的数据损失,我不喜欢这样。
第三个选项:用于 SQL Server VM 的 Azure 备份,此选项可能会起作用,唯一的缺点是 RPO 为 15 分钟,这并不算多,但问题是,如果由于某种原因用户在应用程序中生成了一些关键记录,我们将无法让他们再次进入应用程序,因为用户在注册到应用程序时总是立即销毁所有内容。
第四种方法:因为我真的不需要零停机应用程序,所以我考虑让实际的 VM 使用 2 个高级磁盘,一个用于 SQL Server 数据文件,另一个用于 SQL Server 日志。如果 VM 发生故障,我会立即收到用户通知,我可以做的是创建 OS 磁盘和 SQL 高级磁盘(总共 3 个)的快照,然后使用这些快照创建一个新 VM,所以我会得到一个新的工作虚拟机可能在不同的区域中,在故障发生之前将确切的最后一个数据插入到 SQL 中。
当然,我想我需要在虚拟机上安装一个负载均衡器,这样我就可以将流量重新路由到新的虚拟机。失败的虚拟机我将杀死它并使用新的虚拟机作为我的新系统。如果再次发生故障,我只需遵循相同的流程,因此我只需支付一台 VM 而不是两台。
这是否有人已经尝试过,这听起来合理可行还是我错过了一件大事,或者我不会得到我期望得到的东西?