功能 | 详细信息 |
简单的 BCDR 解决方案 | 能够在 Azure 门户中使用 Site Recovery,以便设置和管理从单个位置进行的复制、故障转移和故障回复。 |
Azure VM 复制 | 能够设置 Azure VM 从主要区域到次要区域的灾难恢复。 |
本地 VM 复制 | 能够将本地 VM 和物理服务器复制到 Azure 或辅助性的本地数据中心。 将数据复制到 Azure 之后,就不需进行复杂的辅助数据中心维护,从而消除相关成本。 |
工做负荷复制 | 复制在支持的 Azure VM、本地 Hyper-V 和 VMware VM 以及 Windows/Linux 物理服务器上运行的任何工做负荷。 |
数据复原能力 | Site Recovery 会协调复制,而不会拦截应用程序数据。 复制到 Azure 时,数据存储在 Azure 存储中,具备后者提供的复原能力。 发生故障转移时,会基于复制的数据建立 Azure VM。 |
RTO 和 RPO 目标 | 让恢复时间目标 (RTO) 和恢复点目标 (RPO) 始终处于组织限制范围内。 Site Recovery 为 Azure VM 和 VMware VM 提供持续复制,为 Hyper-V 提供低至 30 秒的复制频率。 能够经过与 Azure 流量管理器集成来进一步下降 RTO。 |
让应用在故障转移后保持一致 | 能够经过应用程序一致性快照使用恢复点进行复制。 这些快照可捕获磁盘数据、内存中的全部数据,以及正在处理的全部事务。 |
在不中断的状况下测试 | 可轻松地运行灾难恢复练习,不会影响正在进行的复制。 |
灵活的故障转移 | 可针对预期会出现的中断运行计划内故障转移,确保不丢失任何数据;或者针对意外灾难运行计划外故障转移,尽可能减小数据丢失(具体取决于复制频率)。 主站点恢复正常时,可轻松故障回复到主站点。 |
自定义的恢复计划 | 能够经过恢复计划对多个 VM 上运行的多层应用程序的故障转移和恢复进行自定义和排序操做。 能够在恢复计划中将计算机组合到一块儿,选择性地添加脚本和手动操做。 恢复计划可与 Azure 自动化 Runbook 集成。 |
BCDR 集成 | Site Recovery 可与其余 BCDR 技术集成。 例如,可以使用 Site Recovery 保护企业工做负荷的 SQL Server 后端,为 SQL Server AlwaysOn 提供本机支持,进而管理可用性组的故障转移。 |
Azure 自动化集成 | 丰富的 Azure 自动化库提供特定于应用程序的生产就绪型脚本,可下载它们并将其与 Site Recovery 集成。 |
网络集成 | Site Recovery 和 Azure 集成可简化应用程序网络管理,具体包括:保留 IP 地址、配置负载均衡器并集成 Azure 流量管理器,从而实现高效的网络切换。 |
其实主要就是作两件事:html
1.BCDR;后端
2.站点迁移(VM);服务器
注意:Recovery Services 保管库和待复制的Azure VM 不能位于同一个区域且资源组也不能位于同一个区域。网络
本案例中,待复制的Azure VM 位于中国东部2,Recovery Services 保管库位于中国东部,目标位置为中国北部2.app
能够在待复制虚拟机的控制台开始:负载均衡
也能够从Recovery Services 保管库“复制”功能开始,ide
依次选择,源->虚拟机->复制设置。测试
部署过程会自动建立存储帐户,自动化帐户:spa
复制过程根据虚拟机存储大小,可能须要几十分钟(参考数据127G大约45分钟),复制过程当中能够点击图示位置查看进度:3d
同步的过程实际上在目标区域建立并同步磁盘数据:
同时能够在概述中,看到复制到Azure的计算机的基础结构视图:
一般状况下,应该先执行“测试故障切换”,该操做会建立CPU/内存等资源。
测试操做执行结束,能够在资源组中查看并登陆建立的测试虚拟机是否各项功能正常,后缀带“test”:
故障转测试完成后,须要将经过故障转移生成的虚拟机删除掉:
故障转移自己不检测源虚拟机的状态,不能自动执行,须要经过portal或脚本的方式触发。
若是故障转移后的虚拟机符合要求,能够提交故障转移。 提交会删除该服务提供的全部恢复点。 如今没法没法更改恢复点。
6.故障回复到主要区域(步骤类似,再也不提供截图)
从新保护 VM 后,可根据须要故障回复到主要区域。