SIOS SANless clusters High-availability Machine Learning monitoring
您现在可以在Azure中为您的云服务预留静态公共IP。通常，当您停止云服务中的所有虚拟机时，您的静态IP将会释放。这样，下次启动虚拟机时将会发布一个新的虚拟机。您必须始终保持每台云服务至少运行一台虚拟机，这可能使演示无需每次重做都可以正常运行。
更好的消息是，您保留的前五个静态IP地址是免费的。现在，我可以关闭所有虚拟机，并在夜间轻松入眠，因为知道我的地址不会改变，从而打破了我的SQL Server故障转移群集演示。最重要的是，我可以肯定，我不会超过200美元的MSDN Azure信用额度，这总是一件好事。
http://msdn.microsoft.com/en-us/library/azure/dn690120.aspx
经https://clusteringformeremortals.com/2014/06/19/static-ip-in-azure-now-available/许可转载
在我们开始使用Windows Server 2012 R2中所有出色的新群集仲裁类型之前，我们应该花点时间了解它的作用以及我们如何到达今天的位置。Rob Hindman在他的博客文章中描述了法定人数最佳...
“故障转移群集中的仲裁配置决定了群集在保持联机状态时仍能保持的故障数量。”
在Windows Server 2003之前，只有一种仲裁类型，即仅磁盘。现在有不同的群集仲裁类型。 磁盘仅在今天仍然可用，但不推荐使用，因为仲裁磁盘是单点故障。在Windows Server 2003中，Microsoft引入了多数节点集（MNS）法定人数。这是一个改进，因为它消除了作为群集中单个故障点的仅磁盘仲裁。但是，它确实有其局限性。正如其名称所暗示的，多数节点集必须具有大多数节点才能形成法定人数并保持在线状态。因此，这个仲裁模型对于双节点集群来说并不理想，其中一个节点的故障只会留下一个节点。两分之一不是多数，所以剩下的节点将脱机。
Microsoft推出了允许在Windows Server 2003 SP1和2003 R2群集上创建文件共享见证（FSW）的修补程序。本质上，FSW是在MNS群集中投票的另一台服务器上的简单文件共享。这一创新背后的推动力是Exchange Server 2007连续群集复制（CCR），它允许在没有共享存储的情况下进行群集。当然，如果没有共享存储，则仅限磁盘仲裁不是一种选择。 有效的MNS群集将需要三个或更多的群集节点。因此，引入FSW来支持两个节点Exchange CCR群集。
Windows Server 2008引入了一种新的见证类型Disk Witness。与旧式磁盘仲裁类型不同，Disk Witness允许用户在共享磁盘上配置一个小型分区，该分区充当群集中的投票，与FSW类似。但是，Disk Witness比FSW更可取。这是因为它保留了集群数据库的副本并消除了“及时分区”的可能性。如果您想要及时阅读有关分区的更多信息，建议您阅读文件共享见证与 本地集群的磁盘见证。
依据法定人数选项，Windows Server 2012持续改进。我相信许多这些新功能都是由两种力量驱动的：Hyper-V和SQL Server AlwaysOn可用性组。使用Hyper-V，我们开始看到集群中包含的节点比过去通常看到的多得多。在多数节点组中，只要您失去大部分选票，其余节点就会脱机。例如，如果您有一个具有七个节点的Hyper-V群集，并且您将丢失其中四个节点，则即使剩余三个节点，其余节点也将脱机。这可能不是你想要发生的。所以在Windows Server 2012中，微软推出了Dynamic Quorum。
动态法定名称的含义如此。它动态调整法定人数。因此，在所描述的场景中，假设我并未同时丢失全部四台服务器，并且群集中的服务器脱机，则法定数量将动态调整。当节点一脱机时，我理论上会有一个六节点集群。当节点2脱机时，我会有一个五节点群集，依此类推。实际上，如果我继续一个接一个地丢失集群节点，我可以一路下降到两个节点集群，并仍然保持在线状态。而且，如果我配置了一个见证者（磁盘或文件共享），我实际上可以一路走到单个节点并仍然保持联机状态。
在…处阅读有关群集仲裁类型的更多信息。
转载自https://clusteringformeremortals.com/2014/04/29/understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/
问：什么是SANLess集群？
答：它是一个使用本地存储而不是SAN的集群。
问：为什么我要配置Sanless Hyper-V故障转移群集？
答：有几个原因：
如果您知道有关Windows Server故障转移群集的任何信息，那么您已经知道99％的解决方案。如果您之前从未构建过Windows Server故障转移群集，则无需担心。微软已经轻松无痛。对于初学者，我已经写了一篇分步文章，告诉您如何在我的博客文章中构建Windows Server 2012 #SANLess集群。
如果您已按照我的文章中的步骤操作，则可以开始创建第一个高度可用的虚拟机。第一个选项假定您有一个现有的虚拟机，您想使其具有高可用性。 第二个选项假设您正在构建高度可用的虚拟机。
SANLess Hyper-V群集每卷需要一个VM。因此，您需要确保对存储进行分区，以便为每个VM分配足够的卷。每个群集节点上的存储应该按照驱动器号和分区大小进行相同的配置。正确配置分区，并且VM驻留在要复制的分区上。然后，打开DataKeeper接口并完成三步向导以创建DataKeeper Volume Resources，如下所示。
首先，打开DataKeeper界面并点击连接到服务器。这样做两次以连接到两台服务器。
连接完成后，单击“创建作业”以创建包含要高度可用的虚拟机的卷的镜像，如下所示。在这个例子中，我们将镜像E驱动器。
只要有可能，请在专用网络上保留复制流量。在这种情况下，我们将10.0.0.0/8网络用于复制流量。这可以是一个简单的修补程序电缆，通过两个未使用的NIC连接两台服务器。
最后的屏幕显示可用于镜像的选项。对于局域网，最好使用同步镜像。在广域网上进行复制时，您需要使用异步复制并可能启用压缩。我不会限制最大带宽。因为如果您的更改速率（磁盘右字节/秒）超过指定的最大带宽，可能会导致镜像不同步。但是，您可能希望在初始镜像创建过程中暂时启用最大带宽。否则，DataKeeper可能会使用初始复制流量泛滥网络，因为它会尽可能快地同步。创建镜像后，可以调整最大带宽和压缩设置。但是，一旦创建镜像而不删除镜像并重新创建镜像，就不能在同步镜像和异步镜像之间切换。
在镜像创建过程结束时，您会看到一个弹出窗口，询问您是否要将此卷自动注册为群集卷。选择是，这将在故障转移群集可用存储中创建一个DataKeeper卷资源。
您现在已准备好创建高可用性的虚拟机。
再次，此过程假定您有一个现有的虚拟机，您想使其具有高可用性。如果您没有现有的虚拟机，则需要按照选项2 – 创建高可用性虚拟机中的过程进行操作。否则，如下所示，查看Hyper-V管理器时应该有一个虚拟机。
所有虚拟机文件应该已经位于复制卷上，如下所示。如果没有，则在尝试群集VM之前，您将不得不重新定位文件。
要开始群集过程，请打开故障转移群集管理器。右键单击Configure Roles并选择虚拟机作为您想要创建的角色。
这将启动高可用性向导。此时，您应该选择要群集的虚拟机，然后逐步执行向导，如下所示。
您会看到虚拟机资源将被创建，但会有一些警告。警告表明E驱动器当前不是VM群集资源组的一部分。
要使DataKeeper Volume E成为VM Cluster Resource Group的一部分，请右键单击该角色并选择Add Storage。添加您将看到的可用磁盘中列出的DataKeeper卷。
最后一部分是选择虚拟机配置（而不是虚拟机）资源的属性，并使其依赖于刚添加到资源组的存储。
您现在应该能够启动虚拟机。
假设您想从头开始创建高可用性虚拟机，则可以从Hyper-V虚拟机管理器完成整个过程，如下所示。此步骤假定您已经使用DataKeeper创建了E驱动器的镜像，如配置DataKeeper卷资源部分中所述。
要开始，请打开故障转移群集管理器并右键单击角色并选择虚拟机 – 新建虚拟机。
按照向导的步骤进行操作，并选择要用于VM的选项。选择放置VM的位置时，请选择当前是可用存储的所有者的群集节点。它也将成为镜子的来源。
确保在指定VM的名称和位置时，选择复制卷的位置。
其余选项取决于你。只要确保VHD文件位于复制卷上。
您将看到创建了高可用性虚拟机，但存在有关存储的警告。您需要将DataKeeper卷资源添加到VM群集资源组，如下所示。
将DataKeeper卷添加到VM群集资源组后，添加DataKeeper卷作为虚拟机配置资源的依赖项。
您现在拥有高度可用的虚拟机。
在这篇博客文章中，我们讨论了构成#SANLess集群的内容。我们选择了SIOS DataKeeper来配置Sanless Hyper-V故障转移群集。一旦构建完成，群集的行为与基于SAN的群集完全相同，这包括在发生意外故障时能够进行实时迁移，快速迁移和自动故障转移。
#SANLess集群消除了SAN的开支以及SAN的单点故障。DataKeeper Cluster Edition支持SAN中的多个节点。因此，延伸局域网和广域网的配置都是Hyper-V高可用性和灾难恢复的可能解决方案。DataKeeper支持任何本地存储。这为使用高速本地连接的SSD或NAND Flash存储提供了高性能而不放弃高可用性的可能性。
如果您喜欢阅读配置Sanless Hyper-V故障转移群集的技巧，请在此处阅读有关群集的更多信息
经https://clusteringformeremortals.com/2014/03/04/configuring-a-sanless-hyper-v-failover-cluster-with-datakeeper-cluster-edition/许可报告
就在今天，我收到了预告中发布的ExpressRoute，一个新的Windows Azure网络选项。本质上，ExpressRoute现在允许您通过有限数量的网络服务提供商和交换提供商向Windows Azure Cloud租用专用连接。通过Exchange提供商或网络服务提供商可以提供从10 Mbps到10 Gbps的速度。
以前，连接您的内部部署站点的唯一方法是为您的虚拟网络配置站点到站点的VPN。虽然这是一个不错的选择，但像ExpressRoute这样的直接连接可绕过公共网络，这样可以实现更少的延迟和更可靠的连接。
如果您试图使用DataKeeper等数据复制解决方案将数据复制到Azure云中进行灾难恢复，或者尝试使用Azure将数据复制到专用网络以获得额外的数据保护，则您将欣赏可用的各种不同链接速度，这些链接速度可供您调整容量应该随着时间的推移而改变。即使您目前还没有准备好将整个生产网络迁移到云端，我相信使用Windows Azure之类的软件代替维护独立的灾难恢复设备非常有意义，特别是现在可以使用强大的直接连接选项。转载自https://clusteringformeremortals.com/2014/02/21/windows-azure-disaster-recovery-options-just-got-better-with-expressroute/的许可
确保高可用性选项对于SQL Server，始终可能是我们使用云服务的主要原因。但是，防止与云中断相关的停机时间是任何在任何云服务上部署的人都需要解决的问题。只需在“云端”部署您的应用程序并假定现在管理其他人的问题很容易。云提供商可能拥有更多资源和专业知识，以确保您的服 但确保您的关键应用程序可用的最终责任完全在于您。
信不信由你，只需在Windows Azure中部署你的SQL Server就不会使它“高度可用”。为了使其高度可用，您必须使用您可能在自己的数据中心中使用的传统工具和技术。虽然对此主题有不同意见，但我认为SQL Server 2012/2014的高可用性选项如下：
无论您选择哪个选项，您都希望熟悉Windows Azure故障域，如下所述：
“尽管如此，在Windows Azure中，一台计算机确实被确定为故障域。并且在部署时由Windows Azure确定故障域的分配。服务所有者无法控制故障域的分配，但可以通过编程方式找出服务在哪个故障域中运行。Windows Azure计算服务SLA仅在部署服务的每个角色的两个或多个实例时才保证已部署服务的连接正常运行时间级别“
在您开始部署Windows Azure VM时，请确保每个SQL Server和任何“见证”服务器驻留在不同的故障域中。通过将所有虚拟机置于相同的“可用性集”中来实现这一点。本质上，同一个可用性集中的每个服务器都驻留在不同的故障域中，希望能够消除故障。
将所有虚拟机置于不同的故障域中，并配置SQL Server故障转移群集或可用性组，以防止可能本地化为单机架服务器，即AKA故障域的常见故障类型。我已经写了一篇文章，题为在Windows Azure IaaS中使用DataKeeper创建SQL Server 2014 AlwaysOn故障转移群集（FCI）实例，这应该有助于您在Azure云中为您的SQL Server构建灵活性。
自然灾害或人为错误可能是导致此类停电的原因。不幸的是，在这一点上，无法在两个不同的Azure区域之间拉伸Azure虚拟专用网络。这包括东南亚。但是，Azure虚拟专用网络可以支持与有限数量的VPN设备进行站点到站点VPN连接。这些设备来自思科，瞻博网络甚至微软RRAS。
这让我们想到了Azure之外的其他位置，甚至是我们自己的私人数据中心。我最近编写了一篇分步说明文章，介绍如何将您的内部数据中心扩展到Azure Cloud。将数据中心连接到Windows Azure，配置AlwaysOn可用性组或AlwaysOn故障转移群集（多站点），以防止发生灾难性Azure故障。我以前写过关于多站点群集的优势与 可用性组。 因此，在我的实验室中，我决定在Azure中创建一个双节点SQL故障转移群集实例，然后在我的主数据中心添加第三个节点。我在我的博客文章中写了详细的配置步骤，名为“在Windows Azure中创建多站点群集以进行灾难恢复”。
如果您更愿意使用AlwaysOn可用性组，则可能需要访问Windows Azure中的AlwaysOn可用性组（GUI）和Windows Azure中的AlwaysOn可用性组的Listener配置教程。如果您使用的是SQL 2008 R2或更早版本，我相信您可以配置数据库镜像。此时，如果您正在转向Azure，那么我假设您可能正在部署SQL Server 2012或2014。日志传送和复制等其他技术是移动数据的选项，但我不认为它们是高可用性解决方案。
经https://clusteringformeremortals.com/2014/01/15/windows-azure-high-availability-options-for-sql-server-azure-cloud-iaas/许可转载