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

ആ വായനകൾ സാധാരണ തിരക്കേറിയ സമയത്ത് ഓരോ അംഗത്തിലും ഓടിക്കുക, ശാന്തമായ സമയത്തല്ല. സെഷനുകൾ റിപ്പോർട്ട് ചെയ്യുന്നുവെങ്കിലും ഒഴിഞ്ഞ വിലാസങ്ങൾ ഇല്ലാത്ത അംഗം ഇതിനകം അതിന്റെ പ്രായോഗിക പരിധിയിലാണ്, ലൈസൻസ് എന്ത് പറഞ്ഞാലും. ഓരോ ഔട്ട്പുട്ടിനൊപ്പം ഫേംവെയർ പതിപ്പ് രേഖപ്പെടുത്തുക, കാരണം കമാൻഡ് നാമങ്ങൾ റിലീസുകൾക്കിടയിൽ മാറുന്നു.

നഷ്ടം ഒരിക്കൽ ബോധപൂർവ്വം, ഓഫീസ് സമയത്തിന് പുറത്ത് പരിശീലിക്കുക, അത് സംഭവിക്കുമ്പോൾ അവശേഷിക്കുന്ന അംഗങ്ങൾ എന്ത് റിപ്പോർട്ട് ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തുക. റീഡയറക്ഷൻ സ്വീകരിക്കുന്നുവെങ്കിലും പൂളിൽ ഇടമില്ലാത്ത അംഗം പരാജയപ്പെട്ട അനുവദനമായി കാണപ്പെടുന്നു, അത് അധിക ബാൻഡ്വിഡ്ത്ത് ഒരിക്കലും ശരിയാക്കുന്നില്ല. സാധുവായ സംഖ്യകൾ തീയതിയോടൊപ്പം പദ്ധതിക്ക് അടുത്ത് സൂക്ഷിക്കുക, അടുത്ത ശേഷി അവലോകനം തെളിവുകളിൽ നിന്ന് തുടങ്ങട്ടെ, ലൈസൻസ് ഷീറ്റിൽ നിന്നല്ല. ആ പരിശീലനത്തിന്റെ ഫലം അതേ പേജിൽ ചേർക്കുക, സംഖ്യകൾ പദ്ധതിയുമായി ഒത്തുപോകുമ്പോഴും.