数据保护规划
建议更改
PDF
正确的Oracle数据库数据保护架构取决于数据保留、可恢复性以及各种事件期间中断容错能力方面的业务要求。
例如、考虑范围内的应用程序、数据库和重要数据集的数量。为单个数据集构建备份策略以确保符合典型SLA要求相当简单、因为无需管理太多对象。随着数据集数量的增加、监控变得更加复杂、管理员可能不得不花费越来越多的时间来解决备份故障。随着环境达到云和服务提供商规模、需要采用完全不同的方法。
数据集大小也会影响策略。例如、由于数据集非常小、因此对于使用100 GB数据库进行备份和恢复、有许多选项可供选择。只需使用传统工具从备份介质中复制数据、通常就能提供足够的恢复回路(Recovery)。100 TB数据库通常需要完全不同的策略、除非RTO允许发生多天中断、在这种情况下、可以使用基于副本的传统备份和恢复操作步骤。
最后、备份和恢复过程本身之外还有其他因素。例如、是否存在支持关键生产活动的数据库、从而使恢复成为仅由熟练的数据库管理人员执行的罕见事件？或者、数据库是否属于一个大型开发环境、在该环境中、恢复频繁发生、并由一个通才型IT团队进行管理？
快照是否为备份？
对于将快照用作数据保护策略、一个常见的异议是、"实际"数据和快照数据位于同一个驱动器上。丢失这些驱动器将导致主数据和备份均丢失。
这是一个合理的问题。本地快照用于满足日常备份和恢复需求、在这方面、快照是备份。在NetApp环境中、几乎99%的恢复方案都依靠快照来满足最苛刻的恢复时间要求。
但是、本地快照绝不是唯一的备份策略、这就是NetApp提供SnapMirror复制等技术来快速高效地将快照复制到一组独立驱动器的原因。在采用快照和快照复制功能且架构合理的解决方案中、磁带的使用量可以降至最低、甚至可以每季度归档一次、也可以完全避免。
一致性组备份
一致性组备份涉及捕获一个或多个数据集在一个原子时间点的状态。作为数据库示例、这包括所有数据库组件、例如数据文件、日志文件以及与数据库直接关联的其他文件。这几乎适用于所有关系数据库产品、包括Oracle RDBMS、Microsoft SQL Server、SAP HANA、PostgreSQL、 MySQL和MariaDB。使用一致性组备份保护VMware配置的方法与此类似、即在一个原子时间点捕获所有数据存储库、并可能捕获ESX启动LUN。
创建此类一致性组快照本质上是模拟崩溃、因此、此类备份经常称为崩溃状态一致的备份。有时、对恢复方案的支持存在顾虑、但请务必了解、通常不需要恢复操作步骤。当应用程序在还原一致性组备份后启动时、它会执行常规日志恢复过程、文件系统日志重放以及其他任务、以重放备份时传输中的任何I/O。然后、应用程序将照常启动。
从本质上说、可以通过这种方式保护任何能够承受电源故障或服务器崩溃而不会损坏数据的应用程序。许多不同供应商提供的同步和异步镜像产品所保护的大量应用程序也证明了这一点。如果主站点突然发生灾难、则副本站点将包含发生灾难时原始环境的一致映像。同样、不需要特殊的恢复操作步骤。
此方法的RPO通常仅限于备份点。一般来说、单卷快照的最小RPO为一小时。例如、48个每小时快照加上另外30天的每晚快照是合理的、不需要保留过多的快照。低于一小时的RPO将更难实现、因此、如果事先未咨询NetApp专业服务以了解环境、扩展和数据保护要求、则不建议这样做。
通常、可以以秒为单位测量RTO。应用程序关闭、卷还原、应用程序重新启动。
最简单的方法是将所有文件或LUN放在一个卷一致性组中、这样便可直接在ONTAP中计划快照创建。如果数据集必须跨越多个卷、则需要一致性组快照(CG快照)。这可以使用System Manager或还原API调用进行配置、此外、SnapCenter还能够在定义的卷列表上创建简单的一致性组快照。
复制和灾难恢复架构
本节将介绍远程数据保护、即将数据复制到远程站点以实现安全异地存储和灾难恢复。请注意、这些表不涉及同步镜像数据保护。有关此要求、请参见NetApp MetroCluster文档、包括"MetroCluster"和"SnapMirror活动同步"
灾难恢复RPO受可用网络带宽和所保护数据的总大小限制。创建初始基线传输后、更新仅基于更改后的数据、尽管存在例外情况、但更改后的数据在总数据占用空间中所占的百分比通常很低。
例如、一个每周变更率为10%的10 TB数据库平均每小时总变更大约为6 GB。如果使用10 Gb连接、则此数据库需要大约6分钟的传输时间。更改率随数据库更改率的波动而变化、但整体更新间隔为15分钟、因此应可实现15分钟RPO。如果有100个此类数据库、则需要600分钟来传输数据。因此、无法实现1小时的RPO。同样、一个大小为100 TB且每周变更率为10%的数据库的副本无法在一小时内可靠地更新。
其他因素可能会影响复制、例如复制开销和并发复制操作数限制。但是、单卷复制策略的整体规划可以基于可用带宽、通常可以实现一小时的复制RPO。低于一小时的RPO将更难实现、只能在咨询NetApp专业服务后执行。在某些情况下、如果站点间网络连接良好、则15分钟是可行的。但是、总体而言、如果需要的RPO低于一小时、则多卷日志重放架构可以获得更好的结果。
在灾难恢复场景中、具有一致性组复制的恢复时间(从存储角度来看、通常以秒为单位)非常出色。最直接的方法是简单地中断镜像、数据库已准备就绪、可以启动。数据库启动时间通常约为10秒、但包含大量记录事务的大型数据库可能需要几分钟的时间。
确定ROTO的更重要因素不是存储系统、而是运行它的应用程序和主机操作系统。例如、复制的数据可以在一两秒钟内提供、但这仅表示数据。此外、还必须有一个配置正确的操作系统、其中包含可用于数据的应用程序二进制文件。
在某些情况下、客户会提前准备灾难恢复实例、并在操作系统上预先发现存储。在这些情况下、激活灾难恢复方案只需要中断镜像并启动应用程序即可。在其他情况下、操作系统和关联应用程序可能会作为ESX虚拟机磁盘(VMDK)与数据库一起镜像。在这些情况下、RPO取决于客户在自动化方面的投入、以快速启动VMDK、从而可以启动应用程序。
保留时间部分由快照限制控制。例如、ONTAP中的卷限制为1024个快照。在某些情况下、客户会通过多路复用复制来增加限制。例如、如果需要2000天的备份、则可以将一个源复制到两个卷、并在备用日期进行更新。这需要增加初始所需空间、但与涉及多个完整备份的传统备份系统相比、这种方法的效率要高得多。
单卷一致性组
最简单的方法是将所有文件或LUN放在一个卷一致性组中、这样可以直接在存储系统上计划SnapMirror和SnapVault更新。不需要外部软件。
多卷一致性组
如果数据库必须跨越多个卷、则需要一致性组快照(CG快照)。如上所述、可以使用System Manager或还原API调用来配置此功能、此外、SnapCenter还能够在定义的卷列表上创建简单的一致性组快照。
此外、还需要考虑将多卷一致快照用于灾难恢复的问题。在更新多个卷时、可能会在传输过程中发生灾难。结果将是一组彼此不一致的卷。如果发生这种情况、则必须将某些卷还原到先前的快照状态、以提供崩溃状态一致且可供使用的数据库映像。
灾难恢复：激活
NFS
激活灾难恢复副本的过程取决于存储类型。通过NFS、可以在灾难恢复服务器上预挂载文件系统。它们处于只读状态、并在镜像中断后变为读写状态。这样可实现极低的RPO、而且由于需要管理的部件较少、因此整个灾难恢复过程更可靠。
SAN
在发生灾难恢复时激活SAN配置会变得更加复杂。最简单的方法通常是临时中断镜像并挂载SAN资源、包括发现LVM配置(包括Oracle自动存储管理[ASM]等应用程序专用功能)以及向/etc/fstab中添加条目等步骤。
这样、目标服务器就可以识别LUN设备路径、卷组名称和其他设备路径。然后、可以关闭这些资源、然后还原镜像。这样、服务器就会处于可以快速使应用程序联机的状态。激活卷组、挂载文件系统或启动数据库和应用程序的步骤可以轻松实现自动化。
必须注意确保灾难恢复环境是最新的。例如、可能会向源服务器添加新的LUN、这意味着必须在目标上预先发现新的LUN、以确保灾难恢复计划按预期运行。