[OSTEP] CH45 데이터 무결성과 보호 + CH46 대화

찍먹스터디 마지막 발표 😭😭😭 24.12.13 FRI 10시a.m. 

 

CH45 데이터 무결성과 보호 

저장 시스템에서 데이터를 읽었을 때 그 데이터가 처음에 썼던 것과 동일하다는 것을 보장하는 기술을

데이터 무결성 또는 데이터 보호라고 부른다 

핵심 질문 - 데이터 무결성을 어떻게 보장하는가 
저장 장치에 쓴 데이터가 보호되고 있다는 것을 시스템을 어떻게 보장할까? 어떤 기술들이 필요할까? 어떻게 하면 그 기술들을 공간과 시간 오버헤드가 적으면서 효율적으로 만들 수 있을까? 

45.1 디스크 오류 모델 

초기 RAID 시스템에서는 디스크의 실패-시-멈춤 Fail-Stop 모델 덕분?때문?에 오류 모델이 간단한 편이었다  

디스크 전체가 동작하던가, 또는 완전히 불능이었기 때문에 그러한 오류를 단순하게 판단할 수 있었다 

현대의 디스크들은 정상적으로 동작하는 것처럼 보이지만 블럭들을 읽는 데 실패하는 경우가 발생하며 

그 중에 단일-블럭 오류인 숨어있는 섹터 에러 Latent Sector Error 와 블럭 손상 Block Corruption 가 있다 

 

LSE 는 디스크 섹터 (또는 섹터 그룹) 가 어떤 이유로든 손상되었을 때 발생한다 (ex, 헤드 크래시 Head Crash, 강한 방사선) 

디스크 내의 에러 정정 코드 Error Correcting Codes, ECC 를 사용하여 디스크 상에 있는 블럭의 비트가 괜찮은지 판단하고 고치기도 한다, 고칠 수 있는 방안이 없는 경우에 해당 비트를 읽는 요청을 받으면 디스크는 에러를 리턴한다 

디스크가 손상 여부를 인식할 수 없게 내용이 손상 Corrupt 된 경우에 해당 블럭의 내용은 읽혀지지만 잘못된 블럭이 리턴된다 

이러한 조용한 오류 Silent Fault 는 오류가 있는 데이터를 리턴함에도 불구하고, 디스크는 문제를 전혀 알리지 않는다 

이런 부분-실패 Fail-Partial 디스크 오류 모델은 고전적인 Fail-Stop 모델과 동일하게 전체적으로는 불량이라고 볼 수 있지만, 디스크가 동작하는 것처럼 보인다, 가끔 주어진 블럭을 읽거나 쓸 때 에러를 리턴할 수 있으며 (조용하지 않은 부분 오류) 가끔 잘못된 데이터를 리턴할 수 있다 (조용한 부분 오류) 

LSE 에 대해 발견된 현상 

하나 이상의 LSE를 갖고 있는 고가의 드라이브들은 저가의 드라이브들처럼 추가적인 에러를 만들어낸다 
대부분의 드라이브들의 연간 에러율은 둘째 해에 증가한다 
LSB 는 디스크의 크기에 비례하여 증가한다 
LSE 를 갖고 있는 대부분의 디스크는 50개 미만의 LSE를 갖고 있다 
LSE 를 갖고 있는 디스크들은 추가적인 LSE를 만들어낼 확률이 있다 
공간과 시간 지역성이 상당히 두드러진다 
디스크를 지우는 것이 유용하다 (이것으로 대부분의 LSE를 발견할 수 있다)

섹터 손상에 대해서 관찰된 특성 

같은 급의 드라이브들이라고 하더라도 모델에 따라서 손상 확률의 차이가 크다 
사용 연한에 따른 영향은 모델에 따라 다르다 
워크로드와 디스크의 크기는 섹터 손상 빈도에 큰 영향을 미치지 않는다 
섹터 손상이 발생한 대부분의 디스크는 단지 몇 개의 손상된 부분을 갖고 있다 
RAID 로 묶인 디스크들 간이나 하나의 디스크에 있는 손상은 독립적이지 않다 
LSE 와는 연관성이 약하다 

45.2 숨어있는 섹터 에러 Latent Sector Error 

핵심 질문 - 숨어있는 섹터 에러를 어떻게 처리할까
저장 시스템이 숨어있는 섹터 에러들을 어떻게 처리해야 할까?
이런 형태의 부분 오류를 처리하기 위해서는 어떤 추가적인 기술을 필요로 할까?

숨어있는 섹터 에러는 쉽게 발견할 수 있기 때문에 해결이 어렵지 않다, 미러링 RAID 의 경우 사본을 보관하고, 패리티를 기반으로 하는 RAID-4 와 RAID-5 시스템의 경우에는 패리티 그룹 내의 다른 블럭들을 활용하여 해당 블럭을 재생성한다 (중복 기법으로 쉬운 복구 가능)

RAID-4/5 시스템에서 발생할 수 있는 문제 중 하나는 하나의 디스크가 완전히 고장나면서 동시에 다른 디스크에서 LSE 가 발생하는 경우이다, 어떤 디스크가 완전히 고장이 나면 RAID 는 패리티 그룹 내의 모든 다른 디스크들을 읽고 빠진 값을 다시 계산하여 디스크 재구성 Reconstruct 를 시도한다, 하지만 재구성하는 도중에 다른 디스크들 중 하나에서 LSE 를 만나면 재구성이 실패하게 된다 

이 문제를 해결하기 위해 다른 시스템들은 추가적인 기법을 도입할 수 있다, 추가 디스크로 추가적인 패리티 블럭을 구성할 수도 있다 

45.3 손상 검출 - 체크섬

저장 장치 입장에서는 "제대로" 기록을 했기 때문에, 손상된 블럭을 찾아내는 것은 매우 어려운 일이다 

핵심 질문 - 어떻게 데이터가 손상이 되어도 무결성을 유지할까 
오류의 침묵적인 특성을 고려한다면 손상이 일어났다는 것을 저장 시스템이 검출하기 위해서는 무엇을 해야 할까? 
어떤 기술들이 필요한가? 어떻게 하면 기술들을 효율적으로 구현할 수 있을까? 

손상을 "발견"하는 것이 핵심 문제이다, 잘못을 발견하고 복구를 하기 위해서는 "손상되지 않은" 블럭의 사본이 있어야 한다 

데이터 무결성을 유지하기 위해서 사용하는 주요된 기술을 체크섬 Checksum 이라고 부른다 

체크섬은 데이터 청크를 입력으로 함수 값을 계산한다, 이 결과는 데이터 내용에 대한 작은 요약 정보이다 

체크섬의 목적은 데이터의 손상이나 변경 여부를 시스템이 판단할 수 있도록 하는 것이다, 체크섬을 데이터와 함께 저장하여, 저장된 데이터로부터 계산한 현재의 체크섬이 저장 장치에 기록디어 있는 체크섬 값과 같은지 확인한다 

널리 사용되는 체크섬 함수 

XOR 기반 체크섬은 체크섬을 구하고자 하는 각 데이터 블럭의 청크를 XOR 연산하여 

최종적으로는 전체 블럭을 대표하는 XOR 값을 생성한다 

XOR 방식이 합리적이긴 하지만, 체크섬을 계산하는 각 열에서 두 개의 값이 변하면 체크섬은 손상을 검출할 수 없다는 제한점이 있다

 

다른 기본적인 체크섬 함수는 빠르다는 장점을 가지고 있는 덧셈이다 

체크섬을 계산하려면 각 데이터의 청크에 대해서 2의 보수 덧셈을 하고 만약 오버플로우가 발생하면 무시한다 

이 기법은 데이터의 많은 부분이 변경되었어도 변경된 경우 이를 발견할 수 있기는 하지만, 데이터가 쉬프트된 경우에는 발견 못 할 수도 있다 🐣 데이터의 청크 하나라도 변경되면, 덧셈 결과가 달라지고 체크섬 값도 바뀌기 때문에 데이터의 변화를 발견할 수 있다 🐣

 

Fletcher Checksum 은 두 개의 체크 바이트 s1, s2 의 계산이 필요한 비교적 간단한 방법이다 

많은 경우에 동시다발적 에러들을 검출할 수 있다 

Cyclic Redundancy Check, CRC 는 이진 나머지 연산 Modulo Operation 은 상당히 효율적으로 처리를 할 수 있기 때문에 

네트워크 분야에서도 인기가 있다 

 

좋은 체크섬 함수를 선택한다는 것은 충돌의 확률을 최소화하면서 계산은 간단하게 만드는 것을 의미한다 

체크섬의 배치도 

드라이브의 섹터를 520 byte 크기로 포맷하고 8 byte 를 체크섬으로 저장하는 방식이 있고

그러한 기능이 없다면 n 개의 체크섬을 모아서 한 섹터에 저장하고 그 뒤에 해당하는 n 개의 블럭을 배치하는 방식도 있다 

첫번쨰 방식은 블럭을 갱신할 때 한 번의 쓰기만 필요하고, 두번째 방식은 해당 블럭을 포함하는 체크섬 섹터를 읽은 후에 블럭을 새로 계산하고 체크섬 섹터와 새로운 데이터 블럭을 써야 한다 (하나의 읽기와 두 개의 쓰기가 필요하다)

45.4 체크섬의 활용

블럭 D를 읽을 때 파일 시스템 또는 저장 장치 컨트롤러는 디스크에서 저장된 체크섬 Stored Checksum Cs(D) 를 읽는다 

그 후에 해당 블럭 D 로부터 체크섬 값을 계산하고, 이를 계산된 체크섬 Computed Checksum Cc(D) 이라고 한다

저장된 체크섬과 계산된 체크섬을 비교하여 둘이 동일하다면 데이터는 손상이 없는 것이지만 

둘이 다르다면 데이터가 처음 저장된 이후 변경되었다는 것을 의미한다 🐣 체크섬으로 블럭이 손상된 것을 발견했다 🐣 

손상된 블럭의 복사본이 있다면 복사본을 대신 사용하면 되고, 복사본이 없다면 에러를 리턴하는 것 외에는 방법이 없다 

45.5 새로운 문제 - 잘못된 위치에 기록 

디스크에 데이터를 제대로 기록했지만 잘못된 위치에 기록하는 현상을 잘못된 위치에 기록 Misdirected Write 라고 부른다 

핵심 질문 - 잘못된 위치에 기록하는 문제를 어떻게 해결할까
저장 시스템이나 디스크 컨트롤러가 엉뚱한 곳에 쓰기를 어떻게 검출해야 할까? 체크섬에 어떤 기능이 추가되어야 할까?

각 체크섬에 추가적인 정보인 물리적 식별자 Physical Identifier 또는 물리적 ID 를 추가하는 것만으로도 큰 도움이 된다 

체크섬 C(D) 과 디스크 번호와 섹터 번호를 포함하여 저장하면, 사용자는 특정 위치에 정확한 정보가 저장이 되었는지 판단할 수 있다

완벽한 디스크들에서는 전혀 필요 없는 작은 추가 정보이지만, 문제가 발생되면 이 정보가 그 상황을 해결하는 데 큰 도움이 된다 

45.6 마지막 문제 - 기록 작업의 손실

쓰기가 완료되었다고 알리지만 실제로는 저장되지 않은 경우를 기록 작업의 손실 Lost Write 이라고 부른다 

핵심 질문 - 기록 작업의 손실 문제를 어떻게 다룰까 
저장 시스템 또는 디스크 컨트롤러는 기록 작업이 제대로 수행되지 않았을 경우 이를 어떻게 발견할 수 있을까?
체크섬 외에 어떤 다른 기능이 필요할까?

쓰기 검증 Write Verify 또는 쓰기 후 읽기 Read-After-Write 방식으로 쓰기를 수행한 후 즉시 그 값을 다시 읽는 간단한 방식이 있지만, 안 그래도 느린 쓰기 동작을 완료하기 위해 I/O 의 수를 두 배로 늘리는 단점이 있다 

 

Zettabyte File System, ZFS 의 경우 파일 블럭들의 체크섬을 아이노드와 간접 블럭에 저장한다 

쓰기는 손실되었더라도 아이노드 내의 체크섬은 갱신되었을 것이므로, 예전의 데이터와 해당 블럭에 대한 체크섬이 일치하지 않게 된다  

45.7 Scrubbing 

응용 프로그램이 데이터를 읽을 때 체크섬을 검사하긴 하지만, 대부분의 데이터는 거의 접근이 되지 않기 때문에 검사가 안 될 수도 있다 

이 문제를 해결하기 위해서 주기적으로 모든 블럭들을 읽어서 체크섬이 여전히 유효한지 검사하는 디스크 다시 읽기 Disk Scrubbing 방식을 이용하여, 디스크 시스템은 특정 데이터의 모든 사본이 모두 손상되는 확률을 줄일 수 있다 

45.8 체크섬 오버헤드 

체크섬을 사용하는 데 드는 비용은 공간과 시간 두 가지 비용이 존재한다 

첫번째 공간 오버헤드는 디스크 자체 (또는 다른 저장 매체) 상에 체크섬을 저장하기 위한 공간이 필요하며

그에 따라 사용자가 저장할 수 있는 공간이 줄어든다 

두번째 공간 오버헤드는 데이터를 접근할 때 메모리에 데이터와 체크섬을 읽어들일 수 있는 공간, 즉 시스템 메모리가 필요하다는 것이다 

 

시간 오버헤드의 경우, 데이터를 저장할 때 (체크섬 연산) 와 접근할 때 (체크섬을 다시 계산하여 저장된 체크섬과 비교) 각 블럭의 체크섬을 연산해야 한다, CPU 오버헤드를 줄이기 위해 데이터 연산과 데이터 복사를 하나의 연속적인 작업으로 처리할 수 있다 

CPU 오버헤드 외에도 체크섬 기법에 따라 추가적인 I/O 를 유발할 수 있다, 체크섬이 데이터와 구분되어 저장된 경우 (해당 블럭을 접근하기 위한 추가 I/O 필요) 와 백그라운드에서 다시 읽기 Scrubbing 를 수행하는 경우 I/O 가 발생한다 

전자의 경우 설계를 통해 감소시킬 수 있고, 후자의 경우 다시 읽기 수행 시점을 적절히 조절하여 영향을 줄일 수 있다 

45.9 요약 

체크섬은 종류에 따라 서로 다른 종류의 오류를 해결한다 

 

CH46 영속성을 정리하는 대화 

저장 장치에서 데이터를 저장하고, 영속 데이터를 갱신하는 것은 간단해 보여도 사실 매우 복잡하다 

지역성을 고려하는 것은 언제나 유익하다