论文部分内容阅读
灾难恢复通常需要花费高昂的成本。比如在远处某个地方建好备用站点，拥有一整套的硬件、软件和系统，并将数据复制到该远程站点，以防万一遇到了灾难，可以保证系统正常运行。但这需要全面的系统冗余性，而一套备用系统在99.99%的时间里都处于闲置状态。在眼下预算紧张的大环境下，其实很少有谁能实现这种梦想。
因此，云灾难恢复服务提供商应运而生，比如RackWare、亚马逊、谷歌和Zetta。它们给云计算的定位是它不仅仅是存储数据的地方，还是替代传统灾难恢复的一种合理方案。
以下是将云服务添加到灾难恢复计划的七招。
选择要慎重
现在有许多选择。除了上述四家公司外，还有Zerto、HotLink和Veeam等提供商，它们都提供专业的云灾难恢复服务。不过认真打量一番这些提供商，我们就会发现它们之间的不同。有些适合不太需要频繁访问的批量存储，而另一些则更适合复制。当然，定价模式和费用也大不一样。对某一种类型的流量而言是经济高效的云服务，而对另一种类型的流量则可能不那么合适。
使用云改善RPO/RTO
恢复时间目标（RTO）是指用户愿意等待、直到站点恢复如初的时间。恢复点目标（RPO）则是指万一出现灾难，用户愿意失去的数据量。Zetta公司的产品副总裁Chris Schin指出，就传统的灾难恢复解决方案而言，RPO只适用于被迁移到灾难区域以外某个异地位置上的一个备份集。如果灾难发生时备份仍在现场，那备份到磁带或闪驱上的任何近期数据都恢复不了。
Chris Schin说：“如果你使用物理存储介质将数据迁移到异地，灾难场景下的RPO并不取决于备份软件的参数，而是取决于那些磁带被送到异地磁带库的频率。如果是每周一次，那么PRO最多就是为期一周的数据量，哪怕你之前每小时快照一次。”
迁移工作负载
RackWare公司的首席执行官Sash Sunkara鼓励公司大胆尝试：把备份之外的工作负载也放到云端。她建议，可以把一些工作负载整个放到云端，看看效果如何。她说：“毫无疑问，使用云基础设施来备份数据具有优势，不过，你不仅可以备份文件和数据，还能将物理服务器的整个工作负载（包括操作系统、应用程序和数据）直接移到任何云上，比如亚马逊云服务、RackSpace或SoftLayer。”
考虑全面的云灾难恢复
一些公司正在想方设法成为所有备份数据的云存储库，其中谷歌走得最远，它竭力推销Google Apps，希望将用户的全部数据都存储到云上，并负责处理相关的灾难恢复。
Google Apps高级产品经理Rajen Sheth声称，Google Apps的RPO目标为零。它拥有在幕后复制所有数据的庞大云。其他公司也提供类似的服务，让用户可以继续使用自己青睐的任何商务应用软件，而不是完全求助于谷歌。
使用多个云
虽然这个行业的技术巨擘们拼命吆喝使用一个综合云里面的多个数据中心，但LC Technology International公司的CEO David Zimmerman则提议，使用多家云服务提供商来用于灾难恢复，以降低风险。他说：“别仅仅使用一个云，而要使用多个云来降低风险，可将数据备份到每个云，实现冗余机制。由于成本日益下降、可靠性日益提高，云大有希望，不过企业仍应该小心行事。”
物理系统作为补充
降低风险的另一个办法就是，继续保留某种基于物理系统的灾难恢复方案。如果整个云被黑客盯上了，或者丢失了网络，这实际上相当于将全部鸡蛋都放在云这一只篮子里面。David Zimmerman说：“公司应该考虑物理存储及其他方案，作为云的补充。云存储依赖于互联网访问，所以关键系统应该还要有某种内部部署的存储解决方案。”
莫忘保护不足的工作负载
Sash Sunkara支了另一个妙招。她特别指出，在许多数据中心，受保护的工作负载往往被分成两类：关键任务型，这种工作负载即使停止运行几分钟都不行；低优先级型，这种工作负载在归档时可能需要花几小时、甚至几天才能恢复。前者通常由非常昂贵、先进的高可用性和集群解决方案加以保护，这类解决方案能实时同步复制系统。后者往往由磁盘归档或磁带备份加以保护，成本非常低廉，但恢复速度也很慢。
Sash Sunkara说，介于这两类之间的所有工作负载通常需要较快的恢复时间，但不需要昂贵的复制系统，它们缺乏保护力度。面对这些保护不足的工作负载，有一个解决之道，即使用云作为“虚拟灾难恢复”站点，将工作负载出现的变化定期同步起来，万一出现计划内停止运行或意外停止运行，恢复系统可在短短几分钟内投入使用。
由于成本日益下降、可靠性日益提高，云大有希望，不过企业仍应该小心行事。
因此，云灾难恢复服务提供商应运而生，比如RackWare、亚马逊、谷歌和Zetta。它们给云计算的定位是它不仅仅是存储数据的地方，还是替代传统灾难恢复的一种合理方案。
以下是将云服务添加到灾难恢复计划的七招。
选择要慎重
现在有许多选择。除了上述四家公司外，还有Zerto、HotLink和Veeam等提供商，它们都提供专业的云灾难恢复服务。不过认真打量一番这些提供商，我们就会发现它们之间的不同。有些适合不太需要频繁访问的批量存储，而另一些则更适合复制。当然，定价模式和费用也大不一样。对某一种类型的流量而言是经济高效的云服务，而对另一种类型的流量则可能不那么合适。
使用云改善RPO/RTO
恢复时间目标（RTO）是指用户愿意等待、直到站点恢复如初的时间。恢复点目标（RPO）则是指万一出现灾难，用户愿意失去的数据量。Zetta公司的产品副总裁Chris Schin指出，就传统的灾难恢复解决方案而言，RPO只适用于被迁移到灾难区域以外某个异地位置上的一个备份集。如果灾难发生时备份仍在现场，那备份到磁带或闪驱上的任何近期数据都恢复不了。
Chris Schin说：“如果你使用物理存储介质将数据迁移到异地，灾难场景下的RPO并不取决于备份软件的参数，而是取决于那些磁带被送到异地磁带库的频率。如果是每周一次，那么PRO最多就是为期一周的数据量，哪怕你之前每小时快照一次。”
迁移工作负载
RackWare公司的首席执行官Sash Sunkara鼓励公司大胆尝试：把备份之外的工作负载也放到云端。她建议，可以把一些工作负载整个放到云端，看看效果如何。她说：“毫无疑问，使用云基础设施来备份数据具有优势，不过，你不仅可以备份文件和数据，还能将物理服务器的整个工作负载（包括操作系统、应用程序和数据）直接移到任何云上，比如亚马逊云服务、RackSpace或SoftLayer。”
考虑全面的云灾难恢复
一些公司正在想方设法成为所有备份数据的云存储库，其中谷歌走得最远，它竭力推销Google Apps，希望将用户的全部数据都存储到云上，并负责处理相关的灾难恢复。
Google Apps高级产品经理Rajen Sheth声称，Google Apps的RPO目标为零。它拥有在幕后复制所有数据的庞大云。其他公司也提供类似的服务，让用户可以继续使用自己青睐的任何商务应用软件，而不是完全求助于谷歌。
使用多个云
虽然这个行业的技术巨擘们拼命吆喝使用一个综合云里面的多个数据中心，但LC Technology International公司的CEO David Zimmerman则提议，使用多家云服务提供商来用于灾难恢复，以降低风险。他说：“别仅仅使用一个云，而要使用多个云来降低风险，可将数据备份到每个云，实现冗余机制。由于成本日益下降、可靠性日益提高，云大有希望，不过企业仍应该小心行事。”
物理系统作为补充
降低风险的另一个办法就是，继续保留某种基于物理系统的灾难恢复方案。如果整个云被黑客盯上了，或者丢失了网络，这实际上相当于将全部鸡蛋都放在云这一只篮子里面。David Zimmerman说：“公司应该考虑物理存储及其他方案，作为云的补充。云存储依赖于互联网访问，所以关键系统应该还要有某种内部部署的存储解决方案。”
莫忘保护不足的工作负载
Sash Sunkara支了另一个妙招。她特别指出，在许多数据中心，受保护的工作负载往往被分成两类：关键任务型，这种工作负载即使停止运行几分钟都不行；低优先级型，这种工作负载在归档时可能需要花几小时、甚至几天才能恢复。前者通常由非常昂贵、先进的高可用性和集群解决方案加以保护，这类解决方案能实时同步复制系统。后者往往由磁盘归档或磁带备份加以保护，成本非常低廉，但恢复速度也很慢。
Sash Sunkara说，介于这两类之间的所有工作负载通常需要较快的恢复时间，但不需要昂贵的复制系统，它们缺乏保护力度。面对这些保护不足的工作负载，有一个解决之道，即使用云作为“虚拟灾难恢复”站点，将工作负载出现的变化定期同步起来，万一出现计划内停止运行或意外停止运行，恢复系统可在短短几分钟内投入使用。
由于成本日益下降、可靠性日益提高，云大有希望，不过企业仍应该小心行事。