服务器镜像策略问题 SQL Server 复制、MySQL 复制、文件复制等

服务器镜像策略问题 SQL Server 复制、MySQL 复制、文件复制等

我在一家公司担任应用程序开发人员,工作已有一段时间。该公司希望将现有的 Windows 服务器(服务器 A)镜像到新服务器(服务器 B),主要目的是在任一服务器不可用时提供冗余。硬件负载平衡器将管理到任一服务器的流量方向。在任何给定时间,只有一台服务器接收流量。在每台服务器上,运行所有应用程序所需的所有资源都位于一台机器上。

需要在两台机器之间双向同步的数据是:

  • 几个 MySQL 数据库。
  • 两个 SQL Server 数据库。
  • .NET 应用程序和经典 ASP 网站的源代码。
  • 电子邮件服务器。文件。
  • 其他应用程序、备份例程等。
  • 服务器设置(如果可能)。

主机托管公司对负载平衡和复制有自己的想法,但我被要求管理这一点。

我对此有一些普遍的担忧,包括:

  1. 从流程角度来看,这不是我工作过的最结构化的公司(公司中源代码控制经验很少,可以自由访问配置经常更改的实时服务器,没有文档等)。这可能需要比目前更多的技术纪律。

  2. 所有应用程序都不支持集群。大多数数据库操作都是非事务性的。

我的具体问题是:

  • 我在这里描述的双服务器故障转移配置是否常见?有什么优点/缺点吗?

  • 双向数据复制有哪些潜在缺陷?两个数据库服务器都需要同时充当发布者和订阅者。如何审计与数据并发相关的风险?

  • 是否有任何工具可以复制服务器软件安装/设置?(由于两台服务器的硬件和规格不同,因此可能无法进行成像)。我想保留操作系统设置/数据库架构/源代码/版本控制服务器/电子邮件服务器等可能会是一笔很大的开销?

  • 鉴于我前面提到的担忧,我是否应该建议我们放慢速度,直到我们能够带来更好的系统管理并解决任何潜在的应用程序弱点后再继续,或者您是否认为一旦第二台服务器投入使用,必要性将成为这些变化的最佳驱动力?

抱歉,如果这有点啰嗦。欢迎任何关于如何管理这个问题的见解,或者类似“你应该把这件事留给那些知道自己在做什么的人”的评论!

答案1

这个问题太大了;你可能不会得到具体的答案。

为了实现“多主”复制,即两台服务器都响应,您需要针对每种协议(SQL、SMB、HTTP 等)分别解决该问题。更简单的方法是在主动-被动方案中一次只使用一台服务器,但您仍在讨论一种高度复杂的解决方案,以确保所有这些应用程序和协议中数据零丢失。

最简单但不太可能是最好的解决方案是让它成为故障转移主机群集上的虚拟机,但如果你有计划外的故障转移我相信您会在虚拟机重新启动时丢失内存中的内容。

Windows 文件服务、IIS 和 SQL Server 都有其不同级别的冗余,但每个级别都是独一无二的,需要根据您的特定应用需求进行评估。

如果是我,我会根据正常运行时间和数据的重要性来做决定。如果您能忍受虚拟机集群主动-被动方案,那就这样做吧。我认为试图在一个机器上用所有这些不同的技术使其成为多主机是一场噩梦。我不知道有谁会这样做。他们/我们有 SQL 服务器进行镜像,电子邮件在单独的服务器上做自己的事情,等等。您添加的每个应用程序都是它自己的高可用性“解决方案”(对我来说)。

相关内容