आपने शायद तीन अलग-अलग रूपों में एक ही शिकायत सुनी होगी।
एक होटल में, मेहमान कहते हैं कि WiFi अनुपयोगी है, भले ही कागज़ पर इंटरनेट सर्किट काफी बड़ा दिखता हो। एक अस्पताल में, जब किसी मोबाइल डिवाइस को सिंक होने में बहुत अधिक समय लगता है, तो चिकित्सक नेटवर्क को दोष देते हैं। एक रिटेल सेंटर में, किरायेदार इस बात पर अड़े रहते हैं कि साझा कनेक्शन ही समस्या है, जबकि कार्ड भुगतान, इन्वेंट्री सिस्टम और गेस्ट एक्सेस सभी एक ही अपलिंक के लिए प्रतिस्पर्धा करते हैं।
यहीं पर अधिकांश बैंडविड्थ प्रबंधन सलाह अधूरी रह जाती है। यह आपको ट्रैफ़िक को थ्रॉटल, प्राथमिकता देने या आकार देने का तरीका तो बताती है, लेकिन अधिक महत्वपूर्ण प्रश्न को छोड़ देती है। क्या आपको वास्तव में नीति बदलनी चाहिए? वास्तविक नेटवर्क में, "धीमा इंटरनेट" गलत नीति, भीड़भाड़ वाली वायरलेस परत, तनावपूर्ण बैकहॉल या इन तीनों के मिश्रण से हो सकता है। यदि आप हर शिकायत को बैंडविड्थ की समस्या मानेंगे, तो आप गलत चीज़ को हल करने में पैसा और समय बर्बाद करेंगे।
'धीमे WiFi' की शिकायतों से परे
एक वेन्यू मैनेजर आमतौर पर पैकेट लॉस, चैनल उपयोग या अपलिंक संघर्ष की रिपोर्ट नहीं करता है। वे लक्षणों की रिपोर्ट करते हैं। वीडियो कॉल फ़्रीज़ हो जाती हैं। चेक-इन टैबलेट धीमे चलते हैं। गेस्ट स्ट्रीमिंग बफ़र होती है। कार्ड मशीनें अस्थिर महसूस होती हैं। वाक्यांश लगभग हमेशा एक ही होता है: "WiFi धीमा है"।
वह वाक्यांश कई अलग-अलग दोषों को छुपाता है। एक नेटवर्क में पर्याप्त इंटरनेट क्षमता हो सकती है और फिर भी खराब अनुभव मिल सकता है यदि एक्सेस पॉइंट ओवरलोड हों, यदि बहुत सारे डिवाइस एक ही रेडियो स्पेस साझा करते हैं, या यदि कम-मूल्य वाले ट्रैफ़िक को व्यावसायिक-महत्वपूर्ण ऐप्स को बाहर करने की अनुमति दी जाती है। Preseem इस बात को स्पष्ट रूप से रखता है: ट्रैफ़िक प्रबंधन केवल अनुभव की गुणवत्ता में मदद करता है यदि अंतर्निहित एक्सेस नेटवर्क स्वस्थ हो, और एक ओवरलोड एक्सेस पॉइंट स्मार्ट नियंत्रणों के बाद भी खराब प्रदर्शन करेगा, विशेष रूप से हॉस्पिटैलिटी, हेल्थकेयर और रिटेल वातावरण में जहां शिकायतें अक्सर केवल नीति के बजाय RF भीड़भाड़ या बैकहॉल सीमाओं से जुड़ी होती हैं ( बैंडविड्थ प्रबंधन के सर्वोत्तम तौर-तरीकों पर Preseem )।
क्षमता और अनुभव एक ही चीज़ नहीं हैं
मैं बहु-उपयोग वाले वेन्यू में अक्सर यह गलती देखता हूँ। कोई सर्किट को अपग्रेड करता है, शिकायतें कुछ समय के लिए कम होती हैं, फिर वे वापस आ जाती हैं। कुछ भी जादुई नहीं हुआ। अतिरिक्त हेडरूम ने कुछ समय के लिए खराब आवंटन को छुपा दिया, लेकिन अंतर्निहित समस्या बनी रही।
बैंडविड्थ प्रबंधन सबसे अच्छा तब काम करता है जब आप इसे सजा के रूप में नहीं, बल्कि संसाधन नियंत्रण के रूप में देखते हैं। आप यह तय कर रहे हैं कि कौन सा ट्रैफ़िक आसानी से निकलना चाहिए, कौन सा ट्रैफ़िक थोड़ी देर प्रतीक्षा कर सकता है, और किस ट्रैफ़िक को उचित लेकिन सीमित हिस्से की आवश्यकता है।
धीमे WiFi की शिकायतें अक्सर उपयोगकर्ता के दृष्टिकोण से सही होती हैं और फिर भी कारण के बारे में गलत होती हैं।
व्यावहारिक रूप से वह अंतर महत्वपूर्ण है:
- एक होटल अतिथि की समस्या कमरे का खराब कवरेज हो सकती है, न कि अपर्याप्त बैंडविड्थ।
- एक रिटेल संचालन की समस्या पीक फुटफॉल के दौरान साझा अपलिंक पर हावी होने वाले गेस्ट ट्रैफ़िक से आ सकती है।
- एक अस्पताल की गतिशीलता की समस्या इंटरनेट क्षमता के बजाय रोमिंग, RF ओवरलैप या एप्लिकेशन व्यवहार के कारण हो सकती है।
यदि आपका पहला कदम अधिक बैंडविड्थ खरीदना है, तो आप कारण साबित किए बिना लक्षण में मदद कर सकते हैं। यदि आपका पहला कदम सब कुछ थ्रॉटल करना है, तो आप उपयोगकर्ता अनुभव को खराब करते हुए अपलिंक की रक्षा कर सकते हैं।
भौतिक अनुभव से शुरुआत करें
QoS नीतियों को छूने से पहले, बुनियादी बातों को सत्यापित करें। कवरेज अंतराल, कमजोर सिग्नल और खराब एक्सेस पॉइंट प्लेसमेंट किसी भी इंटरनेट कनेक्शन को टूटा हुआ महसूस करा सकते हैं। वेन्यू के प्रदर्शन का निवारण करने वाली टीमों के लिए, WiFi सिग्नल की ताकत को बेहतर बनाने के तरीके पर यह गाइड एक उपयोगी अनुस्मारक है कि हर प्रदर्शन शिकायत WAN किनारे से शुरू नहीं होती है।
सही मानसिकता सरल है। पहले निदान करें। फिर तय करें कि समाधान नीति, वायरलेस डिज़ाइन या सर्किट योजना में है या नहीं।
बैंडविड्थ प्रबंधन के चार स्तंभ
बैंडविड्थ प्रबंधन कोई एक नियंत्रण नहीं है। यह नियंत्रणों का एक समूह है जो अलग-अलग काम करते हैं। जब टीमें उन्हें एक साथ मिला देती हैं, तो वे आमतौर पर ऐसे कुंद नियमों के साथ समाप्त होती हैं जो उपयोगकर्ताओं को निराश करते हैं और फिर भी महत्वपूर्ण अनुप्रयोगों की रक्षा करने में विफल रहते हैं।
यह विज़ुअल मुख्य मॉडल को संक्षेप में प्रस्तुत करता है:
Ofcom डेटा इस बात पर प्रकाश डालता है कि सूक्ष्म अंतर क्यों मायने रखता है। यूके की औसत फिक्स्ड-लाइन डाउनलोड गति 69.4 Mbit/s थी, जबकि सबसे तेज़ 10% फुल-फाइबर कनेक्शन लगभग 1.6 Gbit/s तक पहुंच गए, जिसका अर्थ है कि उपलब्ध हेडरूम एक्सेस तकनीक के अनुसार नाटकीय रूप से भिन्न होता है और जब अड़चन एक्सेस परत में होती है तो एक साधारण "अधिक बैंडविड्थ खरीदें" प्रतिक्रिया की तुलना में प्रति-एप्लिकेशन QoS और ट्रैफ़िक शेपिंग अधिक उपयोगी हो जाती है ( बैंडविड्थ प्रबंधन और यूके एक्सेस अंतरों की ManageEngine व्याख्या )।
ट्रैफ़िक शेपिंग
ट्रैफ़िक शेपिंग केवल गति को कम करने के बारे में नहीं, बल्कि प्रवाह को नियंत्रित करने के बारे में है। यह एक व्यस्त मोटरवे पर वाहनों को नियंत्रित करने के समान है ताकि पूरी सड़क चलती रहे। नेटवर्क के संदर्भ में, शेपिंग अचानक आने वाले उछाल को सुचारू बनाती है और इस संभावना को कम करती है कि एक अचानक उछाल बाकी सब कुछ बाहर कर देगा।
Quality of Service
QoS आपातकालीन लेन है। यह कुछ ट्रैफ़िक को बाकी हिस्सों की तुलना में अधिक महत्वपूर्ण के रूप में चिह्नित करता है ताकि देरी के प्रति संवेदनशील अनुप्रयोगों पर पहले ध्यान दिया जा सके।
वॉयस और रीयल-टाइम सहयोग इसके सामान्य उदाहरण हैं। उन्हें जरूरी नहीं कि बहुत अधिक थ्रूपुट की आवश्यकता हो, लेकिन उन्हें निरंतरता की आवश्यकता होती है। तुरंत संभाली गई एक वॉयस स्ट्रीम अक्सर उस बड़े ट्रांसफर से बेहतर महसूस होती है जिसे पूरी बैंडविड्थ मिलती है लेकिन कॉल में जिटर जोड़ता है।
व्यावहारिक नियम: QoS का उपयोग उन अनुप्रयोगों की सुरक्षा के लिए करें जो देरी के कारण विफल हो जाते हैं, न कि उस टीम को पुरस्कृत करने के लिए जो सबसे तेज़ चिल्लाती है।
बैंडविड्थ आवंटन
आवंटन निष्पक्षता इंजन है। यह तय करता है कि साझा संसाधन का कितना हिस्सा किसी उपयोगकर्ता समूह, सेवा वर्ग या किरायेदार समूह को जाता है।
आवंटन न होने पर कई गेस्ट नेटवर्क खराब हो जाते हैं। आवंटन के बिना, कुछ भारी उपयोगकर्ता साझा सेवा पर हावी हो सकते हैं। समझदारी से किए गए आवंटन के साथ, कर्मचारियों, मेहमानों, उपकरणों और किरायेदारों में से प्रत्येक को एक परिभाषित हिस्सा मिलता है जो व्यावसायिक मूल्य को दर्शाता है।
इसके बारे में सोचने का एक सरल तरीका:
| स्तंभ | मुख्य कार्य | सर्वोत्तम उपयोग का मामला |
|---|---|---|
| ट्रैफ़िक शेपिंग | अचानक आने वाले उछाल को सुचारू बनाना | अचानक मांग में वृद्धि के साथ व्यस्त अवधि |
| QoS | संवेदनशील ट्रैफ़िक की रक्षा करना | वॉयस, भुगतान, क्लिनिकल ऐप्स, संचालन |
| बैंडविड्थ आवंटन | साझा क्षमता को निष्पक्ष रूप से विभाजित करना | मल्टी-किरायेदार, अतिथि, कर्मचारी, मिश्रित उपयोग वाले वेन्यू |
| एप्लिकेशन प्राथमिकता | विशिष्ट सेवाओं को बढ़ावा देना | महत्वपूर्ण ऐप्स जो प्रतिक्रियाशील रहने चाहिए |
एप्लिकेशन प्राथमिकता
एप्लिकेशन प्राथमिकता व्यापक QoS वर्गों की तुलना में अधिक विशिष्ट है। यह मान्यता प्राप्त अनुप्रयोगों पर ध्यान केंद्रित करती है और वास्तव में कहती है कि ये कार्य कतार में सबसे आगे जाते हैं।
व्यवहार में, यह तब उपयोगी होता है जब कई सेवाएं एक ही नेटवर्क साझा करती हैं लेकिन समान व्यवहार की हकदार नहीं होती हैं। एक प्रॉपर्टी मैनेजमेंट सिस्टम, POS ट्रैफ़िक, या क्लिनिकल वर्कफ़्लो को बल्क मीडिया डाउनलोड या बैकग्राउंड सिंक के साथ समान शर्तों पर प्रतिस्पर्धा नहीं करनी चाहिए।
इसका उद्देश्य हर पैकेट को ओवर-इंजीनियर करना नहीं है। इसका उद्देश्य नियंत्रणों के सबसे छोटे सेट को चुनना है जो उस अनुभव की रक्षा करता है जो मायने रखता है।
अपने वेन्यू के लिए स्मार्ट नीतियां तैयार करना
एक अच्छी बैंडविड्थ नीति यह दर्शाती है कि वेन्यू कैसे संचालित होता है। यह इस बात से शुरू नहीं होती है कि "हम किस पर प्रतिबंध लगा सकते हैं?" यह इस बात से शुरू होती है कि "हर बार क्या काम करना चाहिए?"
यही कारण है कि सभी के लिए एक जैसे टेम्पलेट आमतौर पर विफल हो जाते हैं। एक होटल मेहमानों की संतुष्टि और फ्रंट-डेस्क सिस्टम की परवाह करता है। एक अस्पताल क्लिनिकल विश्वसनीयता और डिवाइस अलगाव की परवाह करता है। एक रिटेल सेंटर को उपयोगी गेस्ट एक्सेस की पेशकश करते हुए परिचालन प्रणालियों की रक्षा करनी होती है। एक आवासीय भवन को नेटवर्क को पूरी तरह से मुफ़्त बनाए बिना कई उपयोगकर्ताओं के बीच निष्पक्षता की आवश्यकता होती है।
नीति को वास्तविक दुनिया की बाधाओं का भी सम्मान करना होगा। 20 March 2020 से, यूके ब्रॉडबैंड यूनिवर्सल सर्विस ऑब्लिगेशन ने पात्र परिसरों को कानूनी रूप से 10 Mbit/s download और 1 Mbit/s upload का अनुरोध करने का अधिकार दिया है, जिसने बेसलाइन कनेक्टिविटी को तकनीकी के साथ-साथ एक नियामक और सेवा-गुणवत्ता का विचार बना दिया है, विशेष रूप से ग्रामीण या कठिन सेवा वाले स्थानों में ( बैंडविड्थ निगरानी और यूके USO बेसलाइन का SearchInform अवलोकन )।
डिवाइस के बजाय ट्रैफ़िक क्लास से शुरुआत करें
कई टीमें हार्डवेयर की सूची बनाकर शुरुआत करती हैं। यह गलत क्रम है। ट्रैफ़िक क्लास और व्यावसायिक परिणामों से शुरुआत करें।
तीन प्रश्नों का उपयोग करें:
- यदि प्रदर्शन खराब होता है, तो इससे संचालन में क्या बाधा आती है?
- किसे अच्छी तरह से काम करने की आवश्यकता है लेकिन वह कुछ देरी सहन कर सकता है?
- किसे बिना किसी वास्तविक नुकसान के उचित रूप से धीमा किया जा सकता है?
यह हर हैंडसेट, लैपटॉप, स्कैनर या टीवी के इर्द-गिर्द नीति लिखने की कोशिश करने की तुलना में अधिक स्पष्ट नियम तैयार करता है।
क्षेत्र के अनुसार बैंडविड्थ नीति टेम्पलेट
| क्षेत्र | उच्च प्राथमिकता वाला ट्रैफ़िक | मध्यम प्राथमिकता वाला ट्रैफ़िक | कम प्राथमिकता / दर-सीमित ट्रैफ़िक |
|---|---|---|---|
| होटल | PMS, POS, कर्मचारी संचार, चेक-इन सिस्टम | अतिथि ब्राउज़िंग, मैसेजिंग, नियमित व्यावसायिक ऐप्स | बड़े अतिथि डाउनलोड, सॉफ़्टवेयर अपडेट, बैकग्राउंड सिंक |
| रिटेल सेंटर | भुगतान, इन्वेंट्री टूल, किरायेदार संचालन, सुरक्षा से संबंधित सेवाएं | अतिथि ब्राउज़िंग, लॉयल्टी ऐप्स, किरायेदार व्यवस्थापक ट्रैफ़िक | स्ट्रीमिंग, बल्क डाउनलोड, गैर-आवश्यक अतिथि ट्रैफ़िक |
| अस्पताल | क्लिनिकल सिस्टम, मेडिकल वर्कफ़्लो, स्टाफ पहचान सेवाएं, परिचालन संचार | व्यवस्थापक प्लेटफ़ॉर्म, रोगी पोर्टल, मानक कार्यालय ऐप्स | अतिथि मनोरंजन ट्रैफ़िक, बल्क अपडेट, गैर-अत्यावश्यक स्थानांतरण |
| आवासीय या BTR | भवन संचालन, एक्सेस सिस्टम, प्रबंधन उपकरण | किरायेदार ब्राउज़िंग, रिमोट वर्क, सहयोग ऐप्स | पीयर-भारी बल्क ट्रैफ़िक, अप्रबंधित अपडेट, बैकग्राउंड सिंक |
व्यवहार में स्मार्ट नीति कैसी दिखती है
एक होटल को हर मेहमान और हर परिचालन प्रणाली को एक ही कतार में नहीं धकेलना चाहिए। कर्मचारियों के उपकरणों, POS टर्मिनलों और संपत्ति प्रणालियों को मनोरंजन ट्रैफ़िक की तुलना में अधिक स्पष्ट हैंडलिंग की आवश्यकता होती है। मेहमानों को अभी भी एक अच्छे अनुभव की आवश्यकता है, लेकिन "अच्छा" का मतलब असीमित प्राथमिकता नहीं है।
रिटेल में, आम जाल केवल कॉर्पोरेट कार्यालय ट्रैफ़िक की रक्षा करना और किरायेदारों, कियोस्क और अतिथि उपयोगकर्ताओं को भूल जाना है। यह अक्सर स्थानीय भीड़भाड़ के पैटर्न बनाता है जो तब तक स्पष्ट रूप से दिखाई नहीं देते जब तक आप कार्य के आधार पर विभाजित नहीं करते।
अस्पतालों को सबसे सख्त अनुशासन की आवश्यकता होती है। यदि क्लिनिकल वर्कफ़्लो अतिथि ट्रैफ़िक के समान ही व्यावहारिक प्राथमिकता साझा करते हैं, तो नीति गलत है, भले ही औसत उपयोग स्वीकार्य लगे।
सबसे अच्छी नीति आमतौर पर वह होती है जिसमें सबसे कम अपवाद होते हैं। हर अपवाद कल की समस्या निवारण की समस्या बन जाता है।
आपके पास जो वेन्यू है उसके लिए निर्माण करें
नीति की गुणवत्ता डिवाइस घनत्व और कवरेज के बारे में यथार्थवादी मान्यताओं पर निर्भर करती है। यदि आप गेस्ट एक्सेस या मिश्रित उपयोग परिनियोजन की योजना बना रहे हैं, तो Purple का एक्सेस पॉइंट कैलकुलेटर यह जांचने का एक व्यावहारिक तरीका है कि क्या आपका वायरलेस डिज़ाइन उस नीति का समर्थन कर सकता है जिसे आप लागू करना चाहते हैं।
कुछ डिज़ाइन नियम सभी क्षेत्रों में अच्छी तरह से लागू होते हैं:
- लेन-देन संबंधी ट्रैफ़िक को पहले सुरक्षित करें: भुगतान, चेक-इन, क्लिनिकल वर्कफ़्लो और स्टाफ पहचान सेवाएं विवेकाधीन उपयोग से ऊपर होनी चाहिए।
- मेहमानों को एक उचित न्यूनतम स्तर दें: मेहमानों को असीमित पहुंच की आवश्यकता नहीं है, लेकिन उन्हें निरंतरता की आवश्यकता है।
- बैकग्राउंड ट्रैफ़िक के साथ आक्रामक व्यवहार करें: अपडेट और सिंक कार्यों को कभी भी लाइव संचालन पर हावी होने की अनुमति नहीं दी जानी चाहिए।
- जहां संभव हो भूमिका के अनुसार अलग करें: कर्मचारी, अतिथि, किरायेदार और डिवाइस ट्रैफ़िक अलग-अलग व्यवहार करते हैं। आपकी नीति में यह दिखना चाहिए।
यदि आप किसी ऑपरेशन्स मैनेजर को सरल भाषा में नीति समझा सकते हैं, तो यह शायद उपयोगी है। यदि यह समझने के लिए फ़्लोचार्ट की आवश्यकता है कि किसे क्या मिलता है, तो यह शायद बहुत नाजुक है।
नीति से व्यवहार तक: कार्यान्वयन और एकीकरण
अधिकांश बैंडविड्थ नीतियां व्हाइटबोर्ड पर समझदारी भरी लगती हैं। वे कार्यान्वयन के दौरान विफल हो जाती हैं क्योंकि नेटवर्क टीम ने इरादे को लागू करने योग्य नियंत्रणों में अनुवादित नहीं किया है। यह अंतर आमतौर पर तीन जगहों पर दिखाई देता है: वर्तमान ट्रैफ़िक में खराब दृश्यता, अत्यधिक व्यापक नीति दायरा, और उपयोगकर्ताओं को सही नियमों से जोड़ने का कोई स्पष्ट तरीका न होना।
यह प्रक्रिया दृश्य रोलआउट को व्यावहारिक बनाए रखने का एक उपयोगी तरीका है:
कॉन्फ़िगर करने से पहले ऑडिट करें
नेटवर्क को उसकी सामान्य स्थिति में देखकर शुरुआत करें। "स्ट्रीमिंग समस्या है" या "मेहमान समस्या हैं" जैसी धारणाओं से शुरुआत न करें। बेसलाइन बनाएं कि अपलिंक का क्या उपभोग हो रहा है, पीक कब होते हैं, और कौन सी शिकायतें उन पीक के साथ मेल खाती हैं।
फिर ट्रैफ़िक को परिचालन समूहों में मैप करें:
- महत्वपूर्ण सेवाएं: भुगतान, क्लिनिकल वर्कफ़्लो, स्टाफ एक्सेस, वॉयस
- महत्वपूर्ण लेकिन सहनशील सेवाएं: ऑफिस ऐप्स, ब्राउज़िंग, मानक व्यावसायिक प्लेटफ़ॉर्म
- लचीली या टालने योग्य सेवाएं: अपडेट, मीडिया डाउनलोड, बैकग्राउंड सिंक
यह आपको एक नीति मॉडल देता है जिसे आप अधिकांश एंटरप्राइज़ WiFi प्लेटफ़ॉर्म और एज उपकरणों में ले जा सकते हैं।
नियम वहां लागू करें जहां वे समझदारी भरे हों
Meraki, Aruba, Ruckus, Mist और UniFi जैसे प्लेटफ़ॉर्म पर, कार्यान्वयन विवरण भिन्न होते हैं, लेकिन तर्क नहीं बदलता। वर्गों को परिभाषित करें, जो प्रतिक्रियाशील रहना चाहिए उसे प्राथमिकता दें, और जिसे सुरक्षित रूप से सीमित किया जा सकता है उसे सीमित करें।
जहाँ टीमें संघर्ष करती हैं वह दायरा है। यदि आप केवल SSID द्वारा नियम लागू करते हैं, तो आप अक्सर उस नेटवर्क पर सभी उपयोगकर्ताओं के साथ एक जैसा व्यवहार करते हैं। यह एक छोटी साइट में प्रबंधनीय है। यह एक होटल, अस्पताल या मिश्रित उपयोग वाली संपत्ति में जटिल हो जाता है जहां एक SSID बहुत अलग ट्रैफ़िक प्रोफाइल ले जा सकता है।
पहचान साझा नीति से बेहतर है
पहचान-आधारित नेटवर्किंग व्यापक SSID-स्तरीय शेपिंग की तुलना में कहीं अधिक व्यावहारिक है। यह कहने के बजाय कि "इस नेटवर्क पर सभी को समान व्यवहार मिलता है", आप भूमिका के अनुसार नीति सौंप सकते हैं। कर्मचारियों को एक नियम सेट मिल सकता है, मेहमानों को दूसरा, किरायेदारों को दूसरा, और प्रबंधित उपकरणों को दूसरा।
यहीं पर एकीकरण मायने रखता है। गेस्ट WiFi और पहचान-आधारित पहुंच के लिए Purple का कार्यान्वयन दृष्टिकोण जैसा प्लेटफ़ॉर्म इस मॉडल में फिट बैठता है क्योंकि यह केवल रेडियो अटैचमेंट पॉइंट के बजाय उपयोगकर्ता प्रकार से एक्सेस नीतियों को जोड़ने के लिए वेंडर इन्फ्रास्ट्रक्चर और डायरेक्टरी सिस्टम के साथ काम करता है। परिचालन के संदर्भ में, इसका मतलब है कम मैन्युअल नीति फैलाव और उपयोगकर्ताओं के शामिल होने, छोड़ने या भूमिका बदलने पर अधिक स्पष्ट प्रवर्तन।
यदि आपकी नीति इस बात पर निर्भर करती है कि लोग हर बार सही SSID से जुड़ें, तो यह एक मजबूत नीति नहीं है।
एक व्यावहारिक रोलआउट अनुक्रम
एक व्यावहारिक रोलआउट अनुक्रम का उपयोग करें:
- एक बेसलाइन नीति सेट बनाएं: प्राथमिकता, मध्यम और सीमित वर्गों को परिभाषित करें।
- पहले एक सीमित क्षेत्र में लागू करें: एक एकल मंजिल, वार्ड, किरायेदार क्षेत्र, या स्टोर क्लस्टर पर्याप्त है।
- वास्तविक वर्कफ़्लो के साथ परीक्षण करें: स्टाफ लॉगिन, भुगतान, वॉयस, गेस्ट ऑनबोर्डिंग, डिवाइस रोमिंग।
- अपवाद दबाव की जांच करें: यदि हर कोई तुरंत एक विशेष नियम मांगता है, तो नीति मॉडल गलत है।
- सत्यापन के बाद ही विस्तार करें: शिकायत पैटर्न में सुधार होने और संचालन स्थिर रहने पर व्यापक रूप से रोल आउट करें।
कार्यान्वयन की कुछ गलतियों से बचना चाहिए:
- ओवरलैपिंग नियम: यदि कई नीतियां एक ही ट्रैफ़िक से मेल खा सकती हैं, तो कोई अंततः भूल जाएगा कि कौन सी नीति जीतती है।
- एप्लिकेशन ब्लाइंड स्पॉट: यदि आप ट्रैफ़िक को ठीक से पहचान नहीं सकते हैं, तो आपकी नीति केवल अनुमान होगी।
- अपस्ट्रीम व्यवहार की अनदेखी करना: आंतरिक QoS टैग आपके नियंत्रण डोमेन से परे एंड-टू-एंड उपचार की गारंटी नहीं देते हैं।
व्यावहारिक उद्देश्य लालित्य नहीं है। यह दोहराव है। एक बैंडविड्थ प्रबंधन नीति केवल तभी मदद करती है जब नेटवर्क इसे उपयोगकर्ताओं, साइटों और सहायता टीमों में लगातार लागू कर सके।
जो मायने रखता है उसे मापना: निगरानी और निदान
अधिकांश बैंडविड्थ प्रबंधन परियोजनाएं एक ही तरह से विफल हो जाती हैं। टीम एक नीति परिवर्तन करती है, शिकायतें थोड़ी बदल जाती हैं, और कोई भी यह साबित नहीं कर सकता कि नेटवर्क में सुधार हुआ है या उपयोगकर्ताओं ने एक सप्ताह के लिए टिकट खोलना बंद कर दिया है।
यही कारण है कि ट्यूनिंग से अधिक निगरानी मायने रखती है। तीन अलग-अलग सवालों के जवाब देने के लिए आपको पर्याप्त दृश्यता की आवश्यकता है। कौन से अनुप्रयोग सीमित संसाधन का उपभोग कर रहे हैं? क्या भीड़भाड़ स्थानीय है या अपस्ट्रीम? क्या नीति ने उपयोगकर्ता अनुभव में सुधार किया है, या केवल उपयोग ग्राफ़ को बदला है?
Creanord एक ऐसे अंतर को उजागर करता है जिसे कई मुख्यधारा के गाइड छोड़ देते हैं। उन्नत निगरानी लाइव ट्रैफ़िक को प्रभावित किए बिना उपलब्ध बैंडविड्थ की पहचान कर सकती है और सक्रिय क्षमता योजना का समर्थन कर सकती है, जो महत्वपूर्ण प्रश्न को "मैं बैंडविड्थ को कैसे सीमित करूँ?" से कम और "नीतियों को बदलने या अधिक बैंडविड्थ खरीदने से पहले मैं भीड़भाड़ को सही ढंग से कैसे मापूँ?" अधिक बनाता है ( भीड़भाड़ मापने और सक्रिय क्षमता योजना पर Creanord )।
केवल कुल उपयोग के बजाय क्या देखना चाहिए
कुल उपयोग उपयोगी है, लेकिन यह अपने आप में एक खराब निदान है। एक व्यस्त लिंक स्वचालित रूप से एक टूटा हुआ लिंक नहीं होता है, और एक कम उपयोग किया जाने वाला लिंक अभी भी भयानक उपयोगकर्ता अनुभव उत्पन्न कर सकता।
उन संकेतकों को ट्रैक करें जो उपयोगकर्ता प्रभाव को प्रकट करते हैं:
- एप्लिकेशन लेटेंसी: लेन-देन-भारी ऐप्स और क्लाउड प्लेटफ़ॉर्म के लिए महत्वपूर्ण।
- जिटर और निरंतरता: वॉयस और रीयल-टाइम सहयोग के लिए आवश्यक।
- प्रति-उपयोगकर्ता थ्रूपुट: अतिथि और किरायेदार वातावरण में उपयोगी जहां निष्पक्षता मायने रखती है।
- लोड के तहत कतार का व्यवहार: दिखाता है कि क्या आपकी शेपिंग और प्राथमिकता वह कर रही है जो आपने इरादा किया था।
- शिकायतों के साथ समय का संबंध: संचालन में सबसे कम आंका जाने वाला मीट्रिक।
नीति, RF और बैकहॉल में अंतर कैसे करें
सबसे तेज़ी से समय बर्बाद करने का तरीका यह है कि सभी खराब प्रदर्शन को नीतिगत समस्या माना जाए। संभावित कारणों को अलग करने के लिए लक्षण पैटर्न का उपयोग करें।
| लक्षण पैटर्न | अधिक संभावित कारण | सबसे पहले क्या जांचें |
|---|---|---|
| व्यस्त अवधि के दौरान केवल कुछ अनुप्रयोग विफल होते हैं | नीति या वर्गीकरण की समस्या | ट्रैफ़िक क्लास मैपिंग, कतार नियम, ऐप पहचान |
| एक क्षेत्र के उपयोगकर्ता दूसरों की तुलना में अधिक शिकायत करते हैं | RF या एक्सेस पॉइंट संघर्ष | कवरेज, चैनल उपयोग, AP प्लेसमेंट, क्लाइंट घनत्व |
| पूरी साइट हर दिन एक ही समय पर धीमी हो जाती है | बैकहॉल या अपलिंक बाधा | WAN उपयोग पैटर्न, पीक अवधि की मांग, सर्किट हेडरूम |
| कर्मचारी सेवाएं काम करती हैं लेकिन अतिथि अनुभव समाप्त हो जाता है | आवंटन जानबूझकर या बहुत कठोर हो सकता है | गेस्ट कैप, निष्पक्षता नियम, प्रमाणीकरण प्रवाह |
| मामूली उपयोग पर भी सब कुछ अस्थिर महसूस होता है | वायरलेस स्वास्थ्य या अपस्ट्रीम अस्थिरता | AP लोड, रोमिंग व्यवहार, पैकेट लॉस, प्रदाता पथ गुणवत्ता |
एक अच्छा नैदानिक वर्कफ़्लो आमतौर पर इस तरह दिखता है:
- पुष्टि करें कि शिकायत कहाँ होती है: एक क्षेत्र, एक उपयोगकर्ता समूह, एक ऐप, या पूरी साइट।
- जांचें कि क्या अपलिंक सीमित है: मान न लें।
- प्रभावित क्षेत्र में वायरलेस स्वास्थ्य की समीक्षा करें: क्लाइंट घनत्व और RF स्थितियां अक्सर स्थानीय समस्या की व्याख्या करती हैं।
- एप्लिकेशन वर्गीकरण का निरीक्षण करें: यदि ऐप उस वर्ग में नहीं है जो आप सोचते हैं, तो नीति अप्रासंगिक है।
- एक नियंत्रित नीति परिवर्तन से पहले और बाद की तुलना करें: यदि उपयोगकर्ता अनुभव में सुधार नहीं होता है, तो दोष कहीं और है।
यह मत पूछिए कि क्या लिंक भरा हुआ है। यह पूछिए कि मांग के अस्त-व्यस्त होने पर क्या सही ट्रैफ़िक आसानी से निकल पाता है।
रिपोर्टिंग जिसका उपयोग संचालन टीमें कर सकती हैं
नेटवर्क टीमों को तकनीकी विवरण की आवश्यकता होती है। वेन्यू लीडर्स को निर्णयों की आवश्यकता होती है। आपकी रिपोर्टिंग को दोनों का समर्थन करना चाहिए।
इसका अर्थ है निगरानी को स्पष्ट परिणामों में अनुवादित करना जैसे कि कौन सी सेवाएं पीक समय पर प्रतिक्रियाशील रहीं, किन क्षेत्रों में बार-बार शिकायतें उत्पन्न हुईं, और क्या परिचालन वर्कफ़्लो को नुकसान पहुंचाए बिना गेस्ट ट्रैफ़िक को नियंत्रित किया गया था। नेटवर्क दृश्यता को वेन्यू संदर्भ के साथ जोड़ने वाले उपकरण यहाँ मदद कर सकते हैं। Purple का गेस्ट WiFi एनालिटिक्स इस बात का एक उदाहरण है कि कैसे उपयोगकर्ता और सत्र डेटा नेटवर्क टेलीमेट्री के साथ-साथ उस व्यापक परिचालन दृष्टिकोण का समर्थन कर सकते हैं।
निगरानी का एक प्रमुख मूल्य विश्वास है। जब आप यह साबित कर सकते हैं कि मंदी एक विंग में RF संघर्ष से आई है, तो आप उन QoS नीतियों को फिर से लिखना बंद कर देते हैं जो कभी समस्या थीं ही नहीं।
सामान्य बैंडविड्थ प्रबंधन कमियों का निवारण
प्रवर्तन तर्क के गड़बड़ाने पर अच्छी तरह से डिज़ाइन किया गया बैंडविड्थ प्रबंधन भी टूट जाता है। लक्षण परिचित लग सकते हैं। कटी-फटी वीडियो कॉल, अप्रत्याशित गेस्ट एक्सेस, धीमे क्लाउड ऐप्स, व्यस्त समय में किरायेदारों की शिकायतें। कारण अक्सर उम्मीद से कम आकर्षक होता है।
गलतियाँ जो बार-बार होती हैं
कुछ गलतियाँ बार-बार सामने आती हैं:
- बिना किसी व्यावहारिक प्रभाव के QoS अंकन: आप अपने नेटवर्क के भीतर ट्रैफ़िक को खूबसूरती से चिह्नित कर सकते हैं और फिर भी कोई लाभ नहीं पा सकते हैं यदि उन चिह्नों का सम्मान आपके द्वारा नियंत्रित खंड से परे नहीं किया जाता है।
- नीति टकराव: दो नियम एक ही एप्लिकेशन या उपयोगकर्ता समूह से मेल खाते हैं, और परिणाम इरादे के बजाय प्रसंस्करण क्रम पर निर्भर करता है।
- ओवर-शेपिंग: टीम नियंत्रणों के साथ आक्रामक हो जाती है और केवल गैर-आवश्यक ट्रैफ़िक ही नहीं, बल्कि सामान्य काम को भी बाधित कर देती है।
- खराब वर्गीकरण: एप्लिकेशन की गलत पहचान की जाती है, इस तरह से एन्क्रिप्ट किया जाता है जिसे आपका टूलिंग समझ नहीं सकता, या गलत वर्ग में समूहीकृत किया जाता है।
ये मुद्दे ही कारण हैं कि सरल नीतियां अक्सर जटिल नीतियों से बेहतर प्रदर्शन करती हैं। जटिलता आपको घुमाने के लिए अधिक नॉब देती है। यह आपको गलत होने के अधिक तरीके भी देती है।
एक त्वरित दोष-अलगाव चेकलिस्ट
जब कोई "धीमी वीडियो कॉल" या "टूटे हुए WiFi" की रिपोर्ट करता है, तो इस क्रम में लक्षण का परीक्षण करें:
- पहले स्थान: क्या यह एक कमरे, मंजिल, वार्ड या रिटेल इकाई तक सीमित है?
- अगला उपयोगकर्ता समूह: क्या यह मेहमान, कर्मचारी, किरायेदार या हर कोई है?
- एप्लिकेशन दायरा: क्या यह एक ऐप है या सभी इंटरैक्टिव ट्रैफ़िक?
- समय पैटर्न: क्या यह केवल अनुमानित पीक के दौरान होता है?
- नीति जांच: क्या प्रभावित ट्रैफ़िक क्लास हाल ही में बदली है?
- वायरलेस सत्यता जांच: क्या सिग्नल की गुणवत्ता या क्लाइंट घनत्व वास्तविक समस्या है?
- बैकहॉल समीक्षा: क्या शिकायत विंडो के दौरान अपलिंक सीमित है?
यदि एक उपयोगकर्ता हर जगह शिकायत करता है, तो डिवाइस का निरीक्षण करें। यदि कई उपयोगकर्ता एक ही स्थान पर शिकायत करते हैं, तो RF वातावरण का निरीक्षण करें। यदि हर कोई एक ही समय पर शिकायत करता है, तो अपलिंक का निरीक्षण करें।
एक व्यावहारिक समस्या निवारण आदत मदद करती है। एक समय में एक चीज़ बदलें, परिणाम रिकॉर्ड करें, और "फिक्स बंडल" से बचें जहाँ आप एक ही रखरखाव विंडो में शेपिंग, AP सेटिंग्स और इंटरनेट रूटिंग को बदलते हैं। यदि प्रदर्शन में सुधार होता है, तो आपको पता नहीं चलेगा कि क्यों। यदि यह बदतर हो जाता है, तो आपको पता नहीं चलेगा कि कहाँ वापस जाना है।
बैंडविड्थ प्रबंधन के बारे में अक्सर पूछे जाने वाले प्रश्न
क्या बैंडविड्थ प्रबंधन लेटेंसी बढ़ाता है?
यदि इसे खराब तरीके से किया जाए तो यह हो सकता है। यदि आप बड़े आकार की कतारें बनाते हैं या बहुत अधिक ट्रैफ़िक को सीमित वर्ग में धकेलते हैं तो कोई भी कतारबद्ध तंत्र देरी जोड़ सकता है। ठीक से किए जाने पर, बैंडविड्थ प्रबंधन अक्सर कथित प्रदर्शन में सुधार करता है क्योंकि यह देरी के प्रति संवेदनशील ट्रैफ़िक को उछाल और संघर्ष से बचाता है।
मुख्य बात चुनिंदा रूप से प्राथमिकता देना है। आधे नेटवर्क को "उच्च प्राथमिकता" बकेट में न डालें और स्पष्ट परिणामों की अपेक्षा न करें।
क्या ब्रॉडबैंड की गति बढ़ने पर भी बैंडविड्थ प्रबंधन आवश्यक है?
हाँ। यूके की औसत फिक्स्ड ब्रॉडबैंड डाउनलोड गति November 2019 में 54.2 Mbit/s से बढ़कर November 2020 में 69.4 Mbit/s हो गई, और इसी अवधि में औसत अपलोड गति 8.2 Mbit/s से बढ़कर 17.2 Mbit/s हो गई। वह वृद्धि महत्वपूर्ण है क्योंकि वीडियो मीटिंग, क्लाउड बैकअप और सहयोगी टूल जैसे अपस्ट्रीम-भारी उपयोग प्राथमिकता और निगरानी को अधिक महत्वपूर्ण बनाते हैं, कम नहीं ( Ofcom ब्रॉडबैंड गति परिवर्तनों और बैंडविड्थ योजना संदर्भ का Bandicoot Marketing सारांश )।
अधिक क्षमता मदद करती है। यह महत्वपूर्ण और गैर-महत्वपूर्ण ट्रैफ़िक के बीच संघर्ष को समाप्त नहीं करती है।
पहचान-आधारित नीति और MAC-आधारित नियमों में क्या अंतर है?
MAC-आधारित नियम उपकरणों की पहचान करते हैं। पहचान-आधारित नियम उपयोगकर्ताओं, समूहों या भूमिकाओं की पहचान करते हैं। यह एक बड़ा परिचालन अंतर है।
बदलते उपकरणों, व्यक्तिगत उपकरणों, गेस्ट ऑनबोर्डिंग और साझा स्थानों वाले वातावरण में MAC नियम नाजुक होते हैं। पहचान-आधारित नीति को व्यावसायिक तर्क जैसे कि कर्मचारी, अतिथि, ठेकेदार, किरायेदार या प्रबंधित डिवाइस के साथ संरेखित करना आसान होता है।
बैंडविड्थ प्रबंधन SD-WAN से कैसे संबंधित है?
वे अलग-अलग समस्याओं का समाधान करते हैं। SD-WAN यह तय करता है कि ट्रैफ़िक साइटों या सर्किटों में उपलब्ध पथों और नीतियों का उपयोग कैसे करता है। बैंडविड्थ प्रबंधन यह तय करता है कि ट्रैफ़िक किसी दिए गए पथ या खंड पर सीमित संसाधनों को कैसे साझा करता है।
व्यवहार में, वे एक-दूसरे के पूरक हैं। SD-WAN ट्रैफ़िक को बुद्धिमानी से निर्देशित कर सकता है, जबकि बैंडविड्थ प्रबंधन महत्वपूर्ण अनुप्रयोगों की रक्षा करता है जब ट्रैफ़िक सर्किट या स्थानीय एक्सेस नेटवर्क पर पहुंचता है।
जब ट्रैफ़िक एन्क्रिप्टेड हो और वर्गीकृत करना कठिन हो तो मुझे क्या करना चाहिए?
गहन पहचान पर कम और भूमिका, गंतव्य पैटर्न, नेटवर्क खंड और आपके द्वारा नियंत्रित प्लेटफ़ॉर्म से एप्लिकेशन संदर्भ के संयोजन पर अधिक भरोसा करें। आपको एन्क्रिप्टेड ट्रैफ़िक में हमेशा सही दृश्यता नहीं मिलेगी, इसलिए वर्गीकरण अधूरा होने पर भी नीति डिज़ाइन को व्यावहारिक रहना होगा।
इसका आमतौर पर मतलब अत्यधिक महत्वाकांक्षी सूक्ष्म-नीतियों के बजाय स्पष्ट भूमिका-आधारित नियमों का पक्ष लेना है।
क्या मेहमानों को हमेशा दर-सीमित किया जाना चाहिए?
हमेशा नहीं। मेहमानों को एक अनुमानित अनुभव की आवश्यकता होती है, विशेष रूप से हॉस्पिटैलिटी और प्रीमियम रिटेल वातावरण में। लक्ष्य निष्पक्षता और मुख्य सेवाओं की सुरक्षा है, न कि मनमाना अभाव।
एक बेहतर दृष्टिकोण गेस्ट ट्रैफ़िक को एक उपयुक्त वर्ग और स्पष्ट सीमा देना है, जबकि सेवा का एक स्थिर न्यूनतम स्तर बनाए रखना है।
बैंडविड्थ नीतियों की समीक्षा कितनी बार की जानी चाहिए?
जब भी वेन्यू में भौतिक रूप से बदलाव हो, उनकी समीक्षा करें। एक रिफिट, नया ऐप रोलआउट, क्लिनिकल वर्कफ़्लो बदलाव, किरायेदार मिश्रण परिवर्तन, या अतिथि उपयोग पैटर्न परिवर्तन सभी एक पुरानी नीति को अप्रचलित बना सकते हैं। बड़े बदलाव के बिना भी, एक आवधिक समीक्षा समझदारी भरी है क्योंकि ट्रैफ़िक पैटर्न शायद ही कभी स्थिर रहते हैं।
एक मिश्रित उपयोग वाले वेन्यू के लिए सबसे सरल उपयोगी नीति क्या है?
तीन वर्गों से शुरुआत करें। महत्वपूर्ण व्यावसायिक ट्रैफ़िक। सामान्य व्यावसायिक और गेस्ट ट्रैफ़िक। बैकग्राउंड या बल्क ट्रैफ़िक। यदि आप उस स्तर पर विश्वसनीय रूप से वर्गीकृत कर सकते हैं और परिणाम की निगरानी कर सकते हैं, तो आपको अक्सर एक विस्तृत वर्गीकरण की तुलना में बेहतर परिणाम मिलेंगे जिसे कोई भी बनाए नहीं रख सकता है।
Purple IT टीमों को मौजूदा बुनियादी ढांचे पर अतिथि, कर्मचारी और बहु-किरायेदार WiFi वातावरण में पहचान-आधारित पहुंच और नीति नियंत्रण लागू करने का एक व्यावहारिक तरीका देता है। यदि आप साझा पासवर्ड और कुंद SSID-व्यापी नियमों से आगे बढ़ने की कोशिश कर रहे हैं, तो आपके वर्तमान नेटवर्क स्टैक के साथ Purple का मूल्यांकन करना उचित है।
