VPN पर SMB मल्टीचैनल: क्लाइंट वास्तव में क्या उपयोग करता है
VPN पर SMB मल्टीचैनल बहुत कम चैनल जोड़ता है: धीमी फ़ाइलों के लिए टनल को दोष देने से पहले क्लाइंट के इंटरफ़ेस, चुने गए कनेक्शन और SMB डायलेक्ट पढ़ें।
VPN पर धीमी फ़ाइल पहुँच मल्टीचैनल सेटिंग को समाधान के रूप में लेने पर मजबूर करती है, और अक्सर सेटिंग के पास काम करने के लिए कुछ नहीं होता। RSS के बिना एक ही वर्चुअल एडाप्टर ट्रैफ़िक को कई चैनलों पर नहीं फैला सकता, चेकबॉक्स चाहे कुछ भी कहे। महत्वपूर्ण यह है कि SMB दोनों सिरों पर कौन-सी क्षमता देखता है, लैपटॉप के भौतिक NIC का विनिर्देश नहीं। नीचे दी गई जानकारी सक्रिय सत्र से शुरू होकर एडाप्टर लेआउट तक वापस जाती है।
NIC विनिर्देश से नहीं, सत्र से शुरू करें
पहले पुष्टि करें कि सत्र मल्टीचैनल का उपयोग कर ही सकता है। यह सुविधा SMB3 की है, इसलिए किसी उपकरण या पुराने सर्वर के साथ तय किया गया पुराना डायलेक्ट एडाप्टर का कोई भी प्रश्न महत्वपूर्ण होने से पहले ही इसे बाहर कर देता है। फिर पुष्टि करें कि क्लाइंट वास्तव में किस सर्वर से जुड़ा है, क्योंकि आप जिस नोड की जाँच कर रहे हैं उससे भिन्न नोड पर रिज़ॉल्व होने वाला नाम विश्वसनीय पर असंगत परिणाम देता है।
Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterfaceपहला कमांड डायलेक्ट, सर्वर और शेयर का नाम एक पंक्ति में बताता है। दूसरा दिखाता है कि क्लाइंट पर सुविधा सक्षम है या नहीं, और तीसरा उन इंटरफ़ेस की सूची देता है जिन्हें SMB जानता है, उनकी बताई गई क्षमताओं के साथ। जो वर्चुअल एडाप्टर न RSS बताता है न RDMA, वह आपको बताता है कि लेआउट क्या बन सकता है।
यदि डायलेक्ट SMB3 नहीं है, तो रुकें और पहले वह प्रश्न ठीक करें। अन्यथा हर बाद वाला कमांड ऐसी सुविधा का वर्णन करेगा जो सक्रिय ही नहीं हो सकती।
क्लाइंट के इंटरफ़ेस ईमानदारी से पढ़ें
SMB को इससे मतलब नहीं कि आपका डिफ़ॉल्ट रूट कौन-सा एडाप्टर ले जाता है; वह उन इंटरफ़ेस की गणना करता है जिनका उपयोग कर सकता है और हर एक का मूल्यांकन करता है। Wi-Fi, Ethernet और VPN एडाप्टर वाला लैपटॉप तीन इंटरफ़ेस प्रस्तुत कर सकता है, और उनमें से केवल एक ही उस सर्वर के लिए पहुँच योग्य हो सकता है जिससे आप बात कर रहे हैं। बाकी उम्मीदवार हैं, चैनल नहीं।
लिंक गति वाले कॉलम की जगह RSS और RDMA कॉलम पढ़ें। वर्चुअल एडाप्टर आमतौर पर RSS क्षमता के बिना ऊँची नाममात्र गति बताता है, और नाममात्र गति इंटरनेट के रास्ते की नहीं, वर्चुअल लिंक की व्याख्या करती है। दोनों में से कोई भी संख्या आपको नहीं बताती कि सत्र कितने चैनल उपयोग करता है।
यदि एडाप्टर RSS क्षमता नहीं दिखाता, तो समर्थित सुधार VPN विक्रेता के ड्राइवर में है, भौतिक NIC की उन्नत प्रॉपर्टी में नहीं। हार्डवेयर एडाप्टर पर RSS चेकबॉक्स पर टिक लगाने से वर्चुअल एडाप्टर SMB को जो दिखाता है उसमें कुछ नहीं बदलता।
चुने गए चैनलों को खोजे गए उम्मीदवारों से अलग करें
कनेक्शन सूची वह हिस्सा है जिसे सबसे अधिक गलत पढ़ा जाता है। न चुने गए उम्मीदवारों सहित, आउटपुट वह सब दिखाता है जिस पर SMB ने विचार किया, और यह डेटा ले जाने वाले चैनलों का समूह नहीं है। आपके लिए रुचिकर विशिष्ट क्लाइंट और सर्वर इंटरफ़ेस जोड़ी के लिए चयन ध्वज और चैनल संख्या पढ़ें।
Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *अपने सर्वर के नाम से बदलें। दूसरा रूप चुने गए कनेक्शनों के गुण प्रिंट करता है, जिसमें इंटरफ़ेस सूचकांक और वर्तमान चैनल संख्या शामिल है, और वही महत्वपूर्ण संख्या है। एक एडाप्टर पर खोजे गए कई पते अभी भी एक ही एडाप्टर हैं।
खोजा गया पता VPN नीति के कारण भी अनुपयोगी हो सकता है: यह स्थानीय सबनेट का पता हो सकता है जिसे टनल नहीं ले जाता, या ऐसा पता जिसे सर्वर केवल किसी दूसरे नेटवर्क पर देता है। SMB इसे उम्मीदवार के रूप में सूचीबद्ध करता है क्योंकि इंटरफ़ेस मौजूद है, इसलिए नहीं कि रास्ता काम करता है।
VPN एडाप्टर लेआउट के साथ क्या करता है
तीन लेआउट को अलग पहचानना उचित है, क्योंकि उनमें से केवल दो ही एक से अधिक चैनल बना सकते हैं। RSS के बिना एक एडाप्टर एक चैनल देता है। RSS क्षमता वाला एक एडाप्टर कनेक्शनों को कोरों पर फैला सकता है। कई उपयोगी एडाप्टर RSS के बिना भी कई चैनल बना सकते हैं, और RSS को अनिवार्य मानने वाले लोग यही कॉन्फ़िगरेशन भूल जाते हैं।
| Layout SMB sees | Channels possible |
|---|---|
| One adapter, no RSS | One |
| One adapter with RSS | Several, spread across cores |
| Two or more usable adapters | Several, one path per adapter |
| Several adapters behind one tunnel | Several, one shared bottleneck |
आखिरी पंक्ति वही है जो VPN पर महत्वपूर्ण है। जो चैनल सब एक ही एन्क्रिप्टेड टनल में प्रवेश करते हैं वे टनल की थ्रूपुट, गेटवे की CPU और WAN लिंक साझा करते हैं। वहाँ चैनल जोड़ने से क्षमता बढ़ाए बिना काम फिर से बँटता है, और माप इसे दिखा देगा।
तुलना करते समय साइनिंग और एन्क्रिप्शन सक्षम रखें, क्योंकि उन्हें बंद करने से वह बदल जाता है जो आप माप रहे हैं। सुरक्षा सेटिंग बंद करने पर निर्भर प्रदर्शन परिणाम ऐसा परिणाम नहीं है जिसे आप तैनात कर सकें।
जो कार्यभार वास्तव में धीमा है उसे मापें
कुछ भी बदलने से पहले कार्यभार का नाम लें: एक बड़ी क्रमिक प्रतिलिपि, एक निर्देशिका में बहुत सारी छोटी फ़ाइलें, या ऐसा अनुप्रयोग जो हैंडल खोलता और बंद करता है। वास्तविक स्वतंत्र रास्ते होने पर मल्टीचैनल पहले मामले में मदद कर सकता है, और तीसरे के लिए बहुत कम करता है, क्योंकि वहाँ लागत बैंडविड्थ नहीं, निर्भर राउंड ट्रिप हैं।
वर्तमान लेआउट के साथ आधार रेखा लें, एक चीज़ बदलें, और उसी फ़ाइल समूह तथा दिन के उसी समय पर फिर से लें। चुने गए रास्तों की संख्या संख्या के बगल में लिखें, ताकि बाद का पाठक जान सके कि बदलाव ने लेआउट बदला या केवल भार।
यदि चैनल नहीं बदले, तो प्रदर्शन प्रश्न कहीं और है: टनल का एन्क्रिप्शन ओवरहेड, रास्ते की विलंबता, या सर्वर की अपनी डिस्क और CPU। पहले से पर्याप्त एडाप्टर वाले लैपटॉप में एक और जोड़ने से पहले इन्हें मापना उचित है।