数据库集群的最佳设置

Question

我需要为我投入生产的系统设置一个好的数据库集群解决方案。我希望从专家那里得到一些建议，因为我主要是一名开发人员而不是数据库管理员。

背景
我和我的团队正在用基于 .NET 的系统替换旧系统。目前，我们正在做并行测试，并在慢慢将用户迁移到新系统；然而，令我震惊的是，一旦 thigs 真正开始运行，我们当前的数据库解决方案不足以处理负载。现在，我在一台运行 SQL Server 2008 R2 的 Dell PowerEdge 服务器上拥有我们的整个数据库。它适用于开发和基本测试，但是当我们决定拔掉旧系统的插头并完全使用新系统时，我们将需要诸如故障转移、负载平衡、冗余等之类的东西。我从来没有实施过集群之前，因为我工作的任何地方都已经实施了，而不是我的责任来维护。由于我们正在从头开始实施基于 PC 的系统，因此我正在寻找一个起点。

建议
您对我目前的情况有什么建议：我们有大约 50 个内部用户，他们将负责从数据输入、索赔处理等方面的工作，并且可能有大约 1500-2000 个来自外部的并发连接。进行虚拟设置还是物理设置更好？光纤通道还是SATA？

Answer 1

故障转移很容易做到。这只需要共享存储和几台服务器。

SQL Server 不支持横向扩展到多个节点。然而，一个只有几千用户的设计合理的数据库应该能够很容易地在双芯片服务器上运行。我公司的系统在四芯片服务器（每个芯片有 6 个内核）上每秒支持大约 35k 次事务。

与任何数据库服务器一样，您需要为系统的每个部分使用多个 LUN。1 个用于数据，1 个用于索引，1 个用于事务日志，1 个用于 tempdb。

如果您买不起 SAN（您将单独购买 SAN 的费用为六位数），那么您应该考虑使用数据库镜像。与见证服务器一起使用时，可以在发生故障时自动进行故障转移，并且不需要共享存储。仍应使用不同的存储卷。

在您设计高可用性解决方案（集群、镜像、日志传送等）之前，您需要弄清楚您要防止什么。您愿意丢失多少数据？在故障转移期间，您可以承受停机多久？

Answer 2

首先要事。集群的本质是有两个或多个节点可以访问公共存储。因此，您将需要 SAN 设备。有很多供应商可供选择，我最熟悉的是NetApp，但周围还有很多供应商。您很可能希望通过iSCSI连接到此设备，为此您需要一个启动器。它只是比Emulex更容易管理，而且这对于您的第一个 SAN 来说可能有点大材小用了。

然后，您将在此设备上创建两个卷：一个仲裁磁盘和一个存储磁盘。我通常将它们安装为Q:和S:。仲裁盘供集群使用；通过 ping 磁盘上的块，集群件可以知道哪些节点处于活动状态并且运行良好。这个可以很小，100M就足够了。另一个是 SQL Server 数据和日志文件所在的磁盘。驱动器 S：仅在经典主动-被动故障转移对以及用户实际连接的 VIP 的情况下才会安装在主动节点上。如果第二个节点通过仲裁磁盘检测到第一个节点没有响应，它将控制 SCSI、挂载磁盘、绑定 VIP 并重新启动 SQL Server、从日志文件执行恢复，并恢复为用户提供服务。

您可以在虚拟化设置中使用所有这些，但对于专用生产用途，我通常使用强大的物理服务器（所有内容都是冗余的）。如果有那么多用户，你会受到计算的限制，我会对现代硬件感到惊讶。您更有可能首先遇到 SAN 设备的限制。值得将其视为一项投资并与您选择的供应商建立关系。打几个电话，免费请教他们的售前工程师……