Cisco Catalyst 9500 — кампустық таралған ядроны көшіру

Миграция міндеті және не өзгереді

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

Cisco Catalyst 9500‑ге көшіру кезінде біз ескі орталық коммутаторларды жаңа жұппен алмастырамыз. Бұл жиі аплинк жылдамдықтарының өзгеруін, резервтеу схемасын және шлюз логикасын өзгертуді талап етеді.

Амалдау себептері әртүрлі: ескі ядро өнімділік шегіне жеткен (көп VLAN, маршруттар, Wi‑Fi мен видео трафигі), қажетті функцияларды қолдамайтын болғаны (телеметрия, заманауи протоколдар, қауіпсіз басқарылатын қол жеткізу) немесе техникалық қызмет көрсету тәуекелі артқан. Тағы бір себеп — сенімділік: бір кабель үзілсе немесе бір құрылғы қайта жүктелсе, бүкіл кеңсені тоқтатпау.

Пайдаланушыларға өзгерістер көбінесе тек ауысу сәтінде көрінеді: кейбір желілер қысқа уақытқа шлюзге қол жеткізуді жоғалтуы мүмкін, сессиялар үзіліп, телефония немесе VDI қайта қосылады. Жақсы жоспармен бұл минуттармен есептеледі, сағаттармен емес. Маңыздысы — критикалық сервистер мен өзгерістер терезесін алдын ала келісу.

Бақылауда ұстау қажет негізгі тәуекелдер:

• L2‑циклдар — линктердің қате қосылуы немесе STP мәселелері себеп болуы мүмкін.
• Маршрутизация қателері: қате статикалық маршруттар, IGP конфигурациясы, әртүрлі метрикалар.
• VLAN шлюздерін (SVI) көшіру кезінде дайын DHCP, ARP және қауіпсіздік тәуелділіктерінің болмауы.
• Аплинктердің дистрибуцияға, сервер аймағына немесе провайдерге қате қосылуы (қате порт немесе режим).
• MTU, speed/duplex немесе оптика бойынша сәйкессіздіктер, нәтижесінде жоғалтулар пайда болуы.

Миграцияның мәні — ядро функцияларын Catalyst 9500‑ге солай беру, чтобы адресация мен ережелер болжамды болып қалсын, ал сенімділік жақсарсын — жаңа жасырын сәтсіздік нүктелері пайда болмауы тиіс.

Мақсатты схема: ролдер, L2/L3 шектері және резервтеу

Кампус үшін қарапайым модель жиі жұмыс істейді: екі Catalyst 9500 ядрод ретінде, төменіректе — дистрибуция (агрегация) және қолжетімділік деңгейі. Ядро сегменттер арасындағы маршрутизация, сенімділік пен жылдам транзит үшін жауап береді, порттар «таратуды» өз мойнына алмайды.

Негізгі архитектуралық шешім — L2 қай жерде аяқталып, L3 қай жерде басталатыны. Егер бұрынғыдай үлкен L2‑домендерді ядроның ішіне созсаңыз, онда сол ескі мәселелерді де келесі деңгейге апарасыз: ұзақ STP реконвергенциясы, broadcast‑шум және күрделі тәуелді VLAN‑дар. Көбінесе практикалық шешім — L2‑ны access немесе distribution деңгейінде шектеу және ядроға L3‑линктерді көтеру. Осылайша бір ғимараттағы ақау немесе цикл бүкіл кампусты «жұлып кетпейді».

Миграциядан бұрын базалық шешімдерді бекітіңіз: SVI қай жерде болады (дистрибуцияда немесе ядро), дистрибуция қалай қосылады (екі тәуелсіз линк арқылы L3 point‑to‑point), резервтеу қалай ұйымдастырылған (екі ядро құрылғысы, сөрелер мен қуат бойынша бөлінген), қандай FHRP қолданылатыны (HSRP немесе VRRP, таймерлер бірдей), қандай маршрутизация протоколы таңдалатыны (жиі OSPF, кішкентай жүйелер үшін статика, бірнеше домен және қатал саясат жағдайында BGP).

Мысал: екі ғимарат пен ЦОД үшін әр ғимаратта дистрибуция бар, одан екі 9500‑ге L3‑линктер бар. Пайдаланушы VLAN‑дары локалды қалады, ядро — маршрутизация мен суммарлы префикстерге жауапты. Осылайша ауысу тәуелділіктерді аз қамтиды және өзгерістер терезесі тыныш өтеді.

Дайындық: деректер жинау және ағымды күйді бекіту

Миграция алдында ең бастысы — "жаңа Catalyst 9500‑ді баптау" емес, желінің қазіргі қалай жұмыс істейтінін дәл білу. Көптеген кейінгі ақаулар аппарат моделінен емес, кішкентай тәуелділіктерден туындайды: бір SVI‑де күтпеген DHCP relay, аплинктің ерекше MTU‑сы, ұмытылған ACL принтерге немесе Wi‑Fi контроллерінің ерекшеліктері.

Логиканы инвентаризациядан бастаңыз: VLAN‑дар және олардың тағайындалуы, SVI мен олардың подсетьтері, сегменттердің default gateway‑лері, ACL‑дар (бағытымен), DHCP relay (ip helper‑address), MTU, QoS және multicast (PIM/IGMP, қолданылса). Егер VRF, жеке маршрут кестелері немесе «ерекше» статикалық маршруттар бар болса, оларды бөлек блок ретінде шығарыңыз.

Кейін L3 тәуелділіктерді жинаңыз: кім көрші (файрвол, CE провайдер, DC, Wi‑Fi контроллері, филиал маршрутизаторлары), қандай протоколдар қолданылады (OSPF/BGP/EIGRP немесе статика), таймерлер мен саясаттар. Қай сервис иелері қандай тесттерді растайтынын алдын ала келісу пайдалы: интернет‑қол жетімділік, телефония, есептік жүйелер, Wi‑Fi, серверлерге қол жетімділік.

Окно алдында «физиканы» тексеріңіз: оптика мен жылдамдықтар сай келуі, LACP дұрыстығы (қолданылған жерде), trunk/access режимдері және allowed VLAN тізімі.

Минималды фиксация пакеті "қалай болды":

• Барлық әсер ететін құрылғылардың конфигурацияларының бэкапы және ағымдағы ПО нұсқаларының жазбасы.
• Күйдің шоты: маршрут кестелері, көршілік (L2 және L3), порттар мен агрегаттардың күйі.
• Маңызды интерфейстер тізімі және олардың қайда кететіні (порт, құрылғы, иесінің контакты).
• Байланыс жоспары: окно кезінде кім байланыста, кім сервисті қабылдайды, кім «ок/не ок» береді.
• Бастапқы сәттілік критерийлері: ауысқаннан кейін алғашқы 10–15 минутта не жұмыс істеуі тиіс.

Егер бұл мемлекеттік орган немесе университет болса, қабылдау процесін алдын ала келісіңіз: желі инженерлері маршруттау мен көршілікті тексереді, ИБ қызметі — трафиктің FW арқылы өтуін тексереді, қосымша командалар өз сервистерін қысқа чеклист бойынша тексереді.

Өзгерістер терезесі: қалай жоспарлап, бақылауды жоғалтпау

Өзгерістер терезесі қысқа, басқарылатын және анық тоқтау нүктелері бар болуы керек. Принцип бір: әр қадам сайын немесе сенімді түрде жалғастырасыз, немесе тез түрде қайтып ораласыз — «не бұзылғанын болжауға» тырыспайсыз.

Уақыт пен ұзақтығын қалай таңдау қажет

Кәсіптік жүктеме ең аз болатын кезеңді және резервті айналымның қолжетімді болуын таңдаңыз: кезекші инженер, критикалық жүйелер әкімшісі (телефония, Wi‑Fi, есеп жүйелері) және серверлік бөлмеге қол жеткізе алатын адам. Ұзақтығы үшін запас қалдырған дұрыс, бірақ ішкі қадамдарды 10–20 минутқа бөліп, тексерулер жүргізіңіз.

Окно алдында бір арнада байланыс пен орындау әрекеттерін тіркеу ережесін келісіңіз: кім, қандай уақытта командаларды орындады немесе кабельді ауыстырды. Бұл откатты айтарлықтай жеңілдетеді.

Рольдер мен бақылау нүктелері

Окно үшін минималды ролдер матрицасы:

• Өзгерістер орындаушысы: командаларды енгізеді, коммутацияны орындайды.
• Бақылаушы: мониторинг, логтар және пайдаланушылардан келетін хабарламаларды бақылайды.
• Сервистер жауаптысы: критикалық қолданбалардың жұмысын растайды.
• Шешім қабылдаушы: кезеңдерді жалғастыру туралы go/no‑go береді.

Ауыстырудан бұрын «құрал‑жабдықты» дайындаңыз: қол қойылған патчкордтар, қосымша SFP, жұмыс істейтін консольдік доступ (міндетті түрде екі тәуелсіз нұсқа), қуат және бос порттар. Қате трансивер сияқты ұсақ нәрсе терезенің жартысын оңай жеп қояды.

Go/no‑go нүктелерін алдын ала жазып қойыңыз. Мысалы, жалғастырасыз, егер екі ядро коммутаторына консольдік доступ бар, аплинктер көрініп тұр, негізгі шлюздер мен критикалық серверлерге жетімділік расталған, L2‑петля белгілері жоқ және откат командасы мен физикалық кабель схемасы анық болса.

Catalyst 9500‑ні продқа шығармастан бұрын алдын ала баптау

Көп конфигурацияны алдын ала дайындау жақсы, бірақ жаңа ядро окноға дейін желіге әсер етпеуі керек.

Басқарудан бастаңыз: management VRF немесе жеке mgmt VLAN, AAA (қолданылса), NTP, syslog және SNMP. Логтардың қажетті серверге кетіп жатқанын, уақыттың синхронизацияланғанын және SSH‑ға қолжетімділіктің нақты адрес тізімімен шектелгенін тексеріңіз.

Келесі қадам — VLAN және SVI дайындау. SVI‑дегі IP‑адрестерді әдетте сол күйінде тасимыз, ACL мен саясаттарды оқылатын күйге келтіріңіз: бірдей атаулар, түсінікті логика, нақты комментарийлер. Ережелер тым күрделі болса, қайталанатындарды жоюға болады, бірақ «шығармашылық» өзгерістерсіз: үйлесімділік үшін қажет бөліктерді ғана өзгертіңіз.

Аплинктер мен негізгі түйіндер үшін алдын ала LACP Port‑Channel жасаңыз. Нөмірлері, LACP режимі және VLAN жиынтығы дистрибуция жағындағы күткендерге сәйкес келуі тиіс. Қауіпсіз тәжірибе: физикалық порттарды көтеріп, Port‑Channel‑ды окноға дейін өшіріп қою.

Маршрутизация мен көршіліктерді де алдын ала дайындауға болады: OSPF/BGP процестерін, желілер мен саясаттарды конфигурациялау, бірақ интерфейстерді shutdown күйінде ұстап немесе прод‑префикстерді жарияламаңыз, жаңа жолдар уақытынан бұрын пайда болмас үшін.

Окно алдында STP режимі (PVST/RPVST/MST) және root преференцияларын, PortFast және BPDU Guard‑ты access‑та, UDLD‑ны оптикада (қолданылса), L3‑линктердегі MTU сәйкестігін, speed/duplex және транк параметрлерінің сәйкес болуын тағы бір тексеріңіз.

Ауыстыру тәртібі: қадамдық сценарий

Максималды бақылау беретін сценарий: алдымен желінің тұрақтылығын растаймыз, жаңа ядроны параллель қосамыз, тек кейін ролдерді және трафикті ауыстырамыз.

Ауыстырудан бұрын ескі ядро мен дистрибуцияда предчект жүргізіңіз: аплинктер up/up, CRC/input errors саны өсіп тұрған жоқ; MAC және ARP кестелері күткендей толтырылған; STP жиі қайта есептемейді; маршрутизация көршіліктері (OSPF/EIGRP/BGP) қалыпты. Егер желі бұрыннан тұрақсыз болса, окно проблемалар жүктемесіне тез айналады.

Ыңғайлы тәртіп:

1. Жаңа аплинктерді Catalyst 9500‑ге параллель қосып, шлюздер мен маршрутизацияны өзгертпеңіз. Порттар көтерілгенін, EtherChannel жинақталғанын және күтпеген STP блокталулар жоқтығын тексеріңіз.

2. Дистрибуция аплинктерін кішкене порциялармен (ғимарат бойынша, шкаф бойынша немесе коммутатор жұбымен) жаңа ядроға ауыстырыңыз. Әр «мини‑толқыннан» кейін негізгі сервистердің қолжетімділігін (AD/DNS, телефония, Wi‑Fi контроллерлері) тексеріңіз — қатер аймағы шағын болсын.

3. L2‑топология тұрақтанғаннан кейін L3‑рольді аударыңыз: HSRP/VRRP активін ауыстыру (приоритеттер, preempt) және жаңа ядроға қажетті SVI‑ларды қосу. Мүмкін болса, бұл VLAN‑дар бойынша топтап орындалсын және бірден негізгі маршрут пен суммарды бақылап отырыңыз.

4. Желінің конвергенцияға уақыт беруіне мүмкіндік беріңіз және трафиктің шын мәнінде жаңа ядро арқылы жүріп жатқанын тексеріңіз: асимметрия жоқ, трафик күтпеген түрде ескі байлаулар арқылы оралмайды, кешігулер өспеген.

5. Нәтижені бекітіңіз: конфигурацияларды сақтаңыз, статус пен счетчиктерді алыңыз, негізгі ауысулардың нақты уақытын белгілеңіз.

Тұрақтандыру кезінде қарапайым метрикаларға көңіл бөліңіз: интерфейстердегі қателер мен дроптар, CPU/жад жүктемесі, STP өзгерістер саны, маршрут көршілерінің күйі және пайдаланушылардан келетін шағымдар (офис, Wi‑Fi, телефония). Егер нашарлау белгілі бір қадамнан кейін басталса, соңғы тұрақты күйлерге оралыңыз, ортасында «тірнектеп түзетуге» тырыспаңыз.

Откат жоспары: авария деп нені санаймыз және қалай қайтамыз

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

Авария деп нені санаймыз (триггерлер)

Откат әдетте нақты жұмысты бұзатын белгілер шықса іске қосылады:

• критикалық сервистер қолжетімсіз (AD/DNS, телефония, негізгі жүйелерге қол жеткізу);
• маршрутизация «плавает»: көршілер құлайды, префикстер жоғалады немесе үнемі өзгереді;
• L2‑петля белгілері: broadcast/unknown unicast күрт өсуі, коммутаторларда CPU‑ның көтерілуі, порттарда «шторм»;
• кең көлемді жоғалтулар немесе үлкен кешігулер негізгі бағыттарда;
• басқаруды жоғалту: желі арқылы қатынау жоқ және тұрақты OOB‑жол да жоқ.

Алдын ала уақыт шектерін белгілеңіз. Мысалы: егер ғимараттар арасындағы байланыс 10 минут ішінде қалпына келмесе немесе телефония істемесе — команда откатқа көшеді.

Ең қарапайым және жылдам откат

Ең сенімді тәсіл — трафикті ескі ядроға сол физикалық жолмен қайтару: аплинктерді/транктарды бұрынғы құрылғыларға кері қосып, шлюз ролдерін қалпына келтіру (FHRP приоритеттері, STP root, маршрут метрикалары).

Окно алдында консольдік доступты жаңа және ескі ядроға (және негізгі дистрибуцияға) ұстап тұрыңыз, порттары белгіленген кабель схемасын, сақталған конфигурацияларды және ауысудан бұрын алынған show‑выводтарын қолда ұстаңыз.

Откатты қауіпсіз орындаңыз: бір блок әрекеттеп, қысқа тексеру жүргізіңіз — байланысты қалпына келтіру және протоколдар күйін растаңыз. Сервис қалпына келтірілгеннен кейін не өзгертілгенін, қандай симптомдар пайда болғанын, қай қадамда және қандай счетчиктер/логтар бұлны растайтынын тіркеп қойыңыз.

Типтік тұзақтар және ядро миграциясындағы қателер

Жаңа коммутатордағы конфиг "ескісі сияқты" көрінуі мүмкін, бірақ проблемалар көбіне стыктарда шығады: L2 мен L3 қай жерде кездеседі, агрегация жасалатын жерлер және күтпеген қауіпсіздік саясаттары.

L2: trunk және STP

Ең жиі кездесетін қате — транктегі allowed VLAN тізімінің қате болуы. Нәтижесінде сегменттер ғана бір бөлігіне «жоғалады». Тағы бір жиі себеп — native VLAN‑дың сәйкес еместігі: трафик әртүрлі түрде маркіленіп, циклдер немесе «жыртылатын» симптомдар пайда болады.

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

L3 және қауіпсіздік: бір ереже ұмыту — басқаруды жоғалту

L3 деңгейінде жиі ұмытылады: басқару, мониторинг, OOB немесе сервистік подсектерге статикалық маршруттар. Қате next‑hop көрсету де жиі себеп болады. Тағы бір қауіп — SVI‑ларда IP қайталануы: ескі және жаңа шлюз қысқа уақыт бір VLAN‑де белсендірек болса, ARP «қозғалып» сессиялар үзіледі.

ACL‑мен де сол сияқты: ережені қате интерфейске немесе қате бағытта қолдану — және сіз өзіңізді SSH/SNMP‑дан немесе лог жинаудан қол үзіп қалдыруыңыз мүмкін. Типтік симптом: "пингтер өтеді, бірақ мониторинг қалмады".

Агрегациялар және ұйымдастыру жұмыстары

Port‑Channel‑дағы қателер қарапайым, бірақ жағымсыз: LACP режимдері әр түрлі, Port‑Channel параметрлері сәйкес емес, жылдамдықтар әр түрлі. Нәтижесінде линк физикалық қосылған сияқты, бірақ трафик бір порт арқылы ғана немесе мүлде өткізілмейді.

"Кімнің кінәлі екенін" таласып отырмай, алдын ала go/no‑go критерийлерін белгілеп, бір жауапты қабылдаушы мен откат иесін анықтаңыз.

Практикадан мысал: бір ғимаратта Wi‑Fi жоғалып кетті. Себеп — WLC‑ға жүретін транкте қажет VLAN allowed тізіміне түспеген. Мұндай жағдайлар алдын ала тексерулер мен анық жауапты тұлғалар болғанда минуттар ішінде шешіледі.

Ауыстырудан кейінгі чеклист: 10–15 минут ішінде жылдам тексерістер

Трафикті жаңа ядроға ауыстырғаннан кейін екі нәрсені жылдам түсініңіз: желі тірі және күткендей жұмыс істейді.

1) «Темір» және базалық күйді тексеру

ПО нұсқасы мен аптаймды тексеріңіз (күтпеген перезагрузка болмауы үшін), температура мен қуатты, CPU/жад жүктемесін. Егер логикалық резервтеу (мысалы, StackWise Virtual) қолданылса, актив/резерв рөлдері жоспарға сай екеніне көз жеткізіңіз.

Содан кейін дистрибуцияға аплинктерді қарап шығыңыз: интерфейстер up, CRC/қателер немесе discard‑тар өспеуі керек. Input errors/CRC өсуі немесе «жылдам өзгеретін» жылдамдық көбіне оптика/патчкорд немесе тезегу сәйкессіздігін көрсетеді.

2) L2/L3 және сервистер

Spanning Tree дұрыс root таңдағанына және критикалық байланыстарда күтпеген blocked порттар жоқтығына көз жеткізіңіз. MAC кестесінің транктарда дұрыс үйреніп жатқанын тексеріңіз.

L3 жағынан: маршрут кестесінде күткен префикстер бар ма, көршіліктер FULL/ESTABLISHED күйінде ме, HSRP/VRRP рөлдері жоспарға сай ма — тексеріңіз. ARP‑та көп incomplete жазбалар немесе шлюзтің MAC‑ының жиі ауысуы цикл немесе IP қайталану белгісі болуы мүмкін.

Финалдық тексеріс үшін 3–5 бақылау сервисін түрлі сегменттен тексеріңіз: DNS, AD/LDAP, телефония, Wi‑Fi контроллері/шлюз, негізгі қолданба (мысалы, ERP). Логтарды қарап, критикалық хабарламалардың жоқтығын, құрылғылардың мониторингке пайда болғанын және интерфейс графиктерінің жаңарып жатқанын растаңыз.

Тексеру командалары жинағы: не көру керек және норма қандай

Ауыстырудан кейін физика мен логиканың дұрыс екенін тез растау маңызды: порттар, оптика, қателер және агрегациялар, STP, маршрутизация, шлюздер.

Жылдам командалар жинағы

! Порты, ошибки, оптика
show interfaces status
show interfaces counters errors
show interface transceiver detail

! LACP и EtherChannel
show etherchannel summary
show lacp neighbor

! STP
show spanning-tree summary
show spanning-tree vlan \u003cX\u003e

! L3 и таблицы
show ip interface brief
show ip route
show arp
show ip ospf neighbor
! или, если у вас BGP
show ip bgp summary

! Шлюзы первого хопа (выберите свой протокол)
show standby brief
show vrrp brief

! Быстрый траблшутинг
ping \u003cIP\u003e source \u003cSOURCE_IP\u003e
traceroute \u003cIP\u003e source \u003cSOURCE_IP\u003e
show logging | include (UPDOWN|LINEPROTO|SPANTREE|LACP|HSRP|VRRP|OSPF|BGP)

Ескерту: блок коды ішіндегі командалар өзгертілмеді.

Нормаль деп нені санау керек

Интерфейстер бойынша: қажетті аплинктер up/up, жылдамдық пен дуплекс күткендей, errors/CRC/input‑output drops өсіспеуі керек. Оптика бойынша: Rx/Tx деңгейлері қалыпты және модуль туралы қате хабарламалар жоқ.

LACP: EtherChannel жұмыс күйінде (P), individual (I) немесе suspended (s) болмауы тиіс. show lacp neighbor барлық канал мүшелерінде көрініп тұруы керек.

STP: топология тұрақты, topology change‑тар жиі емес, root күткен болып табылады, критикалық порттар forwarding режимінде.

L3: SVI немесе routed порттар көтерілген, default маршрут пен маңызды желілер show ip route‑та бар, ARP белсенді сегменттер үшін толтырылған. OSPF/BGP үшін көршіліктер FULL/Established күйінде және флаптар жоқ.

HSRP/VRRP: актив/резерв ролдері жоспарға сай. Source‑пен показатель пингтер критикалық подсеттерге өтсе, маршруттау мен қайтарымды жол дұрыс екенін растайды.

Кампусқа арналған мысал сценарий: қадамдар бойынша қалай көрінеді

Шарттар: екі ғимарат (А және Б), әрқайсысында 3 access коммутатор, бөлек серверлік бөлме және ескі ядро екі коммутаторда. Мақсат — Catalyst 9500‑ге таралған ядро ретінде ауысу, толық тоқтаусыз, басқаруды сақтай отырып және анық откатпен.

Тәуекелді азайту үшін миграция кезеңдерге бөлінеді және бәрін бірден қозғауға болмайды. Көбіне демалыс күндері немесе қысқа түнгі терезелер ыңғайлы:

• Этап 1: ғимарат А (access‑аплинктерді жаңа ядроға көшіру, пайдаланушыларды тексеру).
• Этап 2: ғимарат Б (сол сценарий және мінез‑құбылысты салыстыру).
• Этап 3: сервер бөлмесі (серверлік коммутаторлардың агрегациясын және маңызды L3‑шлюздерді көшіру).
• Этап 4: тазалық (ескі қосылымдарды өшіру, маршрутизацияны теңестіру, финалдық тексеріс).

Әр кезеңде тексерісті тек желі инженерлері ғана емес, бизнес те жүргізгені маңызды. Бизнеске қысқа тексеріс тізімі жеткілікті: почтаны ашып көру (браузер және клиент), ERP‑ке кіру, тест қоңырау (IP‑телефония), тестілік печать, Wi‑Fi‑ға қосылу және авторизациядан өту.

Ауыстырудан кейін алғашқы 24 сағатта бірқатар метрикаларды бақылау пайдалы: порттардағы қателердің көбеюі, линк флаптары, ядро жүктемесі, линк қайта қосылған соң қатынаудың қалпына келуі уақыты.

Миграция аяқталған деп есептеледі, егер екі жұмыс күні ішінде қайталанатын оқиғалар болмаса және барлық критикалық сервистер тексеруден сәтті өткен болса. Содан кейін не өзгертілгенін тіркейді: финалдық L2/L3 схемасы, порттар мен VLAN тізімі, маршрутизация, ПО нұсқалары және бизнестің қабылдауын растайтын тұлғалар мен уақыты.

Миграциядан кейін не істеу: нәтижені бекіту және әрі қарай жоспарлау

Ауыстырудан кейін "барлығы жұмыс істейді" деп айту жеткіліксіз — жаңа күйді құжаттап алу маңызды. Аптадан кейін детальдар ұмытылып, уақытша шешім тұрақтыға айналуы мүмкін.

Финалдық схема мен фактілерді бекіту

As‑built пакетті жинаңыз. Жақсы минимум:

• жаңартылған логикалық схема (ядро, дистрибуция, L2/L3 шектері, резервтеу);
• порттар кестесі: әр аплинк неге қосылған, қай порт Port‑Channel құрамында, жылдамдықтар мен трансиверлер;
• VLAN мен SVI тізімі, ағымдағы IP‑подсеттер мен шлюздер, қай жерде DHCP relay қосылған және қандай ACL қолданылған;
• конфигурациялардың соңғы нұсқалары мен бэкаптары, өзгеріс терезесінің күні мен нөмірімен;
• «норма» көрсеткіштері: кешігу, жоғалтулар, линк жүктемесі, CPU/жад, маршруттар мен көршіліктер саны.

Мысал: егер бір корпустың жұмысы ауысқаннан кейін "кейде бар, кейде жоқ" болса, жиі себебі — аплинк физикалық түрде басқа портқа ауыстырылған және порт кестесі жаңартылмаған.

Тексеру рәсімін стандарттау

Кез келген өзгерістен кейін қайталанатын қысқа регламент жасаңыз: қандай командаларды қараймыз, қандай счетчиктер алаңдатады, кім нәтижені растайды және тексерудің логтары қайда сақталады.

Донастройкаларды бөлек кіші терезелерге қалдырыңыз: сегментацияны жақсарту, қолданылмайтын VLAN‑дарды тазалау, trunk allowed VLAN‑ды нақты қажеттілікке келтіру, оповещения мен мониторинг дашбордтарын баптау. Егер мониторинг жаңартылмаса, ол ескі ядро туралы ескертеді және жаңа проблемаларды байқамай қалуы мүмкін.

Сондай‑ақ 1–3 жылға арналған ресурс қоры мен жоспарды бағалаңыз: аплинктердің өткізу қабілеті, маршрут кестелерінің өсуі, жаңа ғимараттарға және сервистерге дайындық, және шекті сәтсіздік сценарийлері (бір линк үзілген, бір ядро құрылғысы істен шыққан, сөре қуатынан айырылу).

Егер миграция күрделі болса, келесі кезеңдер жоспарланса, жүйелік интеграторды тарту орынды: архитектура, жабдық жеткізу, енгізу және қолдау қызметтерін толық жабу үшін. Мысалы, GSE.kz — Қазақстандағы ИТ‑инфрақұрылым жеткізушісі мен интеграторы ретінде жобаны «а»‑дан «я»‑ға дейін жабуға көмектесе алады.