Veri Merkezinde BT Yedekliliği: Ağdan Kümeye Uçtan Uca Hata Alanları

Serinin ilk yazısında DC-IST1’de bir bakım gecesi yaşamış, rack 07’de iki sunucunun kapandığını görmüştük. Sebep, iki güç kordonunun da aynı PDU’ya takılmış olmasıydı.

O yazı kapanan sunucularla bitti. Bu yazı tam oradan başlıyor — çünkü asıl soru cevaplanmadı:

O sunucuların üzerindeki iş yükü ne oldu?

Kapanan sunuculardan biri, SRV-07-04 etiketli kasa, vCenter’da VMHOST10 adıyla görünen bir ESXi hostuydu. Üzerinde onlarca sanal makine çalışıyordu. Fiziksel katman o gece başarısız oldu — ama kullanıcılar hiçbir şey fark etmedi. Çünkü fiziksel katmanın üstünde, aynı mantığı bir kez daha kuran ikinci bir yedeklilik yapısı vardı.

Bu yazıda o yapıyı katman katman kuruyoruz: ağ, depolama, hesaplama, servis ve veri. Her katmanda aynı soruyu soracağız — bu bileşenin ikinci kopyası gerçekten ayrı bir hata alanında mı? — ve her katmanda o sorunun sessizce “hayır” olduğu tuzakları göreceğiz.

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

Tanımadığınız bir kısaltmaya rastlarsanız yazının sonundaki terimler sözlüğüne bakabilirsiniz. SPOF, hata alanı, N+1, 2N, aktif-pasif gibi temel kavramlar ilk yazıda tanımlanmıştı; burada tanımlarını tekrar etmeden kullanacağız.

Ortamı Hatırlayalım

DC-IST1 · Salon A: 40 rack, 160 kW BT yükü, 2N elektrik yolu, rack başına A-PDU ve B-PDU. Bu yazıda kullanacağımız BT tarafı:

SRV-07-NN kasanın rack üzerindeki fiziksel etiketi, VMHOSTNN ise vCenter’daki ESXi ana bilgisayar adıdır. Bakım gecesinde kapanan SRV-07-04, yani VMHOST10, bu yazının başrolünde.

Katman 4: Ağ

Bir sunucunun ağ yedekliliği ilk bakışta basit görünür: iki NIC portu, iki switch. Ama Ethernet dünyasında bu “basit” çözüm, veri merkezinin en ince tasarım tavizini içerir.

Leaf-spine ve çift ToR

DC-IST1’de her rack’te iki leaf (ToR — Top of Rack) switch vardır ve her leaf, her iki spine’a bağlanır:

    
flowchart TB
    SP1["spine-01"]
    SP2["spine-02"]
    T7A["tor-r07-a"]
    T7B["tor-r07-b"]
    T8A["tor-r08-a"]
    T8B["tor-r08-b"]
    N1["vmnic0"]
    N2["vmnic1"]
    SRV["VMHOST09
bond0 · teaming"]
    T7A --- SP1
    T7A --- SP2
    T7B --- SP1
    T7B --- SP2
    T8A --- SP1
    T8A --- SP2
    T8B --- SP1
    T8B --- SP2
    T7A --> N1
    T7B --> N2
    N1 --> SRV
    N2 --> SRV
    linkStyle 0,1,8,10 stroke:#dc2626,stroke-width:2.5px
    linkStyle 2,3,9,11 stroke:#2563eb,stroke-width:2.5px
    linkStyle 4,5,6,7 stroke:#94a3b8,stroke-width:1.5px
    classDef sp fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef la fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef lb fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef hst fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class SP1,SP2 sp
    class T7A,T8A la
    class T7B,T8B lb
    class N1,N2,SRV hst

Bu topolojinin iki özelliği kritiktir:

• Spine’lar birbirine bağlanmaz. Leaf’ler de birbirine bağlanmaz. Her leaf-spine bağlantısı bağımsızdır ve trafik ECMP ile tüm spine’lara dağıtılır. Bir spine kaybı, omurga kapasitesinin yarısını götürür ama hiçbir yolu koparmaz.
• Her sunucu iki farklı leaf’e bağlanır. Bir leaf’in tamamı gitse bile rack ayakta kalır.

Yedeklilik açısından tablo temiz görünüyor. Sorun, sunucunun iki NIC’ini nasıl kullandığında.

İki NIC’i birleştirmenin iki yolu

Bir sunucunun iki NIC portu tek bir mantıksal arayüz gibi davranacaksa, bunun iki yolu vardır ve aralarındaki fark, bu serinin ana temasına dokunur:

İkinci satır ilk bakışta teknik bir ayrıntı gibi durur. Değildir.

Standart bir LACP bağı (link aggregation) tek bir switch’e gider; çünkü LACP’nin karşı tarafında tek bir cihaz olması beklenir. İki farklı fiziksel switch’e bond kurmak istiyorsanız, o iki switch’in sunucuya tek bir switch gibi görünmesi gerekir. Bunu sağlayan teknolojinin genel adı MLAG‘dir (Multi-Chassis Link Aggregation); üreticiler farklı isimlendirir — Cisco’da vPC, Arista’da MLAG, Juniper’da MC-LAG, Dell’de VLT.

MLAG’in gizli bedeli: peer-link

MLAG’in çalışabilmesi için iki leaf’in birbiriyle sürekli konuşması gerekir. Bunun için aralarında iki bağlantı kurulur:

• peer-link: MAC adres tablosu, ARP ve gerektiğinde veri trafiği taşıyan yüksek hızlı bağ.
• peer-keepalive: Yalnızca “hayatta mısın?” sorusunu taşıyan, peer-link’ten fiziksel olarak ayrı olması gereken ikinci yol.

Ve işte tasarım tavizi:

    
flowchart LR
    subgraph FC["FIBRE CHANNEL · çift fabric"]
        direction TB
        FH["ESXi host
vmhba1 / vmhba2"]
        FA["MDS-A"]
        FB["MDS-B"]
        FH --> FA
        FH --> FB
    end
    subgraph ETH["ETHERNET · MLAG çifti"]
        direction TB
        EH["ESXi host
vmnic0 / vmnic1"]
        EA["tor-r07-a"]
        EB["tor-r07-b"]
        EH --> EA
        EH --> EB
        EA <-->|"peer-link
ORTAK HATA ALANI"| EB
    end
    linkStyle 0,2 stroke:#dc2626,stroke-width:2.5px
    linkStyle 1,3 stroke:#2563eb,stroke-width:2.5px
    linkStyle 4 stroke:#d97706,stroke-width:3px
    classDef ha fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef hb fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef hst fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class FA,EA ha
    class FB,EB hb
    class FH,EH hst

42 numaralı yazıda çift fabric mimarisinin altın kuralı şuydu: iki fabric birbirine asla bağlanmaz. Ethernet tarafında ise MLAG çiftini kurabilmek için iki switch’i bilerek bağlıyoruz.

Neden bu fark var? Çünkü iki katman aynı problemi farklı yerde çözüyor. Fibre Channel’da hostun multipath katmanı (NMP) iki yolu birbirinden bağımsız olarak yönetir; her yol ayrı bir SCSI yoludur ve host hangisini kullanacağına kendisi karar verir. Ethernet’te ise bir IP adresi ve MAC adresi tek bir mantıksal arayüzden çıkar; ağın “bu MAC’i iki switch’te birden görüyorum” durumunu tutarlı yönetebilmesi için switch’lerin koordine olması şarttır.

Sonuç şudur ve tasarım belgenizde yazılı olmalıdır: MLAG çifti, tam bağımsız iki hata alanı değildir. Ortak bir yazılım durumu ve ortak bir peer-link’i vardır. Yaygın arıza senaryoları:

• Peer-link koparsa, keepalive ayaktaysa: vPC’de ikincil switch kendi vPC üyelerini kapatır. Bu bilinçli bir davranıştır — döngü ve MAC kararsızlığı yerine yarım kapasiteyi seçer. Sunucular tek bacağa düşer, hizmet sürer.
• Peer-link ve keepalive birlikte koparsa: İki switch de kendini birincil sanır. Gerçek split-brain. Bu yüzden keepalive yolunun peer-link’ten ayrı bir fiziksel yoldan (tipik olarak yönetim ağından) geçmesi bir öneri değil, gerekliliktir.
• Yazılım yükseltmesi: Aynı yazılım sürümünü çalıştıran bir çiftte, bir hataya iki switch de aynı anda yakalanabilir. Yükseltmeler her zaman önce bir tarafa uygulanır ve arada bekleme süresi bırakılır.

Durum kontrolü:

LEAF-R07-A# show vpc brief

Legend:
                (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                     : 107
Peer status                       : peer adjacency formed ok
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 12
Peer Gateway                      : Enabled

Bakılacak iki satır: Peer status ve vPC keep-alive status. İkisi de sağlıklı değilse yedekliliğiniz kâğıt üzerindedir. Configuration consistency status ise ayrı bir tuzaktır: iki switch’in vPC ile ilgili ayarları birebir aynı olmak zorundadır; uyuşmazlık varsa vPC portları hiç ayağa kalkmaz veya beklenmedik biçimde düşer.

ESXi tarafında ne kullanılıyor?

ESXi’de Linux’taki bond kavramı yoktur; onun yerine sanal switch üzerinde NIC teaming politikası vardır. Politika seçimi doğrudan MLAG gereksinimini belirler:

Bu tabloyu atlamak, veri merkezinde en sık yapılan yapılandırma hatalarından birine yol açar. İki uç da yanlış olabilir: switch tarafında EtherChannel açıkken ESXi’de srcport bırakmak, ya da ESXi’de iphash seçip switch tarafında hiçbir şey yapmamak. İkisi de kararsız bağlantı ve açıklanamayan paket kaybı üretir.

Önemli ön koşul: LACP, ESXi’de yalnızca vSphere Distributed Switch (vDS) ile kullanılabilir. Standart sanal switch (vSS) LACP’yi desteklemez; orada seçenek statik EtherChannel ile iphashtir. Lisansınız vDS’e izin vermiyorsa MLAG’li aktif-aktif tasarımı planlamayın.

Mevcut durumu görelim:

[root@vmhost09:~] esxcli network nic list

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address        MTU
------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----
vmnic0  0000:19:00.0  i40en   Up            Up           25000  Full    b8:59:9f:2a:14:70  9000
vmnic1  0000:19:00.1  i40en   Up            Up           25000  Full    b8:59:9f:2a:14:71  9000

[root@vmhost09:~] esxcli network vswitch standard policy failover get -v vSwitch0

   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vmnic0, vmnic1
   Standby Adapters:
   Unused Adapters:

Buradaki Network Failure Detection: link satırı ayrı bir dikkat ister. Varsayılan olan link durumu algılaması yalnızca “kablo takılı mı” sorusunu cevaplar. Switch ayakta ama uplink’i kopmuşsa, ya da VLAN yanlış yapılandırılmışsa, sunucunun NIC’i hâlâ Up görünür ve trafik kara deliğe akar. Alternatif olan işaret tabanlı algılama (beacon probing) bunu yakalayabilir, ancak anlamlı çalışması için üç veya daha fazla aktif NIC gerekir; iki NIC’li bir sunucuda hangi tarafın hatalı olduğunu belirleyemez. İki NIC’li tasarımda pratik çözüm, algılamayı sunucuya değil, switch uplink izlemesine bırakmaktır.

Yönetim ağı: en çok unutulan katman

BMC’ler, switch konsol portları, PDU’lar ve UPS kartları veri ağından fiziksel olarak ayrı bir OOB (out-of-band) ağda durur. Mantığı basittir: veri ağı çöktüğünde müdahale edebilmeniz gerekir.

Ama pratikte bu ağ neredeyse her zaman tek switch’le kurulur — çünkü “sadece yönetim” olarak görülür. Ve tam da bu yüzden şu iki soruyu sormak gerekir:

• OOB switch’i hangi PDU’dan besleniyor? Tek kordonlu bir yönetim switch’i A-PDU’ya takılıysa, ilk yazıdaki bakım gecesinde o switch de kapanırdı — yani salonun en kritik anında uzaktan müdahale yeteneğinizi kaybederdiniz. Tek beslemeli cihazlar için STS’in varlık sebebi budur.
• OOB ağı üretim ağına bağımlı mı? Yönetim ağınıza yalnızca üretim ağı üzerinden erişebiliyorsanız, o ağ “out-of-band” değildir.

Katman 5: Depolama

Bu katmanı 42 numaralı yazıda ayrıntılı işlemiştik; burada yalnızca hata alanı haritasındaki yerini koyuyoruz.

DC-IST1’de her ESXi hostu iki FC HBA taşır: vmhba1 Fabric A’ya, vmhba2 Fabric B’ye bağlıdır. Her fabric depolamanın iki denetleyicisini de görür, dolayısıyla LUN başına dört yol oluşur.

Dördüncü satırdaki ALUA, bu serinin aktif-pasif tartışmasının depolamadaki karşılığıdır: array, her LUN için hangi yolların optimal olduğunu hosta bildirir; host öncelikli olarak optimal yolları kullanır, denetleyici arızasında diğerlerine geçer.

Doğrulama tek komuttur ve yol sayısının iki adaptöre dağılmış olması esastır:

[root@vmhost09:~] esxcli storage nmp device list -d naa.600a09803830443859244e5a41763721

naa.600a09803830443859244e5a41763721
   Storage Array Type: VMW_SATP_ALUA
   Path Selection Policy: VMW_PSP_RR
   Working Paths: vmhba1:C0:T0:L12, vmhba1:C0:T1:L12, vmhba2:C0:T0:L12, vmhba2:C0:T1:L12

Dört yolun dördü de aynı adaptörden geçiyorsa sayı doğru, yedeklilik yoktur. 42 numaralı yazının tamamı bu ayrımın üzerine kuruluydu; ayrıntı ve teşhis komutları için oraya bakın.

Katman 6: Hesaplama

Şimdi bakım gecesine dönüyoruz. VMHOST10 saat 02:41’de elektriğini kaybetti ve kirli biçimde kapandı — kapanma sinyali yok, uyarı yok, sadece anlık kesilme.

vSphere HA ne yaptı?

vCenter olay kaydı:

02:41:31  vSphere HA agent on vmhost09.dc-ist1.local detected host
          vmhost10.dc-ist1.local as failed
02:41:58  vSphere HA is restarting virtual machine APP-DB-02 on host
          vmhost11.dc-ist1.local in cluster CL-IST1-PROD
02:42:04  vSphere HA is restarting virtual machine web-02 on host
          vmhost09.dc-ist1.local in cluster CL-IST1-PROD

Yaklaşık bir dakika içinde VMHOST10‘un sanal makineleri kalan hostlarda yeniden başlatıldı. Bu kesintisiz bir devralma değildir; VM’ler yeniden başlar, yani işletim sistemleri açılış yapar. HA’nın sözü “hizmet hiç kesilmez” değil, **“hizmet birkaç dakika içinde kendiliğinden geri gelir”**dir.

Bunun çalışabilmesi için üç şeyin doğru yapılandırılmış olması gerekiyordu.

1. Kapasite rezervi — küme N+1. Kalan hostların, düşen hostun VM’lerini alacak boş kaynağı olmalıydı. Bunu garanti eden mekanizma Admission Control‘dür: küme, tanımlanan sayıda host kaybını karşılayacak kapasiteyi sürekli boş tutar ve kapasite yetmeyecekse yeni VM açılmasına izin vermez.

PS> Get-Cluster CL-IST1-PROD | Select Name, HAEnabled, HAAdmissionControlEnabled, HAFailoverLevel

Name          HAEnabled HAAdmissionControlEnabled HAFailoverLevel
----          --------- ------------------------- ---------------
CL-IST1-PROD       True                      True               1

HAFailoverLevel: 1 — bir host kaybı tolere edilir. Bu, elektrik tarafındaki N+1‘in hesaplama katmanındaki tam karşılığıdır: dört host var, üçü yükü taşıyabiliyor.

Admission Control’ü kapatmayın. “Kaynak yetmiyor, VM açamıyorum” uyarısı can sıkıcıdır ve devre dışı bırakmak cazip gelir. Ama kapattığınız an küme N+1 olmaktan çıkıp N olur; kaybı ancak gerçek bir host arızasında — VM’ler açılamadığında — fark edersiniz.

2. Arıza gerçekten algılanabilmeliydi. HA, hostları yönetim ağı üzerinden kalp atışıyla izler. Ağ koptuğunda host gerçekten öldü mü, yoksa sadece ağdan mı koptu ayrımını yapabilmesi gerekir — çünkü ikisine verilecek tepki farklıdır. Bu ayrımı iki mekanizma sağlar:

• Datastore heartbeating: Host ağdan koptuysa bile paylaşımlı datastore’a yazmaya devam ediyorsa, hâlâ hayattadır. HA varsayılan olarak iki datastore kullanır.
• İzolasyon adresi: Host, yönetim ağında belirlenen bir adrese ping atarak kendisinin mi izole olduğunu anlar. Varsayılan olarak yönetim arayüzünün ağ geçidi kullanılır.

Bu ikisi olmadan HA, ağı kopmuş ama çalışmaya devam eden bir hostun VM’lerini başka yerde açabilir — aynı VM iki yerde çalışır ve veri bozulur.

3. Uygulama iki hosta yayılmış olmalıydı. İşte asıl kritik nokta bu.

Anti-affinity: host yeter mi, rack mi gerekir?

APP-DB kümesi iki düğümlüdür. İkisi aynı ESXi hostunda çalışıyor olsaydı, host arızasında uygulamanın tamamı aynı anda düşerdi; HA ikisini de yeniden başlatana kadar hizmet olmazdı. Bunu engelleyen şey DRS anti-affinity kuralıdır:

PS> Get-DrsRule -Cluster CL-IST1-PROD

Name         Type            Enabled  VM
----         ----            -------  --
AA-APP-DB    VMAntiAffinity     True  {APP-DB-01, APP-DB-02}
AA-APP-WEB   VMAntiAffinity     True  {web-01, web-02, web-03}

Bu kural “bu VM’ler asla aynı hostta çalışmasın” der. Ama bakım gecesinin öğrettiği ders şudur: host ayrımı yetmeyebilir.

SRV-07-04 ve SRV-07-07 aynı anda kapandı — çünkü ikisi de aynı rack’te, aynı hatalı kablolamanın kurbanıydı. Eğer APP-DB-01 ve APP-DB-02 “farklı host” kuralına uyarak rack 07’deki iki ayrı hosta yerleşmiş olsaydı, kural kâğıt üzerinde sağlanmış, gerçekte ise iki düğüm de tek bir hata alanına düşmüş olurdu.

    
flowchart TB
    APP["APP-DB kümesi
2 düğüm"]
    A1["APP-DB-01"]
    A2["APP-DB-02"]
    H1["VMHOST09"]
    H3["VMHOST11"]
    R7["rack 07
pdu-r07-a/b · tor-r07-a/b"]
    R8["rack 08
pdu-r08-a/b · tor-r08-a/b"]
    APP --> A1
    APP --> A2
    A1 --> H1
    A2 --> H3
    H1 --> R7
    H3 --> R8
    linkStyle 2,4 stroke:#dc2626,stroke-width:2.5px
    linkStyle 3,5 stroke:#2563eb,stroke-width:2.5px
    classDef app fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef fa fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef fb fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    class APP,A1,A2 app
    class H1,R7 fa
    class H3,R8 fb

Doğru yapı, anti-affinity kuralını rack farkındalığıyla birleştirmektir. Hostları rack’e göre gruplayıp VM gruplarını bu host gruplarına bağlarsanız, düğümler yalnızca farklı hostlara değil farklı rack’lere, dolayısıyla farklı PDU’lara ve farklı ToR çiftlerine dağılır.

Kural kendini doğrulamaz. Bir anti-affinity kuralının varlığı, VM’lerin gerçekten ayrı hata alanlarında olduğu anlamına gelmez. Kuralı yazdıktan sonra Get-VM APP-DB-01, APP-DB-02 | Select Name, VMHost ile nerede olduklarını, o hostların da hangi rack’te olduğunu fiilen kontrol edin. Bu, serinin başından beri tekrarlanan cümlenin bir kez daha karşımıza çıkışıdır: yedeklilik, tanımlanan değil ölçülen şeydir.

Bir uyarı daha: DRS etkinken vSphere HA, yeniden başlatma yerleşimi için DRS’ten öneri alır ve kuralları gözetir. Ancak kaynak sıkışıklığında bir VM-VM anti-affinity kuralı yeniden başlatma sırasında geçici olarak ihlal edilebilir; DRS bunu sonraki dengeleme çevriminde düzeltir. Yani felaket anında kural bir garanti değil, bir tercihtir — asıl garanti yeterli kapasitedir.

Katman 7: Servis

Sanal makineler ayakta olsa bile kullanıcı hâlâ tek bir adrese bağlanıyorsa, o adres SPOF’tur.

    
flowchart TB
    C["İstemci"]
    V["VIP · 10.20.0.10"]
    LB1["lb-01 · MASTER
priority 150"]
    LB2["lb-02 · BACKUP
priority 100"]
    W1["web-01"]
    W2["web-02"]
    W3["web-03"]
    C --> V
    V --> LB1
    V -. "MASTER düşerse devralır" .-> LB2
    LB1 --> W1
    LB1 --> W2
    LB1 --> W3
    linkStyle 1 stroke:#16a34a,stroke-width:2.5px
    linkStyle 2 stroke:#94a3b8,stroke-width:1.5px
    classDef akt fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef pas fill:#e2e8f0,stroke:#94a3b8,color:#475569
    classDef web fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef cli fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class LB1,V akt
    class LB2 pas
    class W1,W2,W3 web
    class C cli

Bu şemada iki farklı yedeklilik modeli aynı anda çalışıyor ve bu bilinçlidir:

• Yük dengeleyici çifti: aktif-pasif. VIP’i tek seferde tek makine taşır. keepalived gibi bir VRRP uygulaması bunu yönetir; MASTER düşerse BACKUP saniyeler içinde VIP’i üstlenir.
• Arka uçtaki web sunucuları: aktif-aktif. Üçü de trafik alır; biri düşerse yük dengeleyici onu havuzdan çıkarır.

vrrp_instance VI_APP {
    state MASTER
    interface bond0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ****
    }
    virtual_ipaddress {
        10.20.0.10/24
    }
}

VRRP’nin klasik tuzağı: virtual_router_id aynı yayın alanında (broadcast domain) benzersiz olmalıdır. İki farklı servis çifti aynı VLAN’da aynı virtual_router_id değerini kullanırsa, birbirlerinin VRRP duyurularını kendi eşlerinin duyuruları sanarlar; sonuç, açıklanamayan VIP kaymaları ve zaman zaman iki tarafta birden görünen adreslerdir.

Sağlık kontrolünün ne ölçtüğü de en az bunun kadar önemlidir. Yük dengeleyici arka ucu yalnızca TCP portu açık mı diye kontrol ediyorsa, uygulama çökmüş ama port dinlemede kalmışsa trafik kara deliğe akmaya devam eder. Sağlık kontrolü mümkün olduğunca uygulamanın gerçekten iş yapabildiğini sınayan bir uç noktaya yapılmalıdır — veritabanına dokunan basit bir /health yolu, açık bir TCP portundan kat kat fazlasını söyler.

Quorum ve Split-Brain: Çift Sayının Problemi

Buraya kadar her katmanda “ikinci bir kopya” kurduk. Şimdi bu yaklaşımın kendi ürettiği tehlikeye bakalım.

İki düğümlü bir küme düşünün. Aralarındaki ağ koptu. Her iki düğüm de aynı şeyi görüyor: “karşı taraf cevap vermiyor.” İkisi de aynı sonuca varır — “diğeri öldü, hizmeti ben devralmalıyım.” İkisi de yazmaya başlar.

Bu split-brain‘dir ve sonucu genellikle veri kaybından beterdir: veri bozulması. Çünkü iki taraf da kendi versiyonunun doğru olduğuna inanır ve birleştirilebilir bir hal kalmaz.

Çözüm, çoğunluk (quorum) kavramıdır: bir küme, ancak oy hakkı olan üyelerin yarıdan fazlasını görebiliyorsa hizmet verir. İki üyeli bir kümede çoğunluk 2’dir; bölünme durumunda hiçbir taraf çoğunluğu sağlayamaz ve ikisi de durur. Bu yüzden oy sayısı tek olmalıdır.

Üçüncü bir tam düğüm pahalıysa, yalnızca oy kullanan bir tanık (witness / quorum device) eklenir:

    
flowchart TB
    subgraph R07["rack 07 · hata alanı 1"]
        N1["node-01
veri + oy"]
    end
    subgraph R08["rack 08 · hata alanı 2"]
        N2["node-02
veri + oy"]
    end
    subgraph R20["rack 20 · hata alanı 3"]
        WT["tanık
yalnızca oy, veri yok"]
    end
    N1 <--> N2
    N1 <--> WT
    N2 <--> WT
    linkStyle 0 stroke:#64748b,stroke-width:2px
    linkStyle 1,2 stroke:#16a34a,stroke-width:2px,stroke-dasharray:5 3
    classDef nd fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef wt fill:#dcfce7,stroke:#16a34a,color:#14532d
    class N1,N2 nd
    class WT wt

Artık oy sayısı üçtür. node-01 ile node-02 arasındaki bağ koparsa, tanığı görebilen taraf 2 oyla çoğunluğu sağlar ve hizmete devam eder; diğeri 1 oyda kalır ve kendini kapatır.

Tanığın yeri, varlığından daha önemlidir. Tanık node-01 ile aynı rack’teyse, o rack’in elektriği gittiğinde iki oy birden kaybolur ve kalan tek düğüm çoğunluğu sağlayamaz — hizmet, tek bir rack arızasında tamamen durur. Tanık üçüncü bir hata alanında olmalıdır. Felaket kurtarma senaryolarında bu, çoğu zaman üçüncü bir lokasyon anlamına gelir.

Aynı mantık her yerde karşınıza çıkar: vSphere HA’nın datastore heartbeat’i, vSAN’ın witness appliance’ı, Kubernetes’in etcd çoğunluğu, veritabanı kümelerinin arbiter’ı. İsimler farklı, problem aynıdır.

Bazı kümeler bir adım daha atar ve fencing (STONITH — Shoot The Other Node In The Head) uygular: devralmadan önce karşı düğümü fiziksel olarak kapatır; genellikle BMC üzerinden güç keserek. Bu, split-brain’i olasılık olmaktan çıkarır — ama fencing yolunun (yani OOB ağının) çalışır durumda olmasına bağlıdır. Ağ katmanında sorduğumuz “OOB switch’i hangi PDU’dan besleniyor?” sorusu buraya kadar uzanır.

Uçtan Uca: Bir İsteğin Geçtiği Her Hata Alanı

Katmanları tek şemada birleştirdiğimizde tablo şöyle görünür. Kesikli turuncu oklar, ilk yazının konusu olan elektrik katmanının her şeyin altında durduğunu gösteriyor:

    
flowchart TB
    U["Kullanıcı isteği"]
    FW["Güvenlik duvarı çifti
aktif-pasif"]
    LB["Yük dengeleyici çifti
VRRP · VIP"]
    SW["spine + leaf
ECMP · MLAG"]
    NIC["Host NIC teaming
vmnic0 + vmnic1"]
    HOST["ESXi host
küme N+1 · HA"]
    VM["Sanal makine
anti-affinity"]
    HBA["FC HBA
vmhba1 + vmhba2"]
    FAB["Fabric A + Fabric B
tam bağımsız"]
    CTRL["Denetleyici 0 + 1
ALUA"]
    LUN["LUN · veri"]
    PWR["ELEKTRİK
A yolu + B yolu · PDU · PSU"]
    U --> FW
    FW --> LB
    LB --> SW
    SW --> NIC
    NIC --> HOST
    HOST --> VM
    VM --> HBA
    HBA --> FAB
    FAB --> CTRL
    CTRL --> LUN
    PWR -.-> SW
    PWR -.-> HOST
    PWR -.-> FAB
    PWR -.-> CTRL
    linkStyle 10,11,12,13 stroke:#d97706,stroke-width:1.5px,stroke-dasharray:4 3
    classDef net fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef comp fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef stor fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef pw fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef cli fill:#f1f5f9,stroke:#64748b,color:#0f172a
    class FW,LB,SW,NIC net
    class HOST,VM comp
    class HBA,FAB,CTRL,LUN stor
    class PWR pw
    class U cli

Bu şemadan çıkan tek cümle şudur: zincir, en zayıf halkası kadar yedeklidir. On bir bileşenin onunda 2N yedeklilik kurmuş olmanız, on birincisinde tek nokta bıraktıysanız hiçbir şey ifade etmez. Ve pratikte o tek nokta neredeyse hiçbir zaman pahalı olan bileşen değildir — yanlış takılmış bir kordon, tek beslemeli bir yönetim switch’i, aynı rack’e düşmüş iki küme düğümü ya da aynı hata alanına konmuş bir tanıktır.

Felaket Kurtarma: İkinci Lokasyon

Buraya kadar her şey tek bir binanın içindeydi. Bina yanarsa, su basarsa veya elektrik altyapısı günlerce dönmezse hiçbiri işe yaramaz. Bu noktada iki ölçüt devreye girer:

Bu iki sayı teknik değil, iş kararıdır ve maliyeti doğrudan belirler. RPO’yu sıfıra indirmek ile 15 dakikada tutmak arasındaki fark, mimarinin tamamını değiştirir.

Senkron replikasyon (RPO = 0). Her yazma işlemi, ikinci lokasyona da yazılıp onaylanmadan tamamlanmış sayılmaz. Veri kaybı yoktur — ama fizik bir sınır koyar. Işık fiber içinde saniyede yaklaşık 200.000 km yol alır. DC-IST1 (İstanbul) ile DC-ANK1 (Ankara) arasındaki ~350 km, tek yön için ~1,75 ms, gidiş-dönüş için ~3,5 ms demektir. Her yazma işlemine eklenen bu gecikme, yoğun bir veritabanı için kabul edilemez. Bu yüzden senkron replikasyon pratikte yalnızca kampüs içi veya birbirine yakın (tipik olarak 100 km altı) lokasyonlarda kullanılır.

Asenkron replikasyon (RPO > 0). Yazma işlemi birincil tarafta tamamlanır, ikincil tarafa arkadan aktarılır. Mesafe sınırı pratikte kalkar; bedeli, arıza anında henüz aktarılmamış verinin kaybıdır. DC-IST1’in 15 dakikalık RPO’su bu modelin sonucudur.

Replikasyon yedekleme değildir

Bu, felaket kurtarma tasarımındaki en pahalı yanlış anlamadır ve ayrı bir başlığı hak eder.

Replikasyon sadık bir kopyadır — ve bu bir özellik değil, bu bağlamda bir zaaftır. Yanlışlıkla silinen bir tabloyu, bozulan bir dosya sistemini, ya da fidye yazılımının şifrelediği verileri de aynı sadakatle karşı tarafa kopyalar. Genellikle saniyeler içinde.

Yedekleme tarafında yerleşik kural 3-2-1‘dir: verinin 3 kopyası, 2 farklı ortamda, 1‘i tesis dışında. Fidye yazılımı tehdidiyle birlikte buna bir madde daha eklenmiştir: en az bir kopya değiştirilemez (immutable) veya çevrimdışı olmalıdır — çünkü ağdan erişilebilen bir yedek, saldırganın da erişebildiği bir yedektir.

Ve yedeklemenin tek doğrulaması geri yüklemedir. “Yedek işi başarıyla tamamlandı” satırı, verinin geri dönebileceğini kanıtlamaz; yalnızca bir dosyanın yazıldığını söyler. Düzenli restore testi yapılmayan bir yedekleme sistemi, denenmemiş bir varsayımdır. Bu, serinin en başından beri anlattığımız şeyin veri katmanındaki hâlidir.

Failover Test Matrisi

Serinin tamamının vardığı yer burasıdır: yedeklilik, tanımlandığı için değil, test edildiği için vardır. Aşağıdaki matris, DC-IST1’in her katmanı için ne kapatılacağını ve ne beklendiğini tanımlar.

Test disiplininin kuralları ilk yazıdakiyle aynıdır: bakım penceresinde yapılır, öncesinde karşı tarafın sağlığı doğrulanır, her iki yön için ayrı ayrı tekrarlanır ve sonucu — hangi alarmın geldiği, hangisinin gelmediği dâhil — yazılır.

Son satır özellikle önemlidir. Diğer tüm testler bir bileşeni kapatıp sistemin ayakta kaldığını gösterir; restore testi ise ters yönde çalışır ve çoğu kurumda hiç yapılmaz. Yedekleme sisteminizin gerçekten çalıştığını, ancak ona ihtiyaç duyduğunuz günden önce öğrenmiş olmanız gerekir.

Devreye Alma Kontrol Listesi

Yeni bir host üretime alınmadan önce:

• İki NIC de link-up ve farklı leaf’lere bağlı mı? (esxcli network nic list + switch tarafında port eşleşmesi)
• Teaming politikası ile switch yapılandırması birbiriyle uyumlu mu? (iphash ↔ EtherChannel, LACP ↔ vDS + MLAG)
• show vpc brief çıktısında Peer status, keep-alive status ve consistency status sağlıklı mı?
• peer-keepalive, peer-link’ten fiziksel olarak ayrı bir yoldan mı geçiyor?
• LUN başına yol sayısı beklenen değerde ve yollar iki HBA’ya dağılmış mı?
• Küme Admission Control açık ve HAFailoverLevel en az 1 mi?
• HA için en az iki datastore heartbeat ve geçerli bir izolasyon adresi tanımlı mı?
• Anti-affinity kuralları var mı — ve VM’ler fiilen farklı rack’lerde mi?
• Tanık / quorum cihazı üçüncü bir hata alanında mı?
• BMC, OOB ağına bağlı mı ve OOB switch’i iki yoldan besleniyor mu?
• Yeni host, yedekleme kapsamına alındı mı ve bir restore testi yapıldı mı?
• Yukarıdaki failover matrisi bu host için çalıştırıldı mı?

İzleme tarafında ise bu kontrollerin sürekli hâli gerekir. İzleme sisteminizde şu metrikler bulunmalıdır: bond’daki aktif bacak sayısı, vPC peer durumu, LUN başına aktif yol sayısı, kümedeki devralma kapasitesi (HA slot / yüzde), anti-affinity kural ihlalleri, yedekleme işlerinin başarı oranı ve son başarılı restore testinin tarihi.

Sonuç

İki yazı boyunca aynı soruyu on bir kez sorduk: bu bileşenin ikinci kopyası gerçekten ayrı bir hata alanında mı?

Cevap her katmanda farklı bir teknolojiye dayanıyordu — PDU ve PSU, MLAG ve bonding, çift fabric ve multipath, küme N+1 ve anti-affinity, VRRP, quorum, replikasyon. Ama soru hiç değişmedi. Ve her katmanda tuzak aynı biçimi aldı: bileşen sayısı doğru, hata alanı sayısı yanlış.

• İki PSU, tek PDU’ya bağlı.
• İki switch, ortak bir peer-link ve ortak yazılım sürümüyle bağlı.
• İki küme düğümü, farklı hostlarda ama aynı rack’te.
• İki lokasyon, ama tanık ikisinden birinde.
• İki kopya veri, ama ikisi de aynı mantıksal hatayı taşıyor.

DC-IST1’de bakım gecesi iyi bitti. VMHOST10 kapandı, vSphere HA devraldı, kullanıcılar fark etmedi. Ama bu, tasarımın doğru olduğunu değil, o gece şanslı olduğumuzu gösterir — çünkü aynı rack’te ikinci bir sunucu daha kapandı ve eğer kritik bir uygulamanın iki düğümü o iki kasada olsaydı, hesaplama katmanının tüm yedekliliği hiçbir işe yaramayacaktı.

Serinin akılda kalması gereken cümlesi, ilk yazıda söylediğimizin aynısı:

Yedekliliği bileşen sayarak değil, hata alanı sayarak ölçün. Ve saymakla yetinmeyin — test edin.

Alarm üretmeyen arızalar en pahalı arızalardır; çünkü onları ancak gerçek kesinti anında keşfedersiniz.

Ek: Bu Yazıda Geçen Terimler