“Runbook” Seviyesinde Ultra Detaylı Checklist

A) Değişiklik Türünü Seç ve Risk Sınıfını Belirle

1) Değişiklik türü

• Zone ekleme (genelde en güvenlisi)
• Zoneset’e zone ekleme/çıkarma (orta risk)
• Zone üyesi silme (yüksek risk: mevcut erişimi etkiler)
• Zone silme (çok yüksek risk: geri dönüş şart)
• VSAN/IVR değişikliği (çok yüksek risk, ayrı runbook)

2) Risk seviyesi

• Low: Yeni sunucu + yeni LUN, prod’a bağlı değil
• Medium: Var olan zoneset üzerinde ekleme
• High: Üye silme / zone kaldırma
• Critical: Aktif DB/cluster/storage migration sırasında müdahale

Risk High/Critical ise: Rollback planı + uygulama sahibi + storage + OS ekipleri “hazır” olmadan devam etme.

B) Pre-Change Hazırlık (Kanıt Toplama)

1) Fabrik/Topoloji Haritalama (A/B kesinleştirme)

Her fabric için ayrı ayrı not al (A ve B):

• Switch hostname/IP
• VSAN ID
• Aktif zoneset adı
• İlgili zone adı

Komutlar (A fabric):

show switchname
show vsan
show zoneset active vsan <vsan>

Komutlar (B fabric):

show switchname
show vsan
show zoneset active vsan <vsan>

Beklenen: A ve B’de aynı VSAN ve aynı zoneset ismi (kurum standardına göre)
A’da aktif zoneset farklı, B’de farklı / yok → asimetrik zoning riski

2) Mevcut Konfig Snapshot (Geri Dönüş İçin)

Her fabric’te:

• Mevcut running-config alın
• İlgili zone/zoneset çıktılarını sakla
• “Before” çıktıları ticket’a ekle

Önerilen komutlar:

show running-config zone
show zoneset active vsan <vsan>
show zone name <zone> vsan <vsan>
show device-alias database
show fcns database vsan <vsan>

Amaç: rollback gerektiğinde “eski hal” kesin bulunur
“Eski config bende yok” → devam etme

3) Kimlik Doğrulama (WWPN / Alias / Role)

Device-alias doğrulama

show device-alias database | include <alias>

• Alias doğru WWPN’e gidiyor mu?
• Aynı WWPN farklı alias’ta yok mu?
• Initiator/Target rolü net mi?

• Alias adı “veeam” ama WWPN başka sunucuya ait (çok olur!)
• WWPN daha önce decommission host’a ait

4) FCNS (Name Server) ile Canlı Login Kontrolü

show fcns database vsan <vsan> | include <wwpn>

• Bu WWPN şu an logon mu? (FCNS’te görünüyor mu)
• Port-ID/FCID var mı?

FCNS’te görünmesi = fabric’te login olmuş cihaz
FCNS’te görünmüyor ama prod sanılıyor (kablo/port down olabilir)

5) Interface Seviyesi Sağlık Kontrolü (flap/CRC riski)

İlgili portlar için:

show interface fc<slot/port>
show interface fc<slot/port> counters

• Port up/up mu?
• Error/CRC artıyor mu?
• Son flap zamanı var mı?

CRC ve link reset artışı → zoning değişikliği değil, fiziksel problem olabilir

6) Uygulama/Host/Storage Bağımlılık Kontrolleri (Kesinti Önleme)

Host tarafı minimum kontroller

Linux:

• multipath -ll path sayısı normal mi?
• dmesg disk hatası var mı?
• Filesystem kritik mi (DB mount, quorum, log)?

Windows:

• Event Viewer Disk/StorPort hata var mı?
• MPIO path sayısı normal mi?

Storage tarafı minimum kontroller

• LUN/host mapping listesi kontrol edildi mi?
• Bu host’un LUN’ları prod data mı?
• Replication/backup ilişkisi var mı?

• Quorum disk, DB log disk, cluster disk → yüksek risk
• Backup saatinde müdahale

C) Change Plan (Adım Adım Komut Akışı)

Cisco MDS’de “kural”:
Zone’lar zoneset içinde aktif olur.
Prod’da güvenli yöntem: Değişiklik → commit → zoneset activate → tekrar commit → doğrula

Aşağıda 3 senaryo için runbook veriyorum.

Senaryo 1: Yeni Zone Ekleme (En Güvenli)

Amaç: Mevcut erişimi bozmaz, yeni erişim ekler.

1. Zone oluştur (VSAN doğru!)

conf t
zone name <new_zone> vsan <vsan>
 member device-alias <initiator1> initiator
 member device-alias <target1> target

2. Zoneset’e ekle

zoneset name <active_zoneset> vsan <vsan>
 member <new_zone>

3. Commit

zone commit vsan <vsan>

4. Pending kontrol

show zone pending

Beklenen: No pending info found
Eğer pending varsa: commit tekrarla / syntax kontrol

5. Activate (aktif zoneset aynı isim)

zoneset activate name <active_zoneset> vsan <vsan>

6. Tekrar commit (kurum standardı)

zone commit vsan <vsan>

7. Doğrulama

show zoneset active vsan <vsan>
show zone active vsan <vsan>

Senaryo 2: Zone’u Zoneset’ten Çıkarma (Orta-Yüksek Risk)

Amaç: Zone kalsın ama aktif policy’den çıksın.

1. Doğrula: zone gerçekten bu zoneset’te mi?

show zoneset active vsan <vsan>

2. Zoneset moduna gir ve çıkar

conf t
zoneset name <active_zoneset> vsan <vsan>
 no member <zone_to_remove>

3. Commit

zone commit vsan <vsan>
show zone pending

4. Activate + commit

zoneset activate name <active_zoneset> vsan <vsan>
zone commit vsan <vsan>

5. Doğrula

show zoneset active vsan <vsan> | include <zone_to_remove>

Beklenen: Görünmemeli

host tarafında path düşüşü / disk offline → rollback tetikleyici

Senaryo 3: Zone Silme (Çok Yüksek Risk)

Kritik kural:
Aktif zoneset içinden zone’u önce çıkar, sonra sil.
Aksi halde “aktif policy” ile çakışmalar yaşayabilirsin.

1. Zone’u zoneset’ten çıkar (Senaryo 2)
2. Commit + activate + commit + doğrula
3. Zone’u sil

conf t
no zone name <zone_to_delete> vsan <vsan>
zone commit vsan <vsan>
show zone pending

4. Son doğrulama

show zone name <zone_to_delete> vsan <vsan>

Beklenen: “not found” benzeri çıktı

D) Doğrulama: “Etkisiz Değişiklik” Garantisi İçin Kontroller

1) SAN tarafı doğrulama (switch)

• Active zoneset doğru
• Zone listesi doğru
• Pending yok

Komutlar:

show zoneset active vsan <vsan>
show zone pending
show zone active vsan <vsan>

2) Host tarafı doğrulama (en az 2 katman)

• Path sayısı değişmedi (beklenmeyen)
• Diskler online
• Loglarda hata yok

3) Storage tarafı doğrulama

• Host port login normal
• Path sayısı normal
• Alarm yok

E) Rollback Runbook (Hazır Kopyala-Yapıştır Mantığı)

Rollback tetikleyicileri (görürsen düşünme, geri dön)

• DB / uygulama alarm
• Host’ta disk offline / filesystem read-only
• Multipath path sayısı kritik düşüş (ör: 4’ten 1’e)
• Storage alarm (host unreachable)

Rollback adımları (genel)

1. Silinen/çıkarılan zone’u geri ekle (zoneset member + zone tanımı)
2. zone commit
3. zoneset activate
4. zone commit
5. show zone pending ve doğrula

Rollback komutlarını change başlamadan hazır metin olarak tut.

F) Kalıcılık ve Kapanış (En Çok Unutulanlar)

1) Running → Startup Kaydet

copy running-config startup-config

• Her fabric’te yapıldı mı?

2) After-Change Dokümantasyon

• Before/After çıktıları ticket’a eklendi mi?
• Zone map (initiator → target) güncellendi mi?
• Decommission ise “neden silindi” notu var mı?

3) 24 Saat İzleme Planı

• İlk 5 dk: alarm var mı
• İlk 30 dk: host/storage log
• İlk 24 saat: tekrar path flap kontrol

G) Gerçek Hayatta Kesiye Sebep Olanlar

• Sadece A fabric’te change yapmak (B unutuluyor)
• Yanlış VSAN’da işlem yapmak (20 yerine 120)
• Alias yanlış WWPN’e bağlı (en tehlikelisi)
• Backup/replication saatinde zone silmek
• copy run start unutmak (reboot sonrası sürpriz)
• Benzer isimli zone’ları karıştırmak (veeam / veeam01 / veeam_prd)