当前位置:文档之家› 服务器虚拟化备份和灾难恢复

服务器虚拟化备份和灾难恢复

服务器虚拟化备份和灾难恢复Adam Fazio概览:目录灾难恢复计划101灾难恢复和虚拟化物理到虚拟转换虚拟机快照备份Hyper-VWindows Server Backup使用WSB 备份VM注意事项使用WSB 恢复VMData Protection Manager脚本化备份DiskShadow总结随着服务器虚拟化技术的发展和在行业中愈发广泛地普及,许多组织逐渐意识到它还有着超常的优势:降低基础结构成本并提高IT 灵活性。

下一项前沿技术将使用虚拟化平台作为启用或加强灾难恢复(DR) 战略的方法。

为什么DR 准备始终是IT 行业所面临的最热门话题之一呢?研究表明:公司每停机一小时将平均损失$80,000 到$90,000,并且几乎没有任何公司能够在出现灾难性数据丢失后仍能长期生存。

本文将介绍使用Microsoft 虚拟化平台的DR,并深入探讨了Windows Server 2008 Hyper-V 备份和恢复选项及注意事项。

灾难恢复计划101DR 是在出现停用时恢复关键服务的过程,它应该是每个公司业务连续计划的一部分,该计划定义公司在此类灾难期间或之后将如何继续履行其职能。

这些计划是所有DR 活动的基础。

有些供应商宣称其DR 自动化技术足够好,需要历经演练的详细计划的机率很小,甚至不需要这类计划。

虽然可以说自动化能够改善恢复时间并减轻对人工干预的依赖,但我们还是要郑重指出:您不可能仅凭技术成功减轻灾难。

人员和流程的重要性与技术相比始终不相上下。

事实上,您会发现如果没有事先从DR 计划流程中了解所有限制和目标,几乎不可能选择正确的技术。

虽然本文不讨论定义整个DR 计划,但我想强调这些元素是选择正确的技术和实施方案时所必需的。

所以我们先大致看一下DR 计划中一些关键的技术推动因素。

服务定义和优先级您所尝试保护的整个服务具体由什么定义,它对公司的重要性有多高?图1显示可能包含在任何DR 计划中的公司服务示例。

图1 服务定义和优先级示例服务主要组件依赖关系业务使用情况SLA公共网站网络负载平衡器、三台Web服务器、两台数据库服务器DNS、网络、防火墙、目录、存储区域网络(SAN) 存储产品购买和订单跟踪;电子商务;客户支持门户;公司信息99.99%财务系统两台数据库服务器、一台应用程序服务器DNS、网络按照法律和法规的要求记录公司收入99.99%电子邮件系统三台电子邮件服务器、一台Web 服务器DNS、网络、防火墙、目录公司通信;客户支持99.5%定义好服务后,您可以开始确定系统和依赖关系,以及所需的DR 策略类型。

很可能在查看整个服务和依赖关系集合之后,您发现需要考虑建立几个不同级别的DR,原因是为所有关键任务服务制定单个DR 解决方案可能会非常昂贵且复杂。

服务级别协议(SLA) SLA 是服务提供商(IT) 与客户(组织)之间的协议,用于为给定服务定义可用性目标。

该协议可能非常冗长,也可能非常简短有效;例如,“在正常业务时间期间,电子邮件系统的可用性达到99.95%,非正常业务时间可用性达到98%,不含计划维护时间段,以月为单位计量”。

通常,SLA 可分解为多个层次,IT 服务可以分配到这些层次中,在预定义的时间段进行测量。

操作级别协议(OLA) OLA 主要说明不同IT 组(合作支持SLA )之间的协议,包括服务交付的流程和响应时间。

假设您有一个SLA 目标为99.99% 的关键任务网站,但它赖以提供内容的数据库的可用性目标仅为95%。

OLA 有助于识别这些不匹配的情况,并协调IT 团队以便达到相同的目标。

恢复点和恢复时间目标(RPO/RTO) RTO 定义出现连续性中断之前服务不可用的时间长度,而RPO 定义组织认为可以接受的数据损失级别。

因此,如果某服务每月测量的SLA 为99%,则它的RTO 为7 小时18 分钟。

如果与RPO(比如24 小时)组合起来,则您现在可以准确定义所需的备份技术和时间计划。

数据保留策略组织的数据保留策略精确指定保留备份的时间和存储位置。

它们通常由法律和法规要求决定。

数据分类您还应该考虑数据的特性。

如果将数据分类,那您可以很快发现并不是所有的数据都需要相同级别的DR 考量。

例如,单独数据库的可用性要求可能与有多个域控制器(每个域控制器都包含目录的副本)的Active Directory 的可用性要求不同。

同理,文件服务器的数据可能与CRM 数据的恢复过程大不相同。

灾难方案定义所有希望计划的方案非常重要,因为每种方案都将有不同的恢复过程、业务影响和相关成本。

查看所有可能的方案,然后决定为环境制定DR 计划时的目标非常有用:很明显,恢复整个站点损失与恢复单个系统损失的注意事项有天壤之别。

您还须根据SLA 定义恢复阈值。

例如,假设整个站点离线的原因是主要ISP 网络断开。

如果受影响服务的SLA 对于服务恢复是8 小时,对于数据恢复是48 小时,那您可能更希望对备份站点执行服务故障转移程序,而不是实际完成数据恢复过程,因为预计生产站点会很快再次出现问题。

看!到现在为止我们还没有谈到技术呢!计划的重要性不可低估。

没有成文计划的DR 实现只能是“DR 愿望”。

灾难恢复和虚拟化好的,现在我们已经掌握了DR 计划的基础,那么,虚拟化在其中有何作用呢?许多公司报告的虚拟服务器恢复时间都以分钟为单位,而物理服务器的恢复时间则以天或周为单位。

因为整个服务器的操作系统现在只是一组文件,它已从底层物理硬件中抽象出来,所以为考虑可恢复性开辟了新的空间。

当今流行的理论是可以通过高可用性(HA) 解决方案实现部分或所有DR 目标。

言下之意是:如果在彼此分离的物理位置配备群集节点并使用站点间数据同步的话,那么在发生故障时,被动节点可以恢复运作且能够在近乎实时的情况下恢复。

确实如此,但如果回忆前面定义过的灾难方案,很明显这种解决方案并不能保治百病。

您还需要技术组合以便为所有方案作好准备,这通常包括一些常规类型的备份。

HA 并不能防止所有可能的停机,而且它并不能完全替代某些备份策略。

使用Hyper-V 和HA 需要您仔细规划存储层,因为这是实现可恢复性的关键因素。

例如,即使使用共享存储的2 节点Hyper-V 群集位于不同的数据中心,但仍有存储子系统和数据这一单独的故障点。

然而,您应该知道不使用共享存储的相同2 节点Hyper-V 群集能够承受其中一个节点上的存储或数据损失。

这确实需要复制技术确保存储同步,使得复杂性加大(请参阅图2)。

图2多站点Hyper-V 群集(单击图像可查看大图)在数据复制和同步领域有一些非常有趣的发展,但Microsoft 目前尚不能提供这些技术。

在Windows Server 2008 多站点群集页面(/windowsserver2008/en/us/clustering-multisite.aspx)上,其中介绍的合作伙伴值得一看。

另一项资源是Windows Server 目录(请参阅),它列出了获得Windows Server 2008 认证复制技术的存储供应商。

如您所见,可供考虑的HA 和存储配置为数众多。

这再次说明为什么需要先定义业务需求,然后使其能够推动技术需求,而不是采用相反方式。

物理到虚拟转换虚拟化显然可以提供某些独特的恢复灵活性,但对于并不非常适合虚拟化的物理系统又将如何呢?System Center 虚拟机管理器(SCVMM) 中包含对正在运行的Windows 服务器执行物理到虚拟(P2V) 转换的功能,它可以产生与物理源服务器完全一致的可引导Hyper-V 虚拟机(VM)。

这样您便可以在校园或整个国家内像复制虚拟副本一样复制VM,同时还可获得相似的恢复时间。

这种方法与在恢复位置进行裸机恢复这一传统方式不同,它不再需要配置与生产位置数量或类型相同的物理系统。

这样您可以充分利用恢复硬件,并根据灾难的影响按需进行扩展。

尽管SCVMM 不包括用于P2V 转换的调度程序,但由于GUI 完全在Windows PowerShell 之上运行,所以可以使用New-P2V cmdlet 轻松地进行脚本化。

实际上,SCVMM 中的所有向导都会显示它们用于执行任务的代码,您可以从环境的测试P2V 中复制这些代码并进行修改,供今后自动执行之用。

图3显示了一些示例代码;您可以在您的环境中运行SCVMM P2V 向导获得可自定义的独特Windows PowerShell 脚本。

图3 由SCVMM P2V 向导生成的代码复制代码$Credential = get-credentialNew-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"-Credential $Credential -RunAsynchronously$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously-JobGroupe823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static-VirtualNetwork "External"-MachineConfig $MachineConfig$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously-JobGroupe823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig$Credential = get-credential$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroupe823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM-UseHardwareAssistedVirtualization $false -StopAction SaveVM虚拟机快照尽管从技术上讲并不是备份,但VM 快照提供了可以使用差异磁盘还原的时间点和VM 配置文件的副本。

相关主题