最基本的数据保护级别是校验和、校验和是随数据一起存储的一种特殊错误检测代码。使用校验和(在某些情况下、使用多个校验和)检测网络传输期间的数据损坏。

例如、FC帧包含一种称为循环冗余校验(CRC)的校验和形式、用于确保有效负载在传输过程中不会损坏。发射器会同时发送数据和数据的CRC。FC帧的接收器重新计算已接收数据的CRC、以确保其与已传输的CRC匹配。如果新计算的CRC与附加到帧的CRC不匹配、则数据将损坏、FC帧将被丢弃或拒绝。iSCSI I/O操作包括TCP/IP和以太网层的校验和、并且为了提供额外保护、还可以在SCSI层提供可选的CRC保护。TCP层或IP层会检测到线路上的任何位损坏、从而导致数据包重新传输。与FC一样、SCSI CRC中的错误会导致丢弃或拒绝操作。

校验和还用于验证存储在驱动器上的数据的完整性。写入驱动器的数据块使用校验和功能进行存储、该功能会产生与原始数据相关的不可预测的数字。从驱动器中读取数据时、将重新计算校验和并将其与存储的校验和进行比较。如果不匹配、则数据已损坏、必须由RAID层进行恢复。

最难检测的损坏类型之一是写入丢失或放错位置。确认写入后、必须将其写入到正确位置的介质中。通过使用随数据存储的简单校验和、可以相对容易地检测原位数据损坏。但是、如果只是写入丢失、则先前版本的数据可能仍存在、校验和将是正确的。如果将写入放置在错误的物理位置、则关联的校验和将再次对存储的数据有效、即使写入操作已销毁其他数据。

应对此挑战的解决方案如下：

当ONTAP写入块时、它会包含有关块所属位置的数据。如果后续读取发现某个块、但在位置456发现元数据时、元数据指示该块属于位置123、则表示该写入已放错位置。

检测完全丢失的写入操作会更加困难。解释非常复杂、但从本质上说、ONTAP存储元数据的方式是、写入操作会导致更新到驱动器上的两个不同位置。如果写入丢失、则后续读取的数据和关联元数据将显示两个不同的版本标识。这表示驱动器未完成写入。

丢失和放错位置的写入损坏极为少见、但随着驱动器不断增长、数据集逐渐扩展到EB级、风险也会增加。支持数据库工作负载的任何存储系统都应包括失写检测。

如果发现驱动器上的数据块已损坏、或者整个驱动器发生故障且完全不可用、则必须重新生成数据。这在ONTAP中通过使用奇偶校验驱动器来实现。数据在多个数据驱动器之间进行条带化、然后生成奇偶校验数据。该数据与原始数据分开存储。

ONTAP最初使用的是RAID 4、该RAID 4会为每组数据驱动器使用一个奇偶校验驱动器。这样、组中的任何一个驱动器都可能发生故障、而不会导致数据丢失。如果奇偶校验驱动器发生故障、则不会损坏任何数据、可以构建新的奇偶校验驱动器。如果一个数据驱动器发生故障、则其余驱动器可与奇偶校验驱动器结合使用来重新生成缺失的数据。

如果驱动器较小、则两个驱动器同时发生故障的统计几率可以忽略不计。随着驱动器容量的增长、在驱动器发生故障后重建数据所需的时间也会相应增加。这增加了第二个驱动器故障导致数据丢失的时间范围。此外、重建过程会在无故障驱动器上创建大量额外的I/O。随着驱动器老化、导致第二个驱动器故障的额外负载风险也会增加。最后、即使持续使用RAID 4不会增加数据丢失的风险、数据丢失的后果也会更加严重。RAID组发生故障时丢失的数据越多、恢复数据所需的时间就越长、从而延长业务中断时间。

这些问题促使NetApp开发了NetApp RAID DP技术、这是RAID 6的变体。此解决方案包含两个奇偶校验驱动器、这意味着RAID组中的任何两个驱动器都可能发生故障、而不会造成数据丢失。驱动器的大小持续增长、这最终导致NetApp开发了NetApp RAID-TEC技术、该技术引入了第三个奇偶校验驱动器。

一些历史数据库最佳实践建议使用RAID-10、也称为条带化镜像。这提供的数据保护比RAID DP更少、因为存在多种双磁盘故障情形、而在RAID DP中则没有。

还有一些历史数据库最佳实践表明、出于性能考虑、RAID-10优于RAID-4/5/6选项。这些建议有时会提及RAID惩罚。虽然这些建议通常是正确的、但不适用于在ONTAP中实施RAID。性能问题与奇偶校验重新生成有关。在传统RAID实施中、处理数据库执行的例行随机写入需要多次磁盘读取才能重新生成奇偶校验数据并完成写入。惩罚定义为执行写入操作所需的额外读取IOPS。

ONTAP不会产生RAID惩罚、因为写入会暂存到内存中、在该内存中会生成奇偶校验、然后作为单个RAID条带写入磁盘。完成写入操作不需要执行任何读取操作。

总之、与RAID 10相比、RAID DP和RAID-TEC可提供更多的可用容量、更好地防止驱动器故障、并且不会影响性能。

任何为数据库工作负载提供服务的存储阵列都必须尽快为写入操作提供服务。此外、必须保护写入操作、使其不会因意外事件(例如断电)而丢失。这意味着任何写入操作都必须安全地存储在至少两个位置。

AFF和FAS系统依靠NVRAM来满足这些要求。写入过程的工作原理如下：

从应用程序角度来看、此阶段的写入过程已完成、数据会受到保护、不会丢失、因为数据会存储在两个不同的位置。更改最终会写入磁盘、但从应用程序角度来看、此过程是带外过程、因为它发生在确认写入之后、因此不会影响延迟。此过程再次类似于数据库日志记录。对数据库所做的更改会尽快记录在重做日志中、然后确认已提交更改。数据文件的更新发生得更晚、不会直接影响处理速度。

如果某个控制器发生故障、配对控制器将接管所需磁盘的所有权、并在NVRAM中回显已记录的数据、以恢复发生故障时正在进行的任何I/O操作。

如前文所述、写入操作只有在至少另一个控制器上记录到本地NVRAM和NVRAM后才会得到确认。此方法可确保硬件故障或断电不会导致传输中I/O丢失如果本地NVRAM发生故障或与HA配对节点的连接发生故障、则不会再镜像此传输中的数据。

如果本地NVRAM报告错误、则此节点将关闭。此关闭会导致故障转移到HA配对控制器。由于发生故障的控制器尚未确认写入操作、因此不会丢失任何数据。

除非强制执行故障转移、否则ONTAP不允许在数据不同步时进行故障转移。以这种方式强制更改条件即表示数据可能会留在原始控制器中、并且数据丢失是可以接受的。

如果强制执行故障转移、数据库尤其容易受到损坏的影响、因为数据库会在磁盘上保留大量内部数据缓存。如果发生强制故障转移、先前确认的更改将被有效丢弃。存储阵列的内容会及时有效地向后跳转、数据库缓存的状态不再反映磁盘上数据的状态。

为了保护数据免受这种情况的影响、ONTAP允许对卷进行配置、以便针对NVRAM故障提供特殊保护。触发此保护机制后、卷将进入名为NVFAIL的状态。此状态会导致I/O错误、即发生原因A应用程序会关闭、以使其不使用陈旧数据。数据不应丢失、因为存储阵列上应存在任何已确认的写入。

通常的后续步骤是、管理员先完全关闭主机、然后再手动将LUN和卷重新联机。虽然这些步骤可能涉及一些工作、但这种方法是确保数据完整性的最安全方法。并非所有数据都需要这种保护、这就是可以逐个卷配置NVFAIL行为的原因。

SyncMirror是一种镜像技术、可增强但不会取代RAID DP或RAID-TEC。它会镜像两个独立RAID组的内容。逻辑配置如下：

上图显示了一个示例SyncMirror配置。在控制器上创建了一个包含24个驱动器的聚合、其中12个驱动器来自站点A上分配的磁盘架、12个驱动器来自站点B上分配的磁盘架这些驱动器被分组为两个镜像RAID组。RAID组0在站点A上包含一个6驱动器丛、该丛镜像到站点B上的6驱动器丛同样、RAID组1在站点A上包含一个6驱动器丛、该丛镜像到站点B上的6驱动器丛

SyncMirror通常用于为MetroCluster系统提供远程镜像、每个站点有一个数据副本。有时、它会用于在单个系统中提供额外的冗余级别。尤其是、它可以提供磁盘架级冗余。驱动器架已包含双电源和控制器、总体比金属板稍多、但在某些情况下、可能需要额外保护。例如、一家NetApp客户为汽车测试期间使用的移动实时分析平台部署了SyncMirror。该系统分为两个物理机架、由独立UPS系统的独立电源供电。

对于习惯于使用Oracle RMAN流式备份并迁移到基于快照的备份的数据库用户来说、校验和主题特别重要。RMAN的一项功能是、它会在备份操作期间执行完整性检查。尽管此功能具有一定的价值、但其主要优势是用于未在现代存储阵列上使用的数据库。将物理驱动器用于Oracle数据库时、几乎可以肯定、随着驱动器老化、最终会发生损坏、而在真正的存储阵列中、基于阵列的校验和可以解决这一问题。

对于真正的存储阵列、数据完整性可通过在多个级别使用校验和来保护。如果基于IP的网络中的数据损坏、则传输控制协议(TCP)层会拒绝数据包数据并请求重新传输。FC协议包括校验和、封装的SCSI数据也是如此。将ONTAP置于阵列上后、它将具有RAID和校验和保护功能。可能会发生损坏、但与大多数企业阵列一样、系统会检测到并更正此问题。通常、整个驱动器发生故障、提示重建RAID、数据库完整性不受影响。驱动器上的单个字节仍然可能被宇宙辐射或闪存单元故障损坏。如果发生这种情况、奇偶校验检查将失败、驱动器将出现故障、并开始RAID重建。同样、数据完整性也不受影响。最后一道防线是使用校验和。例如、如果驱动器损坏的数据出现灾难性固件错误、而RAID奇偶校验检查无法检测到该数据、则校验和将不匹配、ONTAP将阻止在Oracle数据库收到损坏的块之前传输该块。

Oracle数据文件和重做日志架构还旨在提供尽可能高级别的数据完整性、即使在极端情况下也是如此。在最基本的层面上、Oracle块包括对几乎每个I/O进行校验和和和基本逻辑检查如果Oracle未崩溃或使表空间脱机、则数据完好无损。数据完整性检查的程度可以调整、Oracle也可以配置为确认写入。因此、几乎所有崩溃和故障情形都可以恢复、在极少数情况下发生不可恢复的情况时、系统会立即检测到损坏。

大多数使用Oracle数据库的NetApp客户在迁移到基于快照的备份之后不再使用RMAN和其他备份产品。在使用SnapCenter执行块级恢复时、仍然可以使用RMAN。但是、在日常工作中、RMAN、NetBackup和其他产品仅偶尔用于创建每月或每季度归档副本。

有些客户选择运行 dbv 定期对其现有数据库执行完整性检查。NetApp不建议采用这种做法、因为它会产生不必要的I/O负载。如上所述、如果数据库之前未遇到问题、则可能会出现 dbv 检测问题几乎为零、此实用程序会在网络和存储系统上创建非常高的顺序I/O负载。除非有理由认为存在损坏、例如暴露于已知的Oracle错误、否则没有理由运行 dbv。