【IT168 评论】在之前的文章中，我们已经了解了微软Hyper-V最新版本的一系列相关内容，其中包括联网功能、扩展性增强、NUMA管理、集群补丁安装以及虚拟机监控等方面的巨大变化。现在让我们将目光转向安全性与灾难恢复方面的改善，特别是Bitlocker Drive Encryption(简称BDE)与Hyper-V Replica。

　　要确保攻击者邪恶的魔爪远离我们的VHDX/VM文件，为其存储驱动器配备加密机制可以说是安全性位居第二的理想方案——顺带一提，位列第一的方案是保障数据中心的物理安全。

　　在配备可信平台模块(简称TPM)芯片的服务器上利用BDE对保存虚拟机信息的驱动器进行加密只会带来非常低的性能损失幅度(1%到2%)，但却能为我们带来高枕无忧的安全保障——即使是被替换掉，其中的内容也将无法读取。TPM芯片管理在Windows 8与Server 2012中都得到了加强，其配置也变得更为顺畅。请注意，我们无法在虚拟机环境中使用BDE，而只能将其用在保存有虚拟机VHDX文件的驱动器上。利用集群共享分卷(简称CSV)2.0格式化的共享SAN分卷现在也能受到Bitlocker的保护。

　　Hyper-V的其它安全建议仍然与早期版本相同：使用Server Core(由于提供了GUI安装选项，我们现在可以轻松完成服务器的初始配置，然后再将其移除)或者在不需要虚拟机许可的情况下使用Hyper-V服务器，并只在主机端运行管理及备份代理;为管理设定单独的网卡，利用管理员隔离制度确保主管管理员无法访问虚拟机、反之亦然;考虑在网络中使用IPSec(搭配与网卡相兼容的合适硬件)。微软公司自家的内部测试实验室为IPSec的使用提供了授权，因此Live Migration及其它一些Hyper-V功能都被证明能与其进行良好协作。

　　在大型环境下的账户管理对于Hyper-V管理员可言确实有点麻烦，因为他们往往不得不在每台单独的主机上扮演本地管理员角色。Windows Server 2012添加了一个新的本地安全组，即Hyper-V管理员，允许组成员在不具备本地管理员全部访问权限的前提下使用所有Hyper-V功能。

▲Hyper-V Replica（简称HVR）配置非常简单

　　除了一大堆新特性之外，接下来要说的只能是最令中小企业用户兴奋的附加改进了。DR功能第一次能够以低成本姿态为我们所用，这在过去是完全无法想象的。

　　Hyper-V Replica为用户提供在不同主机之间进行异步虚拟机复制的能力，我们不需要共享任何存储资源或任何特殊硬件，而且复制关系的两端既可以是独立主机、也可以是集群整体。两端主机不需要处于同一域中，甚至不需要是域的组成部分;而作为复制对象的虚拟机可采用任何受到Hyper-V支持的操作系统。复制工作可以通过常见的ADSL链路或者其它速度较慢的连接方式进行，这取决于各虚拟机之间存在的数据差异程度与我们打算复制的虚拟机数量。

　　常见的HVR适用对象包括根据总部信息状态进行数据调整的分支公司虚拟机、IT服务供应商为其虚拟机提供额外服务的小型企业等等。

　　要使用HVR，我们需要确定复制关系两端的主机是处于同一网络/域当中还是由防火墙彼此隔离。对处于同一环境中或者受信域主机，我们可以利用Kerberos验证，即所有复制流量都不会受到加密。而在其它情况下，我们则需要利用证书进行验证并实施流量加密。大家可以将特定的VHD/VHDX文件从复制对象中排除出去，同时还能够选择是否需要其它复制点。在默认情况下，只有“最新”虚拟机副本才会被保留，不过只要选择保留其它一些特定时段的恢复点，我们就完全可以将虚拟机回滚至对应时间(例如在恶意软件感染之后)。复制流程存在五到十五分钟的延迟，具体时长取决于复制操作所耗费的时间。

▲配置额外的复制点能为我们提供更好的灵活性

　　请注意，HVR提供的是由一台主机到另一台的单一复制关系，我们无法将多台主机通过同一套虚拟机组成同步体系;但同一台主机倒是可以分别充当不同虚拟机间复制关系的起点与终点，而且不同虚拟机也可以在不同主机之间进行复制。

　　如果任意一端属于Hyper-V集群的一部分，那么该集群需要Hyper-V Replica Broker角色才能实现复制流程。如果大家正在将事务日志与应用程序搭配运行，则可以随意选择应用程序的恢复点(这是为了利用VSS保证应用在复制完成之后始终处于中止状态)，以确保该应用能在复制目的地虚拟机中成功运行。

　　只要带宽资源充足，初始副本的制作也可以在网络环境中直接进行。我们可以选择立即、在未来预定的某个时间点或者通过外部存储介质创建一套备份来将其传递至副本位置。如果大家已经在副本位置保留了一套虚拟机备份副本，那么也可以将其直接指定为初始副本。

　　HVR包含了必要的Windows防火墙，但我们需要手动将其启用。在我自己的测试过程中，HVR的设定还是非常简单的，相对繁琐一些的问题出现在为每个终端设定X.509v3验证方面，但这是因为我使用了自签名证书。如果是在搭配第三方验证机制的生产环境下(除了初始副本)，整个过程在十分钟以内就能全部搞定。

　　一旦初始副本制作完毕，我们首先要做的应该是对将要启动虚拟机的副本主机进行故障切换测试(在其名称后添加‘-Test’)，这是为了确保应用程序与服务能够按预期方式工作。

▲HVR将自动将这些IP地址注入保存在副本端中的虚拟机

　　如果在发生故障之前已经收集到足够多的警示信息，我们可以在首次关闭虚拟机后执行计划内故障切换功能，复制流程将彻底完成且不可造成任何数据丢失。而在突发情况下，我们则需要在副本服务器端执行故障转移;如果在此之前尚有部分数据未完成复制，则切换之后可能造成少量信息丢失。在修复结束之后，大家还可以选择将备用虚拟机中的新数据以反向复制方式同步到原始主机当中。

　　HVR允许我们为虚拟机配置不同的IP地址以备主要及副本主机使用;但其并未内置DNS记录变更机制，因此用户需要以手动方式进行。需要注意的是，虽然副本主机中的虚拟机由于长期处于闲置状态而不会占用CPU及网络资源，但如果虚拟机数量过大、我们仍然需要根据其VHD(X)文件的体积为其设定合适的存储空间。

　　虽然HVR中的某些局限性可能会在企业级环境中造成负面影响，但简便的设置流程与易于管理的特性使HVR仍然堪称中小企业用户的理想选择。