AWS ഒറ്റ-ടണൽ അറിയിപ്പ്: യഥാർത്ഥത്തിൽ എപ്പോഴാണ് ഇത് പ്രധാനം

ഒരു ടണൽ ഡൗൺ ആണെന്ന് പറയുന്ന AWS Health അറിയിപ്പ് സാധാരണയായി ഒന്നും തകർന്നതായി തോന്നാത്തപ്പോഴാണ് വരുന്നത്. അതുകൊണ്ടുതന്നെ അത് അവഗണിക്കപ്പെടുന്നു. അറിയിപ്പ് ഒരു തടസ്സത്തെ വിവരിക്കുന്നില്ല; AWS-ന്റെ നിരീക്ഷണ വിൻഡോ കടന്നുപോയ ഒരു റിഡണ്ടൻസി അവസ്ഥയെയാണ് വിവരിക്കുന്നത്. നിങ്ങൾ നടപടിയെടുക്കണോ എന്നത് ഡാഷ്ബോർഡ് എങ്ങനെ തോന്നുന്നു എന്നതിനെ ആശ്രയിക്കുന്നില്ല, നിങ്ങളുടെ ഡിസൈനിന് എന്ത് താങ്ങാനാകും എന്നതിനെയാണ് ആശ്രയിക്കുന്നത്.

അറിയിപ്പ് യഥാർത്ഥത്തിൽ അളന്നത്

ഓരോ Site-to-Site കണക്ഷനിലും രണ്ട് ടണലുകളുണ്ട്, അവ വ്യത്യസ്ത AWS എൻഡ്പോയിന്റുകളിൽ അവസാനിക്കുന്നു. AWS-ന്റെ നിരീക്ഷണ ഡോക്യുമെന്റേഷൻ രണ്ടും റിഡണ്ടൻസിക്കായി കോൺഫിഗർ ചെയ്യാൻ ശുപാർശ ചെയ്യുന്നു, ഒന്ന് രേഖപ്പെടുത്തിയ കാലയളവ് ഡൗൺ ആയി തുടർന്നാൽ അറിയിപ്പ് ഉയർത്തുന്നു. ആ കാലയളവ് പ്രധാനമാണ്, കാരണം ചെറിയ ചാഞ്ചലവും സ്ഥിരമായ നഷ്ടവും ഒരു ഗ്രാഫിൽ ഒരുപോലെ കാണപ്പെടുന്നു.

കണക്ഷന്റെ മൊത്തത്തിലുള്ള അവസ്ഥയ്ക്ക് പകരം ഓരോ ടണലിന്റെയും ടെലിമെട്രി വായിക്കുക. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' ഓരോ ടണലിനും ഒരു സ്റ്റാറ്റസും സന്ദേശവും നൽകുന്നു, അറിയിപ്പ് ആധാരമാക്കുന്ന തെളിവ് അതാണ്.

നിങ്ങളുടെ പ്രതികരണം നിർണ്ണയിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ഇത് ഒരു ടിക്കറ്റാണോ അവഗണനയാണോ എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് മൂന്നും പരിശോധിക്കുക.

ആദ്യം, അവശേഷിക്കുന്ന ടണലിന് ഭാരം വഹിക്കാനാകുമോ, ഏതെങ്കിലും ബാൻഡ്വിഡ്ത്ത് പരിധിയും അത് പ്രഖ്യാപിക്കുന്ന പ്രിഫിക്സുകളും ഉൾപ്പെടെ? രണ്ടാമതായി, സൃഷ്ടിയിൽ നിന്ന് ഡൗൺ ആയ രണ്ടാമത്തെ ടണൽ ഒരിക്കലും ഉയരുന്നതായി തെളിയിക്കപ്പെട്ടിട്ടില്ലെങ്കിൽ, ഫെയിൽഓവർ യഥാർത്ഥത്തിൽ സംഭവിക്കുന്നുണ്ടോ? മൂന്നാമതായി, നിങ്ങളുടെ അടുത്ത ആസൂത്രിത മാറ്റം രണ്ട് ടണലുകളും ഒരുമിച്ച് താഴ്ത്തുമോ, അത് ഒരു അലങ്കാര മുന്നറിയിപ്പിനെ മെയിന്റനൻസ് വിൻഡോ പ്രശ്നമാക്കി മാറ്റുന്നു. ഏതെങ്കിലും ഉത്തരം ഇല്ല അല്ലെങ്കിൽ അജ്ഞാതമാണെങ്കിൽ, അറിയിപ്പ് ഒരു യഥാർത്ഥ കണ്ടെത്തലാണ്.

മൂന്നും പ്രായോഗികമായി ശരിയാണെങ്കിൽ, എന്തുകൊണ്ട് അത് സഹനീയമാണെന്ന് എഴുതി സൂക്ഷിക്കുക, തുടർന്ന് മുന്നോട്ട് പോകുക. ആ കുറിപ്പ് അടുത്ത പാദത്തിലെ വാദത്തേക്കാൾ മൂല്യവത്താണ്.

സ്റ്റാൻഡ്ബൈ പീർ എന്തിനെ തെളിയിക്കുന്നില്ല

കോൺഫിഗർ ചെയ്ത ബാക്കപ്പ് പീറുള്ള കസ്റ്റമർ ഗേറ്റ്വേ AWS രണ്ട് ആരോഗ്യകരമായ ടണലുകൾ കാണുന്നു എന്നതിന് തെളിവല്ല. കസ്റ്റമർ ഭാഗത്ത് പുതിയ ചർച്ച ആവശ്യമുള്ള ഒരു തണുത്ത പീർ സൂക്ഷിക്കാം, അത് സാധുവായ ഒരു ഡിസൈനുമാകാം. എന്നിട്ടും അത് രണ്ട് ജീവനുള്ള ടണലുകളുടെ അതേ നിരീക്ഷണമല്ല.

രണ്ട് ഭൗതിക റൗട്ടറുകളും വിപരീത കേസ് പരിഹരിക്കുന്നില്ല. രണ്ട് ടണലുകളും ഒരു ഉപകരണത്തിൽ അവസാനിക്കുകയോ ഒരു അപ്ലിങ്കിലൂടെ പുറത്തുപോകുകയോ ചെയ്താൽ, റിഡണ്ടൻസി കടലാസിൽ മാത്രമാണ്.

മാറ്റത്തെ അതിന്റെ ആഘാത പരിധിയുമായി യോജിപ്പിക്കുക

AWS-ന്റെ എൻഡ്പോയിന്റ് മാറ്റിസ്ഥാപിക്കുന്നതിനുള്ള ഡോക്യുമെന്റേഷൻ കേസുകളെ വേർതിരിക്കുന്നു, ഈ വ്യത്യാസം വഴിമാറി പോകാൻ എളുപ്പമാണ്. AWS നിയന്ത്രിക്കുന്ന അപ്ഡേറ്റുകൾ ഒരു സമയത്ത് ഒരു ടണലിൽ പ്രയോഗിക്കുന്നു. ലക്ഷ്യ ഗേറ്റ്വേയിലോ കസ്റ്റമർ ഗേറ്റ്വേയിലോ കണക്ഷൻ ഓപ്ഷനുകളിലോ ഉപഭോക്താവ് ആരംഭിക്കുന്ന മാറ്റങ്ങൾ, പകരം എൻഡ്പോയിന്റുകൾ ഒരുക്കുന്നതുവരെ രണ്ട് ടണലുകളും ലഭ്യമല്ലാതാക്കുന്നു.

ഒരു ടണലിൽ ഓപ്ഷനുകൾ മാറ്റുന്നത് സ്വന്തം പ്രഖ്യാപിത ആഘാതമുള്ള മൂന്നാമത്തെ കേസാണ്: ആ ടണൽ അതിന്റെ സ്വന്തം അപ്ഡേറ്റിനിടയിൽ ലഭ്യമല്ല, മറ്റേത് പ്രവർത്തിക്കുന്നു.

ആവശ്യമാകുന്നതിന് മുമ്പ് ബദൽ തെളിയിക്കുക

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

അറിയിപ്പ്, ടെലിമെട്രി ഔട്ട്പുട്ട്, മാറ്റ പദ്ധതി എന്നിവ ഒരു രേഖയിൽ സൂക്ഷിക്കുക. ആ രേഖ അടുത്ത പാദത്തിലെ അറിയിപ്പിനെ, ആരെങ്കിലും ഒരിക്കലും ബാക്കപ്പ് പരിശോധിച്ചിട്ടുണ്ടോ എന്ന വാദത്തിന് പകരം രണ്ട് മിനിറ്റ് നീളുന്ന അവലോകനമാക്കി മാറ്റുന്നു.