Cisco Nexus 9500 негізіндегі деректер орталығының ядросын 3 жылға жобалау

Мәселе қайдан басталады: ядро өсімі мен тұрақтылығы

Cisco Nexus 9500 тәрізді модульді ядро — бұл шасси, мұнда модульдер: порттары бар линейлы карталар, басқару модульдері (supervisor), фабрика, қорек көздері бөлек таңдалады және уақыт бойынша өзгереді. Фиксирленген коммутаторлардан айырмашылығы, сіз алдын ала бекітілген порттар мен мүмкіндіктер жиынтығында шектелмейсіз. Құралым сыйымдылығын өсіруге болады, толық құрылғыны алмастырып жатудың қажеті жоқ.

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

Ядроны ең көп тоқтата тұратын нәрсе — «қиын багтар» емес, базалық нәрселер: A/B болып шынайы бөлінбеген электрмен қамтамасыз ету, екінші supervisor-дың ыстық резервте болмауы, фабриканы немесе линейлы картаны алмастыру схемасының қолайсыздығы, өзгерістердегі қателер (VLAN/VRF, ACL, BGP, MTU, автоматтандырудағы жазып қателер), NX‑OS-ты жоспарсыз жаңарту мен кері қайтару жоспарының болмауы.

Слоттар мен порттарды талқыламас бұрын базалық шешімдер бойынша келісіңіз. Nexus 9500-ді жобалау әдетте төрт сұрақтан басталады:

• қазір және 36 айдан кейін қандай сыйымдылық қажет;\n- қай қандай ақаулар қызметтерге байқалмай өтуі тиіс;\n- NX‑OS-ты қалай жаңартасыз және қаншалықты жылдам кері қайта аласыз;\n- қандай өзгерістер процесі міндетті.

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

3 жылға талаптар: жобалаудан бұрын не жинау керек

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

Алдымен ДҚО-ға ешқандай қызметтер шын мәнінде орналасатынын және олар қалай өсетінін талдаңыз. Маңыздысы — жүйенің атауы емес, профиль: тұрақты трафик пе, әлде шыңдар ма, көп кіші қосылымдар ма әлде ірі ағындар ма, кешігуге сезімтал ба, маусымдық қасиеттер бар ма. Болжамдағы өзгерістерді бөлек белгілеп қойыңыз: нұсқаларға көшу, VDI, Kubernetes кеңеюі, жаңа орындардың пайда болуы.

Келесі қадам — қарапайым мақсатты метрикаларды бекіту. Қолжетімділік әдетте пайызбен көрсетіледі, бірақ «қанша тоқтауға рұқсат» сағатпен жылына жазылғаны жақсырақ. RTO — апаттан кейін сервис қанша уақытта қалпына келуі тиіс. RPO — уақытпен қанша деректі жоғалтуға болатындығы (мысалы, 5 минут немесе 1 сағат). Бұл екі сан қай жерде үздіксіз апгрейд қажет, ал қай жерде жоспарлы терезе жеткілікті екенін тікелей анықтайды.

Содан кейін қосылым түрлерін және олардың критичтілігін сипаттаңыз: серверлік стойкалар, СХД, east‑west байланыстары, сыртқы арналарға шығу және офис желілері. «Қанша порт керек» пен «қандай жылдамдықтар» (10/25/40/100G) сұрақтарын бөліңіз, оптика мен қашықтық талаптарын көрсетіңіз.

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

Соңында 3 жылға болжамдық қабылдаулар жасаңыз: порттар мен өткізу қабілетінің өсімі жылдық %, жаңа залдардың енгізу мерзімдері, сегментация принциптері және «сәтті өзгеріс» дегеннің анықтамасы. Мысалы: «серверлік қосылымдардың жыл сайын 30% өсуі, сақтау бөлімінің бөлігінің екінші жылы 100G-қа көшуі, жаңартулар жоспарлы терезелері тек жексенбі 02:00–06:00». Мұндай келісім шешім қабылдауды жылдамдатады және кейінірек дауларды азайтады.

Сыйымдылықты жоспарлау: порттар, жылдамдық, резерв

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

Алдымен жақын 12–18 айдағы порт тұтынушылар тізімін жасаңыз және 2–3 жылдық жоба болжамдарын қосыңыз. Көбінесе бұл ToR стойкалары, аплинктер, SAN немесе IP‑storage қосылымы, сыртқы маршрутизаторлар, брандмауэрлар, DCI және сервис желілері болады.

Жылдамдықтар бойынша пайдалы ереже — «агрегация көп жерде жылдамдық жоғары». Көп жағдайда: жеке қызметтер мен басқару үшін 10G қалады, жаңа стойкалардағы серверлер мен ToR үшін 25G — негізгі, 40G — мұра ретінде кездеседі, ал 100G ToR аплинктерін, коммутатораралық байланыстарды және DCI шығыстарын жабады. Егер 100G қай жерде керек екенін білмесеңіз, өзіңізге: «осы сілтеме ондаған хосттан трафик жинай ма әлде бірнеше құрылғыдан ма?» деп сұраңыз.

Резервті қуат пен supervisor сияқты ғана емес, порттар мен аплинктер үшін де сақтау қажет. Практикада әр жылдамдық типі бойынша 20–30% бос порт және авариялық қайта қосылуға арналған минимум бір «қосымша» аплинк сақтау жеткілікті. Сонымен қатар DCI/интернетке шығу үшін кеңейтуге арналған өткізу қабілеті бойынша буфер қалдырылады.

Болашақ жобаларды бөлек жолдарға енгізіңіз, тіпті мерзімі анық болмаса да: жаңа виртуализация платформасы, резервтік ДҚО, GPU‑кластер, қаржы секторына арналған жаңа сегмент, серверлік карталарды 25G‑қа көшіру. Бұл жыл өткен сайын порты жетіспеу тәуекелін азайтады.

Жайлылық үшін «жыл 0‑1‑2‑3» кесте жасаңыз:

Мысалы: егер 1‑ші жылы тағы 6 виртуализация стойкасы қосылса және әрқайсысы 2×100G аплинк талап етсе, онда осы жобаға ғана 12 порт 100G керек болады плюс авариялық қайта қосылу үшін резерв. Мұндай қарапайым есеп бюджет пен мерзімді жиі құтқарады.

Nexus 9500 слоттары мен модульдері: компоновкада қалай қателеспеу

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

Nexus 9500‑де рольдер бойынша ойлау маңызды. Линейлы карталар порттар береді (10/25/40/100G және жоғары). Supervisor басқару және бақылау жазықтығын қамтамасыз етеді. Фабрика шасси ішінде өткізу қабілетін береді, және дәл осы компоненттер жиі болашақ өсімді шектеуі мүмкін, тіпті порттар әлі бар болса да. Қуат блоктары мен вентиляторлар — бөлек тәуекел аймағы: кейінгі апгрейдтерге олайша «сиқырлы орын» болмай қалуы мүмкін.

Егер 3 жылда өсу жоспарласаңыз, тек порттар үшін ғана емес, шассидің өткізу қабілетін жақсартуға да орын қалдырыңыз. Практикалық нұсқа: линейлы карталар үшін 1–2 слот бос ұстау және жаңа 100G/400G қосылымдар пайда болғанда фабриканы және қуатты күшейту қажет пе екенін алдын ала түсіну.

«Қазір сатып алу» мен «кейін сатып алу» компромисін тәуекелдер арқылы шешкен дұрыс. Кейінгі сатып алу бастапқы бюджетті төмендетеді, бірақ жеткізу мерзімдері, қажетті ревизиялардың қолжетімділігі және модуль комбинацияларының тәуелділігі сияқты тәуекелдер қосады. Кейде жаңа партия басқа фабрика жинағын немесе NX‑OS-тың басқа тармағын талап етуі мүмкін.

Эксплуатация үшін біркелкілік әдетте тиімдірек: аз типті линейлы карталар, аз оптика және кабель түрлері, запас бөлшектер мен оңай ауыстыру. Бір типті ғана емес, бірақ «зоопарк» деңгейдегі ерекше бірлікшелерден аулақ болыңыз.

Финалдық компоновкадан бұрын шектеушілерді тексеріңіз: таңдалған NX‑OS нұсқасымен модульдердің үйлесімділігі, тұтынуды есептеу (аялдамамен N+1 қуат режимін ескере отырып), жылу шығару және салқындату талаптары, oversubscription шектеулері, сондай‑ақ модульді ұзақ терезе талап етпей ауыстыру мүмкіндігі және трафикке әсері.

Қарапайым мысал: бүгін екі 100G линейлы картасы жеткілікті болса, бірақ 18 айдан кейін аплинк саны екі еселенеді деп жоспарланса, дереу қуат пен фабрика бойынша резерв қалдырып, порттарды кейін қосу тиімдірек. Бұл «орын бар, бірақ қоюға болмайды» деген жағдайдан құтқарады (қуат және шасси ішіндегі өткізу шектеулері себепті).

Резервтеу: нені дублировать және әдетте қай жерде ұмытады

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

Шасси жұбы: актив‑актив не актив‑пассив

Актив‑активта екі шасси бір уақытта трафикті көтереді. Бұл порттарды жақсырақ пайдалану мен бір құрылғы істен шыққанда жоғары жүктемеге төзімділік береді, бірақ қосылыстар схемасына және жауапкершілік шегіне (L2/L3, ECMP, vPC және т.б.) нақты ережелер талап етеді.

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

Қай нұсқада да шасси ішінде резервтеу қарастырылсын: екі supervisor, N+1 қуат және салқындату. Бұл модуль ауыстыруды, шектеулі жағдайларды және пик режимдерін тыныш жүзеге асыруға мүмкіндік береді.

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

Қай жерде жиі қосарланған single point of failure пайда болады

Тіпті логикалық схема әдемі болғанымен, ядро әдетте инфрақұрылым деңгейіндегі ұсақ нәрселерден сыр береді. Өзіңізді тексеріңіз:

• екі шасси бір PDU не бір кіріс автоматтан қоректенбеуі тиіс;\n- әртүрлі құрылғыларға тартылған кабельдер бір лотқадан өтпеуі тиіс;\n- екі аплинк бір ғана аралық коммутаторға жиналмауы тиіс;\n- резервтік қуат блоктары шынайы түрде қоректендіріліп, есепке алынуы керек;\n- «уақытша» патч-кордтар тұрақты жолға айналмауы тиіс.

Жақсы ереже: ақауды бір құрылғыдан емес, орта элементінен (PDU, лоток, стойка, ToR) ойлаңыз да, жұмыс істейтін жол қалады ма тексеріңіз. Мұндай талдауды эксплуатация және интегратормен бірге жасау ыңғайлы, солайша құпия ортақ тәуелділіктер схемадан ғайып болмауы тиіс.

NX‑OS жаңартулар схемасы: күтпеген жағдайсыз қалай жоспарлау

NX‑OS жаңартулары әртүрлі мағына мен тәуекелдерге ие. Планды релиздер қате түзетеді және функциялар қосады. Қауіпсіздік жөніндегі жедел патчтар әдетте жоғары приоритетті және әдеттегі кестені бұзуы мүмкін. Сондай-ақ аппараттық тәуелді жаңартулар бар: кейбір линейлы карталар немесе supervisor үшін белгілі бір NX‑OS тармағы қажет болуы мүмкін, немесе жеке EPLD микрокодын бөлек жаңарту керек болады.

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

Жаңартудан бұрын негізгі дайындамаларды бекітіңіз: таңдаған NX‑OS нұсқасының шасси, supervisor және барлық линейлы карталармен үйлесімділігін тексеріңіз (болашақ жоспарланғандар қосулы), релиз ноталарын оқыңыз, конфигурация мен нақты күйді құжаттаңыз, нақты кері қайтару жолын дайындаңыз және әр қадамнан кейін қысқа тексеру жоспарын әзірлеңіз.

Жұмыс уақытын қысқарту үшін әдетте кезеңді схема таңдалады: түйіндерді жұппен жаңартып, әр қайта іске қосқаннан кейін сервис тексеріледі. Егер ядро резервтелген түрде құрылған болса (мысалы, жұппен екі коммутатор), бір жаққа трафикті уақытша жылжытып, бірін жаңартып, қайтадан жүктемені кері қайтарып, екіншісін жаңартуға болады. Қай функциялар қайта іске қосуға сезімтал екенін (маршрутизация, vPC, LACP және басқа ЦОД протоколдары) алдын ала анықтау маңызды.

Жаңарту терезесін мини‑жоба ретінде қарастырыңыз. Қатысушыларды (желі, жүйелер, қолданбалар, қауіпсіздік) келісіңіз, қанша уақыт нақты қажет екенін үнемдікпен анықтаңыз және не «сәт» саналады: нұсқалар көтерілген, трафик қалпына келген, қателер жоқ, бақылау сервисі жұмыс істейді.

Өзгерістер тәуекелін бақылау: процесс, батырлық емес

ЦОД ядросындағы ең көп тоқтаулар «нашар аппараттан» емес, эмоцияға беріліп және нақты жоспарсыз жасалған өзгерістерден болады. Nexus 9500 үшін бұл әсіресе маңызды: модульдер, бірнеше басқару жазықтығы және NX‑OS‑тегі күрделі тәуелділіктер. Жақсы жобалау тек сызба емес, өзгерістерге тәртіпті де қамтиды.

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

• не өзгереді және не үшін: нақты команда/нұсқа/параметр, күтілетін нәтиже мен сәттілік критерийі;\n- тәуекел бағасы: қай сервис зардап шегуі мүмкін және «жұмсақ жерлер» қайсысы;\n- кері қайтару жоспары: желіні жұмыс күйіне қайтару қадамдары және «қайтарылмайтын нүкте» қайсы;\n- алдын ала және кейінгі минимальды тексерулер: конвергенция, маршрут кестелері, критикалық VLAN/VRF қолжетімділігі, бақылау пингтері және трафик;\n- рөлдер мен коммуникация: кім орындайды, кім бақылайды, тоқтатуды кім шешеді.

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

Тағы бір маңызды бөлік — рұқсаттар. «Түймені баса алатын» адамдар азағанда, кездейсоқ қателіктер азаяды. Құқықтардың минималды қағидасын ұстанып, бөлек аккаунттарды, журналдауды пайдаланыңыз және төтенше қолжетімдікті қолданудың нақты ережесін алдын ала жасаңыз.

Эксплуатация және бақылау: өсім апатқа әкелмеу үшін

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

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

Ерте белгі беретін симптомдар скучно көрінсе де, олар тоқтаудан құтқарады: CRC/input errors өсімі, микрожоғалулар және дроптар айқын шамадан тыс емес жағдайда, нақты модульдің температурасының көтерілуі немесе вентилятор айналымының күрт өсуі, линктің «флап» жасауы, қуат бойынша ескертулер.

Порогтар мен алерттер консервативті және сирек болуы тиіс, әйтпесе хабарламалар оқылмай қалады. Мысалы: ұзақ уақыт бойы 70–80% жоғары жүктемеге арналған бөлек алерт (бір минуттық пик емес), өсіп жатқан кез келген қателерге бөлек хабар, температура мен қуаттағы ауытқуларға бөлек ескерту. Жақсы тәжірибе — өзгерістер мен өсу болған сайын тоқсан сайын порогтарды қайта қарау.

Тұрақты тексерулер желіні қалыпта ұстайды: апталық — қателер мен «ыстық» порттардың қысқаша шолуы; ай сайын — шасси күйінің (температура, вентиляторлар, PSU, логтар) сәйкестігін тексеру; ірі өзгерістен бұрын — нұсқалар мен модульдердің күйінің, бос ресурстардың бақылау нүктесі.

Әрқашан ядроның «паспортын» жүргізіңіз: NX‑OS нұсқалары, орнатылған модульдер мен сериялық нөмірлері, қуат және қосылу схемалары, жұмыс деректері, анықталған тәуекелдер және қабылданған шаралар. 1,5 жылдан кейін линейлы картаны тез қосу немесе оптиканы ауыстыру қажет болғанда бұл паспорт бірнеше сағатты үнемдейді.

Сценарий мысалы: күрделендірмей өсіп жатқан ДҚО үшін ядро

Шарттар: бір ДҚО‑да екі зал, критикалық қызметтер 24/7 (виртуализация, дерекқорлар, VDI және бірнеше мемлекеттік сервистер). Сервер паркі жылына 30% өседі, east‑west ағындары мен өзгерістерге болжамдылық талаптары артады. Мақсат — үш жыл ішінде архитектураны қайта «қайрастыруға» мәжбүрлемейтін ядро жобалау.

3 жылдық сатып алу жоспары: не қазір, не опция ретінде

Бастапқыда әр залға бірінен біреу етіп екі Nexus 9500 шасси қарастырылады және сыйымдылық 3‑ші жылдың мақсатты жүктемесі бойынша плюс запас есептеледі. Бастапқыда барлық слоттарды толтыруға тырыспай, өсуге және жоғары жылдамдыққа ауысқанда модульдерді алмастыруға орын қалдырылады.

Әдеттегі жоспар:

• Год 0: екі шасси, supervisor резерві, қазіргі 10/25G және аплинктерге арналған базалық линейлы карталар;\n- Год 1: жаңа стойкаларға арналған линейлы карталарды қосу, залдар арасындағы аплинктерді кеңейту;\n- Год 2: кейбір қосылымдарды 100G‑қа (немесе жоғары) ауыстыру және жаңа сервистерге порттар қосу;\n- Год 3: 1–2 линейлы картаны жылдам/көбіктік карталарға ауыстыру, шассиді алмастырмай.

Реал схемадағы резервтеу қалай көрінеді

Екі шасси біртұтас ядро ретінде жұмыс істейді, әр критикалық нода «крест‑накрест» жалғанады: әр залға бір аплинк. Залдар арасында екі тәуелсіз трасса (әртүрлі кабель жолдары мен енгізулер). Қуат бойынша — екі енгізу және блоктарды әртүрлі PDU‑ларға бөлу. Бұл аппараттық ғана емес, инфрақұрылымдық «жалғыз нүкте ақауы» тәуекелін азайтады.

NX‑OS бойынша кесте әдетте қарапайым: жылына бір рет үлкен апгрейд алдын ала келісілген терезеде, қауіпсіздік патчтары — жиірек (мысалы, тоқсанда бір рет) тест контурында тексеріп, нақты кері қайтару жоспары бар түрде.

Тәуекелдер мен шараларды алдын ала бекітіңіз: жеткізу бойынша өзара алмастырылатын модульдер тізімін ұстаңыз және уақыт бойынша запас жоспарлаңыз; терезелер бойынша 2–3 нұсқаны алдын ала келісіңіз; инсандар факторы үшін өзгерістер шаблондарын, peer review және чек‑лист енгізіңіз; NX‑OS, модульдер мен оптиканың үйлесімділігін матрицаларда жүйелі тексеріңіз; күтпеген өсім үшін порттар мен қуатта буфер ұстаңыз.

Қысқа чеклист: сатып алу және өзгерістер алдында

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

Жылдам тексеру (10–15 минут)

• Ең жақын 12–18 айға сыйымдылық: порттар мен аплинктер болжамы нақты командалардың сұранысымен сәйкес пе және қор бар ма.\n- Желілік құрылғылар мен компоновка: өсуге және карталарды ауыстыруға слоттар қалды ма, N+1 қуатқа жеткілікті ме, тұтыну стойка мен PDU лимиттеріне сай па.\n- Одақтассыз төзімділік: қуат бөлу (түрлі енгізулер, PDU), трассалар (түрлі лотктар/стойкалар), жасырын ортақ нүктелер жоқ па.\n- Жаңарту және кері қайтару жоспары: терезе келісілді ме, жауаптылар анық па, «барлығы жақсы» критерийлері бар ма және кері қайтару қадамы нақты ма.\n- Құжаттар мен фактілер: схема мен шындық сәйкес пе, конфигурациялар жаңартылған ба, модульдер тізімі, SFP/QSFP, NX‑OS нұсқасы және тәуелділіктер тізімі (vPC‑жұптары, BGP/OSPF көршілер, қосылған фабрикалар, L2 шлюздер).

Қорыта айтқанда: Nexus 9500 базасында ядро көбіне шасси таңдауында емес, айналасындағы ұсақ‑ұсақ нәрселерде — қуат, трассалар, слот резерві және өзгерістер тәртібінде «сынып қалады».

Кіші мысал: келесі кварталда 8 жаңа 100G аплинк қосу планируется. Чеклист арқылы тексеріп көрсеңіз, порттар бар, бірақ қуат бойынша резерв жоқ: бір PSU істен шыққанда шасси рұқсат етілген режимнен шығады. Мұны оптика сатып алып, стойкада жұмыс жүргізбестен бұрын түзету жақсы.

Келесі қадамдар: жоспарды жұмыс істейтін ядроға қалай айналдыру

Кіріс деректерді рәсімдеуден бастаңыз. Бір файлда үш жылдық өсім кестесі мен ағымдағы және мақсатты ядро схемасын ұстау қолайлы.

Кестеде әдетте 10–15 жол жеткілікті: қосылым түрлері (серверлер, ToR, шекара, SAN), ағымдағы жылдамдық және порт саны, тоқсан/жыл бойынша болжам, резервке арналған бөлек баған. Схемада қай шасси мен сымдар қазір критикалық екені және қай жерде кеңейту нүктесі (бос слоттар, стойкадағы орын, қуат, оптика) белгіленуі тиіс.

Содан кейін сатып алудан және миграциядан бұрын тәуекелдерді ревизиялаңыз: қуат (екі тәуелсіз сызық, нақты тұтыну, PDU бойынша запас), трассалар мен оптика (бөлу, ұзындық, модуль түрлері), ортақ нүктелер (OOB‑басқару, NTP/DNS/AAA, лог жинау), процестер (кім өзгерістерді мақұлдайды, кім кері қайтарады, түнде кім байланыста).

Жаңартулар саясатын алдын ала келісіңіз: қаншалықты жиі жаңартасыз, қандай терезелер қабылданады, не сәттілік критерийі және қандай жағдайда кері қайтуға шешім қабылданады.

Кеңейту жоспарын кезеңдеп жасаған дұрыс: не қашан дық, қандай тексерулерден өтуі тиіс (стенд немесе пилот, конфигурация тексерісі, ақау тесті), алғашқы 48 сағатта қай метрикаларды қадағалайтыныңыз.

Егер алаңды тексеретін, жобалайтын, енгізетін және қолдайтын ресурстар жетіспесе, интеграторды тартыңыз — анық процессі бар серіктормен. Қазақстанда мұндай тапсырмаларды GSE.kz (gse.kz) шешеді: жобалаудан бастап жүйелік интеграцияға, тәулік бойы техникалық қолдау мен сервис желісіне дейін.