Паведамленне 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 ужываюцца да аднаго тунеля за раз. Змены, ініцыяваныя кліентам, у мэтавым шлюзе, кліенцкім шлюзе або параметрах злучэння робяць абодва тунелі недаступнымі, пакуль не будуць падрыхтаваныя замяшчальныя канцавыя кропкі.

Змена параметраў на адным тунелі — гэта трэці выпадак з уласным заяўленым уплывам: гэты тунель недаступны падчас свайго абнаўлення, а другі працягвае працаваць.

Дакажыце альтэрнатыву, перш чым яна спатрэбіцца

Заплануйце тэст замест таго, каб чакаць падзеі. Адключыце здаровы тунель у межах акна абслугоўвання, пераканайцеся, што альтэрнатыва ўсталёўвае перагавор, затым пераканайцеся, што рэальны трафік ідзе праз яе ў абодвух кірунках. Праверце зваротную маршрутызацыю разам са статусам тунеля, бо неадпаведнасць другой фазы пакідае тунель паднятым, а працоўную нагрузку мёртвай. Змерце час пераходу, пакуль вы там.

Трымайце паведамленне, вывад тэлеметрыі і план змен у адным запісе. Гэты запіс ператварае паведамленне наступнага квартала ў двуххвілінны агляд замест спрэчкі пра тое, ці хто-небудзь калі-небудзь правяраў рэзерв.

Падобныя артыкулы