如何创建免费的Hyper-V Server故障转移集群

尽管可能使Windows Server授权模型更加复杂,但用户还是可以使用免费Hyper-V Server来创建容错环境以及故障转移集群。

微软在很久之间就已经推出免费版Hyper-V Server,但是出于某些原因,Hyper-V Server一直被大家认为只适合应用在实验室环境当中。也许你还不相信,但是现在真的能够免费部署Hyper-V Server,并且为Hyper-V虚拟机提供高可用性。

为了搭建具有容错特性的Hyper-V环境,管理员需要完成一些前期准备工作。首先,需要准备一个存储阵列作为共享存储,当然其他任何Hyper-V部署都存在这种存储需求;然后,需要准备Hyper-V Server软件,可以在微软官网下载。接着,你需要掌握如何部署和配置故障转移集群等基本知识,提前掌握故障转移集群原理可以简化Hyper-V Server集群的创建流程。最后,为了创建具有容错机制的Hyper-V环境,管理员必须对PowerShell有基本的了解。如果你对于PowerShell的理解还有些生疏,那么我推荐使用Sconfig.cmd工具。这种工具允许用户使用基于菜单的界面来配置服务器。使用这种工具,你可以最大程度上减少必须使用的PowerShell命令数量。

集中配置

使用免费Hyper-V Server创建故障转移集群的第一步就是在每台集群节点服务器上安装Hyper-V Server。安装完成之后,你需要使用Sconfig.cmd对每台服务器进行初始化配置。其中包括为每块网卡分配IP地址、为每个节点分配唯一并且有意义的计算机名、加入到某个活动目录域、启用远程管理功能等,使用Sconfig.cmd工具可以轻松完成所有这些任务。

完成初始配置流程之后,还必须针对故障转移集群进行进一步配置,比如为集群分配名称和IP地址。还需要弄明白如何将集群结点连接到共享存储。最简单的方式是创建两个SMB文件共享。其中一个用于共享存储,而另外一个用于File Share Witness。

创建集群命令

为了进行演示,我们假设用户想要创建一个名称为“Cluster1”的集群,集群IP地址为192.168.0.1。并且假设每个节点当中用于集群通信的的网卡名称为“Ethernet2”——你可以通过使用Get-NetAdapter cmdlet命令获得实际的NIC名称。现在假设你的集群节点被命名为“Hyper-V-1”、“Hyper-V-2”和“Hyper-V-3”。最后还需要为File Share Witness创建一个UNC(Universal Naming Convention)路径。之后为Hyper-V虚拟交换机分配名称。为了便于举例,在这里我们使用“Switch1”作为虚拟交换机名称——每个节点必须使用相同的虚拟机名称——使用\storagewitness作为File Share Witness路径。考虑到这些命名规则,可以使用如下命令来创建故障转移集群:

Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools

New-VMSwitch "Switch1" –NetAdapterName "Ethernet 2" –AllowManagementOS:$True

Test-Cluster –Node Hyper-V-1,Hyper-V-2,Hyper-V-3

New-Cluster –Name Cluster1 –Node Hyper-V-1,Hyper-V-2,Hyper-V-3 –StaticAddress 192.168.0.1

Set-ClusterQuorum –Cluster Cluster1 –NodeAndFileShareMajority \StorageWitness

到现在为止就只剩下最后一项任务了——将共享存储连接到集群。具体使用哪种方式可能会根据所使用的存储类型而发生变化。可以使用Add-ClusterDisk命令来完成相关操作,但是我建议在另外一台Windows服务器上安装Failover Cluster Manager,它提供的图形界面可以帮助用户在集群当中轻松添加存储。使用这种方式管理员可以不用再担心使用命令行配置共享存储的复杂性。

如你所见,通过使用免费Hyper-V Server可以实现高可用性。既然如此,你可能会问为什么企业需要为Hyper-V节点购买Windows Server授权。问题的答案通常和虚拟机授权相关。Windows Server 2012 R2 Datacenter Edition对于获得拥有恰当授权的hyper-V主机来说可以运行无限数量的Windows Server 2012 R2虚拟机,但是如果没有购买这种授权,那么就需要单独处理授权问题,这样可能导致成本大幅上升并且十分复杂。

本文转自d1net(转载)

时间: 2024-11-02 13:37:49

如何创建免费的Hyper-V Server故障转移集群的相关文章

Windows Server 2012 Hyper-V故障转移集群虚拟机亲和性策略详解

今天收到一个邮件咨询如何在Windows Server 2012实现虚拟机亲和性策略, 熟悉VMware vSphere解决方案的技术宅肯定会比较熟悉一个叫做DRS的动态迁移策略, 其中可以配置VM亲和性策略控制两个虚拟机应用运行在不同的物理ESXi主机上.这个功能还是很实用的,例如如果虚拟机应用运行了一个Guest集群,那么其中一个基本需求就是让来宾虚拟机运行在不同的物理主机上,如果DRS控制策略处于性能考虑让两个来宾虚拟机运行在同一台物理主机上则集群的高可用性就失去了:另一个常见的案例是在站

Windows服务器故障转移集群的仲裁

Windows服务器故障转移集群(Windows Server Failover Cluster,简称WSFC)使用仲裁投票(Quorum Voting)决定集群的健康状况,或使故障自动转移,或使集群离线.当集群中的结点发生故障时,会由其他结点接手继续提供服务,不过,当结点之间通信出现问题,或大多数结点发生故障时,集群就会停止服务,可是集群可以容忍多少个结点发生故障呢?这要由仲裁配置(Quorum Configuration)决定,仲裁配置使用多数(Majority)原则,只要集群中健康运行的结

故障转移集群报错-故障转移集群配置问题

问题描述 故障转移集群配置问题

Windows 2008故障转移集群之准备篇

故障转移群集必须满足硬件.软件和网络基础结构的某些要求,并且它需要一个具有适当域权限的管理帐户.具体如下: (一)故障转移群集的硬件要求 在一个故障转移群集中,需要配备有以下硬件: (1)服务器:建议使用一组包含相同或相似组件的匹配计算机. 注意,仅当所有硬件组件均标记为"Certified for Windows Server 2008"时,Microsoft 才支持故障转移群集解决方案.此外,完整配置(服务器.网络和存储)必须通过"验证配置"向导中的所有测试,该

Redis 自动故障转移 集群 解决方案

问题描述 实在无奈,研究不出可行的方案,所以来求助大家.问题:两台服务器,部署redis,一主一从,(主为a1,从为a2)客户端访问redis服务器,如果a1服务器意外关闭,则客户端直接访问a2服务器上的redis,这个需要怎么配置?或者需要什么解决方案.(windows服务器上的) 解决方案 解决方案二:不就是a1连不上,连a2的节奏吗?解决方案三:客户端要连哪个服务器,应该由你的程序来控制,而不是依靠什么"配置"吧?解决方案四:引用2楼rocmemory的回复: 客户端要连哪个服务

SQL Server 2012故障转移的looksalive check和is alive check

什么是looksalive check和is alive check       SQL Server故障转移集群是建立在windows集群服务上的一种热备的高可用方案.在集群运行过程中,windows集群服务定期检测节点的资源健康状态,如果发生了故障,会根据预先定义的故障转移策略把SQL Server服务从故障节点切换到可用节点上,从而实现SQL Server的高可用.       而looksalive和isalive就是windows集群服务定期检测节点的资源健康状况的两个方法,它们存在于

SQL Server误区:在服务器故障转移后,正在运行的事务继续执行

误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行_MsSql

误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

AlwaysOn可用性组功能测试(2)-SQL Server群集故障转移

三. SQL Server群集故障转移对AlwaysOn可用性组的影响 1. 主副本在SQL Server群集CLUSTEST03/CLUSTEST03上 1.1将节点转移Server02.以下是故障转移界面. 1.2 服务脱机,alwaysOn自然脱机,但侦听IP并没有脱机. 1.3 SQL服务联机后,侦听IP[10.0.0.224]会脱机重启,alwaysOn资源组联机 1.4 转移后恢复正常,连接正常,语句执行正常. 2. 主副本在SERVER03的服务上 2.1 当前主副本在SERVER