SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

删除最薄弱的链接，确保高可用性群集配置

by Leave a Comment

构建高可用性群集配置

构建高可用性群集配置时，您的应用程序可用性仅与其最薄弱的链接一样好。这意味着，如果您购买了具有冗余一切（CPU，风扇，电源，RAID，RAM等）和具有多路径连接的超豪华SAN的优质服务器。与多个SAN交换机配合使用，并将您的应用程序与您喜欢的群集软件集中在一起。 你可能有一个非常可靠的应用程序 – 对吧？嗯，不一定。服务器是否插入同一台UPS？它们是否在同一个网络交换机上？它们是否由同一个交流单元冷却？他们在同一栋楼里吗？您的SAN真的可靠吗？其中任何一个问题都是高可用性群集配置中的单点故障。

寻找和删除群集配置中最薄弱的环节

当然，你必须知道什么时候“足够好”是“足够好”的。你的预算和你的SLA将有助于决定什么是好的。然而，我担心人们可能正在掠过的一个领域是存储领域。随着廉价或免费的iSCSI目标软件解决方案的出现，我看到一些人建议你只是将一些iSCSI目标软件放在备用服务器上，并且即时共享存储。

请注意，我不是在谈论内置故障转移技术和/或其他可用性功能的OEM iSCSI解决方案;甚至是FalconStor等存储虚拟化解决方案。我正在谈论那些运行Windows Server 2008的服务器，他装载了存储并希望将其转换为iSCSI目标。这在实验室很棒。但如果你认真对待医管局，你应该再考虑一下。即使是微软也只提供他们的iSCSI目标软件给合格的OEM制造商，他们在提供企业级存储阵列上经验丰富。

你实际上得到了什么？

首先，这是Windows。 没有一些经过强化的操作系统只能用于存储。这将需要维护，安全更新，硬件修复等。它基本上与您要保护的应用程序服务器具有相同的可靠性。集群应用程序服务器是否有意义。然而，使用相同类别的服务器和操作系统来托管您的存储？您基本上已将单点故障从应用程序服务器移开并将其移至存储服务器。就我而言，这不是一个聪明的举动。

某些企业级iSCSI目标软件包括同步和/或异步复制软件和快照功能。此功能肯定有助于恢复点目标（RPO）。虽然它不会帮助您恢复时间目标（RTO），除非故障转移是自动且无缝到您的群集软件。假设主iSCSI存储阵列在半夜失败。谁将在那里激活复制副本？在您意识到存在问题之前，您可能已经停机了很长时间。再次，这可能是“足够好”;你只需要知道你正在注册的东西。这是您正在寻找的高可用性群集配置吗？

SIOS DataKeeper

为提高iSCSI目标服务器的可靠性，您可以做的一件事是使用SteelEye DataKeeper Cluster Edition等复制产品来消除单点故障。让我来说明一下。

典型的共享存储配置
图1 – 典型的共享存储配置。如果iSCSI目标不可用，则所有节点都将脱机。

如果我们采用上面显示的相同配置并使用SteelEye DataKeeper Cluster Edition添加热备用iSCSI目标来执行复制和自动故障转移，那么您刚刚为iSCSI目标解决方案提供了全新的可用性级别。这个解决方案看起来非常像这样。

DataKeeper Cluster Edition - 高可用性群集配置
图2 – 在这种情况下，DataKeeper Cluster Edition正在将主动节点上的iSCSI附加卷复制到被动节点上的iSCSI附加卷上，被动节点连接到一个完全不同的iSCSI目标服务器。

使用SteelEye DataKeeper Cluster Edition的解决方案与某些iSCSI目标供应商提供的复制解决方案的主要区别在于与WSFC的集成。要问你的iSCSI解决方案供应商的问题是这样的…

如果我拔下活动的iSCSI目标服务器上的电源线，会发生什么情况？

如果恢复过程是手动过程，则不是真正的HA解决方案。但是如果它是自动的并且与WSFC完全集成呢？然后，您可以获得更高级别的可用性，并将iSCSI阵列作为单点故障排除在外。

与我们聊天也可以实现高可用性群集配置

经Clusteringformortals许可转载。

Steeleye Datakeeper Cluster Edition荣获Windows It Pro最佳高可用性/灾难恢复奖

by Leave a Comment

我很高兴地宣布，Windows IT Pro授予SteelEye DataKeeper Cluster Edition两个类别的最佳高可用性和灾难恢复产品;社区选择金奖和编辑最佳银奖。

SteelEye DataKeeper集群版 - 最佳高可用性灾难恢复产品SteelEye DataKeeper集群版 - 最佳高可用性灾难恢复产品

作为SteelEye DataKeeper团队的一员，我感到非常自豪，我很欣赏在社区选择奖中为我们投票的所有Windows IT Pro社区！

转载https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/的许可

如何在多站点群集中使用异步复制？数据不同步？

by Leave a Comment

如何在多站点群集中使用异步复制？数据不同步？

我被问过这个问题不止几次了，所以我想我会在我的第一篇博文中回答这个问题。  基本答案是肯定的，在多站点集群中使用异步复制时，可能会导致意外失败的数据丢失。  在一个理想的世界里，每个公司都会有一个到他们灾难恢复站点的暗光纤连接，并使用与他们的多站点集群同步复制，消除数据丢失的可能性。  但是，现实情况是，在许多情况下，到灾难恢复站点的广域网连接有太多的延迟来支持同步复制。  在这种情况下，异步复制是一个很好的选择。

我的选择是什么？

选择与WSFC多站点群集一起使用的异步复制解决方案时，有多个选项。这包括来自EMC，IBM，HP等公司的基于阵列的解决方案。和基于主机的解决方案，比如我亲近的解决方案，“SteelEye DataKeeper Cluster Edition”。  由于我最了解DataKeeper，所以我将解释DataKeeper的这一切是如何工作的。

SteelEye DataKeeper怎么样？

当使用SteelEye DataKeeper和异步复制时，我们允许将一定数量的写入存储在异步队列中。  可以排队的写入次数由“高水位线”确定。这是DataKeeper使用的可调整值，用于确定在镜像状态从“镜像”更改为“暂停”之前队列中可以有多少数据。  当辅助服务器和主服务器之间发生通信故障时，也会进入“暂停”状态。处于暂停状态时，多站点群集中的自动故障转移将被禁用，从而限制意外故障中可能丢失的数据量。  如果原始数据集被认为是“永久丢失”，则可以手动解锁目标服务器上的剩余数据，然后可以使集群节点投入使用。

在“暂停”状态下，DataKeeper允许异步队列耗尽，直到达到“低水位”，此时镜像将进入“重新同步”状态，直到所有数据再次同步。  此时，镜像再次处于“镜像”状态，自动故障转移再次启用。

只要你的广域网链路没有饱和或破坏，在这个异步队列中的任何时候，你永远不应该看到更多的写入。  如果出现意外的故障（请拔掉电源线），您将失去异步队列中的任何写入。  当您需要使用多站点群集实现的卓越恢复点目标（RPO）和恢复时间目标（RTO）时，这是您所做的权衡，但您的WAN链路有太多的延迟来有效支持同步复制。

试试SteelEye DataKeeper

花时间通过Windows性能日志和警报监控DataKeeper异步队列。我想您会惊喜地发现，由于DataKeeper复制引擎的效率，异步队列大部分都是空的。  即使在写入繁重的时候，异步队列也很少增长，并且几乎立即耗尽。因此，在任何给定时间处于风险中的数据量是最小的。  与从昨晚的备份恢复的灾难中的备选方案相比，使用异步复制在意外故障中丢失的写入次数最少！

当然，也有一些情况下，即使丢失一个单一的写是不可容忍的。  在这种情况下，建议在高速，低延迟的LAN或WAN连接上使用SteelEye DataKeeper的同步复制选项。

经Clusteringformeremortals.com许可转载

为什么我应该把我的#AZURE集合转换为管理磁盘今天！

by Leave a Comment

您可能已经听说过最近的存储中断，影响了美国东部地区在3月16日的一些情况。 停电的根本原因分析在这里张贴。

3月16日美国东部存储中断

客户影响：在美国东部地区使用Storage的客户的一小部分可能在单个存储量表单元访问其存储帐户时遇到错误和超时

您可能会问：“什么是单个存储量表单元”。 那么，你可以把它看成一个单一的存储集群，或是一个SAN，或者你想要考虑它。 我不认为Azure发布其精确的基础架构，但是您可以假设幕后使用的是扩展文件服务器来进行后端存储。

所以问题是，如何以最短的停机时间在这种停电中幸存下来？如果你进一步阅读根本原因分析，你会遇到这个小块。

在可用性集中使用托管磁盘的虚拟机将在此事件期间保持可用性。

什么是托管磁盘你问？那么就在2月8日，科里·桑德斯（Corey Sanders）宣布管理磁盘阵列。 您可以在这里阅读有关托管磁盘的所有信息。 https://azure.microsoft.com/en-us/services/managed-disks/

托管磁盘有助于中断这一原因是通过利用可用性集合与托管磁盘组合，您可以确保可用性集中的每个实例都连接到不同的“存储量表单元”。 因此，在这种特殊情况下，只有一个集群节点将失败，剩下的节点才能接管工作负载。

在托管磁盘可用之前（任何部署在2/8/2016之前），没有办法确保连接到您的服务器的存储位于不同的存储容量单位上。 当然，您可以为每个实例使用不同的存储帐户，但实际上并不能保证这些存储帐户在不同的存储量表单元上配置存储。

因此，当可用性集确保您的实例驻留在不同的故障域和更新域中以确保实例本身的可用性时，附加到每个实例的额外存储确实代表了单点故障。 虽然存储本身具有高度的灵活性，但可以使用三个数据副本和地理冗余选项，在这种情况下，电源故障，整个存储量表单元与连接的所有服务器一起下降。

这么长的故事简短…尽快迁移到托管磁盘，以帮助最小化停机时间

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

如果您真的想减少停机时间，那么您应该考虑跨云提供商的混合云部署或云计算的一体机。

使用 arm 在 azure 中部署2节点文件服务器故障转移群集

by Leave a Comment

使用 arm 在 azure 中部署2节点文件服务器故障转移群集

在这篇文章中我们将详细介绍部署在 Azure 使用 Azure 资源管理器的单个区域的 2 节点文件服务器故障转移群集所需的具体步骤。我将假设你熟悉蔚蓝的基本概念，以及故障转移群集的基本概念和这篇文章在什么是独特的部署文件服务器故障转移群集在 Azure 将焦点。

与 DataKeeper 集群版你是能够采取本地连接的存储器，是否它是溢价或标准的磁盘，以及无论是同步、异步复制这些磁盘或混合或两个，两个或多个群集节点之间。此外，Windows 服务器故障转移群集的物理磁盘资源发生在注册 DataKeeper 卷资源。而不是控制 SCSI 3 保留像物理磁盘资源，DataKeeper 音量控制镜子方向，确保主动节点始终镜像的源。故障转移群集而言，它看起来、感觉和闻起来像物理磁盘和用同样的方式将使用物理磁盘资源。

先决条件

使用 azure 门户部署文件服务器故障转移群集实例

打造 Azure 中 2 节点文件服务器故障转移群集实例，我们将假定您有一个基本的虚拟网络基于 Azure 资源管理器上和你有至少一个虚拟机启动运行且配置为域控制器。一旦你有一个虚拟的网络和域配置，您要提供两个新的虚拟机将作为我们的集群中的两个节点。

我们的环境将如下所示：

DC1 — — 我们的域控制器和文件共享见证
SQL1 和 SQL2 — — 我们文件服务器群集中的两个节点

设置两个群集节点 (sql1 和 sql2)

使用 Azure 门户，我们将提供 SQL1 及 SQL2 完全相同的方式。有许多选项可供选择的包括实例的大小、存储选项等。本指南不是要部署在 Azure 服务器，因为有一些很好的资源和更多公布的每一天的详尽指南。然而，有几个关键的事情，要牢记心中，特别是在集群环境中创建您的实例时。

可用性组 — — 重要的是 SQL1、SQL2 和 DC1 驻留在相同的可用性设置。把它们放在同一可用性设置为了确保每个群集节点和文件共享见证的文件驻留在不同故障和更新域。这有助于确保在计划的维护和群集将继续能够维持仲裁并避免停机时间的额外的维护期间。

3
图 3 — — 一定要添加群集节点和文件共享见证到相同的可用性设置

静态 IP 地址

一旦被提供每个 VM，要进入设置和更改的设置，是静态的 IP 地址。我们不想改变我们群集节点的 IP 地址。

4
图 4 — — 确保每个群集节点使用一个静态的 ip 地址

存储

存储而言，你会想要请教，SQL Server 在 Azure 虚拟机的性能最佳做法。在任何情况下，你将微需要添加到每个群集节点至少一个额外的磁盘。DataKeeper 可以使用基本磁盘、保费存储或甚至组成的存储池中的多个磁盘的存储池。只是存储的一定要将相同数量添加到每个群集节点并将其配置完全相同。另外，一定要使用一个不同的存储帐户，为每个虚拟机以确保在同一时间同一个存储帐户的问题不会影响这两个虚拟机。

5
图 5 — — 一定要向每个群集节点中添加额外的存储

创建群集

假设两个群集节点 （SQL1 和 SQL2） 有调配如上文所述，添加到您现有的域，我们准备创建群集。我们在创建群集之前，有几个功能，需要启用。这些功能是.Net Framework 3.5 和故障转移群集。需要在两个群集节点上启用这些功能。您还将需要启用文件服务器角色。

6
图 6 — — 启用这两个.Net Framework 3.5 和故障转移群集功能和文件服务器上两个群集节点

一旦已启用了这一作用和那些功能，你就可以打造您的群集。大部分的通过 PowerShell 和 GUI 正要显示您可以执行两个步骤。然而，我要去推荐，对于这第一步你使用 PowerShell 创建您的群集。如果你选择使用故障转移群集管理器图形用户界面来创建群集，你会发现，风正在问题重复的 IP 地址的群集。

没有继续深入，你会发现是 Azure Vm 必须使用 DHCP。通过指定静态 ip 地址，当我们在 Azure 门户中创建 VM 我们所做的一切是创造某种 DHCP 保留。它不完全是 DHCP 保留，因为真正的 DHCP 保留将从 DHCP 池中删除该 IP 地址。相反，这在 Azure 门户中指定一个静态 ip 地址只是意味着，如果该 IP 地址是仍然可用，VM 请求它时，Azure 将向它发出该 IP。然而，如果你的虚拟机处于脱机状态，另一台主机联机，同一子网中它很好能发出那相同的 IP 地址。

还有另一个奇怪的副作用到 Azure 已实现 DHCP 的方式。当创建的群集与 Windows 服务器故障转移群集 GUI 时主机使用 DHCP （其中他们有到），不是选项，以指定一个群集 IP 地址。相反，它依赖 DHCP 获取地址。奇怪的是，DHCP 将发出一个重复的 IP 地址，通常主机请求一个新的 IP 地址相同的 IP 地址。群集通常将完成，但你可能有一些奇怪的错误，您可能需要从不同的节点运行 Windows 服务器故障转移群集 GUI，为了得到它来运行。一旦你有要走你会想要将群集 IP 地址更改为当前未在网络上使用的地址。

通过简单地创建群集通过 Powershell 和指定的群集 IP 地址作为 PowerShell 命令以创建群集的一部分，可以避免这一团糟。

您可以创建群集使用新群集命令，如下所示：

新群集-名称 cluster1-节点 sql1，sql2-StaticAddress 10.0.0.101-NoStorage

群集创建完成后，你还想要运行群集验证通过运行以下命令：

测试群集

7
图 7 — — 创建群集和群集验证命令的输出

创建文件共享见证

因为没有共享的存储，您将需要在同一可用性设置另一个服务器上创建文件共享见证，作为两个群集节点。通过将它放在同一可用性组你可以肯定，你只失去一票从你仲裁在任何给定的时间。如果您不确定如何创建文件共享见证您可以查看这篇文章 http://www.howtonetworking.com/server/cluster12.htm。在我的演示我把文件共享见证在域控制器上。我有发表详尽的解释，在 https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/ 群集仲裁

安装数据管理员

它创建群集后是时间要安装 DataKeeper。它是重要安装 DataKeeper 后以便与群集可以注册的自定义群集资源类型创建初始群集。如果在创建群集之前，你安装 DataKeeper 你只需要再次运行安装程序并修复安装。

8
图 8 — — 安装 DataKeeper 后创建群集

在安装过程中，你可以带走所有默认选项。 您使用的服务帐户必须是域帐户，而且必须在群集中每个节点上的本地管理员组。

9
图 9 — — 服务帐户必须是在每个节点上的本地管理员组中的域帐户

一旦 DataKeeper 是安装和许可您将需要重启服务器，每个节点上。

创建数据管理员卷资源

要创建 DataKeeper 卷资源，您需要启动 DataKeeper UI 并连接到两个服务器。
10连接到 SQL1
11

连接到 SQL2
12

一旦你连接到每个服务器，你是准备好创建您的 DataKeeper 卷。在工作岗位上右击并选择"创建作业"
13

给这份工作的名称和说明。
14

选择你的源服务器，IP 和卷。IP 地址是是否复制交通出行。
15-文件服务器故障转移群集

选择您的目标服务器。
16

选择您的选项。我们的目的而言，两个虚拟机在同一地理区域在哪里，我们会选择同步复制。对于更长的距离复制要使用异步和启用一些压缩。
17

通过单击在上一个弹出窗口将在故障转移群集中可用的存储中注册新的 DataKeeper 卷资源。
18

您将看到新的 DataKeeper 卷资源的可用存储空间。
19

创建文件服务器群集资源

若要创建文件服务器群集资源, 我们将再次使用 powershell, 而不是故障转移群集界面。这是当虚拟机配置为使用 dhcp 时, 基于 gui 的向导不会提示我们输入群集 ip 地址。 相反, 它将发出一个重复的 ip 地址。为了避免这种情况, 我们将使用一个简单的 powershell 命令来创建 file 服务器群集资源并指定 ip 地址

添加 ClusterFileServerRole-存储"DataKeeper 卷 E"-名称 FS2-StaticAddress 10.0.0.201

请记下您在此处指定的 IP 地址。它必须是唯一的 IP 地址，您的网络上。当我们创建我们内部负载平衡器时，我们将稍后使用此相同的 IP 地址。

创建内部负载均衡器

这里是故障转移群集在 Azure 是不同于传统的基础设施。蔚蓝网络堆栈不支持 ARP，因此客户端不能直接连接到群集 IP 地址。相反，客户端连接到内部负载平衡器和被重定向到活动群集节点。我们需要做的是创建内部负载平衡器。这都可以通过 Azure 门户，如下所示。

首先，创建新的负载平衡器
30

如果您的客户端通过公共互联网连接, 则可以使用公共负载均衡器。但是, 假设您的客户端驻留在同一个 vnet 中, 我们将创建一个内部负载均衡器。重要的是要注意到这里是虚拟网络是的网络群集节点驻留相同。此外，您指定的专用 IP 地址将完全用于创建 SQL 群集资源的地址相同。
31

创建内部负载平衡器 (ILB) 后，您将需要对其进行编辑。我们会做的第一件事是添加一个后端池。通过这一过程，你会选择你的 SQL 群集虚拟机所在的可用性设置。然而，当你选择实际的 Vm 将添加到后端池，要确定你不选择你文件共享见证。我们不想 SQL 流量重定向到您的文件共享见证。
32
33

我们将做的下一件事是添加一个探测器。我们将添加该探测器将探测端口 59999。此探测器确定哪个节点是活跃的在我们的群集。
34

然后最后，我们需要一个负载平衡规则，重定向 SMB 流量，重要的是要注意，在下面的截图是直接服务器返回启用了 TCP 端口 445。请确保进行了此更改。

445_ilb

修复文件服务器 ip 资源

在配置中的最后一步是在一个群集节点上运行下面的 PowerShell 脚本。这将允许群集 IP 地址响应 ILB 探头，并确保群集 IP 地址和 ILB 之间没有 IP 地址冲突。请注意;您将需要编辑此脚本，以适应您的环境。子网掩码设置为 255.255.255.255，这不是一个错误，将其保持原样。这将创建主机的特定路由，以避免与 ILB IP 地址冲突。

# 定义变量
$ClusterNetworkName ="" 
# 群集网络名称 
(在 Windows 服务器上使用 ClusterNetwork 2012, 以查找名称)
$IPResourceName ="" 
# IP 地址资源名称 
$ILBIP ="" 
# (ILB) 内部负载平衡器的 IP 地址
导入模块 FailoverClusters
# 如果你使用的 Windows Server 2012 或更高版本：
ClusterResource $IPResourceName |设置-ClusterParameter 
-多个 @ {地址 = $ILBIP;ProbePort=59999;SubnetMask = "255.255.255.255";
网络 = $ClusterNetworkName;EnableDhcp=0}
# 如果你使用的 Windows Server 2008 R2 使用该操作： 
#cluster res $IPResourceName/priv enabledhcp=0 地址 = $ILBIP probeport=59999  
subnetmask = 255.255.255.255

创建文件共享

你会发现在故障转移群集管理器中使用文件共享向导不能。相反，您将简单地创建文件共享在 Windows 资源管理器在主动节点上。故障转移群集自动拾取这些股票并放在群集中。

请注意，在此配置中不支持的文件共享的"连续可用性"选项。

结论

你现在应该有正常运作的文件服务器故障转移群集。如果您有任何问题, 请在微博上联系我 @daveberm。 需要一个数据管理员评估密钥填写的表格在 http://us.sios.com/clustersyourway/cta/14-day-trial 和 sios 将发送一个评估密钥发送给您。

经群集表单的许可复制