“Bandwidth sorunu var” ifadesi, bugün BT ekiplerinde en sık duyulan cümlelerden biri. Ancak çoğu zaman bu cümle, problemi doğru tanımlamaktan çok yanlış bir refleksi temsil eder. Çünkü modern BT mimarilerinde bandwidth, artık yalnızca network hatlarının doluluk oranını ifade eden basit bir metrik olmaktan çıkmıştır. Gerçek hayatta yaşanan performans sorunlarının önemli bir bölümü, bandwidth’in yanlış katmanda aranması nedeniyle uzar, karmaşıklaşır ve gereksiz maliyetler doğurur.
En temel tanımıyla bandwidth (bant genişliği), belirli bir zaman aralığında taşınabilecek veya işlenebilecek maksimum veri miktarını ifade eder. Geleneksel olarak bu tanım, Mbps veya Gbps cinsinden ölçülen network link kapasiteleriyle özdeşleştirilmiştir. Bu yaklaşım teknik olarak yanlış değildir; ancak günümüz sistemlerini açıklamak için yetersizdir.
Çünkü veri yalnızca bir noktadan diğerine taşınmaz. Veri; uygulamalar tarafından üretilir, sunucular tarafından işlenir, storage üzerinde saklanır ve güvenlik katmanlarından geçirilir. Dolayısıyla bu kavram, yalnızca “hat ne kadar dolu” sorusunun cevabı değil, uçtan uca veri akışının ne kadar sağlıklı ilerlediğinin bir göstergesidir.
Doğru değerlendirebilmek için bu kavramı tek bir noktaya değil, sistemin tamamına yayarak ele almak gerekir.
Network katmanı, bu zincirin yalnızca görünen yüzüdür. WAN, LAN, MPLS veya internet hatları üzerindeki yoğunluklar, çoğu zaman ilk bakılan metriklerdir. Ancak network hattının dolu olması her zaman problemin kaynağını göstermez; sadece problemin nerede fark edildiğini gösterir.
Sorun: Network hattı dolu olabilir; ancak bu her zaman gerçek problemin network olduğu anlamına gelmez.
Asıl tüketim çoğu zaman application katmanında başlar. Uygulamaların ürettiği veri miktarı, API çağrılarının sıklığı, veri paketlerinin büyüklüğü ve gerçek zamanlı iletişim ihtiyacı, network üzerindeki baskıyı doğrudan etkiler. Network trafiği düşük görünmesine rağmen uygulama performansı kötü ise, sorun genellikle network değil; uygulamanın veri üretim modelidir.
Örnek: Network %30 dolu görünürken uygulama yavaşsa, sorun bant genişliği değil; uygulamanın veri üretim ve tüketim şeklidir.
Klasik monitoring çözümleri bu noktada yalnızca “trafik var” der; nedenini söyleyemez.
Bir diğer kritik katman infrastructure’dır. Sunucuların CPU, memory ve network kartı kapasitesi, efektif bant genişliğini doğrudan belirler. Teorik olarak yüksek network kapasitesine sahip bir sistem, işlem gücü yetersizse bu kapasiteyi kullanamaz. Bu durumda bant genişliği problemi varmış gibi algılanan durum, aslında compute kaynaklarının sınıra dayanmasıdır.
Bir sunucu 10 Gbps network kartına sahip olabilir; ancak CPU %95 ise efektif bant genişliği düşer.
Sonuç: Network sağlamdır, ama iş yavaştır.
Özellikle yedekleme, loglama ve veri yoğun uygulamalarda kritik bir katmandır. Storage katmanı da bu kavramın ayrılmaz bir parçasıdır. Disk throughput, IOPS sınırları ve SAN/NAS bağlantı kapasiteleri özellikle yedekleme, loglama ve veri yoğun uygulamalarda belirleyici olur. Network üzerinden akan verinin yavaşlaması çoğu zaman storage I/O darboğazının bir sonucudur; ancak klasik monitoring bu ayrımı yapamaz.
Çok sık karşılaşılan bir durum:
“Network bandwidth problemi var” diye açılan ticket’ın kök nedeni, storage I/O darboğazıdır.
Güvenlik katmanı çoğu zaman göz ardı edilir; ancak ciddi bir bant genişliği tüketicisidir. Son olarak security katmanı, çoğu kurumda bant genişliği tartışmalarının dışında kalır. Oysa firewall’lar, SSL inspection mekanizmaları ve saldırı önleme sistemleri ciddi bir veri işleme yükü oluşturur. Güvenlik cihazlarının kapasite sınırına ulaşması, network ve application tarafı sağlam görünürken bile kullanıcı deneyimini doğrudan bozabilir.
Güvenlik cihazı doygunluğu:
Geleneksel monitoring çözümleri bant genişliğini genellikle izole metrikler üzerinden değerlendirir. Belirli bir eşik aşıldığında alarm üretir, grafikler sunar ve geçmişe dönük raporlar oluşturur. Ancak bu yaklaşım üç temel sorunu beraberinde getirir.
Sonuç olarak monitoring çözümleri “ne oluyor” sorusuna cevap verir; ancak “neden oluyor” ve “ne yapılmalı” sorularını cevapsız bırakır.
ODYA Automated NOC, bandwidth’i izlenen bir sayı olarak değil, yönetilmesi gereken bir risk alanı olarak ele alır. Temel fark, bant genişliği problemlerini tek bir katmanda değil; network, application, infrastructure, storage ve security katmanlarının tamamı üzerinden birlikte değerlendirmesidir.
Bu yaklaşım sayesinde, yanlış teşhislerin önüne geçilir. Network’te görülen bir doygunluğun gerçekten network kaynaklı mı, yoksa application veya storage kaynaklı mı olduğu net biçimde ortaya konur. Aynı kök nedene bağlı birden fazla alarm, tek bir anlamlı olay haline getirilir. Böylece NOC ekipleri grafik izlemek yerine, aksiyon alabilecekleri olaylara odaklanır.
ODYA Automated NOC’un bir diğer önemli farkı, bant genişliği problemlerini iş etkisiyle ilişkilendirmesidir. Hangi bant genişliği sorununun hangi uygulamayı, hangi kullanıcı grubunu ve hangi iş sürecini etkilediği net biçimde görülebilir. Bu da teknik ekipler ile CIO seviyesindeki karar vericiler arasında ortak bir dil oluşmasını sağlar.
Otomasyon katmanı ise bu yaklaşımı tamamlar. Bandwidth kaynaklı olaylar otomatik olarak doğru ekiplere yönlendirilir, gerekli durumlarda ön tanımlı aksiyonlar devreye alınır ve sorun çözüldüğünde süreç kapalı döngü şeklinde tamamlanır.
Bant genişliği, artık sadece network ekiplerinin takip ettiği teknik bir metrik değildir. Application’dan storage’a, infrastructure’dan security’ye uzanan uçtan uca bir kapasite göstergesidir. Bu nedenle bant genişliği problemlerini yalnızca network üzerinden okumak, çoğu zaman yanlış teşhis ve gecikmiş çözüm anlamına gelir.
ODYA Automated NOC’un farkı tam olarak burada ortaya çıkar:
Bandwidth’i ölçmekle yetinmez; ondan kaynaklı iş risklerini görünür, yönetilebilir ve otomatik hale getirir.
ODYA Automated NOC hakkında detaylı bilgi için formu doldurun, size ulaşalım!