Біз секундына бір петабайттан асатын өткізу қабілеттілігінің ең жоғары биссекциясы бар 100 мыңнан асатын серверлерді есептеу кластерлерін орналастыруға мүмкіндік беретін деректер орталығының желісінің дизайнын әзірледік.
Дмитрий Афанасьевтің баяндамасынан сіз жаңа дизайнның негізгі принциптері, масштабтау топологиялары, осыған байланысты туындайтын мәселелер, оларды шешу нұсқалары, «тығыз қосылған» заманауи желілік құрылғылардың бағыттау және бағыттау жазықтығының функцияларын масштабтау ерекшеліктері туралы білесіз. ECMP маршруттарының үлкен саны бар топологиялар . Сонымен қатар, Дима сыртқы қосылымды ұйымдастыру, физикалық деңгей, кабельдік жүйе және өткізу қабілетін одан әрі арттыру жолдары туралы қысқаша айтып берді.
- Қайырлы күн баршаңызға! Менің атым Дмитрий Афанасьев, мен Яндекстің желі сәулетшісімін және ең алдымен деректер орталығының желілерін жобалаумен айналысамын.
Менің әңгімем Яндекс деректер орталықтарының жаңартылған желісі туралы болмақ. Бұл бізде болған дизайнның эволюциясы, бірақ сонымен бірге кейбір жаңа элементтер бар. Бұл шолу презентациясы, себебі аз уақыт ішінде жинақталатын ақпарат көп болды. Біз логикалық топологияны таңдаудан бастаймыз. Содан кейін басқару жазықтығына шолу және деректер жазықтығының масштабталуына қатысты мәселелер, физикалық деңгейде не болатынын таңдау және құрылғылардың кейбір мүмкіндіктерін қарастырамыз. Біраз уақыт бұрын біз айтқан MPLS деректер орталығында не болып жатқанына аздап тоқталайық.
Сонымен, жүктемелер мен қызметтер бойынша Яндекс қандай? Яндекс - бұл әдеттегі гипершкалалер. Пайдаланушыларға қарасақ, біз ең алдымен пайдаланушы сұрауларын өңдейміз. Сондай-ақ әртүрлі ағындық қызметтер және деректерді тасымалдау, өйткені бізде сақтау қызметтері де бар. Егер серверге жақынырақ болса, онда бөлінген нысанды сақтау, деректерді репликациялау және, әрине, тұрақты кезектер сияқты инфрақұрылымдық жүктемелер мен қызметтер пайда болады. Жұмыс жүктемелерінің негізгі түрлерінің бірі MapReduce және ұқсас жүйелер, ағынды өңдеу, машиналық оқыту және т.б.
Мұның бәрі болып жатқан инфрақұрылым қалай? Тағы да, біз өте типтік гипершкалерлерміз, дегенмен біз спектрдің кішірек гипершкалалық жағына жақынырақ болуымыз мүмкін. Бірақ бізде барлық қасиеттер бар. Мүмкіндігінше біз тауарлық жабдықты және көлденең масштабтауды қолданамыз. Бізде толық ресурстарды біріктіру бар: біз жеке машиналармен, жеке тіректермен жұмыс істемейміз, бірақ оларды жоспарлаумен және бөлумен айналысатын кейбір қосымша қызметтермен ауыстырылатын ресурстардың үлкен пулына біріктіреміз және осы бүкіл пулмен жұмыс істейміз.
Сонымен бізде келесі деңгей – есептеу кластері деңгейіндегі операциялық жүйе бар. Біз қолданатын технология стекін толық бақылау өте маңызды. Біз соңғы нүктелерді (хосттарды), желіні және бағдарламалық жасақтаманы басқарамыз.
Бізде Ресейде және шетелде бірнеше ірі деректер орталықтары бар. Оларды MPLS технологиясын пайдаланатын магистраль біріктіреді. Біздің ішкі инфрақұрылымымыз толығымен дерлік IPv6 негізінде құрылған, бірақ біз әлі де негізінен IPv4 арқылы келетін сыртқы трафикке қызмет көрсетуіміз керек болғандықтан, біз қандай да бір жолмен IPv4 арқылы келетін сұрауларды алдыңғы серверлерге жеткізуіміз керек, ал сыртқы IPv4- Интернетке сәл көбірек өтуіміз керек. мысалы, индекстеу үшін.
Деректер орталығының желілік конструкцияларының соңғы бірнеше итерациясында көп деңгейлі Clos топологиялары қолданылды және тек L3-ке арналған. Біз L2-ден сәл бұрын шығып, жеңіл тыныс алдық. Соңында, біздің инфрақұрылым жүздеген мың есептеу (сервер) даналарын қамтиды. Біраз уақыт бұрын кластердің максималды өлшемі шамамен 10 мың сервер болды. Бұл негізінен сол кластер деңгейіндегі операциялық жүйелердің, жоспарлаушылардың, ресурстарды бөлудің және т.б. қалай жұмыс істей алатынына байланысты.Инфрақұрылымдық бағдарламалық қамтамасыз ету жағында ілгерілеушілік орын алғандықтан, мақсатты өлшем енді бір есептеу кластеріндегі шамамен 100 мың сервер және Біздің міндетіміз – осындай кластерде ресурстарды тиімді біріктіруге мүмкіндік беретін желілік зауыттарды құра алу.
Деректер орталығының желісінен бізге не қажет? Біріншіден, арзан және жеткілікті түрде біркелкі бөлінген өткізу қабілеттілігі көп. Өйткені желі – біз ресурстарды біріктіре алатын тірек. Жаңа мақсатты өлшем - бір кластерде шамамен 100 мың сервер.
Біз сондай-ақ, әрине, масштабталатын және тұрақты басқару ұшағын қалаймыз, өйткені мұндай үлкен инфрақұрылымда көптеген бас аурулары жай кездейсоқ оқиғалардан туындайды және біз басқару ұшағы бізге бас ауруын әкелгенін қаламаймыз. Сонымен бірге ондағы мемлекетті барынша азайтқымыз келеді. Жағдай неғұрлым аз болса, соғұрлым бәрі жақсы және тұрақтырақ жұмыс істейді және диагноз қою оңайырақ болады.
Әрине, бізге автоматтандыру керек, өйткені мұндай инфрақұрылымды қолмен басқару мүмкін емес және біраз уақыттан бері бұл мүмкін емес. Бізге мүмкіндігінше операциялық қолдау және CI/CD қолдауы мүмкін болатын дәрежеде қажет.
Деректер орталықтары мен кластерлердің осындай өлшемдерімен қызмет үзіліссіз қосымша орналастыру мен кеңейтуді қолдау міндеті өте өткір болды. Егер мың машинаның кластерлерінде, мүмкін он мыңға жуық машина болса, олар әлі де бір операция ретінде шығарылуы мүмкін болса, яғни біз инфрақұрылымды кеңейтуді жоспарлап отырмыз және бір операция ретінде бірнеше мың машина қосылса, онда жүз мың машинаға тең кластер бұлай бірден пайда болмайды, ол белгілі бір уақыт аралығында құрастырылады. Осы уақыт ішінде қазірдің өзінде шығарылған нәрсенің, орналастырылған инфрақұрылымның қолжетімді болғаны жөн.
Бізде қалдырған және қалдырған бір талап: көп жалға алуды қолдау, яғни виртуалдандыру немесе желіні сегменттеу. Енді бізге мұны желілік мата деңгейінде жасаудың қажеті жоқ, өйткені бөлшектеу хосттарға өтті және бұл біз үшін масштабтауды өте оңай етті. IPv6 және үлкен мекенжай кеңістігінің арқасында бізге ішкі инфрақұрылымда қайталанатын мекенжайларды пайдаланудың қажеті болмады; барлық адрестеу қазірдің өзінде бірегей болды. Біз хосттарға сүзгілеу мен желі сегментациясын қабылдағанымыздың арқасында деректер орталығы желілерінде виртуалды желі нысандарын жасаудың қажеті жоқ.
Өте маңызды нәрсе - бізге қажет емес нәрсе. Кейбір функцияларды желіден алып тастау мүмкін болса, бұл өмірді айтарлықтай жеңілдетеді және, әдетте, диагностиканы өте қарапайым етіп, қол жетімді жабдық пен бағдарламалық жасақтаманы таңдауды кеңейтеді.
Сонымен, бізге не қажет емес, біз неден бас тарта алдық, әрқашан болған сәтте қуанышпен емес, процесс аяқталған кезде үлкен жеңілдікпен?
Ең алдымен, L2-ден бас тарту. Бізге нақты да, эмуляцияланған да L2 қажет емес. Қолданбалар стегін басқаратынымызға байланысты пайдаланылмайды. Біздің қолданбаларымыз көлденең масштабталады, олар L3 адресациясымен жұмыс істейді, олар кейбір жеке дананың өшіп қалғанына қатты алаңдамайды, олар жай ғана жаңасын шығарады, оны ескі мекенжайда шығарудың қажеті жоқ, өйткені бар кластерде орналасқан машиналарды ашу және бақылау қызметінің бөлек деңгейі. Біз бұл тапсырманы желіге бермейміз. Желінің жұмысы пакеттерді А нүктесінен В нүктесіне жеткізу болып табылады.
Сондай-ақ бізде мекенжайлар желі ішінде қозғалатын жағдайлар жоқ және бұл бақылауды қажет етеді. Көптеген дизайндарда бұл әдетте VM ұтқырлығын қолдау үшін қажет. Біз үлкен Яндекстің ішкі инфрақұрылымында виртуалды машиналардың ұтқырлығын пайдаланбаймыз, сонымен қатар, егер бұл орындалса да, желілік қолдаумен болмауы керек деп санаймыз. Егер сізге мұны шынымен жасау керек болса, оны хост деңгейінде орындау керек және астыңғы қабаттың маршруттау жүйесіне (көлік желісі) тиіп кетпеу немесе тым көп динамикалық өзгерістер жасамау үшін қабаттасуға көшуі мүмкін мекенжайларды итеру керек. .
Біз пайдаланбайтын тағы бір технология – мультикаст. Қаласаңыз, себебін егжей-тегжейлі айта аламын. Бұл өмірді әлдеқайда жеңілдетеді, өйткені егер біреу онымен айналысып, мультикастты басқару ұшағы қалай көрінетінін қараса, қарапайым қондырғылардан басқасының бәрінде бұл үлкен бас ауруы. Оның үстіне, мысалы, жақсы жұмыс істейтін ашық бастапқы енгізуді табу қиын.
Ақырында, біз желілерді тым көп өзгермейтіндей етіп жасаймыз. Маршрутизация жүйесіндегі сыртқы оқиғалар ағыны аз екеніне сене аламыз.
Дата-орталық желісін дамыту кезінде қандай мәселелер туындайды және қандай шектеулерді ескеру қажет? Құны, әрине. Масштабтау мүмкіндігі, біз өскіміз келетін деңгей. Қызметті тоқтатпай кеңейту қажеттілігі. Өткізу қабілеті, қолжетімділігі. Мониторинг жүйелері, жедел топтар үшін желіде не болып жатқанын көру. Автоматтандыруды қолдау - қайтадан мүмкіндігінше, өйткені әртүрлі тапсырмаларды әртүрлі деңгейлерде шешуге болады, соның ішінде қосымша қабаттарды енгізу. Ал, [мүмкін] жеткізушілерге тәуелді емес. Әртүрлі тарихи кезеңдерде қай тарауға қарағаныңызға байланысты бұл тәуелсіздікке жету оңайырақ немесе қиынырақ болды. Егер біз желілік құрылғының чиптерінің көлденең қимасын алатын болсақ, онда соңғы уақытқа дейін жеткізушілерден тәуелсіздік туралы айту өте шартты болды, егер біз жоғары өткізу қабілеті бар чиптерді де қаласақ.
Желімізді құру үшін қандай логикалық топологияны қолданамыз? Бұл көп деңгейлі Clos болады. Шын мәнінде, қазіргі уақытта нақты балама жоқ. Clos топологиясы, тіпті егер бізде үлкен радикс қосқыштары болса, қазір академиялық қызығушылық аймағындағы әртүрлі кеңейтілген топологиялармен салыстырғанда өте жақсы.
Көп деңгейлі Clos желісі шамамен қалай құрылымдалған және ондағы әртүрлі элементтер қалай аталады? Ең алдымен жел көтерілді, солтүстік қайда, оңтүстік қайда, шығыс қай жерде, батыс қайда екенін бағдарлау үшін. Бұл типтегі желілерді әдетте батыс-шығыс трафигі өте үлкен адамдар салады. Қалған элементтерге келетін болсақ, жоғарғы жағында кішігірім қосқыштардан жиналған виртуалды қосқыш бар. Бұл Clos желілерінің рекурсивті құрылысының негізгі идеясы. Біз қандай да бір радикс түрі бар элементтерді аламыз және алынған нәрсені үлкенірек радикспен ауыстырғыш ретінде қарастыру үшін оларды байланыстырамыз. Егер сізге одан да көп қажет болса, процедураны қайталауға болады.
Жағдайларда, мысалы, екі деңгейлі Clos, менің диаграммамда тік орналасқан құрамдастарды нақты анықтау мүмкін болған кезде, олар әдетте жазықтықтар деп аталады. Егер біз үш деңгейлі омыртқа қосқыштары бар Clos құрастыратын болсақ (олардың барлығы шекаралық емес немесе ToR қосқыштары емес және тек транзит үшін пайдаланылады), онда ұшақтар күрделірек көрінеді; екі деңгейлілер дәл осылай көрінеді. Біз ToR немесе жапырақ қосқыштарының блогын және олармен байланысты бірінші деңгейлі омыртқа қосқыштарын Pod деп атаймыз. Подтың жоғарғы жағындағы омыртқа-1 деңгейіндегі омыртқа қосқыштары Pod жоғарғы жағы, Pod жоғарғы жағы. Бүкіл зауыттың жоғарғы жағында орналасқан қосқыштар - бұл зауыттың жоғарғы қабаты, Матаның жоғарғы жағы.
Әрине, сұрақ туындайды: Clos желілері біраз уақыттан бері салынған; идеяның өзі әдетте классикалық телефония, TDM желілері дәуірінен келеді. Мүмкін жақсырақ нәрсе пайда болды, мүмкін жақсырақ нәрсе жасауға болады ма? Иә және жоқ. Теориялық тұрғыдан иә, іс жүзінде жақын арада жоқ. Бірқатар қызықты топологиялар болғандықтан, олардың кейбіреулері тіпті өндірісте қолданылады, мысалы, Dragonfly HPC қосымшаларында қолданылады; Сонымен қатар Xpander, FatClique, Jellyfish сияқты қызықты топологиялар бар. Жақында SIGCOMM немесе NSDI сияқты конференциялардағы есептерді қарасаңыз, Clos-қа қарағанда жақсы қасиеттері (бір немесе басқа) бар балама топологиялар бойынша жұмыстардың айтарлықтай көп санын таба аласыз.
Бірақ бұл топологиялардың барлығының бір қызықты қасиеті бар. Бұл оларды біз тауарлық аппараттық құралдарға негіздеуге тырысып жатқан және айтарлықтай ақылға қонымды ақша тұратын деректер орталықтарының желілерінде енгізуге жол бермейді. Осы балама топологиялардың барлығында өткізу қабілеттілігінің көп бөлігі, өкінішке орай, ең қысқа жолдар арқылы қол жетімді емес. Сондықтан біз дәстүрлі басқару ұшағын пайдалану мүмкіндігін бірден жоғалтамыз.
Теориялық тұрғыдан мәселенің шешімі белгілі. Бұл, мысалы, k-ең қысқа жолды қолданатын сілтеме күйінің модификациялары, бірақ тағы да өндіріске енгізілетін және жабдықта кеңінен қол жетімді мұндай хаттамалар жоқ.
Сонымен қатар, сыйымдылықтың көп бөлігіне ең қысқа жолдар арқылы қол жеткізу мүмкін болмағандықтан, біз сол жолдардың барлығын таңдау үшін басқару жазықтығынан да көп нәрсені өзгертуіміз керек (және айтпақшы, бұл басқару жазықтығында айтарлықтай көбірек күй). Бізге әлі де жіберу ұшағын өзгерту керек және, әдетте, кем дегенде екі қосымша мүмкіндік қажет. Бұл пакетті бір реттік бағыттау туралы барлық шешімдерді қабылдау мүмкіндігі, мысалы, хостта. Шындығында, бұл бастапқы маршруттау, кейде өзара байланыс желілері туралы әдебиеттерде бұл бірден бағыттау шешімдері деп аталады. Ал адаптивті маршруттау - бұл желі элементтеріне қажет функция, ол, мысалы, кезектегі ең аз жүктеме туралы ақпарат негізінде келесі секіруді таңдағанымызға дейін төмендейді. Мысал ретінде, басқа нұсқалар мүмкін.
Осылайша, бағыт қызықты, бірақ, өкінішке орай, біз оны дәл қазір қолдана алмаймыз.
Жарайды, біз Clos логикалық топологиясына тоқтадық. Оны қалай кеңейтеміз? Оның қалай жұмыс істейтінін және не істеуге болатынын көрейік.
Clos желісінде біз қандай да бір жолмен өзгерте алатын және белгілі бір нәтижелерді ала алатын екі негізгі параметр бар: элементтердің радикасы және желідегі деңгейлер саны. Менде екеуінің де өлшемге қалай әсер ететіні туралы схемалық диаграмма бар. Ең дұрысы, біз екеуін біріктіреміз.
Clos желісінің соңғы ені оңтүстік радикстің омыртқа қосқыштарының барлық деңгейлерінің өнімі екенін көруге болады, бізде қанша сілтеме бар, ол қалай тармақталған. Осылайша біз желінің көлемін ұлғайтамыз.
Сыйымдылыққа қатысты, әсіресе ToR қосқыштарында, масштабтаудың екі нұсқасы бар. Немесе жалпы топологияны сақтай отырып, жылдамырақ сілтемелерді пайдалана аламыз немесе көбірек жазықтықтарды қоса аламыз.
Егер сіз Clos желісінің кеңейтілген нұсқасын (төменгі оң жақ бұрышта) қарасаңыз және төмендегі Clos желісі арқылы осы суретке оралсаңыз...
... онда бұл дәл сол топология, бірақ бұл слайдта ол ықшамырақ құлап, зауыттың жазықтықтары бір-бірінің үстіне қойылған. Бұл бірдей.
Clos желісін масштабтау сандарда қалай көрінеді? Мұнда мен желінің қандай максималды енін алуға болатыны, тіректердің, ToR қосқыштарының немесе жапырақ қосқыштарының максималды саны туралы деректерді беремін, егер олар сөрелерде болмаса, біз омыртқа деңгейлері үшін қандай қосқыштар радиусын қолданатынымызға байланысты ала аламыз және біз қанша деңгейді қолданамыз.
Міне, бізде қанша сөре болуы мүмкін, қанша сервер және осының барлығы бір тірекке 20 кВт негізінде қанша тұтынылуы мүмкін. Біраз бұрын мен шамамен 100 мың серверді құрайтын кластер көлемін мақсат етіп отырғанымызды айттым.
Бұл дизайнда екі жарым нұсқа қызығушылық тудыратынын көруге болады. Екі қабатты омыртқалар мен 64 портты қосқыштары бар опция бар, ол сәл қысқарады. Содан кейін екі деңгейлі 128 портты (радикс 128 бар) омыртқа қосқыштары немесе үш деңгейлі радикс 32 қосқыштары үшін тамаша сәйкес келетін опциялар бар. Радикстер мен қабаттар көп болған барлық жағдайларда сіз өте үлкен желі жасай аласыз, бірақ күтілетін тұтынуды қарасаңыз, әдетте гигаватт бар. Кабель тартуға болады, бірақ бір учаскеден онша электр қуатын алуымыз екіталай. Деректер орталықтары туралы статистика мен жалпыға ортақ деректерді қарасаңыз, болжамды қуаты 150 МВт-тан асатын деректер орталықтарын өте аз таба аласыз. Үлкендері әдетте деректер орталығының кампустары, бір-біріне өте жақын орналасқан бірнеше үлкен деректер орталықтары.
Тағы бір маңызды параметр бар. Егер сіз сол жақ бағанға қарасаңыз, онда қолданылатын өткізу қабілеттілігі көрсетілген. Clos желісінде порттардың маңызды бөлігі коммутаторларды бір-біріне қосу үшін пайдаланылатынын көру оңай. Қолданылатын өткізу қабілеттілігі, пайдалы жолақ - серверлерге сырттан берілуі мүмкін нәрсе. Әрине, мен шартты порттар туралы және әсіресе топ туралы айтып отырмын. Әдетте, желідегі сілтемелер серверлерге сілтемелерге қарағанда жылдамырақ, бірақ өткізу қабілеттілігінің бірлігіне, біз оны серверлік жабдыққа жібере алатын болсақ, желінің өзінде біршама өткізу қабілеті бар. Біз неғұрлым көп деңгейлер жасасақ, бұл жолақты сыртқа шығарудың нақты құны соғұрлым жоғары болады.
Оның үстіне, бұл қосымша топтың өзі бірдей емес. Аралықтар қысқа болғанымен, біз DAC (тікелей жалғанатын мыс, яғни twinax кабельдері) немесе көп немесе аз ақылға қонымды ақша тұратын мультимодалы оптика сияқты нәрсені пайдалана аламыз. Біз ұзағырақ аралықтарға көшкен кезде - әдетте, бұл бір режимді оптика және бұл қосымша өткізу қабілеттілігінің құны айтарлықтай артады.
Тағы да, алдыңғы слайдқа оралсақ, егер біз артық жазылусыз Clos желісін жасасақ, онда диаграмманы қарау оңай, желінің қалай салынғанын көру - омыртқа қосқыштарының әрбір деңгейін қосып, біз барлық жолақты қайталаймыз. төменгі. Плюс деңгейі - плюс бірдей жолақ, алдыңғы деңгейде болғандай қосқыштардағы порттардың бірдей саны және қабылдағыштардың бірдей саны. Сондықтан омыртқа қосқыштарының деңгейлерінің санын азайту өте қажет.
Осы суретке сүйене отырып, біз шынымен 128 радиусты қосқыштар сияқты нәрсеге құрғымыз келетіні анық.
Мұнда, негізінен, бәрі менің айтқанымдай, бұл кейінірек қарастырылатын слайд.
Мұндай қосқыштар ретінде таңдауға болатын қандай опциялар бар? Біз үшін өте қуанышты жаңалық, енді мұндай желілерді бір чипті коммутаторларда құруға болады. Және бұл өте керемет, оларда көптеген жақсы мүмкіндіктер бар. Мысалы, олардың ішкі құрылымы дерлік жоқ. Бұл олардың оңайырақ сынғанын білдіреді. Олар әртүрлі жолдармен бұзылады, бірақ бақытымызға орай, олар толығымен бұзылады. Модульдік құрылғыларда көптеген ақаулар бар (өте жағымсыз), ол көршілердің және басқарушы жазықтықтың көзқарасы бойынша жұмыс істеп тұрған сияқты болып көрінеді, бірақ, мысалы, матаның бір бөлігі жоғалып кетті және ол жұмыс істемейді. толық қуатта. Ал оған баратын трафик оның толық жұмыс істеуіне байланысты теңдестірілген және біз шамадан тыс жүктелуіміз мүмкін.
Немесе, мысалы, артқы панельде проблемалар туындайды, өйткені модульдік құрылғының ішінде жоғары жылдамдықты SerDes бар - бұл шынымен де күрделі. Қайта жіберу элементтері арасындағы белгілер синхрондалған немесе синхрондалмаған. Жалпы алғанда, көптеген элементтерден тұратын кез келген өнімді модульдік құрылғы, әдетте, өз ішінде бірдей Clos желісін қамтиды, бірақ оны диагностикалау өте қиын. Көбінесе сатушының өзі де диагноз қою қиынға соғады.
Сондай-ақ оның құрылғы нашарлайтын, бірақ топологиядан толығымен шықпайтын көптеген сәтсіздік сценарийлері бар. Біздің желіміз үлкен болғандықтан, бірдей элементтер арасындағы теңгерім белсенді түрде қолданылады, желі өте тұрақты, яғни бәрі реттелген бір жолдың басқа жолдан еш айырмашылығы жоқ, біз үшін кейбірін жоғалтқан тиімдірек. топологияның құрылғылары олардың кейбіреулері жұмыс істейтін сияқты көрінетін, бірақ кейбіреулері жұмыс істемейтін жағдайға тап болғаннан гөрі.
Бір чипті құрылғылардың келесі жағымды ерекшелігі - олар жақсырақ және жылдамырақ дамиды. Олар сондай-ақ жақсы мүмкіндіктерге ие. Егер біз шеңберде орналасқан үлкен жинақталған құрылымдарды алсақ, онда бірдей жылдамдықтағы порттар үшін тірек бірлігінің сыйымдылығы модульдік құрылғыларға қарағанда екі есе дерлік жақсы. Бір микросхеманың айналасында салынған құрылғылар модульдік құрылғыларға қарағанда айтарлықтай арзанырақ және энергияны аз тұтынады.
Бірақ, әрине, мұның бәрі себеп, кемшіліктер де бар. Біріншіден, радиус модульдік құрылғыларға қарағанда әрқашан дерлік аз. Егер біз 128 порты бар бір чиптің айналасында құрастырылған құрылғыны ала алсақ, онда бірнеше жүз порттары бар модульдік құрылғыны қазір еш қиындықсыз ала аламыз.
Бұл қайта жіберу кестелерінің айтарлықтай кішірек өлшемі және, әдетте, деректер жазықтығының масштабталуына қатысты барлық нәрсе. Таяз буферлер. Және, әдетте, шектеулі функционалдылық. Бірақ егер сіз бұл шектеулерді білсеңіз және оларды айналып өтуге уақытында қамқорлық жасасаңыз немесе жай ғана ескерсеңіз, бұл соншалықты қорқынышты емес. Жақында пайда болған 128 радиусты құрылғыларда радикстің кішірек болуы енді проблема емес; біз омыртқаның екі қабатында жасай аламыз. Бірақ біз үшін қызықты екіден кіші нәрсені салу әлі мүмкін емес. Бір деңгеймен өте кішкентай кластерлер алынады. Тіпті бұрынғы дизайнымыз бен талаптарымыз олардан асып түсті.
Шын мәнінде, егер кенеттен шешім табалдырықта болса, масштабтаудың әлі де жолы бар. Серверлер қосылған соңғы (немесе бірінші), ең төменгі деңгей ToR қосқыштары немесе жапырақты қосқыштар болғандықтан, оларға бір тірек қосу талап етілмейді. Сондықтан, егер шешім шамамен жартысына қысқарса, сіз төменгі деңгейде үлкен радиусты қосқышты пайдалану және мысалы, екі немесе үш тіректерді бір қосқышқа қосу туралы ойлай аласыз. Бұл да опция, оның өзіндік құны бар, бірақ ол өте жақсы жұмыс істейді және шамамен екі есе үлкен өлшемге жету қажет болғанда жақсы шешім болуы мүмкін.
Қорытындылай келе, біз сегіз зауыттық қабаты бар екі деңгейлі топологияны құрастырамыз.
Физикамен не болады? Өте қарапайым есептеулер. Егер бізде жұлынның екі деңгейі болса, онда бізде қосқыштардың тек үш деңгейі бар және біз желіде үш кабель сегменті болады деп күтеміз: серверлерден жапырақты қосқыштарға, 1 омыртқаға, 2 омыртқаға. Біз жасай алатын опциялар пайдалану – бұл twinax, multimode, single mode. Бұл жерде біз қандай жолақ бар екенін, оның құны қанша болатынын, физикалық өлшемдері қандай, біз қандай аралықты қамтуға болатынын және біз қалай жаңарту керектігін қарастыруымыз керек.
Құнға келетін болсақ, барлығын ретке келтіруге болады. Twinaxes белсенді оптикаға қарағанда айтарлықтай арзанырақ, мультимодалы қабылдағыштарға қарағанда арзанырақ, егер сіз оны соңынан бастап бір рейске қабылдасаңыз, 100 гигабиттік коммутатор портынан біршама арзанырақ. Және, ескеріңіз, бұл бір режимді оптикаға қарағанда арзанырақ, өйткені бір режим қажет рейстерде деректер орталықтарында бірнеше себептерге байланысты CWDM пайдалану мағынасы бар, ал параллельді жалғыз режим (PSM) жұмыс істеуге өте ыңғайлы емес. бар, өте үлкен пакеттер алынған талшықтар, және егер біз осы технологияларға назар аударсақ, шамамен келесі баға иерархиясын аламыз.
Тағы бір ескертпе: өкінішке орай, бөлшектелген 100-ден 4x25-ке дейінгі мультимодалы порттарды пайдалану өте мүмкін емес. SFP28 трансиверлерінің дизайн ерекшеліктеріне байланысты ол 28 Гбит QSFP100-ден әлдеқайда арзан емес. Ал мультимода үшін бұл бөлшектеу өте жақсы жұмыс істемейді.
Тағы бір шектеу – есептеу кластерлерінің көлеміне және серверлердің санына байланысты біздің деректер орталықтары физикалық түрде үлкен болып шығады. Бұл сингл модымен кем дегенде бір рейс жасау керек дегенді білдіреді. Тағы да, Pods физикалық өлшеміне байланысты екі аралық twinax (мыс кабельдер) жүргізу мүмкін болмайды.
Нәтижесінде, егер біз бағаны оңтайландыратын болсақ және осы дизайнның геометриясын ескерсек, біз CWDM көмегімен бір twinax, бір аралық мультимода және бір аралық режимді аламыз. Бұл ықтимал жаңарту жолдарын ескереді.
Міне, соңғы кездегідей, біз қайда бара жатырмыз және не болуы мүмкін. Кем дегенде, мультимода үшін де, жалғыз режим үшін де 50-Гигабиттік SerDes-ке қалай өту керектігі түсінікті. Сонымен қатар, егер сіз қазір және болашақта 400G үшін бір режимді трансиверлерде не бар екенін қарасаңыз, көбінесе 50G SerDes электрлік жағынан келгенде де, бір жолақ үшін 100 Гбит/с оптикаға өтуі мүмкін. Сондықтан 50-ге көшудің орнына 100 Гигабит SerDes және бір жолақ үшін 100 Гбит/с көшу болуы әбден мүмкін, өйткені көптеген жеткізушілердің уәделері бойынша олардың қол жетімді болуы жақын арада күтілуде. 50G SerDes ең жылдам болған кезең өте ұзақ болмайды, өйткені 100G SerDes алғашқы көшірмелері келесі жылы шығарылады. Біраз уақыттан кейін олар ақылға қонымды ақшаға ие болуы мүмкін.
Физиканы таңдау туралы тағы бір нюанс. Негізінде, біз 400G SerDes көмегімен 200 немесе 50 гигабиттік порттарды пайдалана аламыз. Бірақ мұның мағынасы жоқ екені белгілі болды, өйткені мен жоғарыда айтқанымдай, біз, әрине, ақылға қонымды түрде қосқыштарда жеткілікті үлкен радиусты қалаймыз. Біз 128-ді қалаймыз. Ал егер бізде чиптің сыйымдылығы шектеулі болса және байланыс жылдамдығын арттырсақ, онда радикс табиғи түрде төмендейді, ешқандай кереметтер болмайды.
Біз ұшақтардың көмегімен жалпы сыйымдылықты арттыра аламыз, және арнайы шығындар жоқ, біз ұшақтардың санын қоса аламыз. Ал егер біз радиксті жоғалтсақ, біз қосымша деңгейді енгізуіміз керек, сондықтан қазіргі жағдайда, бір чиптің қазіргі максималды қол жетімді сыйымдылығымен, 100 гигабиттік порттарды пайдалану тиімдірек болып шықты, өйткені олар сізге мүмкіндік береді. үлкенірек радикс алу үшін.
Келесі мәселе - физика қалай ұйымдастырылады, бірақ кабельдік инфрақұрылым тұрғысынан. Бұл біршама күлкілі түрде ұйымдастырылған көрінеді. Жапырақ қосқыштары мен бірінші деңгейлі тікенектер арасындағы кабель - бұл жерде көптеген сілтемелер жоқ, бәрі салыстырмалы түрде қарапайым түрде салынған. Бірақ егер біз бір ұшақты алсақ, онда біз бірінші деңгейдің барлық омыртқаларын екінші деңгейдің барлық омыртқаларымен байланыстыруымыз керек.
Сонымен қатар, әдетте, деректер орталығының ішінде оның қалай көрінетіні туралы кейбір тілектер бар. Мысалы, біз кабельдерді байламға біріктіріп, оларды бір жоғары тығыздықтағы патч-панель толығымен бір патч-панельге кіретіндей етіп тартқымыз келді, осылайша ұзындықтар бойынша хайуанаттар бағы жоқ. Біз бұл мәселені шеше алдық. Егер сіз бастапқыда логикалық топологияға қарасаңыз, онда сіз жазықтықтардың тәуелсіз екенін көре аласыз, әрбір жазықтықты өздігінен салуға болады. Бірақ біз осындай жинақты қосқанда және бүкіл патч-панельді патч-панельге сүйреп апарғымыз келгенде, біз бір буманың ішінде әртүрлі жазықтықтарды араластырып, оларды қалай жиналғанынан қайта орау үшін оптикалық көлденең қосылымдар түріндегі аралық құрылымды енгізуіміз керек. бір сегментте , олардың басқа сегментте қалай жиналатыны. Осының арқасында біз жақсы мүмкіндікке ие боламыз: барлық күрделі коммутация тіректерден асып кетпейді. Бір нәрсені өте қатты біріктіру қажет болғанда, Clos желілерінде кейде «ұшақтарды ашыңыз», оның барлығы бір тірекке шоғырланған. Бізде жоғары бөлшектелген, жеке сілтемелерге дейін, тіректер арасында ауысу жоқ.
Кабельдік инфрақұрылымның логикалық ұйымдастырылуы тұрғысынан ол осылай көрінеді. Сол жақтағы суретте түрлі-түсті блоктар бірінші деңгейлі омыртқа қосқыштарының блоктарын, әрқайсысы сегіз бөлікті және олардан келетін төрт байлам кабельдерді бейнелейді, олар омыртқа-2 қосқыштарының блоктарынан шығатын байламдармен қиылысады. .
Кішкентай шаршылар қиылыстарды көрсетеді. Жоғарғы сол жақта мұндай қиылыстардың әрқайсысының бөлінуі берілген, бұл шын мәнінде кабельдерді бір тірекке толығымен түсетін етіп қайта орайтын 512-ден 512-ге дейінгі көлденең қосылым модулі, мұнда тек бір омыртқа-2 жазықтығы бар. Оң жақта бұл суретті сканерлеу омыртқа-1 деңгейіндегі бірнеше Pod-қа қатысты және оның кросс-коннектке қалай оралғандығы, омыртқа-2 деңгейіне қалай келетіні туралы біршама егжей-тегжейлі берілген.
Ол осылай көрінеді. Әлі толық құрастырылмаған омыртқа-2 тірегі (сол жақта) және кросс-қосқыш тірек. Өкінішке орай, онда көруге болатын көп нәрсе жоқ. Бұл құрылым дәл қазір кеңейтіліп жатқан үлкен деректер орталықтарымыздың бірінде орналастырылуда. Бұл орындалып жатқан жұмыс, ол әдемірек көрінеді, ол жақсырақ толтырылады.
Маңызды сұрақ: біз логикалық топологияны таңдадық және физиканы құрастырдық. Басқару ұшағымен не болады? Бұл операциялық тәжірибеден жақсы белгілі, байланыс күйінің протоколдары жақсы екендігі туралы бірқатар есептер бар, олармен жұмыс істеу бір ғанибет, бірақ, өкінішке орай, олар тығыз байланысты топологияда жақсы масштабталмайды. Бұған кедергі болатын бір негізгі фактор бар - су тасқыны сілтеме күйінің хаттамаларында осылай жұмыс істейді. Егер сіз жай ғана су тасқыны алгоритмін алып, желіміздің қалай құрылымдалғанына қарасаңыз, әр қадамда өте үлкен фанут болатынын көре аласыз және ол басқару ұшағын жаңартулармен толтырады. Атап айтқанда, мұндай топологиялар байланыс күйінің хаттамаларындағы дәстүрлі су тасқыны алгоритмімен өте нашар араласады.
Таңдау - BGP пайдалану. Оны қалай дұрыс дайындау керектігі үлкен деректер орталықтарында BGP пайдалану туралы RFC 7938-де сипатталған. Негізгі идеялар қарапайым: бір хосттағы префикстердің ең аз саны және әдетте желідегі префикстердің ең аз саны, мүмкін болса, біріктіруді пайдаланыңыз және жолды іздеуді болдырмаңыз. Біз жаңартулардың өте мұқият, өте бақыланатын таратылуын қалаймыз, оны алқапсыз деп атаймыз. Жаңартулар желі арқылы өткенде дәл бір рет орналастырылғанын қалаймыз. Егер олар төменгі жақтан пайда болса, олар бір реттен көп емес ашылады. Зигзагтар болмауы керек. Зигзагтар өте нашар.
Бұл әрекетті орындау үшін біз негізгі BGP механизмдерін пайдалану үшін жеткілікті қарапайым дизайнды қолданамыз. Яғни, біз жергілікті сілтеме бойынша жұмыс істейтін eBGP пайдаланамыз және автономды жүйелер келесідей тағайындалған: ToR бойынша автономды жүйе, бір Pod омыртқаның-1 қосқыштарының бүкіл блогындағы автономды жүйе және жоғарғы жағында жалпы автономды жүйе мата. Тіпті BGP қалыпты әрекеті бізге қалаған жаңартуларды таратуға мүмкіндік беретінін көру және көру қиын емес.
Әрине, адрестеу және адрестерді біріктіру маршруттауды құрастыру тәсілімен үйлесімді етіп, басқару жазықтығының тұрақтылығын қамтамасыз ететіндей етіп жасалуы керек. Көліктегі L3 адресациясы топологиямен байланысты, өйткені онсыз біріктіруге қол жеткізу мүмкін емес, онсыз жеке адрестер маршруттау жүйесіне енеді. Және тағы бір нәрсе, агрегация, өкінішке орай, көп жолға жақсы араласпайды, өйткені бізде көп жолды және бізде біріктіру болған кезде бәрі жақсы, бүкіл желі сау болса, онда ешқандай ақаулар болмайды. Өкінішке орай, желіде сәтсіздіктер пайда болған кезде және топологияның симметриясы жоғалған кезде, біз бірлік жарияланған нүктеге келе аламыз, одан әрі біз бару керек жерге бара алмаймыз. Сондықтан, бұдан әрі көп жол жоқ жерде біріктіру жақсы, біздің жағдайда бұл ToR қосқыштары.
Шындығында, жинақтауға болады, бірақ мұқият. Егер желі ақаулары орын алған кезде басқарылатын дезагрегация жасай алсақ. Бірақ бұл өте қиын тапсырма, біз тіпті мұны істеу мүмкін бе, қосымша автоматтандыруды қосу мүмкін бе деп ойладық және қажетті әрекетті алу үшін BGP-ді дұрыс іске қосатын соңғы күй машиналары. Өкінішке орай, бұрыштық корпустарды өңдеу өте айқын емес және күрделі және бұл тапсырма BGP-ге сыртқы тіркемелерді қосу арқылы жақсы шешілмейді.
Келесі баяндамада талқыланатын RIFT хаттамасы аясында осыған байланысты өте қызықты жұмыстар атқарылды.
Тағы бір маңызды нәрсе - бізде көптеген балама жолдар бар тығыз топологияларда деректер жазықтықтары қалай масштабталады. Бұл жағдайда бірнеше қосымша деректер құрылымдары пайдаланылады: ECMP топтары, олар өз кезегінде Next Hop топтарын сипаттайды.
Қалыпты жұмыс істейтін желіде, ақауларсыз, Clos топологиясына көтерілгенде, тек бір топты пайдалану жеткілікті, өйткені жергілікті емес барлық нәрсе әдепкі бойынша сипатталған, біз жоғары көтеріле аламыз. Біз жоғарыдан төмен қарай оңтүстікке қарай жүрсек, онда барлық жолдар ECMP емес, олар бір жолды жолдар. Барлығы жақсы. Мәселе мынада, және классикалық Clos топологиясының ерекшелігі, егер біз матаның жоғарғы бөлігіне, кез келген элементке қарасақ, төменде кез келген элементке бір ғана жол бар. Егер осы жолда сәтсіздіктер орын алса, зауыттың жоғарғы жағындағы нақты элемент бұзылған жолдың артында жатқан префикстер үшін жарамсыз болады. Бірақ қалғандары үшін бұл жарамды, және біз ECMP топтарын талдап, жаңа күйді енгізуіміз керек.
Заманауи құрылғыларда деректер жазықтығының ауқымдылығы қалай көрінеді? Егер LPM (ең ұзын префикс сәйкестігі) жасасақ, бәрі жақсы, 100 мыңнан астам префикстер. Егер біз Next Hop топтары туралы айтатын болсақ, онда бәрі нашар, 2-4 мың. Егер біз Next Hops (немесе іргелес) сипаттамасын қамтитын кесте туралы айтатын болсақ, онда бұл 16к пен 64к аралығында болады. Және бұл проблемаға айналуы мүмкін. Міне, біз қызықты шегініске келдік: деректер орталықтарындағы MPLS-ке не болды? Негізінде біз мұны істегіміз келді.
Екі жағдай болды. Біз хосттарда микро-сегментация жасадық, енді оны желіде жасаудың қажеті жоқ. Бұл әртүрлі жеткізушілердің қолдауымен, тіпті MPLS бар ақ жәшіктерде ашық енгізулермен де жақсы болмады. MPLS, кем дегенде, оның дәстүрлі іске асырулары, өкінішке орай, ECMP-мен өте нашар үйлеседі. Және сол себепті.
IP үшін ECMP қайта жіберу құрылымы осылай көрінеді. Префикстердің үлкен саны бір топты және бірдей Next Hops блогын (немесе іргелес, бұл әртүрлі құрылғылар үшін әртүрлі құжаттамада басқаша аталуы мүмкін) пайдалана алады. Мәселе мынада, бұл шығыс порт ретінде сипатталады және дұрыс Next Hop-ке жету үшін MAC мекенжайын қайта жазу керек. IP үшін бәрі қарапайым болып көрінеді, бір топ үшін префикстердің өте көп санын, сол Next Hops блогын пайдалануға болады.
MPLS классикалық архитектурасы шығыс интерфейсіне байланысты белгіні әртүрлі мәндерге қайта жазуға болатындығын білдіреді. Сондықтан біз әрбір енгізу белгісі үшін топты және Next Hops блогын сақтауымыз керек. Бұл, өкінішке орай, ауқымды емес.
Біздің дизайнымызда бізге шамамен 4000 ToR қосқышы қажет екенін түсіну оңай, егер біз омыртқа-64-ден омыртқа-1-ге қарай жылжытсақ, максималды ені 2 ECMP жолы болды. Біз ECMP топтарының бір кестесіне әрең кіреміз, егер ToR бар бір префикс жойылса және біз Next Hops кестесіне мүлдем кірмейміз.
Мұның бәрі үмітсіз емес, өйткені Segment Routing сияқты архитектуралар жаһандық белгілерді қамтиды. Формальды түрде, осы Next Hops блоктарының барлығын қайтадан құлатуға болады. Мұны істеу үшін сізге жабайы карта түріндегі операция қажет: белгіні алып, оны нақты мәнсіз бірдей етіп қайта жазыңыз. Бірақ, өкінішке орай, бұл қол жетімді енгізулерде онша жоқ.
Соңында дата орталығына сыртқы трафикті енгізу керек. Мұны қалай жасауға болады? Бұрын трафик Clos желісіне жоғарыдан енгізілген. Яғни, матаның жоғарғы жағындағы барлық құрылғыларға қосылатын шеткі маршрутизаторлар болды. Бұл шешім шағын және орта өлшемдерде өте жақсы жұмыс істейді. Өкінішке орай, трафикті осылайша бүкіл желіге симметриялы түрде жіберу үшін біз бір уақытта матаның барлық элементтеріне жетуіміз керек, ал олардың жүзден астамы болған кезде, бізге де үлкен қажет болады. шеткі маршрутизаторлардағы radix. Жалпы, бұл ақшаны талап етеді, өйткені шеткі маршрутизаторлар функционалды, олардағы порттар қымбатырақ болады және дизайн өте әдемі емес.
Тағы бір нұсқа - мұндай трафикті төменнен бастау. Clos топологиясы төменнен, яғни ToR жағынан келетін трафик бүкіл желіні жүктей отырып, екі итерацияда матаның бүкіл жоғарғы бөлігінде деңгейлер арасында біркелкі таратылатындай етіп құрастырылғанын тексеру оңай. Сондықтан біз сыртқы қосылымды қамтамасыз ететін Pod, Edge Pod арнайы түрін енгіземіз.
Тағы бір нұсқа бар. Мысалы, Facebook осылай жасайды. Олар оны Fabric Aggregator немесе HGRID деп атайды. Бірнеше деректер орталықтарын қосу үшін қосымша омыртқа деңгейі енгізілуде. Бұл дизайн интерфейстерде қосымша функциялар немесе инкапсуляция өзгерістері болмаса мүмкін болады. Егер олар қосымша жанасу нүктелері болса, бұл қиын. Әдетте деректер орталығының әртүрлі бөліктерін бөлетін көптеген функциялар мен мембрана түрі бар. Мұндай мембрананы үлкен етіп жасаудың қажеті жоқ, бірақ егер ол қандай да бір себептермен шынымен қажет болса, онда оны алып тастау, оны мүмкіндігінше кең етіп, хосттарға беру мүмкіндігін қарастырған жөн. Мұны, мысалы, көптеген бұлттық операторлар жасайды. Олардың қабаттасуы бар, олар хосттардан басталады.
Біз қандай даму мүмкіндіктерін көріп отырмыз? Ең алдымен, CI/CD құбырын қолдауды жақсарту. Біз қалай сынасақ, солай ұшқымыз келеді және ұшатын жолды сынап көргіміз келеді. Бұл өте жақсы нәтиже бермейді, өйткені инфрақұрылым үлкен және оны сынақтар үшін қайталау мүмкін емес. Өндірістік инфрақұрылымға сынақ элементтерін түсірмей енгізу жолын түсіну керек.
Жақсырақ құрал-саймандар мен жақсы бақылау ешқашан артық болмайды. Барлық мәселе - күш пен қайтарым теңгерімін. Егер сіз оны ақылға қонымды күшпен қоса алсаңыз, өте жақсы.
Желілік құрылғыларға арналған ашық операциялық жүйелер. RIFT сияқты жақсырақ хаттамалар және жақсырақ маршруттау жүйелері. Сондай-ақ, кептелістерді бақылаудың жақсы схемаларын пайдалану және мүмкін, ең болмағанда кейбір нүктелерде кластер ішінде RDMA қолдауын енгізу бойынша зерттеулер қажет.
Болашаққа қарайтын болсақ, бізге жетілдірілген топологиялар және, мүмкін, қосымша шығындарды аз пайдаланатын желілер қажет. Жақында жаңа нәрселердің ішінде Ethernet тауарына негізделген, бірақ әлдеқайда қысқа тақырыптарды пайдалану мүмкіндігі бар HPC Cray Slingshot үшін мата технологиясы туралы жарияланымдар болды. Нәтижесінде үстеме шығындар азаяды.
Барлығын мүмкіндігінше қарапайым ұстау керек, бірақ қарапайым емес. Күрделілік - ауқымдылықтың жауы. Қарапайымдылық пен тұрақты құрылымдар біздің досымыз. Егер сіз бір жерде масштабты кеңейте алсаңыз, оны жасаңыз. Жалпы, қазір желілік технологиялармен айналысу өте жақсы. Көптеген қызықтар болып жатыр. Рақмет сізге.
Ақпарат көзі: www.habr.com