Melacak gangguan Hetzner AX162 dengan powerstat, sensors, dan dmidecode

 (ubicloud.com)
1 poin oleh GN⁺ 2025-02-21 | 1 komentar | Bagikan ke WhatsApp
  • Ubicloud mengadopsi server baru Hetzner AX162 karena tampak lebih baik dari AX161 dari sisi performa dan harga, tetapi selama operasi mengalami masalah keandalan: gangguan terjadi 16 kali lebih sering
  • Pelacakan penyebab dimulai dari log sistem yang menyisakan byte NULL, lalu dilakukan dengan menyingkirkan satu per satu faktor beban, suhu, informasi komponen, dan konsumsi daya; sensors, dmidecode, dan powerstat menjadi alat kunci
  • Pada data awal, AX161 mencatat 11 gangguan selama 3.784 hari layanan dengan AFR 1,06, sedangkan AX162 mencatat 34 gangguan selama 737 hari dengan AFR 16,84
  • 80% server yang pernah mengalami gangguan mengalami gangguan kedua dalam 24 jam, dan Hetzner memberi tahu adanya cacat batch motherboard tanpa mengonfirmasi apakah ada pembatasan daya
  • AX162 -v3 yang dipindahkan ke motherboard terbaru turun hingga AFR 0,39 setelah dipantau beberapa bulan; hardware baru perlu divalidasi bertahap mulai dari workload nonkritis

Crash berulang setelah adopsi AX162

  • Ubicloud membuat software yang mengubah penyedia bare metal menjadi platform cloud, dan telah menggunakan Hetzner sebagai penyedia server yang murah dan dapat diandalkan
  • Lini server AX162 dari Hetzner menawarkan performa lebih baik dan harga lebih rendah dibanding model sebelumnya AX161, sehingga cepat diadopsi
  • Tiga minggu setelah pembelian server AX162 pertama, satu server crash, dan log sistem menyisakan byte NULL
    • Ini ditafsirkan sebagai sinyal kegagalan mendadak yang membuat operasi tulis tidak dapat diselesaikan secara normal, seperti kehilangan daya
  • Pemeriksaan hardware oleh Hetzner awalnya tidak menemukan kelainan, tetapi satu minggu kemudian terjadi crash lain, dan gangguan berulang dalam beberapa hari

Pola munculnya gangguan

  • Semua crash hanya terjadi pada server AX162
  • Gangguan terbagi menjadi dua bentuk
    • Server kembali online setelah restart manual
    • Server tidak merespons permintaan restart maupun kode diagnostik dari engineer Hetzner, sehingga harus diganti
  • Server biasanya berjalan normal dalam waktu lama, lalu setelah crash pertama kemungkinan crash tambahan meningkat
  • Teramati alur ketika crash tipe pertama berulang beberapa kali dan akhirnya berujung pada tipe kedua, sehingga server diganti

Menyingkirkan beban dan suhu terlebih dahulu

  • AX162 menyediakan 96 vCPU, dan Ubicloud memiliki workload yang menggunakan semua vCPU secara bersamaan
  • Hipotesis bahwa beban tinggi dapat menaikkan suhu atau menimbulkan masalah tak terduga diperiksa, tetapi pada saat crash gangguan juga terjadi dalam kondisi beban rendah atau tanpa beban
  • Untuk melihat korelasi antara suhu dan gangguan, suhu komponen sistem dikumpulkan dengan perintah sensors
  • Data suhu dikumpulkan dengan cron job sederhana, dan saat crash terjadi lagi, suhu yang diperiksa tidak jauh lebih tinggi dari rata-rata

Menyelidiki informasi komponen dan konsumsi daya

  • Model dan nomor seri komponen hardware diperiksa dengan lshw dan dmidecode
  • Komponen server AX162 yang mengalami crash dibandingkan dengan server yang tidak mengalaminya, tetapi tidak ditemukan perbedaan yang signifikan
  • Karena komponen yang lebih lama bisa lebih sering rusak, pola kenaikan nomor seri juga diperiksa, tetapi crash juga terjadi pada server dengan nomor seri terbaru
  • Dalam ekspansi data center, daya listrik sering menjadi batasan yang lebih besar daripada ruang, dan operator dapat membatasi penggunaan daya per mesin
    • Ubicloud tidak tahu apakah Hetzner membatasi konsumsi daya, tetapi gejala server berjalan stabil dalam jangka panjang lalu mengalami crash berulang dianggap cocok dengan keausan hardware
    • Setelah hipotesis lain disingkirkan satu per satu, pembatasan daya tersisa sebagai hipotesis yang kuat
  • Konsumsi daya maksimum jangka panjang diukur dengan powerstat -R dan dibandingkan dengan angka yang diiklankan
    • AX161: daya maksimum yang diiklankan 147W, daya maksimum terukur 168W
    • AX162: daya maksimum yang diiklankan 408W, daya maksimum terukur 266W
  • Perbedaan ini memunculkan kecurigaan bahwa Hetzner mungkin membatasi penggunaan daya aktual

Tingkat gangguan dilihat dari AFR

  • Untuk membandingkan keandalan hardware, digunakan Annualized Failure Rate(AFR)
  • AFR memiliki keterbatasan, tetapi merupakan metrik yang cukup sederhana sebagai titik awal untuk membandingkan tingkat gangguan
  • Hasil pengukuran awal menunjukkan tingkat gangguan AX162 jauh lebih tinggi daripada AX161
    • AX161: 11 gangguan, total layanan 3.784 hari, AFR 1,06
    • AX162: 34 gangguan, total layanan 737 hari, AFR 16,84
  • Data ini mendukung pengamatan bahwa AX162 memiliki kemungkinan mengalami gangguan 16 kali lebih tinggi dibanding model lain
  • Server yang pernah crash sangat mungkin crash lagi, dan 80% server yang pernah mengalami satu crash mengalami crash kedua dalam 24 jam

Penggantian motherboard dan keterbatasan v2

  • Ubicloud mengirimkan tiket dukungan terperinci ke Hetzner yang mencakup kecurigaan pembatasan daya dan data AFR
  • Hetzner tidak mengonfirmasi maupun membantah kemungkinan pembatasan daya, tetapi memberi tahu bahwa mereka telah mengonfirmasi adanya cacat batch motherboard
  • Hetzner telah menerima motherboard dari batch baru dan merekomendasikan penggantian motherboard pada server yang terdampak
  • Penggantian server dalam skala besar dapat memengaruhi workload pelanggan, tetapi karena crash berulang, sebagian besar pekerjaan penting sudah dipindahkan dari AX162 sehingga penggantian dapat dilakukan
  • Setelah mengganti ke motherboard baru, workload penting tetap tidak dikembalikan ke AX162 dan pemantauan jangka panjang terus dilakukan
  • Awalnya tidak ada crash, tetapi dua minggu kemudian crash juga terjadi pada server yang memakai motherboard baru
    • AX162 -v2: 11 gangguan, total layanan 758 hari, AFR 5,30
  • v2 lebih jarang crash dibanding AX162 sebelumnya, tetapi tingkat gangguannya masih tinggi

Hasil stabil pada v3

  • Setelah menghubungi Hetzner lagi, diketahui bahwa ada versi motherboard terbaru dengan keandalan yang lebih baik
  • Server dimigrasikan ke versi terbaru dan keandalannya dipantau
  • Setelah mengamati server baru selama beberapa bulan, masalah crash AX162 dinilai telah terselesaikan
  • Perbandingan AFR akhir adalah sebagai berikut
    • AX161: 11 gangguan, total layanan 3.784 hari, AFR 1,06
    • AX162: 34 gangguan, total layanan 737 hari, AFR 16,84
    • AX162 -v2: 11 gangguan, total layanan 758 hari, AFR 5,30
    • AX162 -v3: 4 gangguan, total layanan 3.738 hari, AFR 0,39
  • AFR AX162 -v3 bahkan lebih rendah daripada AX161

Perbaikan proses operasional

  • Jika lini server baru diadopsi terlalu awal, masalah yang tidak terduga bisa muncul
  • Spesifikasi AX162 menarik, dan fakta bahwa Hetzner menghentikan AX161 juga tampak seperti sinyal bahwa lini baru tersebut siap untuk produksi
  • Mereka menilai banyak masalah bisa dihindari jika menunggu 6 bulan
  • Perubahan ke depan adalah sebagai berikut
    • Melakukan validasi yang lebih menyeluruh untuk model server baru
    • Mengadopsi hardware baru secara bertahap, dimulai dari workload nonkritis
    • Menambahkan lebih banyak penyedia bare metal untuk mendistribusikan risiko
  • Ubicloud sudah mendukung dua penyedia bare metal tambahan, Leaseweb dan Latitude, dan penambahan penyedia keempat juga sedang berlangsung

Bacaan terkait

1 komentar

 
GN⁺ 2025-02-21
Opini Hacker News

  • Model AX lain (AX42, AX52, AX102) juga memiliki masalah keandalan serius yang rusak setelah beberapa bulan
    Karena berbasis mainboard yang cacat, Hetzner harus mengganti sebagian besar, mungkin semua, mainboard server yang dibuat sebelum tanggal tertentu dalam 12 bulan ke depan [0]
    [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

    • Saya memakai dua AX42; satu stabil sejak saya mendapatkannya saat diskon Eurocup, sementara yang lain sudah diganti dua kali sejauh ini
      Unit pengganti terbaru tampaknya bertahan, jadi berdasarkan sampel kecil, terlihat seperti tingkat kegagalan 50%. Angka sebenarnya mungkin hanya Hetzner dan ASRock yang tahu

  • Di perusahaan lama, tim DevOps sering menemukan kerusakan kipas CPU pada mesin Hetzner
    Ini terpisah dari kerusakan HDD/SSD yang umumnya diperkirakan, dan harus dimonitor sendiri. Itu salah satu alasan server yang tidak dikelola lebih murah daripada instance cloud

    • Di Azure pun saya sering melihat unit pendingin yang rusak, dan ketika bekerja di Google hal itu juga menjadi masalah kecil tetapi terus-menerus
      Pada hari pertama bergabung di Dropbox, saya bilang kepada tim bahwa “saya bisa menemukan mesin di dalam fleet yang berjalan pada 400MHz”, dan ternyata benar. Pengendali PSU redundan yang salah sedang memicu PROCHOT. Kalau mesinnya banyak, hal seperti ini akan terjadi
    • Tidak dikelola berarti Anda mendapat akses level silikon dan KVM jarak jauh, bukan berarti tanggung jawab perangkat keras fisik berpindah ke pelanggan
      Memiliki, memelihara, dan memperbaiki perangkat fisik dengan benar tetap menjadi tanggung jawab perusahaan hosting, termasuk monitoring. Dulu Anda harus memasang skrip atau paket untuk menghubungkannya ke monitoring, tetapi sekarang ketika IPMI dan sejenisnya sudah menjadi standar, hal itu bisa dilakukan tanpa bantuan pelanggan
      Jika bukan sekadar menyediakan ruang rak, listrik, dan jaringan, sejauh mana tanggung jawabnya adalah soal kontrak. Jika Hetzner bahkan tidak bisa mendeteksi kerusakan kipas CPU pada hardware mereka sendiri dan menerapkan sistem baru tanpa pengujian yang memadai, itu terlihat sebagai bukti bahwa mereka terus terpeleset
    • Saya sangat menentang baik bergantung pada dependensi gratis maupun selalu memilih opsi termurah
      Saat mengevaluasi pembelian, jika Anda hanya berusaha menekan biaya dan menaikkan pendapatan tanpa sedikit pun memikirkan posisi pihak lain, Anda tidak akan bertahan lama kecuali berada di jenis bisnis penjualan yang mencurigakan
      Hardware server sebenarnya sangat murah, dan bagi programmer yang cukup kompeten, sebagian besar program bisa ditangani oleh satu server atau satu mesin virtual saja. Bayarlah 50 dolar per bulan alih-alih 25 dolar per bulan agar mereka punya sedikit margin. Meski begitu, tidak ada jaminan perusahaan itu tidak bangkrut atau menganggap Anda pelanggan berharga; pada akhirnya Anda tetap bergantung pada struktur yang secara keseluruhan menguntungkan berkat pelanggan besar
      Jika bisnis Anda berada di AS, sebaiknya gunakan penyedia hosting AS

  • Saran bahwa “kalau menunggu 6 bulan, banyak masalah bisa dihindari, dan early adopter biasanya menemukan masalah lebih dulu lalu masalah itu diperbaiki kemudian” layak diterapkan pada semua sistem yang membutuhkan stabilitas
    Jika tidak ada masalah keamanan, tunggu beberapa bulan atau tetap tertinggal satu-dua versi

    • GitHub sedang berupaya menambahkan fitur ini ke dependabot: https://github.com/dependabot/dependabot-core/issues/3651
    • Di alam pun ini pola yang sudah lama berhasil. Individu yang lebih tua memakai individu muda yang belum berpengalaman sebagai unit pengujian yang antusias
      Misalnya di hutan, babi hutan tua akan memberi sinyal aman agar anak-anaknya dikirim lebih dulu ke area terbuka yang meragukan. Dalam konteks teknologi, ini mirip menulis artikel blog yang melebih-lebihkan teknologi yang belum siap produksi
    • Saya penulis artikel blog itu. Secara umum, itu memang praktik yang baik
      Meski begitu, setidaknya penderitaan kami membantu mengungkap akar masalah lebih cepat
      Tidak saya tulis di artikel, tetapi ke depannya kami juga mempertimbangkan untuk menerima server lalu membiarkannya idle sekitar sebulan tanpa workload pelanggan sungguhan. Biayanya lebih tinggi, tetapi bisa membantu menemukan masalah laten tanpa berdampak pada pengguna. Dalam kasus kami, crash mulai terjadi 3 minggu setelah server AX162 pertama kami dideploy, jadi diperlukan masa penyangga setidaknya satu bulan, mungkin lebih lama
    • Tergantung sistemnya. Kelly Johnson dari Skunk Works pernah menetapkan salah satu aturan utama: sistem inspeksi yang ada saat ini sesuai dengan maksud persyaratan militer dan harus digunakan juga pada proyek baru, dengan lebih banyak tanggung jawab inspeksi dasar dialihkan ke subkontraktor dan vendor serta tidak menduplikasi inspeksi
      Namun ini mungkin pertama sekaligus terakhir kalinya Ubicloud memakai model baru atau tranche pembelian baru tanpa burn-in. Saya juga bekerja di sana dan merupakan salah satu co-founder

  • Dell juga kadang mengalami masalah seperti ini. Saat menerima batch pertama server lama, server sempat kehilangan perangkat di sisi I/O belakang sehingga bagian I/O belakang pada mainboard harus diganti
    Misalnya controller Ethernet, iDRAC, dan kadang bahkan BIOS menghilang. Setelah masalah ini dibereskan, server berjalan baik hampir 10 tahun
    Belakangan server itu dipensiunkan karena semuanya mulai aus, dari kartu RAID sampai regulator daya. Mengubah konfigurasi lalu me-reboot server yang sebelumnya berjalan baik, kemudian kehilangan kartu RAID selamanya karena electromigration mengikis trace internal prosesor RAID, adalah pengalaman yang sangat menyadarkan

    • Dell memang punya sangat banyak masalah. Satu mini board rusak pada LED depan bisa membuat server tidak bisa boot atau berjalan sama sekali, dan dalam kasus itu DRAC juga mati

  • Katanya Hetzner tidak mengonfirmasi maupun membantah kemungkinan pembatasan daya, jadi saya penasaran apa akibat dari pembatasan daya itu
    Di tulisan tersebut disebutkan bahwa perangkat keras bisa terdegradasi lebih cepat, tapi saya tidak paham kenapa
    Melihat tidak adanya respons dari Hetzner dan hasil pengukuran UbiCloud, sepertinya memang ada pembatasan daya. Kalau tidak, mereka pasti akan bilang tidak

    • Saya sudah melihat hal serupa di berbagai produk cloud: CPU scaling governor disetel ke nilai ramah lingkungan yang hanya menguntungkan penyedia cloud, sama sekali tidak menguntungkan pengguna, dan hanya memangkas performa CPU maksimum secara signifikan
      Untuk memeriksanya, jalankan cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Nilainya seharusnya performance
      Kalau bukan, bisa disetel dengan echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Ini membantu untuk workload yang banyak memakai CPU. Karena akan kembali seperti semula setelah reboot, pertahankan dengan cron/systemd atau sejenisnya
      Tentu saja kalau Anda membayar listrik sendiri atau memakai hardware sendiri, scaling governor bisa diputuskan sendiri. Tapi untuk server bare metal sewaan, performance adalah pilihan yang tepat

  • Bagian bahwa operator pusat data membatasi pemakaian daya per server untuk menambah jumlah mesin dalam batasan daya, dan bahwa ini bisa mempercepat degradasi motherboard, terasa berlawanan dengan intuisi
    Dari pencarian sekilas juga, pembatasan daya tampaknya justru memperpanjang umur efektif berbagai komponen
    Hasil pencarian yang menyatakan sebaliknya hanya membahas bahwa suhu operasi tinggi saat terkena thermal throttling bisa mempercepat degradasi komponen seperti kapasitor. Namun tulisan itu melihat beberapa sensor suhu, dan secara eksplisit bukan kasus itu

    • Saat melakukan investigasi, saya menemukan beberapa tulisan bahwa pembatasan daya bisa menyebabkan degradasi hardware, tetapi sekarang saya tidak punya sumber pastinya
      Balasan di bawah membagikan satu contoh, dan setelah mencari, ada beberapa sumber lagi [1], [2]
      Namun saya bukan insinyur elektronika, jadi pemahaman saya mungkin tidak sepenuhnya akurat. Bisa saja degradasinya bukan karena pembatasan daya itu sendiri, melainkan karena fluktuasi daya, atau ada faktor lain
      [1] https://electronics.stackexchange.com/questions/65837/can-el...
      [2] https://superuser.com/questions/1202062/what-happens-when-ha...
    • Daya = tegangan × arus
      Tegangan adalah nilai yang dipasok perusahaan listrik, dan arus dipantau per rak. Respons umum ketika sebuah pusat data melampaui batas arus adalah sekring putus atau diminta membayar lebih banyak
      Satu-satunya cara mengurangi daya yang dipakai server adalah men-throttle CPU. Biasanya CPU di-throttle melalui sistem operasi, jadi dibutuhkan kerja sama
      Saya menduga ini mungkin bisa dilakukan melalui lights-out baseband controller tanpa keterlibatan OS, tetapi kalau begitu kemungkinan besar akan terlihat di /sys
    • Aneh. Selama ini saya selalu membaca bahwa daya dan suhu yang tinggi membuat perangkat elektronik jauh lebih cepat terdegradasi. Ada insinyur elektronika yang bisa menjelaskan?
    • Semua rak di pusat data memiliki anggaran daya, dan dalam praktiknya dibatasi oleh jumlah panas yang bisa dikeluarkan sistem pendingin dari pusat data, bukan oleh jumlah daya yang tersedia
      Meski begitu, pembatasan tetap dilakukan per rak agar beberapa server berdaya tinggi tidak menjatuhkan area pusat data yang lebih besar
      Saya tidak tahu pasti metode pembatasannya, tetapi pemutus arus sederhana seperti di rumah bisa menjadi solusi mudah. Jika begitu, saat terputus daya rak akan mati dan berdampak pada seluruh rak serta banyak pelanggan, jadi itu tidak ideal
      Opsi lain adalah pembatas arus/daya[0], tetapi karena P = U * I, itu bisa menimbulkan lebih banyak masalah. Tegangan (U) turun sehingga seluruh sistem mengalami kondisi undervoltage, lalu muncul glitch aneh. Ini juga cara umum untuk melewati berbagai mekanisme keamanan pada chip. Raspberry Pi juga mengadakan tantangan[1] untuk menemukan bug semacam ini dan menguji seberapa tahan chip terhadap serangan, termasuk serangan tegangan
      [0] - https://en.m.wikipedia.org/wiki/Current_limiting
      [1] - https://www.raspberrypi.com/news/security-through-transparen...
    • Satu kemungkinan adalah pada setelan daya rendah, CPU menjadi tidak terlalu panas, sehingga kipas berputar lebih pelan, dan komponen lain juga menerima aliran udara lebih sedikit sehingga justru menjadi lebih panas
      Biasanya solusinya adalah memantau juga suhu komponen lain itu dan memasukkannya sebagai input ke algoritme kecepatan kipas. Saya tidak tahu apakah itu yang benar-benar terjadi di sini

  • Tidak bisa dipastikan, tetapi ini bisa saja masalah daya/sinyal atau VRM
    Fakta bahwa CPU tidak panas bukan berarti komponen lain di board tidak berada di luar spesifikasi dan masuk ke kegagalan fatal
    Masalah motherboard di sekitar daya/sinyal sangat menyebalkan untuk didiagnosis. Dari luar, gejalanya bisa muncul sebagai segala macam masalah yang tampak seperti masalah komponen lain, dan berdasarkan pengalaman, kegagalan inisialisasi RAM serta restart acak sangat umum. Pada akhirnya Anda akan mengganti semuanya sebelum benar-benar mengganti motherboard

  • Saya juga mengalami hal serupa di AX102 yang saya pakai sekarang, dan sepertinya crash karena masalah terkait kartu jaringan
    Untungnya dukungan Hetzner menangani hardware pengganti dengan baik. Cukup merepotkan, tetapi ini jadi kesempatan bagus untuk belajar troubleshooting hardware, dan secara pribadi menurut saya sepadan

    • Saya juga sama. AX102 crash meski hampir tidak ada beban, tidak ada apa pun di log, dan tidak mau menyala lagi
      Hetzner memeriksanya beberapa kali tetapi tidak menemukan apa pun, atau hanya mengganti thermal paste CPU dan konektor PSU. Saya pindah ke AX162 dan sejauh ini baik-baik saja

  • Apakah ada orang yang punya pengalaman di pusat data yang bisa menebak penyelesaian komersial seperti apa yang mungkin dilakukan Hetzner di sini dengan pemasok motherboard?
    Apakah harus dianggap bahwa mereka mendapat penggantian semua motherboard secara gratis, bahkan sampai kompensasi?

    • Kalau membeli server dari merek ternama, hardware yang cacat pasti bisa diganti.
      Kompensasi hanya mungkin jika dinegosiasikan sebelumnya, dan dalam kasus itu harus membayar biaya tambahan. Daripada mencoba menagih biaya downtime ke vendor, kemungkinan lebih baik membeli sesuatu seperti asuransi gangguan bisnis. Itu tetap berlaku meskipun kesalahannya ada pada vendor.
      Hetzner bukan pelanggan biasa. Sebagai bagian dari optimasi biaya yang ekstrem, kemungkinan besar mereka membeli komponen termurah, dan mungkin juga menegosiasikan harga lebih rendah tanpa garansi. Jika begitu, mereka harus membeli sendiri motherboard penggantinya.
    • Sepertinya sejak awal mereka mendapatkan batch ini dengan sangat murah. Karena server-server tersebut awalnya ditawarkan tanpa biaya instalasi.
      Itu adalah masa ketika Piala Dunia sepak bola digelar di Jerman.

  • Saya baru pertama kali mendengar, dan cukup terkejut, bahwa operator pusat data membatasi konsumsi daya per server karena keterbatasan daya, dan hal itu bisa membuat degradasi motherboard menjadi lebih cepat.