Kurumsal veri merkezlerinde depolama sistemlerinin kalitesi çoğu zaman yalnızca “kaç IOPS basıyor?” sorusuyla ölçülür. Oysa gerçek dünyada storage altyapısının başarısı şunlarla belirlenir:

• Kesintisiz erişim (Availability)
• Tahmin edilebilir performans (Predictable Performance)
• Güvenlik ve izolasyon (Security & Isolation)
• Kolay işletilebilirlik (Operational Manageability)

İşte Fibre Channel (FC) SAN mimarisi yıllardır bu ihtiyaçları en iyi karşılayan altyapıların başında gelir. Çünkü FC ethernet ağlarına kıyasla daha deterministik, daha kapalı ve “enterprise” tasarıma daha uygun bir yapıda çalışır.

Ancak sağlam bir FC altyapısı kurmak sadece:

• switch’leri fabric olarak ayağa kaldırmak,
• HBA’ları server’lara takmak,
• storage front-end portlarını uplink etmek ile bitmez.

Bütün bu bağlantılar tamamlandıktan sonra asıl kritik soru ortaya çıkar:

“Bu fabric üzerinde hangi sunucu hangi storage portunu görmeli?” Bu noktada devreye giren teknoloji SAN Zoning’dir.

SAN Zoning Nedir?

SAN Zoning Fibre Channel fabric üzerinde kim kiminle konuşabilir sorusunun cevabıdır.

Daha açık anlatımla zoning:

• Hangi initiator’ların (host HBA portları)
• hangi target’lara (storage portları) erişebileceğini belirleyen erişim kontrol mekanizmasıdır.

Bunu IP dünyasındaki bazı kavramlara benzetebiliriz:

• VLAN mantığına benzer: trafiği segmentlere ayırır.
• Firewall mantığına benzer: kural yazar, erişimi sınırlar.
• ACL mantığına benzer: kimin kime ulaşacağını tanımlar.

Ama burada uygulama alanı Fibre Channel fabrictir.

Zoning Olmazsa Ne Olur? (Gerçek Hayat Senaryosu)

Zoning yapılandırılmadığında FC fabric şunu yapar;

• Fabric’e bağlanan her HBA login olur.
• Fabric Name Server üzerinden tüm target’ları keşfetmeye çalışır.
• Mümkünse bağlantı kurar (PLOGI, PRLI vs.)

Bu şu sonuçları doğurur:

Aşırı Discovery / Login Trafiği

Özellikle büyük ortamlarda 50-100 host aynı anda reboot ettiğinde fabric üzerinde ciddi “login storm” oluşabilir.

Güvenlik Açığı

Yanlış storage mapping yapılırsa bir host, başka bir host’a ait LUN’ları görebilir.

SAN zoning “tek başına güvenlik değildir” ama en kritik katmanlardan biridir.

Yönetilemezlik ve Kaos

• Hangi host hangi storage’a bağlı?
• Hangi WWPN neyin nesi?
• Troubleshooting saatler sürebilir.

Multipath Problemleri

Bazı path’ler görünür bazıları görünmez olur. Sonuç:

• path flapping
• dead path
• trespass (özellikle active/passive array’lerde)
• I/O pause

SAN Zoning Ne İşe Yarar? (Faydaları)

SAN zoning çoğu ortamda kurulumun en “sessiz” adımıdır. Bir kez yapılır yıllarca dokunulmaz ama sağladığı faydalar sürekli çalışır.

1) Kontrollü Görünürlük (Controlled Visibility)

Her sunucu yalnızca kendisine tahsis edilen storage portlarını görür.

Bu hem:

• güvenlik,
• hem düzen,
• hem de işletim kolaylığı sağlar.

2) Fabric Trafiğini Optimize Eder

Host yalnızca zone’undaki cihazları keşfeder. Böylece:

• Name Server yükü azalır
• RSCN (Registered State Change Notification) daha az yayılır
• fabric daha stabil olur

3) Multipathing’i “Garantiye” Alır

FC tarafında multipath sağlıklı çalışsın diye iki önemli şart gerekir:

• doğru path’lerin tamamı görünmeli
• path’ler simetrik olmalı (A/B fabric tasarımı)

Zoning burada belirleyici rol oynar. Çünkü multipath agent, ancak gördüğü path’ler üzerinden karar verir.

4) Operasyonel İzolasyon Sağlar

Yanlış yapılandırılmış bir host, tüm SAN’ı etkileyemez.

Örneğin:

• hatalı driver
• yanlış HBA firmware
• sürekli login/logout yapan bir port gibi sorunlar zoning ile sadece ilgili zone’ları etkiler.

SAN Zoning Türleri (En Yaygın Yaklaşımlar)

SAN zoning’i birkaç farklı yöntemle uygulayabilirsiniz.

1) Soft Zoning (WWN Bazlı Zoning)

En yaygın yöntemdir.
Cihazlar WWPN (World Wide Port Name) ile tanımlanır.

Artıları

• Host switch portu değişse bile zoning bozulmaz
• Esnektir
• Best practice’lerde en çok önerilen yöntemdir

Eksileri

• Fiziksel port güvenliği kadar sıkı değildir

2) Hard Zoning (Port Bazlı Zoning)

Cihazlar WWPN yerine switch üzerindeki fiziksel port ile eşlenir.

Artıları

• Çok güçlü güvenlik
• Cihaz başka porta taşınırsa erişim otomatik kesilir

Eksileri

• Operasyon zorlaşır (kablo/port değişikliği riskli hale gelir)
• Bakım süreçlerinde esneklik azalır

3) VSAN / Peer Zoning (Mantıksal Ayrım)

Özellikle:

• multi-tenant veri merkezi
• birden çok müşteri environment’i
• büyük ölçekli kurumsal yapı senaryolarında kullanılır.

VSAN ile fabric’i mantıksal olarak bölümlersiniz.
Peer zoning ise “kimin kime erişeceği” konusunu daha kontrollü hale getirir.

SAN Zoning’in Yapı Taşları (Terminoloji)

SAN zoning’i doğru uygulamanın sırrı; terminolojiye hâkim olmaktan geçer.

1) Alias

WWPN’ler uzun ve okunması zordur:

10:00:00:00:c9:12:34:56

Bunun yerine alias oluşturulur:

• AppSrv01_HBA1
• AppSrv01_HBA2
• PURE_CT0_FC1
• NETAPP_A0B_0

Alias’lar sayesinde:

• dokümantasyon kolaylaşır
• hata ihtimali azalır
• config okunabilir olur

2) Zone

Zone, haberleşmesine izin verilen üyeler grubudur.

En kritik Best Practice: Single Initiator – Single Target

Yani:

• 1 adet initiator (host HBA portu)
• 1 adet target (storage portu)

Bu yaklaşım şu avantajları getirir:

• izolasyon artar
• sorun tespiti kolaylaşır
• RSCN yayılımı ve etkisi azalır
• host’lar birbirini etkilemez

3) Zone Configuration (CFG)

Zone’lar bir “CFG” altında toplanır.

Örnek:

• CFG_PROD_SAN
• CFG_DR_SAN

Switch’te aynı anda genelde tek config aktif olur.

4) Aktif Konfig (cfgenable)

CFG hazırlanıp aktif edilmezse zoning “uygulamaya geçmez”.

Bu yüzden workflow şöyledir:

1. Alias oluştur
2. Zone oluştur
3. CFG’ye ekle
4. CFG enable et
5. Verify et

SAN Zoning Nasıl Tasarlanmalı? (A/B Fabric Mantığı)

Kurumsal ortamlarda standart yaklaşım:

• Fabric A ve Fabric B (tam yedekli iki ayrı yol)

Örnek:

• AppSrv01_HBA1 → Fabric A → Storage Port A1
• AppSrv01_HBA2 → Fabric B → Storage Port B1

Böylece:

• Switch A düşse bile B üzerinden I/O devam eder
• HBA arızalansa bile diğer HBA üzerinden erişim sürer
• Storage port arızasında diğer portlar devrede kalır

Zoning çoğu zaman “fabric bazlı” planlanır. Yani Fabric A ve B’nin zoning’i ayrı yapılır.

Hızlı Zoning Yapılandırma Adımları (Saha Reçetesi)

Adım 1: WWPN Toplama

Host tarafında:

• ESXi: esxcli storage san fc list
• Windows: HBA BIOS / vendor tool
• Linux: /sys/class/fc_host/host*/port_name

Storage tarafında front-end FC port WWPN listesi çıkarılır.

Adım 2: Alias Oluşturma

Her WWPN’yi anlamlı isimle kaydet.

Adım 3: Zone Oluşturma

Her host HBA için storage port ile eşle.

Adım 4: CFG Güncelleme ve Enable

Zone CFG’ye eklenir, aktif edilir.

Adım 5: Test ve Doğrulama

• storage host mapping kontrolü
• host multipath kontrolü
• path sayısı kontrolü
• I/O test

Brocade / FC Switch Üzerinde Örnek Komutlar (Detaylı)

Aşağıda Brocade zoning örneğini daha geniş anlatımla veriyorum:

1) Alias Oluşturma

alicreate "AppSrv01_HBA1","10:00:00:00:c9:12:34:56"
alicreate "Array_Port1","50:00:09:76:ab:cd:ef:01"

Amaç WWPN yerine okunabilir isimler kullanmak.

2) Zone Oluşturma

zonecreate "Z_AppSrv01_HBA1_ArrayP1","AppSrv01_HBA1;Array_Port1"

Burada zone üyeleri “;” ile ayrılır. Single initiator / single target örneğidir.

3) CFG’ye Ekleme

cfgadd "CFG_PROD_SAN","Z_AppSrv01_HBA1_ArrayP1"

4) CFG Enable Etme (Aktif Etme)

cfgenable "CFG_PROD_SAN"

Burada switch aktif zoning’i uygular. Bazı ortamlarda bu adım change window gerektirir.

5) Doğrulama

zoneshow
cfgshow
switchshow

• zoneshow: zone üyelerini listeler
• cfgshow: aktif config’i gösterir
• switchshow: port durumlarını gösterir (online/offline, speed vs.)

En Yaygın Hatalar (Ve Nasıl Önlenir?)

Multiple Initiator Zoning

“Kolay olsun” diye aynı zone içine iki host koymak çok risklidir.

Çözüm: Single initiator / single target.

Fabric A ve B’yi Karıştırmak

A fabric’teki HBA’yı B fabric’e zone etmek multipath dengesini bozar.

Çözüm: A/B planı net dokümante edilmeli.

Zoning ile LUN Masking’i Karıştırmak

Zoning yalnızca “port görsün/görmesin” kontrolüdür.

Asıl LUN erişimi:

• Host mapping
• LUN masking ile storage üzerinden yapılır.

Güvenli tasarım: Zoning + Masking birlikte.

SAN zoning çoğu zaman bir kez yapılandırılır ve uzun süre unutulur.
Ama altyapının stabil çalışmasının en temel sebeplerinden biridir.

Özetle zoning:

• host’ların sadece doğru storage’ı görmesini sağlar
• fabric’i gereksiz keşif trafiğinden korur
• multipath tasarımını düzenli ve deterministik hale getirir
• hataların yayılmasını engeller
• güvenlik ve izolasyon sağlar

Kısacası SAN Zoning, Fibre Channel dünyasında erişim kontrolünün omurgasıdır.

VMware ESXi İçin Zoning / Multipath Doğrulama Komutları

ESXi Host FC HBA’ları Görüyor mu? (İlk Kontrol)

Önce host üzerindeki FC adaptörleri ve WWPN’leri doğrula:

esxcli storage san fc list

Bu komut çıktısında şunları kontrol et:

• Adapter (vmhbaX)
• Port World Wide Name (WWPN)
• Node World Wide Name
• Link State: link-up
• Speed: 16/32Gb (beklenen hız)

Beklenen:

• Her HBA link-up
• Speed doğru
• WWPN’ler elindeki plan/dokümanla birebir aynı

Not: Zoning yaparken yanlış WWPN girilirse ESXi tarafında link-up olur ama storage portu ile login olmaz.

FC Port Login Var mı? (Zoning Doğrulamanın En Kıymetli Göstergesi)

ESXi host, storage portlarına login olmuş mu bakmak için:

esxcli storage core adapter list

Ardından detay için:

esxcli storage core adapter get -A vmhba1

Benzer şekilde diğer HBA için:

esxcli storage core adapter get -A vmhba2

Burada özellikle şunlara bak:

• Driver
• Link State
• Topology (genelde fabric)
• FC Port WWN
• FC Node WWN

Bu bölüm doğru ise switch tarafındaki zoning’in doğru olma ihtimali yükselir.

Storage LUN’ları Görünüyor mu? (LUN Masking + Zoning Sonucu)

esxcli storage core device list

Burada her device için:

• Display Name (vendor/model)
• Devfs Path
• Size
• Multipath Plugin (NMP / PowerPath vb.)

LUN görünmüyorsa:

• zoning yok / yanlış
• storage host mapping (LUN masking) yok / yanlış
• storage front-end portları yanlış hedeflenmiş olabilir

Multipath Durumu (En Kritik Kontrol)

ESXi üzerindeki path’leri görmek için en temel komut:

esxcli storage core path list

Bunu LUN bazlı filtrelemek daha anlamlıdır.

Önce LUN ID / NAA’yı bul:

esxcli storage core device list | grep -i naa

Sonra belirli bir device için path’leri listele:

esxcli storage core path list -d naa.xxxxxxxxxxxxxxxx

Bu çıktıda özellikle şunları kontrol et:

• Runtime Name: vmhbaX:Cx:Tx:Lx
• State: active / standby / dead
• Preferred: true/false
• Adapter: vmhba1 / vmhba2 (her iki HBA da path üretmeli)

Beklenen:

• En az 2 path (küçük ortam)
• Enterprise ortamda genelde 4 path / 8 path
• DEAD path olmamalı

PSP (Path Selection Policy) Kontrolü

NMP kullanıyorsan (çoğu ortam):

esxcli storage nmp device list

Belirli LUN için:

esxcli storage nmp device list -d naa.xxxxxxxxxxxxxxxx

Buradan:

• Storage Array Type (SATP)
• Path Selection Policy (PSP)

kontrol edilir.

En sık görülen PSP’ler:

• VMW_PSP_RR (Round Robin) → genelde önerilir
• VMW_PSP_FIXED
• VMW_PSP_MRU

Storage vendor best practice dökümanına göre PSP seçilmelidir.

Storage Rescan (Değişiklik Sonrası)

Zoning değiştiyse ESXi rescan gerekebilir.

Tüm adapterlarda rescan:

esxcli storage core adapter rescan --all

Datastore / VMFS Doğrulama

Datastore’lar doğru mount edilmiş mi:

esxcli storage filesystem list

VMFS detayları:

esxcli storage vmfs extent list

HBA / Driver / Firmware Görme (Troubleshooting)

HBA sürücü + firmware kontrolü için:

esxcli hardware pci list | grep -i -A20 fibre

Driver modülü:

esxcli system module list | grep -i lpfc

(Emulex: lpfc, QLogic: qlnativefc/qla2xxx vs.)

Log Üzerinden FC Sorunu Yakalama

Özellikle login / path flapping sorunlarında:

tail -f /var/log/vmkernel.log

Arama:

grep -i "NMP\|fc\|path\|vmhba" /var/log/vmkernel.log