【留存】VMware站点恢复管理的业务决策:RTO与RPO

原文:http://www.searchvirtual.com.cn/showcontent_49914.htm

导读:如果你的公司没有常规的VMware灾难恢复规划工作以确定你所有系统的RTO以及RPO,那么你要为一个较长的过程做准备。

关键词:VMware 灾难恢复 RTO RPO

【TechTarget中国原创】针对VMware vCenter Site Recovery Manager (SRM)业务决策的复杂度,通常不只局限于技术成分。事实上,技术配置绝大部分取决于企业所作的IT之外的业务决策。

很多由业务驱动的SRM设计都采用标准的灾难恢复规划。这包括指定运行关键任务的服务器以及将备份保存的时间。但不幸的,有些VMware SRM决定涉及了企业内部的政治,难以妥协以及过于细致的规划。

  VMware SRM的恢复时间目标(RTO)

恢复时间目标(Recovery Time Objective, RTO)是一个系统在发生灾难后必须得到恢复的时间长度。这个变量决定哪些虚拟机在VMware SRM恢复计划中首先启动。SRM很容易从技术角度来配置虚拟机的重要性。但是直到企业勾画出一个合适的顺序,IT团队只能猜测哪些虚拟机需要首先得到恢复。

一旦企业决定了整个系统的RTO,IT部门必须将其转换为具体服务器的RTO。大多数企业拥有多台服务器并存在各种关联。例如,一个公司可能不为域控制器和反病毒管理系统定义RTO。但是架构中的每台服务器都以某种方式与他们关联着。因此确保这些服务器获得合适的优先级,是SRM实施团队的任务。

  恢复点目标(RPO)

另一个商业决定是恢复点目标(Recovery Point Objective, RPO)。它定义了灾难后一个系统可以接受的以时间为单位的数据损失量。传统上,RPO同时定义了服务器备份的频率。但是当应用到SRM实施中来,RPO决定了在主备站点阵列间的复制频率。

在设计虚拟机数据存储以及存储复制之前,一项很重要的业务决定是为每个应用定义RPO。虚拟化管理员们接下来能够将相近RPO的服务器归组并配置到同一套存储卷中。然后他们可以根据RPO为每个存储卷配置合适的复制计划。要注意的是,如果将VMware SRM引进到现有的vSphere架构中,这个过程可能需要对存储系统的重设计以及迁移。

  没有RTO以及RPO?

如果你的公司没有常规的灾难恢复规划工作以确定你所有系统的RTO以及RPO,那么你要为一个较长的过程做准备。由于RTO以及RPO涉及到内部的政治,技术局限,个人决定以及系统交互,定义它们是很费时间的。

保持这些RTO以及RPO的定义,与你公司的业务部门进行常规的沟通,对系统优先级的变化保持更新是同样重要的。VMware SRM以及存储管理员们必须有合适的时间来实施这些变化。

最重要的是IT和业务部门在VMware SRM设计过程中相互配合,以确保平稳和可靠的实施。

Leave a Comment

电子邮件地址不会被公开。 必填项已用*标注