Hetzner AX162 arızalarını powerstat, sensors ve dmidecode ile izlemek

 (ubicloud.com)
1 puan yazan GN⁺ 2025-02-21 | 1 yorum | WhatsApp'ta paylaş
  • Ubicloud, Hetzner’ın yeni AX162 sunucusunu AX161’e göre performans ve fiyat açısından daha iyi göründüğü için devreye aldı; ancak işletim sırasında arızaların 16 kat daha sık yaşandığı bir güvenilirlik sorunuyla karşılaştı
  • Kök neden arayışı, NULL baytlar kalan sistem günlüklerinden başladı; yük, sıcaklık, parça bilgileri ve güç tüketimini sırayla eleme yöntemiyle ilerledi ve sensors, dmidecode, powerstat temel araçlar oldu
  • İlk verilerde AX161, 3.784 günlük hizmet süresinde 11 arızayla 1,06 AFR’ye sahipken AX162, 737 günde 34 arızayla 16,84 AFR kaydetti
  • Bir kez arıza yaşayan sunucuların %80’i 24 saat içinde ikinci bir arıza yaşadı; Hetzner, güç sınırlaması olup olmadığını doğrulamadan anakart parti kusuru olduğunu bildirdi
  • En yeni anakarta taşınan AX162 -v3, birkaç aylık izlemenin ardından AFR’yi 0,39’a kadar düşürdü; yeni donanımlar önce kritik olmayan iş yüklerinden başlayarak aşamalı doğrulanmalı

AX162 devreye alındıktan sonra tekrarlayan çökmeler

  • Ubicloud, bare metal sağlayıcılarını bulut platformuna dönüştüren yazılımlar geliştiriyor ve Hetzner’ı uygun fiyatlı, güvenilir bir sunucu sağlayıcısı olarak kullanıyordu
  • Hetzner’ın AX162 sunucu serisi, önceki model AX161’e göre daha iyi performans ve daha düşük fiyat sunduğu için hızla devreye alındı
  • İlk AX162 sunucusunun satın alınmasından 3 hafta sonra bir sunucu çöktü ve sistem günlüklerinde NULL baytlar kaldı
    • Bu, güç kaybı gibi yazma işlemlerinin düzgün tamamlanamadığı ani bir arıza sinyali olarak yorumlandı
  • Hetzner’ın donanım kontrolünde başlangıçta bir anormallik bulunmadı; ancak bir hafta sonra başka bir çökme daha yaşandı ve birkaç gün içinde arızalar tekrarlandı

Arızanın ortaya çıkış biçimi

  • Tüm çökmeler yalnızca AX162 sunucularında meydana geldi
  • Arızalar iki biçime ayrılıyordu
    • Manuel yeniden başlatmadan sonra sunucunun tekrar çevrimiçi olması
    • Yeniden başlatma isteğine veya Hetzner mühendisinin tanı kodlarına yanıt vermemesi ve sunucunun değiştirilmesinin gerekmesi
  • Sunucu genellikle uzun süre normal çalışıyor, ilk çökmeden sonra ise ek çökme olasılığı artıyordu
  • Birinci tür çökme birkaç kez tekrarlandıktan sonra sonunda ikinci türe dönüştüğü ve sunucunun değiştirildiği bir akış gözlemlendi

Önce yük ve sıcaklığın elenmesi

  • AX162 96 vCPU sunuyordu ve Ubicloud’da tüm vCPU’ları aynı anda kullanan iş yükleri vardı
  • Yüksek yükün sıcaklık artışı veya beklenmeyen sorunlar yaratabileceği hipotezi incelendi; ancak çökmeler düşük yükte veya hiç yük yokken de meydana geldi
  • Sıcaklık ile arıza arasındaki korelasyonu görmek için sensors komutuyla sistem bileşenlerinin sıcaklıkları toplandı
  • Basit bir cron göreviyle sıcaklık verileri toplandı; tekrar çökme olduğunda kontrol edilen sıcaklıklar ortalamanın belirgin biçimde üzerinde değildi

Parça bilgileri ve güç tüketimi araştırması

  • lshw ve dmidecode ile donanım parçalarının model ve seri numaraları kontrol edildi
  • Çöken AX162 sunucularla çökmeyen sunucuların parçaları karşılaştırıldı, ancak anlamlı bir fark bulunmadı
  • Eski parçaların daha sık arızalanma olasılığı nedeniyle seri numarası artış eğilimi de kontrol edildi; fakat en yeni seri numaralarına sahip sunucularda da çökmeler yaşandı
  • Veri merkezi genişlemelerinde çoğu zaman alan değil güç kısıt haline gelir ve operatörler makine başına güç kullanımını sınırlayabilir
    • Ubicloud, Hetzner’ın güç tüketimini sınırlayıp sınırlamadığını bilmiyordu; ancak uzun süre kararlı çalıştıktan sonra tekrarlayan çökmelerin ortaya çıkmasını donanım yıpranmasıyla uyumlu gördü
    • Diğer hipotezler tek tek elendikten sonra güç sınırlaması güçlü bir hipotez olarak kaldı
  • powerstat -R ile uzun süreli maksimum güç tüketimi ölçüldü ve reklamı yapılan değerlerle karşılaştırıldı
    • AX161: reklamı yapılan maksimum güç 147W, ölçülen maksimum güç 168W
    • AX162: reklamı yapılan maksimum güç 408W, ölçülen maksimum güç 266W
  • Bu fark nedeniyle Hetzner’ın gerçek güç kullanımını sınırlıyor olabileceğinden şüphelenildi

AFR’ye göre arıza oranı

  • Donanım güvenilirliği karşılaştırması için Annualized Failure Rate(AFR) kullanıldı
  • AFR’nin sınırlamaları olsa da arıza oranlarını karşılaştırmak için yeterince basit bir başlangıç metriğiydi
  • İlk ölçüm sonuçlarında AX162’nin arıza oranı AX161’den çok daha yüksekti
    • AX161: 11 arıza, toplam 3.784 gün hizmet, AFR 1,06
    • AX162: 34 arıza, toplam 737 gün hizmet, AFR 16,84
  • Bu veriler, AX162’nin diğer modellere kıyasla arıza yaşama olasılığının 16 kat daha yüksek olduğu gözlemini destekledi
  • Bir kez çöken sunucunun tekrar çökme olasılığı çok yüksekti; bir çökme yaşayan sunucuların %80’i 24 saat içinde ikinci bir çökme yaşadı

Anakart değişimi ve v2’nin sınırları

  • Ubicloud, güç sınırlaması şüphesi ve AFR verilerini içeren ayrıntılı bir destek talebini Hetzner’a iletti
  • Hetzner, güç sınırlaması olasılığını doğrulamadı ya da reddetmedi; ancak anakart parti kusuru tespit ettiğini bildirdi
  • Hetzner, yeni bir parti anakart aldığını ve etkilenen sunucuların anakartlarının değiştirilmesini önerdi
  • Büyük ölçekli sunucu değişimi müşteri iş yüklerini etkileyebilirdi; ancak tekrarlayan çökmeler nedeniyle kritik işlerin çoğu zaten AX162’den taşınmış olduğundan değişim mümkün oldu
  • Yeni anakart takıldıktan sonra bile kritik iş yükleri AX162’ye geri alınmadı ve uzun süreli izleme sürdürüldü
  • Başta çökme olmadı, ancak 2 hafta sonra yeni anakart takılı sunucularda da çökme yaşandı
    • AX162 -v2: 11 arıza, toplam 758 gün hizmet, AFR 5,30
  • v2, mevcut AX162’ye göre daha seyrek çöküyordu; ancak arıza oranı hâlâ yüksekti

v3 ile kararlı hale gelen sonuç

  • Hetzner ile tekrar iletişime geçildikten sonra, güvenilirliği daha da iyileştirilmiş en yeni anakart sürümü olduğu öğrenildi
  • Sunucular en yeni sürüme geçirildi ve güvenilirlik izlendi
  • Yeni sunucular birkaç ay gözlemlendikten sonra AX162’nin çökme sorununun çözüldüğüne karar verildi
  • Nihai AFR karşılaştırması şöyleydi
    • AX161: 11 arıza, toplam 3.784 gün hizmet, AFR 1,06
    • AX162: 34 arıza, toplam 737 gün hizmet, AFR 16,84
    • AX162 -v2: 11 arıza, toplam 758 gün hizmet, AFR 5,30
    • AX162 -v3: 4 arıza, toplam 3.738 gün hizmet, AFR 0,39
  • AX162 -v3’ün AFR’si AX161’den bile daha düşüktü

Operasyon sürecindeki iyileştirmeler

  • Yeni bir sunucu serisini erken aşamada devreye almak beklenmedik sorunlar yaratabilir
  • AX162’nin teknik özellikleri cazipti ve Hetzner’ın AX161’i sonlandırması da yeni serinin prodüksiyona hazır olduğuna dair bir sinyal gibi görünüyordu
  • 6 ay beklenseydi birçok sorunun önlenebileceği değerlendirildi
  • Bundan sonraki değişiklikler şöyle olacak
    • Yeni sunucu modelleri için daha kapsamlı doğrulama yapılacak
    • Yeni donanımlar, kritik olmayan iş yüklerinden başlayarak kademeli devreye alınacak
    • Riski dağıtmak için daha fazla bare metal sağlayıcısı eklenecek
  • Ubicloud hâlihazırda Leaseweb ve Latitude adlı iki ek bare metal sağlayıcısını destekliyor ve dördüncü sağlayıcının eklenmesi de devam ediyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-21
Hacker News yorumları

  • Diğer AX modellerinde de (AX42, AX52, AX102) birkaç ay sonra arızalanan ciddi bir güvenilirlik sorunu var.
    Kusurlu anakart temelinde oldukları için Hetzner, belirli bir tarihten önce üretilen sunucuların anakartlarını önümüzdeki 12 ay içinde büyük ölçüde, belki de tamamını değiştirmek zorunda [0].
    [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

    • İki AX42 kullanıyorum; biri Eurocup indirim döneminde aldığımdan beri stabildi, diğeri ise şimdiye kadar iki kez değiştirildi.
      Son değişim ürünü dayanıyor gibi görünüyor; küçük bir örnekleme göre arıza oranı %50 gibi duruyor. Gerçek rakamları muhtemelen yalnızca Hetzner ve ASRock biliyordur.

  • Eski şirketimde DevOps, Hetzner ekipmanlarında sık sık CPU fanı arızası tespit ediyordu.
    Bu, genelde beklenen HDD/SSD arızalarından ayrıydı ve doğrudan izlenmesi gerekiyordu. Yönetilmeyen sunucuların bulut instance’larından daha ucuz olmasının nedenlerinden biri bu.

    • Azure’da da arızalı soğutma birimlerini sık sık gördüm; Google’da çalışırken de düşük seviyede ama sürekli bir baş ağrısıydı.
      Dropbox’a katıldığım ilk gün ekibe “fleet içinde 400MHz’de çalışan bir makine bulabilirim” dedim ve gerçekten de buldum. Hatalı bir yedekli PSU kontrolcüsü PROCHOT tetikliyordu. Çok makineniz varsa böyle şeyler olur.
    • Yönetilmeyen olması, silikon düzeyinde erişim ve uzaktan KVM aldığınız anlamına gelir; fiziksel donanım sorumluluğunun müşteriye geçtiği anlamına gelmez.
      Fiziksel ekipmanı düzgün şekilde sahiplenmek, bakımını yapmak ve onarmak hâlâ hosting şirketinin sorumluluğudur; buna izleme de dahildir. Eskiden izlemeye bağlanmak için script veya paket kurmak gerekirdi, ama IPMI vb. artık standart olduğundan bunu müşterinin yardımı olmadan da yapabilirler.
      Yalnızca rack alanı, güç ve ağ sağlanan bir durum değilse, nereye kadar sorumluluk alınacağı sözleşme meselesidir. Hetzner kendi donanımındaki CPU fanı arızasını bile yakalayamıyor ve yeni sistemleri yeterince test etmeden dağıtıyorsa, bu sürekli tökezlediğinin kanıtı gibi görünüyor.
    • Hem ücretsiz bağımlılıklara yaslanmaya hem de sadece en ucuz seçeneği seçmeye şiddetle karşıyım.
      Bir satın almayı değerlendirirken karşı tarafın durumunu bir an bile düşünmeden yalnızca maliyeti düşürüp geliri artırmaya çalışırsanız, şaibeli satış sektörleri dışında uzun süre ayakta kalamazsınız.
      Sunucu donanımı gerçekten ucuz; belli düzeyde yetkin bir programcı için çoğu program tek bir sunucu ya da sanal makineyle bile kaldırılabilir. Ayda 25 dolar yerine ayda 50 dolar ödeyip biraz marj bırakmalısınız. Yine de o şirketin batmayacağının ya da sizi değerli bir müşteri olarak göreceğinin garantisi yok; sonuçta büyük müşteriler sayesinde bütünün kârlı olduğu bir yapıya yaslanmış oluyorsunuz.
      İşiniz ABD’deyse ABD’li bir hosting sağlayıcısı kullanmak doğru olur.

  • “6 ay bekleseydiniz pek çok sorundan kaçınabilirdiniz; erken benimseyenler genelde sorunları önce bulur ve bunlar sonradan düzeltilir” tavsiyesi, kararlılık gerektiren tüm sistemler için geçerli sayılabilir.
    Güvenlik sorunu yoksa birkaç ay beklerim ya da bir iki sürüm geride kalırım.

    • GitHub bunu dependabot’a eklemeye çalışıyor: https://github.com/dependabot/dependabot-core/issues/3651
    • Doğada da uzun süredir başarılı olan bir örüntü. Yaşlı bireylerin genç ve deneyimsiz bireyleri hevesli test birimleri olarak kullanması.
      Örneğin ormanda yaşlı bir yaban domuzu, güvenilmesi zor bir açıklığa önce yavruları göndermek için güvenli sinyali verir. Teknoloji tarafına uyarlarsak, henüz production’a hazır olmayan bir teknolojiyi abartan blog yazıları yazmaya benzer.
    • Blog yazısının yazarıyım. Genel olarak iyi bir pratik olduğu doğru.
      Yine de yaşadığımız zorlukların kök nedenin daha hızlı ortaya çıkmasına yardımcı olması en azından iyi oldu.
      Yazıda belirtmedim ama ileride sunucuyu teslim alıp gerçek müşteri workload’u olmadan yaklaşık bir ay boşta bırakmayı da düşündük. Daha maliyetli olur, ancak kullanıcıları etkilemeden potansiyel sorunları bulmaya yardımcı olabilir. Bizim durumda ilk AX162 sunucusunu dağıttıktan 3 hafta sonra crash’ler başladı; bu yüzden en az bir ay, belki daha da uzun bir tampon süre gerekiyor.
    • Sisteme göre değişir. Skunk Works’ten Kelly Johnson, ana kurallarından biri olarak mevcut denetim sisteminin askerî gereksinimlerin ruhuna uygun olduğunu ve yeni projelerde de kullanılması gerektiğini; temel denetim sorumluluğunun daha fazlasının taşeronlara ve tedarikçilere devredilmesini, denetimlerin de yinelenmemesini söylemişti.
      Ancak Ubicloud’un yeni bir modeli ya da satın alma tranche’ini burn-in olmadan kullanması muhtemelen ilk ve son kez olacak. Ben de orada çalışıyorum ve kurucu ortağım.

  • Dell’de de bazen böyle sorunlar oluyor. Eski bir sunucu serisinin ilk partisini aldığımızda, sunucu bir süre arka I/O tarafındaki aygıtları kaybediyordu; bu yüzden anakartın I/O arka bölümünü değiştirmek gerekti.
    Örneğin Ethernet kontrolcüsü, iDRAC, hatta bazen BIOS bile kayboluyordu. Bu sorunu atlattıktan sonra neredeyse 10 yıl boyunca sorunsuz çalıştı.
    Yakın zamanda RAID kartından güç regülatörlerine kadar her şey yıprandığı için emekliye ayırdık. Yapılandırma değişikliği nedeniyle düzgün çalışan bir sunucuyu yeniden başlatıp, elektromigrasyon yüzünden RAID işlemcisinin iç yolları aşındığı için RAID kartını temelli kaybetmek insanı kendine getiren bir deneyim.

    • Dell’in gerçekten çok sorunu var. Ön LED’deki kusurlu küçük bir kart, sunucunun boot etmesini ya da çalışmasını tamamen engelleyebiliyor; o durumda DRAC da ölüyor.

  • Hetzner'ın güç sınırlaması olasılığını ne doğruladığı ne de reddettiği söyleniyor; güç sınırlamasının sonucunun ne olduğunu merak ediyorum.
    Yazıda donanımın daha hızlı yıpranabileceği söyleniyor ama nedenini anlayamadım.
    Hetzner'ın yanıtsızlığına ve UbiCloud'un ölçümlerine bakınca gerçekten gücü sınırlıyor gibi görünüyor. Öyle olmasa “hayır” derlerdi.

    • Benzer şeyi çeşitli bulut ürünlerinde zaten gördüm: CPU scaling governor, yalnızca bulut sağlayıcısına fayda sağlayan çevreci bir değere ayarlanmış oluyor; kullanıcıya hiçbir faydası yok ve yalnızca maksimum CPU performansını ciddi biçimde düşürüyor.
      Kontrol etmek için cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor çalıştırılabilir. Değer performance olmalı.
      Değilse echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor ile ayarlanabilir. CPU'yu yoğun kullanan iş yüklerinde işe yarar. Yeniden başlatınca eski hâline döneceği için cron/systemd vb. ile kalıcı tutulabilir.
      Elbette elektrik faturasını doğrudan ödüyorsanız ya da donanım size aitse scaling governor konusunda kendiniz karar verebilirsiniz. Ama kiralık bare-metal sunucuda doğru seçim performancetır.

  • Veri merkezi işletmecisinin güç kısıtları içinde makine sayısını artırmak için sunucu başına güç kullanımını sınırlaması ve bunun anakartın daha hızlı yıpranmasına yol açabilmesi kısmı sezgilere ters geliyor.
    Üstünkörü baktığımda da güç sınırlamasının çeşitli bileşenlerin etkin ömrünü uzatma yönünde olduğu görülüyordu.
    Aksini iddia eden arama sonuçları yalnızca thermal throttling'e girildiğinde yüksek çalışma sıcaklığının kapasitör gibi bileşenleri daha hızlı yıpratabileceğinden bahsediyordu. Oysa yazıda birden çok sıcaklık sensörüne bakılmıştı ve bu durumun açıkça söz konusu olmadığı belirtilmişti.

    • Araştırma sırasında güç sınırlamasının donanım yıpranmasına yol açabileceğini söyleyen birkaç yazı bulmuştum ama şu an tam kaynaklar elimde yok.
      Aşağıdaki yanıtta bir örnek paylaşılmış, arayınca birkaç kaynak daha çıktı [1], [2].
      Ancak elektronik mühendisi olmadığım için anlayışım tamamen doğru olmayabilir. Yıpranma güç sınırlamasının kendisinden değil güç dalgalanmasından kaynaklanmış olabilir ya da başka bir etken olabilir.
      [1] https://electronics.stackexchange.com/questions/65837/can-el...
      [2] https://superuser.com/questions/1202062/what-happens-when-ha...
    • Güç = gerilim × akımdır.
      Gerilim elektrik şirketinin sağladığı değerdir, akım ise raf bazında izlenir. Veri merkezinde akım sınırı aşıldığında tipik tepki sigortanın atması ya da daha fazla para istenmesidir.
      Sunucunun kullandığı gücü azaltmanın tek yolu CPU'yu throttle etmektir. Genelde CPU işletim sistemi üzerinden throttle edilir, dolayısıyla iş birliği gerekir.
      OS müdahalesi olmadan lights-out baseband controller ile mümkün olabileceğini tahmin ediyorum, ama öyleyse bunun /sys içinde görünme olasılığının yüksek olduğunu düşünüyorum.
    • Garip. Hep yüksek güç ve sıcaklığın elektronik cihazları çok daha hızlı yıprattığını okudum. Bir elektronik mühendisi açıklayabilir mi?
    • Veri merkezindeki her rafın bir güç bütçesi vardır ve pratikte bu bütçe kullanılabilir güç miktarından çok, iklimlendirme sisteminin veri merkezinden uzaklaştırabileceği ısı miktarıyla sınırlanır.
      Yine de birkaç yüksek güçlü sunucunun veri merkezinin daha büyük bir bölümünü devirmemesi için raf bazında sınır koyarlar.
      Sınırlandırma yöntemini kesin bilmiyorum, ama evdeki gibi basit bir devre kesici kolay çözüm olabilir. Bu durumda kesinti olduğunda rafın elektriği gider; tüm rafı ve birden fazla müşteriyi etkilediği için ideal değildir.
      Diğer seçenek akım/güç sınırlayıcı[0]dır; ancak P = U * I olduğundan daha fazla sorun yaratabilir. Gerilim (U) düşer, tüm sistem düşük gerilim durumuna girer ve tuhaf glitch'ler oluşur. Bu aynı zamanda çiplerdeki çeşitli güvenlik mekanizmalarını aşmanın yaygın bir yoludur. Raspberry Pi de bu tür hataları bulmak ve çipin gerilim saldırıları dâhil saldırılara ne kadar dayanabildiğini test etmek için bir challenge[1] düzenlemişti.
      [0] - https://en.m.wikipedia.org/wiki/Current_limiting
      [1] - https://www.raspberrypi.com/news/security-through-transparen...
    • Bir olasılık şu: düşük güç ayarında CPU daha az ısınıyor, bu yüzden fanlar daha az dönüyor ve diğer bileşenler de daha az hava akışı aldığı için tersine daha sıcak çalışıyor.
      Normal çözüm, o diğer bileşenlerin sıcaklıklarını da izleyip fan hızı algoritmasının girdisine katmaktır. Burada gerçekten bunun yaşanıp yaşanmadığını bilmiyorum.

  • Bilmek mümkün değil ama güç/sinyal ya da VRM sorunu da olabilir.
    CPU'nun sıcak olmaması, karttaki başka bir şeyin spesifikasyon dışına çıkıp ölümcül arızaya girmediği anlamına gelmez.
    Güç/sinyal çevresindeki anakart sorunlarını teşhis etmek berbat zordur. Dışarıdan başka bileşen sorunları gibi görünen her tür belirtiyle ortaya çıkarlar; deneyimime göre RAM başlatma hataları ve rastgele yeniden başlatmalar çok yaygındır. Sonunda gerçekten anakartı değiştirmeden önce her şeyi değiştirmiş olursunuz.

  • Şu anda kullandığım AX102'de de benzer bir şey yaşadım; ağ kartıyla ilgili bir sorun yüzünden crash oluyormuş gibi görünüyordu.
    Neyse ki Hetzner desteği yedek donanım işini iyi yönetti. Epey baş ağrıttı ama donanım sorun gidermeyi öğrenmek için iyi bir fırsattı ve kişisel olarak buna değdi.

    • Bende de aynıydı. AX102 neredeyse hiç yük altında değilken crash oluyordu, loglarda hiçbir şey yoktu ve tekrar açılmıyordu.
      Hetzner birkaç kez baktı ama hiçbir şey bulamadı ya da sadece CPU termal macununu, PSU konnektörünü değiştirdi. AX162'ye geçtim ve şu ana kadar sorun yok.

  • Veri merkezi deneyimi olan biri, Hetzner’ın burada anakart tedarikçisiyle nasıl bir ticari çözüme gitmiş olabileceğini tahmin edebilir mi?
    Tüm anakartların ücretsiz değiştirildiğini ve üstüne tazminat da aldığını mı varsaymalıyız?

    • Tanınmış markalı sunucular satın alırsanız kusurlu donanımın kesinlikle değiştirileceğini bilirsiniz.
      Tazminat ise ancak önceden müzakere edilmişse mümkündür; bu durumda da ek ücret ödemeniz gerekir. Kesinti maliyetini tedarikçiden almaya çalışmaktansa iş kesintisi sigortası gibi bir şey satın almak muhtemelen daha mantıklıdır. Hata tedarikçide olsa bile durum böyledir.
      Hetzner sıradan bir müşteri değil. Aşırı maliyet optimizasyonunun bir parçası olarak en ucuz parçaları satın alma olasılığı yüksek; hatta garanti olmadan daha düşük bir fiyat için pazarlık etmiş de olabilir. Öyleyse yedek anakartları kendisinin satın alması gerekmiş olurdu.
    • Zaten bu partiyi çok ucuza almış gibi görünüyor. Çünkü söz konusu sunucular başlangıçta kurulum ücreti olmadan sunulmuştu.
      Almanya’da futbol Dünya Kupası’nın düzenlendiği dönemdi.

  • Bir veri merkezi operatörünün güç kısıtları nedeniyle sunucu başına güç tüketimini sınırladığını ve bunun anakartların daha hızlı yıpranmasına yol açabileceğini ilk kez duydum; oldukça şaşırtıcıydı.