1、为什么要引入故障转移群集？

和终端用户相比，企业用户对于业务的连续性和可靠性更为在意。相对而言，企业一般不会将追逐单一硬件的性能排在第一位。

如何衡量业务是否持续可用，一般使用"x 个 9"这种方式来定义。如我们常说的"3 个 9"，即表示年可用性为 99.9%，也即意味着一年只能有 8.76 个小时的系统停机时间。对于单台物理服务器而言，这意味着该设备一年内不能出现硬件损坏的情况，否则更换配件和重新上架的时间过长，很容易导致可用性等级超出这个标准。像"5 个 9"，甚至"6 个 9"这种高可用性是如何实现的呢？可想而知，通过单台物理服务器来实现这种目标将是非常苛刻且成本高昂的。

常见的可用性与相应的可允许停机时间如表 1-1 所示。

表1-1 可用性与停机时间简表

为了满足企业对业务持续可用的追求，降低年故障停机时间，系统、网络、存储各大厂商都引入了"群集"的概念。"群集"的作用是通过多台硬件同时运行来实现的，当故障发生时，通过快速且自动化的切换故障服务器，从而实现业务的持续运行。和传统的硬件故障或网络故障发生后，需要人为参与排障不同的是，群集技术是不需要人为参与的，可以做到全自动运行。当故障发生时第一时间转移故障节点，从而极大限度的提升业务持续可用的能力。

Windows Server 2012 R2 作为新一代的 Cloud OS，其 Hyper-V 角色自然也拥有"群集" 的能力。Windows 下的群集技术被称之为"故障转移群集"，Hyper-V 角色的故障转移群集目的很明确：当群集内某一台 Hyper-V 主机出现故障无法提供服务时，可由群集内的其他主机快速接管任务，继续为用户提供持续可用的服务。

2、故障转移群集的功能

故障转移群集（Failover Cluster）是 Windows Server 下的群集技术的全称。它指的是一组协同工作的独立服务器，通过物理链路和软件进行连接，以相应的技术手段来实现更好的服务可用性：当群集内某一台物理服务器出现故障时，另一台服务器开始接管故障服务器的服务（此转移的过程被称为故障转移过程）。群集角色会主动监测群集内的主机工作是否正常，通过故障转移，最终用户所能感知到的停机时间将会非常短暂。尽管群集多数是由两台以上的独立服务器组成，但在逻辑上，它们被认为是一个紧密的整体。

故障转移群集在 Windows Server 下是一项覆盖面很广的技术，其不仅可以提升 Hyper-V 的服务可用性，还可以将以下几个重要角色添加到故障转移群集中：

DFS 命名空间服务器：命名空间是一个组织中文件共享的虚拟视图。当用户查看命名空间时，共享看似驻留于单个硬盘中。用户无需了解承载数据的服务器名称或文件共享，即可导航命名空间。

DHCP 服务器：DHCP 服务器自动提供客户端计算机和其他基于 TCP/IP 并具有有效 IP 地址的网络设备。

虚拟机：虚拟机是在物理计算机上运行的虚拟化的计算机系统。多个虚拟机可运行在同一台计算机上。关于虚拟机的故障转移群集也是本书的重点之一。

Hyper-V 副本代理：故障转移群集可以使用 Hyper-V 副本代理加入具有 Hyper-V 副本的虚拟机复制。每个故障转移群集上只能配置一个 Hyper-V 副本代理。通过Hyper-V 副本代理，使得 Hyper-V 副本可以在故障转移群集中使用。

文件服务器：文件服务器的群集可以为用户提供基于文件共享的高可用实例。

通用服务、脚本、应用程序：可以将本不是用于在故障转移群集中运行的服务、脚本、应用程序配置高可用性。

Exchange 服务器：在早期的 Exchange 中，如 Exchange2007，即采用的故障转移群集技术，最新的 Exchange2010和 2013 所采用的 DAG 技术则采用了故障转移群集组件提供的有限的一部分群集功能。DAG 使用群集数据库、群集心跳（Cluster heartbeat）及文件共享见证（File Share Witness，FSW）功能

SQL Server，SQL Server 是一套数据库系统，通过故障转移群集，可为 SQL Server 带来高可用性，使用户免遭服务中断的影响。

2.1、故障转移群集的优势

故障转移群集的优点正如其名称一样，通过转移故障，为最终用户带来自动化的，中断时间相对较短的高可用性。总的来说，故障转移群集可以实现以下几个目标：

适应计划内的停机维护，通过故障转移群集，可以在设定的时间范围内对群集内的一部分服务器进行停机维护，同时可以保障业务的连贯性。使用故障转移群集，可以在白天进行一些维护工作，而无需等到夜深人静时加班去做这些操作。

减少计划外的停机时间，故障转移群集通过自有的算法机制，自动接管意外停机服务器上的服务，减少由于硬件或软件的故障造成的停机，对业务连贯性的影响，维护整套系统的高可用性。

由此可以看出，故障转移群集是一种为提供更高可用性而存在的技术。在 Windows Server 2012 R2 中，故障转移群集支持最多 64 个节点，而在 Windows Server 2008 R2 中，仅仅支持 16 个节点。在数据中心越来越庞大的今天，16 个节点的限制显然是捉襟见肘的，要满足用户的需求，升级系统势在必行。同时，在 Windows Server 2012 R2 中，每个群集中的最大虚拟机数量也从 Windows Server 2008 R2 中的 1000 个提升到了 8000 个。

2.2、故障转移群集的劣势

故障转移群集可以为企业带来更高的可用性，相应的，为了搭建故障转移群集需要付出一部分代价方可实现。

相对较低的资源利用率，由于希望当故障发生时，可以有备用的服务器随时转移故障，接管服务，因此群集内的所有服务器不可能会满负荷运行，至少要预留一部分资源，以完成可能会发生的故障转移的操作。

增加响应时间，由于最终用户不是直接和目标服务器通信，而是由一套群集机制来负载和分流，因此对于维护故障转移群集本身，这需要消耗一部分系统资源去实现，相应的，会增加一些系统响应时间。

额外的成本，由于使用故障转移群集需要投入冗余的硬件成本和共享存储，因此在设备投资上会超越非高可用架构的设计规划。

相对较高的技术要求，由于使用了冗余的架构设计，因此需要 IT 管理人员的知识面要更加广泛。

3 搭建共享存储服务器

如果希望使用故障转移群集，则必须要为故障转移群集准备共享存储，共享存储可以使用直连存储、iSCSI 存储、光纤存储中的一种。关于三种存储的优缺点，以及所采用的硬盘所带来的性能差异可参考本书前面的章节。如果企业预算紧张或在测试环境中希望对群集的功能进行验证，则可以使用 Windows Server 2012 R2 自带的角色功能来搭建"iSCSI 目标服务器"。

3.1iSCSI 目标服务器的优势

作为 Windows Server 2012 起自带的一项系统功能，"iSCSI 目标服务器"最大的优势是搭建简单，应用方便。在 Windows Server 2008 R2 时代，如果希望搭建虚拟化的共享存储，一般会采用"Openfiles"的类 Linux 操作系统来实现，Openfiles 配置共享存储的操作步骤较多，设置选项也较为复杂，相比我们熟知的 Windows Server 系统，其部署难度和管理难度都超出预期。Windows Server 2012 R2 提供了简便快捷的"iSCSI 目标服务器"，将部署和运维共享存储的难度进一步降低。

另一方面，Windows Server 2012 R2 中"iSCSI 目标服务器"所生成的存储格式为 vhd 或 vhdx，在 Windows Server 2012/2012 R2 操作系统中，这种文件格式极易被编辑和拷贝、增减、维护。这一点也是该功能的显著优势。

3.2iSCSI 目标服务器角色

为了使用"iSCSI 目标服务器"来模拟 iSCSI 共享存储，首先需要为目标服务器添加"iSCSI 目标服务器"角色。如果希望保证"iSCSI 目标服务器"的性能，建议最好在物理服务器上安装此角色。如果为了验证功能，不考虑性能，则可以在虚拟化环境中搭建。在继续进行下面的操作之前，需要简单理解三个概念：

• iSCSI 目标服务器：为其他计算机提供 iSCSI 存储的服务器，角色性质类似于FTP/HTTP，以对外提供服务为主要特征。
• iSCSI 发起程序：连接 iSCSI 目标服务器的客户端信息，可以为 IP 地址、MAC 地址、DNS 名称等。
• iSCSI 目标：iSCSI 目标是 iSCSI 发起程序的集合，一个 iSCSI 目标可以包含多个并且不同种类的发起程序。iSCSI 目标对应的主机可以是 iSCSI 目标服务器，也可以是 iSCSI 发起程序所在的主机。

第 1 步，登录 hv4.contoso.com 这台计算机，本地登录或远程桌面登录均可。依次点击打开"服务器管理器"→"仪表盘"→"添加角色和功能"。如图 3-1 所示。

图3-1

第 2 步，弹出"添加角色和功能向导"，在"开始之前"对话框中，点击"下一步"以继续安装。如图 3-2 所示。

图3-2

第 3 步，在"iSCSI 虚拟磁盘大小"对话框中，为了获得更好的存储性能，选择"固定大小"选项，关于固定大小、动态扩展、差异磁盘的优缺点，可参考本书前面的章节。这里同时输入的还有虚拟磁盘的空间大小，此处输入 140G。只要输入的大小不超过物理磁盘的实际大小即可，如图 3-3 所示，点击"下一步"继续。

图3-3

第 4 步，在"服务器选择"对话框中，选择"从服务器池中选择服务器"，点选 hv4.contoso.com，点击"下一步"，如图 3-4 所示。如之前通过"添加要管理的其他服务器" 整合了多台服务器，则此处可以看到服务器列表，需要手动予以选择。

图3-4

第 5 步，在"服务器角色"对话框中，依次展开"文件和存储服务"→"文件和 iSCSI 服务"，点选"iSCSI 目标服务器"，如图 3-5 所示，点击"下一步"继续。

图3-5

第 6 步，在"功能"对话框中，无需勾选任何选项，直接点击"下一步"，如图 3-6 所示。

图3-6

第 7 步，在"确认"对话框中，勾选"如果需要，自动重新启动目标服务器"，点击"安装"，稍等片刻即会安装成功。如此时系统存在挂起的任务，则服务器可能会重新启动，如图 3-7 所示。

图3-7

3.3创建iSCSI虚拟磁盘

完成"iSCSI 目标服务器"的角色安装后，即开始创建 iSCSI 虚拟磁盘的操作。

第 1 步，打开"服务器管理器"，于列表左侧依次点击"文件和存储服务"→"iSCSI"，在 iSCSI 虚拟磁盘对话框中，点击蓝色斜体字部分（若要创建 iSCSI 虚拟磁盘，请启动"新建 iSCSI 虚拟磁盘向导"），如图 3-8 所示。

图3-8

第 2 步，在"新建 iSCSI 虚拟磁盘向导"中，于"iSCSI 虚拟磁盘位置" 对话框点击存储位置的"按卷选择"，选中此例中的 F 盘，可以看到该磁盘下还有 172G 空间，默认 iSCSI 虚拟磁盘保存在选定卷的\iSCSIVirtualDisk 目录中，如图 3-9 所示，点击"下一步"继续，配置 iSCSI 虚拟磁盘的名称，便于识别即可。

图3-9

    第 3 步，在"iSCSI 虚拟磁盘大小"对话框中，为了获得更好的存储性能，选择"固定大小"选项，关于固定大小、动态扩展、差异磁盘的优缺点，可参考本书前面的章节。这里同时输入的还有虚拟磁盘的空间大小，此处输入 140G。只要输入的大小不超过物理磁盘的实际大小即可，如图 3-10 所示，点击"下一步"继续。

图3-10

第 4 步，在"iSCSI 虚目标"对话框中，点击"新建 iSCSI 目标"按钮，并点击"下一步"，如图 3-11 所示。

图3-11

第 5 步，在"添加发起程序 ID"对话框中，此处有三种选项可选：分别是"查询发起程序计算机 ID"、"从目标服务器上的发起程序缓存中选取"、"输入选定类型的值"，如图 3-12 所示。

图3-12

第 6 步，选择"查询发起程序计算机 ID"，并点击右侧的浏览按钮，会弹出选择计算机对话框，输入允许使用 iSCSI 目标服务器的域内计算机名称即可，如图 8-13 所示。

图3-13

第 7 步，点击确定后，可以检查发起程序类型，此时会发现，通过这种方式创建的 iSCSI 发起程序类型为"IQN"，如图 3-14 所示。

图3-14

第 8 步，除了 IQN 的类别外，还可以使用 DNS、IP 地址、MAC 地址这三种方式来识别发起程序。在"添加发起程序 ID"对话框中，可以选择"输入选定类型的值"的方式，于下拉菜单中选择手动输入此类型值。如图 3-15 所示。

图3-15

第 9 步，如果并非是第一次创建 iSCSI 虚拟磁盘，则在"从目标服务器上的发起程序缓存中选择"下，会列出已经被使用的发起程序。其作用类似于"收藏夹"，保存了之前添加过的目标服务器信息。如图 3-16 所示，配置完发起程序后，可以点击"下一步"继续。

图3-16

第 10 步，接下来配置"目标名称和访问"，此处填写准确详细的名称和描述可为管理带来便利，如图 3-17 所示，点击"下一步"继续。

图3-17

第 11 步，在"访问服务器"对话框中，可以看到于第 9 步所添加的 iSCSI 目标名称，目标的类型与连接效果无任何关联，只要是系统支持的连接类型，均可提供完全一致的访问能力，如图 3-18 所示，点击"下一步"继续。

图3-18

第 12 步，在"启用验证服务"对话框中，可以配置 CHAP 协议，以对发起程序连接进行身份验证。如果对系统的安全性有要求，可以配置此验证服务，一般情况下无需配置，如图 8-19 所示，点击"下一步"继续。

图3-19

第 13 步，在"确认"对话框中，可以检查之前配置的所有环节，如果在此处发现有配置错误的地方，则可点击"上一步"，依次返回修改，如图 3-20 所示。

图3-20

第 14 步，在"结果"对话框中，可以看到系统开始逐步进行创建 iSCSI 虚拟磁盘的过程。由于此前选择了虚拟磁盘的格式为固定大小，会发现创建过程很慢。此时打开"资源监视器"（依次按下 Ctrl+Alt+Esc 打开"任务管理器"→切换至"详细信息"→"性能"选项卡→ "打开资源管理器"），会发现磁盘资源消耗严重的文件正是我们创建的 iSCSI 虚拟磁盘文件，其持续进行写入操作，所操作的时间与实际文件大小相匹配（每秒写入 100MB 数据，140GB 的 iSCSI 虚拟磁盘文件写入需时 24 分钟（1430 秒））。由于固定大小的 iSCSI 虚拟磁盘本身的特性，因此此时耗时过长是正常现象，如图 3-21 所示。

图3-21

第 15 步，创建如果未完成，亦可关闭操作窗口，进行其他操作。返回"文件和存储服务"→"iSCSI"可以观察到 iSCSI 虚拟磁盘的创建进度，如图 3-22 所示。需要注意的是，仅在使用固定大小时会使用较长的时间进行创建。如使用动态扩展，则创建过程会瞬间完成。

图3-22