Резервтік арнаға автоматты ауысу қалай жұмыс істейді?

Резервтік арнаға автоматты ауысу маршрутизатор сыртқы желінің нақты қолжетімділігін тексеріп, істен шыққан жолды маршруттаудан алып тастап, жаңа қосылымдарды екінші WAN арқылы жібергенде ғана жұмыс істейді. Маршрутизаторға жалғанған екі кабель мен екі default route жазбасы өздігінен резерв жасамайды.

Бұл сұлбаның қолайсыз бір қасиеті бар: интерфейстегі жасыл индикатор провайдер апатынан кейін де жанып тұра береді, ал белсенді TCP сессиясы жария IP мекенжайы ауысқанда көбіне үзіледі. Сондықтан дерексіз «резервті» емес, төрт бөлек процесті жобалау керек: ақауды анықтау, маршрутты ауыстыру, мекенжай трансляциясын ауыстыру және қолданбаларды қалпына келтіру. Мен мұндай қос арналарды талай рет баптадым, қателікті көбіне маршрут синтаксисінен емес, «нені ақау деп есептейміз?» деген сұраққа берілген қате жауаптан таптым.

Резерв ақау моделінен басталады

Алдымен сұлба қандай ақаулардан қорғауы керегін тізіп шығыңыз, өйткені маршрутизатор олардың әрқайсын әртүрлі көреді. Ethernet кабелінің үзілуі немесе оптикалық сигналдың жоғалуы интерфейсті down күйіне түсіреді, бірақ қатып қалған CPE, оператор желісінің ішіндегі бұзылған маршрут, DNS ақауы және пакеттердің көп жоғалуы арнаны көтерілген күйде қалдыруы мүмкін.

Бақылауды деңгейлерге бөлген дұрыс. Физикалық порттың күйі тек көрші құрылғымен байланыс бар-жоғын көрсетеді. Шлюзді тексеру провайдердің ең жақын маршрутизаторы қолжетімді ме деген сұраққа жауап береді. Қашықтағы мекенжайға жіберілген probe пакеттің қатынау желісінен әрі өткенін растайды. DNS, HTTPS немесе қажет бизнес-сервисті тексеру арнаның нақты жұмысқа жарамдылығын өлшейді.

Екі арна шынымен тәуелсіз жабдықта аяқтала ма, соны бөлек тексеріңіз. Маршрутизатор алдындағы жалғыз басқарылатын коммутатор, ортақ медиаконвертер немесе бір қуат көзі сұлбада екі провайдер көрсетілсе де, екі WAN-ды бір сәтте өшіре алады. Кейде мұндай құрастыру шығын жағынан орынды, бірақ оны ортақ бөлшек ақауынан қорғаныс деп көрсетуге болмайды. Тәуекелдер тізімінде осы ортақ торапты атап, оның екінші данасы керек пе, соны шешіңіз.

Қатынаудың әртүрлі технологиялары да физикалық трассалардың бөлек болуына кепілдік бермейді. Оптика мен радио бір агрегация алаңында түйісуі, ал екі оператор бір магистральді жалға алуы мүмкін. Инженер оператор желісінің толық картасын әрдайым ала алмайды, бірақ ғимаратқа бөлек кірістерді, әртүрлі қатысу нүктелерін және соңғы мильдің сипаттамасын сұрата алады. Осыдан кейін бір мезгілдегі ақауды сынау жасалған болжамдардың жалғыз сенімді тексеруі болып қалады.

Кәдімгі кеңсе немесе филиал үшін дұрыс мақсат мынадай: негізгі арна арқылы бірнеше тәуелсіз сыртқы торапқа тұрақты жету мүмкін болмаған кезде шығыс трафикті ауыстыру және арна тұрақты қалпына келген соң ғана кері қайтару. Бұл шекаралық маршрутизатордың өзінің жоғары қолжетімділігін қамтамасыз етпейді. Жалғыз маршрутизатор қуатсыз қалса, екі провайдер де пайдасыз болады. Мұндай ақаудан қорғану үшін екі шекаралық құрылғы, күйді синхрондау немесе келісілген first-hop сұлбасы, бөлек қуат және әр тораптың істен шығуын тексеру қажет.

Баптауға кіріспей тұрып уәденің шегін жазыңыз. Резервтік арна жаңа сыртқы қосылым ашу мүмкіндігін сақтай алады, бірақ ашық бейнеқоңырауды, VPN туннелін немесе файл жүктеуін сақтауға міндетті емес. Екінші оператор басқа мекенжай бергенде, ал сыртқы клиенттер бірінші мекенжайға жүгінуді жалғастырғанда, ол жарияланған кіріс сервистерді де автоматты түрде қалпына келтірмейді.

Бір ping бизнеске қажет күйді тексермейді

Провайдер шлюзінің мекенжайын ғана тексеру жеткіліксіз: оның ар жағындағы желі қолжетімсіз болса да, шлюз жауап беруі мүмкін. Бір танымал жария мекенжайды тексеру де дұрыс емес, өйткені оның иесі ICMP сұрауларын шектеуі, оған баратын маршрут өзгеруі немесе сол тораптың жергілікті ақауы сау WAN-ды істен шыққан етіп көрсетуі мүмкін.

Әр провайдер үшін оның қатынау желісінен тыс кемінде екі нысан таңдаңыз. Олар тұрақты жауап беріп, қатаң бекітілген WAN арқылы өтуі және бір операторға не бір автономды жүйеге тәуелді болмауы керек. Маршрутизатор мүмкіндік берсе, бір нысан жоғалғанда ескерту берілетіндей, ал барлық нысан жоғалғанда арна жұмыстан шығарылатындай нәтижелерді біріктіріңіз. «Кез келген probe құласа, WAN өлді» деген тым қатаң ереже бір адресаттағы қысқа ақауды бүкіл ұйымның ауысуына айналдырады.

Әр бақылау нысанына баратын маршрутты тексеріліп жатқан провайдерге бекітіңіз. Әйтпесе негізгі WAN істен шыққаннан кейін probe резерв арқылы кетіп, жауап алып, негізгі жолды қате түрде қайта жұмыс істейді деп жариялайды. Журналда бұл цикл біресе ары, біресе бері үздіксіз ауысу болып көрінеді. Рекурсивті статикалық маршруттауда бекітуді әр оператордың шлюзі арқылы жүргізілген жеке host route жасайды. Policy routing бар жүйелерде осы міндетті мониторинг көзіне немесе процесіне арналған ереже орындайды.

ICMP негізгі IP қолжетімділігін көрсетеді, бірақ қолданба сапасын өлшемейді. Платформа бақылау терезесінде есептей алса, телефония немесе терминалдық қатынау үшін пакет жоғалуы мен кідіріс шектерін қосыңыз. Netgate компаниясының Multi-WAN құжаттамасы толық істен шығу, жоғары кідіріс және пакет жоғалуы оқиғаларын нақты ажыратады. Бұл айырмашылық пайдалы: 20 пайыз пакет жоғалтқан арна техникалық тұрғыда тірі, бірақ пайдаланушы қалыпты жұмыс істей алмайды. Шекті біреудің конфигурациясынан емес, сау арнаның өлшемдері мен қолданба талаптарынан алыңыз.

Таймерлер ақауды жасырмай, тұрақсыздықты сүзуі керек

Ауысу уақыты probe аралығынан, сәтсіз тексерулер санынан немесе терезесінен, күй өзгерісінің кідірісінен, маршрутты қайта есептеу мен қолданбаның қайта қосылуынан құралады. Егер тек резервтік default route пайда болған сәт өлшеніп, браузер ескі TCP сессиясын тағы бір минут ұстап тұрса, «бір секундта ауысады» деген уәденің мәні жоқ.

Арнадан кету мен оған қайту үшін әртүрлі шарт қойыңыз. Әдетте негізгі арнадан кетуге қатарынан бірнеше қате немесе қысқа терезеде шектен асу жеткілікті. Қайту баяуырақ болуы керек: пайдаланушыларды қайта жібермей тұрып негізгі арна тұрақты жұмысын көрсетуі тиіс. Cisco object tracking бұл үшін бөлек delay down және delay up мәндерін береді. Көптеген желіаралық экрандар мен SD-WAN құрылғыларында ұқсас параметрлер немесе сценарийлер бар.

Мысалы, әр 3 секундтағы probe, 3 сәтсіз жауаптан кейін ақау деп тану және 5 секундтық down кідірісі үзілу сәтіне қарай шамамен 11-14 секундтық теориялық анықтау уақытын береді. Оған маршрутты орнату, күйлерді тазарту және қолданбаның қайталап көруі қосылады. Бұл есептік баға, кепілденген сан емес. Оны өз құрылғыңызда нақты жүктемемен өлшеңіз.

Әдемі көрсеткіш үшін аралықтарды мүмкін болғанша қысқартпаңыз. Мобильді, радиорелелік немесе жүктелген арнадағы қысқа timeout жалған ақаулар туғызады. Тым ұзақ терезе де зиян: мониторингтен бұрын мәселені пайдаланушылар хабарлайды. Дұрыс баптау жекелеген жоғалуларды телеметрияда көрсетеді, бірақ маршрутты ұзаққа созылған нашарлау кезінде ғана өзгертеді.

Маршрут, NAT және саясат бірге ауысуы тиіс

Ақау расталғаннан кейін резервтік default route белсенді болуы, ал шығыс NAT пен желіаралық экран ережелері сол трафикті екінші WAN арқылы өткізуі керек. Жиі кездесетін ақау былай көрінеді: маршрут кестесі дұрыс, пакет резервтік интерфейстен жеке бастапқы мекенжаймен шығады, ал masquerade немесе source NAT ережесі тек бірінші интерфейске жазылғандықтан провайдер оны тастайды.

Тек негізгі кестені тексерумен шектелмеңіз. Қонақ желісіне, телефонияға, VPN-ге, сервер сегментіне және маршрутизатордың өз трафигіне арналған policy routing нақты шлюзге сілтеме жасауы мүмкін. Корпоративтік DNS-ке немесе бас кеңсеге арналған статикалық маршрут та жаңа default route жолын айналып өтеді. Резерв барлық жүйеге арналмаса, шығарылған саясаттарды reject ережесімен анық аяқтаңыз, сонда олар кездейсоқ маршрут арқылы сыртқа шықпайды.

Резервтік арнаға жеке шығыс трансляциялары, рұқсат ережелері және қажет болса туннельдер үшін кішірек MSS керек. DNS клиенттері екі жол арқылы да резолверге жете алуы тиіс. Желіаралық экранның NTP, жаңарту, VPN клиенті және журнал жіберу секілді өз сервистері кейде бөлек кесте не интерфейске бекітуді қолданады, сондықтан пайдаланушы ноутбугынан жасалған сынақ олардың жұмысын растамайды.

Failover мен жүктемені теңестіруді шатастырмаңыз. Резервтеу кезінде негізгі арна жарамды болғанша барлық жаңа қосылым бірінші басымдықтағы арнамен жүреді. Теңестіру кезінде жүйе қосылымдарды екі жұмыс істейтін WAN арасында бөледі. Бір сессияның жеке пакеттерін әртүрлі провайдер арқылы жіберу көп жағдайда қате: әртүрлі кідіріс пен жария мекенжайлар пакет ретін және қашықтағы тараптың тексерулерін бұзады. Екі арнаның да мүмкіндігін қолдану қажет болса, тұтас қосылымдарды бөліп, сезімтал нысандарды бір шығысқа бекітіңіз.

Ескі қосылымдар провайдер ауысқанда сақталмауы мүмкін

Кәдімгі IPv4 NAT кезінде белсенді қосылымдар көбіне үзіледі, өйткені резервтік провайдер басқа жария мекенжайды қояды. Қашықтағы сервер мекенжайлар мен порттардың жаңа төрттігін басқа қосылым деп көреді, ал ескі сессияның пакеттері не жетпейді, не NAT пен желіаралық экран күйіне сәйкес келмейді.

RFC 4116 мұны жарнамалық жұмсартусыз тұжырымдайды: NAT қолданатын multihoming сұлбасында жол ауысқанда көлік деңгейіндегі сессиялар жалпы жағдайда сақталмайды, бірақ ауысудан кейін жаңа сессиялар ашуға болады. Провайдер берген мекенжайларды пайдаланатын екі тұрмыстық немесе корпоративтік арна үшін адал күту осы. Браузер сұрауды әдетте қайталайды, мессенджер қайта қосылады, ал SSH, RDP, SIP қоңырауы, ұзақ жүктеу және кей VPN туннельдері үзілісті байқайды.

Күй кестесі клиенттің істен шыққан жолға қанша уақыт байланып қалатынын анықтайды. Ескі state entries сақталса, резервтік маршрут белсенді болса да, қолданба TCP timeout біткенше күтуі мүмкін. Күйлер тазартылса, клиент екінші WAN арқылы жаңа қосылымды тезірек жасайды, бірақ әкімші сәйкес сессиялардың бәрін әдейі үзеді. Сондықтан pfSense құжаттамасы күйлерді сақтау, істен шыққан шлюз күйлерін іріктеп тазарту және бүкіл кестені тазарту арасынан таңдауды ұсынады. Соңғысы байланысы жоқ трафикті де бұзуы мүмкін.

Мен расталған ақаудан кейін істен шыққан WAN күйлерін іріктеп тазартуды жөн көремін. Дауыс шлюзіне немесе тұрақты туннельге қолданба өзі тым баяу қалпына келсе, тіркеуді не туннельді қайта іске қосатын жеке watchdog пайдалы. Екі жол бір қолжетімді жария префиксті қолданғанда және Интернет маршруттауы оны операторлар арасында ауыстырғанда, не екі қатынау арнасының үстіндегі туннель ортақ шығыс нүктесіне апарғанда ғана сессияны сақтауға болады. Бұл BGP, PI мекенжайлары, оператор қызметі немесе сыртқы концентраторы бар басқа архитектура.

Кіріс трафик бөлек ережелермен ауысады

Шығыс қатынауды резервтеу жарияланған серверді екінші провайдер арқылы қолжетімді етпейді. Сыртқы клиент бірінші оператордың мекенжайына жүгінуді жалғастырады, ал резервтік интерфейстегі DNAT ережесі өзіне келмеген пакетті ұстай алмайды.

Маңызы төмен жариялау үшін екінші мекенжай ашып, апат кезінде DNS жазбасын өзгертуге болады, бірақ кідіріс резолвер кэшіне, TTL-ге, жазбаны жаңарту жылдамдығына және қолданба әрекетіне байланысты. Ашық қосылымдар бұрынғы мекенжайды әлі де қолданады. Торап мекенжайы DNS-те тұрған IPsec те екі тарап атауды жаңартып, туннельді қайта құрғанша біраз уақыт қалпына келмеуі мүмкін.

Кіріс сервис өз мекенжайын сақтауы керек болса, операторлармен BGP және провайдерден тәуелсіз префикс туралы сөйлесіңіз немесе тұрақты мекенжайы бар жария кіру нүктесін алаңнан тыс орналастырыңыз. Екінші нұсқа трафикті екі туннельдің бірімен алаңға жеткізеді. Ол сыртқы нүктеге тәуелділік қосады, сондықтан оның өткізу қабілетін, кідірісін және өз резервін тексеру қажет.

Кері жол да симметриялы болуы тиіс. WAN2 арқылы келген пакет WAN2 арқылы жауап алуы керек, әйтпесе провайдердің бастапқы мекенжайды сүзуі немесе stateful firewall оны тастайды. Кіріс интерфейсіне қарай policy routing, бөлек кестелер және дұрыс source NAT бұл мәселені шешеді. Жарияланған сервистерді LAN ішінен hairpin NAT арқылы емес, шын сыртқы желіден тексеріңіз.

Жұмыс істейтін конфигурация маршрут кестесінен көрінеді

RouterOS 7 үшін бұл мысал бірден көшіріп қоятын үлгіні емес, рекурсивті тексеру қағидасын көрсетеді. Шлюздер мен бақылау мекенжайларын ауыстырып, кесте атауларын тексеріңіз және командаларды алдымен стендте орындаңыз. MikroTik компаниясының WAN Backup құжаттамасы осы тәсілді қолданады: host route сыртқы probe-ты провайдерге бекітеді, ал default route қолжетімділікке рекурсивті түрде тәуелді болады.

/ip route
add dst-address=1.1.1.1/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-a
add dst-address=9.9.9.9/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-b
add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-a
add dst-address=208.67.222.222/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-b
add dst-address=0.0.0.0/0 gateway=1.1.1.1,9.9.9.9 distance=1 target-scope=11 check-gateway=ping comment=default-isp1
add dst-address=0.0.0.0/0 gateway=8.8.8.8,208.67.222.222 distance=2 target-scope=11 check-gateway=ping comment=default-isp2

192.0.2.1 және 198.51.100.1 мекенжайлары құжаттамалық диапазондардан алынған, жұмыс желісінде оларды нақты next hop мәндерімен ауыстыру керек. Әр default route ішіндегі екі gateway бірнеше рекурсивті next hop жасайды. Қолданар алдында RouterOS нұсқаңыздың әрекетін нақтылаңыз: қажет логика кемінде бір нысан жауап бергенде негізгі маршрутты қолжетімді қалдырып, екі нысан да жоғалғанда ғана оны алып тастауы тиіс.

Баптаудан кейін /routing/route/print detail where dst-address=0.0.0.0/0 командасы негізгі маршрутты белсенді, ал distance мәні үлкен резервтік маршрутты үміткер ретінде көрсетуі керек. Ақау кезінде негізгі маршруттың рекурсивті next hop мәндері қолжетімсіз болып, негізгі default route белсенді емес күйге өтеді де, distance=2 маршруты белсенді болады. Сол уақытта NAT есептегіштерін, таңдалған шығыс интерфейсті және сынақ клиентінің сыртқы мекенжайын тексеріңіз. Трафик өтпей тұрған белсенді маршрут жалаушасы сұлбаның жартысын ғана дәлелдейді.

Басқа өндірушінің жабдығында да тәуелділік графы сол күйінде қалады: probe WAN-ға бекітіледі, track object нәтижені алады, негізгі default route сол track мәніне тәуелді болады, резервтің метрикасы нашарлау тұрады, ал NAT пен саясаттар екі шығысқа да жазылады. Платформалар арасында синтаксисті көшірмеңіз. Тексеруге болатын себеп-салдар байланысын көшіріңіз.

Сынақ желіні физикалық порттан жоғары деңгейде бұзуы керек

Қабылдау сынағы мәлімделген әр ақауды қайталап, нәтижені қолданба деңгейінде өлшеуі тиіс. Кабельді суыру пайдалы, бірақ бұл ең оңай жағдай: интерфейс бірден құлайды, ал күрделі қолжетімділік тексеруі мүлде іске қосылмайды.

1. Үздіксіз ping, қысқа HTTPS сұрауларын, ұзақ жүктеуді, SSH немесе RDP сессиясын және сынақ қоңырауын іске қосыңыз. Маршруттау, NAT және мониторинг оқиғаларының уақытын қатар сақтаңыз.
2. Негізгі WAN арқылы бақылау нысандарына қатынауды жергілікті шлюзден жоғары жерде бұғаттаңыз немесе стендте провайдер жағында уақытша blackhole жасаңыз. Бір нысан жоғалғанда арна сақталатынын, ал бәрі жоғалғанда трафик ауысатынын тексеріңіз.
3. Арнаны көтерілген күйде қалдырып, кәдімгі Интернет трафигіне тыйым салыңыз. Осылайша резерв арқылы байқамай кететін немесе тек шлюзді өлшейтін тексеруді табасыз.
4. Негізгі жолды қысқа уақытқа қайтарып, қайта бұзыңыз. Маршрут тұрақсыз ауыспауы, ал delay up тұрақты қалпына келуге дейін пайдаланушыларды резервте ұстауы керек.
5. Кіріс жарияланымдар, VPN, DNS, телефония және маршрутизатордың өз сервистері үшін сынақты қайталаңыз. Ескі сессиялардың үзілуін жаңа қосылымның сәтті ашылған уақытынан бөлек жазыңыз.

Есепте соңғы сәтті probe, WAN ақаулы деп танылған сәт, белсенді маршрут ауысқан уақыт, жаңа жария мекенжайы бар алғашқы пакет және қолданбадағы алғашқы сәтті әрекет белгіленуі керек. Сонда «тез ауысты ма, баяу ма» деген талас өлшенетін аралықтарға айналады. Екінші тарифтің жылдамдығы не көлемі шектеулі болса, сыртқы резервтік көшіру немесе жаңарту сияқты резервке әдейі жіберілмейтін трафикті де жазыңыз.

Алғашқы толық сынақты жұмыс уақытында қызмет көрсету терезесі мен кері қайту жолынсыз өткізбеңіз. Алдымен автоматты қайтуды өшіріп, қолмен ауысуды тексеріңіз, содан кейін анықтауды, ең соңында failback функциясын қосыңыз. Инфрақұрылымдық жобада GSE серверлік және желілік бөлікті, арналардың тәуелсіздігін және тәулік бойғы қолдауды бір сұлбада байланыстыра алады, бірақ қабылдау өлшемдерін бәрібір тапсырыс беруші белгілеп, өз қолданбаларына сәйкестендіруі тиіс.

Негізгі арнаға қайту одан кетуден қауіпті

Автоматты failback жиі екінші жоспарланбаған үзіліс жасайды: пайдаланушылар WAN2 арқылы жұмыс істеп отырғанда қалпына келген WAN1 маршрутты қайта алып, жария мекенжайды тағы өзгертеді. Негізгі оператор бірнеше рет көтеріліп, қайта құласа, гистерезиссіз желі әр оқиғада сессияларды үзеді.

up кідірісін down мәнінен ұзағырақ қойып, қалпына келгеннен кейін арна сапасын тексеріңіз. Сезімтал ауысымдар немесе операциялар кезінде келісілген терезеде қолмен қайту дұрысырақ болуы мүмкін. Бұл автоматтандырудан бас тарту емес, екінші әсерді басқару. Автоматты ауысу жалғасып жатқан апаттан қорғайды, ал автоматты қайту тек тиімді тарифті немесе өткізу қабілетін қайтарады.

Қайту кезінде резервтік WAN күйлерін тазарту қажет пе, соны шешіңіз. Олар сақталса, платформа күйдің шлюзге бекітілуін ұстайтын жағдайда ашық қосылымдар WAN2 арқылы аяқталып, жаңалары WAN1 арқылы жүреді. Бірден тазарту қайтуды жылдамырақ әрі байқалатын етеді. Қоңыраулар мен транзакциялар үшін белсенді күйлерді сақтау әдетте дұрысырақ, бірақ өтпелі кезеңде маршрутизатор екі жолды да дұрыс ұстауы керек.

Әр апаттан кейін нақты уақытты мақсатпен салыстырып, қалпына келудің қай кезеңі кешіккенін қараңыз. Маршрут 12 секундта ауысып, VPN 90 секундтан кейін көтерілсе, probe баптау ештеңені түземейді. IKE таймерлерін, DNS-ті, тіркеуді немесе нақты клиенттің логикасын талдау керек.

Резервтің өткізу қабілетін саясат қорғауы керек

Резервтік арна апат кезінде маңызды трафикті көтеруі тиіс, бірақ негізгі тарифтің дәл көшірмесін сатып алу әрдайым қажет емес. Алдымен жұмыс жүктемесін трафик кластары бойынша өлшеп, қай қолданбалар міндетті түрде жалғасатынын, қайсысы баяулай алатынын және WAN1 қалпына келгенше қайсысын тоқтату керегін шешіңіз. Орташа тұтыну бұл есепке жарамайды, өйткені ақау жұмыс кезіндегі ең жоғары жүктемемен, резервтік көшірумен, бейнеконференциямен немесе файлдардың жаппай синхрондалуымен қатар келуі мүмкін.

Дауыс, терминалдық қатынау, төлем операциялары, корпоративтік VPN және қызметтік DNS пен NTP үшін арна жолағының бюджетін жасаңыз. Протокол шығыны мен қысқа жүктеме секірістеріне қор қосыңыз. Одан кейін WAN2 арқылы операциялық жүйе жаңартуларын, бұлттағы үлкен каталогтарды синхрондауды, қонақ Wi-Fi желісін және сыртқы резервтік көшіруді шектеңіз не тыйыңыз, егер олар жұмыс қолданбаларын ығыстыра алса. Агрессивті класты шектемей берілген басымдық жиі көмектеспейді: үлкен ағындар кезекті толтырып қойған, ал тар жер маршрутизатор жіберуді басқара алмайтын оператор жағында болады.

Шығыс жылдамдықты резервтік қатынаудың нақты өлшенген сыйымдылығынан сәл төмен қалыптастырыңыз. Сонда кезек өз құрылғыңызда қалады және дауыс пен интерактивті трафикке болжамды қызмет бере аласыз. Кіріс бағытта бақылау әлсіздеу, сондықтан алушыларды өз жағыңызда шектеңіз, оператордан тиісті профиль сұраңыз немесе қолданбалардың қарқынын азайтыңыз. Сапаны толық жүктемеде тексеріңіз: бос арна бір үлкен upload басталғанда жоғалатын әдемі кідірісті дерлік әрдайым көрсетеді.

LTE немесе көлемі бойынша төленетін басқа қатынау арқылы жасалған резервті күтпеген шоттан бөлек қорғау керек. Көлем туралы ескертулер орнатып, ауыр санаттарды тоқтатыңыз және ұмыт қалған ақаудың кесірінен арна негізгі болып қалмағанына көз жеткізіңіз. Оператор CGNAT қолданса, кәдімгі шығыс қосылымдар жұмыс істеп, кіріс жарияланымдар мен кейбір туннельдер көтерілмеуі мүмкін. Қызметтің бұл қасиетін апат кезінде емес, алдын ала анықтау керек.

Екінші WAN қосылғанда шекаралық құрылғының өнімділігі де өзгереді. NAT, туннель шифрлауы, күйлерді есепке алу, кезек қалыптастыру және егжей-тегжейлі журналдау процессор мен жадты пайдаланады. Порттардың сипаттамадағы жылдамдығына сенбей, қауіпсіздік ережелері қосылған маршрутизаторды қажетті жылдамдықта сынаңыз. Резерв күткеннен баяу болса, алдымен шектеуді табыңыз: тариф, радиосигнал, дуплекс, MTU, CPU, кезек және қашықтағы VPN шлюзі әртүрлі түзетуді қажет етеді.

Соңында саясат желінің өзін басқару мүмкіндігін сақтауы тиіс. Әкімші қатынауын, мониторингті, журналдарды және DNS-ті байқамай «маңызы жоқ» трафикке жатқызып, жүктеме кезінде үзіп тастауға болмайды. Оларға шағын кепілденген жолақ қалдырып, инженер жабдыққа тәуелсіз жол арқылы кіре алатынын тексеріңіз. Диагностикалау қажет болмаған кезде ғана жұмыс істейтін резерв қабылдау сынағынан өткен жоқ.

Резервті жұмыс арнасы секілді қызметтендіріңіз

Айлар бойы қолданылмаған WAN байқатпай резерв болудан қалады: шлюз мекенжайы өзгереді, төлем мерзімі өтеді, оператор CPE құрылғысын ауыстырады, NAT ережесі ескі сұлбадан қалып қояды немесе өткізу қабілеті жаңа қолданбаларға жетпейді. Сыртқы мекенжайды автоматты тексеру осы ақаулардың бір бөлігін табады, бірақ нақты өнімділік пен барлық сервистің қолжетімділігін растамайды.

Жоспар бойынша басқарылатын ауысу өткізіп, DNS, VPN, жарияланымдар, тариф шектеулері және маршрут асимметриясы байқалатындай пайдаланушыларды екінші арнада жеткілікті уақыт қалдырыңыз. Мониторинг әр WAN күйін, белсенді default route, кідірісті, жоғалуды, ауысулар санын және әр оқиғаның себебін бөлек көрсетуі тиіс. Пайдаланушылар ештеңе байқамаса да, «резервтеміз» деген ескерту дереу керек, өйткені келесі ақау алаңды сыртқы байланыссыз қалдырады.

Физикалық трассалары бар сұлбаны сақтаңыз. Екі кіріс бір муфтада, бір қалалық магистральде, бір CPE құрылғысында, бір сөреде немесе бір қуат көзінде болса, екі келісімшарт тәуелсіздік бермейді. Операторлардан соңғы миль мен кіру нүктелері туралы сұрап, жауапты қарап шығу және сынау арқылы растаңыз. Техникалық тәуелсіздікті келісімшарттағы логотиптер емес, ақау сынағы дәлелдейді.

Команда әр күйді түсіндіріп, қайталай алатын сұлба дайын деп есептеледі: WAN неге ақаулы деп танылды, қай маршрут жеңді, қандай NAT қолданылды, қай сессиялар үзілді, қолданбалар қалай қалпына келді және қай уақытта кері қайтуға болады. Бұл сұрақтарға маршрутизаторды бір кезде баптаған жалғыз адам ғана жауап берсе, резервтеудің өзінде бір ақау нүктесі бар.