Bu Konu Neden Önemli?
QoS, sınırlı ağ kapasitesinde farklı trafik türlerine sınıflandırma, işaretleme, kuyruklama ve öncelik politikaları uygulamak için kullanılır.
Karar Verirken Kontrol Edilecek Noktalar
Önce gerçek congestion noktalarını belirleyin.
Uygulama sınıflarını gereksiz ayrıntıya bölmeyin.
DSCP işaretlemelerini uçtan uca tutarlı yönetin.
QoS'u bant genişliği eksikliğinin kalıcı çözümü olarak görmeyin.
Mimari ve çalışma modeli
QoS kapasite yaratmaz; tıkanıklık sırasında trafiği sınıflandırır, işaretler ve kuyruklar arasında paylaştırır. DSCP güven sınırı ve her ağ atlamasının işaret davranışı önemlidir. Öncelik kuyruğu sınırsız bırakılırsa diğer hizmetlerin kaynaklara erişimini kısıtlayabilir. Uplink kapasitesi ve shaping değeri gerçek operatör sınırıyla uyumlu olmalıdır.
- 1Trafik sınıflandırma
- 2DSCP/güven sınırı
- 3Kuyruk ve shaping
- 4Yoğunlukta kalite
Tasarım parametreleri
- İşaretleme ve güven
- DSCP’nin hangi noktada üretildiğini ve nerede güvenildiğini belirleyin; kullanıcı işaretini sınırsız kabul etmeyin.
- Kuyruk ve darboğaz
- QoS kapasite üretmez; düşük hızlı çıkıştaki shaping ve kuyruk davranışını test edin.
- Adres ve yönlendirme
- Subnet, gateway, route ve NAT kapsamını çizimde ayrı gösterin. DNS cevabı ile hedef IP’ye gerçek yolu birlikte doğrulayın.
- Yedek yol
- Yedek bağlantının aynı cihaz, enerji veya operatör arızasını paylaşmadığını kontrol edin. Geçiş süresini uygulama üzerinden ölçün.
- Taşıma kapasitesi
- Port hızı, uplink yoğunluğu, paket kaybı ve kuyrukları birlikte değerlendirin. Tek bir test akışı bütün kapasiteyi temsil etmeyebilir.
- İşletim görünürlüğü
- Arayüz sayaçları, komşuluklar, hata kayıtları ve zaman senkronizasyonunu izleyin. Normal davranış için başlangıç ölçümü tutun.
Hesap ve uygulama örneği
G.711 için 20 ms paketlemede 160 byte payload ve 40 byte IP/UDP/RTP başlığı, saniyede 50 paketle Layer 3te yaklaşık 80 kbit/s verir; link ve tünel overhead ayrıca eklenir. Örnek testte ses görüşmesi ile büyük transfer birlikte çalışsın; jitter, kayıp ve kuyruk düşmesini ölçün.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Ses yalnız yoğun saatte kesiliyor | Darboğaz kuyruğu veya kaybolan işaretleme olabilir. | Uçtan uca DSCP, drop, jitter ve çıkış kuyruğunu yük altında ölçün. |
| Aynı VLAN çalışıyor, uzak ağ çalışmıyor | Gateway, route, ACL veya dönüş yolu farklı olabilir. | Kaynak ve hedef tarafında adres, route ve politika kayıtlarını karşılaştırın. |
| Küçük istek çalışıyor, büyük aktarım duruyor | MTU, paket kaybı veya hedef depolama beklemesi olası ayrımlardır. | Paket boyutu ve yeniden iletimleri ölçün; ağ sorununu disk beklemesinden ayırın. |
| Yedek bağlantı var ama kesinti uzun | Algılama, yeniden yakınsama, DNS veya oturum yenilenmesi süreyi büyütebilir. | Arıza zamanını ve ilk başarılı uygulama işlemini aynı saatle kaydedin. |
Kabul ve doğrulama kontrolleri
- QoSyi boş hatta değil kontrollü tıkanıklık altında uygulama kalitesiyle test edin.
- İzin verilen ve engellenen ağ çiftleri için erişim matrisi test edin.
- Tek bağlantı ve tek cihaz arızalarını ayrı uygulayın.
- Yoğun yükte kayıp, gecikme ve kuyruk sayaçlarını kaydedin.
- Değişiklik öncesi yapılandırma ve geri dönüş adımını saklayın.
- Yönetim erişiminin kullanıcı ağından gerektiği gibi ayrıldığını doğrulayın.
İlgili kavramlar
Katman 2 ve Katman 3 sınırları
VLAN ayrı bir yayın alanı oluşturur; VLAN’lar arası iletişimi yönlendirme ve erişim politikası belirler. Bir trunk üzerindeki VLAN listesi, access port ataması ve gateway konumu birlikte incelenmelidir. Ağ çiziminde yalnız kablo bağlantısını değil, paketlerin nerede yönlendirildiğini ve nerede filtrelendiğini gösterin. Aynı switchte bulunmak aynı yetkiye sahip olmayı gerektirmez. Bir erişimin çalışmaması halinde önce doğru VLAN ve adresi, ardından gateway, route ve politika eşleşmesini doğrulayın.
MTU ve yol boyunca paket boyutu
MTU bir bağlantının taşıyabildiği paket boyutuyla ilgilidir; tünel ve kapsülleme başlıkları yararlı yük için kalan alanı azaltabilir. Küçük istekler çalışırken büyük aktarımların durması MTU sorunu gösterebilir; fakat tek başına kanıt değildir. TCP MSS ile arayüz MTU aynı kavram değildir. Yolun iki ucunu ve tünel arayüzlerini karşılaştırın. Değişikliği bütün cihazlara rastgele uygulamak yerine kontrollü testle sorunlu segmenti belirleyin; ICMP hata mesajlarının engellenmesi keşfi zorlaştırabilir.
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun