将Azure群集转换为托管磁盘

为什么要将Azure群集转换为托管磁盘

你可能听说过最近的存储中断在3月16日影响了美国东部地区的一些情况。此处发布了中断的根本原因分析。 3月16日美国东部停电中断

客户影响力

在美国东部地区使用存储的客户子集在单个存储规模单元中访问其存储帐户时可能会遇到错误和超时。您可能会问，“什么是单个存储比例单位”。好吧，您可以将其视为单个存储群集或单个SAN，或者您想要考虑它。我不认为Azure发布他们的确切基础设施。虽然您可以假设在幕后他们使用横向扩展文件服务器进行后端存储。

以最短的停机时间生存停电

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

在此事件期间，使用可用性集中的托管磁盘的虚拟机将保持可用性。因此，是时候将Azure群集转换为托管磁盘

什么是托管磁盘？

2月8日，Corey Sanders宣布了管理磁盘的GA。托管磁盘可以帮助解决这种中断问题。因为通过利用可用性集与托管磁盘相结合，可用性集中的每个实例都连接到不同的“存储规模单元”。因此，在这种特殊情况下，只有一个集群节点发生故障，剩下的节点将接管工作负载。在托管磁盘可用之前（2016年2月8日之前部署的任何磁盘）之前，无法确保连接到服务器的存储位于不同的存储规模单元上。当然，您可以为每个实例使用不同的存储帐户。但实际上，并不能保证那些存储帐户在不同的存储规模单元上配置存储。将Azure群集转换为托管磁盘的更多理由。因此，虽然可用性集确保您的实例驻留在不同的故障域和更新域中以确保实例本身的可用性，但是附加到每个实例的附加存储确实代表单点故障。虽然存储本身具有高弹性，但有三个数据副本和地理冗余选项可用，在这种情况下断电时，整个存储规模单元与连接到它的所有服务器一起关闭。长话短说……尽快将Azure群集转换为托管磁盘，以帮助减少停机时间https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to管理磁盘如果您真的想最大限度地减少停机时间，您应该考虑跨云提供商或云端部署的混合云部署！经Clusteringformeremortals.com许可转载

Cloud Witness在Azure中构建多实例SQL Server故障转移群集

新的Azure ILB功能允许您在Azure中构建多实例SQL Server故障转移群集

新功能，Cloud Witness是我最喜欢的。在我们查看Windows Server 2016中的新仲裁功能之前，我认为了解它们的来源非常重要。在我之前的帖子了解Windows Server 2012 R2中的Windows Server故障转移群集仲裁中，我详细介绍了群集仲裁的历史和演变。我建议您查看该帖子，以了解仲裁在Windows Server 2012 R2中的工作原理。此外，Windows Server 2016的新功能将如何使您的群集部署更具弹性。

云见证人

Cloud Witness允许您利用Azure Blob存储作为群集的见证。这个证人将代替磁盘见证或文件共享见证。Cloud Witness的配置非常简单。根据我的经验，几乎没有任何东西可以在Azure中托管。唯一的缺点是群集节点需要能够通过Internet与Azure Blob存储进行通信。通常，群集节点被禁止与公共互联网通信。因此，如果要启用Cloud Witness，则需要与安全团队协调。使用Cloud Witness在Azure中构建多实例SQL Server故障转移群集有许多令人信服的理由。但对我来说，它在三个非常特定的环境中最有意义：Azure中的故障转移群集，分支机构群集和多站点群集。

仔细看看

让我们来看看每个场景，看看Cloud Witness如何提供帮助。图1 – 当您尝试在Azure中构建多实例SQL Server故障转移群集时，应始终配置云见证存储帐户本地冗余存储（LRS）[/字幕]

高度可用的部署

如果您要迁移到Azure（或任何云提供商），您将需要确保您的部署具有高可用性。如果您正在使用传统上与Windows Server故障转移群集集群的SQL Server，文件服务器，SAP或其他工作负载，则需要使用文件共享见证或云见证，因为Azure中无法使用磁盘见证。对于Windows Server 2012 R2或Windows Server 2008 R2，您将需要使用文件共享见证。Windows Server 2016可以使用Cloud Witness。Cloud Witness的优势在于您无需在Azure中维护另一个Windows实例来托管文件共享。相反，Microsoft允许您利用Blob存储。 这为您提供了一种更便宜的解决方案，一种更易于管理且更具弹性的解决方案。

位置

在分支机构中查看集群部署时，始终需要考虑成本和维护。对于拥有数百或数千个位置的零售连锁店而言，在每个位置都有SAN可能成本过高。每个位置可能在S2D Hyper-fusionged配置或第三方复制解决^方案上运行双节点Hyper-V群集以托管多个虚拟机。现在，Cloud Witness可以做的是帮助企业避免在每个位置添加额外的物理服务器以充当文件共享见证或向每个位置添加SAN的成本。

消除了对第三个数据中心的需求

最后，在部署多站点群集时，Cloud Witness无需第三个数据中心来托管文件共享见证。在引入Cloud Witness之前，最佳实践将要求File Share Witness位于第3个位置。访问第三个数据中心只是为了托管文件共享见证并不总是可行的，并且肯定会引入另一层复杂性。通过使用Cloud Witness，您无需维护第三个位置，并且可以通过公共互联网访问见证，从而最大限度地降低了网络要求。

网站意识

在构建多站点群集时，总会出现另一个常见问题。控制故障转移始终优先选择本地站点是不可能的。虽然您可以指定“首选所有者”，但“首选所有者”设置通常会被误解。管理员可能没有意识到这一点。但是，您知道即使他们没有将服务器列为首选所有者，服务器也会自动附加到群集维护的首选所有者列表的末尾。这种误解的结果是，虽然您可能只将本地服务器列为首选所有者，但您可能会将群集资源故障转移到DR站点。即使在本地站点中有一个非常好的节点，这也是如此。显然这不是您所期望的，使用Site Awareness将消除此问题。站点感知通过在决定将哪个节点联机时始终优先选择本地站点来解决此问题。因此，在正常情况下，除非您有完整的站点中断，否则群集工作负载将始终故障转移到本地节点。在这种情况下，其中一个DR节点将联机。一旦您在灾难恢复站点中运行，情况也是如此。如果先前在DR站点中的节点上运行，则群集将恢复DR站点中的服务器上的工作负载。站点意识总是更喜欢本地节点。

故障域

建立在站点上的意识是Fault Domains。Fault Domains更进一步，除了Site之外，还可以定义Node，Chasse和Rack位置。Fault Domains有三个好处：Stretch Cluster中的存储亲和性可以提高存储空间的弹性。它通过包含有关引发警报的相关资源的位置的元数据来增强运行状况服务警报。Storage Affinity将帮助确保您的群集工作负载和存储在同一位置运行。您当然不希望您的VM读取和写入位于不同城市的CSV上的数据。但是，我认为这里最大的赢家是Storage Spaces Direct（S2D）场景。SD2将利用您提供的有关群集节点位置（站点，机架，机箱）的信息，以确保为冗余编写的多个数据副本都存在于不同的故障域中。这有助于确保优化数据放置，以便单个节点，机箱，机架或站点的故障不会影响整个S2D部署。  Cosmos Darwin在第9频道播放了一段精彩视频，详细解释了这一概念。

概要

Windows Server 2016为群集仲裁添加了几项新增强功能，这些增强功能将为群集部署提供一些直接的好处。此外，还可以查看其他一些新的集群增强功能，如滚动系统升级，虚拟机恢复能力，工作组和多域集群等。要阅读其他提示，例如在Azure中使用Cloud Witness构建新的多实例SQL Server故障转移群集，请阅读我们的帖子。经Clusteringformeremortals.com许可转载

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支持的两种解决方案。 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群集解决方案之前应考虑的一些事项的概述，请查看下表。 如果我们浏览此图表，我们会发现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许可转载

Google云平台中的Sanless SQL Server故障转移群集实例

如何在Google Cloud Platform中构建Sanless SQL Server故障转移群集实例

如果您要在Google Cloud Platform（GCP）上托管SQL Server，您需要确保它具有高可用性。最好和最经济的方法之一是在Google Cloud Platform中构建一个Sanless SQL Server故障转移群集实例。

成本效益

由于SQL Server Standard Edition支持故障转移群集，因此我们可以避免与永远在线可用性组所需的SQL Server Enterprise Edition相关的成本。此外，SQL Server故障转移群集是一种更强大的解决方案，因为它可以保护整个SQL Server实例。它在DTC（分布式事务处理协调器）支持方面没有限制，并且更易于管理。此外，它支持您可能仍然拥有的早期版本的SQL Server，例如SQL 2012到最新的SQL 2017。遗憾的是，由于缺乏对跨子网故障转移的支持，因此不支持SQL 2008 R2。

与SIOS Datakeeper有何不同？

传统上，SQL Server FCI要求您拥有SAN或某种类型的共享存储设备。在云中，没有群集感知共享存储。代替SAN，我们将使用SIOS DataKeeper Cluster Edition（DKCE）构建SANless集群。DKCE使用块级复制来确保每个实例上的本地连接存储保持彼此同步。它还通过称为DataKeeper Volume的自己的存储类资源与Windows Server Failover Clustering集成，后者取代了物理磁盘资源。就集群而言，SIOS DataKeeper卷看起来像物理磁盘，而不是控制SCSI保留。它控制镜像方向，确保只有活动服务器写入磁盘，并且被动服务器同步或异步接收所有更改。

Google云平台中的Sanless SQL Server故障转移群集实例入门

在本指南中，我们将介绍在同一区域中的两个实例之间构建双节点故障转移群集的步骤，但是在GCP内的不同区域中，如图1所示。 要了解有关Sanless SQL Server故障转移群集实例的更多信息，请访问https://us.sios.com/sios-resources/white-paper-build-sql-server-failover-cluster-gcp/了解有关SIOS DataKeeper的更多信息经Clusteringformeremortals.com许可转载

Linux上的MS SQL Server v.Next的高可用性故障转移群集

MS SQL Server V.Next在Linux上具有复制和高可用性

微软最近发布了在Linux上运行的MS SQL Server的第一个公开预览版。 我想知道他们会为高可用性做些什么。了解AlwaysOn可用性组和故障转移群集与Windows操作系统的紧密耦合，我很确定它们不是选项。我是对的 – Linux上的MS SQL Server v.Next的高可用性故障转移群集。 好吧，LinuxClustering.Net上的人们回答了我关于如何使用这个伟大的Step by Step文章为Linux上的MS SQL Server v.Next提供高可用性故障转移群集的问题。http://www.linuxclustering.net/2016/11/18/step-by-step-sql-server-v-next-for-linux-public-preview-high-availability-azure/不仅如此，他们还做了考虑到一些网络限制，我们知道Azure中的一切都很棘手。 我很想知道您是否对在Linux上为MS SQL Server v.Next创建高可用性故障转移群集感到兴奋。或者，如果你认为这只是一个小科学实验。对于兴奋的人来说，Linux上的SQL Server会给开源数据库的表带来什么？既然你非常喜欢SQL Server，为什么不在Windows上运行呢？我在这里不是很滑稽。老实说，我想知道Linux上的SQL Server令你兴奋的是什么。我很期待你的意见。经Clusteringformeremortals.com许可转载