Veri Merkezi Nasıl Ayakta Kalır? Enerji, Soğutma ve Yedekliliğin Fiziği

Bir veri merkezine ilk kez girdiğinizde sizi iki şey karşılar: gürültü ve soğuk. Binlerce fanın ürettiği o sabit uğultu, aslında tek bir cümlenin sesidir — “buradaki hiçbir şeyin durmasına izin verilmiyor.”

Peki bu iddia neye dayanıyor? Sunucular da elektrikle çalışır, onlar da ısınır, kabloları da kopar. Bir ofisteki bilgisayardan farkı, bileşenlerinin daha iyi olması değildir; farkı, her bileşenin ikinci bir kopyasının olması ve bu kopyaların birbirinden ayrı yollardan beslenmesidir.

Bu yazı, o ayrımın nasıl kurulduğunu anlatıyor. Elektriğin şehir şebekesinden çıkıp sunucunun güç kaynağına kadar geçtiği yolu, ısının o yoldan geri çıkarılışını ve bu zincirin hangi halkasında hangi yedekliliğin durduğunu adım adım göreceğiz. Basit kavramlarla başlayıp gerçek bir tasarım kararına — ve sonunda alarm üretmeden ilerleyen bir arızaya — varacağız.

Bu yazıdaki tüm tesis adları, cihaz isimleri, IP adresleri ve ölçüm çıktıları kurgusal bir veri merkezine aittir. Komutlar ve mühendislik kuralları gerçektir; değerler örnektir.

Veri merkezi dünyası kendi kısaltmalarıyla gelir. Tanımadığınız bir terime rastlarsanız yazının sonundaki terimler sözlüğüne bakabilirsiniz.

Bu, iki yazılık bir serinin ilkidir. Burada fiziksel katmanı — enerji, soğutma, rack ve kablolama — ele alıyoruz. İkinci yazı ağ, depolama ve küme yedekliliğini işleyecek.

Veri Merkezi Nedir? “Sunucu Odası"ndan Farkı

Çoğu kurumda bir “sistem odası” vardır: klimalı, kilitli, içinde birkaç rack bulunan bir oda. Bu bir veri merkezi değildir. Aradaki fark cihazlarda değil, kaç tane bağımsız yolun olduğundadır.

Son satır, en çok atlanan ve en pahalıya patlayan satırdır. Ölçmediğiniz bir yedekliliğin var olduğunu varsayarsınız; bu yazının sonundaki vaka tam olarak o varsayımın hikâyesidir.

Kendi başınıza bu katmanların çoğunu deneyimlemek isterseniz, evde kurduğunuz bir homelab mantığı öğrenmek için fazlasıyla yeterlidir — orada eksik olan tek şey, aşağıda anlatacağımız ikinci yoldur.

Bu Yazının Örnek Ortamı: DC-IST1

Kavramları havada bırakmamak için baştan sona tek bir kurgusal tesis kullanacağız.

DC-IST1 · Salon A

Bir veri merkezini katmanlara ayırdığımızda tablo şöyle görünür. Bu yazı ilk üç katmanı kapsıyor:

    
flowchart TB
    L1["1 · Enerji
şebeke · jeneratör · UPS · PDU"]
    L2["2 · Ortam
soğutma · nem · yangın · fiziksel güvenlik"]
    L3["3 · Rack ve Kablolama
rack · A/B besleme · etiketleme"]
    L4["4 · Ağ
ToR · spine · uplink"]
    L5["5 · Depolama
SAN · fabric A/B"]
    L6["6 · Hesaplama
host · küme · hipervizör"]
    L7["7 · Servis
VM · uygulama · veri"]
    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7
    classDef bu fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef son fill:#e2e8f0,stroke:#94a3b8,color:#475569
    class L1,L2,L3 bu
    class L4,L5,L6,L7 son

Katmanların sırası önemlidir: üsttekiler alttakilere bağımlıdır ve tersi doğru değildir. Kusursuz bir Kubernetes kümesi, altındaki PDU’nun kesicisi attığında hiçbir işe yaramaz. Bu yüzden yedekliliği tartışmaya en alttan başlıyoruz.

Yedekliliğin Dili

Elektrik şemasına bakmadan önce dört kavramı oturtmamız gerekiyor. Yazının geri kalanı tamamen bunların üzerine kurulu.

SPOF ve hata alanı

SPOF (Single Point of Failure — tek arıza noktası), tek başına arızalandığında hizmeti durduran bileşendir. Yedekliliğin tanımı basittir: sistemde SPOF bırakmamak.

Ama asıl kavram hata alanıdır (fault domain): tek bir olayla birlikte kaybedilen bileşenler kümesi. İki sunucunuz olabilir, ama ikisi de aynı rack’te ve aynı PDU’ya bağlıysa, o PDU tek bir hata alanıdır — sunucu sayısı ikidir, hata alanı birdir.

Yedekliliği bileşen sayarak değil, hata alanı sayarak ölçün. Bu cümle, bu yazının ve serinin tamamının özetidir.

N, N+1, 2N: yedek sayısı mı, yol ayrılığı mı?

Sektörün ortak gösterimi, ihtiyacı N ile ifade eder:

DC-IST1’de jeneratörler N+1 (üç ünite, ikisi yeterli), UPS’ler ise 2N‘dir (iki bağımsız yol, her biri tek başına tüm yükü taşıyabilir).

Buradaki kritik ayrım şudur ve çoğu tasarım tartışması burada düğümlenir:

N+1, yedek bileşen ekler. 2N, yedek yol ekler.

N+1 bir jeneratör grubunda üç ünite vardır ama hepsi aynı jeneratör barasına, oradan aynı panoya bağlıdır. Bir ünite arızalanırsa sorun yok. Ama o baranın kendisi arızalanır ya da bakıma alınırsa üç ünitenin de bir anlamı kalmaz — çünkü hepsi tek bir hata alanındadır.

2N’de ise A yolu ve B yolu birbirine hiçbir noktada değmez. Tam olarak ESXi’de çift fabric SAN mimarisinde olduğu gibi: iki fabric’i bilerek birbirine bağlamayız, çünkü bağladığımız an tek hata alanına dönüşürler. Elektrikte de kural aynıdır.

Aktif-pasif ve aktif-aktif

İki yol varsa, ikisi de aynı anda çalışıyor mu?

    
flowchart TB
    subgraph AP["AKTİF – PASİF"]
        direction TB
        APY["Yük · 100 birim"]
        APA["Bileşen A
AKTİF · 100 birim taşıyor"]
        APB["Bileşen B
PASİF · 0 birim, bekliyor"]
        APY --> APA
        APY -. "yalnızca arıza anında devralır" .-> APB
    end
    subgraph AA["AKTİF – AKTİF"]
        direction TB
        AAY["Yük · 100 birim"]
        AAA["Bileşen A
AKTİF · 50 birim taşıyor"]
        AAB["Bileşen B
AKTİF · 50 birim taşıyor"]
        AAY --> AAA
        AAY --> AAB
    end
    classDef akt fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef pas fill:#e2e8f0,stroke:#94a3b8,color:#475569
    classDef yuk fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    class APA,AAA,AAB akt
    class APB pas
    class APY,AAY yuk

Aktif-pasif tasarımın sinsi tarafı üçüncü satırdır: pasif bileşen çalıştığını asla kanıtlamaz. Yıllardır bekleyen jeneratörün marş aküsü bitmiş olabilir; yedek pompanın rulmanı kurumuş olabilir. Bunu ancak düzenli test ederek öğrenirsiniz — yazının sonundaki test disiplini bölümünün varlık sebebi budur.

Aktif-aktif tasarımda ise yedek yol her saniye kullanımdadır; bozuksa hemen bilirsiniz. Bedeli bir sonraki başlıkta.

2N’in yazılmayan kuralı: %50

Aktif-aktif iki yol kurduğunuzda kapasitenin tamamını kullanmak cazip gelir. Bu, veri merkezi tasarımının en klasik tuzağıdır.

DC-IST1’de her UPS 300 kW taşıyabiliyor, toplam BT yükü 160 kW. Normal işletmede her yol 80 kW, yani kapasitesinin %27’sini taşır. A yolu düştüğünde B’nin taşıması gereken yük 160 kW olur — hâlâ %53. Güvenli.

Şimdi yükün büyüdüğünü ve her yolun 170 kW taşıdığını düşünün. Tablo sağlıklı görünür: iki UPS de %57’de, alarm yok. Ama A yolu düştüğü an B’nin taşıması gereken yük 340 kW olur; bu, kapasitesinin %113’ü demektir. Sonuç aşırı yük, kesici açması ve tam kesinti — üstelik yedeklilik “vardı”.

2N tasarımın yazılmayan kuralı: Her yol, tek başına toplam yükü taşıyabilecek kadar boş kalmalıdır. Pratikte bu, normal işletmede her yolun %50’nin altında tutulması demektir. Bu kural yalnızca elektrik için değil; çift switch, çift uplink ve çift depolama denetleyicisi için de aynen geçerlidir.

Elektrik Zinciri: Veri Merkezinin Omurgası

Artık şemayı okuyabiliriz. Aşağıda kırmızı hat A yolunu, mavi hat B yolunu, turuncu kesikli hat ise ortak jeneratör beslemesini gösteriyor:

    
flowchart TB
    G1["OG Hat A
bağımsız şebeke girişi"]
    G2["OG Hat B
bağımsız şebeke girişi"]
    GEN["Jeneratör Grubu
3 × 250 kVA · N+1"]
    GB["Jeneratör Barası"]
    TR1["Trafo A
34,5 kV → 0,4 kV"]
    TR2["Trafo B
34,5 kV → 0,4 kV"]
    AT1["ATS-A
şebeke ↔ jeneratör"]
    AT2["ATS-B
şebeke ↔ jeneratör"]
    PA["Ana Pano A"]
    PB["Ana Pano B"]
    U1["UPS-A
300 kW · 15 dk akü"]
    U2["UPS-B
300 kW · 15 dk akü"]
    D1["A-PDU · rack 07"]
    D2["B-PDU · rack 07"]
    S1["PSU 1"]
    S2["PSU 2"]
    SRV["SRV-07-04"]
    G1 --> TR1
    G2 --> TR2
    GEN --> GB
    TR1 --> AT1
    GB --> AT1
    TR2 --> AT2
    GB --> AT2
    AT1 --> PA
    PA --> U1
    U1 --> D1
    D1 --> S1
    AT2 --> PB
    PB --> U2
    U2 --> D2
    D2 --> S2
    S1 --> SRV
    S2 --> SRV
    linkStyle 0,3,7,8,9,10,15 stroke:#dc2626,stroke-width:2.5px
    linkStyle 1,5,11,12,13,14,16 stroke:#2563eb,stroke-width:2.5px
    linkStyle 2,4,6 stroke:#d97706,stroke-width:2px,stroke-dasharray:4 3
    classDef gridn fill:#f1f5f9,stroke:#64748b,color:#0f172a
    classDef pathA fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef pathB fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef gn fill:#fef3c7,stroke:#d97706,color:#78350f
    class G1,G2,SRV gridn
    class TR1,AT1,PA,U1,D1,S1 pathA
    class TR2,AT2,PB,U2,D2,S2 pathB
    class GEN,GB gn

Dikkat edilecek nokta şemanın ortasındadır: jeneratör barası her iki yola da besleme yapar. Bu bilinçli bir tavizdir — jeneratörü 2N kurmak çok pahalıdır ve şebeke kesintisi zaten her iki yolu birden etkileyeceği için ayrı jeneratör grupları çoğu senaryoda ek fayda sağlamaz. Ama bu, jeneratör barasının tesisin en büyük ortak hata alanı olduğu anlamına gelir ve tasarım belgesinde böyle kayıt altına alınmalıdır.

Jeneratörün 10 saniyesi ve UPS’in asıl görevi

Şebeke kesildiğinde jeneratör anında devreye girmez. Dizel bir jeneratörün marş alması, devrini ve frekansını oturtması ve yükü kabul edebilecek hale gelmesi zaman alır; NFPA 110 standardının en yaygın sınıfı olan Type 10, sistemin yükü 10 saniye içinde kabul edebilmesini şart koşar. Pratikte bu süre 5-15 saniye arasındadır.

Sunucular ise 10 saniye bir yana, 20 milisaniyelik bir kesintiye bile dayanamaz.

İşte UPS’in gerçek görevi budur ve sıkça yanlış anlaşılır: UPS, kesinti boyunca sistemi ayakta tutmak için değil, jeneratör kalkana kadarki boşluğu köprülemek için vardır. DC-IST1’deki 15 dakikalık akü süresi, “15 dakika kesintiye dayanırız” demek değildir; 10 saniyelik jeneratör kalkışı için fazlasıyla yeterli, jeneratör hiç kalkmazsa da sistemleri kontrollü kapatmaya yetecek bir penceredir.

Akü süresi bir konfor değil, bir karar penceresidir. “Jeneratör kalkmadı” alarmından itibaren kaç dakikanız olduğunu ve o dakikalarda kimin ne yapacağını yazılı olarak bilmiyorsanız, o akülerin 15 dakika mı 45 dakika mı olduğunun pratik bir önemi yoktur.

UPS topolojileri: hangisi gerçekten koruyor?

Her “UPS” etiketi aynı şeyi yapmaz. IEC 62040-3 üç ana topoloji tanımlar:

Kurumsal veri merkezinde yalnızca üçüncüsü kullanılır ve sebebi geçiş süresi değildir: online UPS’te yük hiçbir zaman doğrudan şebekeye bağlı değildir. Şebekedeki gerilim çökmeleri, harmonikler ve frekans oynamaları yükü hiç görmez, çünkü aradaki inverter elektriği baştan üretir.

Online UPS’in de bir bypass’ı vardır — hatta ikisi:

• Statik bypass: UPS’in kendi içindeki otomatik yol. Inverter arızalanır veya aşırı yüklenirse yük milisaniyeler içinde ham şebekeye aktarılır. Koruma kaybolur ama hizmet durmaz.
• Bakım bypass’ı: UPS’in dışındaki manuel şalter. UPS’i tamamen devreden çıkarıp fiziksel olarak sökmenizi sağlar; bu sırada yük ham şebekeden beslenir.

Bu ayrım vaka bölümünde önem kazanacak: bakım bypass’ı UPS’i kurtarır, ama UPS’ten sonraki dağıtım panosunu kurtarmaz.

STS: tek beslemeli cihazların çaresi

Her cihazın iki güç kaynağı yoktur. Bazı ağ cihazları, KVM’ler, eski depolama üniteleri veya bazı ölçüm cihazları tek beslemelidir (single-corded). Bunlar A veya B’den birine bağlanmak zorundadır ve o yol düştüğünde kapanırlar.

Çözüm STS’tir (Static Transfer Switch — statik transfer şalteri). STS iki kaynağı da izler ve tristör tabanlı olduğu için mekanik bir şalterin aksine yarım şebeke çevriminden kısa sürede (tipik olarak 4-8 ms) diğer kaynağa geçer. Tek beslemeli cihaz STS’e bağlanır, STS ise hem A hem B’yi görür.

ATS ile karıştırmayın. İkisi de “transfer” yapar ama ölçekleri ve hızları farklıdır:

Rack’e inen son iki metre: PDU ve PSU

Zincirin en görünür ama en çok hata yapılan halkası burasıdır. Her rackte iki PDU (Power Distribution Unit — güç dağıtım ünitesi) bulunur: biri A yolundan, diğeri B yolundan beslenir. Sunucunun iki PSU‘su (Power Supply Unit — güç kaynağı) da ayrı PDU’lara takılır.

Kural tek cümledir ve 42 numaralı yazıdaki HBA kuralının birebir aynısıdır:

Aynı sunucunun iki PSU’su asla aynı PDU’ya takılmaz. İki PSU’nun ikisi de aynı yolda ise, o sunucu için yedeklilik kâğıt üzerinde vardır ama gerçekte yoktur.

Bu kuralın sinsi tarafı şudur: sunucu bunu size söyleyemez. Sunucunun yönetim kartı (BMC) iki PSU görür, ikisi de sağlıklıdır, ikisi de gerilim alıyordur — dolayısıyla durumu “tam yedekli” olarak raporlar. Kordonların nereye gittiğini bilmesinin hiçbir yolu yoktur. Bu yazının vakası tam olarak bu kör noktada yaşanacak.

Besleme kablosu tablosu

Yedekliliği kayıt altına almanın yolu, her kablonun iki ucunu da yazmaktan geçer. SRV-07-04 sunucusu için tablo şöyledir:

Altı kablo, iki yol, hiçbir noktada kesişme yok. Bu tablo yoksa yedekliliğiniz belgelenmemiş demektir; belgelenmemiş yedeklilik ise ilk bakımda kaybolur.

Soğutma: Elektriğin Diğer Yarısı

Sunucuya verdiğiniz elektriğin neredeyse tamamı ısıya dönüşür. Fiziksel olarak başka gidecek yeri yoktur: veri işlemek enerjiyi başka bir forma taşımaz, ısı olarak dışarı verir. Bu yüzden pratik kural şudur:

Salona 160 kW elektrik veriyorsanız, salondan 160 kW ısı çıkarmak zorundasınız.

DC-IST1’de bu iş dört adet CRAH ile yapılır. Burada da bir terim karışıklığı yaygındır:

• CRAC (Computer Room Air Conditioner): kendi kompresörü ve soğutucu gazı olan, bağımsız bir klima ünitesidir.
• CRAH (Computer Room Air Handler): kompresörü yoktur. Merkezî bir chiller‘dan gelen soğuk suyu kullanır; yalnızca havayı bu su serpantininden geçirir.

DC-IST1 CRAH kullanır: 12 °C soğuk su, dört ünite, her biri 60 kW. N+1’dir çünkü üç ünite (180 kW) 160 kW’lık yükü tek başına karşılar, dördüncüsü yedektir.

Sıcak koridor / soğuk koridor

Soğutmanın verimi, soğuk hava ile sıcak havanın karışmasını engellemekten geçer. Tüm sunucular havayı önden emip arkadan attığı için rack’ler sırt sırta ve yüz yüze dizilir:

    
flowchart LR
    CR["CRAH
12 °C soğuk su · N+1"]
    CA["SOĞUK KORİDOR
~22 °C giriş havası"]
    RK["Rack ön yüzü
emiş"]
    SV["Sunucular
ön → arka hava akışı"]
    HA["SICAK KORİDOR
~35 °C çıkış havası"]
    CR -->|"üfleme"| CA
    CA --> RK
    RK --> SV
    SV --> HA
    HA -->|"dönüş"| CR
    linkStyle 0,1 stroke:#2563eb,stroke-width:2.5px
    linkStyle 3,4 stroke:#dc2626,stroke-width:2.5px
    classDef cold fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef hot fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef eq fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class CA,CR cold
    class HA hot
    class RK,SV eq

Bu düzeni bozan iki yaygın hata vardır:

• Boş U’ların açık bırakılması. Rack’te cihazsız kalan her U, sıcak koridordaki havanın rack’in içinden geçip öne, soğuk koridora dönmesine izin verir. Sunucu kendi attığı sıcak havayı geri emer. Çözüm ucuzdur: kör panel (blanking panel). Bir veri merkezinde yapabileceğiniz en düşük maliyetli verim iyileştirmesi budur.
• Kablo geçişlerinin kapatılmaması. Yükseltilmiş tabandan veya rack arkasından geçen kablo boşlukları da aynı kısa devreyi yaratır; fırça contayla kapatılır.

İleri seviye tesisler bir adım daha atar ve koridorun kendisini fiziksel olarak kapatır (containment): sıcak koridorun üstü ve uçları paneller ve kapılarla kapatılarak iki hava kütlesi tamamen ayrılır.

Sıcaklık nerede ölçülür?

ASHRAE TC 9.9 kılavuzunun önerilen aralığı 18-27 °C‘dir; A1 sınıfı için izin verilen aralık 15-32 °C’ye kadar açılır. Ama asıl mesele rakam değil, ölçüm noktasıdır.

Sıcaklık, salonun ortalaması olarak değil, cihazın hava emdiği noktada — yani rack’in ön yüzünde — ölçülür. Salon ortalaması 21 °C iken, rack’in en üst sunucusunun emiş sıcaklığı 32 °C olabilir; çünkü sıcak hava yükselir ve koridorun üstünden geri döner.

Bu yüzden rack başına tek sensör yetmez. Pratik yaklaşım rack ön yüzüne alt, orta ve üst olmak üzere üç sensör koymaktır; alarm eşiği üstteki sensöre göre belirlenir.

Soğutma da elektriğe bağlıdır

En çok atlanan bağımlılık budur ve ciddi sonuçları vardır.

Şebeke kesildi, jeneratör 10 saniyede kalktı, sunucular UPS sayesinde hiç hissetmedi. Peki soğutma? Tesislerin çoğunda CRAH fanları UPS’e, ama chiller jeneratöre bağlıdır. Fanlar hiç durmaz; chiller ise jeneratör kalktıktan sonra yeniden başlar ve tam kapasiteye ulaşması dakikalar sürebilir.

O dakikalarda salona soğuk su gitmez. Yüksek yoğunluklu bir salonda sıcaklık dakikada birkaç derece artabilir; yeterince uzun sürerse sunucular termal koruma ile kendilerini kapatır. Elektrik kesintisini kusursuz atlatan bir tesis, soğutma yüzünden kesinti yaşar.

Çözüm iki başlıktadır: chiller devresine soğuk su tamponu (buffer tank) koymak — böylece chiller yeniden başlarken depodaki soğuk su akmaya devam eder — ve chiller’ları da UPS’e almak. İkincisi pahalıdır ve genelde yalnızca yüksek sınıf tesislerde yapılır.

Tasarımınızda şu soruyu net cevaplayabilmelisiniz: “Şebeke kesildikten sonra salona soğuk su akmadan geçen en uzun süre kaç saniyedir ve bu sürede en sıcak rack kaç dereceye çıkar?” Cevabı bilmiyorsanız, soğutma yedekliliğiniz test edilmemiştir.

Rack ve Kablolama Disiplini

Bu katmanda teknoloji yok, yalnızca disiplin var — ve tam bu yüzden en çok burada hata yapılır.

Renk ayrımı. A yolunun tüm güç kordonları tek renk (yaygın olarak kırmızı), B yolunun tümü başka renk (mavi) olur. Bu bir estetik tercih değil, bir doğrulama aracıdır: rack’in arkasına baktığınızda her sunucudan bir kırmızı ve bir mavi kordon çıkmıyorsa, hatayı ölçüm yapmadan, tek bakışta görürsünüz.

Etiketleme. Her kordonun iki ucu da etiketlenir; her PDU çıkışı hangi cihaza gittiğini söyler. Bu, 42 numaralı yazıdaki dersin aynısıdır: orada devreye alınmamış switch portunun description alanı boştu ve bu küçük ayrıntı, zoning’in de hiç yapılmadığının ilk işaretiydi. Etiketlenmemiş bir bağlantı, büyük olasılıkla devreye alma sürecinin tamamının atlandığı bir bağlantıdır.

Rack elevation kaydı. Hangi U’da ne olduğu, hangi çıkıştan beslendiği yazılı tutulur:

Bu tablo, vaka bölümünde göreceğimiz hatanın kâğıt üzerinde nasıl görünmesi gerektiğini gösteriyor. Gerçekte ise böyle görünmüyordu.

Tier Sınıfları: Kâğıt Üstündeki Yedeklilik

Uptime Institute’un Tier sınıflandırması, bir tesisin yedeklilik seviyesini tanımlayan yaygın referanstır:

Tablodaki en öğretici satır ikincisidir. Tier II, N+1 kapasiteye sahiptir ama dağıtım yolu tektir. Yani üç jeneratörünüz olabilir; o yolun panosunu bakıma almak yine de kesinti demektir. Tier III’ü Tier II’den ayıran şey ek bir ünite değil, ikinci bir yoldur — az önce N+1 ile 2N arasında kurduğumuz ayrımın standartlaşmış hâli.

DC-IST1, elektrik tarafında iki tam yol ve N+1 jeneratör ile Tier III sınıfına karşılık gelir; jeneratör barası ortak olduğu için Tier IV’ün gerektirdiği tam bölmelendirmeyi sağlamaz.

Dikkat edilecek iki nokta. Birincisi, Tier sertifikasyona dayanır ve tasarım belgesi, inşa edilmiş tesis ve operasyonel sürdürülebilirlik için ayrı ayrı verilir; pazarlama metinlerinde sıkça görülen “Tier 3 uyumlu” ifadesinin denetlenmiş bir karşılığı yoktur. İkincisi, sınıflarla birlikte yaygın olarak alıntılanan %99,671 / %99,982 gibi kullanılabilirlik yüzdeleri, Uptime Institute’un güncel Tier standardının parçası değildir; eski bir yayından türeyip literatürde dolaşan rakamlardır. Bir tesisi bu yüzdelere göre seçmeyin; yukarıdaki tablonun son üç satırına göre seçin.

Arıza Matrisi: DC-IST1’de Ne Düşerse Ne Olur?

Tasarımın gerçek değeri, arıza tablosunda görünür:

Tablonun beşinci satırı bu yazının kalbidir ve içinde bir şart barındırır: “doğru kablolanmışsa”. Şimdi o şartın tutmadığı bir geceye bakacağız.

Vaka: Bakım Gecesi

Ne oldu?

DC-IST1’de UPS-A’nın akü grubu değişimi ve A yolunun çıkış kesicisinin yenilenmesi planlanmıştı. Akü değişimi tek başına bakım bypass’ı ile yapılabilirdi; ancak çıkış kesicisinin değişmesi, A yolunun tamamen enerjisiz bırakılmasını gerektiriyordu.

2N bir tesiste bu rutin bir işlemdir — eşzamanlı bakım tam olarak bunun için vardır. Beklenen etki sıfırdı: tüm yük B yoluna geçecek, hiçbir cihaz bunu fark etmeyecekti.

Saat 02:41’de A yolu kesildi. Salondaki 40 rack’in 39’unda hiçbir şey olmadı.

Rack 07’de ise iki sunucu — SRV-07-04 ve SRV-07-07 — anında kapandı.

PDU tarafında teşhis

İlk bakılacak yer, kesinti öncesinde rack’lerin ne çektiğidir. DC-IST1’deki rack PDU’ları SNMP ile okunabiliyor. Aşağıdaki OID, APC PowerNet-MIB‘deki rPDULoadStatusLoad değeridir ve akımı 0,1 A biriminde döndürür — diğer üreticilerde OID ve birim farklıdır, kendi MIB’inizden doğrulayın:

$ snmpget -v2c -c dcread -Ovq pdu-r07-a.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1
91

$ snmpget -v2c -c dcread -Ovq pdu-r07-b.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1
61

Yani pdu-r07-a 9,1 A, pdu-r07-b ise 6,1 A çekiyordu. Tek başına bakıldığında iki değer de normaldir; 32 A’lik bir PDU için ikisi de rahat sınırlar içindedir. Anlamlı olan aralarındaki fark. Tüm rack’leri tarayalım:

$ for r in $(seq -w 1 40); do
    a=$(snmpget -v2c -c dcread -Ovq pdu-r${r}-a.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1)
    b=$(snmpget -v2c -c dcread -Ovq pdu-r${r}-b.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1)
    echo "rack $r  A=$((a/10)),$((a%10)) A   B=$((b/10)),$((b%10)) A"
  done

rack 05  A=7,4 A   B=7,3 A
rack 06  A=7,6 A   B=7,5 A
rack 07  A=9,1 A   B=6,1 A
rack 08  A=6,9 A   B=7,0 A
rack 09  A=7,2 A   B=7,1 A

Tablo tek başına teşhisi tamamlıyor. Diğer tüm rack’lerde A ve B kolları birbirinin 0,1-0,2 A yakınında; rack 07’de ise A kolu B’den 3 A fazla çekiyor. Bu ancak tek bir şeyle açıklanabilir: rack 07’de bazı cihazlar B’den hiç beslenmiyor.

Aritmetiği yapalım. Rack 07’de 10 sunucu var, her biri ~350 W çekiyor, toplam 3,5 kW:

Doğru kablolanmış 8 sunucu → A'dan 8 × 175 W = 1400 W
                            B'den 8 × 175 W = 1400 W
Hatalı kablolanmış 2 sunucu → A'dan 2 × 350 W =  700 W
                            B'den            =    0 W

A kolu = 2100 W ÷ 230 V = 9,1 A   ✓ ölçümle uyuşuyor
B kolu = 1400 W ÷ 230 V = 6,1 A   ✓ ölçümle uyuşuyor

Ölçüm ile hipotez birebir örtüşüyor: iki sunucunun her iki PSU’su da A koluna bağlı.

Sunucu tarafında teşhis

Şimdi kritik soru: bu durum neden aylardır fark edilmedi? Sunucular bunu raporlamıyor muydu?

Kesinti öncesinde SRV-07-04‘ün yönetim kartına sorulsaydı alacağınız cevap şuydu:

$ ipmitool -I lanplus -H 10.30.7.104 -U monitor -P '***' sdr type "Power Supply"
PSU1 Status      | 70h | ok  | 10.1 | Presence detected
PSU2 Status      | 71h | ok  | 10.2 | Presence detected

$ ipmitool -I lanplus -H 10.30.7.104 -U monitor -P '***' sdr type "Power Unit"
PSU Redundancy   | 77h | ok  | 21.1 | Fully Redundant

Fully Redundant. Sunucu, kendi bildiği her şeye göre haklıdır: iki PSU takılı, ikisi de sağlıklı, ikisi de gerilim alıyor. Bir BMC’nin kordonların nereye gittiğini öğrenmesinin hiçbir yolu yoktur. Sunucu tarafındaki hiçbir izleme aracı bu hatayı yakalayamazdı.

Kesintiden sonra sunucular geri geldiğinde olay kayıtları ise tabloyu kapatıyor. Önce doğru kablolanmış bir komşu, SRV-07-02:

$ ipmitool -I lanplus -H 10.30.7.102 -U monitor -P '***' sel list | tail -2
   9 | 08/08/2026 | 02:41:16 | Power Supply PSU1 | Power Supply input lost (AC/DC) | Asserted
  10 | 08/08/2026 | 02:41:16 | Power Unit PSU Redundancy | Redundancy Lost | Asserted

Bu sunucu PSU 1’in beslemesini kaybetti, yedekliliği düştü — ve çalışmaya devam etti. Tasarımın beklenen davranışı tam olarak budur.

Şimdi SRV-07-04:

$ ipmitool -I lanplus -H 10.30.7.104 -U monitor -P '***' sel list | tail -2
  4f | 08/08/2026 | 02:41:16 | Power Supply PSU1 | Power Supply input lost (AC/DC) | Asserted
  50 | 08/08/2026 | 02:41:16 | Power Supply PSU2 | Power Supply input lost (AC/DC) | Asserted

İki PSU de aynı saniyede beslemesini kaybetti. İki bağımsız yoldan beslenen iki güç kaynağının aynı anda kararması mümkün değildir; bu kayıt, ikisinin de aynı kaynağa bağlı olduğunun kesin kanıtıdır. Bu sunucu için “yedeklilik kaybı” diye bir ara adım olmadı — doğrudan kapandı.

Kök neden ve çözüm

Rack 07’nin arkasına bakıldığında tablo netleşti: SRV-07-04 ve SRV-07-07 sunucularının her iki güç kordonu da pdu-r07-a‘ya takılıydı. pdu-r07-b‘nin karşılık gelen çıkışları boştaydı.

    
flowchart LR
    subgraph W["BULUNAN DURUM · SRV-07-04"]
        direction TB
        WA["pdu-r07-a"]
        WB["pdu-r07-b"]
        W1["PSU 1"]
        W2["PSU 2"]
        WX["çıkış 04 · boşta"]
        WA --> W1
        WA --> W2
        WB -.-> WX
    end
    subgraph R["DÜZELTİLMİŞ DURUM · SRV-07-04"]
        direction TB
        RA["pdu-r07-a"]
        RB["pdu-r07-b"]
        R1["PSU 1"]
        R2["PSU 2"]
        RA --> R1
        RB --> R2
    end
    linkStyle 0,1,3 stroke:#dc2626,stroke-width:2.5px
    linkStyle 2 stroke:#94a3b8,stroke-width:1.5px
    linkStyle 4 stroke:#2563eb,stroke-width:2.5px
    classDef pathA fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef pathB fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef dead fill:#e2e8f0,stroke:#94a3b8,color:#475569
    classDef psu fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class WA,RA pathA
    class RB pathB
    class WB,WX dead
    class W1,W2,R1,R2 psu

Kök neden bir arıza değil, bir devreye alma hatasıydı: rack montajı sırasında kordonlar sırayla en yakın PDU’ya takılmış, renk disiplini uygulanmamış, besleme tablosu doldurulmamıştı. Sunucular o günden beri sorunsuz çalıştığı için hiçbir alarm üretilmedi.

Çözüm dakikalar sürdü — her sunucunun PSU 2 kordonu pdu-r07-b‘nin karşılık gelen çıkışına taşındı. Sunucular çalışırken yapıldı; PSU 1 beslemeyi taşıdığı sürece PSU 2 kordonunu değiştirmek kesinti üretmez.

Ama bu işlemi yaparken sırayı bozmayın. Kordonu çekmeden önce diğer PSU’nun gerçekten beslendiğini sdr type "Power Supply" ile teyit edin ve sunucuları teker teker ele alın. Aynı anda iki sunucuda birden kordon değiştirmek, ikinci sunucuda beklenmedik bir durumla karşılaşırsanız hata payınızı sıfırlar.

Aynı taramayı 40 rack’in tamamında tekrarladık — simetrik bir sistemde bir tarafta bulunan eksiğin başka yerde de olması kural değil, beklentidir. Diğer rack’lerin tümü dengeliydi; hata yalnızca rack 07’nin montaj gününe aitti.

Doğrulama

Kordonlar taşındıktan sonra akım tablosu:

$ snmpget -v2c -c dcread -Ovq pdu-r07-a.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1
76

$ snmpget -v2c -c dcread -Ovq pdu-r07-b.dc-ist1.local .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.1
76

7,6 A / 7,6 A — rack 07’nin 3,5 kW’lık yükü artık iki yol arasında eşit bölünmüş durumda ve değerler komşu rack’lerle uyumlu.

Ama akım dengesi tek başına kanıt değildir. Aynı tablo, kordonlar doğru PDU’ya ama yanlış yola bağlı olsaydı da benzer görünebilirdi. Kanıt, yedekliliği bilerek bozmaktan geçer. Bir sonraki bakım penceresinde A yolu tekrar kesildiğinde beklenen çıktı şudur:

$ ipmitool -I lanplus -H 10.30.7.104 -U monitor -P '***' sel list | tail -2
  53 | 08/12/2026 | 03:10:44 | Power Supply PSU1 | Power Supply input lost (AC/DC) | Asserted
  54 | 08/12/2026 | 03:10:44 | Power Unit PSU Redundancy | Redundancy Lost | Asserted

Yalnızca PSU 1 beslemesini kaybetmeli, PSU 2 sessiz kalmalı ve sunucu ayakta olmalıdır. SRV-07-02‘nin bakım gecesinde ürettiği kaydın aynısı — yedekliliğin çalıştığının tek geçerli kanıtı budur.

Test Disiplini: Yedekliliği Bilerek Bozmak

Yukarıdaki vakanın asıl dersi şudur: hiç kullanılmayan yedeklilik, var olduğu varsayılan yedekliliktir. Bunu önlemenin tek yolu, yedekliliği kontrollü koşullarda düzenli olarak bozmaktır.

Jeneratör — yıllık tam yük testi. Haftalık çalıştırma yeterli değildir. Dizel bir jeneratör uzun süre düşük yükte çalıştırılırsa yanmamış yakıt egzoz sisteminde birikir; buna wet stacking denir ve zamanla ünitenin tam yük alma kabiliyetini düşürür. Bu yüzden yılda en az bir kez yük bankası ile anma gücünde test yapılır. Haftalık rutin ise yalnızca “marş alıyor mu, yakıt sistemi çalışıyor mu” sorusunu cevaplar.

UPS — akü otonomi testi. Aküler yaşlanır ve bunu sessizce yapar. Üreticinin “10 yıl tasarım ömrü” dediği VRLA aküler saha koşullarında çoğu zaman 5-7 yıl dayanır. Empedans izleme sürekli bir gösterge verir; ama gerçek kapasiteyi yalnızca kontrollü deşarj testi ölçer.

A/B yol testi — en önemlisi. Planlı olarak bir yolu tamamen kesip tesisin ayakta kaldığını görmek. DC-IST1’de bu, 42 numaralı yazıdaki kontrollü fabric failover testinin fiziksel karşılığıdır ve aynı disiplini ister:

• Test bakım penceresinde yapılır.
• Öncesinde diğer yolun sağlığı doğrulanır — çünkü test, riski bilerek üretir.
• Her iki yön için ayrı ayrı tekrarlanır: A’yı kesip B’yi sınadıktan sonra B’yi kesip A’yı sınayın.
• Sonuç yazılır: hangi cihaz düştü, hangi alarm geldi, hangisi gelmedi.

Rack 07’deki hata, tesis devreye alındığında böyle bir test yapılmış olsaydı ilk gece ortaya çıkardı. Yedekliliğin ölçülmediği her ay, faturası ertelenen bir kesintidir.

İzleme: Hangi Metrikler Alarm Üretmeli?

Bir kerelik doğrulama yeterli değildir; bir yıl sonra bir kordon değişir, bir akü yaşlanır ve tablo sessizce yeniden bozulur. İzleme sisteminizde şu metrikler bulunmalıdır:

Birinci satır özellikle önemlidir çünkü başka hiçbir sistem o hatayı göremez. Sunucu göremez, UPS göremez, hipervizör göremez. Yalnızca iki PDU’nun akımını yan yana koyan bir kural görür.

Sonuç

Bir veri merkezi, bileşenlerinin kalitesiyle değil, hata alanlarının ayrılığıyla ayakta kalır. Bu yazıda o ayrımı elektriğin şehir şebekesinden sunucunun güç kaynağına kadar takip ettik: iki OG hattı, iki trafo, N+1 jeneratör, 2N UPS, rack başına iki PDU ve sunucu başına iki PSU.

Zincirin her halkasında yedeklilik vardı. Yine de tek bir yanlış takılmış kordon, planlı bir bakım gecesinde iki sunucuyu kapattı — çünkü o kordon, iki hata alanını görünmeden tek hata alanına indirmişti. Sunucu bunu göremezdi, UPS göremezdi; yalnızca iki PDU’nun akımını karşılaştıran bir ölçüm görebilirdi.

Akılda kalması gereken üç cümle:

• Yedekliliği bileşen sayarak değil, hata alanı sayarak ölçün. İki PSU, tek PDU’ya bağlıysa yedeklilik yoktur.
• N+1 bileşen ekler, 2N yol ekler. Aradaki fark, bakım gecesinde ortaya çıkar.
• Test edilmemiş yedeklilik, varsayılmış yedekliliktir. Ve varsayımlar yalnızca gerçek kesinti anında sınanır.

Serinin ikinci yazısında bu fiziksel temelin üstüne çıkacağız: ağ yedekliliği, çift ToR ve bonding, küme seviyesinde N+1, quorum ve split-brain, uçtan uca bir isteğin geçtiği tüm hata alanları.

Ek: Bu Yazıda Geçen Terimler