RAID

여러 디스크를 하나의 장치로 인식하게 하는 방법. 단일 디스크로 만들 수 없는 거대한 스토리지 공간을 확보하거나 속도를 높이거나 하는 데 쓰이고, 특히 내 경우 미러링을 통해 가용성을 높이는 데 이용했다.

미러링의 경우 백업과 개념이 혼동되곤 하는데 작업자가 (실수로라도) 손수 날린 내용에 대해서 복구를 보장하지 않기 때문에 백업이라고 할 수는 없다(고 한다).

구현 방식은 대강 Hardward RAID, Fake RAID, Software RAID로 나눌 수 있다. 하드웨어 방식은 Adaptec 같이 이름만 대면 알 수 있는 브랜드에서 자체 컨트롤러를 심어 외부에서 봤을 때는 디스크 하나로만 보이는 것이다. 물론 그만큼 비싸다. 개인 차원에서 해볼만한 것은 페이크나 소프트웨어인데 전자는 dmraid, 후자는 mdadm를 통해 할 수 있다.

자세한 사항은 https://raid.wiki.kernel.org/index.php/Linux_Raid 참조.

연혁

dmraid

하드웨어 방식은 OS 이전에 처리가 되고, 소프트웨어는 OS 안에서 처리가 되는데, 페이크는 이 중간에서 소프트웨어 방식을 일종의 장치로 인식시키는 처리만 할 뿐이라고 한다.

몇 가지 칩셋을 지원하는데 목록은 다음과 같다.
$ dmraid -l
asr : Adaptec HostRAID ASR (0,1,10)
ddf1 : SNIA DDF1 (0,1,4,5,linear)
hpt37x : Highpoint HPT37X (S,0,1,10,01)
hpt45x : Highpoint HPT45X (S,0,1,10)
isw : Intel Software RAID (0,1)
jmicron : JMicron ATARAID (S,0,1)
lsi : LSI Logic MegaRAID (0,1,10)
nvidia : NVidia RAID (S,0,1,10,5)
pdc : Promise FastTrack (S,0,1,10)
sil : Silicon Image(tm) Medley(tm) (0,1,10)
via : VIA Software RAID (S,0,1,10)
dos : DOS partitions on SW RAIDs

sil680 칩이 달린 PCI 카드로 250GB PATA 디스크 두 개를 mirror 했다. dmraid를 통해 활성화하면 /dev/mapper 아래에 장치가 생기는데 이걸 fdisk 하면 번호가 붙은 장치가 더 생긴 (뒤에 재부팅을 해줘야 인식 된)다. 그걸 mkfs, mount 하면 된다. 이때 개별 디스크도 바로 접근할 수 있다. 혹시나 해서 메인보드의 PATA 케이블에 연결해보았을 때는 장치가 이미 마운트됐거나 사용중이라면서 마운트를 할 수 없었다. dmraid의 흔적을 지우는 옵션에 대한 설명이 어딘가에 있는 걸로 봐서 파일시스템에 모종의 흔적이 남고 이 때문에 개별적으로는 마운트가 안 되었던 게 아닌가 싶다. 혹시 미러가 깨졌을 때는 어떻게 하는가 싶다.

mdadm

shuttle에서 쓰는 장치를 lshw로 확인하면 다음과 같다.
00:05.0 RAID bus controller: Silicon Integrated Systems [SiS] RAID bus controller 180 SATA/PATA [SiS] (rev 01) (prog-if 85)
        Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f459
        Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 23
        I/O ports at e900 [size=8]
        I/O ports at e400 [size=4]
        I/O ports at e500 [size=8]
        I/O ports at e600 [size=4]
        I/O ports at e700 [size=16]
        I/O ports at e800 [size=128]
        Capabilities: [58] Power Management version 2
sis180(혹은 sis964인지도 모르겠다)는 sis 인터페이스가 없어서 결국 바로 쓸 수 없었다. 요컨데 바이오스에서 RAID라고 켜봐야 의미가 없다는 것. 그래서 mdadm을 써서 개별 장치를 묶어 /dev/md0을 만들었다. 이걸 마운트하면 된다. 묶을 때 디스크를 직접 접근하는 것이 아니라 이미 파티션이 만들어져서 숫자가 붙은 장치를 묶는 게 dmraid의 방식과 달랐다. mdadm --detail /dev/md0을 해보면 Rebuild Status라고 해서 완료율이 조금씩 올라가는데, 이 와중에도 mount /dev/md0는 정상적으로 처리가 된다. 신기하다.


fsck /dev/md0 해보니 filesystem size와 physical size가 다르다면서 superblock이나 partition table이 깨졌을지 모른다고, 더 진행할 거냐고 묻는다. 처음에는 두려움에 떨며 감히 넘어가질 못 했는데, 아무리 검색해도 비슷한 문제가 나오질 않는다. 실제로도 sda1과 sdb2의 크기가 미묘하게 달라서 아마 미러링 과정에서 정보가 어긋난 게 아닌가 했다. man mdadm 상으로는 가장 작은 크기에 맞게 크기가 결정된다고 하지만.


phenom에도 shuttle에서 쓰던 sda, sdb를 그대로 md0에 물리고 쓰다가, hddtemp로 온도를 봤는데 sdb의 SMART가 안 된다는 에러가 나왔다. 이게 뭔가 싶어서 mdadm --detail /dev/md0 해봤더니 sdb가 faulty로 되어 있었다. 돈도 없고 하드도 비싼데 이걸 어떻게 하나 싶은 생각이 들면서, 어떻게 살릴 방법이 없나 찾아봤다.

dmesg에 나오는 메시지 중에 kicking non-fresh /dev/sdb1 from array가 있어서 찾아보니, 전원을 갑자기 끄거나 하는 원인으로 일어날 수 있느 문제라면서 다시 --add로 해당 디스크를 어레이에 넣으면 될 거라고 한다. 넣어보니 들어가지고 --detail로 확인하니 레이드 처음 만들었을 때처럼 재구축 진행률이 나온다.

근데 문제가 여기서 끝난 게 아니었다. 콘솔을 열어보니 간간히
ata2.00: irq_stat 0xx08000000, interface fatal error
ata2: SError: { HostInt 10B8B Handshk }
ata2.00: cmd 61/80:00:3f:66:a3/00::00:03:00:00/40 tag 0 ncq 65536 out
           res 40/00:04:3f:66:a3/00:00:03:00:00/40 Emask 0x50 (ATA bus error)
ata2.00: status: { DRDY }
ata2: softreset failed (device not ready)
라고 나온다. 아마 리빌딩하면서 디스크에 접근하는 동안 뭔가 오류가 난 거겠지.

마지막의 softreset failed는 예전 cheetah에서 보드의 SATA 포트를 HackOS가 제대로 지원하지 않아 꾸준히 에러가 나던 (그래서 성능을 무진장 깎아먹었다고 의심되는) 때 보던 메시지와 같다. 중간에 나온 ncq는 아마 SATA의 AHCI 모드에서 지원하는 native command queuing을 뜻하는 것 같다. 조금이라도 성능 향상이 있을까 하여 AHCI로 해놨는데 그게 뭔가 문제가 되는 건가? /var/log에서 softreset을 살펴보니 과연 2008년 11월 24일부터 ata2(=sdb?)에서 하루에 몇 번씩 에러를 내다가 11월 30일에 에러가 많이 나고, 다시 12월 3일에 마구 에러가 났다. ata1 쪽도 별로 다르지 않고 오히려 12월 3일에는 에러가 없고 12월 5일에 몇 번의 에러를 냈다.

이런 식이면 곤란하다. 아직 하드 수명이 다 될만한 것도 아니고 발열이 그렇게 많은 것도 아닌데 (cheetah나 Shuttle에선 환기가 시원찮아서 50도 전후로 유지됐지만 phenom은 환기도 잘 되고 계절 영향도 있고 해서 30도 초중반대에서 유지된다) 에러가 날 이유가 없다.

dmraid, 다시

에러가 나던 하드를 결국 교환했다. 하지만 돌아와서 해보니 또 에러가 나서 혹시나 하고 케이블을 바꿨더니 에러가 없어졌다. 어쩌면 하드 가지러 안 가도 되는 거였을지 모르지만 어쨌든 하드를 교환했다는 걸로 의미를 삼기로 했다.

하드를 바꾼 김에 아예 phenom에서 지원하는 RAID로 바꾸기로 하고 하드를 백업한 뒤 바이오스에서 SATA 설정을 RAID로 바꾼 다음 RAID 1로 어레이를 새로 만들었다. 기존 것은 JBOD로 잡혀 있었고 그걸 둘 다 지운 다음 하나로 합쳤다. shuttle에서처럼 싱크 과정을 거치거나 하는 건 없었는데 아마 삭제하는 과정에서 초기화가 되어 양쪽 다 같은 상태였기 때문이 아닐까 한다.

우분투로 켜고 dmraid -ay를 하고 /dev/mapper를 보니 pdc로 시작하는 장치가 있었다. 그걸 fdisk로 열어 파티션을 하나 만들고 저장했는데 이번에도 역시 pdc_blah1은 바로 생기지 않았고 재부팅 후에 장치가 생긴 것을 확인하고 mkfs와 마운트 처리를 진행했다.

mdadm --detail 같이 어레이의 상태를 확인하는 명령은 dmraid -r 정도가 다인가? ok 라고 상태 표시가 뜨긴 하는데 너무 간단하다. 디스크에 문제가 있을 때 메일을 보내는 기능은 smartd에서도 하고 있으니 기능 손실은 없는 셈이다.

mdadm, 또 다시

dmraid는 기본적으로 바이오스 단계에서 설정을 마친 내용을 적용하는 데 그친다. 잘 돌아갈 때는 괜찮은데 일단 레이드에 문제가 생기고 나니 복구를 어떻게 할지 곤란했다. 780G 보드의 바이오스에서 지원하는 메뉴는 고작 확인, 생성, 삭제 정도가 고작인데 혼자 돌아가고 있는 미러링에 하나를 추가하려면 어떻게 해야 할지 감이 안 왔다.

결국 다른 하드를 추가한 다음 억지로 인식시킨 dmraid 기반 디바이스에 접근을 해서 파일을 복사해 넘겼다. 그 뒤엔 다시 각각 따로 잡고 /dev/md0 아래에 묶었다. 이렇게 하자 문제가 있을 때 복구를 어떻게 할지가 명확해졌다. 직접 mdadm으로 명령을 하면 되니까.


D510MO에 디스크를 추가하기 위해 처음엔(2009년 8월 하순) sil3512 칩셋을 썼는데 자꾸 hard resetting link 에러를 내길래 싼 게 역시 비지떡인가 하면서 좀 찾아봤는데 케이블을 바꾸고 매만져봐도 결국 차도가 없었다. 혹시나 싶어 해봤더니 윈도우에서는 잘만 됐다. 결국 나중에 INIC-1623 카드로 바꾸고 나서 이상이 없어졌다.

mdadm을 쓰다가 가만히 있는데 갑자기 Rebuild Status가 올라가고 있는 경우가 있다. dmesg를 확인하면 data-check of RAID array md0가 나오는데, 이는 다음과 같은 cron 쪽 설정 때문이다.
$ tail /etc/cron.d/mdadm
# By default, run at 01:06 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet



Comments