10년간 드라이브 고장 없는 71 TiB ZFS NAS

• 24개의 4TB HGST 드라이브로 만든 71 TiB ZFS NAS가 10년 넘게 운용됐고, 마더보드와 전원공급장치는 교체됐지만 드라이브 고장은 아직 없었음
• 10년 동안 드라이브 누적 동작 시간은 약 6000시간에 그쳤으며, 필요할 때만 원격으로 켜는 방식이 전력 비용을 크게 낮춤
• HN에서는 24개 드라이브가 10년간 모두 무고장일 확률이 생각보다 높다는 의견이 나와, 전원을 자주 꺼둔 덕분이라고 단정하기는 어려움
• ZFS는 운영체제 변경 후에도 풀을 문제없이 다시 가져왔고, 연 몇 회 실행한 zpool scrub에서도 체크섬 오류가 한 번도 발견되지 않았음
• 소음, 네트워크, UPS, 백업, 교체 계획은 모두 전력·비용·위험 수용 사이의 절충으로 운영됐으며, 같은 용량은 향후 6~8개 드라이브 RAIDZ2로도 가능함

---

10년 넘게 버틴 71 TiB ZFS NAS

• 24개의 4TB 드라이브로 구성한 4U 71 TiB ZFS NAS가 10년 넘게 계속 사용되고 있음
• 현재 시스템은 두 번째 마더보드와 두 번째 전원공급장치를 사용 중임
• 드라이브 고장은 아직 한 번도 없었음
• 4TB HGST 드라이브의 누적 동작 시간은 약 6000시간으로, 10년 기준 약 250일치 동작 시간에 해당함

필요할 때만 켜는 전원 운용

• NAS는 기본적으로 꺼져 있고, 필요할 때만 원격으로 켬
• 전원 켜기 흐름은 다음과 같음
  • 스크립트로 IoT 전원 멀티탭을 켬
  • BMC(Baseboard Management Controller) 부팅이 끝나면 IPMI로 NAS 본체를 켬
  • 대안으로 Wake-on-LAN도 사용할 수 있었음
• 사용이 끝나면 작은 스크립트로 서버를 끄고, 몇 초 기다린 뒤 벽면 전원을 끔
• 서버만 끄고 마더보드와 BMC 전원을 남겨두면 약 7W가 계속 소모되어 이 방식은 피했음
• 다른 서비스는 Raspberry Pi 4나 대기 전력이 훨씬 낮은 서버에서 실행하기 때문에, 큰 NAS를 상시 가동할 필요가 없었음
• 주된 동기는 전기요금 절감이며, 하드드라이브 수명에도 좋아 보인다고 판단함
• 다만 HN에서는 24개 드라이브가 10년간 무고장일 확률이 예상보다 높다는 의견이 나와, 이 결과를 전원 차단 운용 덕분으로 단정하기 어려움
• 이전 NAS도 20개의 1TB Samsung Spinpoint F1 드라이브로 약 5년간 운용하면서 드라이브 고장이 없었음

드라이브보다 먼저 문제를 낸 부품들

• 드라이브는 멀쩡했지만, 몇 년 전 마더보드는 교체해야 했음
• 고장 증상은 BIOS 진입이 불가능하고 가끔 부팅에 실패하는 형태였음
• CMOS 배터리 제거 같은 기본 조치를 시도했지만 해결되지 않았음
• 같은 마더보드가 Ebay에서 적당한 가격에 판매 중이어서 큰 문제 없이 교체함
  • 같은 보드가 필요했던 이유는 서버가 PCIe 슬롯 4개를 사용했기 때문임
  • 구성은 HBA 3개와 10Gbit NIC 1개였음
• 전원공급장치는 부팅 시 모든 드라이브가 동시에 스핀업되며 몇 초 동안 약 600W를 끌어 쓰는 조건을 겪었음
• 전원공급장치는 750W 정격이고 12V 레일도 충분한 전력을 낼 수 있었던 것으로 기억하지만, 부팅 때 가끔 차단됐음

ZFS 운용과 scrub 결과

• ZFS는 수년간 문제없이 동작했음
• 운영체제를 여러 번 바꿨지만, 새 OS 설치 후 기존 풀을 다시 가져오는 데 문제가 없었음
• 새 스토리지 서버를 만든다면 다시 ZFS를 사용할 생각임
• zpool scrub은 1년에 몇 번 실행함
  • scrub 1회 완료에는 약 20시간이 걸림
  • scrub 중 전력 사용량이 커서, 동적 전기요금제에서 전기가 싼 날 실행함
• 지금까지 scrub에서 체크섬 오류는 한 번도 발견되지 않았음
• 모든 드라이브를 합쳐 1페타바이트가 넘는 데이터를 읽었을 것으로 보지만, ZFS가 복구에 개입해야 하는 상황은 없었음

드라이브 오류와 조용한 데이터 손상

• 드라이브 고장은 주로 두 가지 형태로 나뉨
  • 드라이브가 아예 감지되지 않는 전체 고장
  • 읽기·쓰기 실패나 불량 섹터
• 세 번째 형태인 조용한 데이터 손상은 매우 드물다고 봄
  • 디스크가 손상된 데이터를 전달했음을 스스로 알지 못하는 경우
  • SATA 연결에서 체크섬 오류를 감지하지 못하는 경우
• 낮은 수준의 체크섬 검사가 많기 때문에 이 위험은 매우 작다고 봄
• 조용한 데이터 손상은 실제 위험이지만, 주거 환경보다는 데이터센터처럼 규모가 큰 환경에서 더 신경 쓸 문제로 봄
• ZFS는 Linux나 FreeBSD에 익숙한 사용자라면 배워볼 가치가 있으며, 배우기 아주 어렵지는 않음

조용한 NAS를 위한 팬 제어

• 이 NAS는 NAS치고는 매우 조용한 편임
• 섀시에는 24개 드라이브 베이를 식히는 튼튼한 12V 팬 3개가 들어 있음
• 기본 속도로 돌면 매우 시끄럽지만, 낮은 RPM에서는 꽤 조용하고 대부분의 상황에서 충분한 공기 흐름을 제공함
• 낮은 속도만으로는 드라이브 읽기·쓰기 중 온도가 결국 올라갔음
• 사용한 Supermicro 마더보드는 Linux에서 모든 팬 헤더를 제어할 수 있었음
• 가장 뜨거운 드라이브 온도에 따라 팬 속도를 조절하는 스크립트를 만들었음
• 수학 관련 서브레딧에서 조용하면서도 드라이브를 식히는 데 맞는 알고리듬을 물었고, PID 제어기를 추천받음
• Python으로 PID 제어 코드를 작성하고 예제 코드를 가져와 파라미터를 조정했음
• 이 스크립트는 수년간 잘 동작했고 드라이브 온도를 40°C 이하로 유지함
• 기본 공기 흐름이 적어 HBA와 네트워크 카드 등 PCIe 카드 4개를 식히기 위한 추가 팬도 필요했음

네트워크 구성의 변화

• 초기에는 쿼드 포트 기가비트 네트워크 컨트롤러와 네트워크 본딩을 사용했음
• 이 구성으로 여러 시스템 간 약 450MB/s 전송 속도를 얻음
• UTP 케이블이 너무 많이 필요해 이후 저렴한 Infiniband 카드로 변경함
• Infiniband 구성에서는 시스템 간 약 700MB/s에 도달할 수 있었음
• Ubuntu에서 Debian으로 돌아가기로 하면서 Infiniband 카드가 더 이상 동작하지 않았고, 원인을 해결하지 못함
• 이후 중고 10Gbit Ethernet 카드를 구입했고, 지금까지 문제없이 동작 중임

UPS, 백업, 위험 수용

• 한동안 정전 시 정상 종료를 위해 큰 UPS를 사용했음
• UPS가 서버 전력 사용량 외에 10W 이상을 추가로 사용한다는 점을 확인하고 제거함
• 전원 문제로 시스템을 잃을 위험은 수용하기로 했음
• 가장 중요한 데이터는 세 번 백업함
• 서버에 저장된 많은 데이터는 백업할 만큼 중요하지 않다고 봄
• 드라이브 고장으로 인한 데이터 손실은 교체 하드웨어와 ZFS에 의존함
• 그 보호가 충분하지 않으면 손실을 감수하는 조건으로 10년간 운용해 왔음

더 작은 구성으로도 가능한 다음 세대

• 현재 별도의 향후 스토리지 계획은 없음
• 처음 이 서버를 만든 이유는 저장공간 부족 때문에 데이터를 계속 옮기고 싶지 않았기 때문이며, 지금도 공간은 충분히 남아 있음
• 예비 마더보드, CPU, 메모리, HBA 카드가 있어 고장이 나도 시스템을 되살릴 가능성이 높음
• 하드드라이브 용량이 크게 늘었기 때문에, 언젠가는 24베이 섀시를 더 작은 폼팩터로 바꿀 수도 있음
• 동일한 수준의 중복 저장공간은 6~8개 하드드라이브와 RAIDZ2, 즉 RAID 6 수준 중복성으로 만들 수 있음
• 스토리지는 여전히 비싸다고 봄
• 또 다른 가능성은 앞으로 몇 년 안에 시스템이 결국 고장 나고, 교체하지 않으면서 스토리지 취미가 끝나는 것임

[GN⁺]

Hacker News 의견들

• 드라이브 교체 주기가 있는지 궁금함
  24개 드라이브가 같은 모델이고 같은 배치일 가능성이 크며 마모도도 비슷할 텐데, 대부분이 비슷한 시점에 고장 나고 나머지도 재구성 중 늘어난 부하 때문에 같이 고장 날 수 있음
  신뢰성 있는 저장소는 까다로움

  • HN 장애 때 SSD 두 개가 4만 시간 후 동시에 고장났던 일이 떠오름: https://news.ycombinator.com/item?id=32031243
  • 예전에 Dell이 연속된 일련번호의 드라이브가 들어간 서버를 보내준 적이 떠오름
    당연히 둘 다 동시에 고장 났고, 밤새 복구 작업을 해야 했음
  • RAID 1에 드라이브 두 개만 있었는데, 새 드라이브를 실버링해서 배열을 다시 만든 직후 두 번째 드라이브가 바로 고장났음
    정말 운이 좋았던 셈임 :D
  • 소프트웨어 버그라면 그럴 수 있음. 예를 들어 어떤 카운터 오버플로 때문에 정확히 10억 IOPS 후 드라이브가 고장나는 식임
    하지만 하드웨어 마모가 그렇게까지 일관적일 것 같지는 않음
  • 친구에게 이런 일이 실제로 있었음. 2000년대에 글의 NAS와 비슷한 홈 NAS를 더 적고 작은 드라이브로 만들었고, RAID5 구성이었음
    드라이브 하나가 죽고 재구성 중 두 번째가 따라 죽을 때까지는 잘 버텼음
    물론 ZFS도 아니었고, 정기 스크럽도 없었고, 2000년대 드라이브 고장률도 달랐을 수 있으며, 안 쓸 때 전원을 끄지도 않았음
    핵심은 정확한 원인보다 상관된 고장임. 표본 1개, 인터넷의 랜덤한 사람이라는 일반적인 단서는 붙음

• “이 NAS는 NAS치고 매우 조용하다”는 부분은 큰 반지름의 팬이 낮은 RPM에서도 많은 공기를 움직일 수 있고, 에너지 효율도 훨씬 좋기 때문임
  Oxide Computer가 발표에서 80mm 팬을 쓰는 이유를 말했는데, 조용하고 더 중요하게는 전력 소모가 낮아서라고 함
  다른 서버에서는 전력의 25%까지 팬 구동에 쓰이는 반면, 자기들은 약 1%라고 관찰했다는 내용임
  https://www.youtube.com/shorts/hTJYY_Y1H9Q
  https://www.youtube.com/watch?v=4vVXClXVuzE

  • 흥미로움. 데스크톱/워크스테이션 하드웨어에 익숙해서 80mm가 표준 팬 중 가장 작은 축이라고 생각했음
    거의 사라진 Flex ATX 전원공급장치의 40mm 팬을 빼면 그렇고, 80mm도 요즘은 꽤 드묾. 보통 120mm나 140mm를 많이 봄
  • 0xide를 언급한 것에 +1. 그런 방향을 택한 것도 좋고, 전력 통계도 흥미로움
    전형적인 DC 고RPM 소형 팬의 고주파 소음은 정말 싫음
    팬 속도를 제어할 때 뭔가 “똑똑한” 방식도 쓰기를 바람 ;-)
  • 내 Synology는 120mm 팬 두 개를 쓰는데, 바로 옆 책상 위에 있어도 거의 안 들림
    더 큰 풍량을 더 낮은 속도로 움직이는 아이디어에는 완전히 설득됨
    1U나 2U 섀시에서는 어렵다는 점은 이해함
  • 이런 유튜브 영상들이 꽤 obscure한데 혹시 Oxide와 관련 있는지 궁금함 :D
    그래도 좋음. 팬 소음 감소만 해도 놀라운데, 이렇게 단순해 보이는 걸 왜 전에는 아무도 생각하지 않았는지 궁금해짐

• 드라이브는 계속 돌려야 전원 사이클로 인한 마모를 줄인다는 정반대 조언을 들은 적이 있음
  무엇을 믿어야 할지는 모르겠지만, ZFS NAS를 켜둬서 정기적으로 스크럽을 돌리고 데이터를 확인할 수 있는 점은 마음에 듦
  참고로 4드라이브 시스템을 10년 동안 돌렸고 그동안 드라이브 고장은 2번 있었지만, 엔터프라이즈급이 아니라 WD Green이었음

  • 드라이브를 계속 켜두라는 조언의 상당수는 스핀다운과 시작으로 생기는 마모, 즉 Start Stop Cycles를 낮게 유지하라는 의미라고 봄
    하루 한두 번 드라이브를 켜고 끄는 것과 15분 이하마다 스핀다운하는 것은 다름
    WD Green 드라이브는 NAS용으로 권장되지 않음. 과거에는 읽기/쓰기 헤드를 몇 초마다 파킹하곤 했는데, 데이터 접근이 드물면 괜찮지만 서버에서는 지속적인 마모로 이어져 조기 고장을 부를 수 있음
  • 계속 켜두는 편이 좋음
    읽기/쓰기 헤드는 플래터 위에 떠 있는 동안 거의 마모되지 않음. 전원을 끄면 헤드가 선반이나 플래터의 랜딩 존에 물리적으로 내려앉고, 착륙과 이륙이 헤드에 가장 큰 마모를 줌
    최악의 경우 정지 마찰 때문에 이륙 중 헤드가 뜯겨 나갈 수도 있음
    베어링도 더 오래가며, 너무 오래 멈춰 있으면 고착될 수 있음. 드라이브 모터도 마찬가지임
    전원을 켤 때의 돌입 전류도 아무리 작아도 전기적 스트레스임
    하드디스크를 끄는 이유는 전력 절약, 소음 감소, 운반 정도뿐임
  • 하드디스크는 일정 시간 유휴 상태가 되면 스핀다운하도록 설정되는 경우가 많음
    그러면 하루에도 여러 번 스핀업과 스핀다운이 생길 수 있어서, 이 주장은 전혀 납득하기 어려움
    다만 이를 뒷받침할 증거는 가지고 있지 않음
  • 이건 접근 빈도에 완전히 달려 있음. 여러 사람이 많은 파일에 자주 접근하거나, 백업을 자주 돌리는지에 따라 다름
    그렇다면 디스크가 몇 분마다 켜졌다 꺼졌다 하는 걸 막기 위해 계속 회전시키는 것이 수명 개선에 도움이 될 수 있음
    하지만 홈랩이라면 디스크 유지비에서 아끼는 것보다 전기요금으로 훨씬 더 많이 쓰고 있을 가능성이 큼
  • 정기적으로 스크럽하고 데이터를 확인한다는 게, 각 파일의 md5 같은 해시/체크섬을 기록하고 주기적으로 검사하는 내장 체크섬 시스템을 포함하는지 궁금함
    가족 미디어용 대용량 드라이브가 몇 개 있는데, “드라이브가 고장 나지 않았다” 이상의 확신으로 보호하고 싶음

• 체크섬 파일시스템 논의는 보통 ZFS와 BTRFS를 중심으로 돌아가지만, bcachefs를 써본 사람이 있는지 궁금함
  Linux 커널에 upstream됐고, 전체 체크섬을 지원한다고 알고 있음. 작성자도 파일시스템의 책임을 진지하게 받아들이는 것처럼 보임
  여기서 쓰는 사람이 있나?
  https://bcachefs.org/

  • Linux 커널에 병합된 직후 홈랩 서버에서 시험해 봤음
    전체 RAID가 저널 문제로 마운트되지 않기까지 대략 1주일 걸렸음. 구성은 8개 HDD, 2개 SSD 쓰기 캐시, 2개 NVMe 읽기 캐시였음
    작성자가 Reddit에서 하루 안에 답했고, 그의 수정안을 적용해 봤음. Linux 커널을 컴파일하고 그걸로 부팅해야 했지만, 문제는 해결되지 않았음
    이후에는 안타깝게도 답이 없어서 며칠 기다린 뒤 밀고 평범한 mdadm RAID로 돌아갔음
    중요한 건 당연히 전부 백업해 뒀지만, 중요하지 않은 데이터 일부는 잃었고 최첨단은 불안정하다는 사실을 다시 떠올리게 됨
    다만 설정 과정과 기능은 훌륭했음. 디스크를 추가하고 읽기/쓰기 캐시로 표시할 수 있는 것만으로도 좋았음
    몇 년 더 숙성된 뒤에는 분명 다시 시도해 볼 생각임
  • Linus가 나중에 후회한 결정이었음[1]. 최근 Hacker News에서도 관련 논의가 있었음[2]
    [1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
    [2] https://news.ycombinator.com/item?id=41407768
  • 아직 실험적으로 표시되어 있고, 커널에 병합된 뒤 몇 가지 큰 문제가 해결되었음
    운영 데이터는 위험을 감수하고 싶지 않지만 홈랩이라면 괜찮을 수 있음
    다만 뭔가 잘못됐을 때 얼마나 시간을 쓸 의향이 있는지 스스로 물어봐야 함
    ZFS도 15년 넘게 써왔고 나쁜 하드웨어 때문에 별일을 많이 봤지만, 좋은 엔터프라이즈 하드웨어에서는 흠 없이 동작했음
  • 쓰고 있음. 지금까지는 괜찮았지만, 혹시 모르니 데이터는 어쨌든 전부 백업해 둬야 함
    약 2TiB SSD를 약 8TiB 대형 하드디스크 앞에 두고 SSD를 캐시로 쓰는 조합을 시험 중임
  • 낙관적이긴 하지만 당분간 홈랩을 옮기지는 않을 것 같음
    Ubuntu에서 이제는 레거시가 된 zsys + 루트 ZFS 조합으로 자잘한 문제를 겪었지만, 흔한 설정이고 수년간 널리 쓰여서 지원을 찾기 쉬움
    bcachefs도 비슷한 수준의 채택률과 커뮤니티 지원이 생기기 전까지는 쓰지 않을 듯함

• 드라이브가 돌아가는 환경이 수명에 엄청난 차이를 만든다고 봄
  주거 환경은 데이터센터나 사무실보다 변동성이 훨씬 큼. 온도와 습도 변동도 큰 과제지만, 놀라웠던 건 소량의 먼지도 꽤 뚜렷한 영향을 준다는 점이었음
  오래전에 지하실의 낡은 Dell 서버에서 8x500G 배열을 돌렸음. 드라이브는 모두 새 Seagate였고 7200RPM, “엔터프라이즈” 버전이었을 수도 있음
  5년 동안 평균 6개월에 한 번 드라이브가 고장 났음. 패리티 드라이브 2개를 두고, 예비 드라이브를 보관하며, 고장 날 때마다 RMA를 보냈음
  이사 후 실험실 전용 방을 갖게 됐고, 같은 구성으로 이후 5년 동안 고장이 하나도 없었음. 새 환경이 더 좋을 건 예상했지만, 더 깨끗하고 안정적인 환경이 이렇게까지 좋아질 줄은 놀라웠음

  • 6개월마다 드라이브가 고장 났다면 먼지보다는 전원 품질 문제처럼 들림
    NAS/파일 서버를 먼지 많은 주거 환경에 계속 두고 썼고, 지금도 보송한 회색 Synology 로고가 보일 정도지만 그런 일은 본 적 없음
  • 나도 16x500GB Seagate 배열이 있었고 6개월마다 RMA가 평균적으로 하나씩 나왔음
    그 세대에는 펌웨어 문제가 있었던 것 같음
  • 모델 문제일 가능성이 가장 큼. 예전에 Seagate ST3000DM001 36개가 들어간 머신을 쓴 적이 있는데, 거의 매달 하나씩 고장 났음
    여기 연간 고장률을 보면 됨: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
  • 먼지가 어떻게 영향을 주는지 궁금함. 드라이브는 밀폐되어 있지 않나?
  • “네가 숨 쉬는 게 공기라고 생각하나?”
    요즘의 밀폐된 헬륨 충전 드라이브에서는, 애초에 문제였다고 해도 이제는 큰 문제가 아닐 것임

• “전원 문제로 시스템을 잃는 위험은 감수한다”는 부분과 관련해, UPS가 막아주는 또 다른 매우 드문 고장으로 전기 불균형이 있음
  근처 공사 중 전기에 문제가 생기거나, 집 근처 전봇대에 번개가 치면 위아래 방향의 스파이크가 생길 수 있고 둘 다 파괴적일 수 있음
  첫 직장에서 약 10년 전에 여러 서버가 그런 식으로 죽었음. 다만 그런 문제를 들은 건 그때가 유일함
  이해하기로 UPS는 그런 스파이크도 막아주며, 서버가 손상되기 전에 UPS가 먼저 죽을 것임

  • 관리하던 장비가 낙뢰를 맞은 걸 직접 겪어봤음
    부모님 집 TV 안테나에 바로 번개가 쳤고, 동축 케이블로 통신함의 증폭기/분배기까지 이어져 있었음
    그 뒤 어떻게 된 건지 근처 네트워크 패치 패널로 넘어가서, 네트워크에 붙은 모든 유선 이더넷 컨트롤러를 태웠음. 스위치 포트와 AP에 내장된 것들도 포함됨
    네트워크 스위치에서는 전류가 접지로 가려 했는지 전원공급장치까지 파괴됐음
    동축에서 Cat5로 어떻게 넘어갔는지는 아직도 약간 미스터리임. 전기기사가 어딘가에 가까이 병렬로 깔아둔 구간이 있었을지도 모름
    전체 네트워크를 다시 깔아야 했지만, 다행히 현장에 유선 컴퓨터는 없었음. 저장장치도 버티기 어려웠을 것 같음
  • UPS 종류에 따라 크게 다름. 크고 비싼 UPS는 교류를 직류로 바꾼 뒤 다시 교류로 바꿔서, 훌륭한 순수 사인파 전원을 제공함
    Office Depot에서 사는 99달러짜리 850VA APC는 그렇게 하지 않음. 교류에서 배터리로 매우 빠르게 전환할 뿐, 실제 전원 정화는 하지 않음
    좋은 제품을 살 수 있다면 장기적으로 하드웨어 신뢰성을 정말 높여줌. 깨끗한 전원은 좋음
  • 약 일주일 전 집에서 번개가 모뎀과 주변 장비 몇 개를 날렸음. 주거 환경이었음
    죽은 장비, 손상된 장비, 겉보기엔 멀쩡한 장비의 분포를 보면 VDSL을 실은 구리선이 매우 직접적인 경로였음. 모뎀은 이더넷으로 다른 모든 장비에 연결돼 있었음
    제대로 된 해결은 아마 광으로 변환해 광섬유 구간을 조금 지나가게 한 뒤 다시 변환하는 것일 듯함. 전기는 유리보다 다른 경로를 택할 가능성이 큼
    그런데 제품을 고르는 일이 예상보다 훨씬 귀찮았고, 네트워크 쪽 사람이 아니라 한 시간쯤 제품 구분을 시도하다 포기했음
    그래서 VDSL 모뎀과 나머지 장비 사이에 Wi-Fi 브리지를 넣어뒀음. 다음 폭풍 때는 그 고장 모드가 격리되기를 바람
    같은 모뎀에 연결돼 있던 ZFS 배열이 있었는데 살아남긴 했지만, 운이 좋았던 것 같음
  • 예전에 살던 낡은 아파트에서 그런 스파이크를 겪었음
    당시 서버는 없었지만 LED 전구가 몇 주마다 고장 나서 짜증났음. 60년대 오래된 건물이었고, 우리 집 전기 설비에도 미심쩍은 임시 수리가 있었음
  • 그게 서지 보호기가 하는 일 아닌가?

• “비밀”은 전원을 끄는 게 아니라 그냥 운임
  4TB HGST 드라이브를 10년 넘게 24/7로 돌리고 있음. 정확히 24개가 아니라 8개지만, 고장은 0개임
  나도 운이 좋은 것뿐이고, 같은 드라이브로 RMA를 여러 번 보낸 지인들도 있음
  가장 궁금한 건, 대부분의 시간 꺼둘 수 있는데도 71TB가 필요한 데이터가 무엇이냐는 점임. 백업 저장 서버인가?

  • 사실 오랫동안의 통념은 수명을 원하면 전원을 끄지 말라는 것이었음
    예를 들어 베어링은 차가울 때 고착될 수 있음
  • 운일 수도 있지만, 24개 드라이브라면 정말 운이 좋은 느낌임
    통계를 제대로 아는 사람이 연간 고장률 1%쯤으로 추정해 24개가 모두 살아남을 확률을 계산할 수 있을 것 같음
    게다가 이전 NAS의 20개 드라이브도 고장이 없었음. 그러면 N=44인데, 얼마나 운이 좋아야 하는 걸까?
    주거용으로 쓰고 있고, 데이터가 필요하면 보통 10Gbit로 훨씬 저전력인 시스템에 복사한 뒤 이 NAS는 다시 끔
  • 대부분 꺼둘 수 있는데 71TB가 필요한 게 무엇인지 나도 아직 설명을 기다리는 중임

• 전원 사이클이 위험했던 드라이브들이 있었음
  그래서 모델에는 동의하지만, 이것이 항상 모든 사람에게 좋은 방법이라고 가정하면 안 됨. 일부 SSD는 주기적으로 전원이 공급되어야 함
  NAS의 사용 주기라면 아마 그 요건은 충족할 것임
  아마 괜찮고, 전기요금은 확실히 더 쌈. 축에 여분의 그리스가 들어간 드라이브들은 한때의 특이 사례였음
  Backblaze가 드라이브 켜짐/꺼짐과 수명 통계 모델을 갖고 있는지 궁금함. 그쪽은 늘 켜져 있는 문제 공간에 있을 것 같음

  • 30년 넘은 그런 이야기는 알고 있음. 그때는 맞았을 수도 있고, 지금도 맞을 수 있음
    하지만 내 경우 이 드라이브들을 자주 전원 사이클하지 않음. 많아야 한 달에 몇 번임
    큰 위험이 아니라고 말하거나 증명할 수는 없지만, 아니라고 믿고 15년 넘게 그 위험을 받아들여 왔음
    하드디스크에는 유휴 시 스핀다운하는 옵션이 있다는 점도 기억해야 함. 즉 하드디스크는 하루에도 많은 스핀업을 감당할 수 있음
  • 오래전 “IT Nightmares” 한 편이 될 만한 클라이언트가 있었음
    Synology 장비 몇 대를 백업하려고 내장 3.5인치 하드디스크와 USB 도크를 썼는데, 파일 복원이나 추가 백업을 위해 드라이브를 도크에 다시 꽂을 때 10번 중 1번쯤은 전원이 다시 안 켜지는 느낌이었음

• 운영 환경에서 몇 년째 ZFS 위의 다중 TB PostgreSQL 데이터베이스를 쓰고 있고, 지금까지 비트 플립 포함 아무 문제도 겪지 않았음
  관심 있는 사람을 위해 경험을 여기 문서화해 두었음:
  https://lackofimagination.org/2022/04/our-experience-with-po...

• 부팅 중 간헐적인 전원 차단과 관련해서는, 드라이브가 시작 시 5V 레일에서 전력을 끌어온다는 점을 봐야 함
  비슷한 드라이브는 보통 최대 1.2A를 소비함. 5V 레일의 최대 부하가 25A인 점(Seasonic Platinum 860W)을 합치면, staggered spinup을 쓰지 않을 때 부팅 중 전원 실패가 발생할 가능성이 큼