云数据-欲练神功必先写文档

时间:2022-04-24
本文章向大家介绍云数据-欲练神功必先写文档,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

当构建DR计划时,第一步是查看用来交付IT服务的应用,并且决定灾难发生时需要保护什么。这意味着创建需要运行的应用和服务的清单。很多企业已经转向虚拟化作为其核心服务器的部署模型;但是,仍然需要考虑物理服务器。完善的云数据恢复计划应该包括如下:

用来交付基础架构的物理和虚拟服务器。这些包括活动目录(AD)服务器,DNS/DNCP服务器和应用。

用来交付应用的物理服务器。为什么还在物理服务器上交付服务,这需要有好一点的理由;这可能包括扩展和性能要求,或者使用自定义硬件和操作系统。但是,云恢复服务可能能够帮助虚拟化其中一些组件。

用来交付应用的虚拟服务器。可能有几十台或者上百台虚拟机用来实现应用。每台都需要确认和记录、查看存储、内存和虚拟处理器需求。

最好提前确定基础架构服务器,因为当灾难发生时这些系统需要第一时间恢复服务。可以预配置在云上运行的AD、DNS和DNCP服务,并且和它们的内部实例同步,让DR流程更加容易,也能够更快实现。

要想让云上的DR能够成功工作,理解网络配置至关重要。这意味着需要花时间理解网络层的应用之间的相互依赖关系,包括安全和防火墙配置。云数据恢复相关的问题有:

是否有应用或者服务器互相之间有延迟依赖?

是否有East-West防火墙规则来管理站内流量?

面向客户的应用的外部带宽需求是什么?

确定云数据恢复需求

假定在灾难事件发生时,每个应用都需要立即恢复,这并不太实际。相反,应该基于一系列条件来区分应用的优先级,来决定需要多快,以及哪些同步系统和数据需要恢复运营。在决定恢复应用的服务等级时,可以使用一些标准来进行度量:

恢复时间目标。它衡量在应序备份并且运行之前可以容忍多长的下线时间;通常以分钟或者小时计量。比如,零RTO表示完全不能容忍掉线,而一小时的RTO意味着应用必须在DR发生的一小时内完成恢复。

恢复点目标。它衡量一旦应用再次运行时可以容忍丢失多少数据。零RPO意味着所有数据都必须恢复到灾难发生点,而24小时的RTO意味着恢复后数据或系统可以过时24小时。

服务级别目标。SLO衡量整体应用的恢复情况。比如,协议可能是在四小时内恢复90%的应用。越严格的SLO要求越多的基础架构支撑并且可能需要越多的人力才能达到,因此留有一定的灵活度有助于管理DR的费用。

SLO 允许区分数据和应用的优先级。比如,一个在线信用卡处理系统要求零RPO和非常低的RTO。期望这样的系统永远也不会丢失信息是合理的。另一种极端情 况是,负责报告的应用可能能够容忍24到48小时的数据过期时间,因为其数据是从其他应用里抽取出来的。其他系统大多数处在这两种极端情况之间。

建立正确的云数据恢复需求包括和应用程序的业务所有者沟通,因为他们了解其应用的重要程度。从经验上看,业务所有者会认为其所有应用都很重要——直到他们了解恢复所需的费用为止。因此可以告诉他们不同方案的费用评估。

服务级别的最后一点是:一些严格的需求,比如零PRO,基于云的DR是无法达成的,因为本地和云位置之间会有延时。需要将这些应用排除在基于云的DR之外,并且提供更多定制的DR产品。

DR服务会运行多久?

最后需要讨论的是,服务会在公有云上运行多久。做这样的决策依赖于发生的事件类型。并非所有灾难都会导致所有在线功能的崩溃。还会存在一些边缘事件类型,比如:

服务器丢失。要么是物理服务器,要么是虚拟服务器主机。虚拟服务器的丢失可能很严重,但也可能不严重,应用程序需要转而运行在DR模式。

多系统丢失。比如,如果共享存储阵列出问题的话,可能会失去多个应用。

数据中心丢失。在最坏的情况下,整个数据中心都丢失了,或者访问不了。所有服务都需要运行在DR模式下。

有时候,服务需要移动几个小时或者几天。当整个站点都丢失时,需求可能是运行DR服务几周或者几个月,直到重建了之前的设备。云恢复服务会为所使用的活动服务计费,因此在选择DR服务时这是很重要的考核点。