71 TiB ZFS NAS tanpa kerusakan drive selama 10 tahun
(louwrentius.com)- ZFS NAS 71 TiB yang dibuat dengan 24 drive HGST 4TB telah dioperasikan lebih dari 10 tahun; motherboard dan power supply sudah diganti, tetapi belum pernah ada kerusakan drive
- Selama 10 tahun, total jam operasi kumulatif drive hanya sekitar 6000 jam; metode menyalakannya dari jarak jauh hanya saat diperlukan sangat menekan biaya listrik
- Di HN muncul pendapat bahwa kemungkinan 24 drive tetap tanpa kerusakan selama 10 tahun ternyata lebih tinggi dari perkiraan, sehingga sulit menyimpulkan bahwa hal ini semata berkat kebiasaan sering mematikannya
- ZFS dapat mengimpor kembali pool tanpa masalah setelah pergantian sistem operasi, dan pada zpool scrub yang dijalankan beberapa kali setahun, tidak pernah ditemukan kesalahan checksum
- Kebisingan, jaringan, UPS, backup, dan rencana penggantian semuanya dikelola sebagai kompromi antara daya, biaya, dan toleransi risiko; kapasitas serupa ke depan juga bisa dicapai dengan RAIDZ2 berisi 6–8 drive
71 TiB ZFS NAS yang bertahan lebih dari 10 tahun
- 4U 71 TiB ZFS NAS yang terdiri dari 24 drive 4TB masih terus digunakan setelah lebih dari 10 tahun
- Sistem saat ini menggunakan motherboard kedua dan power supply kedua
- Belum pernah ada kerusakan drive sama sekali
- Total jam operasi kumulatif drive HGST 4TB sekitar 6000 jam, setara dengan sekitar 250 hari waktu aktif dalam rentang 10 tahun
Pengelolaan daya: dinyalakan hanya saat diperlukan
- NAS pada dasarnya dalam keadaan mati dan hanya dinyalakan dari jarak jauh saat diperlukan
- Alur menyalakannya adalah sebagai berikut
- Menyalakan stopkontak listrik IoT dengan skrip
- Setelah BMC (Baseboard Management Controller) selesai booting, menyalakan unit NAS melalui IPMI
- Sebagai alternatif, Wake-on-LAN juga bisa digunakan
- Setelah selesai dipakai, server dimatikan dengan skrip kecil, lalu beberapa detik kemudian daya dari dinding dimatikan
- Jika hanya server yang dimatikan sementara motherboard dan daya BMC tetap tersambung, sekitar 7W akan terus terpakai, sehingga metode itu dihindari
- Layanan lain dijalankan di Raspberry Pi 4 atau server dengan daya siaga yang jauh lebih rendah, sehingga NAS besar ini tidak perlu menyala terus-menerus
- Motivasi utamanya adalah menghemat biaya listrik, dan dinilai juga tampak baik untuk umur hard drive
- Namun, di HN ada pendapat bahwa peluang 24 drive tetap tanpa kerusakan selama 10 tahun lebih tinggi dari dugaan, sehingga sulit memastikan hasil ini berkat operasi yang memutus daya secara rutin
- NAS sebelumnya juga dioperasikan sekitar 5 tahun dengan 20 drive Samsung Spinpoint F1 1TB tanpa kerusakan drive
Komponen yang bermasalah lebih dulu daripada drive
- Drive tetap baik-baik saja, tetapi beberapa tahun lalu motherboard harus diganti
- Gejala kerusakannya berupa tidak bisa masuk BIOS dan sesekali gagal boot
- Langkah dasar seperti melepas baterai CMOS sudah dicoba, tetapi tidak menyelesaikan masalah
- Karena motherboard yang sama dijual di Ebay dengan harga yang wajar, penggantian bisa dilakukan tanpa kendala besar
- Alasan membutuhkan board yang sama adalah karena server menggunakan 4 slot PCIe
- Konfigurasinya adalah 3 HBA dan 1 NIC 10Gbit
- Power supply menghadapi kondisi saat boot di mana semua drive melakukan spin-up secara bersamaan dan menarik sekitar 600W selama beberapa detik
- Power supply itu berdaya 750W dan, sejauh diingat, rel 12V-nya juga mampu memasok daya yang cukup, tetapi kadang tetap trip saat boot
Operasi ZFS dan hasil scrub
- ZFS berjalan tanpa masalah selama bertahun-tahun
- Sistem operasi sudah beberapa kali diganti, tetapi setelah memasang OS baru tidak ada masalah saat mengimpor kembali pool lama
- Jika membangun server penyimpanan baru, penulis berniat tetap memakai ZFS
- zpool scrub dijalankan beberapa kali dalam setahun
- Menyelesaikan satu kali scrub membutuhkan sekitar 20 jam
- Karena konsumsi daya meningkat selama scrub, proses ini dijalankan pada hari ketika listrik lebih murah dalam skema tarif listrik dinamis
- Sampai sekarang, scrub belum pernah menemukan kesalahan checksum
- Kemungkinan total data yang telah dibaca dari semua drive sudah melampaui 1 petabyte, tetapi belum pernah ada situasi di mana ZFS harus turun tangan untuk pemulihan
Kesalahan drive dan kerusakan data senyap
- Kerusakan drive umumnya terbagi dalam dua bentuk
- Kerusakan total, ketika drive sama sekali tidak terdeteksi
- Gagal baca/tulis atau bad sector
- Bentuk ketiga, yaitu kerusakan data senyap, dinilai sangat jarang
- Saat disk tidak menyadari sendiri bahwa ia telah mengirimkan data yang rusak
- Saat koneksi SATA gagal mendeteksi kesalahan checksum
- Karena ada banyak pemeriksaan checksum tingkat rendah, risiko ini dinilai sangat kecil
- Kerusakan data senyap adalah risiko nyata, tetapi dianggap lebih layak dikhawatirkan di lingkungan berskala besar seperti data center daripada lingkungan rumah
- ZFS layak dipelajari bagi pengguna yang akrab dengan Linux atau FreeBSD, dan tidak terlalu sulit untuk dipelajari
Kontrol kipas untuk NAS yang senyap
- Untuk ukuran NAS, sistem ini tergolong sangat senyap
- Chassis-nya memiliki 3 kipas 12V yang kokoh untuk mendinginkan 24 bay drive
- Pada kecepatan default kipas sangat bising, tetapi pada RPM rendah cukup senyap dan dalam sebagian besar situasi tetap memberi aliran udara yang memadai
- Namun, dengan kecepatan rendah saja, suhu akhirnya tetap naik saat drive melakukan baca/tulis
- Motherboard Supermicro yang digunakan memungkinkan semua header kipas dikendalikan dari Linux
- Dibuat skrip yang menyesuaikan kecepatan kipas berdasarkan suhu drive terpanas
- Di subreddit terkait matematika, penulis menanyakan algoritme yang cocok untuk tetap senyap sambil mendinginkan drive, dan direkomendasikan pengendali PID
- Kode kontrol PID ditulis dalam Python, lalu parameter disetel dengan mengambil contoh kode yang ada
- Skrip ini bekerja baik selama bertahun-tahun dan menjaga suhu drive di bawah 40°C
- Karena aliran udara dasar terbatas, diperlukan kipas tambahan untuk mendinginkan 4 kartu PCIe seperti HBA dan kartu jaringan
Perubahan konfigurasi jaringan
- Pada awalnya digunakan kontroler jaringan gigabit quad-port dan network bonding
- Dengan konfigurasi ini, kecepatan transfer antar beberapa sistem mencapai sekitar 450MB/s
- Karena membutuhkan terlalu banyak kabel UTP, kemudian diganti dengan kartu Infiniband murah
- Dalam konfigurasi Infiniband, kecepatan antar sistem bisa mencapai sekitar 700MB/s
- Saat memutuskan kembali dari Ubuntu ke Debian, kartu Infiniband tidak lagi berfungsi dan penyebabnya tidak berhasil diatasi
- Setelah itu dibeli kartu 10Gbit Ethernet bekas, dan hingga kini berjalan tanpa masalah
UPS, backup, dan toleransi risiko
- Selama beberapa waktu, UPS besar digunakan agar sistem bisa dimatikan dengan benar saat listrik padam
- Setelah diketahui bahwa UPS mengonsumsi tambahan lebih dari 10W di luar konsumsi daya server, UPS tersebut dilepas
- Risiko kehilangan sistem karena masalah kelistrikan diputuskan untuk diterima
- Data yang paling penting dibackup tiga kali
- Banyak data yang tersimpan di server dianggap tidak cukup penting untuk dibackup
- Kehilangan data akibat kerusakan drive ditangani dengan mengandalkan perangkat pengganti dan ZFS
- Jika perlindungan itu ternyata tidak cukup, kehilangan tersebut memang diterima sebagai konsekuensi selama 10 tahun pengoperasian
Generasi berikutnya yang mungkin cukup dengan konfigurasi lebih kecil
- Saat ini belum ada rencana penyimpanan masa depan yang terpisah
- Alasan awal membangun server ini adalah karena tidak ingin terus memindahkan data akibat kekurangan ruang, dan sampai sekarang ruangnya masih cukup longgar
- Ada cadangan motherboard, CPU, memori, dan kartu HBA, sehingga jika rusak kemungkinan sistem masih bisa dihidupkan kembali
- Karena kapasitas hard drive telah meningkat pesat, suatu saat chassis 24-bay ini mungkin bisa diganti dengan form factor yang lebih kecil
- Tingkat redundansi penyimpanan yang sama dapat dibuat dengan 6–8 hard drive dan RAIDZ2, yaitu redundansi setara RAID 6
- Penyimpanan masih dianggap mahal
- Kemungkinan lain adalah dalam beberapa tahun ke depan sistem ini akhirnya benar-benar rusak, tidak diganti, dan hobi penyimpanan pun berakhir
1 komentar
Pendapat Hacker News
Penasaran apakah ada siklus penggantian drive
Kemungkinan besar 24 drive itu model yang sama dan dari batch yang sama, dengan tingkat keausan yang juga mirip; sebagian besar bisa rusak pada waktu yang hampir bersamaan, dan sisanya ikut rusak karena beban yang meningkat saat rekonstruksi
Penyimpanan yang andal memang rumit
Tentu saja keduanya rusak bersamaan, dan kami harus melakukan pemulihan semalaman
Benar-benar bisa dibilang sangat beruntung :D
Tapi rasanya keausan perangkat keras tidak akan sekonsisten itu
Sistemnya bertahan baik sampai satu drive mati dan saat rekonstruksi drive kedua ikut mati
Tentu saja itu bukan ZFS, tidak ada scrub berkala, tingkat kegagalan drive era 2000-an mungkin berbeda, dan dayanya juga tidak dimatikan saat tidak dipakai
Intinya bukan penyebab pastinya, melainkan kegagalan yang berkorelasi. Dengan catatan umum: sampel 1, orang acak di internet
Bagian “NAS ini sangat senyap untuk ukuran NAS” karena kipas berjari-jari besar dapat menggerakkan banyak udara pada RPM rendah, dan efisiensi energinya juga jauh lebih baik
Dalam presentasinya, Oxide Computer menjelaskan alasan memakai kipas 80mm: karena senyap dan, yang lebih penting, konsumsi dayanya rendah
Mereka mengamati bahwa pada server lain hingga 25% daya dipakai untuk menggerakkan kipas, sedangkan pada sistem mereka sekitar 1%
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Kecuali kipas 40mm pada PSU Flex ATX yang hampir punah, dan 80mm pun sekarang cukup jarang. Biasanya yang sering terlihat 120mm atau 140mm
Saya benar-benar tidak suka suara frekuensi tinggi dari kipas DC kecil ber-RPM tinggi yang umum di data center
Semoga mereka juga memakai cara yang “pintar” untuk mengendalikan kecepatan kipas ;-)
Saya sepenuhnya yakin dengan gagasan memindahkan aliran udara lebih besar pada kecepatan lebih rendah
Saya paham bahwa ini sulit pada sasis 1U atau 2U
Tetap bagus. Mengurangi suara kipas saja sudah mengagumkan, dan membuat orang bertanya-tanya mengapa sebelumnya tidak ada yang memikirkan sesuatu yang tampak sesederhana ini
Saya pernah mendengar saran yang benar-benar berlawanan, yaitu drive sebaiknya terus berputar untuk mengurangi keausan akibat siklus daya
Tidak tahu mana yang harus dipercaya, tetapi saya suka bahwa ZFS NAS bisa dibiarkan menyala agar scrub berjalan berkala dan data dapat diperiksa
Sebagai catatan, saya menjalankan sistem 4 drive selama 10 tahun dan selama itu ada 2 kegagalan drive, tetapi drive-nya WD Green, bukan kelas enterprise
Menyalakan dan mematikan drive satu-dua kali sehari berbeda dengan melakukan spin-down setiap 15 menit atau kurang
Drive WD Green tidak direkomendasikan untuk NAS. Dulu drive ini sering memarkir head baca/tulis setiap beberapa detik; itu tidak masalah jika akses data jarang, tetapi di server dapat menyebabkan keausan terus-menerus dan memicu kegagalan dini
Head baca/tulis hampir tidak aus selama melayang di atas platter. Saat daya dimatikan, head secara fisik turun ke rak atau landing zone pada platter, dan proses mendarat serta lepas landas itulah yang memberi keausan terbesar pada head
Dalam kasus terburuk, karena gesekan statis, head bisa tercabut saat lepas landas
Bearing juga lebih awet, dan jika berhenti terlalu lama bisa macet. Motor drive juga demikian
Arus masuk saat dinyalakan, sekecil apa pun, tetap merupakan stres listrik
Alasan mematikan hard disk hanyalah penghematan daya, pengurangan kebisingan, atau transportasi
Akibatnya spin-up dan spin-down bisa terjadi berkali-kali dalam sehari, jadi argumen ini sangat sulit diterima
Namun saya tidak punya bukti untuk mendukungnya
Jika demikian, membuat disk terus berputar agar tidak menyala-mati setiap beberapa menit dapat membantu meningkatkan umur pakai
Namun jika ini homelab, kemungkinan besar biaya listrik yang dikeluarkan jauh lebih besar daripada penghematan biaya perawatan disk
Saya punya beberapa drive berkapasitas besar untuk media keluarga, dan ingin melindunginya dengan keyakinan lebih dari sekadar “drive-nya belum rusak”
Diskusi tentang filesystem dengan checksum biasanya berpusat pada ZFS dan BTRFS, tetapi saya penasaran apakah ada yang pernah memakai bcachefs
Setahu saya sudah di-upstream ke kernel Linux dan mendukung checksum menyeluruh. Pembuatnya juga tampak menganggap serius tanggung jawab sebuah filesystem
Ada yang menggunakannya di sini?
https://bcachefs.org/
Butuh kira-kira 1 minggu sampai seluruh RAID tidak bisa di-mount karena masalah journal. Konfigurasinya 8 HDD, 2 SSD sebagai write cache, dan 2 NVMe sebagai read cache
Pembuatnya membalas di Reddit dalam sehari, dan saya mencoba menerapkan patch darinya. Saya harus mengompilasi kernel Linux dan boot dengan kernel itu, tetapi masalahnya tidak terselesaikan
Setelah itu sayangnya tidak ada jawaban, jadi setelah menunggu beberapa hari saya menghapusnya dan kembali ke RAID mdadm biasa
Data penting tentu saja semuanya sudah saya backup, tetapi saya kehilangan sebagian data yang tidak penting, dan itu mengingatkan saya lagi bahwa teknologi paling mutakhir itu tidak stabil
Namun proses setup dan fiturnya sangat bagus. Bisa menambahkan disk lalu menandainya sebagai read/write cache saja sudah menyenangkan
Setelah matang beberapa tahun lagi, saya pasti berniat mencobanya kembali
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Untuk data produksi saya tidak ingin mengambil risiko, tetapi untuk homelab mungkin masih oke
Namun Anda perlu bertanya pada diri sendiri seberapa banyak waktu yang bersedia Anda habiskan ketika ada sesuatu yang tidak beres
Saya juga sudah memakai ZFS lebih dari 15 tahun dan melihat banyak kejadian aneh akibat hardware buruk, tetapi pada hardware enterprise yang bagus, ia berjalan tanpa cacat
Saya sedang mencoba kombinasi memakai SSD sebagai cache, dengan SSD sekitar 2 TiB di depan hard disk besar sekitar 8 TiB
Di Ubuntu saya sempat mengalami masalah-masalah kecil dengan kombinasi zsys yang kini sudah legacy + root ZFS, tetapi itu setup yang umum dan sudah dipakai luas selama bertahun-tahun, jadi dukungan mudah ditemukan
Saya rasa saya tidak akan memakai bcachefs sampai tingkat adopsi dan dukungan komunitasnya mencapai level serupa
Menurut saya lingkungan tempat drive beroperasi membuat perbedaan sangat besar pada umur pakainya
Lingkungan rumah jauh lebih berubah-ubah dibanding pusat data atau kantor. Fluktuasi suhu dan kelembapan juga tantangan besar, tetapi yang mengejutkan adalah sedikit debu pun punya dampak yang cukup jelas
Dulu sekali saya menjalankan array 8x500G di server Dell tua di ruang bawah tanah. Semua drive adalah Seagate baru, 7200 RPM, mungkin versi “enterprise”
Selama 5 tahun, rata-rata satu drive rusak setiap 6 bulan. Saya memakai 2 drive parity, menyimpan drive cadangan, dan setiap kali rusak saya mengirim RMA
Setelah pindah, saya punya ruangan khusus untuk lab, dan dengan konfigurasi yang sama selama 5 tahun berikutnya tidak ada satu pun yang rusak. Saya memang menduga lingkungan baru akan lebih baik, tetapi terkejut karena lingkungan yang lebih bersih dan stabil bisa membuat perbedaan sebesar itu
Saya terus memakai NAS/file server di lingkungan rumah yang berdebu, bahkan sekarang sampai logo Synology abu-abu yang berbulu halus terlihat, tetapi belum pernah mengalami hal seperti itu
Sepertinya generasi itu punya masalah firmware
Lihat tingkat kegagalan tahunan di sini: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Pada drive modern berisi helium yang tertutup rapat, kalaupun dulu itu memang masalah, sekarang seharusnya bukan masalah besar
Terkait bagian “menerima risiko kehilangan sistem karena masalah listrik”, ada kegagalan lain yang sangat jarang tetapi bisa dicegah UPS, yaitu ketidakseimbangan listrik
Jika terjadi masalah listrik saat ada konstruksi di dekat rumah, atau petir menyambar tiang listrik dekat rumah, bisa muncul lonjakan ke atas maupun ke bawah, dan keduanya bisa merusak
Di tempat kerja pertama saya sekitar 10 tahun lalu, beberapa server mati dengan cara seperti itu. Namun itu satu-satunya saat saya pernah mendengar masalah semacam itu
Sejauh yang saya pahami, UPS juga mencegah lonjakan seperti itu, dan UPS akan mati lebih dulu sebelum server rusak
Petir menyambar langsung antena TV di rumah orang tua saya, dan kabel koaksialnya tersambung ke amplifier/splitter di kotak komunikasi
Setelah itu entah bagaimana merambat ke panel patch jaringan di dekatnya, lalu membakar semua controller Ethernet kabel yang terhubung ke jaringan. Termasuk port switch dan yang tertanam di AP
Pada switch jaringan, arus tampaknya mencoba mengalir ke ground sehingga sampai merusak catu daya
Bagaimana ia berpindah dari koaksial ke Cat5 masih agak misterius. Mungkin teknisi listrik pernah memasang bagian yang sejajar dan berdekatan di suatu tempat
Seluruh jaringan harus dipasang ulang, tetapi untungnya tidak ada komputer berkabel di lokasi. Perangkat penyimpanan pun rasanya akan sulit bertahan
APC 850VA seharga 99 dolar yang dibeli di Office Depot tidak melakukan itu. Ia hanya beralih sangat cepat dari listrik AC ke baterai, bukan benar-benar membersihkan daya
Jika bisa membeli produk yang bagus, dalam jangka panjang itu benar-benar meningkatkan keandalan hardware. Daya yang bersih itu bagus
Melihat sebaran perangkat yang mati, rusak, dan tampak baik-baik saja, kabel tembaga yang membawa VDSL adalah jalur yang sangat langsung. Modem terhubung ke semua perangkat lain lewat Ethernet
Solusi yang benar mungkin adalah mengonversinya ke optik, melewati sedikit segmen serat optik, lalu mengonversinya kembali. Listrik kemungkinan besar akan memilih jalur selain kaca
Namun memilih produknya jauh lebih merepotkan dari perkiraan, dan karena saya bukan orang jaringan, setelah sekitar satu jam mencoba membedakan produk saya menyerah
Jadi saya memasang bridge Wi-Fi di antara modem VDSL dan perangkat lainnya. Saya berharap mode kegagalan itu terisolasi pada badai berikutnya
Ada array ZFS yang terhubung ke modem yang sama dan memang selamat, tetapi sepertinya hanya karena beruntung
Saat itu tidak ada server, tetapi lampu LED rusak setiap beberapa minggu dan itu menjengkelkan. Bangunannya tua dari era 60-an, dan instalasi listrik di unit kami juga punya perbaikan sementara yang mencurigakan
“Rahasianya” bukan mematikan daya, melainkan sekadar keberuntungan
Saya menjalankan drive HGST 4TB selama lebih dari 10 tahun secara 24/7. Memang bukan 24 unit, melainkan 8 unit, tetapi yang rusak 0
Saya juga hanya beruntung, dan ada kenalan yang beberapa kali melakukan RMA untuk drive yang sama
Yang paling membuat saya penasaran adalah, data apa yang membutuhkan 71TB padahal bisa dimatikan hampir sepanjang waktu. Apakah ini server penyimpanan backup?
Misalnya, bearing bisa macet saat dingin
Seseorang yang benar-benar paham statistik mungkin bisa menghitung probabilitas semua 24 drive bertahan hidup dengan asumsi tingkat kegagalan tahunan sekitar 1%
Selain itu, 20 drive di NAS sebelumnya juga tidak ada yang gagal. Jadi N=44; seberapa beruntungkah itu?
Dipakai untuk rumah, dan jika data dibutuhkan biasanya disalin lewat 10Gbit ke sistem yang jauh lebih hemat daya, lalu NAS ini dimatikan lagi
Ada drive yang berisiko saat power cycle
Jadi saya setuju dengan modelnya, tetapi jangan menganggap ini selalu metode yang baik untuk semua orang. Sebagian SSD perlu diberi daya secara berkala
Dengan pola penggunaan NAS, kemungkinan syarat itu terpenuhi
Mungkin baik-baik saja, dan tagihan listrik jelas lebih murah. Drive dengan grease ekstra pada porosnya dulu adalah kasus khusus pada masanya
Saya penasaran apakah Backblaze punya model statistik untuk nyala/mati drive dan umur pakainya. Mereka tampaknya berada di ruang masalah yang selalu menyala
Namun dalam kasus saya, drive-drive ini tidak sering saya power cycle. Paling banyak beberapa kali sebulan
Saya tidak bisa mengatakan atau membuktikan bahwa itu bukan risiko besar, tetapi saya percaya demikian dan telah menerima risiko itu selama lebih dari 15 tahun
Perlu juga diingat bahwa hard disk punya opsi untuk spin down saat idle. Artinya hard disk mampu menangani banyak spin-up dalam sehari
Untuk membackup beberapa perangkat Synology, mereka memakai hard disk 3,5 inci internal dan dock USB, dan ketika drive dipasang kembali ke dock untuk memulihkan file atau backup tambahan, rasanya sekitar 1 dari 10 kali dayanya tidak menyala lagi
Di lingkungan produksi, saya sudah beberapa tahun memakai database PostgreSQL multi-TB di atas ZFS, dan sejauh ini belum mengalami masalah apa pun, termasuk bit flip
Untuk yang berminat, saya mendokumentasikan pengalaman itu di sini:
https://lackofimagination.org/2022/04/our-experience-with-po...
Terkait pemadaman listrik intermiten saat boot, perlu dilihat bahwa drive menarik daya dari rail 5V saat startup
Drive serupa biasanya mengonsumsi hingga 1,2A. Jika digabungkan dengan beban maksimum rail 5V sebesar 25A (Seasonic Platinum 860W), kegagalan daya saat boot sangat mungkin terjadi bila tidak memakai staggered spinup