SAN ve Fibre Channel
Zoning, Name Services ve Güvenli Operasyon
Discovery, Name Server ve RSCN zincirini oku
Ön koşul: WWPN ile FC_ID’yi, FLOGI/PLOGI/PRLI ilişkisinin amacını, frame/credit akışını ve çift fabric yolunu açıklayabilmelisin. Bu dersin sonunda FLOGI database, FCNS/Name Server ve RSCN kanıtlarını görünürlük zincirinde okuyabilecek; zoning’in hangi iletişimi sınırladığını storage mapping ve multipath’ten ayırabilecek; pWWN/alias yaşam döngüsünü active/full/pending zone database ve kontrollü commit ile yönetebilecek; Arven için giriş, doğrulama, geri dönüş ve audit kanıtı bulunan bir zoning değişikliği hazırlayabileceksin. Yaklaşık 29 dakika anlatı, 18 dakika vaka ve 10 dakika kontrollerdir. Vendor komut ezberi veya evrensel zone topolojisi önerilmez.
Bir N_Port fabric’e fiziksel olarak bağlandığında FLOGI ile fabric ilişkisini kurar ve FC_ID alır. FLOGI database, belirli switch/VSAN veya fabric bağlamında hangi pWWN’in hangi interface ve FC_ID ile login olduğunu doğrulamada kullanılır. Portun FLOGI tablosunda görünmesi link ile fabric login’in başarılı olduğunu gösterir; hedefe erişebildiğini, aynı zone’da olduğunu veya LUN gördüğünü kanıtlamaz. Name Server ya da FCNS, login olmuş host ve storage portlarının pWWN, FC_ID ve desteklenen FC-4 türü gibi kayıtlarını dağıtılmış fabric veritabanında tutar. Bir Nx_Port kendi niteliklerini kaydedebilir ve erişebildiği diğer portların niteliklerini sorgulayabilir. FCNS’te hedefi görmek hedefin fabric’te kayıtlı olduğunu gösterir. Zoning görünürlüğü sınırlar; PLOGI/PRLI ve storage mapping tamamlanmadıysa block aygıt yine görünmeyebilir. RSCN, fabric’te disk/port katılımı veya ayrılması, Name Server kaydı ya da zone enforcement değişikliği gibi bir olay olduğunu kayıtlı node’lara bildirir. Bildirim değişikliğin bütün ayrıntısını taşımaz; node’un Name Server’ı yeniden sorgulamasını tetikler. Bu nedenle RSCN “arıza” ile eş anlamlı değildir. Planlı zoning aktivasyonu, port bakımı veya HBA değişimi de RSCN oluşturabilir. Olayın kapsamı, zamanı, etkilenen zone üyeleri ve host davranışı ilişkilendirilir. Görünürlük kanıtı sıralıdır: fiziksel/link state, FLOGI ve FC_ID, FCNS kaydı/FC-4 özelliği, zone üyeliği ve active configuration, PLOGI/PRLI, target mapping, host discovery ve multipath. Troubleshooting bu sırayı kör bir checklist gibi değil, son başarılı kapıdan sonraki bilgi boşluğunu bulmak için kullanır. Her fabric ayrı incelenir; Fabric A başarısı Fabric B’nin kimlik, zone ve mapping doğruluğunu kanıtlamaz.
| Kapı | Kanıt | Kanıtlamadığı |
|---|---|---|
| Link / FLOGI | Port online, pWWN, interface ve FC_ID | Zone veya LUN erişimi |
| FCNS | Port niteliği ve FC-4 kaydı | Storage mapping |
| Active zoning | İzinli initiator–target iletişimi | Doğru LUN sunumu |
| PLOGI / PRLI | Port ve process ilişkisi | Hosttaki doğru multipath policy |
| Host discovery | LUN ve path görünürlüğü | Uygulama kabulü |
| RSCN | Fabric değişikliği bildirimi | Tek başına arıza/kök neden |
ÖRNEK
RSCN olaydır, teşhis değildir
Arven monitoring’i zoning aktivasyonunda RSCN artışı görür. Aynı anda bir host yeni target’ı keşfeder, diğer hostta yanlış alias nedeniyle yol oluşmaz. RSCN iki durumda da değişikliği haber verir; başarısız hostun nedeni değildir. Ekip FLOGI, FCNS, active zone, PLOGI/PRLI, mapping ve host path zincirini iki fabric için karşılaştırır.
MÜŞTERİYE SOR
Bir host “LUN yok” dediğinde iki fabric için link, FLOGI, FCNS, active zone, PLOGI/PRLI, target mapping ve multipath kanıtını hangi araç ve sahiplerle sıralıyorsunuz?
Belirtiyi fabric görünürlüğü, erişim, storage sunumu ve host yolu kapılarına ayırır.
BİLGİNİ KONTROL ET
Bir target portun FCNS veritabanında görünmesi neyi kanıtlar?
Zoning üyeliği ve enforcement sınırını kur
Zoning aynı fabric veya mantıksal fabric içinde hangi port kimliklerinin iletişim kurabileceğini tanımlayan fabric erişim kontrolüdür. Zone üyeleri pWWN, port/alan, FC_ID veya platformun desteklediği alias türleriyle ifade edilebilir. Taşınabilirlik ve kimlik yaşam döngüsü nedeniyle pWWN tabanlı üyelik yaygın bir başlangıçtır; doğru yöntem güncel platform desteği, operasyon modeli ve interop şartıyla doğrulanır. Zone, zone set/configuration ve active configuration ayrılır. Zone üyelik kuralıdır; zone set etkinleştirilecek zone koleksiyonudur; active configuration fabric’in gerçekten enforce ettiği sonuçtur. Full/defined database edit ve gelecekteki nesneleri içerebilir; active database genişletilmiş üyeliklerle çalışan durumdur. “Config’e yazdım” ile “fabric’te aktif ve bütün switchlerde tutarlı” aynı kanıt değildir. Pending değişiklik, diff, lock/session, commit/activate ve distribution sonucu kaydedilir. Hard zoning her frame’in kaynak-hedef kombinasyonunu switch donanımında enforce eder. Soft zoning yalnız discovery/Name Server görünürlüğüyle sınır koyarsa, FC_ID’yi bilen bir uç için aynı güvenlik sonucu sağlanmayabilir. Güncel ürün davranışı ve zone member türü doğrulanır. Default zone politikası açıkça “no access/deny” olarak tasarlanabilir; ancak mevcut cihazlar üzerindeki etkisi test ve change planı olmadan değiştirilmez. Zone boyutu erişim alanı ve değişiklik etkisini belirler. Single-initiator/single-target küçük blast radius ve açık ilişki sunar; zone sayısını büyütür. Single-initiator/multiple-target operasyon sayısını azaltabilir; RSCN, görünürlük ve yanlış üyelik etkisini genişletebilir. Peer/smart zoning gibi özellikler intent ile enforcement girişlerini optimize edebilir; destek ve gerçekten oluşan initiator-target izin matrisi doğrulanır. “Best practice” etiketi müşterinin scale, platform ve değişiklik yeteneği yerine geçmez.
| Nesne/kural | Soru | Operasyon kanıtı |
|---|---|---|
| Zone member | Hangi pWWN/alias hangi rolle? | Kaynak envanter ve owner |
| Zone | Hangi initiator hangi target’a erişir? | İzin matrisi |
| Zone set/config | Hangi zone koleksiyonu etkin? | Pending diff ve active sonuç |
| Enforcement | Hard/soft ve member türü nasıl uygulanır? | Platform/sürüm doğrulaması |
| Default zone | Tanımsız cihazlar ne yapabilir? | Deny sonucu ve istisna |
| Zone modeli | SIST, SIMT veya peer neden seçildi? | Scale, RSCN ve blast radius |
ÖRNEK
Kolay yönetilen zone, geniş etki
Arven tüm hypervisor initiator’larını sekiz target portla tek zone’a koyar. Nesne sayısı azdır; fakat yanlış eklenen host geniş target görünürlüğü kazanır ve bir target değişikliği daha fazla üyeyi etkileyebilir. Ekip desired initiator-target matrisini çıkarır; platformun peer/smart enforcement davranışını doğrular ve yönetim kolaylığını blast radius ile birlikte tartar.
MÜŞTERİYE SOR
Zone modeli hangi initiator–target izin matrisini üretmeli; default zone, enforcement, RSCN kapsamı, database limiti ve günlük değişiklik hacmi bu seçimi nasıl etkiliyor?
Zone adedi veya slogan yerine erişim sonucu, ölçek ve operasyon trade-off’unu görünür kılar.
ŞİMDİ SEN DENE
Desired erişim matrisinden zone üret
İki host, iki fabric ve dört target port için rol, pWWN/alias, izin ve LUN ihtiyacını yaz. SIST, SIMT ve desteklenen peer/smart yaklaşımını zone sayısı, enforcement girdisi, RSCN/blast radius ve database ölçeğinde karşılaştır. Seçtiğin modelin active configuration’da oluşturacağı izin çiftlerini doğrula.
BİLGİNİ KONTROL ET
Bir zone tanımı full database’de bulunuyor fakat active configuration’da yoksa hangi sonuç doğrudur?
Alias, masking ve değişiklik kontrolünü bağla
Alias insanın okuyabildiği adı pWWN gibi kalıcı port kimliğine bağlar. İyi ad ortam, host/cluster, HBA/port rolü ve gerekiyorsa fabric’i anlaşılır kılar; IP adresi, geçici FC_ID veya belirsiz “host1” gibi yaşam döngüsü zayıf bilgilerden kaçınır. Alias kaynağı CMDB veya otomasyon envanteriyle eşleşir. Aynı adın iki fabric’te farklı ve doğru pWWN’e bağlanması beklenebilir; kopyala-yapıştır hatası iki yolu aynı fabric portuna yönlendirmemelidir. Zone alias ile device alias aynı nesne olmayabilir. Cisco’nun güncel belgesi device alias’ın fabric-wide dağıtılabildiğini, pWWN kullanan farklı özelliklerde yeniden kullanılabildiğini; zone alias’ın ise zoning database kapsamıyla sınırlı olduğunu açıklar. Broadcom ve diğer platformlarda ad, dağıtım ve transaction semantiği farklı olabilir. Otomasyon önce platformun canonical alias türünü, active çıktıda adın nasıl genişlediğini ve değişikliğin hangi nesneleri etkilediğini doğrular. Zoning fabric iletişimini sınırlar; storage host registration/mapping veya LUN masking belirli initiator’a hangi volume’un sunulacağını belirler. İki host target’la aynı zone’da olsa da farklı LUN görmelidir. Yanlış masking veri erişim riskidir; yanlış zoning de gereksiz görünürlük ve fabric etki alanı yaratır. Host multipath, aynı LUN’ın izinli yollarını tek aygıt olarak yönetir. Zoning, masking ve multipath üç ayrı desired-state kaydıyla uzlaştırılır. Güvenli change hazırlığında kaynak envanter, exact pWWN, desired erişim matrisi, mevcut active/full database export’u, pending diff, isim standardı, platform limitleri, çakışan session/lock, impact ve rollback bulunur. Değişiklik önce bir fabric’te yapılır; bağlantı, LUN ve uygulama doğrulandıktan sonra ikinci fabric kontrollü ilerler. Rollback yalnız eski config’i activate etmek değildir: alias, zone, mapping, host rescan ve path durumunun hangi sırayla geri alınacağı yazılır.
| Kapı | Girdi/kanıt | Başarısızlıkta eylem |
|---|---|---|
| Kimlik | Kaynak sistemden pWWN ve owner | Yanlışsa durdur |
| Desired state | Initiator–target–LUN–path matrisi | Eksikse onaya gönderme |
| Pre-check | Active/full export, lock ve limit | Çakışmayı çöz |
| Commit/activate | Pending diff ve dağıtım sonucu | Commit/activate etme veya rollback |
| Doğrulama | FLOGI, FCNS, active zone, mapping, path, I/O | İkinci fabric’e geçme |
| Audit | Ticket, before/after, kişi ve zaman | Kayıt kapanmadan işi kapatma |
MÜŞTERİYE SOR
Zoning talebinin pWWN kaynağı, erişim ve LUN sahibi, active/full yedeği, change yetkilisi, tek-fabric doğrulaması ve rollback kararı kimdedir?
Teknik komutu kimlik, veri erişimi, ayrılmış görev ve geri dönüş kontrolüne bağlar.
ŞİMDİ SEN DENE
Zoning MOP ve rollback yaz
Yeni bir Arven cluster node’u için before state, exact pWWN/alias, desired zone/mapping/path, pre-check, pending diff, tek-fabric commit, FLOGI/FCNS/PLOGI/LUN/I/O doğrulaması, ikinci fabric kapısı ve rollback adımlarını yaz. Her adıma owner, timestamp ve saklanacak kanıtı ekle.
BİLGİNİ KONTROL ET
Host target portla aynı zone’da fakat LUN göremiyorsa sıradaki en güçlü kontrol hangisidir?
Arven zoning değişikliğini güvenle yürüt
Arven iki yeni ERP node’unu çift fabric’e ekleyecektir. Talep formunda dört initiator WWPN’i vardır; fakat iki değer HBA node adı, ikisi port adı olarak kopyalanmıştır. Storage ekibi yeni LUN’ı mevcut host group’a eklemeyi, SAN ekibi geniş cluster zone’unu kullanmayı planlar. Pre-Sales tasarımı bu işlemi hazır kabul etmez: WWNN/WWPN ayrımı, port-fabric eşleşmesi, initiator-target-LUN matrisi ve mevcut zone modelinin blast radius’u doğrulanır. Ekip HBA inventory ve switch FLOGI’den exact pWWN’leri iki kaynakla eşler. Her fabric için canonical alias üretir, target owner ile izin çiftlerini, storage owner ile host group ve LUN ID’yi, OS owner ile beklenen path sayısı/policy’yi imzalar. Active ve full database, current alias, mapping ve host path durumu change kaydına eklenir. Pending diff yalnız beklenen alias ve zone üyelerini içermelidir. Fabric A aktivasyonundan sonra RSCN beklenebilir; fakat başarı sayılmaz. Yeni node’un FLOGI/FCNS kaydı, active zone üyeliği, target PLOGI/PRLI, doğru LUN ve tek Fabric A path’i doğrulanır; küçük kontrollü I/O çalıştırılır. Mevcut ERP node’larının path, latency ve error durumu bozulmadıysa Fabric B’ye geçilir. B doğrulamasından sonra beklenen çoklu path, failover ve uygulama kabul testi yapılır. Yanlış pWWN, beklenmeyen diff, zone database/lock sorunu, mevcut host etkisi veya LUN kimlik çakışması stop condition’dır. Rollback ilgili fabric’te yeni zone/alias üyeliğini, gerekirse mapping’i ve host discovery’yi kontrollü geri alır; çalışan diğer fabric korunur. Kapanış paketi ticket, onay, before/pending/active diff, FLOGI/FCNS, mapping, path ve I/O kanıtını; yeni desired state ile CMDB güncellemesini taşır.
| Aşama | Yeni node kanıtı | Mevcut hizmet kanıtı |
|---|---|---|
| Kimlik | WWPN/alias ve fabric eşleşmesi | Mevcut alias bütünlüğü |
| Desired state | Initiator–target–LUN–path matrisi | Yetkisiz yeni erişim yok |
| Fabric A | FLOGI, FCNS, active zone, LUN ve I/O | Fabric B yolları sağlıklı |
| Fabric B | Aynı kapılar ve çoklu path | Mevcut path/latency/error normal |
| Kapanış | Failover, audit ve CMDB | Rollback kanıtı saklı |
ŞİMDİ SEN DENE
Arven zoning change paketini tamamla
İki node ve iki fabric için WWPN/alias, initiator-target-LUN-path desired state’ini üret. Before/full/active export, pending diff, lock/limit kontrolü, Fabric A ve B kapıları, RSCN/FLOGI/FCNS/mapping/path/I/O doğrulaması, stop condition, rollback ve audit sahibi ekle. Üç risk ve üç TBD’yi karar etkisiyle kaydet.
BU DERSTEN AL
Bu dersten taşıyacağın düşünceler
- FLOGI login ve FC_ID’yi; FCNS port kaydı ve niteliklerini kanıtlar.
- RSCN değişiklik bildirir; ayrıntı ve kök neden için node Name Server’ı yeniden sorgular.
- Zoning fabric iletişimini, storage mapping LUN sunumunu, multipath host yol davranışını yönetir.
- Full/pending database ile active enforcement sonucu ayrı doğrulanır.
- Alias yaşam döngüsü canonical pWWN kaynağı ve platform dağıtım semantiği ister.
- Arven change’i bir fabric’te kanıtlanmadan diğerine geçmez ve uçtan uca audit iziyle kapanır.
Son ders bu erişim operasyonunu mimari karar paketine tamamlayacaktır. Fabric topolojisi, ISL/fan-in/oversubscription sizing’i, port ve domain büyümesi, dual-fabric bakım/arıza testleri, firmware/interop yaşam döngüsü ve migration birlikte değerlendirilecek; ardından Modül 9’un 10 soruluk değerlendirmesi Arven SAN karar paketini sınayacaktır.