Frame, Flow Control ve Fabric Davranışı

Ön koşul: SAN hizmetini, FC-0–FC-4 seviyelerini, N/F/E port rollerini, WWPN/FC_ID kimliklerini ve çift fabric veri yolunu açıklayabilmelisin. Bu dersin sonunda üst katman I/O’sunun information unit, frame, sequence ve exchange ilişkisini okuyabilecek; buffer-to-buffer credit’in her link yönünde nasıl akış kontrolü kurduğunu açıklayabilecek; credit stall, slow drain, over-utilization ve congestion belirtilerini ayırabilecek; Arven için ISL, fan-in ve telemetry içeren ölçülebilir fabric kabul planı hazırlayabileceksin. Yaklaşık 30 dakika anlatı, 18 dakika vaka/uygulama ve 10 dakika kontrollerdir. Vendor’a özgü komut ve otomatik tuning reçetesi verilmez.

Uygulama veya üst katman protokolü bir bilgi birimi üretir. Fibre Channel bu bilgiyi taşıyabileceği frame’lere böler; birbiriyle ilişkili frame’ler sequence içinde sıralanır, aynı operasyonun karşılıklı sequence’leri exchange bağlamında tutulur. FCIA’nın modern mimari materyali frame, sequence, exchange ve protocol hiyerarşisini; segmentation, reassembly, error detection ve recovery ile birlikte ele alır. Bir SCSI read veya NVMe I/O tek bir “paket” değildir; komut, veri ve durum akışı bir exchange boyunca birden fazla frame doğurabilir. Frame başlangıç/bitiş ayraçları, header, payload ve CRC gibi alanlarla link üzerinde taşınabilir birimdir. Header kaynak ve hedef kimliği, sequence/exchange bağlamı ve kontrol bilgisi taşır. CRC bozulmayı algılamaya yardım eder; fakat tek başına uygulamanın doğru veriyi, doğru sırada ve kabul süresinde aldığını kanıtlamaz. Link hata sayaçları, sequence recovery, üst katman retry/timeout ve uygulama sonucu aynı olay penceresinde değerlendirilir. Sequence aynı yönlü, sıralı frame grubudur; exchange initiator ve responder arasındaki operasyon bağlamıdır. Bu ayrım troubleshooting’de önemlidir: fiziksel hata tek frame’i bozabilir, recovery sequence’i yeniden isteyebilir, gecikme exchange timeout’una ve üst katman hatasına dönüşebilir. “CRC yok, fabric sağlıklı” sonucu kurulmaz; credit bekleme veya aşırı kullanım frame bozulmadan da latency yaratabilir. Frame boyutu ve iş yükü karışımı link verimini etkiler. Çok sayıda küçük I/O daha fazla frame/header ve işlem oranı; büyük sequential transfer daha yüksek sürekli bant genişliği talebi oluşturabilir. Port throughput yüzdesi, frame rate, payload boyutu, yön, süre ve uygulama I/O profili olmadan açıklanmaz. Aynı Gbit/s iki workload’da farklı exchange concurrency ve tail latency üretebilir.

Fibre Channel buffer-to-buffer credit ile link düzeyinde, hop-by-hop akış kontrolü yapar. Her alıcı port kaç frame buffer’ı kabul edebileceğini komşu göndericiye bildirir. Gönderici bir frame yolladığında kullanılabilir transmit credit azalır; alıcı buffer’ı işleyip yeniden hazır olduğunda R_RDY ile credit’i geri verir. Kalan credit sıfırsa gönderici yeni frame iletemez. Bu mekanizma her linkte ve her yönde bağımsız işler; initiator ile target arasında tek, uçtan uca credit havuzu yoktur. Credit frame’in kendisi veya bant genişliği kotası değildir; alıcıda bir frame için buffer kullanılabilirliğini temsil eder. Link hızlanınca aynı sürede daha çok frame taşınır. Mesafe arttığında frame’in gidip credit’in geri dönme süresi uzar; hattı dolu tutmak için gereken buffer sayısı artabilir. Yeterlilik link hızı, round-trip mesafe/gecikme, frame boyutu ve platformun credit yönetimiyle değerlendirilir. Ezber bir “kilometre başına credit” sayısı farklı hız ve frame karışımına uygulanmaz. F_Port bağlantısında credit parametreleri fabric login sırasında, E_Port/ISL bağlantısında link parametre değişimi sırasında ilişkilendirilebilir. Uygulamada static, dynamic veya shared buffer davranışı platform ve sürüme göre değişir. Datasheet toplam buffer sayısı her porta aynı anda tahsis edilen sayı değildir. Uzun mesafe veya çok hızlı ISL sizing’i güncel üretici desteği, lisans, port grubu paylaşımı ve gerçek frame profiliyle doğrulanır. Sıfır transmit credit görülen süre, her zaman yetersiz tahsis anlamına gelmez. Karşı uç frame’leri yavaş işlediği için credit geç dönebilir; downstream link dolu olabilir; fiziksel hata credit kaybına yol açabilir; paylaşılan buffer başka trafikle baskılanabilir. Credit metriği yön, port rolü, trafik hedefi ve downstream zinciriyle okunur. Daha çok buffer semptomu geciktirebilir fakat sürekli giriş-çıkış dengesizliğini çözmez.

Congestion, belirli noktaya gelen frame oranı çıkışın taşıyabildiği orandan yüksek olduğunda oluşur. Over-utilization giriş talebinin linkin sürdürülebilir throughput’unu aşmasıdır. Slow drain ise bir uç aygıtın veya downstream yolun frame’leri beklenen hızda tüketmeyip credit’i geciktirmesidir. Her ikisi upstream portlarda zero-credit ve queue büyümesi üretebilir; tedavileri farklıdır. FCIA, credit stall ile oversubscription’ı ayırmak için credit dönüş hızının yanı sıra throughput değerlendirmesini önerir. Slow drain; yoğun target, problemli HBA/driver, uzun pause, queue baskısı veya protokol davranışından doğabilir. Credit geri dönmeyince switch frame’leri tutar, paylaşılan buffer veya ISL üzerinden backpressure upstream’e yayılabilir. Aynı kaynakları kullanan ilgisiz victim flow’lar latency ve timeout yaşayabilir. Sorunun görüldüğü port her zaman sebep değildir; congested point, source, destination ve victim akışları ayrılır. Over-utilization sürekli talebin çıkış kapasitesinden büyük olmasıdır. Hız uyumsuzluğu, çok sayıda hızlı initiator’ın tek target porta fan-in’i veya oversubscribed ISL bunu doğurabilir. Alıcı credit’i normal hızda döndürse bile throughput sınırı dolar. Çözüm workload zamanlaması, target/ISL kapasitesi, path dağılımı, fan-in veya QoS olabilir; yalnız credit eklemek kalıcı throughput açığı yaratmaz. Telemetry en az port throughput/frame rate, zero-credit/TxWait, queue, discard, CRC/link error, credit loss recovery, timeout ve fabric notification olaylarını içerir. FPIN gibi bildirimler fabric’in etkilenen endpoint’i haberdar etmesine yardım edebilir; destek HBA, switch, firmware ve yönetim zincirinde doğrulanır. Alarm eşiği evrensel sayı değildir. Baseline, olay öncesi normal davranış, uygulama SLO’su ve platform sayaç semantiğiyle kurulmalıdır.

Arven ay sonu ERP p99 artışını Fabric A’ya bağlar. Bir ISL yüzde 85–95 throughput gösterir, upstream portlarda TxWait yükselir ve aynı ISL’yi kullanan raporlama hostları da yavaşlar. Fabric B’de belirti yoktur. Bu veri “ISL yetersiz” sonucuna yaklaşsa da tek başına kök neden değildir: target portun credit’i yavaş döndürmesi upstream backpressure yaratabilir veya çok sayıda source aynı anda ISL’yi gerçekten doyurabilir. Ekip önce saatleri eşler: ERP transaction ve p99, host outstanding I/O/timeout, HBA path, her hopun throughput/frame/credit/queue/error sayaçları, target port ve controller latency, storage backend yükü. Trafik yönü ve source–destination eşleşmesi çıkarılır. Credit dönüşü line rate sürüyor ve ISL sürekli doluyorsa fan-in/oversubscription; target tarafında credit gecikiyor ve etkisi geriye yayılıyorsa slow drain hipotezi güçlenir. CRC/encoding artışı varsa fiziksel yol ayrı incelenir. Test üretim güvenliğiyle yapılır. Kontrollü yükte raporlama akışı zamanlanır veya alternatif target/path’e yönlendirilir; ERP p99 ve ISL davranışı karşılaştırılır. Tek değişken, başlangıç/bitiş, rollback ve gözlem sahibi yazılır. ISL trunk genişletme, target port dağılımı, path policy, workload throttling veya sorunlu endpoint düzeltmesi ancak kanıtlanan neden ve güncel platform desteğiyle seçilir. Karar paketi normal/tepe baseline, frame ve throughput profili, hop-by-hop credit/TxWait, source–destination–victim haritası, ISL fan-in, target queue, error ve application SLO’yu birlikte taşır. Varsayım ve TBD’ler sahiplenir. Kabul; normal, tepe, tek yol kaybı ve bakımda p99/throughput/hata eşiklerini; alarmın doğru port ve akışı göstermesini; runbook’un sorunu source, destination ve victim olarak sınıflandırabilmesini gerektirir.

Bir sonraki ders bu performans kanıtını güvenli erişim operasyonuna bağlar. Name server discovery, zoning üyeliği ve enforcement, alias/WWPN yaşam döngüsü, storage masking, change planı, dağıtılmış zone database ve rollback birlikte ele alınacaktır. Frame ve credit telemetry’si zoning değişikliğinin RSCN, login ve victim flow etkisini değerlendirmek için Arven kanıt paketinde korunur.