Aruba CX 8325 spine-leaf деректер орталығында: іске қосуға арналған чек-лист

Spine-leaf іске қосқанда әдетте не бұзылады және неге\n\nSpine-leaf алғашқы мәселелері сирек «порт құлап кетті» тәрізді көрінеді. Көбінесе бәрі әдемі: линк өсіп тұр, маршрутизация бар, пинг өтеді. Ал шынайы жүктеме кезінде микропотерялар, кешігулердің секірісі және жеке сервистердің «табандылықтары» пайда болады.\n\nЕң жиі кездесетін жасырын проблема — сәйкес келмейтін MTU. Бір жерде jumbo қосылды, ал басқа жерде 1500 қалды. Қайда да бір виртуалдық коммутатор немесе NIC баптауы араласты. Нәтижесінде фрагментация немесе үлкен пакеттердің үнсіз тасталуы болады. Бұл әсіресе сақтау жүйелерінде, бэкаптарда және торап аралық east-west трафигінде байқалады.\n\nЕкінші топтағы проблемалар — жүктелулер мен кезектер. Aruba CX 8325 фабрикасында «тамаша» интерфейстерді көріп тұрып та микропотеряларды ұшыратып қалуыңыз мүмкін, себебі ECN/PFC логикасы дұрыс емес, кезек профилдері сәйкес келмейді немесе сервер жағынан күтпеген burst-тар бар.\n\nҮшінші қауіпті зона — таймерлер және қалпына келу күту уақыты. Түрлі BFD, LACP, маршруттау протоколдарының таймерлері және тіпті NTP әртүрлілігі «жалпы жұмыс істейді, бірақ кейде ұзақ қалпына келеді» әсерін береді. Бұл эксплуатацияда тосынсый туғызады.\n\nІске қосарда тек байланыс бар ма екенін емес, желі типтік стресс-жағдайларда қалай жұмыс істейтінін тексеру маңызды. Әдетте қарап шығады:\n\n- даусырақ MTU (ToR, spine, серверлер, гипервизор қосымша)\n- жүктеме кезінде микропотерялардың болмауы (жәй ғана порттағы CRC/дроптарды емес)\n- жүктемеге болжамды жауап (кезектер, ECN және PFC қажет жерде)\n- линк/коммутатор ақауы кезінде сходимость пен күтілетін қалпына келу уақыты\n- базалық бақылау: деградация басталғанда не көресіз\n\nЖауапкершілік шекарасын алдын ала келісіңіз. Әйтпесе кез келген мәселе тез «бұл желі» мен «бұл сервер» дауына айналады.\n\nЖелінің жауапкершілігі әдетте фабрика баптаулары, кезек саясаты, таймерлер мен метрикаларды жинау. Сервер командасы — NIC пен ОС-тағы MTU, offload-тар және DCB/RoCE параметрлері (қолданылса). Айрықша назар аударыңыз: кабель жүйесі, оптика және трансиверлер (сәйкестілік, сигнал деңгейі, жинау сапасы), сондай-ақ ДҚ инженерлік бөлігі (қуат, салқындату, маркерлер және трассировка).\n\nҚарапайым мысал: іске қосқаннан кейін түнгі бэкаптар айтарлықтай баяулай бастады, ал қателік графиктері бос болды. Себеп жиі бір «тар» учаскеде MTU 1500 немесе uplink-тегі кезектерде, онда бірнеше хосттың burst-тары басқаларды қысымдайтын жер болады. Мұндай нәрселерді іске қосар алдында анықтау жеңілірек.\n\n## Жобалаудан бұрын жинақталатын бастапқы деректер\n\nAruba CX 8325 конфигурациясын қозғамас бұрын spine-leaf үшін бастапқы деректер жинаңыз. Бұл пакетсіз «қызыл» күндерін үнемдейді және қай тексерістер міндетті екенін алдын ала көрсетеді.\n\nТопология мен физиканы бастаңыз: қазір және бір жылдан кейін қанша spine және leaf қажет, аплинк/даунлинк жылдамдықтары (25G, 100G және т.б.), оптика немесе DAC түрлері, арақашықтықтар және қанша порт резервте қалу керек. LAG/MC-LAG қай жерде болатынын және асимметриялық жолдардың мүмкіндігін белгілеңіз.\n\nКейін фабрика түрін анықтаңыз. L2 немесе L3 — бұл философия ғана емес, болашақ тәуекелдер мен тексерістер тізімі. L2-де жиі loop-тар, STP күтулері және broadcast сюрприздері шығады. L3-де маршруттау, ECMP және ақау сходимосты көбірек назарды талап етеді.\n\nТрафик профилін алдын ала сипаттаңыз: қолданбалар арасында қанша east-west, бэкап түнде қалай өтеді, бөлек сақтау трафигі бар ма, north-south шыңдары қашан. Бұл кезектерге, буфер талаптарына және микропотерялардың қаншалықты маңызды екеніне әсер етеді.\n\nЕгер сезімтал сервистер (VDI, дауыс, сауда жүйелері) болса, кешігу және джиттер бойынша мақсаттарды тіркеңіз: қай жерде бұл "ауырады", ал қай жерде рұқсат етіледі.\n\nСыртқы сервистерді бірден келісіңіз: NTP (жазбалар үшін бір уақыт), DNS (басқарылу және AAA), AAA (TACACS+/RADIUS, рөлдер және аудит), орталықтандырылған логтау (Syslog), сондай-ақ IP-адрестер және құрылғылар, интерфейстер, VRF/VLAN атауларының жоспары.\n\nПрактикалық мысал: бэкап түнде фабриканы жиі «толтырады» — бұл туралы кезектерді орнатпас бұрын білу керек. Әйтпесе күндіз бәрі жақсы, ал түнде жоғалтулар мен қайта жіберулер пайда болады.\n\n## MTU және jumbo frames: жасырын фрагментациядан қалай сақтану керек\n\nAruba CX 8325 фабрикасында MTU жиі «тыныш» себебі болады. Кіші пакеттерде желі сау көрінуі мүмкін, бірақ жүктеме кезінде қайта жіберулер, жылдамдықтың төмендеуі және таймауттар пайда болады.\n\nJumbo MTU әдетте оправдан east-west трафик көп болса (сақтау, виртуализация, бэкаптар) немесе overlay (мысалы, VXLAN) қолданылса, ол накладные байттарды қосады. Егер MTU «тығыз» болса, үлкен кадрлар кесіліп немесе тасталуы мүмкін — сіз себепті емес, салдарын көресіз.\n\n"Біртұтас MTU" дегеніміз — барлық жол: коммутатор порттары, trunk-тар мен агрегациялар, сервер NIC-тері, гипервизор және vSwitch, плюс overlay интерфейстері. Бір ұмытылған порт кіші MTU-лы "аралшаны" жасайды, онда үлкен кадрлар өтпейді.\n\n### Несоответствиені табу үшін минималды тексерістер\n\nІске қосар алдында бірнеше тест жеткілікті, бірақ оларды әр түрлі нүктелерден жасаңыз: leaf–leaf арқылы spine, сервер–сервер, хост–шлюз.\n\n- DF-пинг (фрагментациясыз) жасап, өлшемді біртіндеп ұлғайту, фрагментациясыз өтетін максимумды табу.\n- Бірнеше пакет өлшемінде тесттер (шамамен 1500 және jumbo), жоғалтулардағы айырмашылықты көру үшін.\n- Үлкен пакеттерді жіберу кезінде интерфейстегі дроп/қате счетчиктерін салыстыру.\n- MTU-ны тек коммутаторларда емес, NIC және гипервизорда да тексеру.\n\nТиптік симптом: 1500-де бәрі таза, ал үлкен пакеттерде жоғалтулар және "түсініксіз" TCP retransmit-тер пайда болады.\n\n### MTU-ны стандарт ретінде бекіту\n\nMTU-ны домен (подсеть, стэнд немесе барлық фабрика) үшін стандарт ретінде бекітіңіз және әр жаңа түйінді қосқанда тексеріңіз. Жаңа серверлер мен жаңа шилер үшін қысқа қабылдау шаблоны — MTU мәндері мен жылдам DF-ping — пайдалы. Осылайша іске қосқаннан кейін айдан кейін жаңа "аралшалар" пайда болмайды.\n\n## ECN, PFC және кезектер: артықша күрделендірмей негізгі логика\n\nECN пен PFC ұқсас мәселені шешеді: коммутатор кезегі өседі, жоғалтулар басталып, кешігу секіріп кетеді. Айырмашылығы — желі трафикті қалай "ұқыпты" жүргізуді сұрайды.\n\nECN (Explicit Congestion Notification) жұмсақ жұмыс істейді. Кезек өсіп жатқанда коммутатор пакеттерді белгілейді, ал жіберуші TCP сияқты баяулайды, жоғалтусыз. Бұл фабрика үшін, кешігулер тұрақты және өткізу қабілеті болжамды болуы керек кезде жақсы.\n\nPFC (Priority Flow Control) қатты жұмыс істейді. Ол таңдалған приоритеттегі трафикті қысқа уақытқа тоқтата алады, сол арқылы жоғалтулар болмайды. Бұл тек пакеттер жоғалуы жөнінде келісілмейтін және дұрыс жауап беретін ағындарға қажет, мысалы RoCE. Кәдімгі IP-трафик пен көпшілік TCP-қолданбалар әдетте PFC-ны қажет етпейді және оны «қауіпсіздік үшін» қосу жиі жайсыздық әкеледі.\n\nAruba CX 8325 үшін практикалық ереже: PFC-ны тек нүктелі түрде және тек end-host қолдайтын, бапталған жерлерде қосыңыз; ECN-ды негіз ретінде қолданыңыз.\n\nКөбіне қателік теорияда емес, ұсақ сәйкессіздіктерде: барлық приоритеттерде PFC қосылды және кезектер «тоқтап» қалды; сервер, ToR және аплинктер арасында RoCE үшін PCP-ны шатастырды; коммутаторларда PFC орнатылып, ал NIC пен драйверлер ұмытылды; QoS профильдері сақтау командасымен келісілмеген және фондық бэкаптар lossless-класқа түсті.\n\nСервер және сақтау командаларымен алдын ала келісіңіз: қандай трафик lossless саналады, оның приоритеті (PCP/DSCP), RoCE қажет пе және қай нұсқа, және кім NIC баптаулар үшін жауапты (DCB, PFC, ECN, троттлинг).\n\nИске қосар алдындағы минималды тексеріс қарапайым болуы мүмкін: жүктеме кезінде желі күтілген түрде жауап береді ме. Мысалы, жүктеме кезінде ECN mark-тары өседі, тек drops ғана емес; PFC қосылғанда қажетті приоритетте PFC pause frame-дері көрінеді, бірақ басқа кластарда массовые паузалар жоқ; кезектер «жабыспайды», ал пиктен кейін кешігулер қалыпқа келеді.\n\n## Таймерлер және сходимость: NTP, BFD және қалпына келу күту уақыты\n\nSpine-leaf фабрикада маңызды мәселе — тек порт жылдамдығы ғана емес, ақаудан кейін желінің алғашқы секундтардағы мінезі. Таймерлер шатасса, «жүзетін» проблемалар пайда болады: трафик бір сәтте жоғалып, қосымшалар кешігуді айтады, ал журналдар себепті анық көрсете алмайды.\n\nNTP дәл уақыты «түрткі» үшін керек емес. Синхрондаусыз коммутатордағы сағаттар бөлекке кетеді, телеметрия мен оқиғалар бір сызыққа келмейді. Типтік симптом: leaf-тағы линк 10:01:05-де құласа, spine-та сол оқиға 09:58:12 деп жазылған.\n\nСходимость — желі ақауды қаншалықты тез байқайды және протоколдар маршруты қайта есептеуді қанша уақытта жүзеге асыратынына байланысты. Қандай цифрларды күтетініңізді алдын ала келігіңіз: секундтарда қалпына келу ме, әлде ондаған секундта ма. Таймерлер неғұрлым агрессивті болса, қысқа пропаданияларға жалған срабатывания қаупі жоғары.\n\nBFD маршруттық деңгейдегі мәселелерді тез анықтауға көмектеседі, бірақ оны ақылмен қосу керек. Ол критикалық L3 сессияларда (мысалы, leaf–spine) пайдалы, ал тұрақсыз учаскелерде немесе CPU жүктелген кезде өте қысқа интервалар флаппингке әкелуі мүмкін.\n\nАйрықша тақырып — 25/40/100G-дағы микроберсттер және буферлер. Төмен орташа жүктеме кезінде де қысқа жарылыстар кезекті бітеп, жоғалтуларға әкелуі мүмкін. Бұл, әсіресе, бір жерде төмен жылдамдық (мысалы, 25G сервер мен 100G аплинк) және трафик бір нүктеге жиналғанда байқалады.\n\n"Түрлі таймерлер паркі" болмас үшін барлық коммутаторларға базалық шаблон бекітіңіз: бірдей NTP көздері және журнал форматы; қай жерде BFD қосылған және интервалы қандай; барлық фабрикада бірдей протокол таймерлері; мақсатты қалпына келу уақыты және өлшеу әдісі; кезектер мен шекті мәндер мониторингі ережелері.\n\nЖұмыс алдындағы жылдам тест: қызметтік терезеде бір leaf–spine аплинкті өшіріп, 2–3 типтік ағын үшін қалпына келу уақытын өлшеңіз (мысалы, DB-ға қатынау және үлкен файл тасымалы). Бұл күтілетін нәтиже мен шынайылықтың сәйкестігін тез көрсетеді.\n\n## Орнату тәртібі: тосынсыйларсыз қадамдық жоспар\n\nAruba CX 8325 фабрикасын бір сценарий бойынша қадамдап енгізу оңайырақ. Логика қарапайым: алдымен «қаңқа» (spine), кейін leaf, және тек содан соң жүктемені қосасыз. Бұл кезде қатені тез табуға болады және не бұзылғанын болжауға тура келмейді.\n\nАлғашқы қосқанда аттарды және адресация жоспарын бекітіңіз. Атаулар роль мен орынды көрсетуі тиіс (мысалы, SP1-SP2, LF01-LF08), ал underlay IP-адрестер анық жүйеге сәйкес берілуі жақсы — адрес бойынша қандай құрылғы екені көрінуі керек. Порттардың серверлерге және көршілерге атауы туралы да біркелкі келісіңіз, әйтпесе қосылу картасы екінші аптада «ағып» кетуі мүмкін.\n\nЖұмыс тәртібі әдетте мынадай:\n\n- Конфигурация шаблондарын дайындау: базалық параметрлер, underlay, порт саясаты, NTP, логтау және телеметрия.\n- Spine-ді енгізу: линк, жылдамдық, FEC, оптика дұрыстығын және коммутаторлар арасындағы порт режимдерін тексеру.\n- Spine пен leaf арасындағы underlay-ды көтеру: тұрақты маршрутизация және барлық коммутатораралық линктарда бірдей MTU қамтамасыз ету.\n- Leaf-тарды енгізіп, әр spine-пен көршілікті тексеру, содан кейін uplink-терді біртіндеп қосу, бәрін бірден емес.\n- Серверлер мен сервистерді соңында қосу, пилоттық стойкадан бастап.\n\nӘр қадамнан кейін келесіге өтпей тұрып қысқа «жасыл» тексерістер жиынтығын жасаңыз: линк қателерсіз және дроптар жоқ, жылдамдықтар мен MTU сәйкес, LLDP көршіліктері бар, маршруттау протоколдары көтерілген, NTP синхронда және телеметрия/алерттер жұмыс істейді.\n\nБарлығын есте сақтаңыз: порт картасын (қайда не қосылған), оптика түрлері мен ұзындықтары, жылдамдықтар мен FEC, сериялық нөмірлер, ПО нұсқалары және шаблоннан айрықша кез келген бөлшектер. Бұл инциденттерде және фабриканы кеңейту кезінде сағаттарды үнемдейді.\n\n## Телеметрия және бақылау: не жинау керек және қалай оқу керек\n\nБақылауды бірінші трафикке дейін ойластыру жақсы. Іске қосқаннан кейін сіз "неге баяу" емес, деградация қай жерде басталатынын іздейсіз: портта ма, кезекте ме, оптикада ма немесе хостта ма.\n\n### Бірінші күннен бастап база: счетчиктер, қателер және кезектер\n\nКөптеген кезде түпкі себепті көрсететін жиынтықтан бастаңыз. Bandwidth қана емес, өткізу сапасы мен кезек мінезін бақылаңыз.\n\n- FCS/CRC және symbol қателері: көбінесе оптика, кабель немесе модуль сәйкессіздігі себеп болады.\n- Interface-дегі discards және drops: "буферге сыймады" және "policy/ACL" себебін ажырату маңызды.\n- Кезектер мен congestion: queue depth, tail drops, ECN mark-тары, микроберсттердің шарықтауы.\n\n- Кестелер мен "флаптайтын" жазбалар (MAC/ARP/ND): оғаш маршруттар мен "жүзетін" симптомдарда пайдалы.\n- Линк күйі: flaps, жылдамдық, автосогласование қателері, FEC (қолданылса).\n\n### Логтар, шекті мәндер және серверлермен "жалпы көрініс"\n\nЛог деңгейін сигнал беретіндей етіп орнатыңыз, шу емес: линк оқиғалары, маршруттау протоколдарының өзгерістері, көрші өзгерістері, аппараттық қателер. Салыстырмалы түрде сирек CRC оқиғалары және discards өспеген кезде аппаратты тексеру керек, бірақ әр 5 минут сайын тревога жіберу дұрыс емес.\n\nАлерт шектерін ерте анықтаңыз: оптика қателерінің өсуі, тұрақты discards, ішкі фабрикадағы RTT өсімі, congestion белгілері (кезектер босатылмай, ECN mark-тары өседі). Желінің және серверлердің метрикаларын байланыстырыңыз: NIC жүктемесі, TCP retransmits, сақтау жүйесінің latency, CPU шыңдары. Осылайша жоғалудың нақты қай ToR-дан басталғаны көрінеді, ал кейін ретрансляциялар көбейеді.\n\n## Іске қосар алдындағы минималды тесттер — өнімділік\n\n«Минималды» тесттің не екенін алдын ала келісіп алыңыз. Aruba CX 8325 үшін бұл зертханалық көрсеткіш емес, ал фабриканың трафикті жоғалтусыз, болжамды кешігумен және қарапайым ақаулардан аман өтуін растайтын қысқа тексерістер жиынтығы.\n\nТест шарттарын (пакет өлшемі, ағындар саны, ұзақтығы) бекітіп, төрт метриканы тексеріңіз:\n\n- өткізу қабілеті\n- жоғалтулар\n- кешігу (орташа және 99-перцентиль)\n- джиттер (дауыс пен VDI үшін маңызды)\n\nСосын бағыттар бойынша тестілеңіз: leaf–leaf бір стойкада, leaf–spine–leaf арқылы фабрика, әрі «сервистерге дейін» жол (шлюз, firewall, балансировщик, storage). Тыныш режим мен жүктеме режимін салыстырыңыз. Кешігулер мен жоғалтулар секірсе, көбінесе себеп — кезектер/ECN, сәйкес келмейтін MTU немесе ағындар хэшталудағы қисықтық.\n\nТөзімділікті нақты жағдайлармен тексеріңіз: бір аплинкті өшіріп қосу, leaf-тың бір портын өшіру, бір leaf-ты қайта жүктеу (келісілген терезеде), және егер саяси рұқсат болса — spine-ты қайта жүктеу.\n\nСоңында нәтижені «эталон» ретінде құжаттаңыз: метрикалар, конфигурация нұсқалары, тест ағындарының картасы және күтілетін сандар. Кейін кез келген өзгеріс осы базамен салыстырылады, көзге қарап дау болмайды.\n\n## Aruba CX 8325 баптауындағы жиі қателер мен тұзақтар\n\nФабрикадағы көп мәселе «қиын архитектурадан» емес, стендте көрінбейтін ұсақ сәйкессіздіктерден шығады.\n\nБірінші тұзақ — жолдағы бір учаскеде сәйкес келмейтін MTU. Бір линк немесе port-channel төмен MTU-ға ие болса, үлкен пакеттер жасырын түрде фрагментацияланады немесе тасталады. Симптом — "жүзетін" өнімділік. Бұл әсіресе leaf-та бәрі дұрыс, бірақ uplink немесе бір spine әлі әдепкі мәнде болғанда қауіпті.\n\nЕкінші типтік себеп — физика: жылдамдық, автосогласование және оптика. Қағазда бәрі 100G, шын мәнінде трансивер қажетті режимді қолдамайды, кабель дұрыс типте емес немесе бір жағында жылдамдық қатты бекітілген, ал екінші жағында автосогласование. Нәтиже — CRC, FEC қателері және сирек, бірақ ауыр әсер ететін жоғалтулар.\n\nТағы бір тұзақ — QoS бір стандарт бойынша емес. Leaf пен spine-де «ұқсас, бірақ бірдей емес» кезек баптаулары, DSCP маппингі, буферлер, ECN немесе PFC болса, фабрика жүктеме кезінде болжамсыз болады. Микроберсттер кезінде бұл айқын көрінеді.\n\nТаймерлермен де оңай асырып алуға болады. Өте агрессивті таймерлер қысқа джиттер немесе CPU жүктемесі үшін жалған флаппингтер туғызады: сессия құлдырайды-және қайта көтеріледі.\n\nЖәне қарапайым, бірақ маңызды нәрсе — базлайнның жоқтығы. NTP болмаса логтар мен телеметрия мәнін жояды, ал бастапқы метрикалар болмаса өзгеріс пайда болғанын дәлелдеу қиын.\n\nНақты өзін-өзі тексеру жүктеме тесттеріне дейін:\n\n- фабриканың барлық линктері және негізгі сервистерге дейін end-to-end MTU-ны тексеру\n- әр аплинктегі линк режимдерін, FEC және қате счетчиктерін қарау\n- leaf және spine үшін бір QoS шаблонын бекіту және ешкімге ерекшелік жасамау\n- таймерлер қысқа жарылыстарда флаппинг тудырмайтынын тексеру\n- NTP қосып, базалық метрикалардың снимогын алу (кешігу, дроптар, порт жүктемесі)\n\nМысал: фабрика "сияқты жұмыс істейді", бірақ бір шкафтық сегмент кешігулерге шағымданады. Көп жағдайда анықталады: бір аплинкте басқа оптика тұрғандықтан CRC өсіп жатқанын және сол leaf-та кезек маппингі әртүрлі екенін. Жеке алғанда бұл шыдамды, бірақ бірге — "ұстап болмайтын" әсер береді.\n\n## Іске қосар алдындағы қысқа чек-лист\n\nФабриканы іске қосар алдында қысқа тексерістен өту пайдалы, ол көпшілік "тыныш" проблемаларды ұстайды: қате жылдамдықтар, байқалмайтын оптика қателері, MTU сәйкессіздігі және кезектердің шамадан тыс жүктелуі.\n\nБұл чек-листі бір техникалық терезеде жасау және нәтижелерді базалық сызық ретінде тіркеу ыңғайлы.\n\n- Физикалық деңгей (линк және оптика). Порттар күтілген жылдамдықта көтеріледі, қателер (CRC/align) жоқ, оптика деңгейлері қалыпты, кабельдер мен патчкордтар белгіленген және шатастырылмаған.\n- L2/L3 консистенциясы. Протокол бойынша көршілік дизайнға сәйкес, жолдар әр spine және leaf-та бар, конфигурациялар біртипті құрылғылар арасында бөлінбеген. Егер MLAG/VSX болса, жұптың күйі және синхронизациясын тексеріңіз.\n- MTU end-to-end. Үлкен пакеттер серверден серверге фабрика арқылы фрагментациясыз және бір линкте ұсталып қалмай өтеді.\n- Жүктелу белгілері (кезектер және дискардтар). Тест жүктемесінде кезек, дроп және ECN mark-тарын салыстырыңыз. Бір бағытта дискардтар өссе, бұл трафик теңсіздігі немесе қате кезек баптауы екенін көрсетеді.\n- Бақылау және төзімділік. NTP жұмыс істейді, оқиғалар мониторингіге түседі, негізгі алерттер бар. Қысқа failover-тест жасаңыз: бір линкті, кейін бір leaf (немесе leaf-тың uplink-ін) өшіріп, сходимость күтілген уақытқа сай келетінін тексеріңіз.\n\nНұсқа — бір аплинкті өшіргенде жұп серверларға кешігу өзгермей, сессиялар үзілмей және дроп счетчиктері аспайтын болса, іске қосуға жақынсыз.\n\n## Мысал сценарий: кішкене фабриканы іске қосу және нәтижелерді талдау\n\nФабрика ойша: 2 spine және 6 leaf Aruba CX 8325, аплинктер 100G, серверлерге 25G. Сақтауға бөлек аймақ бөлінген (мысалы, бөлек VLAN/VRF немесе бөлек кезектер мен трафик кластары). Мақсат — іске қосуда кешігудің болжамдылығы, жүктеме кезінде жоғалтулардың болмауы және түсінікті телеметрия.\n\nЧек-листі 1–2 күнде өткізу үшін ыңғайлы жоспар:\n\n- Күн 1 (таңертең): базалық байланыс, NTP, бірдей ПО және профильдер, телеметрия мен базалық счетчиктерді қосу.\n- Күн 1 (күндіз): барлық жолдардағы MTU end-to-end тексерісі (leaf–spine–leaf, leaf–сервер) және сақтау контурында.\n- Күн 1 (кеш): ECN қосу, қажет болса PFC тек қажетті жерлерде; жүктеме кезінде кезектерді тексеру.\n- Күн 2: жүктеме тесттері (жалғыз ағындар және көп ағындар), нәтижелерді тіркеп, ауытқулар бойынша шешімдер қабылдау.\n\nMTU қате орнатылса, тесттер көбінесе "секірікті" жылдамдықты, кешігудің күрт өсуін және порттарда түсініксіз дроптардың пайда болуын көрсетеді. Кейде бәрі "дерлік жұмыс істейді", бірақ нақты жүктеме кезінде сақтау деградацияланады.\n\nECN дұрыс емес орнатылғанда (немесе біркелкі емес қосылғанда) жүктеме кезінде микроберсттер, кезектердің өсуі және жүйелі емес жоғалтулар байқалады — бұл қосымшаларда ара-тұра жағымсыз таймауттар ретінде көрінеді.\n\nІске қосу протоколын қысқа құжат ретінде жасаңыз: схема және конфигурация нұсқалары, даталар мен жауапты тұлғалар; не тексерілді (MTU, ECN/кезектер, кешігу, жоғалтулар) және қандай тесттермен; нәтижелер цифрмен; ауытқу және шешімдер; "эксплуатацияға дайын" критерийлері.\n\nІске қосқаннан кейін апта сайын қате және дроп счетчиктерін, NTP бақылауын, кешкі уақытта кезектер трендін және кез келген өзгерістерден кейін қысқа өнімділік тестін жүргізуді ұсынамыз (прошивка, жаңа стойкалар, QoS профильдері).\n\n## Іске қосқаннан кейінгі келесі қадамдар: регламент және қолдау\n\nФабрика көтеріліп, бастапқы тексерістерден өткеннен кейін жұмыс аяқталған жоқ. Айда бірден пайда болатын «тұтқыр» проблемалардың ең жиі себебі — нақты орнатулар емес, өзгерістер тәртібінің болмауы: норманы не екенін кім біледі, конфигурацияларды кім өзгертеді және бастапқы деректер қайда сақталады.\n\nБарлық артефакттарды бір жерде жинаңыз, бұл тек жоба инженері үшін емес, ауысымдағы инженерге де қолжетімді болуы керек. Бұл жай ғана файлдар жинығы емес, бірегей "желі паспорты": ағымдағы конфигурациялар мен шаблондар (дата мен нұсқасымен), порт және кабель картасы, базалық метрикалар (кешігу, жоғалтулар, линк жүктемесі, кезек дроптары), тест хаттамалары және "норма/жоқ" шектері, тәуелділіктер тізімі (NTP, DNS, AAA, мониторинг, қолжетімділіктер).\n\nСодан кейін өзгерістер терезелері туралы келісіңіз: кім бекітеді, беккап қалай жасалады, қайтару тәртібі және жаңартудан кейін нәтижені қалай тексересіз. Қауіпсіз ереже — бірден бүкіл қабатты жаңартпау: алдымен бір коммутатор, кейін жұп, қысқа бақылаудан кейін жалғастыру.\n\nДежур командаға деградация кезінде "басынан тексеретін" қысқа нұсқа беріңіз: құрылғылар уақыты, линк күйі, порттағы қателер, дроптардың өсуі және кезектер, spine бойынша трафикте қисықтық, және соңғы 24 сағатта не өзгергені.\n\nЕгер RoCE, тығыз виртуализация, басқа фабриканың миграциясы немесе «кілтке дейін» жүйалық интеграция жоспарланса, интеграторды тартқан жөн. Қазақстанда GSE.kz (gse.kz) деректер орталығы үшін жүйелік интеграция, инфрақұрылымдық шешімдер, серверлер мен жұмыс станцияларын жеткізу және тәулік бойы техникалық қолдау көрсететін сервис желісі арқылы қамтамасыз етеді.