# Vaka: SQL Sunucuları Failover Yapıyor — iSCSI Yol Dalgalanması (Path Flapping) Nasıl Teşhis Edip Çözdüm

- Bağlantı: https://musti.org/guncel-teknoloji/iscsi-path-flapping-sql-failover-cozum/
- Yayımlanma: 2026-09-30T09:17:09+03:00
- Yazar: mmutlu

🎧 Bu yazıyı dinleyebilirsiniz

Tarayıcınız ses oynatmayı desteklemiyor.

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 60
    ```

Aynı 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-IscsiSession
    ```

    ```
    mpclaim -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, OperationalStatus
    ```

Okunan 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.