Cisco Catalyst-тен Aruba CX-ке көшу: VLAN, PoE және QoS тасымалдау

Не көшірілуі керек және неге бұл маңызды

Cisco Catalyst-тен Aruba CX-ке көшу көбінесе «құрылғыны ауыстыру» үшін емес. Мақсат қарапайым әрі практикалық: коммутаторларды жаңарту, қолдаудың жүктемесін азайту, жеткізу талаптарын жабу және алдағы жылдарға болжамды желі алу. Миграцияның сәттілігі пайдаланушылар байқамайтын, бірақ жұмыс істейтін нәрсені қаншалықты дәл көшіретініңізге байланысты.

Физикалық қосылымдарды ғана емес, желі логикасын да сақтау маңызды. Алдымен тексерілетіндер:

• VLAN және сегментация (кім кіммен араласады)
• транктар: native VLAN және рұқсат етілген VLAN тізімі
• PoE: жалпы қуат бюджеті, порттардың приоритеттері және шамадан тыс жүктеме кезінде мінез-құлық
• QoS: трафикті белгілеу және дауыс, видео мен маңызды сервистерге приоритет
• басқару параметрлері: басқаруға қатынау, NTP, SNMP/мониторинг, журналдар

Миграцияның сәтті өткенін бизнес белгілерімен бағалау оңай: телефония шулы емес, видеоқоңыраулар «сабырлы» өтеді, принтерлер басады, 1С/CRM қалыпты ашылады, Wi‑Fi нүктелері түсіп қалмайды, және пайдаланушылардан көп хаттамалар көтерілмейді. Жақсы тексеру — тек "ping" емес, ажырамас сервистерді алмастырмас бұрын және кейін салыстыру.

Көбінесе ақаулар ұсақ нәрселерден болады, оларды өткізіп жіберу оңай:

• транкта native VLAN шатастырылды да, кейбір құрылғылар басқа сегментке шықты
• PoE бюджетін есептемеді, және AP немесе телефондар қайта жүктеліп кетті
• VLAN көшірілді, бірақ ACL/саясаттар ұмытылды, сервистер қол жетімсіз болды
• QoS тексерілмеді, дауыс/видео жалпы кезекке түсті
• откат жоспары дайын емес, қалпына келтіру ұзаққа созылды

Мысал: кеңседе access коммутаторын ауыстырғанда. Егер PoE қосулы болса, бірақ приоритеттер белгіленбеген болса, шыңды тұтыну кезінде бірінші «түтіні» конференц-зал телефондары болуы мүмкін. Сондықтан маңызды порттар мен олардың қуатын алдын ала бекітіп, ауыстырғаннан кейін дереу тексерген жөн.

Миграцияға дейін инвентаризация: бір күнде не жинау керек

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

Алдымен қарапайымдан бастаңыз: дәл қазіргі орнатылған нәрселерді және олардың қалай жұмыс істейтінін тіркеңіз. Мұнда дәлдік әдеміліктен маңызды.

Міндетті жинақ (минимум)

• Жабдық және ПО: коммутатор модельдері, firmware нұсқалары, модульдер, лицензиялар, трансивер түрлері және қайда орнатылғаны.
• Порт картасы: қай порттар аплинк, қайсысы транк, қайсысы access, қандай LAG/Port-Channel құрылып, қандай интерфейстер оларға кіретіні.
• VLAN кестесі: ID мен атауы, қайда қолданылады (кабинеттер, қабаттар, сервистер), әр транкта қандай native VLAN орнатылған.
• PoE шолуы: қандай құрылғылар қуат алады (телефондар, Wi‑Fi нүктелері, камералар), олардың шамамен тұтынуы және қай нүктелер критикалық (ресепшн, кассалар, қауіпсіздік).
• QoS және тәуелділіктер: не приоритеттеледі (дауыс, видео, VDI/терминалдар, медициналық жүйелер), сондай‑ақ сыртқы сервистер: DHCP, DNS, AAA/RADIUS, NTP, телефония, Wi‑Fi контроллері, бейнебақылау.

Уақытқа сыйдыру үшін жинауды «конфигурациядан шығару» және «көзімен тексеру» деп бөліңіз. Шығару әдетте картинаның 80% береді, ал қолмен тексеру ұсақ бірақ ауыр зардапты нәрселерден сақтайды: ескерілмеген транк немесе шегінде қуат беріліп тұрған камера.

Мысал: аплинкте Port‑Channel қосылған, бірақ құжаттарда ол жай trunk ретінде жазылған. Егер бұл алдын ала байқалмаса, коммутаторды ауыстырғаннан кейін кейбір VLAN өтуі мүмкін, және бірінші болып дауыс немесе Wi‑Fi құлады.

Күннің соңында бір файлда құрылғылар тізімі, бір VLAN кестесі, бір порт схемасы және PoE мен QoS пріоритеттерін бөлек жазба болуы керек. Бұл әрі қарай параметрлерді есте сақтап емес, саналы түрде көшіруге жеткілікті.

Cisco ұғымдарын Aruba CX‑қа аудару — артық теориясыз

Миграцияда командаларға емес, мақсатқа қарай ойлаған жеңілірек: порт не істейді, аплинк қайда апарады, қандай VLAN өтуі тиіс, қандай сервистер критикалық. Сонда Cisco Catalyst пен Aruba CX арасындағы айырмашылықтар «терминдерді аудару» сияқты, жаңа әлемді меңгеру емес.

Желідегі рөлдер әдетте сақталады: access (пайдаланушылар мен телефондар), distribution (қабаттарды немесе аймақтарды агрегаттау), core (магистраль), edge (провайдерге, firewall‑ларға шығу). Aruba CX‑та сол деңгейлер құрылады, бірақ көбіне порт профилдері мен шаблондарға ұмтылады.

Пайдалы сәйкестіктер:

• Port‑Channel (Cisco) = LAG (Aruba CX). Логика сол: порттарды біріктіру, LACP және барлық қатысушыларда бірдей баптаулар.
• Trunk (Cisco) = Aruba CX‑та tagged VLAN портында. Access VLAN = untagged VLAN.
• Native VLAN (Cisco) = транктегі untagged VLAN Aruba CX‑та. Мұнда «жұмбақ» қателер жиі шығады.
• CDP (Cisco) жиі LLDP‑пен ауысады. Егер желіде телефондар немесе AP болса, LLDP қосылып, қажетті өрістер жіберіліп жатқанына көз жеткізіңіз.
• STP/RSTP/MST екеуінде де бар. Ақпараттан гөрі режим мен root‑приоритеттердің сәйкестігі маңызды.

VLAN және транктар бойынша басты нюанс — Aruba CX‑та tagged пен untagged‑ты айқын бөледі. Көшіру кезінде аплинктарда қандай VLAN‑дар tagged болатынын, қай VLAN untagged болатынын жеке жазып, Cisco‑да әдетте рұқсат етілген «қызметтік» VLAN‑дарды қарастыруды ұмытпаңыз.

ACL мен саясаттарды порт деңгейінде, SVI (VLAN интерфейсінде) немесе аплинкта қолданылған жерін тексеріңіз:

• фильтр қай интерфейсте жұмыс істегені (in/out)
• ережелер реті (бірінші табыс сәйкес келеді)
• DHCP, DNS және телефонияға арналған ерекшеліктер
• журналдау (бар болса), оны құрылғыны шамадан тыс жүктемеу үшін реттеңіз

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

Миграция бойынша кезең-кезең жоспар: дайындау, ауыстыру, откат

Көп ақаулар — бәрін түнде "жерінде" баптауға тырысу нәтижесі. Сенімді тәсіл — мақсатты конфигурацияны алдын ала жинап, тест құрылғысында (немесе бөлек оқшауланған жерде) тексеріп барып, сосын өндірістік ауысуға шығу.

Дайындау

Инвентаризацияға сай Aruba CX үшін жобалық конфигурация жасаңыз: қандай VLAN‑дар, аплинктар қайда, қандай LAG, қай порттар телефондар мен AP‑ларды қуаттайды, қайсысына QoS керек. Алдын ала қай саясаттар және терминдер өзгеретінін белгілеп қойыңыз, сонда апат кезінде сәйкестікті іздемейсіз.

Одан кейін басқару базасын баптаңыз: жеке management‑қатынау (немесе mgmt VLAN), есептік жазбалар мен рөлдер, NTP, syslog, SNMP. Сонымен бірге "үй шаруасы": баннер, конфигурацияның сақтық көшірмесі, интерфейстерге түсінікті аттар. Бұл ауыстырғаннан кейін симптомдарды тез анықтауға уақыт үнемдейді.

Практикалық жұмыс тәртібі:

• Басқару және қатынау үшін базалық конфигурация жүктеңіз.
• L2-ні көтеріңіз: VLAN, транктар, native VLAN, LAG және коммутаторлар арасындағы байланысты тексеріңіз.
• Аплинктерді біреу-біреуінен ауыстырыңыз, қай кабель қайда қосылғанын жазып отырыңыз.
• PoE‑ны кезең-кезеңімен қосыңыз: алдымен критикалық құрылғылар (телефондар, AP, камералар), содан кейін қалғандары.
• QoS‑ты көшіріп, дауыс пен видеоны тек «дзвін» емес, нақты жүктеме жағдайында тексеріңіз.

Ауыстыру және откат

Жұмыс терезесі әдетте жұмыстан тыс уақытта жоспарланады. Дегенмен сапаны тексеруді (әсіресе телефонияны) шұғыл сағаттарда қайталау пайдалы, себебі кезектер мен буферлер сол уақытта өзгеше әрекет етеді.

Откат жоспары жұмысты бастамас бұрын дайын болуы керек және 5‑10 минут ішінде жүзеге асырылатын болуы тиіс. Минимум чек‑тізім:

• Ескі және жаңа құрылғылардың сақталған конфигурациялары (күні мен нұсқасымен).
• Порттар мен кабельдердің тізімі: не қайда қосулы және не ауыстырылды.
• Тоқтату шегі: қандай симптомдар критикалық саналады (VLAN‑дар арасында байланыс жоқ, телефондар жоғалған, PoE бюджеті жетпейді).
• Жылдам қайтару: аплинкті Cisco‑ға қайтару, проблемалы LAG‑ты өшіру немесе уақытша QoS саясатынан алып тастау.

VLAN көшіру: транктар, native VLAN және типтік нюанстар

Көбінесе бұзылатын нәрсе — VLAN нөмірі емес, оның транкте қалай өтіп жатқаны: қай VLAN‑дар рұқсат етілген, қайсысы native (нетегирленген), және қай жерде tagged пен untagged шатастырылған. Алдымен сәйкестік кестесін жасаңыз: VLAN ID, атауы, қолданылатын жері (access порттар, транктар, L3 SVI) және ішіндегі сервистер (DHCP, телефония, Wi‑Fi, принтерлер).

Транктар және native VLAN: жиі қателесетін жерлер

Cisco‑да trunk + allowed VLAN + native VLAN дегенге үйреніп қалғансыз. Aruba CX‑та логика ұқсас, алайда терминология өзгеше: транктегі VLAN tagged болуы мүмкін, ал бір VLAN untagged болуы мүмкін (яғни native эквиваленті). Негізгі ереже: untagged VLAN екі шетінде де сәйкес болуы керек, әйтпесе кейбір құрылғылар ешқандай қате хабарламасыз «жоғалады».

Әр транкты бөлек тексеріңіз. "Барлық VLAN‑дарды рұқсат ету" уақытша ыңғайлы көрінсе де, кең таралған себебі — broadcast ағымдарының ағып кетуі және желіде күтпеген ілмектер. Белгілі бір сілтемеге нақты қажетті VLAN‑дарды білу жақсырақ.

Басқару VLAN және L3 баптаулары

Егер басқару коммутаторларға арналған бөлек VLAN болса, оны бөлек белгілеңіз және қолжетімділікті шектеңіз: оны әр edge‑портқа таратпаңыз және әдепкі бойынша untagged қылмаңыз. Солай басқарудың дұрыс емес сегментке ашылу ықтималдығы төмендейді.

Егер VLAN‑дар маршрутизациясы L3 құрылғыда орындалса, DHCP relay (helper) туралы ұмытпаңыз. SVI‑ды Aruba CX‑қа көшіргеннен кейін клиенттер линкті көрсе де, IP ала алмауы мүмкін.

Ключтік VLAN‑дарға ауыстырғаннан кейін қысқа тексеру жиынтығы:

• Клиент күтілген IP, шлюз және DNS алады ма.
• VLAN шлюзі пингтеледі және ішкі сервис (мысалы, домен контроллері немесе CRM) қол жетімді.
• Бір типтік пайдаланушы сценариін тексеру (IP‑телефоннан қоңырау, басып шығару, Wi‑Fi‑ге кіру).
• Транктарда рұқсат етілген VLAN тізімі мен untagged/native сәйкестігі тексеріледі.

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

PoE миграциясында: қуат бюджеті және приоритеттер

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

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

Содан соң тұтынуды ролдер бойынша бөліңіз. IP‑телефондар әдетте аз энергия алады және әрқашан қосылуы тиіс. AP‑тар айтарлықтай көп тұтынуы мүмкін (арнайы Wi‑Fi 6/6E және USB қосылғанда). Камералар орташа тұтынады, ал панельдер мен терминалдар іске қосылған кезде шыңдықтарды береді. Егер кейбір құрылғылар PoE+ немесе одан жоғары талап етсе, порт пен коммутатордың оны қолдайтынына көз жеткізіңіз.

Критикалық порттар үшін PoE приоритеттерін орнатыңыз. Логика қарапайым: алғашқы кезекте байланыс, ал қалғаны кейін. Егер бюджет асып кетсе, маңызды емес құрылғылар қуаттан айырылсын, телефондар мен негізгі Wi‑Fi сақталсын.

Ауыстыру алдындағы қысқа чек:

• Aruba CX‑тың жалпы PoE бюджетін және порттар бойынша нақты жүктемені салыстырыңыз.
• Порттар режимдерін тексеріңіз: auto, enable, disable және порт бойынша қуат лимиттері.
• Телефондар, магистральдық AP және критикалық камералар үшін PoE приоритеттерін тағайындаңыз.
• Қандай құрылғылар PoE+ қажет етеді және қайсысы кәдімгі режимде істей алатынын анықтаңыз.
• Коммутаторлар мен қуаттың UPS арқылы қорғалғанын тексеріңіз.

Қосу жоспарын кезең-кезеңімен жасаңыз. Мысалы: алдымен коммутаторды қосып, тек телефондарды қосыңыз, одан кейін Wi‑Fi, сосын камералар мен қалғандары. Бұл бірдей уақытта іске қосылған бастапқы шыңды болдырмайды, ол формальды түрде бюджет жеткілікті болғанына қарамастан қуатты құлата алады.

Мысал: бір коммутаторда 24 телефон, 6 AP және 8 камера. Барлығын бірден қосса, AP‑тар максимум сұрауы мүмкін және резервті жұта алады. Кезең-кезеңімен қосу және дұрыс приоритеттер арқылы критикалық сервистер бірінші көтеріледі, қалған порттар лимиттер арқылы реттеледі.

Егер миграция ауқымды болса, алдын ала бюджетке резерв қалдырып, қандай порттарды шектеуге болатынын келісіп алыңыз.

QoS көшіру: маркерлеу, кезектер және сапаны тексеру

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

Көбінде ақау «приоритетті орнатудың өзі емес», ал оның қай жерде және қалай қойылғаны: маркерлеу қайда орнатылады, сенім шекарасы қайсы, қандай кезектер нағыз қатты жүктеледі. Алдымен қолданыстағы модельді анықтаңыз: қандай DSCP мен CoS қолданылып, қай порттарда пайда болады.

Не жинап, қалай сәйкестендіру керек

QoS‑тың қысқа инвентаризациясы бақылаулы көшіру үшін:

• Қай трафик класстары критикалы (мысалы, SIP/RTP, Teams/Zoom, VDI, медициналық трафик).
• Маркерлеу қай жерде қойылады: телефонда, AP‑та, ПК‑де, access‑портта немесе uplink‑та.
• Қолданылатын мәндер: DSCP (мысалы EF/AF) және транктардағы CoS, және қай жерде қайта белгінің жазылатыны.
• Қай интерфейстер тар тұтқын болғаны: uplink, коммутаторлар арасындағы сілтемелер, ядроға шығу.
• Uplink‑та жылдамдық шектеулері немесе шейпинг бар ма және қай кластарға арналған.

Сосын бұл логиканы Aruba CX‑пен сәйкестендіріңіз: мақсат — команданы қайталау емес, кезектердің бірдей мінез-құлқын (дауыс үшін приоритетті кезек, интерактивті трафик үшін болжамды кідіріс және басқа трафиктің аштан қалмауы) қамтамасыз ету.

Айрықша тексеріңіз «сенім шекарасы». Типтік қате: жұмыс станциясынан маркерлеуге сену, сонда біреу жүктеп алу трафигін «дауыс» деп белгілеп қоятын болуы мүмкін. Көбінесе телефондар мен AP‑тарға сеніп, қалғаны үшін портта ережелермен маркерлеу қауіпсіз.

Көшіруден кейін сапаны тексеру

Тесттерді алдын ала дайындап, ауыстырудан бұрын және кейін қайталап алыңыз:

• Бір дауыс қоңырау: робот тәрізді бұзылу және айқын кідіріссіз.
• Қоңырауды канал жүктемесімен қатар жасау (файл көшіру): дауыс нашарламауы тиіс.
• Пик сағаттардағы видеоконференция.
• VDI немесе маңызды қосымшаның жауап беруін тексеру.
• Uplink‑тағы кезек есептері мен drop‑тарды салыстыру, мәселе қай жерден басталатынын көру.

Егер желіде телефония мен видео болса, күтілетін метрикаларды (кідіріс, жою, jitter) бекітіп, қабылдауды сол бойынша өткізіңіз, ал конфигурацияның ұқсастығына емес.

Сервистерге бақылау тізімі: ауыстырғанға дейін және кейін жылдам тексерулер

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

Ауыстырудан бұрын ағымдағы күйді тіркеп, откат дайындаңыз. Бұл «кішігірім» тәуелділік шыққанда сағаттарды үнемдейді.

• Cisco конфигурацияларын сақтап, негізгі командалар шығуын алыңыз: VLAN, транктар, PoE, QoS, MAC кестелері, STP, LACP.
• Критикалық порттарды және олардың не қосылғанын белгілеңіз (аплинктар, AP, телефондар, камералар, серверлер).
• Откат жоспарын дайындаңыз: не, қай тәртіппен қайтарылады, кім жауапты, қанша уақыт бар.
• Әкімшілердің қатынауын тексеріңіз: есептік жазбалар, SSH/консоль қатынасы, management VLAN арқылы жеке қатынас.
• Эталонды тіркеңіз: шлюздер, DNS, негізгі қолданбалар және бірнеше нүктеден бақылау ping‑тер.

Ауыстырғаннан кейін бастапқыда базалық байланысты тексеріп, содан соң пайдаланушы сценарийлеріне көшу керек. Егер бастапқыда loop немесе шторм болса, басқа тексерулер кедергі келтіреді.

• Шлюзтер мен негізгі подсеттердің қолжетімділігін тексеріңіз, broadcast штормдары мен линктердің күтпеген жүктелуін анықтаңыз.
• DHCP мекенжай тағайындауды, DNS жауаптарын, NTP уақытын, домен аутентификациясын (AD/LDAP) тексеріңіз.
• Пайдаланушы сценарийлері бойынша тез өтіңіз: интернет, корпоративті қосымшалар, файлдар және басып шығару.
• Байланыстарды бөлек тексеріңіз: IP‑телефония, Wi‑Fi роуминг, видеоконференциялар және бейнебақылау.
• Мониторинг пен сақтық көшірме жүйелерін қараңыз: метрикалар/траптар келіп жатыр ма, желілік құрылғылардың бэкаптары жоғалмады ма.

Мысал: қолданыстағы құрылғыны ауыстырғаннан кейін бәрі пингіленеді, бірақ телефондар тіркелмейді. Мұндай симптом көбіне VLAN/транк (native VLAN дұрыс емес) немесе PoE приоритеттері мен қуат тапшылығынан болады. Әр шкафта 2–3 бақылау құрылғысын (телефон, ноутбук, камера) ұстап, әрқайсысын бірдей сценарий бойынша тексеріңіз.

Жиі қателер және олардан қалай сақтану

Ең ауыр ақаулар көбінесе «күрделі баптау» емес, ауыстырғаннан кейін ғана көрінетін кішкентай сәйкессіздіктерден шығады.

Типтік жағдай: VLAN‑дар көшірілді, бірақ транктарда "барлық VLAN‑дарды рұқсат ету" қалған. Нәтижесінде көрші сегменттерге қажетсіз трафик ағады, күтпеген DHCP жауаптары пайда болады немесе broadcast жарылыстары шығады. Ереже қарапайым: әр транкта рұқсат етілген VLAN тізімін мінсіз етіп сақтаңыз.

Native VLAN‑ды шатастыру да жиі кездеседі. Бір шетінде untagged бір VLAN болса, ал екінші жағында басқа болса, құрылғылар тошып то қайта пайда болады — себептер көрінбейді. Ауыстырғанға дейін қай VLAN untagged болуы керек екенін салыстырып, екі жағында да дәл бірдей етіңіз.

STP‑ты да төмен бағамаңыз. Root‑приоритеттер мен ролдерді ескермесеңіз, желі қалыптыдан ұзақ құрылады немесе қате патчкордпен петля болуы мүмкін. Алдын ала root қайда болу керектігін анықтап, пайдаланушы порттарда loop‑қа қарсы қорғауды қосыңыз.

PoE‑да көбіне бюджет «ату» жасайды. Стендте бәрі дұрыс болса да, жүктеме кезінде AP немесе камералар қайта жүктеле бастайды. Бұл суммар тұтыну коммутатордың немесе порт топтың қолжетімді PoE‑сынан артық болғанда орын алады.

QoS бойынша қате — маркерлеуге сену. Саясат қосылды, бірақ кіріс кезінде DSCP‑қа сенбеген, немесе дауыс трафигі дұрыс кезекке түспеген. Нәтижесінде қоңырау сапасына шағымдар миграциядан кейін шығады.

Қауіптерді азайту жолы

• Әр транкта рұқсат етілген VLAN тізімін бекітіп, схемамен салыстырыңыз.
• Native VLAN‑ды нақты көрсетіп, untagged трафикті тест хостымен тексеріңіз.
• STP‑root‑ты анықтап, приоритеттерді ауыстырудан бұрын орнатыңыз.
• PoE бюджетін резервпен есептеп, критикалық порттарға приоритеттер қойыңыз.
• QoS‑ты нақты трафикпен тексеріңіз: қоңырау, видео ағым, файл көшіру.

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

Мысал сценарий: офисті тоқтатпай миграциялау

150 қызметкері бар офис: жұмыс орындарында IP‑телефондар, қызметкерлер мен қонақтарға арналған Wi‑Fi, коридорларда камералар, бірнеше принтер және бірнеше шағын сервер. Желіде шамамен 10–15 VLAN бар: пайдаланушылар, телефония, бейнебақылау, Wi‑Fi staff, Wi‑Fi guest, басқару және бірнеше қызметтік сегменттер.

Дайындауды бір жұмыс күніне сыйдыруға болады, егер бәрін мінсіз жинауға тырыспасаңыз. Қарапайым кесте жасалады: порт, не қосылған, қай VLAN, PoE керек пе, арнайы баптаулар бар ма (мысалы, voice VLAN немесе телефонға приоритет). Сол уақытта жұмыс уақыты туралы ескерту жасалады: не уақытша жоғалуы мүмкін және таңертең не істеу керек.

Миграция бөліктермен жүреді, толық қабатты бірден өшірмес үшін. Бірінші кеште тек бірнеше access коммутаторын бір бөлік немесе қабат бойынша ауыстырады. Жаңа Aruba CX‑тарды сол VLAN‑дар, транктар және PoE‑мен көтереді, бірақ аплинкті distribution‑тағы Cisco‑да қалдырады. Одан кейін осы аймақтың аплинкін Aruba‑ға көшіреді және телефондар, AP мен камералардың қалай жұмыс жасайтынын бақылайды. Егер қате болса, откат қарапайым: аплинкті қайта Cisco‑ға қосу.

Ауыстырғаннан кейін тек "интернет бар" ғана емес, нақты жұмыс сценарийлерін тексеріңіз:

• IP‑телефоннан қоңырау (ішкі және сыртқы) және дауыс сапасының бағалануы.
• 5–10 минуттық видеожиналыс бұзылусыз.
• Wi‑Fi‑да бірнеше құрылғы арқылы жүктеу, жылдам роуминг.
• Камера ағымын қарау және жазба.
• Негізгі сервистерге (пошта, 1–2 корпоративті қосымша, басып шығару) қолжетімділік.

Аймақ тұрақты болғанда, сол шаблонмен келесі аймаққа өтеді: тағы 1–2 access коммутатор, содан кейін келесі аплинк. Соңында өзгертулерді тіркеп, порт кестесін жаңартып, жұмыс конфигурациясын келесі аймақ үшін эталон ретінде сақтайды. Көп жағдайда келесі түнді жылдамдату үшін қысқа жұмыс шаблонын бірден жасау ыңғайлы.

Келесі қадамдар: пилот, жұмыс жоспары және енгізуді кімге сеніп тапсыру

Миграция тыныш өтуі үшін не нақты сәттілік екенін алдын ала келісіп алыңыз. "Барлығы жұмыс істейді" деген анықтама тым жалпылама, сондықтан ауыстырғаннан кейін даулар жиі шығады.

Қабылдау критерийлерін және өлшенетін тексерулерді бекітіңіз. Оларды сервистер иелерімен келісіп, қысқа тізімге түсіріңіз:

• клиенттер IP алады (DHCP), интернетке және қажетті подсеттерге шығады
• телефондар тіркеледі және жүктеме кезінде регистрации жоғалтпайды
• Wi‑Fi нүктелері PoE алады, контроллерде көрінеді және желіні таратады
• критикалық қосымшалар қажетті сапада өтеді (кідіріс, жоғалулар)
• мониторинг құрылғыларды және порттарды көреді, журналдар жиналады

Сосын пилотты бір сегментте жасаңыз, бәріне бірден емес. Типтік ролдері бар, бірақ толық компанияны тоқтатпайтын жерді таңдаңыз — мысалы, бір қабат немесе бір қанат. Пилоттан кейін шаблондарға түзетулер енгізіп, тек содан соң масштабтаңыз.

Ауыстыру терезесіне дейін бір тұтас пакет дайындаңыз: порт кестесі (не қайда қосылған), конфигурация шаблондары, откат жоспары және бақылау нүктелері (15 минут, 1 сағат, 4 сағаттағы тексерулер). Миграциядан кейін алғашқы 24–48 сағат өте маңызды: күзетші қолдау және мониторинг қажет, себебі мәселелер көбіне бірден емес, жұмыс пикінде шығады.

Егер толықтай тапсыру қажет болса, VLAN, PoE және QoS‑ты вендорлар арасында көшірген тәжірибесі бар команданы таңдаңыз. Мысалы, GSE.kz (gse.kz) жүйелік интегратор ретінде жобалау, енгізу және ауыстырудан кейінгі қолдауды қамтамасыз ете алады, соның ішінде терезе уақытындағы және одан кейінгі 24/7 сүйемелдеу.