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

તે વાંચનો દરેક સભ્ય પર સામાન્ય વ્યસ્ત કલાકમાં ચલાવો, શાંત કલાકમાં નહીં. જે સભ્ય સત્રોની જાણ કરે છે પણ ખાલી સરનામાં ધરાવતું નથી તે પહેલેથી તેની વ્યવહારુ મર્યાદા પર છે, લાઇસન્સ ગમે તે કહે. દરેક આઉટપુટની બાજુમાં ફર્મવેર આવૃત્તિ નોંધો, કારણ કે આદેશ નામો રિલીઝ વચ્ચે બદલાય છે.

નુકસાનનો એક વાર જાણી જોઈને, કાર્યાલય સમયની બહાર અભ્યાસ કરો અને નોંધો કે થતી વખતે બચેલા સભ્યો શું જાણ કરે છે. જે સભ્ય રીડાયરેક્શન સ્વીકારે છે પણ પૂલમાં જગ્યા ધરાવતું નથી તે નિષ્ફળ ફાળવણી તરીકે દેખાય છે, જેને વધારાની બેન્ડવિડ્થ કદી સુધારતી નથી. માન્ય આંકડા તારીખ સાથે યોજનાની બાજુમાં સાચવો, જેથી આગલી ક્ષમતા સમીક્ષા પુરાવાથી શરૂ થાય, લાઇસન્સ શીટથી નહીં. તે અભ્યાસનું પરિણામ એ જ પૃષ્ઠ પર ઉમેરો, જ્યારે આંકડા યોજના સાથે મળતા હોય ત્યારે પણ.