Sanallaştırma platformu operasyonunda en riskli işlerden biri “host patch”tir. Çünkü aynı anda hem compute katmanına dokunursun hem de çoğu workload’un kaderini DRS/HA kararlarına bırakırsın. Sağlam bir runbook olmadan yapılan remediation, “patch” değil “platform değişikliği” gibi davranır.
Bu yazıda, vSphere/ESXi host patch sürecini bakım dalgaları (ring rollout) ve net geri dönüş koşullarıyla nasıl yönetebileceğini anlatıyorum.
Hedef: “tek seferde tüm cluster” değil, ring bazlı güvenli ilerleme
Benim sahada kullandığım ring yaklaşımı:
- Ring 0 (canary): 1 host (en düşük riskli workload’lar)
- Ring 1: cluster’ın %10–20’si
- Ring 2: kalan host’lar
Her ring arasında “sağlık kontrolü” ve “geri dönüş penceresi” vardır.
Pre-check list (bakım başlamadan)
Bakım penceresi başlamadan şu kontrolleri yap:
- Cluster’da N+1 kapasite var mı? (en az 1 host kaybını kaldırmalı)
- DRS etkin mi? vMotion sağlıklı mı?
- Datastore kapasitesi ve latency normal mi?
- HA admission control ve failover slot modeli gözden geçirildi mi?
- Donanım/driver uyumluluğu (HCL) ve firmware bağımlılıkları doğrulandı mı?
- vCenter yedeği / snapshot (kurum standardına göre) alındı mı?
Değişiklik kapsamı: patch mi, firmware mi?
Saha gerçeği:
- Sadece ESXi patch’i bile NIC/storage driver davranışını etkileyebilir.
- Firmware upgrade daha yüksek risklidir ve ayrı runbook ister.
Öneri:
- Aynı bakım dalgasında “ESXi patch + firmware” birleştirme. Ayrıştır.
Runbook: bir host üzerinde remediation akışı
- Host’u tahliye et (evacuate)
- DRS ile VM’leri otomatik taşı (mümkünse)
- Taşınmayan VM’ler varsa sebebini yaz: affinity rule, pinned device, datastore, vMotion disable
- Maintenance Mode
- Host maintenance mode’a girer
- Eğer “quick exit” gerekiyorsa plan net olsun (geri çık, ring’i durdur)
- Remediate / Patch
- Lifecycle Manager (veya kurum standardı) ile remediation
- İşlem sırasında: host connectivity, datastore path ve NIC link durumlarını izle
- Reboot + sağlık kontrolü
Minimum sağlık kontrolü:
- Host yeniden bağlandı mı?
- NIC uplink’ler ve VLAN’lar doğru mu?
- Storage path’ler (MPIO) normal mi?
- Cluster alarm’ları arttı mı?
- Basit bir “smoke test” VM’i çalışıyor mu?
- Maintenance Mode’dan çıkar
- Host tekrar resource pool’a döner
- DRS rebalance kontrolü (aşırı churn varsa sınırla)
Ring gate: bir sonraki dalgaya geçme koşulları
Ring 0 sonrası “go/no-go” kriteri:
- 30–60 dk içinde yeni alarm/incident yok
- vMotion ve HA olayları anormal artmadı
- Storage/NIC error sayıları artmadı
- Uygulama ekipleri “servis stabil” onayı verdi (kritik servisler için)
Geri dönüş (rollback) planı
Rollback planı “teoride var” değil, “pratikte çalışır” olmalı:
- Eğer patch sonrası host stabil değilse: host’u tekrar maintenance’a al, ring’i durdur
- Bir önceki image/baseline’a dönüş prosedürü kurum standardıyla yazılı olmalı
- Gerekirse workload’u başka cluster/site’a taşımak için acil plan hazır olmalı
Sonuç
vSphere/ESXi host patch süreci, doğru yönetilmezse platformu kırabilecek kadar kritik bir değişikliktir. Ring bazlı bakım dalgaları, net pre-check listesi, ölçülebilir gate’ler ve gerçekçi rollback planı ile remediation; stresli bir gece operasyonu olmaktan çıkıp yönetilebilir bir rutin haline gelir. Büyük ölçekli altyapılarda sürdürülebilirlik, “patch’i yapmak” değil “patch’i güvenle tekrar edebilmek” demektir.