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-સંચાલિત અપડેટ એક સમયે એક ટનલ પર લાગુ થાય છે. લક્ષ્ય ગેટવે, કસ્ટમર ગેટવે અથવા કનેક્શન વિકલ્પોમાં ગ્રાહક-શરૂ કરેલા ફેરફારો, રિપ્લેસમેન્ટ એન્ડપોઇન્ટ તૈયાર થાય ત્યાં સુધી બંને ટનલને અનુપલબ્ધ બનાવે છે.

એક ટનલ પર વિકલ્પો બદલવો એ તેની પોતાની જાહેર અસર સાથેનો ત્રીજો કિસ્સો છે: તે ટનલ તેના પોતાના અપડેટ દરમિયાન અનુપલબ્ધ રહે છે અને બીજી ચાલુ રહે છે.

જરૂર પડે તે પહેલાં વૈકલ્પિકને સાબિત કરો

ઘટનાની રાહ જોવાને બદલે પરીક્ષણનું આયોજન કરો. સ્વસ્થ ટનલને મેન્ટેનન્સ વિન્ડોની અંદર ડાઉન કરો, વૈકલ્પિક વાટાઘાટ કરે છે તેની ખાતરી કરો, પછી વાસ્તવિક ટ્રાફિક બંને દિશામાં તેમાંથી પસાર થાય છે તેની ખાતરી કરો. ટનલ સ્ટેટસની સાથે રિટર્ન રાઉટિંગ પણ તપાસો, કારણ કે ફેઝ-ટુ મેળ ન ખાય તો ટનલ ઉપર રહે છે અને વર્કલોડ મૃત રહે છે. ત્યાં હોવ ત્યારે ટ્રાન્ઝિશનનો સમય માપો.

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