Windows Server 2008 R2继续存在于云中。因此，这是一个快速入门指南，适用于在Windows Server 2008 R2上需要SQL Server群集帮助的所有人。是的，Azure确实支持Windows Server 2008 R2和旧版本的SQL Server，包括2008 R2和2012。当然，在SQL 2012之前不会引入Always On Availability Groups，即便如此，由于与该版本相关的一些性能问题，您可能希望避免可用性组。需要支持旧版本的SQL Server或Windows吗？如Azure文档中所述，基于SIOS DataKeeper构建SANless群集。

Windows Server 2008 R2上的SQL Server群集 – 如何完成？

简而言之，这是SQL Server群集在Windows Server 2008 R2上的步骤

• 在同一可用性集中配置两个群集服务器和一个文件共享见证。这将所有三个法定人数投票放在不同的故障和更新域中。
• Azure中的SQL 2008 R2群集有一个修补程序，用于启用AG和FCI使用的侦听器。 https://support.microsoft.com/en-us/help/2854082/update-enables-sql-server-availability-group-listeners-on-windows-serv
• 安装该更新以及所有其他OS更新。
• 在每台服务器上配置存储。
• 格式化NTFS并给出驱动器号。
• 每个群集节点需要相同的存储。在每台服务器上启用故障转移群集和.Net 3.5 Framework
• 将服务器添加到域
• 创建基本群集，但使用POWERSHELL并指定群集IP地址。如果您使用GUI来创建群集，它将会混淆并提供重复的IP地址。通过GUI连接将使您能够从其中一个节点连接到群集。如果连接，则可以通过指定群集资源使用的静态IP地址来解决问题。以下是创建群集的Powershell用法示例

  New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.101 -NoStorage-

• 将文件共享见证添加到群集
• 在两个群集节点上安装DataKeeper
• 创建DataKeeper卷资源并确保它们是可用存储
• 像往常一样在共享存储群集中将SQL安装到群集中。
• 配置Azure ILB并运行powershell脚本以更新SQL群集IP资源以侦听探测端口。

所有这些都在SIOS文档页面上完整记录，在Azure中部署DataKeeper Cluster Edition如果您对Azure，AWS或Google Cloud中的SQL Server高可用性或灾难恢复有任何疑问，请访问我们关于群集和其他相关主题的页面。 经Clusteringformeremortals.com许可转载

您正在使用SIOS DataKeeper构建SANless SQL Server群集。或者您可能正在为SQL Server配置Always On Availability Groups。如何尝试在简单存储空间（RAID 0）中将多个磁盘拆分以获得性能？这通常在云中完成，其中每个实例通常都有硬件弹性支持，因此RAID 0并非真正具有风险。例如，我最近在AWS中有一个客户希望将其IOPS最大化到80,000 – 当前可用于单个实例的最大IOPS。现在请记住，只有最大的EBS优化实例大小才支持80,000 IOPS。因此，请确保您知道特定实例大小支持的最大IOPS。https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html在这种情况下，我们有ac5.18xlarge实例，它支持80,000 IOPS。但是，任何单个EBS预配置IOPS卷仅支持最高32,000 IOPS。写入任何单个卷时实现80,000 IOPS的唯一方法是在Simple Storage Space中将这些卷中的三个一起剥离。这就是摩擦。如果您尝试在现有群集中的简单存储空间中对多个磁盘进行剥离，那么事情就会变得非常快。MVP Joey D'Antoni最近在博客上发表了关于这个问题的博文。它似乎仍然是Windows Server 2019预览中的一个问题。正如Joey所说，我总是建议我的客户在开始集群过程之前构建节点和任何存储空间。这使得在简单存储空间中将多个磁盘剥离在一起的过程变得更加顺畅。它还允许客户在添加任何复制之前有时间对服务器的性能进行基准测试。并确保一切按预期工作。热衷于了解更多关于如何在简单存储空间中将多个磁盘捆绑在一起的快速提示，请查看我们关于群集的其他帖子经Clusteringformeremortals.com许可转载

在简单的存储空间中将多个磁盘一起剥离

您正在使用SIOS DataKeeper构建SANless SQL Server群集。或者您可能正在为SQL Server配置Always On Availability Groups。如何尝试在简单存储空间（RAID 0）中将多个磁盘拆分以获得性能？这通常在云中完成，其中每个实例通常都有硬件弹性支持，因此RAID 0并非真正具有风险。例如，我最近在AWS中有一个客户希望将其IOPS最大化到80,000 – 当前可用于单个实例的最大IOPS。现在请记住，只有最大的EBS优化实例大小才支持80,000 IOPS。因此，请确保您知道特定实例大小支持的最大IOPS。https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html在这种情况下，我们有ac5.18xlarge实例，它支持80,000 IOPS。但是，任何单个EBS预配置IOPS卷仅支持最高32,000 IOPS。写入任何单个卷时实现80,000 IOPS的唯一方法是在Simple Storage Space中将这些卷中的三个一起剥离。这就是摩擦。如果您尝试在现有群集中的简单存储空间中对多个磁盘进行剥离，那么事情就会变得非常快。MVP Joey D'Antoni最近在博客上发表了关于这个问题的博文。它似乎仍然是Windows Server 2019预览中的一个问题。正如Joey所说，我总是建议我的客户在开始集群过程之前构建节点和任何存储空间。这使得在简单存储空间中将多个磁盘剥离在一起的过程变得更加顺畅。它还允许客户在添加任何复制之前有时间对服务器的性能进行基准测试。并确保一切按预期工作。热衷于了解更多关于如何在简单存储空间中将多个磁盘捆绑在一起的快速提示，请查看我们关于群集的其他帖子经Clusteringformeremortals.com许可转载

SQL Server 2017 On Linus可用性组分裂脑问题

使用SQL Server在Linux上使用此支持文章避免拆分大脑。在Linux上运行SQL Server可以带来一些优势，例如在Azure中运行时可以节省操作系统的成本。做一些计算。随着核心数量的增加，成本节约是实质性的。此外，您为每个群集对授予至少两个服务器的许可。但是，如果技术不稳固，为什么还要省钱呢？我在Linux上运行SQL Server时遇到的最大问题之一是缺乏一致的HA / DR故事。在Windows上，Microsoft拥有整个HA堆栈，SQL Server严重依赖Windows Server故障转移群集来支持可用性组和故障转移群集实例。这已经运行了很多年，并且有很长的成功故事记录。迁移到Linux时，Microsoft不再拥有操作系统级别的HA堆栈。根据您的Linux发行版，您将继续尝试将Pacemaker等开源解决方案拼凑在一起。更不用说尝试与SQL Server可用性组合作。为了避免在Linux上使用SQL Server的可用性拆分，我宁愿选择第三方高可用性解决方案，如SIOS Protection Suite for Linux（SPS-L）。它为您在Linux上运行的业务关键型应用程序提供了经过验证的真正HA解决方案。

利用SIOS在Linux上使用SQL Server拆分可用性组

自1999年以来，SPS-L一直在保护在Linux上运行的关键业务应用程序。它是一个完整的HA / DR解决方案，可以监控。它可以恢复整个应用程序堆栈以及物理服务器和网络，以确保您的业务关键型应用程序具有高可用性。所有这些都在为远程数据中心或云的不同地理区域维护灾难恢复的第三个副本。SPS-L的另一个好处是它不需要SQL Server企业版，因此​​SQL Server许可证也可以显着节省成本。考虑SQL Server Standard Edition每个核心的成本为1859美元，而SQL Server Enterprise Edition的每个核心成本为7128美元。成本节约优势可能很大，具体取决于您需要许可的核心数量。以下是SPS-L保护在Azure云中运行Linux的SQL Server的视频演示。该演示显示SQL Server Standard Edition Cluster在不同Azure故障域中的节点之间手动故障转移，以及SPS-L响应意外故障。 想要了解其他提示，例如在Linux上使用SQL Server避免拆分可用性组，请阅读我们的博客，转发与ClusteringForMereMortals.com