तपाईं दोस्रो गेटवे थप्नुहुन्छ, कन्सोलले दुई स्वस्थ सदस्य देखाउँछ, र सत्रको सीमा लगभग सर्दैन, किनकि कसैले पनि ग्राहकहरूलाई नयाँ बाकसमा कसरी पुग्ने भनेर बताएको थिएन। 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

ती पढाइहरू प्रत्येक सदस्यमा सामान्य व्यस्त घण्टामा चलाउनुहोस्, शान्त घण्टामा होइन। जो सदस्य सत्रको जानकारी दिन्छ तर खाली ठेगाना छैन त्यो पहिले नै आफ्नो व्यावहारिक सीमामा छ, इजाजतपत्रले जे भने पनि। प्रत्येक आउटपुटको छेउमा फर्मवेयर संस्करण लेख्नुहोस्, किनकि आदेशका नाम रिलिजहरूबीच बदलिन्छन्।

हानिको एक पटक जानाजान, कार्यालय समयबाहिर अभ्यास गर्नुहोस् र त्यो हुँदा बाँकी सदस्यहरूले के रिपोर्ट गर्छन् लेख्नुहोस्। जो सदस्य रिडाइरेक्सन स्वीकार्छ तर पूलमा ठाउँ छैन त्यो असफल बाँडफाँडका रूपमा देखिन्छ, जसलाई थप ब्यान्डविथले कहिल्यै सुधार्दैन। प्रमाणित अंकहरू मितिसहित योजनाको छेउमा सुरक्षित राख्नुहोस्, ताकि अर्को क्षमता समीक्षा प्रमाणबाट सुरु होस्, इजाजतपत्रको पानाबाट होइन। त्यो अभ्यासको नतिजा उही पृष्ठमा थप्नुहोस्, अंकहरू योजनासँग मिले पनि।

सम्बन्धित लेखहरू