NetApp集成数据保护方案

NetApp集成数据保护：作出正确的数据保护选择作者：技术营销工程师SrinathAlapatiNetApp®存储有很多出色之处，其中之一就是所有保护关键数据的功能均与NetApp硬件和DataONTAP®紧密集成。通常，您所需的只是一个许可密钥。您根本无需购买专门的设备或执行复杂的软件安装来增加功能，我们的所有数据保护解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 均利用内置的数据管理功能。图1)传统数据保护方法增加复杂性和成本。NetApp集成数据保护的基本原理已在之前的TechOnTap文章中介绍过。在本文中，我想深入了解我们的复制技术的一些细节。NetApp数据保护的大部分重要要素（例如卷SnapMirror®、配额树SnapMirror、SnapVault®和MetroCluster™）均使用镜像或复制。了解这些技术的工作原理以及它们之间的区别，更易于选择最佳数据保护策略。首先，我将介绍这几种不同的技术，然后就如何选择适合您要求的正确产品提供一些指导。NetApp复制产品这几年来，TechOnTap发 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 了很多关于SnapMirror、SnapVault和MetroCluster的文章。但是，据我所知，目前还没有哪一篇文章完整介绍过这些产品的几个关键功能以及各产品之间的一些重要区别。我先从SnapMirror开始，然后再介绍与之有关的另外两个产品。（如果您觉得SnapMirror的说明过于冗长，请不要太过吃惊。要了解SnapVault和MetroCluster，不一定非得阅读如此冗长的说明。）文章中还包含几个比较表格，可帮助回答您想了解的任何其他问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。SnapMirror可能所有人都知道，SnapMirror主要用于在远程位置创建镜像，以便进行灾难恢复。而只有少数人知道SnapMirror实际上有两种运行模式。卷SnapMirror在物理块级运行。它可将整个卷的内容及所有卷属性从源（主）卷原原本本地复制到目标（二级）卷。因此，目标存储系统必须运行与源存储系统上的DataONTAP版本相同或更高版本的DataONTAP。如果主系统上正在运行重复数据删除或NetApp数据压缩（DataONTAP8.0.1中新增），目标卷上也会继承这些节省，因为卷是相同的，WAN上也会实现节省。配额树SnapMirror可复制各个配额树。因为配额树是卷的子集，所以配额树SnapMirror在逻辑级运行。您不能原原本本地复制配额树，因为在目标系统上，配额树的某些必要卷级记录保存信息会丢失。由于复制在逻辑级进行，因此与卷SnapMirror存在一些重要区别。首先，配额树SnapMirror不会继承重复数据删除实现的节省。再则，如果您从源系统和目标系统背景的角度考虑，这就容易理解了。在源系统上，配额树可以包含经过重复数据删除的块，该块只是指向位于该配额树外的某个块的指针。指针块显然不会存在于目标上，因此必须使用配额树，而不是只使用该指针复制所指向的块。在这种情况下，在网络和容量效率方面，配额树SnapMirror不如卷SnapMirror高效。默认情况下，配额树SnapMirror只复制最后创建的Snapshot副本，因此，它在源位置和目标位置保留的Snapshot副本数量不对等。（根据定义，卷SnapMirror在源位置和目标位置保留相同的Snapshot副本。）配额树SnapMirror只保留执行复制更新所需的一对公用Snapshot副本。换句话说，配额树SnapMirror不具有Snapshot保留功能。两种SnapMirror都从基本副本开始，卷或配额树中的所有数据均从源位置复制到目标位置。完成基本副本复制之后，以后的复制会定期进行。卷SnapMirror支持异步、半同步和同步复制，而配额树SnapMirror只支持异步复制。在异步模式下，会在源位置定期创建卷或配额树的Snapshot副本。只会将上次复制周期后更改或新创建的块传输到目标位置，因而此方法在存储系统开销和网络带宽方面非常高效。同步模式会在发生更新时就将其从源位置发送到目标位置，而不是根据预定计划发送。这有助于在目标系统上实现对源系统中写入的数据的保护，即使整个源系统发生故障，数据也不会受影响。NVLOG和一致点(CP)发送用于保持目标完全是最新的。通过NVLOG发送，可以将写入日志（通常缓存在NetApp存储器上的NVRAM中）中的数据与目标系统保持同步。通过一致点发送，可以使磁盘上的文件系统映像保持同步。半同步模式与同步模式在以下两个方面不同。对源系统的写入无需等待目标系统的确认即可执行并确认；不使用NVLOG发送。这两项变化加快了应用响应速度，对可实现的恢复点目标(RPO)的影响也很小。您可以参考TR-3446：《SnapMirror异步概述和最佳实践指南》以及TR-3326：《SnapMirror同步和SnapMirror半同步概述及 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 注意事项》，了解关于上述所有模式的更多信息。图2)SnapMirror。最后，关于SnapMirror，需要了解的关键一点是卷SnapMirror和配额树SnapMirror都会生成可写入的目标系统。换句话说，如果发生了影响源系统或主系统的故障，您可以对操作进行故障转移，开始向目标系统写入。故障得到解决后，您可以执行故障恢复重新同步操作，将新增的更改复制回源系统，恢复正常运行。此功能是SnapMirror与SnapVault的关键区别。SnapVaultSnapVault主要用于磁盘到磁盘备份。与异步SnapMirror一样，SnapVault利用NetAppSnapshot技术在块级备份和恢复系统。同样，SnapVault也只识别系统上更改的数据块（而非更改的文件），并将其复制到二级存储系统。这不仅能通过限制备份和恢复操作过程中传输的数据量来提高性能，还能限制存储备份的数据所需的容量，使您可以更频繁地执行备份（如果需要）。在基本运作方面，SnapVault与配额树SnapMirror非常类似，它在配额树级执行基于逻辑的复制。因此，与配额树SnapMirror一样，它也不是源卷的精确副本，不会从源卷继承重复数据删除或数据压缩状态。（您可以在目标卷上运行重复数据删除和/或数据压缩，就像对任何其他NetApp卷操作一样。）此外，您无法像对SnapMirror一样实现SnapVault卷可写（用于即时恢复）；因此，如果您通过网络传输大量数据，使用SnapVault的恢复时间可能比使用SnapMirror长很多。如果您也拥有SnapMirror，则可以将SnapVault卷设置为可写，但请记住，SnapVault是单向的，它不具有故障恢复重新同步功能，无法将源系统恢复为最新状态。图3)SnapVault。使用OpenSystemsSnapVault（本文中不予介绍），可以将第三方存储集成到备份框架中。由于SnapVault在逻辑级运行，因此具有Snapshot保留和Snapshot合并这两个关键功能。您可以在SnapVault卷上保留任意多个Snapshot副本（每个卷的上限为255个），Snapshot副本会按照您设置的时间表自动过期。使用合并功能，您可以从多个源系统向一个目标系统运行多个SnapVault进程，然后在目标上创建一个包含所有不同源的Snapshot副本。这样可以减少保存的Snapshot副本的数量；如果您在目标系统上运行重复数据删除，则可以对备份数据中的所有配额树的相同块进行重复数据删除。您可以从《SnapVault最佳实践指南》中了解关于SnapVault各个方面的更多信息。表1)SnapMirror与SnapVault之比较。功能卷SnapMirror配额树SnapMirrorSnapVault复制类型物理逻辑逻辑复制网络FC或IPFC或IP仅IP多个复制路径是是否是否有DataONTAP版本要求是否否网络压缩是是（需得到批准）否RPO（我可以承受丢失多少数据？）1分钟11分钟21小时故障转移功能是是是（需与SnapMirror结合使用）Snapshot保留（用于备份）否可以，但时间很长是Snapshot合并不适用否是故障恢复重新同步是是否重复数据删除目标系统会继承重复数据删除实现的节省以及网络节省目标系统不继承重复数据删除实现的节省SnapVault与重复数据删除集成；目标不继承重复数据删除实现的节省1虽然可以进行1分钟更新，但NetApp不建议进行这种更新。请使用SnapMirror半同步以实现低RPO（低于3分钟）。2虽然可以进行1分钟更新，但NetApp不建议进行这种更新。无法将SnapMirror半同步用于独立的配额树。MetroClusterMetroCluster是NetApp连续数据可用性解决方案。与SnapMirror和SnapVault相比，此解决方案可算是个“另类”，因为它的工作方式非常特殊，但在概念上却很容易理解。顾名思义，MetroCluster可提供“延伸”集群功能。借助它，您可以选择一个标准NetApp高可用性对，将节点分开长达100公里的距离。MetroCluster使用完全镜像的主动-主动式配置，该配置可保留所有镜像数据的两个完整副本，集群两端各一个。这些副本称为丛(plex)，每次DataONTAP向磁盘写入数据时，它们都会持续同步更新。每个控制器都在两个节点上拥有存储卷（丛）。这样不仅能在两个节点上进行重复数据删除，还可以将读取操作分在两个磁盘集上执行，从而将读取性能提升高达80%。您可以阅读近期的TechOnTap案例研究，了解关于MetroCluster的更多信息，也可以观看完整的视频说明。表2)MetroCluster与SnapMirror同步之比较。SnapMirror同步MetroCluster复制网络IP或FCFC是否限制并发传输是无限制最长距离200公里（半同步超过200公里）100公里是否在HA对之间复制是否故障转移CLICLI（单一命令），SystemCenter是否使用副本是是否支持主存储系统重复数据删除是我应该选择哪个选件？上一部分中的表1和表2旨在帮助您选择适合您特定需求的最佳复制选件。有一些考虑因素可以帮助您从上述众多技术中作出选择。第一个也是最显而易见的问题是，您需要的是备份还是灾难恢复。备份如果需要的是备份，那么大多数人会发现，要满足备份需求，只需对主存储系统执行定期快照计划（通常为每小时一次）—可能还需要结合夜间向二级存储系统（本地或远程）上复制SnapVault副本。主存储系统上的Snapshot副本可以满足大多数文件恢复需求，而SnapVault能恢复到更早的时间，还能在发生更严重故障的情况下进行重大恢复。请查看边栏，观看关于NetAppSyncsort集成备份的视频，它结合了Syncsort数据管理与NetApp复制技术，适用于各种重要的应用环境。灾难恢复要保护数据免受整个站点发生灾难的影响，并实现业务连续性，您可能要选择MetroCluster或SnapMirror。目前，在部署数量方面最受欢迎的备选方案是具有异步复制功能的卷SnapMirror。人们倾向于选择此方案，因为它简单经济，能高效地使用存储设备和网络资源。NetApp对SnapMirror投入了大量开发力量，开发出了极其重要的功能，例如带宽限制、网络压缩以及与SnapManager产品套件集成（实现应用集成）。配额树SnapMirror和卷SnapMirror均可实现从数秒到数分钟的恢复时间目标(RTO)，以及低至一分钟的恢复点目标(RPO)—这需要每分钟复制一次数据，尽管NetApp通常不建议每分钟进行一次异步复制。要实现一至三分钟范围内的恢复时间，半同步模式的SnapMirror是更好的选择。（如果您不了解RPO和RTO，请查看边栏。）如果您需要的RPO比异步SnapMirror可以实现的RPO更短，您可以选择MetroCluster或同步SnapMirror。请记住，同步解决方案的实施通常需要使用大得多的网络带宽，以及专门的网络设备，因此费用明显更加高昂。对于距离多达100公里的情况，MetroCluster是首选解决方案，因为它可提供连续数据可用性以及自动故障转移和恢复。SnapMirror同步将支持的距离扩大一倍，达到200公里；SnapMirror半同步支持的距离可以超过200公里（如果您需要更长距离内尽可能低的RPO）。特例虽然上述方法应能涵盖大多数情况，但总会有些特例。有些人使用SnapMirror进行备份，通常因为他们希望能快速轻松地将备份卷设置为可写（当必要时）。相反，另外有一些人使用SnapVault进行灾难恢复，因为SnapVault能让他们恢复到任意时间点。只有SnapVault，无法将SnapVault卷设置为可写，但正如我提过的（虽然我未说明方法），使用SnapVault和SnapMirror却可将SnapVault卷设置为可写。入门当然，许多NetApp用户同时实施了本文中我介绍的几个解决方案，来满足备份和灾难恢复需求。比较常见的方案是将SnapMirror用于关键卷，以在远程站点上创建镜像，另外再在该远程站点执行定期SnapVault计划，以进行备份。某些站点甚至同时部署MetroCluster、SnapMirror和SnapVault来满足数据保护需求。图4)NetApp集成数据保护产品组合（包含本文中未介绍的功能）。您可以阅读《NetApp数据保护手册》，了解关于高级配置、本文中我介绍的所有主题以及我未涉及的主题（例如数据保护规划）的更多信息。您还可以查看本文中我提到的其他资源，了解更多详细信息。NetApp发展了大量专业技术，提供各种数据保护解决方案。如果您在做出正确决策方面需要帮助，可以立即登录NetApp社区或咨询NetApp团队。对集成数据保护有何见解？请在NetApp社区中在线提出问题、交流想法、分享看法。SrinathAlapatiNetApp技术营销工程师Srinath于2004年加入NetApp，已在数据保护部门工作超过四年。他拥有10年以上的IT经验，从事服务器和存储基础架构的管理。Srinath撰写、合著了多篇关于SnapMirror、MetroCluster、VMware®和Exchange的技术报告，并在各种技术会议上有过发言。他也是参与NetAppIT灾难恢复实施的核心团队成员。