가장 기본적인 데이터 보호 수준은 데이터와 함께 저장되는 특별한 오류 감지 코드인 체크섬입니다. 네트워크 전송 중 데이터 손상은 체크섬을 사용하여 감지되며 경우에 따라 여러 체크섬을 사용할 수 있습니다.

예를 들어, FC 프레임에는 전송 중에 페이로드가 손상되지 않도록 CRC(Cyclic Redundancy Check)라는 체크섬 유형이 포함되어 있습니다. 송신기는 데이터와 데이터의 CRC를 모두 전송합니다. FC 프레임의 수신기는 수신된 데이터의 CRC를 다시 계산하여 전송된 CRC와 일치하는지 확인합니다. 새로 계산된 CRC가 프레임에 연결된 CRC와 일치하지 않으면 데이터가 손상되고 FC 프레임이 삭제되거나 거부됩니다. iSCSI I/O 작업에는 TCP/IP 및 이더넷 계층에 체크섬이 포함되며, 추가적인 보호를 위해 SCSI 계층에 선택 사항인 CRC 보호 기능이 포함될 수도 있습니다. 와이어의 모든 비트 손상은 TCP 계층 또는 IP 계층에서 감지되어 패킷의 재전송을 초래합니다. FC와 마찬가지로 SCSI CRC의 오류로 인해 작업이 삭제되거나 거부됩니다.

또한 체크섬을 사용하여 드라이브에 저장된 데이터의 무결성을 검증합니다. 드라이브에 기록된 데이터 블록은 원래 데이터와 연결된 예측 불가능한 수를 생성하는 체크섬 기능과 함께 저장됩니다. 드라이브에서 데이터를 읽으면 체크섬이 다시 계산되어 저장된 체크섬과 비교됩니다. 일치하지 않으면 데이터가 손상되어 RAID 계층에 의해 복구되어야 합니다.

감지하기 가장 어려운 유형의 손상 중 하나는 손실되거나 잘못 배치된 쓰기입니다. 쓰기가 확인되면 올바른 위치에 있는 미디어에 기록해야 합니다. 데이터 이동 없는 데이터 손상은 데이터와 함께 저장된 간단한 체크섬을 사용하여 비교적 쉽게 감지할 수 있습니다. 그러나 쓰기가 단순히 손실되는 경우 이전 버전의 데이터가 여전히 존재하고 체크섬이 정확할 수 있습니다. 쓰기가 잘못된 물리적 위치에 배치되면 쓰기가 다른 데이터를 제거했더라도 연결된 체크섬이 저장된 데이터에 대해 다시 한 번 유효합니다.

이 문제에 대한 해결책은 다음과 같습니다.

ONTAP에서 블록을 쓰면 해당 블록이 속한 위치에 대한 데이터가 포함됩니다. 후속 읽기에서 블록을 식별하지만 메타데이터에서 위치 456에서 찾은 위치 123에 해당 블록이 속해 있음을 나타내는 경우 쓰기가 잘못 배치된 것입니다.

완전히 손실된 쓰기를 감지하기가 더 어렵습니다. 이 설명은 매우 복잡하지만 기본적으로 ONTAP은 쓰기 작업으로 인해 드라이브의 서로 다른 두 위치에 업데이트가 이루어지도록 메타데이터를 저장하고 있습니다. 쓰기가 손실되면 후속 데이터 읽기와 관련 메타데이터를 읽으면 서로 다른 두 버전 ID가 표시됩니다. 이는 드라이브에서 쓰기가 완료되지 않았음을 나타냅니다.

손실되거나 잘못 배치된 쓰기 손상은 매우 드물지만 드라이브가 계속 증가하고 데이터 세트가 엑사바이트 규모로 증가함에 따라 위험이 증가합니다. 손실된 쓰기 감지 기능은 데이터베이스 워크로드를 지원하는 모든 스토리지 시스템에 포함되어야 합니다.

드라이브의 데이터 블록이 손상되었거나 전체 드라이브에 장애가 발생하여 완전히 사용할 수 없는 경우 데이터를 다시 구성해야 합니다. 이 작업은 ONTAP에서 패리티 드라이브를 사용하여 수행됩니다. 데이터가 여러 데이터 드라이브에 스트라이핑된 다음 패리티 데이터가 생성됩니다. 원본 데이터와 별도로 저장됩니다.

ONTAP에서는 원래 데이터 드라이브 그룹마다 단일 패리티 드라이브를 사용하는 RAID 4를 사용했습니다. 그 결과, 그룹의 드라이브 중 하나에 장애가 발생하여 데이터가 손실되지 않을 수 있었습니다. 패리티 드라이브에 장애가 발생하면 데이터가 손상되지 않았으며 새 패리티 드라이브를 구성할 수 있습니다. 단일 데이터 드라이브에 장애가 발생하면 나머지 드라이브를 패리티 드라이브와 함께 사용하여 누락된 데이터를 재생성할 수 있습니다.

드라이브 용량이 작을 경우 두 개의 드라이브가 동시에 실패할 가능성이 매우 낮았습니다. 드라이브 용량이 증가함에 따라 드라이브 장애 후 데이터를 재구성하는 데 많은 시간이 필요하게 되었습니다. 이로 인해 두 번째 드라이브 오류로 인해 데이터가 손실되는 기간이 늘어났습니다. 또한 리빌드 프로세스는 나머지 드라이브에서 많은 I/O를 추가로 생성합니다. 드라이브가 노후화되면 추가 로드로 인해 두 번째 드라이브 장애가 발생할 위험도 증가합니다. 마지막으로 RAID 4를 계속 사용하면 데이터 손실 위험이 증가하지 않더라도 데이터 손실의 결과는 더욱 심각해집니다. RAID 그룹 장애 시 손실될 데이터가 많을수록 데이터 복구에 시간이 더 오래 걸리기 때문에 비즈니스 운영이 중단됩니다.

이러한 문제로 인해 NetApp는 RAID 6의 변종인 NetApp RAID DP 기술을 개발하게 되었습니다. 이 솔루션에는 패리티 드라이브가 2개 포함되어 있으므로 RAID 그룹에 있는 두 드라이브가 데이터 손실없이 실패할 수 있습니다. 드라이브의 크기가 계속 커짐에 따라 NetApp는 NetApp RAID-TEC 기술을 개발하여 세 번째 패리티 드라이브를 도입했습니다.

일부 내역 데이터베이스 모범 사례에서는 스트라이프 미러링이라고도 하는 RAID-10을 사용할 것을 권장합니다. 여러 개의 2-디스크 장애 시나리오가 있기 때문에 RAID DP보다 데이터 보호 기능이 떨어지는 반면 RAID DP는 없습니다.

또한 성능 문제로 인해 RAID-10이 RAID-4/5/6 옵션보다 선호됨을 나타내는 몇 가지 과거 데이터베이스 모범 사례가 있습니다. 이러한 권장 사항은 종종 RAID 성능 저하와 관련이 있습니다. 이러한 권장 사항은 일반적으로 정확하지만 ONTAP 내에서 RAID를 구현하는 경우에는 적용되지 않습니다. 성능 문제는 패리티 재생과 관련이 있습니다. 기존 RAID 구현에서 데이터베이스에서 수행하는 일상적인 랜덤 쓰기를 처리하려면 패리티 데이터를 재생성하고 쓰기를 완료하기 위해 여러 디스크 읽기를 수행해야 합니다. 페널티는 쓰기 작업을 수행하는 데 필요한 추가 읽기 IOPS로 정의됩니다.

쓰기 작업은 패리티가 생성된 메모리에서 스테이징된 다음 단일 RAID 스트라이프로 디스크에 기록되므로 ONTAP에서 RAID 패널티가 발생하지 않습니다. 쓰기 작업을 완료하는 데 읽기 작업이 필요하지 않습니다.

요약하면 RAID DP 및 RAID-TEC는 RAID 10과 비교하여 훨씬 더 많은 가용 용량을 제공하고, 드라이브 장애를 방지하며, 성능에 영향을 주지 않습니다.

데이터베이스 워크로드를 처리하는 스토리지 어레이는 쓰기 작업을 최대한 빨리 처리해야 합니다. 또한 쓰기 작업은 전원 장애와 같은 예기치 않은 이벤트로 인한 손실로부터 보호해야 합니다. 즉, 쓰기 작업은 적어도 두 위치에 안전하게 저장해야 합니다.

AFF 및 FAS 시스템은 이러한 요구사항을 충족하기 위해 NVRAM을 사용합니다. 쓰기 프로세스는 다음과 같이 작동합니다.

이 단계의 쓰기 프로세스는 응용 프로그램 관점에서 완료되며 데이터는 서로 다른 두 위치에 저장되므로 손실로부터 보호됩니다. 최종적으로 변경 사항이 디스크에 기록되지만 이 프로세스는 쓰기 확인 후에 발생하므로 지연 시간에 영향을 주지 않기 때문에 애플리케이션 관점에서 대역 외로 처리됩니다. 이 프로세스는 데이터베이스 로깅과 다시 유사합니다. 데이터베이스 변경 사항은 가능한 한 빨리 재실행 로그에 기록되고 변경 사항은 커밋된 것으로 확인됩니다. 데이터 파일에 대한 업데이트는 훨씬 나중에 수행되며 처리 속도에 직접적인 영향을 주지 않습니다.

컨트롤러 장애가 발생할 경우 파트너 컨트롤러가 필요한 디스크의 소유권을 가져오고 NVRAM에 기록된 데이터를 재생하여 장애가 발생했을 때 전송 중이었던 I/O 작업을 복구합니다.

앞서 설명한 것처럼, 쓰기는 하나 이상의 다른 컨트롤러에서 로컬 NVRAM 및 NVRAM에 로그인되기 전까지는 승인되지 않습니다. 이렇게 하면 하드웨어 장애나 정전이 발생해도 전송 중인 I/O가 손실되지 않습니다 로컬 NVRAM에 장애가 발생하거나 HA 파트너에 대한 연결이 실패하면 전송 중인 이 데이터는 더 이상 미러링되지 않습니다.

로컬 NVRAM에 오류가 보고되면 노드가 종료됩니다. 이 종료를 통해 HA 파트너 컨트롤러로 페일오버됩니다. 오류가 발생한 컨트롤러가 쓰기 작업을 인식하지 못했기 때문에 데이터가 손실되지 않습니다.

페일오버가 강제 적용되지 않는 한 ONTAP는 데이터가 동기화되지 않을 때 페일오버를 허용하지 않습니다. 이러한 방식으로 조건을 강제로 변경하면 데이터가 원래 컨트롤러에 남겨질 수 있으며 데이터 손실이 허용되는 수준임을 알 수 있습니다.

데이터베이스는 디스크에 대규모 내부 데이터 캐시를 유지하기 때문에 페일오버가 강제 적용되는 경우 손상에 특히 취약합니다. 강제 적용 페일오버가 발생하면 이전에 승인되었던 변경사항이 효과적으로 폐기됩니다. 스토리지 어레이의 콘텐츠가 사실상 이전 시간으로 이동하며, 데이터베이스 캐시의 상태는 디스크에 있는 데이터의 상태를 더 이상 반영하지 않습니다.

이 상황에서 데이터를 보호하기 위해 ONTAP에서는 NVRAM 장애에 대비하여 특별한 보호를 제공하도록 볼륨을 구성할 수 있습니다. 이 보호 메커니즘이 트리거되면 볼륨이 NVFAIL이라는 상태로 전환됩니다. 이 상태에서는 I/O 오류가 발생하여 오래된 데이터를 사용하지 않도록 애플리케이션이 종료됩니다. 확인된 쓰기가 스토리지 배열에 있어야 하므로 데이터가 손실되지 않아야 합니다.

일반적인 다음 단계는 관리자가 LUN 및 볼륨을 수동으로 다시 온라인 상태로 전환하기 전에 호스트를 완전히 종료하는 것입니다. 이러한 단계에는 일부 작업이 포함될 수 있지만 이 접근 방식은 데이터 무결성을 보장하는 가장 안전한 방법입니다. 모든 데이터에 이 보호가 필요한 것은 아니므로 NVFAIL 동작을 볼륨별로 구성할 수 있습니다.

SyncMirror는 RAID DP 또는 RAID-TEC를 향상하지만 대체하지는 않는 미러링 기술입니다. 2개의 독립적인 RAID 그룹의 콘텐츠를 미러링합니다. 논리적 구성은 다음과 같습니다.

위 그림은 SyncMirror 구성의 예를 보여 줍니다. 24-드라이브 애그리게이트가 사이트 A에 할당된 쉘프의 드라이브 12개와 사이트 B에 할당된 쉘프의 드라이브 12개로 컨트롤러에서 생성되었습니다 드라이브는 두 개의 미러링된 RAID 그룹으로 그룹화되었습니다. RAID Group 0에는 사이트 B의 6개 드라이브 플렉스에 미러링된 사이트 A의 6개 드라이브 플렉스가 포함되어 있습니다 마찬가지로, RAID 그룹 1에는 사이트 B의 6개 드라이브 플렉스에 미러링되는 사이트 A의 6개 드라이브 플렉스가 포함되어 있습니다

SyncMirror는 일반적으로 각 사이트에 하나의 데이터 복사본으로 MetroCluster 시스템에 원격 미러링을 제공하는 데 사용됩니다. 경우에 따라 단일 시스템에서 추가 수준의 이중화를 제공하기 위해 사용되었습니다. 특히, 쉘프 레벨 이중화를 제공합니다. 드라이브 쉘프에는 이미 이중 전원 공급 장치와 컨트롤러가 포함되어 있으며 전반적으로 판금보다 조금 더 크지만, 경우에 따라 추가 보호가 필요할 수 있습니다. 예를 들어, 한 NetApp 고객은 자동차 테스트에 사용되는 모바일 실시간 분석 플랫폼용 SyncMirror를 구축했습니다. 시스템은 독립적인 UPS 시스템의 독립적인 전원 공급으로 공급되는 두 개의 물리적 랙으로 분리되었습니다.

체크섬에 대한 주제는 Oracle RMAN 스트리밍 백업을 사용하는 데 익숙한 DBA가 스냅샷 기반 백업으로 마이그레이션하는 데 특히 유용합니다. RMAN은 백업 운영 중에 무결성 점검을 수행하는 기능을 가지고 있습니다. 이것이 유용하기는 하지만 이 기능의 주요 이점은 최신 스토리지 어레이에 사용되지 않는 데이터베이스를 위한 것입니다. Oracle 데이터베이스에 물리적 드라이브를 사용할 때 드라이브가 노후하면 결국 손상이 발생할 확률이 매우 높아지는데, 이 문제는 진정한 스토리지 어레이에서 어레이 기반 체크섬을 통해 해결됩니다.

진정한 스토리지 어레이는 여러 레벨에서 체크섬을 사용하여 데이터 무결성을 보호합니다. IP 기반 네트워크에서 데이터가 손상된 경우 TCP(Transmission Control Protocol) 계층은 패킷 데이터를 거부하고 재전송을 요청합니다. FC 프로토콜은 캡슐화된 SCSI 데이터처럼 체크섬을 포함하고 있습니다. 이것이 어레이에 배치되면 ONTAP에서 RAID 및 체크섬 보호 기능을 수행할 수 있습니다. 대부분의 엔터프라이즈 어레이에서 그렇듯 손상이 발생할 수도 있지만 감지하여 수정할 수 있습니다. 일반적으로 전체 드라이브에 장애가 발생하면 RAID 리빌드가 신속하게 이뤄지며 데이터베이스 무결성은 영향을 받지 않습니다. ONTAP가 드라이브의 데이터가 손상되었음을 의미하는 체크섬 오류를 감지하는 경우가 간혹 있습니다. 그러면 드라이브 작동이 중단되고 RAID 리빌드가 시작됩니다. 여기서도 데이터 무결성은 영향을 받지 않습니다.

또한, Oracle 데이터 파일 및 재실행 로그 아키텍처는 극단적인 환경에서도 최고 수준의 데이터 무결성을 제공하도록 설계되었습니다. 가장 기본적인 레벨에서 Oracle 블록은 거의 모든 I/O에 관한 체크섬과 기본 논리 점검을 포함합니다 Oracle이 충돌하거나 테이블스페이스를 오프라인으로 전환하지 않았다면 데이터는 온전한 상태입니다. 데이터 무결성 점검의 수준은 조정할 수 있으며 쓰기를 확인하도록 Oracle을 구성할 수도 있습니다. 결과적으로 거의 모든 충돌 및 장애 시나리오가 복구될 수 있으며, 극도로 드물긴 하나 복구가 불가능한 상황에서는 손상이 즉시 감지됩니다.

Oracle 데이터베이스를 사용하는 대부분의 NetApp 고객은 스냅샷 기반 백업으로 마이그레이션한 후에 RMAN 및 기타 백업 제품의 사용을 중단합니다. SnapCenter를 통한 블록 레벨 복구를 수행하기 위해 RMAN을 사용할 수 있는 옵션이 여전히 있습니다. 하지만, 일별 기준으로 보면 RMAN, NetBackup 및 기타 제품은 월별 또는 분기별 아카이빙 복사본을 생성하기 위해 가끔씩만 사용됩니다.

어떤 고객은 실행을 선택합니다 dbv 정기적으로 기존 데이터베이스에 대한 무결성 검사를 수행합니다. 하지만 NetApp에서는 불필요한 I/O 로드가 생성되기 때문에 이 방식은 권장되지 않습니다. 위에서 설명한 바와 같이 데이터베이스에 이전에 문제가 발생하지 않았다면 의 가능성이 높습니다 dbv 문제를 감지하는 것은 거의 0에 가까우며, 이 유틸리티는 네트워크 및 스토리지 시스템에 매우 높은 순차 I/O 로드를 생성합니다. 알려진 Oracle 버그에 관한 노출 같은 손상이 존재한다고 판단할 근거가 있지 않는 한 를 실행할 이유는 없습니다 dbv.