Leaf-spine желісі ЦОД: қашан екідеңгейлі схемадан көшу керек

Неліктен ЦОД-та желі топологиясын өзгерту керек\n\nЦОД шағын болғанда желі көбіне ұшты-күйлі болмай жұмыс істейді. Бірнеше ToR коммутаторы, жұп агрегация — бәрі түсінікті. Қиындықтар іске қосу күні емес, жаңа шкафтар, сервистер мен жылдамдық талаптары пайда болғанда басталады.\n\nӘдетте бірінші көрінетін мәселе «жетпейтін өткізу қабілеті» емес, кішігірім бірақ жүйелі проблемалардың жиынтығы: қажет жерде порт жетіспейді, аплинктер мен патчкордтар саны өседі, бірдей конфигурацияларды ұстап тұру қиындайды, ал кез келген кеңейту тоқтатулары бар жобаға айналады. Сонымен қатар кешігулердің секірістері аплинктердің шамадан тыс жүктелуінен пайда болады, east-west трафик өседі (серверлер арасындағы), oversubscription болжамы күрделенеді.\n\nБелгілі бір сәтте сіз тек құрал-жабдықпен ғана емес, желінің «геометриясы» арқылы да шектелесіз. Сол кезде сұрақ туындайды: классикалық екідеңгейлі желіні әрі қарай ұлғайту ма, әлде leaf-spine-ге өту ме, онда масштабтау мен трафик жолдары басқа тәртіпте ұйымдастырылған.\n\nКөбіне салыстырады:\n\n- Екідеңгейлі схема (қол жеткізу + агрегация), мұнда өсу аплинктер қосу немесе агрегацияны күшейту арқылы жүреді.\n- Leaf-spine, мұнда шкафтар leaf-ке қосылады, ал leaf барлық spine-лерге бірдей ережемен қосылады.\n\nШешім қабылдау үшін «көзге қарап» емес, қандай жүктемелерде топологияны өзгерту тиімді екенін, жабдық сатып алмас бұрын қандай метрикаларды бақылау керектігін және коммутаторлар мен оптикаға (10G, 25G, 100G және жоғары) қандай талап қою керектігін білу маңызды, сонда желі кейін қайта жасалмай-ақ өседі.\n\n## Екідеңгейлі және leaf-spine қарапайым тілмен\n\nЕкідеңгейлі ЦОД желісі әдетте былай көрінеді: шкафтарда қол жеткізу коммутаторлары (ToR немесе EoR), жоғарыда — жұп күшті агрегациялық немесе ядролық коммутаторлар. Серверлер қол жеткізуге қосылады, қол жеткізу аплинктер арқылы агрегацияға көтеріледі, одан әрі трафик басқа шкафтарға немесе сыртқы қолданушылар мен сервистерге шығады.\n\nLeaf-spine басқа принципте. Leaf-коммутаторлар серверлердің жанында, ToR тәрізді, бірақ әр leaf бір агрегация деңгейіне емес, барлық spine-лерге қосылады. Spine ортақ «фабрика» құрайды: кез келген екі шкаф арасында бірнеше тең мәнді жолдар бар және маршрутизация ағындарды бөледі.\n\nАйырмашылық ең айқын east-west трафикте (серверлер арасындағы). Екідеңгейлі схемада шкафтар арасындағы алмасу жиі агрегация арқылы өтеді, және жүктеме өскенде сол жерде тар шұңқыр пайда болады. Leaf-spine жүйесінде алмасу көбіне leaf -> spine -> leaf арқылы өтеді, яғни жолдар саны көбінесе бірдей. North-south (пайдаланушыларға, интернетке) үшін екеуі де жұмыс істей алады, бірақ leaf-spine әдетте «ортаны» қайта құрусыз кеңейтуге жеңіл.\n\nҚысқаша:\n\n- Кешігулер: leaf-spine-те олар болжамдырақ, жолдар бірдей болғандықтан.\n- Масштабтау: екідеңгейлі схема ядроға ұрасады, ал leaf-spine-те leaf немесе spine қосып өсесіз.\n- Кабельдер: leaf-spine көп шкафаралық қосылыстар талап етеді, бірақ ядроға тән «ерекше» сілтемелер азаяды.\n- Oversubscription: leaf-spine-те түсінікті коэффициенттер ұстау оңайырақ, бірақ оларды алдын ала жобалау керек.\n\nМысал: виртуализация кластері немесе мәліметтер базасы түрлі шкафтар арасында белсенді сөйлессе, leaf-spine оң әсерін тез көрсетеді — жоғарғы деңгейдегі кезектер азаяды және жауап уақыты тұрақтырақ болады.\n\n## Қашан екідеңгейлі схема әлі де жақсы таңдау болып қалады\n\nЕкідеңгейлі желі (қол жеткізу + агрегация) «соқыр» қарапайымдылығы — оның артықшылығы. Егер ЦОД шағын және өсім алдын ала анықталған болса, аз құрылғы, кабель және конфигурация арқылы жұмыс істейтін схема аласыз. Мұндай жағдайда leaf-spine артықша күрделілік әкелуі мүмкін.\n\nЕң жиі сценарий — шамамен 3–10 шкаф, серверлер негізінен интернетке, пайдаланушыларға және орталық сервистерге шығады; сол кезде қарапайымдық пен құны маңызды, ал ерекше масштабталу қажеттілігі аз.\n\n### Трафик негізінен north-south болса\n\nЕгер сервистер дәстүрлі (пошта, файлдық ресурстар, ERP, домен қызметтері, VDI) болса, серверлердің көп бөлігі сыртқа шығатын болса, екідеңгейлі схема әдетте жеткілікті, егер қол жеткізудегі аплинктер агрегацияға қарай айқын тарлық тудырмаса.\n\nҚалдыруға болатын белгілер:\n\n- шкафтар аз, өсу сирек және ұсақ қадамдармен\n- тығыз east-west кластерлері жоқ\n- қарапайым авариялық сценарийлер мен диагностика маңызды\n- бюджет шектеулі, желіні ғана емес, серверлер мен СХД-ны да жаңарту керек\n- команда шағын және күрделі өзгерістерге ресурстар жоқ\n\nМысал: өңірлік ұйым 6 шкафпен виртуализация, телефония, ERP және резервтік көшіруді ұстайды. Шаңдағы шыңдар бар, бірақ ішкі алмасу орташа. Мұндай ЦОД-та сенімді қол жеткізу коммутаторлары мен аплинктерге инвестиция салған дұрыс, топологияны қайта жобалау емес.\n\nЕгер сатып алулар мен енгізуді кешенді жоспарласаңыз (серверлер, шкафтар, желі, қолдау), интеграторлар (мысалы, GSE.kz) әдетте алдымен трафик профилін және өсу жоспарын қарайды, «модалы» схеманы емес.\n\n## Қай мөлшерде және қандай жүктемеде leaf-spine мағыналы\n\nLeaf-spine-ге өту нақты «қанша шкафтан кейін» емес, алдын ала айқынырақ болжам мен біртекті мінез маңызды болғанда тиімді болады. Егер ағымдардың көп бөлігі сыртқа емес, серверлер арасында (east-west) жүрсе, екідеңгейлі схема жиі тар шұңқырға ұшырайды.\n\nКүшті сигнал — east-west трафиктің өсуі: виртуализацияның көбеюі, VM миграциялары, кластер платформалар, репликациялар және желідегі резервтік көшіру. Екідеңгейлі желіде кейбір шкафтар ресурстарға «жақын», кейбірі «алыс» болып, кешігулер мен жылдамдық бағытқа байланысты секіріп отырады.\n\nТағы бір белгі — жүйелі кеңейту. Әр бірнеше айда шкаф қосқан кезде жаңа ToR-ды конструктор сияқты қосқыңыз келсе — leaf қосып, аплинктерді көтеріп, көршілермен бірдей сипаттамалар алу жеңіл болуы тиіс.\n\nLeaf-spine-ті жиі таңдайды, егер керек болса:\n\n- кез келген шкафтар арасындағы кешігулер мен өткізу қабілетін біркелкі ету\n- айтарлықтай ішінара масштабтау үлкен қайта жасауларсыз\n- өсуге қарай 25/100/200/400G-ке өту жоспарын жеңілдету\n- әр leaf-тегі oversubscription-ды бақылау, ал «күзгісі сияқты» емес\n\nМысал: бұрын 6 шкаф болды және түнгі бэкаптар сирек болатын. Кейін виртуализация кластері, деректер репликациясы және күнделікті бэкаптар қосылды. Шкафтар арасындағы трафик тұрақты түрде өтіп, сол кезде leaf-spine тез әсер береді: күтпеген тар шұңқырлар азаяды және жылдамдық пен порттарды жоспарлау оңайырақ.\n\n## Қалай шешім қабылдау: ЦОД үшін кезең-кезең бағалау\n\nLeaf-spine-ке көшу шешімі цифрларға сүйенеді: шкаф саны, сервер жылдамдықтары, ішкі трафик пен өсу резерві.\n\nТексеру қадамдары:\n\n- Ағымдағы және мақсатты масштабтарды анықтаңыз: шкафтар мен серверлер саны, әр шкафқа қанша порт қажет, қол жеткізу жылдамдығы (10G, 25G) және жоғары (40G, 100G). Қазір не бос емес және бір жылдан кейін не жоспарланғанын есептеңіз.\n- Трафик профилін өлшеңіз: east-west пе әлде north-south па басым. Уақыт бойынша шыңдарды және сервистерді қараңыз (мысалы, түнгі бэкаптар, ай соңындағы есептер).\n- Leaf үшін және бүкіл фабрикаға арналған мақсатты oversubscription таңдаңыз. Ішкі алмасулар көп болса, шкафта 1:1-ге жақын болуға ұмтыласыз.\n- 2–3 жылға архитектураны алдын ала есептеп көріңіз: әр leaf-ке қанша аплинк керек, қанша spine қажет және порт резерві қандай. Егер бір жылдың ішінде порттар немесе жылдамдықтар жетпейтін болса, бұл тікелей сигнал.\n- Физикалық шектеулерді тексеріңіз: шкафтағы орын, патч-панельдер, қуат және салқындату, кабель маршруттары. Көбінесе кабель тығыздығы мен лотоктағы орын кедергі болады.\n\nҚысқа мысал: қазір 8 шкаф, әрқайсында 20 сервер 10G-пен, трафик негізінен north-south болса, екідеңгейлі схема тыныш тұрады. Бірақ егер бір жыл ішінде 24 шкафқа, сервер порттарын 25G-ге көшіруге және кластерлерді қосуға жоспар болса, east-west үлесі тез өседі — сонда фабриканы алдын ала жобалау оңайырақ болуы мүмкін, кейін аплинктерді «латтау» және ядроны бөліп ауыстырудан гөрі.