Linux TC sınıfı / filtre numaralandırma

Şu anda ISP düzeyindeki şirketler için trafik şekillendirme çözümü üzerinde çalışıyorum ve ilginç (felsefi) bir soruna geldim.

Sistemin işlemesi gereken uç noktaların sayısına baktığımda (ki yaklaşık 20k civarında) Daha fazla kullanıcının trafiğini politikaya dönüştürmek / şekillendirmek istediğimde ne olacağı konusunda biraz endişeliyim. Şu anda tüm ağ için HFSC şekillendirme ağacı (bkz. Tc-hfsc, çoğunlukla daha iyi bilinen HTB ile aynı ama daha serin bir şey) kullanıyorum, daha fazla ClassID (tabii ki her kullanıcı için en azından bir tane) kullanmam gerekir ağ). Bulduğum sorun, TC ClassID'lerin tür sınırlı olmasıydı - 16 bit sayıları, bu da bana bu çözümle şekillendirilmiş maksimum 64k kullanıcı veriyor.

Benzer şekilde, TC filtrelerini verimli bir şekilde yönetmek istersem (örneğin, 'tüm tekniği temizle' kullanmamak), ayrı filtre girişlerini silebilir veya değiştirebilirim. (LARTC [1] karma tablosuna benzer bir şey kullanıyorum). Yine, bununla çalışıyor gibi görünen tek yöntem, tüm filtreleri bireysel öncelikleri kullanarak numaralandırmaktır (tc filter add dev ... prio 1). Bu amaçla kullanılabilecek başka bir parametre yoktur ve regio olarak, prio sadece 16 bitliktir.

Sorum şu: "tc sınıfı" komutu için 32-bit clsid ve "tc filtresi" için 32-bit öncelikler (veya diğer değişiklik tutamaçları) gibi "tanımlayıcı alanı" genişletmek için iyi bir yöntem var mı? komut?

Çok teşekkürler,

-mk

(btw Umarım bu "64 bin kullanıcı herkes için yeterli olmalı" senaryosuna gitmez ...)

— eksa
kaynak

Tüm bu değerler çekirdek alanında depolanır, daha büyük hale getirmek için çekirdek ve kullanıcı alanı yardımcı programlarınızı yeniden derlemeniz gerekir. 64bit çekirdek kullanmayı denediniz mi? Orada 32bit olarak tanımlanabilirler.

— Hubert Kario

64 bit çekirdek aynı boyutları kullanır. Örneğin, filtre numarası her ikisi de 16bit olan üst (protokol) ve alt kısımdan (prio) oluşan u32-tamsayıdır. Sınıf kimlikleri u16 olarak sabit kodlanmıştır. Muhtemelen LKML'de birine sormayı deneyeceğim.

— exa

filtreleriniz için karma kullanarak bile, bu kadar filtre kullanıyorsanız (yukarı ve aşağı akış için sanırım) çok fazla IO probleminiz olacaktır. Ben çok zaman geçirdim ve işler khouftirqd ile çalışmak için çekirdek içindeki kuyruk uygulaması yama zorunda kaldı. 4 yıl önce LARTC'da tanıştığım Simon Lodal adlı bir adamın yamasını kullandım. Yamasına bir göz atın mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Ona bir e-posta göndermeyi deneyebilirsiniz çünkü onunla her zaman çok güncel bir sürümü (son çekirdeğe karşı) vardır.

— Pabluez

@Pabluez Çok teşekkürler, bundan en iyi şekilde yararlanmaya çalışacağım.

— exa

Sanırım ihtiyacın geçerli ama Pabluez'in yazdığı gibi, bu kesinlikle çok fazla çekirdek değişikliği içeriyor. "Bunu yanlış yapıyorsun" demek istemiyorum, ancak paket işlemenin alt kısımlarının anahtar düzeyinde yapıldığı ve polisliğin özel yazılımda yapıldığı açık akışı kontrol etmenizi öneririm. kullanıcı alanında çalışıyor. İhtiyacınıza uygun olup olmadığını bilmiyorum, ama kesinlikle araştırmaya değer.

— AndreasM

Yanıtlar:

Ben aynı arayüzde her biri için yukarı ve aşağı sınıfları ve filtreleri ile 64k kullanıcıları koymak gerektiğini düşünüyorum. Sahip olduğunuz her arabirim için işleyicileri tekrarlayabilirsiniz, böylece daha fazla arabirim ekleyin. Bu şeylere sahip olmak için inanılmaz bir çalışma / sunucu / NIC'ye ihtiyacınız olacak. Sunucu çökerse, çevrimdışı 64k kullanıcınız olur (ve bu miktarda trafikle kolayca kilitlenir). Ağ kartınızdan geçen her paketin bir filtre tarafından kontrol edileceğini ve sınıflandırılacağını ve kuyruğa alınacak bir sınıfa gönderileceğini unutmayın. Bu, 64 bin müşterisi olan bir ISS ağ geçidinin bir NIC'si için çok iştir. Temelde günümüzde sahip olduğumuz tüm video akışı ile (düzgün sıraya koymak zor).

— Pabluez
kaynak

Başka bir düzeyde hizmet kullanılabilirliğini sağlıyorum, ancak endişeniz için teşekkürler. Aslında, iyi NIC'lerle 10Gbit iletebilen bir linux yönlendiriciye sahip olmak o kadar da zor değil.

— exa

Orijinal soru için, her kullanıcı için 5 farklı sınıf eklemek gibi şeylerle daha fazla ilgileniyordum, bu da gerçekten iyi bir QOS işi yapmamı sağlayacaktı (akışları ve gerçek zamanlı trafiği ayrı ayrı ele almak gibi), ancak mevcut koşullarda (benim ile ~ 20k uç noktaların mevcut kullanım durumu zaten sınırın arkasında olurdu).

— exa

tamam, 10Gbits iletmek herhangi bir sorun değil, sorun birçok 64k * 2 (iniş çıkışlar) filtreleri ve sınıfları yaşıyor. İyi şanslar olsa: D

— Pabluez

Trafik işlemeyi bir makinedeki tüm trafiği işlemek yerine iki makineye (üçüncü bir tane kullanarak) bölebilirsiniz. Trafik, kaynak IP adresine göre yönlendirilebilir. Bu nedenle, IP aralıklarını eşit olarak bölebiliyorsanız en iyi 10k kullanıcınız olacaktır.

Tabii ki, gerekirse ikiden fazla makine kullanabilirsiniz. Bence bu, Linux çekirdeğini yamalamaktan ve başka hack'ler yapmaktan daha iyi olabilir. Kısacası, trafik şekillendirme birkaç makineye dağıtılacaktır. Merkezi düğüm trafiği doğru işleme düğümüne iletecektir.

— Halid
kaynak