设计选项:多集群、多实例或多可用性组

Question

我们有一个微软平台，里面有两套数据库。一组用于平台服务等的数据库和一组具有更多自定义性质的数据库，其中一些数据松散地连接到其他数据库。

我们希望将这些数据库集保持独立，因为我们希望数据库平台集比其他自定义数据库具有更高的性能，但它不是最重要的因素--高可用性、稳定性、最佳实践和很少的复杂性/易用性更为重要。

当我们集思广益时，我们想出了三种选择：

• 选项A: 2个集群，2个可用性组，这是我们目前的设置，显然是最好的(?)但也是最昂贵和最耗时的维护
• 选项B:一个大集群，一个默认实例，两个可用性组应该是最容易维护的，但是我们有哪些选项可以确保我们的“首选”AG (带有平台数据库)具有最高的可用性？
• 选项C: 1大集群，2个实例，2个可用组，使用此选项我们可以自定义每个实例的所有硬件资源，但多实例多AG的维护似乎也有点复杂。

如果其他人对上述方案有意见，我们想听听他们的意见吗？如果钱没有选择，你会选择什么？还有其他选择吗？

Answer 1

我们希望将这些数据库集保持独立，因为我们希望数据库平台集比其他自定义数据库具有更高的性能，但它不是最重要的因素--高可用性、稳定性、最佳实践和很少的复杂性/易用性更为重要。

这个问题很难回答，因为它可能是基于意见的。我用你的标准作为加权，从最重要到最不重要的顺序。

1. 高可用性
2. 稳定性
3. 简单环境(非复杂环境)

由于稳定性是由太多因素所决定的，所以第二种情况立即不能被使用。因此，我将只按这个顺序继续处理#1和#3。

在你提出的选项(A，B，C)中，我会立即将C.

选项C: 1大集群，2个实例，2个可用组，使用此选项我们可以自定义每个实例的所有硬件资源，但多实例多AG的维护似乎也有点复杂。

这个设置以最恶劣的方式违反了#3。拥有多个实例会导致更多的复杂性和更低的整体公平性。例如，一个实例中的IO峰值可能会对另一个实例产生有害影响，因为Windows (Linux不是选项)决定将在何处处理它(cpu)，驱动程序可能比其他cpu更多地使用某些cpu。这只是一个例子，我并没有全部列出。

这就剩下了A和B两种选择，所以可以归结为.选项A的价格点是比控制单个数据库性能的能力更大的决策因素吗？这是你需要回答的问题。

其他体系结构也存在，例如，使用FCIs可以提供类似的方法，而不需要AGs，一般来说，AGs比AGs的复杂度要低。因此，有两个集群和一个FCI可以是一种选择。一个具有4个或多个具有两个不同FCIs的节点的集群可以是一个选项，其中每个节点只能故意托管两个实例中的一个(其他实例没有安装)等等。