SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

在Azure中配置SQL Server故障转移群集实例的指南

by Leave a Comment

循序渐进：如何在Azure中配置SQL Server 2008 R2故障转移群集实例

如果您需要指南在Azure中配置SQL Server故障转移群集实例，您可能仍在使用SQL Server 2008/2008 R2。并且，如果将SQL Server 2008/2008 R2移动到Azure，则希望利用Microsoft提供的扩展安全更新。我之前在这篇博文中写过关于这个主题的文章。您可能想知道如何在迁移到Azure后确保SQL Server故障转移群集实例保持高可用性。今天，大多数人将业务关键型SQL Server 2008/2008 R2配置为其数据中心中的群集实例（SQL Server FCI）。在查看Azure时，您可能已经意识到由于缺少共享存储，您似乎无法将SQL Server FCI引入Azure云。然而，由于SIOS DataKeeper，情况并非如此。 SIOS DataKeeper使您能够在Azure，AWS，Google Cloud或其他任何无法使用共享存储的位置或您希望配置共享存储无意义的多站点群集的位置构建SQL Server故障转移群集实例。自1999年以来，DataKeeper一直在为Windows和Linux启用SANless集群。Microsoft在其文档中记录了SIOS DataKeeper在SQL Server故障转移群集实例中的使用：Azure虚拟机中SQL Server的高可用性和灾难恢复。 我之前写过有关SQL Server FCI在Azure中运行的文章，但我从未发布过特定于SQL Server 2008/2008 R2的循序渐进指南。好消息是它在SQL 2008/2008 R2和SQL 2012/2014/2016/2017以及即将发布的2019年一样好用。此外，无论Windows Server（2008/2012/2016/2019）或SQL Server（2008/2012/2014/2016/2017）的版本如何，配置过程都足够相似，本指南应足以让您完成任何操作配置。如果我的任何指南都没有涵盖您的SQL或Windows风格，请不要害怕跳进并构建SQL Server FCI并参考本指南，我想您会发现任何差异，如果您遇到困难在Twitter @daveberm上与我联系，我很乐意帮助你。本指南使用SQL Server 2008 R2和Windows Server 2012 R2。截至撰写本文时，我没有在Windows Server 2012 R2上看到SQL 2008 R2的Azure Marketplace映像，因此我不得不手动下载并安装SQL 2008 R2。我个人更喜欢这种组合，但如果您需要使用Windows Server 2008 R2或Windows 212，那就没问题了。如果您使用Windows Server 2008 R2，请不要忘记安装适用于Windows Server 2008 R2 SP1的kb3125574Convenience汇总更新。或者，如果您遇到Server 2012（而不是R2），则需要kb2854082中的修补程序。 不要被这篇文章所愚弄，该文章说你必须在SQL Server 2008 R2实例上安装kb2854082。如果您开始搜索Windows Server 2008 R2的更新，您会发现只有Server 2012的版本可用。Server 2008 R2的特定修补程序包含在Windows Server 2008 R2 SP1的汇总便捷汇总更新中。

提供无效的实例

我不会在这里详细介绍一些屏幕截图，特别是因为Azure门户UI经常会经常更改，所以我拍摄的任何屏幕截图都会很快变得陈旧。相反，我将只介绍您应该了解的重要主题。

故障域或可用区域？

为了确保您的SQL Server实例具有高可用性，您必须确保您的群集节点位于不同的故障域（FD）或不同的可用区（AZ）中。您的实例不仅需要驻留在不同的FD或AZ中，而且您的文件共享见证（见下文）也需要驻留在与您的群集节点所在的FD或AZ不同的FD或AZ中。这是我的看法。AZ是最新的Azure功能，但到目前为止它们仅在少数几个地区得到支持。AZ给你一个更高的SLA（99.99％）然后FD（99.95％），并保护你免受我在我的Azure Outage Post-Mortem后期描述的那种云中断。 如果您可以在支持AZ的区域中部署，那么我建议您使用AZ。在本指南中，我使用了AZ，当您进入有关配置负载均衡器的部分时，您会看到这些AZ。但是，如果使用FD，则所有内容都将完全相同，但负载均衡器配置将引用可用性集而不是可用区。

什么是文件分享证明你问的？

Windows Server故障转移群集（WSFC）要求您配置“见证”以确保故障转移正常运行，而无需详细说明。Windows Server Failover Clustering支持三种见证：磁盘，文件共享，云。由于我们在Azure中，因此无法使用磁盘见证。Cloud Witness仅适用于Windows Server 2016及更高版本，因此我们可以使用文件共享见证。如果您想了解有关群集仲裁的更多信息，请查看Microsoft Press博客上的帖子，来自MVP：了解Windows Server 2012 R2中的Windows Server故障转移群集仲裁

添加存储到您的SQL Server实例

在配置SQL Server实例时，您需要为每个实例添加其他磁盘。最低限度，您需要一个磁盘用于SQL数据和日志文件，一个磁盘用于Tempdb。在云中运行时，是否应该为日志和数据文件设置单独的磁盘有些争议。在后端，存储全部来自同一个地方，您的实例大小限制了您的总IOPS。在我看来，分离日志和数据文件确实没有任何价值，因为您无法确保它们在两个物理磁盘集上运行。我会留给你决定，但我把日志和数据全部放在同一卷上。通常，SQL Server 2008 R2 FCI会要求您将tempdb放在群集磁盘上。但是，SIOS DataKeeper有一个非常好的功能，称为DataKeeper非镜像卷资源。本指南不包括将tempdb移动到此非镜像卷资源，但为了获得最佳性能，您应该执行此操作。真的没有理由复制tempdb，因为它无论如何都是在故障转移时重新创建的。就存储而言，您可以使用任何存储类型，但必要时尽可能使用托管磁盘。确保群集中的每个节点都具有相同的存储配置。启动实例后，您需要附加这些磁盘并将它们格式化为NTFS。确保每个实例使用相同的驱动器号。

联网

这不是一个硬性要求，但如果可能的话，使用支持加速网络的实例大小。此外，请确保在Azure门户中编辑网络接口，以便您的实例使用静态IP地址。要使群集正常工作，您需要确保更新DNS服务器的设置，使其指向Windows AD / DNS服务器而不仅仅是某个公共DNS服务器。

安全

默认情况下，同一虚拟网络中的节点之间的通信是敞开的，但如果您已锁定Azure安全组，则需要知道必须在群集节点之间打开哪些端口并调整安全组。根据我的经验，在Azure中构建群集时遇到的几乎所有问题都是由阻塞的端口引起的。DataKeeper有一些端口需要在群集实例之间打开。这些端口如下：UDP：137,138 TCP：139,445,9999，以及10000到10025范围内的端口故障转移群集有自己的一组端口要求，我甚至不会尝试在此处进行记录。这篇文章似乎涵盖了这一点。 http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html此外，稍后描述的Load Balancer将使用必须允许每个节点上的入站流量的探测端口。本指南中常用和描述的端口是59999。最后，如果您希望您的客户端能够访问您的SQL Server实例，您需要确保您的SQL Server端口是打开的，默认情况下是1433。请记住，Windows防火墙或Azure安全组可以阻止这些端口，因此请务必检查这两个端口以确保它们可访问。

加入域名

SQL Server 2008 R2 FCI的要求是实例必须驻留在同一Windows Server域中。因此，如果您还没有这样做，请确保已将实例加入Windows域

本地服务帐户

安装DataKeeper时，它会要求您提供服务帐户。您必须创建域用户帐户，然后将该用户帐户添加到每个节点上的本地管理员组。在DataKeeper安装期间询问时，请将该帐户指定为DataKeeper服务帐户。注意 – 不要安装DataKeeper！

域名全球安全组织

安装SQL 2008 R2时，系统会要求您指定两个全局域安全组。您可能希望展望SQL安装说明并立即创建这些组。此外，创建域用户帐户并将它们放在每个安全帐户中。您将指定此帐户作为SQL Server群集安装的一部分。

其他预先要求

您必须在两个群集实例的每个实例上启用故障转移群集和.Net 3.5。启用故障转移群集时，还要确保启用可选的“故障转移群集自动化服务器”。 这是Windows Server 2012 R2中的SQL Server 2008 R2群集所必需的。

创建集群和DATAKEEPER卷资源

我们现在准备开始构建集群。第一步是创建基本群集。由于Azure处理DHCP的方式，我们必须使用Powershell创建集群，而不是集群UI。我们使用Powershell，因为它允许我们在创建过程中指定静态IP地址。如果我们使用UI，则会看到VM使用DHCP并且它将自动分配重复的IP地址。因此，为了避免这种情况，让我们使用Powershell，如下所示。

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

群集创建后，运行Test-Cluster。这在SQL Server安装之前是必需的。

测试群集

您将收到有关存储和网络的警告。值得庆幸的是，您可以忽略Azure中SANless群集中的预期。但是，请在继续之前解决任何其他警告或错误。创建群集后，您需要添加文件共享见证。在我们指定为文件共享见证的第三台服务器上，创建一个文件共享，并为我们刚刚创建的集群计算机对象提供读/写权限。在这种情况下，$ Cluster1将是在共享和NTFS安全级别都需要读/写权限的计算机对象的名称。创建共享后，您可以使用配置群集仲裁向导（如下所示）配置文件共享见证。

安装DATAKEEPER

在安装DataKeeper之前等待创建基本集群非常重要，因为DataKeeper安装会在故障转移群集中注册DataKeeper Volume Resource类型。如果你已经跳过枪并安装了DataKeeper就可以了。只需再次运行安装程序并选择“修复安装”。下面的屏幕截图将引导您完成基本安装。首先运行DataKeeper安装程序。

您在下面指定的帐户必须是域帐户。它必须是每个群集节点上的Local Administrators组的一部分。

当提供SIOS许可证密钥管理器时，您可以浏览到临时密钥。或者，如果您有永久密钥，则可以复制系统主机ID并使用它来申请永久许可证。如果您需要刷新密钥，SIOS许可证密钥管理器是一个将安装的程序，您可以单独运行以添加新密钥。

创建DATAKEEPER VOLUME RESOURCE

在每个节点上安装DataKeeper后，您就可以创建第一个DataKeeper卷资源了。第一步是打开DataKeeper UI并连接到每个群集节点。

如果一切都正确完成，服务器概述报告应该如下所示。

您现在可以创建第一个Job，如下所示。

选择源和目标后，您将看到以下选项。对于同一区域中的本地目标，您唯一需要选择的是同步。

选择“是”并将此卷自动注册为群集资源。

完成此过程后，打开故障转移群集管理器并查看磁盘。您应该在Available Storage中看到DataKeeper Volume资源。此时，WSFC将其视为普通的群集磁盘资源。

SLIPSTREAM SP3 ONTO SQL 2008 R2安装媒体

SQL Server 2008 R2仅在带有SQL Server SP2或更高版本的Windows Server 2012 R2上受支持。不幸的是，Microsoft从未发布过包含SP2或SP3的SQL Server 2008 R2安装介质。相反，您必须在安装之前将Service Pack整合到安装介质上。如果您尝试使用标准SQL Server 2008 R2媒体进行安装，则会遇到各种问题。我不记得你会看到的确切错误。但我记得他们并没有真正指出确切的问题。 你会浪费很多时间来弄清楚出了什么问题。截至本文撰写之日，Microsoft在Azure Marketplace中没有带有SQL Server 2008 R2产品的Windows Server 2012 R2。如果要在Azure中的Windows Server 2012 R2上运行SQL 2008 R2，请带上自己的SQL许可证。如果他们稍后添加该图像，或者您选择在Windows Server 2008 R2映像上使用SQL 2008 R2，则必须先卸载现有的SQL Server独立实例，然后再继续。我按照本文选项1中的指导将SP3整合到我的SQL 2008 R2安装介质上。您当然必须调整一些内容，因为本文引用的是SP2而不是SP3。确保在我们将用于群集的两个节点的安装介质上整合SP3。完成后，继续下一步。

在第一个节点上安装SQL SERVER

使用带有SP3的SQL Server 2008 R2媒体进行整理，运行安装程序并安装群集的第一个节点，如下所示。

如果您使用除SQL Server的默认实例以外的任何其他内容，则本指南中将介绍一些其他步骤。最大的区别是您必须锁定SQL Server使用的端口，因为默认情况下SQL Server的命名实例不使用1433。一旦锁定端口，每当我们引用本指南中的端口1433时，您还需要指定该端口而不是1433，包括防火墙设置和Load Balancer设置。

这里确保指定一个未使用的新IP地址。这是我们稍后在配置内部负载均衡器时将使用的相同IP地址。

正如我之前提到的，SQL Server 2008 R2使用AD安全组。如果您还没有创建它们，请继续创建它们，如下图所示，然后再继续执行SQL安装中的下一步

指定先前创建的安全组。

确保您指定的服务帐户是关联的安全组的成员。

在此处指定SQL Server管理员。

如果一切顺利，您现在可以在群集的第二个节点上安装SQL Server。

在第二个节点上安装SQL SERVER

在第二个节点中，运行带有SP3安装的SQL Server 2008 R2，然后选择“将节点添加到SQL Server故障转移群集实例”。

继续安装，如以下屏幕截图所示。

假设一切顺利，您现在应该配置一个双节点SQL Server 2008 R2群集，其外观如下所示。

但是，您可能会注意到只能从活动群集节点连接到SQL Server实例。问题是Azure不支持免费ARP。您的客户端可能无法直接连接到群集IP地址。相反，客户端必须连接到Azure负载均衡器，该负载均衡器将连接重定向到活动节点。要使此工作有两个步骤：创建负载均衡器并修复SQL Server群集IP以响应负载均衡器探测并使用255.255.255.255子网掩码。这些步骤如下所述。

创建AZURE负载平衡器

我将假设您的客户端可以直接与SQL群集的内部IP地址通信。让我们继续在本指南中创建一个内部负载均衡器（ILB）。如果需要在公共Internet上公开SQL实例，请改用Public Load Balancer。在Azure门户中，按照屏幕截图创建一个新的Load Balancer，如下所示。Azure门户UI快速变化。但是这些屏幕截图应该为您提供足够的信息来完成您需要做的事情。随着我们的进展，我会召集重要的设置。在这里，我们创建了ILB。在此屏幕上需要注意的重要事项是您必须选择“静态IP地址分配”。指定我们在SQL群集安装期间使用的相同IP地址。由于我使用了可用区，我将Zone Redundant视为一种选择。如果您使用可用性集，您的体验将略有不同。

在后端池中，请确保选择两个SQL Server实例。您不希望在池中添加文件共享见证。

在这里，我们配置健康探测器。大多数Azure文档使用端口59999，因此我们将坚持使用该端口进行配置。

然后我们将添加一个负载平衡规则。在我们的示例中，我们希望将所有SQL Server流量重定向到活动节点的TCP端口1433。选择浮动IP（直接服务器返回）为已启用也很重要。

运行POWERSHELL脚本以更新SQL客户端访问点

现在，我们必须在其中一个群集节点上运行Powershell脚本，以允许Load Balancer Probe检测哪个节点处于活动状态。该脚本还将SQL群集IP地址的子网掩码设置为255.255.255.255.255，以避免与我们刚刚创建的Load Balancer发生IP地址冲突。

＃定义变量
$ ClusterNetworkName =“” 
＃群集网络名称（在Windows Server 2012上使用Get-ClusterNetwork） 
更高的找到名字）
$ IPResourceName =“” 
#IP地址资源名称 
$ ILBIP =“” 
＃内部负载均衡器（ILB）和SQL群集的IP地址
导入模块FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
网络= $ ClusterNetworkName; EnableDHCP时= 0}
＃如果您使用的是Windows Server 2008 R2，请使用以下命令： 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
子网掩码= 255.255.255.255

如果正确运行，这就是输出的样子。

Windows服务器故障转移群集

您可能会注意到，如果您在Windows Server 2008 R2上运行，该脚本的末尾会有一行注释代码。运行Windows Server 2008 R2？确保在命令提示符下运行特定于Windows Server 2008 R2的代码，它不是Powershell。

下一步

如果你达到这一点，你不是第一个，你仍然无法远程连接到群集。在安全性，负载均衡器，SQL端口等方面存在许多可能出错的问题。我编写本指南以帮助解决连接问题。事实上，我在SQL Server配置管理器中的SQL Server TCP / IP属性方面遇到了一些奇怪的问题。当我查看属性时，我没有看到SQL Server群集IP地址作为其正在侦听的地址之一。因此我必须手动添加它。我不确定这是不是异常。虽然在我从远程客户端连接到群集之前，我必须先解决这个问题。正如我之前提到的，您可以对此安装进行的另一项改进是为TempDB使用DataKeeper非镜像卷资源。如果你设置它，请注意人们经常遇到的以下两个配置问题。第一个问题是如果将tempdb移动到第一个节点上的文件夹，则必须确保在第二个节点上创建完全相同的文件夹结构。如果不这样做，当您尝试进行故障转移时，SQL Server将无法联机，因为它无法创建TempDB。第二个问题发生在创建集群后，将其他DataKeeper卷资源添加到SQL集群的任何时候。您必须进入SQL Server群集资源的属性，并使其依赖于您添加的新DataKeeper Volume资源。对于TempDB卷和您在创建集群后可能决定添加的任何其他卷都是如此。如果您对此配置或任何其他群集配置有任何疑问，请随时通过Twitter @DaveBerm与我联系。

https://clusteringformeremortals.com/2016/01/06/troubleshooting-azure-ilb-connection-issues-in-a-sql-server-alwayson-fci-cluster/
经Clusteringformeremortals.com许可转载

可用性方程 – 高可用性解决方案

by Leave a Comment

可用性公式 - 高可用性解决方案.jpg

可用性方程

您熟悉可用性方程吗？简而言之，此等式显示了将应用程序恢复到可用性所需的总时间如何等于检测应用程序遇到问题所需的时间加上执行恢复操作所需的时间：

TRESTORE = TDETECT + TRECOVER

高可用性解决方案的关键概念

该等式引入了高可用性（HA）的关键概念：聚类，问题检测和后续恢复。HA解决方案监控业务应用程序组件的运行状况当检测到问题时，这些解决方案可以恢复它们的服务。部署高可用性解决方案的目标是最大限度地减少停机时间。减少检测和恢复时间是您选择部署的任何HA解决方案的两个重要任务。今天的应用程序是技术组合：服务器，存储，网络基础设施等。在查看HA选项时，请确保您了解每个解决方案用于检测所有中断类型并从中恢复的技术。每项技术都会对服务恢复时间产生直接影响。

本地检测和恢复

高可用性解决方案非常简单。一种对提供最快恢复时间至关重要的技术称为本地检测和恢复（也称为服务级别问题检测和恢复）。在基本群集解决方案中，服务器已连接。它们被配置为一个或多个服务器可以在服务器发生故障时接管另一个服务器的操作。群集中的服务器节点不断地向对方发送小数据包（通常称为心跳信号）以指示它们“活着”。在简单群集环境中，当一台服务器停止生成心跳时，其他群集成员会认为此服务器已关闭。然后，它将开始接管该服务器的操作域的责任。这种方法足以检测服务器级别的故障。但除非问题导致心跳信号中断或停止，否则服务器级检测不充分。更重要的是，它实际上可以放大停电的程度和影响。例如，如果Apache进程挂起，服务器仍可能发送心跳。即使Web服务器子系统已停止执行其主要功能。基本服务器级群集解决方案不是在相同或不同的服务器上重新启动Apache子系统，而是在备份服务器上重新启动故障服务器的整个软件堆栈，从而导致用户中断并延长恢复时间。

这个怎么运作

使用本地检测和恢复，高级群集解决方案在各个群集服务器中部署运行状况监视代理，以监视各个系统组件，如文件系统，数据库，用户级应用程序，IP地址等。这些代理使用特定于受监视组件的启发式方法。因此，代理可以预测和检测操作问题，然后采取最合适的恢复操作。通常，最有效的恢复方法是在同一服务器上停止并重新启动问题子系统。通过在同一物理服务器中启用恢复，可以大大减少将应用程序还原到用户可用性的时间。此外，通过更简单地检测故障，而不仅仅是通过观察服务器级心跳。诸如SIOS的SteelEye Protection Suite for Linux等解决方案可为您的环境提供此级别的检测和恢复。  确保您部署的HA解决方案也支持本地检测和恢复。您想为您的项目享受高可用性解决方案吗？请与我们联系。需要更多参考，以下是我们的成功案例。经Linuxclustering许可转载

使用Fusion-io最大化Linux群集的复制性能

by Leave a Comment

使用Fusion-io最大化Linux群集的复制性能

使用Fusion-io最大化Linux群集的复制性能的技巧

当大多数人考虑设置群集时，它通常涉及两个或更多服务器，以及SAN或其他类型的共享存储。SAN的设置和维护通常非常昂贵且复杂。此外，它们在技术上代表了集群架构中潜在的单点故障（SPOF）。如今，越来越多的人开始使用Fusion-io这样的公司，以及他们闪电般快速的ioDrives，来加速关键应用。  这些存储设备位于服务器内（即不是“共享磁盘”）。 因此，它不能用作具有许多传统群集解决方案的群集磁盘。幸运的是，有一些方法可以最大化使用Fusion-io进行Linux群集的复制性能。 允许您在不涉及共享存储时形成故障转移群集的解决方案 – 即“无共享”群集。

传统集群 使用Fusion-io - 传统集群最大化Linux集群的复制性能  “无共享”集群使用Fusion-io - 无共享群集最大化Linux群集的复制性能

在将数据复制作为群集配置的一部分时，充足的带宽至关重要，这样才能在网络上复制数据，就像写入磁盘一样快。  以下是调优技巧，可让您在涉及高速存储时充分利用“无共享”群集配置：

网络

  • 使用10Gbps网卡：Fusion-io（或OCZ，LSI等其他类似产品）的基于闪存的存储设备能够以MB /秒或更高的百万分之一（750）的速度写入数据。  1Gbps网卡只能推动理论最大值~125 MB /秒，因此任何利用ioDrive潜力的人都可以比通过1 Gbps网络连接推送更快地写入数据。  为确保服务器之间有足够的带宽以促进实时数据复制，应始终使用10 Gbps NIC来承载复制流量
  • 启用巨型帧：假设您的网卡和交换机支持它，启用巨型帧可以大大提高网络吞吐量，同时减少CPU周期。  要启用巨型帧，请执行以下配置（例如来自RedHat / CentOS / OEL linux服务器）
    • ifconfig <interface_name> mtu 9000
    • 编辑/ etc / sysconfig / network-scripts / ifcfg- <interface_name>文件并添加“MTU = 9000”，以便在重新启动后更改仍然存在
    • 要验证端到端巨型帧操作，请运行以下命令：ping -s 8900 -M do <IP-of-other-server>
  • 更改NIC的传输队列长度：
    • / sbin / ifconfig <interface_name> txqueuelen 10000
    • 将其添加到/etc/rc.local以保留重新启动后的设置

TCP / IP调整

  • 更改NIC的netdev_max_backlog：
    • 在/etc/sysctl.conf中设置“net.core.netdev_max_backlog = 100000”
  • 已显示可提高复制性能的其他TCP / IP调整：
    • 注意：这些是示例值，有些可能需要根据您的硬件配置进行调整
    • 编辑/etc/sysctl.conf并添加以下参数：
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = HTCP

调整

通常，您还需要对群集配置进行调整，这将根据您决定实施的群集和复制技术而有所不同。  在这个例子中，我使用的是SIOS Technologies的SteelEye Protection Suite for Linux（又名SPS，又名LifeKeeper）。 它允许用户利用几乎任何后端存储类型形成故障转移群集：光纤通道SAN，iSCSI，NAS，或者与本文最相关的本地磁盘，需要在群集节点之间实时同步/复制。  SPS for Linux包括集成的块级数据复制功能，这使得在没有共享存储时很容易设置集群。

建议

为了最大化使用Fusion-io的Linux群集的复制性能，让我们试试这个。SteelEye Protection Suite（SPS）for Linux配置建议：

  • 分配位于Fusion-io驱动器上的小（~100 MB）磁盘分区以放置位图文件。  在此分区上创建一个文件系统并将其挂载，例如，在/ bitmap：
    • #mount | grep /位图
    • / dev / fioa1 on / bitmap type ext3（rw）
  • 在创建镜像之前，请在/ etc / default / LifeKeeper中调整以下参数
    • 插入：LKDR_CHUNK_SIZE = 4096
      • 默认值为64
    • 编辑：LKDR_SPEED_LIMIT = 1500000
      • （默认值为50000）
      • LKDR_SPEED_LIMIT指定重新同步将采用的最大带宽 – 应设置为足够高以允许重新同步以尽可能最大的速度运行
    • 编辑：LKDR_SPEED_LIMIT_MIN = 200000
      • （默认值为20000）
      • LKDR_SPEED_LIMIT_MIN指定当同时进行其他I / O时允许重新同步的速度 – 根据经验，这应该设置为驱动器的最大写入吞吐量的一半或更少，以避免挨饿重新同步发生时，正常的I / O活动

从这里开始，像往常一样创建镜像并配置群集。有兴趣通过Fusion-io最大化Linux群集的复制性能，请参阅SIOS可以提供的其他内容。经LinuxClustering许可转载

我可以将我的文件共享证人放在DFS共享上吗？

by Leave a Comment

我可以将我的文件共享证人放在DFS共享上吗？

我可以将我的文件共享证人放在DFS共享上吗？

我一直被问到这个问题 – 哪里可以将我的文件共享见证放在DFS共享上。人们担心失去他们的文件共享证人。因此，与其他许多股票一样，他们希望利用DFS获得一些额外的可用性。这是一个非常糟糕的主意，不受支持。微软最近发布了一篇很棒的博客文章，该文章描述了为什么不支持DFS共享上的文件共享见证的原因。https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/本文的大部分内容也适用于那些询问是否可以使用DataKeeper将卷资源复制为磁盘共享。这说得通。对于任何其他工作负载，您可以使用DataKeeper卷资源代替物理磁盘资源，那么为什么不使用Disk Witness？此问题与DFS问题相同。如果两台服务器之间的通信中断，则无法保证两台服务器上的卷都不会联机。这将导致潜在的裂脑情况。物理磁盘资源通过使用SCSI保留克服了此问题。这将确保磁盘一次只能由一个群集节点访问。好消息是，微软已经阻止您尝试使用复制的DataKeeper Volume资源。在Windows Server 2019中，看起来它们也会阻止您将DFS共享用作文件共享见证。

来自故障转移群集和网络负载平衡团队博客文章“故障转移群集文件共享见证和DFS [/ caption]

有关于将文件共享见证放在DFS共享上的问题吗？阅读我们的博客或联系我们！经ClusteringForMereMortals.com许可转载

S2D用于SQL Server故障转移群集实例 

by Leave a Comment

存储空间直接（S2D）用于SQL Server故障转移群集实例

存储空间直接用于SQL Server故障转移群集实例

随着Windows Server 2016 Datacenter Edition的推出，引入了一项名为Storage Spaces Direct（S2D）的新功能。在非常高的级别，S2D For SQL Server故障转移群集实例允许您将本地连接的存储池合并在一起，并将其作为CSV呈现给群集，以便在扩展文件服务器中使用。然后，它可以通过SMB 3访问，并用于保存群集数据，如Hyper-V VMDK文件。这也可以以超融合（HCI）方式配置，使得应用程序和数据都可以在同一组服务器上运行。  这是一个非常简化的描述，但有关详细信息，您需要查看此处。

存储空间直接堆栈 图片取自https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview目标主要用例是Hyper-V部署的超融合基础架构。但是，还有其他用例，包括利用此SMB存储来存储要在SQL Server故障转移群集实例中使用的SQL Server数据

为什么有人想这样做？

那么，对于初学者，您现在可以使用SQL Server标准版构建高度可用的2节点SQL Server故障转移群集实例（FCI），而无需共享存储。以前，如果您想要没有SAN的HA，您几乎可以购买SQL Server企业版并使用Always On Availability Groups或购买SIOS DataKeeper并利用第三方解决方案，该解决方案允许您使用任何版本的Windows构建SANless群集或SQL Server。SQL Server企业版可以真正提高项目成本，特别是如果您只是为可用性组功能购买它。除了与可用性组相关的成本之外，还有许多其他技术原因可能会使您更喜欢故障转移群集而不是AG。应用程序兼容性，实例与数据库级别保护，大量数据库，DTC支持，经过培训的人员等等，只是您可能希望坚持使用故障转移群集实例的一些技术原因。

SIOS DataKeeper解决方案VSS用于SQL Server故障转移群集实例 

Microsoft在此处的文档中列出了SIOS DataKeeper解决方案和S2D解决方案，作为SQL Server FCI支持的两种解决方案。S2D用于SQL Server故障转移群集实例  https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr比较这两种解决方案时，你必须考虑到这一点自1999年以来，SIOS一直允许您构建SANless Clusters。但S2D for SQL Server故障转移群集实例仍处于起步阶段。  话虽如此，一定会有一些区域，S2D有一些赶上来做。或者，仅仅由于技术的限制，它们将永远不会支持的功能。

在选择SANless群集解决方案之前

有关在选择SANless群集解决方案之前应考虑的一些事项的概述，请查看下表。S2D用于SQL Server故障转移群集实例  如果我们浏览此图表，我们会发现SIOS DataKeeper显然具有一些显着优势。例如，DataKeeper支持更广泛的平台，一直回到Windows Server 2008 R2和SQL Server 2008 R2。S2D解决方案仅支持最新版本的Windows和SQL Server 2016/2017。S2D还需要Windows的Datacenter Edition，这会显着增加部署成本。此外，SIOS还为Linux上的SQL Server提供了唯一的HA / DR解决方案，既可以在本地也可以在云中运行。

分析差异

但是，除了成本和平台限制之外，我认为当我们开始考虑SANless群集的灾难恢复选项时，最明显的差距就出现了。Allan Hirt，SQL Server集群大师以及Microsoft Cloud和Datacenter Management MVP，最近发布了有关此S2D限制的文章。在他的文章Revisiting Storage Spaces Direct和SQL Server FCI中，Allan指出，由于缺乏对跨站点拉伸S2D群集的支持，或者包括基于S2D的群集作为Always On Availability Group中的支路，因此，DR的最佳选择是S2D场景是日志传送！别误会我的意思。原木运输已经永远存在，并且可能在我离开后很长一段时间。但是，当我们考虑我们已经习惯的所有灾难恢复解决方案时，例如多站点群集，可用性组等，这是向后迈出了巨大的一步。相比之下，SIOS DataKeeper解决方案完全支持Always On Availability Groups。更好的是 – 它可以让您跨站点扩展您的FCI，为您提供您希望在RTO / RPO方面实现的最佳HA / DR解决方案。在Azure环境中，DataKeeper还支持Azure站点恢复（ASR），为您提供更多灾难恢复选项。这个图表的其余部分非常自我解释。它基本上包括在部署S2D群集之前必须满足的列表硬件，存储和网络要求。这里保留了详细的S2D要求列表。  https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper。有什么好的

SIOS DataKeeper解决方案更加宽松。它支持任何本地连接的存储，只要硬件通过集群验证，它就是受支持的集群配置。块级复制解决方案一直运行良好，因为1 Gbps被认为是快速LAN并且T1 WAN连接被认为是奢侈品。SANless群集对于云部署尤其有用。云不为集群提供传统的共享存储选项。因此，对于想要随身携带群集的“升级并转移”到云中的用户，他们必须查看备用存储解决方案。对于云部署，SIOS已通过Azure，AWS和Google认证，可在相关的云市场中使用。虽然在Azure或Google中似乎没有阻止基于S2D的群集部署的任何内容，但Microsoft对这些平台的文档或支持性声明显然不足。

做出安全的选择

SIOS DataKeeper自1999年以来一直在这样做。SIOS已经听取了所有功能请求，发现了所有的错误，并为SANless集群提供了坚如磐石的解决方案，经过时间测试和验证。虽然微软S2D是一种很有前景的技术，但作为第一代产品，我会等到尘埃落定并且一些功能差距关闭之后我会考虑将它用于我的业务关键应用程序。

要了解有关S2D对于SQL Server故障转移群集实例的更多信息，请在此处查找SIOS DataKeeper经Clusteringformeremortals.com许可转载