AWS-ի ծանուցումը մեկ թունելի մասին. երբ է այն իրոք կարևոր

AWS Health-ի ծանուցումը, որ մեկ թունելը կանգնած է, սովորաբար գալիս է, երբ ոչինչ կոտրված չի թվում։ Հենց դրա համար է այն անտեսվում։ Ծանուցումը չի նկարագրում ընդհատում. այն նկարագրում է ավելորդության վիճակ, որը շարունակվել է AWS-ի դիտարկման պատուհանից ավելի երկար։ Ձեր գործողությունը կախված է նրանից, թե ինչին կարող է դիմանալ ձեր ձևավորումը, ոչ թե նրանից, թե ինչպես է թվում վահանակը։

Ինչ է իրականում չափել ծանուցումը

Յուրաքանչյուր Site-to-Site միացում ունի երկու թունել, որոնք ավարտվում են տարբեր AWS վերջնակետերում։ AWS-ի մոնիտորինգի փաստաթղթերը խորհուրդ են տալիս կարգավորել երկուսն էլ ավելորդության համար և բարձրացնում են ծանուցումը, երբ մեկը մնում է կանգնած փաստաթղթավորված ժամանակահատվածում։ Այդ ժամանակահատվածը կարևոր է, որովհետև կարճ տատանումը և մշտական կորուստը նույնն են թվում մեկ գրաֆիկում։

Կարդացեք թունելային հեռաչափությունը միացման ընդհանուր վիճակի փոխարեն։ aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry'-ը վերադարձնում է կարգավիճակ և հաղորդագրություն յուրաքանչյուր թունելի համար, և դա այն ապացույցն է, որի վրա հիմնված է ծանուցումը։

Երեք պայման, որոնք որոշում են ձեր արձագանքը

Անցեք երեքով, նախքան որոշելը՝ սա տոմս է, թե ուսի թոթափում։

Առաջին, կարո՞ղ է փրկված թունելը կրել ծանրաբեռնվածությունը, ներառյալ ցանկացած թողունակության սահմանը և այն նախադրյալները, որոնք այն հայտարարում է։ Երկրորդ, իրականում տեղի՞ է ունենում փոխանցումը, հաշվի առնելով, որ ստեղծումից ի վեր կանգնած երկրորդ թունելը երբեք չի ապացուցվել, որ բարձրանում է։ Երրորդ, ձեր հաջորդ պլանավորված փոփոխությունը միաժամանակ կիջեցնի՞ երկու թունելները, ինչը կոսմետիկ նախազգուշացումը դարձնում է սպասարկման պատուհանի խնդիր։ Եթե որևէ պատասխան ոչ է կամ անհայտ, ծանուցումը իրական հայտնաբերում է։

Եթե բոլոր երեքը ապացուցելիորեն լավ են, գրեք, թե ինչու է դա հանդուրժելի, և շարունակեք։ Այդ գրառումն ավելի արժեքավոր է, քան հաջորդ եռամսյակի վեճը։

Ինչ չի ապացուցում պահուստային peer-ը

Հաճախորդի դարպասը կարգավորված պահուստային peer-ով ապացույց չէ, որ AWS-ը տեսնում է երկու առողջ թունել։ Հաճախորդի կողմը կարող է պահել սառը peer, որը նոր բանակցություն է պահանջում, և դա կարող է լինել օրինական ձևավորում։ Այնուամենայնիվ դա նույն դիտարկումը չէ, ինչ երկու կենդանի թունել։

Երկու ֆիզիկական երթուղիչներ նույնպես չեն լուծում հակառակ դեպքը։ Երբ երկու թունելներն ավարտվում են մեկ սարքում կամ դուրս են գալիս մեկ վերին կապով, ավելորդությունը գոյություն ունի միայն թղթի վրա։

Համապատասխանեցրեք փոփոխությունը դրա ազդեցության շառավղին

AWS-ի վերջնակետերի փոխարինման փաստաթուղթը-ը բաժանում է դեպքերը, և այդ տարբերությունը հեշտ է բաց թողնել։ AWS-ի կողմից կառավարվող թարմացումները կիրառվում են միաժամանակ մեկ թունելի վրա։ Հաճախորդի նախաձեռնած փոփոխությունները թիրախ դարպասում, հաճախորդի դարպասում կամ միացման ընտրանքներում երկու թունելներն էլ դարձնում են անհասանելի, քանի դեռ փոխարինող վերջնակետերը տրամադրվում են։

Մեկ թունելի վրա ընտրանքները փոխելը երրորդ դեպքն է իր իսկ հայտարարված ազդեցությամբ. այդ թունելը անհասանելի է իր թարմացման ընթացքում, իսկ մյուսը շարունակում է աշխատել։

Ապացուցեք այլընտրանքը, նախքան այն ձեզ պետք կգա

Պլանավորեք թեստը՝ իրադարձությանը սպասելու փոխարեն։ Իջեցրեք առողջ թունելը սպասարկման պատուհանի ընթացքում, հաստատեք, որ այլընտրանքը բանակցում է, ապա հաստատեք, որ իրական տրաֆիկը անցնում է դրա միջով երկու ուղղություններով։ Ստուգեք վերադարձի երթուղավորումը և թունելի կարգավիճակը, որովհետև երկրորդ փուլի անհամապատասխանությունը թողնում է թունելը վերև, իսկ աշխատանքային ծանրաբեռնվածությունը՝ մեռած։ Չափեք անցումը, քանի դեռ այնտեղ եք։

Պահեք ծանուցումը, հեռաչափության ելքը և փոփոխությունների պլանը մեկ գրառման մեջ։ Այդ գրառումը հաջորդ եռամսյակի ծանուցումը դարձնում է երկու րոպեանոց վերանայում՝ փոխարեն այն բանի, թե արդյոք ինչ-որ մեկը երբևէ փորձարկել է պահուստը։