Sabah 03:20’de operasyon ekibinden bir mesaj geldi: “Gece batch’leri başarısız, uygulama veritabanlarına erişilemiyor.” O an kafamda birkaç klasik neden belirdi ama yaklaşımımı veriyle kanıtlamaya odakladım. Bu vakada, problemi bulup kapatana kadar geçen saatler boyunca küçük kontroller, log okuma ve host-storage ortak çalışma rutini bana yeniden hatırlattı: depolama kaynaklı performans dalgalanmaları, özellikle iSCSI katmanında, kümelenmiş veritabanı servislerini hızla kararsızlaştırır.
Sorunun ortaya çıkışı
Belirtiler şunlardı: SQL Server Always On Availability Group (AG) replikalarından biri otomatik olarak düşüyordu, bazı veritabanlarında I/O timeouts görülüyordu ve Windows Failover Cluster kaynakları birkaç dakikalığına başka düğümlere taşınıyordu. Uygulama takımları gece batch’lerinin zaman aşımından dolayı başarısız olduğunu raporladı. İlk rapor zamanı: 03:05 — bu, yoğun I/O saatiydi.
Teşhis — 1: Hızlı durum tespiti (ilk 15 dakika)
İlk işim sistem sağlığına hızlı bakmaktı. Bu komutlarla cluster ve Windows olay günlüklerini aldım:
Get-ClusterLog -Destination C:\Temp\ClusterLogs -TimeSpan 60Aynı zamanda ilgili Windows Event Viewer kanallarında (System, Application, FailoverClustering) zaman damgalarını taradım. Öne çıkan kayıtlar: “I/O timeout on volume”, “Disk resource lost I/O path”, ve MPIO ile ilgili tekrar eden uyarılar. Bu çıktı, sorunun depolama katmanında aranması gerektiğine işaret ediyordu.
Teşhis — 2: Depolama/Host katmanını kontrol etmek
Sunucuda MPIO ve iSCSI durumunu kontrol ettim. Örnek komutlar:
Get-IscsiSessionmpclaim -s # mevcut MPIO path sayıları ve durumlarımpclaim ve vendor MPIO araçları, bazı path’lerin sık sık “dead”/”recovered” döngüsünde olduğunu gösteriyordu (yani path flapping). SAN tarafında da aynı zamanlarda path reset/timeout olayları raporlanmıştı. Storage üreticisinin yönetim konsolunda onlara ait link/port durumlarında eş zamanlı uyarılar vardı.
Teşhis — 3: IO gecikmeleri ve uygulama perspektifi
SQL Server tarafında bekleme (wait) istatistiklerine baktım; I/O related wait’ler (PAGEIOLATCH_*, WRITELOG) artmıştı. Windows üzerinde disk latency’yi görmek için aşağıdaki yardımcıları kullandım:
typeperf "PhysicalDisk(_Total)\Avg. Disk sec/Read" -sc 10
or
Get-PhysicalDisk | Format-List FriendlyName, MediaType, OperationalStatusOkunan değerler normal aralığın çok üstündeydi; batch işlemlerinin büyük sıralı I/O yarattığı saatlerde bu dalgalanma kritik eşikleri aşıyordu. Ayrıca SAN tarafında recent firmware update (ilave bir değişiklik kaydı) olduğunu öğrendik — değişiklik kontrolü eksik yapılmıştı.
Çözüm adımları (uygulanan ve doğrulanan)
- Geçici hafifletme: SQL sunucularında AG failover hassasiyetini azaltmak için cluster resource health check eşiklerini geçici olarak yükselttik. Böylece kısa path recovery döngülerinin failover tetiklemesini engelledik. (Her zaman dikkatli olun; bu, gerçek donanım arızalarını gizleyebilir.)
- Path izolasyonu ve yeniden yapılandırma: Etkilenen hostlarda iSCSI bağlantılarını kontrollü şekilde yeniden başlattık: önce birer path’i devre dışı bırakıp diğer yolların stabil olduğunu doğruladık, sonra sırayla tüm iSCSI oturumlarını yeniden başlattık. MPIO politikalarını (Round Robin / FailoverOnly) vendor tavsiyesine göre geçici olarak ayarladık.
- Depolama üreticisi ile koordinasyon: SAN yöneticileriyle birlikte aynı zaman dilimindeki firmware değişikliklerini gözden geçirdik. Vendor, problemli firmware sürümünü doğruladı; rollback planı uygulandı ve ilgili hostlara test edilmiş uyumlu sürüm dağıtıldı.
- Kalıcı düzeltme: Firmware rollback ve host tarafı MPIO parametre ayarlarından sonra sistemleri testi gece trafiği altında izledik. I/O latency normale döndü, MPIO path flapping durdu. AG replikaları stabil hale geldi; failover’lar durdu.
- Change Control ve İzleme: Depolama firmware değişiklikleri için canary/çoğaltma ortamında test zorunluluğu getirdik. Ayrıca host-side MPIO ve SAN path durumunu gösteren basit bir alert playbook’u ekledim (örneğin path downtime > 30s => pager trigger).
Alınan dersler
Birkaç pratik not paylaşıyorum: depolama değişiklikleri en fazla disiplin gerektiren alanlardan biridir; tek bir firmware güncellemesi, doğru test döngüsü yoksa veritabanı hizmetlerini kısa sürede bozabilir. Host ve storage ekipleri arasındaki iletişimi güçlendirmek, değişiklikleri küçük gruplarda önce test etmek ve MPIO davranışını gerçek iş yüküyle doğrulamak hayati. Ayrıca, Failover Cluster hassasiyet ayarlarını acil durumlarda bilerek kullanmak işleri kurtarırken aynı zamanda riskler getirdiğini unutmamak gerekiyor.
Bu vaka bana bir kez daha hatırlattı: sistemler katmanlar halinde birbirine bağlı; bir katmandaki küçük stabilite sorunu, üst katmanda büyük bir görünür arıza olarak kendini gösterir. Sabah kahvemi alırken düşündüğüm şey şu oldu — küçük değişiklikleri 03:00’te üretimde yapmak, kahve molasını çok uzatabiliyor. Bir sonraki güncelleme penceresini daha temkinli planladık.