मैं अपनी इंटरनेट लाइन में कुछ प्रकार के ट्रैफ़िक प्रबंधन को जोड़ना चाहूंगा। बहुत सारे दस्तावेज़ीकरण पढ़ने के बाद, मुझे लगता है कि HFSC मेरे लिए बहुत जटिल है (मैं सभी घटता सामान नहीं समझता, मुझे डर है कि मैं इसे कभी भी सही नहीं पाऊंगा), CBQ की सिफारिश नहीं है, और मूल रूप से HTB का तरीका है ज्यादातर लोगों के लिए जाओ।
हमारे आंतरिक नेटवर्क में तीन "सेगमेंट" हैं और मैं बैंडविड्थ को कम से कम समान रूप से उन लोगों के बीच साझा करना चाहता हूं (कम से कम शुरुआत में)। इसके अलावा मुझे कम से कम तीन प्रकार के ट्रैफ़िक (रियलटाइम ट्रैफ़िक, मानक ट्रैफ़िक और बल्क ट्रैफ़िक) के अनुसार ट्रैफ़िक को प्राथमिकता देनी होगी। बैंडविड्थ शेयरिंग इस तथ्य के रूप में महत्वपूर्ण नहीं है कि रियलटाइम ट्रैफ़िक को हमेशा जब भी संभव हो प्रीमियम प्रीमियम के रूप में माना जाना चाहिए, लेकिन निश्चित रूप से कोई भी अन्य ट्रैफ़िक वर्ग या तो भूखा नहीं रह सकता है।
सवाल यह है कि क्या अधिक समझ में आता है और बेहतर रीयलटाइम थ्रूपुट की गारंटी भी देता है:
प्रति खंड एक वर्ग बनाना, प्रत्येक की समान दर (प्राथमिकता उन वर्गों के लिए महत्वपूर्ण नहीं है जो HTB डेवलपर के अनुसार कोई पत्तियां नहीं हैं) और इनमें से प्रत्येक वर्ग में 3 प्राथमिकता स्तर (अलग-अलग प्राथमिकताओं के साथ) के लिए तीन उप-वर्ग (पत्तियां) हैं। और अलग-अलग दर)।
शीर्ष पर प्रति प्राथमिकता स्तर पर एक वर्ग होने, प्रत्येक की अलग-अलग दर (फिर से प्राथमिकता मायने नहीं रखेगी) और प्रत्येक में 3 उप-वर्ग, एक सेगमेंट होते हैं, जबकि रियलटाइम क्लास में सभी 3 में सबसे अधिक मूल्य, सबसे कम प्राइको थोक में होता है कक्षा, इत्यादि।
मैं निम्नलिखित ASCII कला छवि के साथ इसे और अधिक स्पष्ट करने की कोशिश करूंगा:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
केस 1 जिस तरह से ज्यादातर लोग ऐसा करते हैं, ऐसा लगता है, लेकिन जब तक मैं HTB कार्यान्वयन विवरण को सही ढंग से नहीं पढ़ता, केस 2 बेहतर प्राथमिकता दे सकता है।
HTB मैनुअल में कहा गया है, कि यदि किसी वर्ग ने अपनी दर को मारा है, तो वह अपने माता-पिता से उधार ले सकता है और उधार लेते समय, उच्च प्राथमिकता वाली कक्षाएं हमेशा बैंडविड्थ की पेशकश करती हैं। हालाँकि, यह भी कहता है कि निम्न वृक्ष-स्तर पर उपलब्ध होने वाली बैंडविड्थ को प्राथमिकता के आधार पर उच्च वृक्ष स्तर पर हमेशा पसंद किया जाता है ।
चलो निम्नलिखित स्थिति मान लेते हैं: सेगमेंट सी कोई ट्रैफ़िक नहीं भेज रहा है। सेगमेंट ए केवल रियलटाइम ट्रैफ़िक भेज रहा है, जितनी तेज़ी से यह कर सकता है (केवल लिंक को संतृप्त करने के लिए पर्याप्त है) और सेगमेंट बी केवल बल्क ट्रैफ़िक भेज रहा है, जितनी जल्दी हो सके (फिर से, पूरी लिंक को अकेले संतृप्त करने के लिए पर्याप्त है)। क्या होगा?
मामला एक:
सेगमेंट A-> हाई प्रियो और सेगमेंट B-> लो प्रियो दोनों में पैकेट भेजने की जरूरत है, क्योंकि A-> हाई प्रियो की प्राथमिकता ज्यादा होती है, यह हमेशा पहले शेड्यूल की जाएगी, जब तक कि यह इसकी दर को हिट न कर दे। अब यह सेगमेंट ए से उधार लेने की कोशिश करता है, लेकिन चूंकि सेगमेंट ए उच्च स्तर पर है और सेगमेंट बी-> लो प्रियो ने अभी तक इसकी दर को हिट नहीं किया है, इसलिए यह वर्ग अब पहले सेवा में है, जब तक कि यह दर हिट नहीं करता है और इससे उधार लेना चाहता है। सेगमेंट बी। एक बार जब दोनों ने अपनी दरों को मारा है, तो दोनों फिर से एक ही स्तर पर हैं और अब सेगमेंट ए-> उच्च प्रियो फिर से जीतने जा रहा है, जब तक कि यह सेगमेंट ए की दर को हिट नहीं करता है। अब यह रूट से उधार लेने की कोशिश करता है (जो है) बहुत से ट्रैफ़िक स्पेयर, जैसा कि सेगमेंट सी अपने किसी भी गारंटीकृत ट्रैफ़िक का उपयोग नहीं कर रहा है), लेकिन फिर से, इसे सेगमेंट बी-> लो प्रियो के लिए भी मूल स्तर तक पहुंचने के लिए इंतजार करना होगा। एक बार ऐसा हो जाए,
केस 2:
उच्च Prio-> सेगमेंट A और निम्न Prio-> सेगमेंट B दोनों को पैकेट भेजना है, फिर से उच्च Prio-> सेगमेंट A जीतने जा रहा है क्योंकि इसमें उच्च प्राथमिकता है। एक बार जब यह अपनी दर से टकराता है, तो यह उच्च प्रियो से उधार लेने की कोशिश करता है, जिसमें बैंडविड्थ स्पेयर होता है, लेकिन उच्च स्तर पर होने के कारण, इसे कम प्रियो-> सेगमेंट बी के लिए फिर से अपनी दर को हिट करने के लिए इंतजार करना पड़ता है। एक बार जब दोनों अपनी दर से टकरा जाते हैं और दोनों को उधार लेना पड़ता है, तो उच्च Prio-> सेगमेंट A तब तक फिर से जीतेगा जब तक कि यह उच्च Prio वर्ग की दर से न टकराए। एक बार ऐसा होने पर, यह रूट से उधार लेने की कोशिश करता है, जिसमें फिर से बहुत सारे बैंडविड्थ बचे हैं (सामान्य प्रियो की सभी बैंडविड्थ इस समय अप्रयुक्त है), लेकिन इसे कम प्रियो-> सेगमेंट बी तक फिर से इंतजार करना होगा निम्न Prio वर्ग और जड़ से उधार लेने की भी कोशिश करता है। अंत में दोनों वर्ग जड़ से उधार लेने की कोशिश करते हैं, प्राथमिकता को ध्यान में रखा जाता है, और उच्च Prio->
दोनों ही मामले उप-इष्टतम लगते हैं, जिस तरह से रियलटाइम ट्रैफ़िक के लिए कभी-कभी बल्क ट्रैफ़िक की प्रतीक्षा करनी पड़ती है, भले ही बहुत सारे बैंडविड्थ बचे हों, यह उधार ले सकता है। हालाँकि, अगर मामला 2 ऐसा लगता है कि रियलटाइम ट्रैफ़िक के मामले में 1 से कम इंतज़ार करना पड़ता है, क्योंकि इसे केवल तब तक इंतज़ार करना पड़ता है जब तक कि थोक ट्रैफ़िक दर हिट न हो जाए, जो कि एक पूरे सेगमेंट की दर से कम होने की संभावना है (और मामले में) 1 यही वह दर है जिसके लिए इंतजार करना पड़ता है)। या मैं यहाँ पूरी तरह से गलत हूँ?
मैंने प्राथमिकता वाले qdisc के उपयोग से और भी सरल सेटअपों के बारे में सोचा। लेकिन प्राथमिकता वाले कतारों में बड़ी समस्या यह है कि वे भुखमरी का कारण बनते हैं यदि वे किसी तरह सीमित न हों। भुखमरी स्वीकार्य नहीं है। बेशक एक टीबीएफ (टोकन बकेट फ़िल्टर) को प्रत्येक प्राथमिकता वर्ग में दर को सीमित करने के लिए रखा जा सकता है और इस तरह भुखमरी से बचा जा सकता है, लेकिन ऐसा करते समय, एक एकल प्राथमिकता वर्ग अपने स्वयं के लिंक को किसी भी लंबे समय तक संतृप्त नहीं कर सकता है, भले ही अन्य सभी प्राथमिकता वर्ग हों खाली हैं, टीबीएफ ऐसा होने से रोकेगा। और यह भी उप-इष्टतम है, क्योंकि किसी वर्ग को इस समय 100% लाइन की बैंडविड्थ नहीं मिलती है यदि किसी अन्य वर्ग को फिलहाल इसकी कोई आवश्यकता नहीं है?
इस सेटअप के बारे में कोई टिप्पणी या विचार? मानक tc qdiscs का उपयोग करना इतना कठिन लगता है। एक प्रोग्रामर के रूप में यह इतना आसान काम था अगर मैं बस अपना खुद का शेड्यूलर लिख सकता था (जो मुझे करने की अनुमति नहीं है)।