VPN सर्भर लोडको व्याख्या: प्रयोगकर्ता, CPU वा अपलिंक?
कम लोड स्कोरले निष्क्रिय प्रयोगकर्ता, बाँकी CPU वा फराकिलो अपलिंक जनाउन सक्छ। यसलाई छिटो भन्नु अघि loadavg, इन्टरफेस काउन्टर र स्टेटस फाइल पढ्नुहोस्।
0.4 लोडमा बसेको गेटवेले आफ्नो पछाडिका हरेक प्रयोगकर्ताका लागि अझै घस्रिन सक्छ। औसत लोडले चलाउन सकिने वा अविच्छिन्न निद्रामा अड्किएका कार्यहरू गन्छ, र चार कोरको होस्टमा एउटै संतृप्त प्रक्रिया यसलाई 1.0 तर्फ धकेल्न पर्याप्त हुन्छ, जब तीन कोर बेकार बसिरहेका हुन्छन्। त्यो संख्यालाई सुरक्षित क्षमता मानेर पढ्नु इन्डपोइन्ट छनोटको सबैभन्दा सामान्य गल्ती हो। टनेललाई वास्तवमा सीमित गर्ने कुरा सामान्यतया चारमध्ये एक हुन्छ: एउटा व्यस्त कोर, अपलिंक, त्यसको अगाडिको लाम वा कसैले कागजात नगरेको प्रति-सत्र नीति।
औसत लोडले कार्य गन्छ, थ्रुपुट होइन
कर्नेलले रन क्यू र इनपुट-आउटपुट प्रतीक्षा गरिरहेका कार्यहरूको संख्याको नमुना लिन्छ, त्यसपछि दुवैलाई एक, पाँच र पन्ध्र मिनेटमा सम्याउँछ। त्यो परिभाषामा बाइट, प्याकेट वा टनेलको कुनै उल्लेख छैन। भण्डारण अड्किएको होस्टले लगभग कुनै ट्राफिक बिना उच्च लोड रिपोर्ट गर्न सक्छ, र कर्नेल डेटा मार्गबाट गिगाबिट धकेल्ने होस्टले आरामदायी लोड रिपोर्ट गर्न सक्छ।
त्यसैले लोडलाई टनेल कार्यक्षमतासँग जोड्न प्रति-कोर दृष्टि चाहिन्छ। एउटा कोर पूरा भरिए पनि ड्यासबोर्डको कुल प्रतिशत अझै राम्रो देखिनेछ:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20तेस्रो आदेश नै VPN होस्टमा सबैभन्दा महत्त्वपूर्ण हुन्छ। OpenVPN 2.x मा प्रयोगकर्ता स्थानको प्याकेट प्रशोधन धेरैजसो प्रति प्रक्रिया क्रमिक हुन्छ, त्यसैले एउटै व्यस्त थ्रेड उच्चतम सीमा बन्न सक्छ, जब ड्यासबोर्डले प्रशस्त खाली क्षमता रिपोर्ट गर्छ। यदि तपाईंको ढिलो अवधिमा एउटा थ्रेडले कोरको धेरै भाग ओगट्छ भने, होस्ट समग्रमा कम सुसज्जित होइन; त्यो यस्तो आयाममा सीमित छ जुन संयोगवश महत्त्वपूर्ण हुन्छ।
समयलाई पनि ध्यान दिनुहोस्। पन्ध्र मिनेटको औसतले कल बिगार्ने विस्फोट लुकाउँछ, त्यसैले उजुरीपछि लिइएको स्क्रिनसट कमजोर प्रमाण हो। समस्या हुँदै गर्दा नमुना लिनुहोस्, र आउटपुटसँगै समय छाप राख्नुहोस्।
अपलिंक र त्यसको अगाडिको लाम
इन्टरफेस काउन्टरहरूले CPU का अंकहरूले उत्तर दिन नसक्ने ब्यान्डविथ प्रश्नको उत्तर दिन्छन्। तिनीहरूले क्षमतालाई हानिबाट पनि छुट्याउँछन्, र यी फरक उपाय भएका फरक विफलता हुन्:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitतपाईंको परीक्षणका क्रममा आफ्नो तोकिएको दरको नजिक रहेको लिंक नै व्याख्या हो, र बाँकी CPU को कुनै मात्राले त्यो बदल्दैन। qdisc लाइनले अन्तरक्रियात्मक ट्राफिकका लागि महत्त्वपूर्ण विवरण थप्छ: ब्याकलग र ड्रपहरूले प्याकेटहरू प्रस्थान गर्नु अघि लाममा पर्खिरहेका छन् कि छैनन् भन्ने बताउँछन्। ठूलो अपलोडमुनि भरिने लामले मानिसहरूले टाढाको सर्भरमा दोष थोपार्ने लक्षण नै उत्पन्न गर्छ, अर्थात् बेन्चमार्कमा अझै राम्रो देखिने जडानमा ढिला कलहरू।
पुनःप्रेषण काउन्टरहरूले प्याकेटहरू प्रस्थान गर्ने तर कहिल्यै सफा नपुग्ने अवस्था समात्छन्। यदि ढिलो विन्डोमा पुनःप्रेषण बढ्छ र इन्टरफेस क्षमताको नजिक छैन भने, समस्या होस्टमा होइन मार्गमा छ, र त्यही सहरको अर्को इन्डपोइन्टमा जाँदा मद्दत गर्दैन।
सत्र संख्याले माग देखाउँछ, सुरक्षित क्षमता होइन
हरेक सार्वजनिक निर्देशिकाले केही संख्यामा जोडिएका प्रयोगकर्ता देखाउँछ, र तिनमध्ये लगभग कसैले पनि ती प्रयोगकर्ताले के गरिरहेका छन् भनी बताउँदैन। अन्तरक्रियात्मक काम गर्ने बीस सत्र र ठूला फाइल तान्ने चार सत्रले एउटै हार्डवेयरमा धेरै फरक लोड उत्पन्न गर्छन्। दोस्रो ढाँचा प्रयोगकर्ता संख्यामा अदृश्य हुन्छ, र त्यही नै एउटा साँझ बिगार्छ। त्यसैले सत्र संख्यालाई मागको संकेतका रूपमा पढ्नु उत्तम हुन्छ, कहिल्यै सुरक्षित क्षमताको कथनका रूपमा होइन।
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
तपाईंले नियन्त्रण गर्ने होस्टमा, स्टेटस फाइलले छुटेको आयाम दिन्छ। OpenVPN ले प्रत्येक क्लाइन्टका लागि बाइट काउन्टर समावेश गर्ने आवधिक स्न्यापसट लेख्छ, र एउटै सत्रले सम्पूर्ण अपलिंकको जिम्मेवारी लिएको छ कि छैन हेर्न त्यो पर्याप्त छ:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusदस सेकेन्डको अन्तरालमा दुई नमुनाले ती संचित गणनालाई प्रत्येक क्लाइन्टको दरमा बदल्छ। त्यही नाप हो जसको ठाउँ प्रयोगकर्ता संख्याले लिन्छ, र यसरी नै एउटा गलत कन्फिगर गरिएको क्लाइन्टले हरेक रात त्यही घण्टामा लिंक संतृप्त गर्छ भन्ने पत्ता लाग्छ।
प्रति-सत्र सीमाहरू नीतिभित्र लुकेका हुन्छन्
सर्भर निष्क्रिय हुन सक्छ र तैपनि तपाईंलाई ब्यान्डविथ दिन अस्वीकार गर्न सक्छ। दर सीमा, प्रति-क्लाइन्ट ब्यान्डविथ उच्चतम सीमा र ट्राफिक आकार दिने काम प्रायः साझा नाम वा पूल अनुसार लागू हुन्छ, त्यसैले एउटै गेटवेका दुई प्रयोगकर्ताले पूरै फरक नतिजा पाउन सक्छन्। संयन्त्र सूक्ष्म छैन, तर दुवै अवस्थामा टनेल सामान्य रूपमा उठ्ने हुनाले बाहिरबाट अदृश्य छ।
आकार दिने काम टनेल इन्टरफेसमा खोज्नुहोस्, भौतिकमा होइन। सीमाले प्रयोगकर्ता, प्रमाणपत्र वा ठेगाना पूल पछ्याउँछ कि जाँच्नुहोस्। यदि तपाईंको परीक्षण खाता सीमारहित पूलमा पर्छ भने, सर्भर ठीक छ र उजुरी गर्ने प्रयोगकर्ता गलत छ भन्ने निष्कर्षमा पुग्नुहुनेछ। त्यो निष्कर्ष कुनै निष्कर्ष नहुनुभन्दा नराम्रो हो, किनकि यसले टिकट बन्द गर्छ।
एउटै निश्चित कामले दुई इन्डपोइन्ट तुलना गर्नुहोस्
क्लाइन्ट पक्षको प्रयोग अझै गर्न लायक छ, तर चरहरू स्थिर भएमा मात्र। एउटै यन्त्र, एउटै पहुँच सञ्जाल, एउटै प्रोटोकल र एउटै गन्तव्य फाइल प्रयोग गर्नुहोस्, त्यसपछि समान दूरीको दोस्रो इन्डपोइन्टविरुद्ध दोहोर्याउनुहोस्। दौडहरूबीच बदलिने जुनसुकै कुरा, दिनको समय पनि समेटेर, नतिजा दूषित गर्छ।
असफलताहरू सफलताइतिकै होसियारीसाथ लेख्नुहोस्। तीन इन्डपोइन्ट चल्ने र एउटा समयसीमामा पुग्ने श्रृंखला चार वेग अंकभन्दा बढी सूचनामूलक हुन्छ, किनकि यसले क्षमताको होइन मार्ग वा नीतिको समस्या देखाउँछ। हरेक केस कम्तीमा दुई पटक चलाउनुहोस्; साझा सञ्जालमा एउटा ढिलो नमुनाले केही प्रमाणित गर्दैन।
अन्तमा, तपाईंले संकलन गरेका अंकहरू तिनले समर्थन गर्ने दाबीसँगै राख्नुहोस्। "यो इन्डपोइन्टले अर्को अड्किएको त्यही विन्डोमा स्थानान्तरण सम्पन्न गर्यो" भन्ने रक्षणीय छ, जबकि "यो इन्डपोइन्ट छिटो छ" भन्ने गृहपृष्ठको स्कोरले जित्न नसकिने बहसमा निम्तो दिन्छ। OpenVPN 2.6 पुस्तिका ले स्टेटस फाइल र आकार दिने विकल्पहरूको कागजात गर्छ, यदि तपाईंलाई होस्ट पक्षका सटीक निर्देशनहरू चाहिन्छ भने।