HDD Disk 장애 분석
sata, sas, ssd, nvme ,raid 구성 장애 대응 가이드
1-1 : Disk 종류 소개
1-2 : Disk 장애의 유형
1-3 : badsector? correlated? uncorrelated?
1-4 : 배드섹터가 걱정 되면 레이드 구성 하면 해결?
1-5 : smartctl 로 디스크 상태 확인
1-6 : Nand disk 상태 확인
1-1 Disk 종류 소개
※ 여기서는 리눅스 서버용 디스크 위주의 글로 소개 합니다.
- 저장 장치의 발전 과정
서버용 저장장치는 과거부터 IDE => SCSI => SATA => SAS => SSD => NVME => Optane, Z-ssd => NVRAM 기반 스토리지 순서로 발전해 가고 있습니다.
CPU, Memory 등의 발전은 매우 빠르게 진행되지만 그에 반해 저장장치는 발전 속도가 많이 더딥니다.
저장 장치의 목적은 말 그대로 휘발성 DRAM을 통해 저장 목적으로 쓰이는 장치 입니다.
저장 장치의 성능을 위해 Disk 내부 구조 즉 플래터기반 => Nand flash 기반 => 3D XPoint, phase-change 등의 Nand 의 단점을 보안한 메모리 기술 등으로 변하고 있고,
저장장치의 통신을 위한 인터페이스에 대한 변화도 발전 하고 있다. (IDE => SATA => SCSI => SAS => PCI => memory direct 등)
해당 브런치에선 서버운영시 위와 같이 다양한 저장장치의 서버를 경험하게 되며, 인프라 운영에 있어 저장장치의 문제 및 장애에 대한 대응 방법을 설명 한다.
1-2 Disk 장애의 유형
- 저장장치의 레벨 즉 Disk 레벨에서의 장애는 크게 아래와 같이 2가지로 구분 된다.
(1) 디스크 인식 불가 : 디스크 내부의 기계적, 전자적인 결함으로 인한 디스크 인식 불가 상황.
+ Disk 컨트롤러, 펌웨어, 전원 불량, 케이블 또는 접촉단자 불량, 메타데이터 영역 손상 시 인식 되지 않는다.
+ (스핀들 디스크 기준) 인식 불가의 가장 높은 원인은 물리적 배드섹터 발생 후 계속 증가하면서 메타데이터 영역 섹터를 포함 대부분의 섹터가 인식이 안될 경우 발생 한다.
+ (nand 디스크 기준) 컨트롤러 불량이 대부분 이며, 벤더사 마다 틀리지만 전원(power) 불균형으로 인한 데이터 보호를 위해 자체적으로 안전모드라 불리는 데이터 영역을 강제로 rock 걸어 버리는 현상.
(2) 배드섹터 : 실제 운영 시 가능 빈번하고 문제가 되는 게 배드섹터로 인한 장애 입니다.
+ 배드섹터란 data 가 저장된 sector 영역에 read/write 가 불가능한 상태를 말 합니다.
+ 실제 운영에는 문제가 없는 거 처럼 느껴집니다. 배드섹터가 적을 경우 해당 sector 영역을 read/write 하는 경우의 수가 적고, 혹시가 접근 하더라도 서버가 죽거나 하진 않습니다. (io가 느려지면서 결국 read/write 실패로 끝남)
+ 물리적 배트섹터 (아래 1-3에서 자세히 소개)가 발생하면 이 배드섹터 카운트는 계속 증가 할수 있습니다.
++ ex1) 스핀들 Disk 내부에 먼지 또는 기계적 결함으로 고속으로 회전하는 플레터에 마모를 주게 되는 현상.
++ ex2) 물리적/전기적 충격으로 특정 구간의 플레터/Nand Cell 손상 되는 경우
++ ex3) 스핀들 Disk펌웨어 결함(알고리즘)으로 인한 원인 등
++ ex4) Nand(ssd, nvme) 의 경우 주로 Cell 수명이 다 된 경우이며, 그 외 Wear Leveling 알고리즘 또는 펌웨어 결함으로 특정 셀에 write 부하가 걸려 배드섹터로 이어짐.
1-3 badsector? correlated? uncorrelated?
스핀들 디스크 내부 구조(1) 배드섹터?
배드섹터 즉 data을 저장 하는 최소단위로 스핀들 디스크에선 sector 이고, Nand 제품에선 Cell 이라고 한다.
이 data을 저장 하는 최소 구역에 read/write 가 안되어 해당 구역을 접근 못하는 상황을 흔히 배드 섹터라 한다.
정확한 표현은 uncorrelated error 이다.
disk 는 sector(스핀들) / Page(nand) 단위로 ECC (Error Correcting Code) 영역을 둔다.
ecc는 data가 write 될때 생성되어 스페어 영역(sector/page 스페어영역을 말함)에 패리티 비트를 계산해 저장 한다. 해당 영역에 read 발생시 data 영역을 읽은 후 ecc 패리티까지 write 할때와 맞는지 검증 하게 된다.
이 과정에서 패리티가 틀린 경우 자동보정 (1bit 까지)이 가능하다.
이렇게 1bit 패리티 에러를 correlated error (싱글비트 에러)라고 하며 이는 ECC 로 보정 가능하다.
만약 1bit 이상 즉 2bit (멀티비트 에러) 이상 보정은 불가 하며 이를 uncorrelated error 즉 보정 불가 (배드섹터) 라고 한다.
uncorrelated error 가 발생하면 Disk 펌웨어 레벨에선 해당 구역을 repair (reassign, remap) 즉 다른 정상 적인 sector 로 치환 하며 배드섹터 영역은 fail 구획으로 마킹 (컨트롤러,메타데이터 영역에 해당 섹터 넘버로 fail 상태로 마킹해 해당 섹터로 접근을 하지 않도록 구현) 하여 처리 한다.
uncorrelated error sector data 는 손실 (복구불가) 되는 것 이다.
참고로 스핀들/Nand 모두 제조과정에서 플래터/Cell 에 일부 손실이 있을 수 있다. 이런 경우 제조과정에서 해당 영역을 fail 구획으로 마킹하고 스페어 영역으로 대체 하기에 사용자 입장에선 뽑기운? 이라 해야 하나... 알수가 없다.
※ 그럼 왜? 배드섹터가 발생 하는 건가요?
배드섹터는 보통 논리적/물리적 배드섹터로 구분 한다.
논리적 배드섹터는 OS 또는 S/W 상 read/write 시에 문제로 발생한 uncorrelated error 이다.
이 경우엔 OS 상에서 배드섹터 영역 검출 및 복구가 가능 하다.
물리적 배드섹터는 말 그대로 물리적인 결함으로 발생 하는 상황 이다.
여러가지 원인 (disk 내부 먼지, 회전수 부족, 물리적 충격, 펌웨어 결함, 전원튐 등등)의 원인으로 플래터에 손상이 가는 경우가 있으며 이런 경우 손상된 영역의 data 는 손실 된다. (복구전문 업체에선~ 가능하다.)
위 그림 처럼 섹터를 나누는 구획 (Intertrace Gap)이 자기적 변화로 인해 틀어지는 경우도 있으나 이 경우는 물리적 손상? 케이스는 아니라서 흔히 말하는 로우 포멧 또는 전용 툴 등을 사용해 자기값을 초기화 하여 복구 할 수 있다.
1-4 배드섹터가 걱정 되면 레이드 구성 하면 해결?
- Raid 구성은 보통 data 의 이중화 즉 디스크 장애가 나더라도 데이터를 보존 하기 위한 목적으로 주로 사용 됩니다. Raid 란 완전 무결한 방법은 아닙니다, 최소한의 데이터 보존을 위한 장치 입니다.
보통 Raid 는 복제(미러링, Raid1) 또는 패리티를 두어 이중화 (Raid 5,6) 하여 운영 하고 일부 디스크 장애시 데이터를 자동으로 복구 할수 있습니다.
여기서 조건이 붙습니다. Raid Card 에서 디스크가 문제가 생겼을때 이를 장애로 인지하고 해당 디스크 영역을 Raid 볼륨에서 제외 해야 합니다.
Raid Card 에선 아래와 같은 조건이 부합 하면 디스크를 장애로 인지 하고 처리 합니다.
+ 디스크 인식 불가
+ 특정시간 (제조사 및 모델마다 다름) 동안 read/write 응답이 없어 Timeout 이 일정수 쌓을 때
+ 디스크 인식 연결이 붙었다 끊어졌다 (일정 시간 동안 몇회 이상 발생) 시
+ negotiation 불량 : 전원 인가 후 부팅시 Raid Card <==> MainBoard 간에 인터페이스 속도 (1.5Gbps ~ 12Gbps) 규약 및 디스크상태 확인 및 활성화 등의 과정이 제대로 진행이 안될 때
그럼 예를 들어... Disk 2개를 Raid 1 미러링 구성 환경에서, A 와 B 디스크 중 A 디스크에 배드섹터 1개가 발생 했다고 가정 하겠습니다.
이런 경우 Raid Card 레벨에서 어떻게 복구 할까요?
(제조사 및 모델마다 틀리지만) 보통 저가형 (S/W 레이드 또는 HostRaid (IOC)) 레이드 카드 에선 대부분 배드섹터 감지 및 복구에 대한 기능이 없습니다. 저가형 카드 입장에선 단순히 디스크 인지가 안되거나 A또는 B디스크에 이미 배드섹터가 많이 쌓여 timeout이 빈번 할때 장애로 인지 합니다.
예를 들어 5년 동안 미러링 된 서버를 운영 중이였는데, 어느날 보니 A디스크에는 배드섹터가 100개 B디스크에는 10개가 발생 되어 있었고, 이 후 A디스크를 교체 해게 되면 어떻게 될까요?
교체 된 A디스크는 B디스크와 리빌딩 과정에서 B디스크에 발생한 배드섹터 영역까지 리빌딩을 시도 합니다.
이렇게 되면 리빌딩 완료 후 A디스크에 배드섹터 카운트가 (새 디스크인데 레이드 리빌딩만 했음에도) 쌓입니다. 그리고 해당 섹터는 물리적 배드섹터가 아닌 논리적 배드섹터가 되고, 실제 해당 섹터의 데이터는 손실 된 것 입니다.
운이 안좋은 경우 B디스크에 메타데이터 영역에 배드섹터가 있었을 경우 (교체전 A디스크의 메타데이터 영역은 정상) 부팅 자체가 안 됩니다.
그럼 고가 (DRAM 캐쉬가 달린)의 레이드 카드에선 어떻게 처리 할까요?
일단... 저가형과 동일 합니다. 단 고가의 카드의 경우 Consistency error check 기능을 사용해 주기적으로 디스크에 대한 정상 검사를 진행 한다. 이 과정에서 디스크 문제 즉 배드섹터도 검출되어 레이드 카드 레벨에서문제 된 영역을 Spot Rebuilding 이라해서 배드섹터 즉 문제된 영역을 fail로 마킹하고, 같은 데이터가 있는 정상적인 디스크에서 해당 데이터를 가져와 새로운 데이터 영역으로 복제 하는 과정을 거친다.
아주 좋은 기능이다... 하지만 Consistency error check 가 돌아가는 동안은 그 만큼 ioutil 이 올라간다.
DB 나 io를 평소에 많이 쓰는 서비스에선 해당 기능이 돌 때마다 서비스 지장 또는 리소스 부족으로 더 복잡한 상황이 올수 있어서 대부분 해당 기능을 off 해서 사용 한다.
최근엔 고가 카드에선 Consistency error check 가 돌지 않고 컨트롤러 레벨에서 배드섹터가 리포팅 되면 Spot Rebuilding 돈다고 한다. 하지만 모든 배드섹터가 Consistency error check 또는 log 리포팅이 되지 않는 경우도 있으니 주의 해야 한다.
중요한 건 레이드 구성에서도 배드섹터난 데이터가 다른 디스크에 복제가 가능한 상황이 아니라면 어쩃든 해당 영역의 데이터는 손실 된다. (특히 패리티 복구를 하는 Raid 5)
레이드 카드의 기능은 아주 많고 (보통 퍼포먼스 위주의 옵션) 데이터 안정성도 좋지만, 결국엔 배드섹터가 쌓이고 이를 빨리 조치 하지 않으면 결국 복구 불가한 장애로 이어 질 수 있습니다. 항상 Raid Card, Kernel message, ioutil 리소스 모니터링을 통해 io에 의심되는 항목을 모니터링을 해야 합니다.
추가로 디스크에 read/write 배드섹터 카운트가 있을 경우 이게 논리적/물리적 배드섹터인지 판단 할 수 없습니다.
이런 경우 OS에 배드섹터 체크/복구 툴을 통해 복구 가능한 섹터를 논리적 배드섹터 수로 보고 나머지를 배드섹터 카운트를 물리적 배드섹터로 보시면 됩니다. S.M.A.R.T 지표에 쌓인 각종 정보 (배드섹터 카운트 포함) reset이 안됩니다. 벤더사 레벨에서 전용 툴과 장비를 통해서만 가능 하다고 하니 참고 하세요.
1-5 smartctl 로 디스크 상태 확인
HDD (스핀들 디스크 sata, sas)
===========================================================
sata, sas 디스크 분석 방법, 레이드 카드가 달리고 sata인 경우 sat+ 옵션 필요1. 레이드 카드가 장착된 모델과 그렇지 아닌 모델은 smartctl 옵션이 자체가 바뀐다.
ㄱ. 레이드카드(R/C) 없는 모델
- ex] smartctl -a /dev/sda or smartctl -a /dev/sg0 (prco 밑에서 확인 가능, dell 210의 경우 /dev/sg1과 sg2)
ㄴ. 레이드카드(R/C) 장착된 모델
- sas ] smartctl -d megaraid,00 -a /dev/sda
- sata] smartctl -d sat+megaraid,00 -a /dev/sda
+ sata의 경우 -d 옵션 뒤에 sat+ 옵션을 붙여야 한다. megaraid 뒤에 00 <- 이건 디스크 순서 넘버이고, LSI와 같은 경우 아래와 같은 커멘드로 알 수 있다. -a 뒤에 디바이스는 명은 R/C 달린 상태에선 의미 없다.
MegaCli64 -LDPDInfo -aALL | grep "Device Id"
ㄷ, smartctl 결과가 제대로 안 나오는 경우, 옵션을 제대로 넣었는가? smartmontools 버전이 낮은가? 그 외 smart 옵션이 꺼진 상태, (smartctl --smart=on --offlineauto=on --saveauto=on /dev/sda로 활성화)인지 체크를 하기 바란다.
ㄹ. sata의 경우와 sas의 경우 로그 결과 값이 틀리다, 아래와 같이 장애 유무를 확인해서 결정해보자!!!
표 1-1 SATA
1 Raw_Read_Error_Rate - 디스크 Raw단에서 디스크를 읽는 과정에서 문제가 생김 (주로 물리적인 충격으로 발생)
5 Reallocated_Sector_Ct - 섹터에 문제가 생겨서 스페어 영역의 섹터로 대체한 횟수
7 Seek_Error_Rate - 탐색 오류
10 Spin_Retry_Count - 최대 rpm에 도달하기 위해 회전을 시도하는 횟수 (정상이라면 1번에 끝나야 한다.)
197 Current_Pending_Sector - 불안정적인 섹터로 스페어 영역 섹터로 remap을 준비 중이거나 읽는 과정에 문제가 생김 (medium error)
198 Offline_Uncorrectable - read/write 에 문제가 생긴 색터, 즉 디스크 표면이 손상됨 (bad sector)
199 UDMA_CRC_Error_Count - 디스크 인터페이스를 통해 데이터 전송 과정에 발생한 CEC 오류 횟수
190 Airflow_Temperature_Cel - 디스크 온도 부분이다. 이게 비정상적으로 높은 경우가 있다. 100C를 넘는... 이럴 경우 빨리 교체해야 한다. 보통 디스크 물리적인 문제로 발생하고, 디스크 장애로 이어지지 않고 미디엄 에러나 또는 정상인데 스핀들에 문제로 온도만 높아지며, 실제 io에 문제가 되는 경우가 있다.
간혹 실제로 디스크를 뻇는데 뜨겁지 않은 경우도 있다. 이런 경우 S.M.A.R.T 센서 오작동 + 디스크 상태가 이상하니 그냥 교체한다.
온도 문제로 io가 간헐적으로 정상 처리를 못함.- 이 외에도 정상적인 디스크와 출력 화면을 비교해 보면 마지막 부분에 이상한? 로그가 여러 개 찍혀 나온다. 실제 에러 디테일 로그...
위 에러 코드 중 카운터가 주로 5, 197, 198 많이 발생하는데 교체를 진행해야 함.
197번의 경우 카운터가 발생하는 순간 CDB error (섹터를 찾는데 실패함) 발생하면서 io time out 이 난다. 즉 렌덤 하게 (1~10초) 사이 동안 디스크에 read write 가 안된다.
<raw value 값이 어떻게 계산되는지 사실 궁금하신 분들은 아래 매뉴얼 참고(영어임), 추가로 시게이트는 sata, sas 모두 다른 벤더와 틀린지표로 표시된다. 이 이유도 있음>
표1-1 SAS
0. 1번 항목 왼쪽. fast는 빠르게 ECC를 복구한 횟수, delayed는 복구는 했는데 시간이 꽤 걸린 것 (시게이트는 해당 항목 카운터가 되지만, 타 벤더 WD 등은 해당 카운터를 일부러 off 한다 함)
+ 디스크 벤더 사별로 smart로 뿌려주는 표준이 틀릴 수 있음을 인지 해야 한다.
1. Reread/Rewrites(Sagate parameter code:0002h)
> 최초의 Read / Write 수행에서 완전히 수행하지 못해 해당 Command에 대해 재시도를 하여 성공한 횟수.
하나의 Command에 대해 여러 번의 재시도가 있더라도 수행에 성공하면 1회 Count.
2. Total errors corrected (Sagate parameter code:0003h)
> Corrected by ECC(Fast&Delayed), Reread/Rewrite의 총합
3. Correction algorithm invocations (Sagate parameter code:0004h)
> Error recovery algorithm이 적용된 Error correction 횟수.
실패한 경우에도 Count 증가되며 Error correction에 실패한 경우 #5(Total uncorrected errors)의 Count도 증가
4. Gigabytesprocessed (Sagate parameter code:0005h)
> 앞에 열거된 모든 Error correction 방법들이 시도된 총 용량(Read+Write).
Error correction 성공 여부와 관계없이 Count.
5. Total uncorrected erros(요것만 보면 됨) (Sagate parameter code:0006h)
> 앞에 열거된 Error correction 방법들로 Correction이 성공되지 않은 Error의 수
0번 항목에 delayed 카운터가 발생할 때 disk io가 순간 폭증한다. (서비스에 문제가 되면 교체를 진행하는 게 좋겠다.)
1, 5번 항목에 카운터가 발생하면 교체를 진행한다.
<5번항목 이외의 값은 디스크 벤더사마다 다르다. 지표로 판단하기엔 신뢰가 가지 않으니 난 5번만 본다.>
SSD
===========================================================
- 붉게 표시된 근 스핀들 디스크 (HDD)에서 크리티컬 한 값이며, 파란 박스는 intel ssd의 경우 크리티컬 한 값이다. ID : 05는 데드 셀로 해당 블록이 마킹되어(블록 단위로 작업하기 때문에...) 더 이상 쓰지 않고, OP영역 (오버 프로비저닝) 영역에서 대체한다. 해당 셀에 있던 데이터가 다른 셀로 안전하게 백업이 됐는지 확인할 방법은 없다. (FTL를 통해 이동됐을 수도... data 손실이 됐을 수도...) 사실 ID : 05 보다 232, 233 정보가 더 중요하다, 셀의 마모도와 수명을 판단하는 지표이기 때문.
05, 232, 233 모두 수치가 안 좋다면 잦은 튀는 현상(low 레이턴시)과 장애로 이어질 가능성이 높다.
(발췌) http://dayccm.tistory.com/80
<Intel SSD smartctl 값>
ID값은 16진수로 표시됐으며, 10진수로 변경해서 smartctl 값과 매칭 시킨다.ex)
ATTRIBUTE_NAME OS 및 smartctl 버전별로 틀리니 ID#으로만 분류 하자!- SSD 수명 계산 확인 방법
Nand 제품은 write 또는 delete 시 셀에 전원을 인가하여 전자를 이동하는 방식이라, 전자를 흐름을 막아주는 산화막은 수명이 있다. 즉 수명을 다하면 더 이상 write, delete 가 안되거나 매우 느려진다. ( 1MB/s 이하) read에는 문제가 없다.
+ smartctl -a /dev/디바이스명으로 값 추출
+ (ID# 226) : Timed Workload Media Wear Indicator 항목 (Intel 제품만 해당)
새 디스크면 해당 항목이 0부터 시작해서 102400 (max)까지 표시된다. 102400 이면 수명 다함.
++ 계산식 : (ID# 226) RAW_VALUE / 1024 (ex) 22732/1024 = 22.19% (즉 셀 수명이 78% 정도 남음)
+ (ID# 177) : Wear Leveling Count 항목 (Intel & Samsung 공통 해당)
100%부터 시작해 점점 줄어든다. 해당 값이 1% 이하 일 경우 수명을 다 했다고 보면 된다. 셀의 산화막 수명이 남은 비율로 보면 될 거 같다.
인텔의 경우 Intel (ID# 233 Media_Wearout_Indicator) 요 지표를 보자.
+ (ID# 241) : Total_LBAs_Written 항목 (ID# 225 intel)과 동일. (Intel & Samsung 공통 해당)
총 write 사용량 지표.
1. 가지고 있는 SSD의 수명을 확인한다. (수명 용어 설명은 첫 페이지에 있다.)
보유하신 SSD의 DWPD 나 수명 지표는 구글링으로 확인 하자. (ex. 보통 5년 기준 0.8 DWPD 등으로 표시되거나 180 TBW 이런 식으로 총 write 한계치가 표시되기도 한다.)
2. 아래 계산식을 대입해 현재 사용한 [총 수명 write 용량 - 사용한 write 용량]을 계산해 얼마큼 더 write 수명이 남았는지 산출한다.
+ intel ssd 계산식 : (ID# 241) RAW_VALUE x 65535 x 512 / 1,000,000,000
(ex) 9674359 x 65535 x 512 / 1,000,000,000 = 324,612GB 을 사용했다.
+ samsung ssd 계산식 (ID# 241) RAW_VALUE x 512 / 1,000,000,000 으로 계산. (intel 과 다르게 65535 곱하는 항목이 없다.)
[
1,000,000,000 => GB 계산하기 위해 표현하기 간단하게 써 놓은 것이며 정확히는 아래와 같이 대입한다.
1GB는 1000MB 아니라... 정확히는 1024MB이다.
현재까지 사용한 write 용량을 정확한 GB/TB 단위로 보려면 1,000,000,000 이 아닌 아래 수치를 대입해서 나누면 된다.
GB = 1024^3 = 1,073,741,824
TB = 1024^4 = 1,099,511,627,776
]
samsung 제품의 write 사용량을 확인하는 계산식 사이트도 있으니 참고 바람.
http://www.virten.net/2016/12/ssd-total-bytes-written-calculator/
intel 제품의 수명 및 성능 계산 페이지
https://estimator.intel.com/ssdendurance/
+ smartctl로 한 번에 수명 계산 지표 뽑아 보기. (hex 코드로 Total LBA write 값을 추출하여 계산)
삼성제품 :
smartctl -s on -i -A -f brief -f hex,id -l devstat /dev/디바이스명 | grep 0xf1 | awk '{printf "%dGB\n", $8 / 1953125 }' ## 1953125 == 1,000,000,000 / 512
인텔 제품 :
smartctl -s on -i -A -f brief -f hex,id -l devstat /dev/디바이스명 | grep 0xf1 | awk '{printf "%dGB\n", $8 / 29.8}' ## 29.8 == 1,000,000,000 / 65535 x 512
=> xx GB (write 했다. 즉 디스크 총수명에 해당 용량을 빼면 유추 가능하다.)
1124831분 (228번 항목) 동안 운영했으며, read/write 작업 비율이 37% (227번 항목)의 read와 63%의 write 작업을 했다. (225번 항목 x 65535 x 512 / 1,000,000,000) 324,612 GB의 write 작업이 있었으며,
셀 마모도는 22% 사용하여 앞으로 78%는 더 쓸 수 있다.
<첨언> 2년 전 같은 날 intel ssd로 들어가 서버들이 같은 날 디스크 문제가 발생했고, 확인 해 보니, 셀이 수명을 다 했다. smartctl로 ID#233 번의 VALUE 값이 1이고, ID#226 번 값이 102400 이면... 셀 수명을 다 한 것이다.
smartctl 외에 intel에서 제공하는 isdct 데이터센터 툴로도 확인 가능하다. 좀 더 상세하고 많은 기능을 볼 수 있다.
smartctl와 같이 사용하면 좋다.
ex) isdct show -a -intelssd
<Samsung SSD smartctl 값>
ex) magician 결과
아래는 smartctl 결과 (삼성 전용 툴보단 항목 값이 지원이 안된다.)
참고로 magician 은 삼성에서 제공하는 유틸이며 아래 site에서 다운로드 가능하다.
http://www.samsung.com/semiconductor/minisite/ssd/download/tools.htmlㅇ
linux에서 magician 실행 시 device가 보이지 않는다면 updatedb 한번 때려 주고 한다~
NVME
===========================================================
SSD와 비슷하나 헬스 체크 툴이 틀리다. 보통 벤더사마다 유틸로 제공 하나, 공통된 오픈 소스로 nvme cli라는 툴을 이용해 보자. 추가로 smartctl 6.5 버전부터는 nvme cli 가 설치되면 smartctl로도 체킹 가능하다.
nvme cli 다운로드 : https://github.com/linux-nvme/nvme-cli
smactctl 최신 버전 다운로드 : https://www.smartmontools.org
1. nvme cli 사용 방법 (주로 쓰는 커멘드)
- nvme list
+ 현재 장착된 nvme에 대한 정보를 출력한다.
+ 사용 중 용량은 일부 벤더에선 full로 표시된다. (intel 등) 정확한 의미는 Identify Namespace Data Structure 중 Namespace Utilization (NUSE) 값.
- nvme smart-log /dev/드라이브지정
+ available_spare : bad block이 발생했을 때 교체해주기 위한 스페어 영역. 벤더사마다 틀리지만 over Provisioning 영역일 수 있다. 암튼 이게 availble_spare_threshold 값이 10% 이하로 떨어지면 그만큼 bad block 또는 dead cell일 많아졌다는 뜻으로 장애로 이어진다.
+ percentage_used : Erase(지우기)/Program(쓰기) cycle이 수없이 반복되면 절연막이 Wear-out(더 이상 사용 못하는 셀) 되며, NAND가 MAX Erase(지우기)/Program(쓰기) 수명 대비 몇 %사용 한 것인지 표시해주는 직관적인 항목이며, 사용량에 비례하여 증가한다. 100% 이상되면 수명이 거의 다 했다고 보면 된다.
0~100% 사이는 퍼포먼스에 영향을 주지 않는다고 한다.
+ controller_busy_time : 말 그대로 nvme가 제대로 처리? 못한 시간을 뜻하는데, nvme dirty 상태가 되거나 뭔가 io가 빠르게 처리 안될 때 해당 지표를 기준으로 정상 제품과 비교하는 척도가 될 것이다.
+ unsafe_shutdowns : nvme에 비정상적인 종료가 있던 횟수이다. 리붓 또는 셧다운 시 nand에 전기적인 신호에 문제가 될 수 있고 일부 벤더에선 안전모드(nand 보호를 위한 rock기능)로 빠질 수 있다.
+ media_errors : 배드 섹터 감지 횟수
위 이벤트는 아래 매뉴얼을 참고하셔서 디테일하게 확인 가능합니다.
2. smartctl -a /dev/드라이브지정 : 위와 같은 nvme smart-log 기반으로 smartctl로도 출력된다.
3. 그 외 nvme 포맷이나, 수동으로 over Provisioning 등 기능을 지원한다. 인텔 같은 경우 isdct 툴을 이용하면 좀 더 직관적이고 다양한 기능을 쓸 수 있다. (isdct의 경우 글로벌 제품만 가능하며, Dell HP 등 벤더 써티 된 제품은 안 먹는다~)
* host, nand written 크기 계산 방법
- 아래 3가지 값은 모두 동일한 의미이며, 단위의 차이이지 같은 수치로 표기된다.
+ nvme intel smart-log-add /dev/nvme0 으로 나오는 [ host_bytes_written ]
==> sectors : 수치 - 이건 섹터 하나당 32MiB 이다. [ 수치 * 32 (32MiB) * 1048580 (1MiB를 바이트로 환산) ] 로 계산하면 실제 written 한 byte 수치가 나옴.
+ nvme smart-log /dev/nvme0 으로 나오는 [ data_units_written ]
==> 해당 수치 값은 [ 수치 * 1000 unit * 512 Bytes ]로 계산
+ isdct show -smart -intelssd 0으로 나오는 [ Host Bytes Written ]
==> 해당 수치는 실제 wrtten 한 Byte 크기이다. 계산 방식의 차이이지 동일한 값이 추출된다.
* WAF (쓰기 증폭) : 해당 지표는 예를 들어 Nand에서 1MB write을 위해 실제 Nand 에선 얼마의 write job 이 발생했는지에 대한 지표입니다.
1MB write 시 실제 Nand 도 1MB write 만 했다면 해당 지표는 WAF=1 (가장 이상적) 이 됩니다. 해당 지표가 높다면 그만큼 퍼포먼스 및 성능이 줄어듭니다.
만약 1MB write 시 실제 Nand는 1.5MB write를 했으면 WAF=1.5 입니다.
+ WAF 계산 방법 : (플래시 메모리에 기록된 데이터 / 호스트가 기록한 데이터 = WAF)
++ nvme intel smart-log-add /dev/nvme0
==> ( nand_bytes_written / host_bytes_written = WAF)
++ isdct show -smart -intelssd 0
==> ( NAND Bytes Written (F4수치) / Host Bytes Written (F5 수치) = WAF
