将存储复制与故障转移群集集成

在本系列的第1部分中，我们介绍了构建多站点群集所需的第一步。我们达到了使用节点和文件共享大多数法定人数的双节点群集的地步，没有定义任何资源。

我们继续吧

在本节中，我们将从停止的地方开始，看看您的复制解决方案如何与故障转移群集集成。由于每个供应商的复制解决方案将以不同方式实施，因此很难有一个文档来描述它们。需要记住的重要一点是，您希望购买与故障转移群集集成并由Microsoft认证的复制解决方案。您的选择基本上是基于阵列，基于设备或基于主机的复制解决方案。EMC同时提供基于设备和基于阵列的复制解决方案，似乎在这两方面都做得很好。EMC的John Toner维护着一个专门针对地理位置分散的群集的博客，如果您要采用EMC路线，我相信他可以引导您朝着正确的方向前进。所有的主要供应商都有解决方案，您只需要联系他们获取详细信息。

SIOS DataKeeper

在本次演示中，我将使用我公司SteelEye Technology的基于主机的复制解决方案SteelEye DataKeeper Cluster Edition。这是如此简单，以至于我不想写一篇长篇文章，而只是记录步骤，并在视频中与您分享。基于主机的复制的一个优点是可以利用现有存储，无论是本地连接的磁盘，iSCSI还是昂贵的SAN。基于主机的复制可以跨任何存储设备进行复制。

以下是您将在视频中看到的内容摘要。

• 启动SteelEye DataKeeper MMC管理单元
  • 创建一个新的DataKeeper作业，定义镜像端点，网络，压缩等
• 启动故障转移群集MMC管理单元
  • 创建一个Hyper-V资源
  • 添加一个DataKeeper卷资源
  • 编辑DataKeeper Volume资源的属性，将其与先前创建的镜像相关联
  • 使虚拟机配置依赖于新的DataKeeper卷资源

而已！你现在完成了。坐下来享受新的Hyper-V多站点群集。

点击观看视频

在本系列的第3部分中，我们将讨论Windows Server 2008 R2上的SQL 2008多站点群集。还有几个步骤，一些技巧和诀窍，你一定要知道，所以请确保你检查了解所有的细节。在此期间，如果您需要帮助，请给我留言或通过SIOS与我联系，我很乐意帮助您。

 介绍

欢迎阅读我的系列文章“逐步：在Windows Server 2008 R2上配置双节点多站点群集”的第1部分。在我们深入细节之前，让我们花点时间来讨论一个多站点集群是什么以及为什么要实现这个集群。微软有一个伟大的网页和白皮书，你会想要下载所有的细节，所以我不会在这里重复一切。但基本上，多站点集群是一个灾难恢复解决方案，而高可用性解决方案则集成在一个中。多站点群集为您的关键应用程序提供了最高的恢复点目标（RTO）和恢复时间目标（RTO）。随着Windows Server 2008故障转移群集的引入，通过引入交叉子网故障转移和支持高延迟网络通信，多站点群集变得更加可行。

我提到“跨子网故障转移”是Windows Server 2008故障转移群集的一个很棒的新功能，它是一个很棒的新功能。但是，SQL Server尚未支持此功能，这意味着您仍然需要在跨多个站点的SQL Server多站点群集中跨越子网。从Tech-Ed 2009开始，SQL Server团队就报告说他们计划支持这个功能，但是他们说在SQL Server 2008 R2发布后的某个时候。在可预见的未来，您将被困在一个SQL Server多站点群集的跨站点跨越您的子网。还有一些与网络相关的其他问题需要考虑，如冗余通信路径，带宽和文件共享见证安置。

网络考虑

所有Microsoft故障转移群集都必须具有冗余的网络通信路径。这可以确保任何一个通信路径的故障都不会导致错误的故障转移，并确保您的群集保持高可用性。多站点群集也有这个要求，所以你需要考虑到你的网络规划。通常有两件事情需要在节点之间传输：复制流量和群集心跳。除此之外，您还需要考虑客户端连接和集群管理活动。你将要确定，无论你有什么网络，你都不会压倒网络，否则你将会有不可靠的行为。您的复制流量很可能需要最大的带宽;您将需要与您的复制供应商合作以确定需要多少带宽。

通过冗余的通信路径，您需要考虑的最后一件事情就是仲裁模式。对于双节点多站点群集配置，Microsoft推荐的配置是节点和文件共享多数法定人数。有关法定类型的详细说明，请参阅本文。

与节点和文件共享多数法定人数混淆的最常见原因是文件共享见证的放置。我应该在哪里放置承载文件共享的服务器？让我们看看选项。

方案1 – 将文件分享到主要网站。

这当然是灾难恢复的有效选择，但不是高可用性。如果整个站点发生故障（包括主节点和文件共享见证），则辅助站点中的辅助节点将不会自动启动，您需要手动强制仲裁。这是因为它将是集群中唯一剩下的选票。三分之一不占多数！现在，如果您可以在发生灾难时采取手动步骤进行恢复，那么此配置对您而言可能是正常的。

方案2 – 将文件分享到第二网站。

这不是一个好主意。虽然它可以解决完全丢失网站时自动恢复的问题，但却可能导致错误的故障转移。考虑这个…如果你的辅助站点发生故障会发生什么？在这种情况下，您的主服务器（Node1）也将脱机，因为现在只有主站点中的单个节点，并且不再具有节点多数。由于涉及的风险太大，我看不出有什么好的理由来实施这种配置。

方案3 – 把文件放在第三个地理位置

这是首选配置，因为它允许在发生完全站点丢失的情况下自动进行故障切换，并消除辅助站点导致主节点脱机的任何故障的可能性。通过让第三方站点托管文件共享见证，您已经消除了任何一个站点作为单点故障，所以现在集群将按照您的预期运行，并且在站点丢失的情况下可以自动进行故障转移。识别第三个地理位置对于一些公司来说可能是一个挑战，但随着Amazon EC2和GoGrid等基于云的效用计算的出现，所有公司都可以将文件共享见证放在云中，并具有所需的弹性为有效的多站点群集。事实上，您可能会将云本身视为您的辅助数据中心，并在发生灾难时将其转移到云端。我认为基于云计算和灾难恢复配置的可能性是非常诱人的，事实上，我打算在不久的将来完成一个完整的博客文章。

配置集群

现在我们已经掌握了基础知识，现在让我们开始使用集群的实际配置。您需要将故障转移群集功能添加到群集的两个节点。为了简单起见，我已经调用了我的节点PRIMARY和SECONDARY。这通过添加功能向导非常容易地完成，如下所示。

接下来，您将需要查看您的网络连接。如果您重命名每个服务器上的连接以反映它们代表的网络，那么最好。这将使以后更容易记住。

您还需要进入每个服务器的网络连接的高级设置（点击Alt以查看高级设置菜单），并确保公共网络在列表中位于第一位。

您的专用网络应只包含一个IP地址和子网掩码。不应该定义默认网关或DNS服务器。您的节点需要能够通过此网络进行通信，因此请确保服务器可以通过此网络进行通信;如有必要添加静态路由。

配置完网络之后，即可开始构建群集。第一步是“验证配置”。打开故障转移群集管理器并单击验证配置。

“验证向导”将启动并显示如下所示的第一个屏幕。在群集中添加两台服务器，然后单击下一步继续。

多站点群集不需要通过存储验证（请参阅Microsoft文章）。Toskip存储验证过程中，单击“只运行我选择的测试”，然后单击继续。

在测试选择屏幕中，取消选择“存储”，然后单击“下一步”

您将看到以下确认屏幕。单击下一步继续。

如果你所做的一切正确，你应该看到一个如下所示的摘要页面。请注意，黄色感叹号表示并非所有测试都已运行。这是在多站点群集中预期的，因为存储测试被跳过了。只要其他一切都检查好，你可以继续。如果报告显示有任何其他错误，请修复问题，重新运行测试并继续。

您现在已经准备好创建您的群集。在故障转移群集管理器中，单击创建群集。

下一步询问您是否要验证您的群集。既然你已经这样做了，你可以跳过这一步。请注意，如果安装SQL，稍后会引起一些问题，因为这需要在继续之前通过验证。当我们到达这一点时，我将向您展示如何通过SQL Server安装程序中的命令行选项旁路此检查。现在，选择否和下一步。

下一步是您必须为此群集和IP创建一个名称来管理此群集。这将是您将用于管理群集的名称，而不是稍后将创建的SQL群集资源的名称。输入唯一的名称和IP地址，然后单击下一步。

注意：这也是需要文件共享见证权限的计算机名称，如本文后面所述。

确认您的选择并单击下一步。

恭喜，如果你已经做好了所有的事情，你会看到下面的总结页面。注意黄色感叹号;显然有些不完美。点击查看报告，找出问题可能是什么。

如果你查看报告，你应该看到几行看起来像这样的。

别烦恼这是在多站点集群中预期的。记得我们之前说过，我们将实施一个节点和文件共享多数法定人数。我们将从当前节点多数集群（在两节点集群中不是一个好主意）中将法定类型更改为节点和文件共享多数法定人数。

实现一个节点和文件共享多个定量

首先，我们需要确定将持有我们的文件共享见证的服务器。请记住，正如我们前面所讨论的，这个文件共享见证应该位于第三个位置，群集的两个节点都可以访问这个位置。一旦您确定了服务器，就像平常共享一个文件夹一样共享一个文件夹。就我而言，我在名为DEMODC的服务器上创建一个名为MYCLUSTER的共享。

要记住这个共享的关键是您必须授予共享级别和NTFS级别权限的集群计算机名称对共享的读/写权限。如果你回想一下图13，我创建了我的集群并给它起了名字“MYCLUSTER”。您将需要确保提供群集计算机帐户的读/写权限，如以下屏幕截图所示。

现在使用共享文件夹并分配了适当的权限，即可准备更改您的仲裁类型。在故障转移群集管理器中，右键单击群集，选择更多操作并配置群集仲裁设置。

在下一个屏幕上选择节点和文件共享多数，然后单击下一步。

在此屏幕中，输入您先前创建的文件共享的路径，然后单击下一步。

确认信息是否正确，然后单击下一步。

假设你做的一切正确，你应该看到下面的总结页面。

现在，当您查看群集时，Quorum配置应如下所示说“节点和文件共享多数”。

我列出的步骤直到适用于任何多站点群集，无论是SQL，Exchange，文件服务器还是其他类型的故障转移群集。创建多站点群集的下一步是将存储和复制解决方案集成到故障转移群集中。这一步将根据您的复制解决方案而有所不同，所以您确实需要与复制供应商保持密切联系才能做到正确。在本系列的第2部分中，我将演示SteelEye DataKeeper Cluster Edition如何与Windows Server故障转移群集集成，以便您了解复制供应商的解决方案之一是如何工作的。

本系列的其他部分将详细介绍如何在多站点群集中安装SQL，文件服务器和Hyper-V。我还会在三节点或更多节点的多节点集群上发表一个注意事项。

随着Windows Server 2008 R2的发布，其中一项增强功能是改善了动态VHD文件的性能。在R2之前，由于元数据缓存有限，写入动态扩展VHD文件的速度可能比写入固定大小的VHD文件慢3倍。总的来说，微软声称动态VHD文件与固定大小的VHD文件的性能几乎是相同的。配置Hyper-V虚拟机时，通过磁盘是另一种选择。根据我的研究结果，传递磁盘的性能比VHD文件略好。但是，如果使用pass-through磁盘，则会失去VHD文件的所有优点，例如便携性，快照和精简配置。考虑到这些折衷，如果您需要大于2TB的磁盘，或者如果您的应用程序受I / O限制，并且您真的可以从另一个.1毫秒刮掉的情况下使用传递磁盘，则应该只考虑使用传递磁盘你的平均响应时间。我认为，不要用微软的话来说，我会把这些不同类型的磁盘作为自己的测试。我设置了在Windows Server 2008 R2之上运行的Hyper-V Windows Server 2008 R2虚拟机。对于我的虚拟机管理程序，我使用连接到Dell AX150 SAN的Dell PowerEdge 1950服务器，并分割出三个10 GB的LUN用于测试。在Hyper-V管理器中，我添加了三个新磁盘，一个直通，一个动态VHD和一个固定大小的VHD。然后，我使用IOMeter来测试磁盘的性能。测试参数和原始数据可以在这个CSV文件中找到。下面的图表总结了我的结果。正如您所看到的，在极限（最大值/最小值）上，传递磁盘在大多数情况下都会胜出。但是，平均来说，三种不同类型的磁盘的性能几乎没有区别。

精简配置的好处，意思是构建一个VHD文件或多个VHD文件，其总大小大于可用磁盘空间，以及VHD文件的可移植性，这使得动态扩展VHD文件成为大多数Windows Server 2008 R2虚拟机的显而易见的选择。总之，我强烈建议您在Windows Server 2008 R2上使用动态扩展的VHD文件进行下一个Hyper-V部署。转载https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in- Windows的服务器-2008-R2 /