VPN सत्रे भूमिकेनुसार स्केल करा, मग अपयशाचे हेडरूम तपासा

तुम्ही दुसरे गेटवे जोडता, कन्सोल दोन निरोगी सदस्य दाखवते, आणि सत्रांची मर्यादा जवळपास हलत नाही, कारण कोणीही क्लायंटना नवीन बॉक्सपर्यंत कसे पोहोचायचे ते सांगितले नाही। VPN सेवा स्केल करणे म्हणजे क्रमाने दोन निर्णय: या कनेक्शन प्रकारासाठी कोणती यंत्रणा क्लायंटचे वितरण करते, आणि सर्वात वाईट एका नुकसानानंतर किती क्षमता उरते। ते उलट क्रमाने घेतल्यास अशी रचना तयार होते जी अनावश्यक वाटते आणि तिची गरज असते तेव्हाच अपयशी ठरते। कन्सोलपासून सुरुवात करा, मग गणित करा।

यंत्रणा सत्र प्रकाराशी जुळवा

रिमोट वापरकर्ते, साइट-ते-साइट सहकारी आणि सदैव सुरू असलेल्या उपकरण टनेल या अदलाबदल करण्यायोग्य सत्रे नाहीत। यापैकी एकासाठी तयार केलेले वितरण वैशिष्ट्य सहसा वाटाघाटीदरम्यान क्लायंटला वळवते, ज्याचा आधीच निश्चित पत्ता आणि स्थिर संरचना असलेल्या सहकार्यासाठी काही अर्थ नाही।

Cisco चे ASA उच्च उपलब्धता मार्गदर्शक तीन क्षमता वेगळ्या ठेवते: रिमोट प्रवेश VPN लोड संतुलन, स्थितीसह फेलओव्हर आणि साइट-ते-साइट क्लस्टरिंग। फक्त पहिली पात्र क्लायंटला गट नोंदीतून सदस्याकडे हलवते, आणि LAN-ते-LAN कनेक्शन त्या वितरणाबाहेर राहतात। सामान्य TCP बॅलन्सर प्रोटोकॉलच्या स्वतःच्या रीडायरेक्शन पायरीची जागा घेऊ शकत नाही, कारण टनेल हँडशेक हा साधा HTTP नाही जो प्रॉक्सी पुन्हा लिहू शकेल। व्यावहारिक परिणाम असा बॅलन्सर आहे जो कनेक्शन स्वीकारतो आणि तरीही क्लायंटला टनेल तयार करू देत नाही।

दुसरे उपकरण मागवण्यापूर्वी वैशिष्ट्यांची यादी तुमच्या सत्र प्रकारासमोर वाचा। परवाना ओळ आणि यंत्रणा ओळ या वेगळ्या नोंदी आहेत, आणि एकाचा अर्थ दुसरी नाही।

अंदाजाऐवजी उदाहरण मोजा

समजा तीन गेटवे तुम्ही मंजूर केलेल्या भाराखाली 800 एकाचवेळी टनेलवर प्रमाणित आहेत, जे एकूण 2,400 आहे। व्यस्त तासाचे 1,650 लक्ष्य एक युनिट गमावेपर्यंत आरामदायक वाटते, आणि नंतर उरलेल्या जोडीला कठोर 1,600 समोर 1,650 टिकवावे लागते। रचना आधीच अपयशी झाली आहे, आणि फेलओव्हरचे कोणतेही ट्युनिंग गणित सुधारत नाही।

लक्ष्य असे ठेवा की उरलेला संच ते अजूनही पूर्ण करेल, ज्याचा अर्थ तीन सदस्यांच्या गटासाठी एकूणाच्या दोन-तृतीयांशपेक्षा खाली राहणे होय। ते प्रमाण गणिताचे गुणधर्म आहे, कोणत्याही उत्पादनाचे नाही, म्हणून सदस्याचा प्रमाणित आकडा बदलल्यावर ते पुन्हा मोजा। परवानाधारक संख्या, दस्तऐवजीकृत कमाल आणि तुमचा स्वतःचा मोजलेला आकडा तीन स्तंभांत ठेवा, कारण ते क्वचितच जुळतात आणि सर्वात लहान निर्णायक ठरतो। पाहिलेल्या व्यस्त-तासाच्या शिखरासाठी चौथा स्तंभ योजना पहिल्या महिन्यानंतरही प्रामाणिक ठेवतो।

फक्त स्थिर स्थिती नाही, पुन्हा जोडणीच्या लाटेचे बजेट ठेवा

अपयशी सदस्यावरील सत्रे शांतपणे दुसरीकडे परत येत नाहीत। यंत्रणेनुसार ती स्थितीसह हस्तांतरित होतात, शून्यापासून पुन्हा वाटाघाटी करतात, किंवा अनुप्रयोग त्याच्या स्वतःच्या वेळापत्रकानुसार पुन्हा प्रयत्न करण्याची वाट पाहतात।

एका मिनिटात पुन्हा प्रयत्न करणारे काही हजार क्लायंट स्थिर 1,650 पेक्षा वेगळी घटना आहेत, आणि प्रमाणीकरण सर्व्हर ते सर्वात आधी जाणवतात। पूलमधील जागाही तपासा, कारण रीडायरेक्शन त्याचा सल्ला घेत नाही: जो सदस्य पत्ता वाटू शकत नाही तो तरीही क्लायंट स्वीकारतो आणि नंतर त्याचा रहदारी टाकून देतो।

पूल आणि मार्गासह क्षमता पडताळा

पडताळणी हा केवळ-वाचनाचा सराव आहे जो देखभाल विंडो उघडण्यापूर्वी बहुतेक रचना त्रुटी पकडतो। प्रत्येक सदस्याचा पूल, सक्रिय सत्रांची संख्या आणि क्लायंटच्या सबनेटपर्यंत परतीचा मार्ग गोळा करा, मग प्रत्येकाची योजनेशी तुलना करा। पूल संपणे आणि परतीचा मार्ग नसणे दोन्ही अशा क्लायंटसारखे दिसतात जो प्रमाणित होऊन नंतर रहदारी गमावतो।

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

ती वाचने प्रत्येक सदस्यावर सामान्य व्यस्त तासात चालवा, शांत तासात नाही। जो सदस्य सत्रांची नोंद देतो पण रिकामे पत्ते नाहीत तो आधीच त्याच्या व्यावहारिक मर्यादेवर आहे, परवाना काहीही म्हणो। प्रत्येक आउटपुटच्या शेजारी फर्मवेअर आवृत्ती नोंदवा, कारण आदेशांची नावे आवृत्त्यांमध्ये बदलतात।

नुकसानाचा एकदा जाणूनबुजून, कार्यालयीन वेळेबाहेर सराव करा आणि ते घडत असताना उरलेले सदस्य काय नोंदवतात ते लिहा। जो सदस्य रीडायरेक्शन स्वीकारतो पण पूलमध्ये जागा नाही तो अयशस्वी वाटप म्हणून दिसतो, जे अतिरिक्त बँडविड्थ कधीही सुधारत नाही। प्रमाणित आकडे तारखेसह योजनेजवळ साठवा, जेणेकरून पुढील क्षमता आढावा पुराव्यांपासून सुरू होईल, परवाना पत्रकापासून नाही। त्या सरावाचा निकाल त्याच पानावर जोडा, आकडे योजनेशी जुळले तरीही।