Бид секундэд нэг петабайтаас дээш хурдтай 100 мянга гаруй сервер бүхий компьютерийн кластеруудыг байрлуулах боломжийг олгодог дата төвийн сүлжээний загварыг боловсруулсан.
Дмитрий Афанасьевын илтгэлээс та шинэ дизайны үндсэн зарчмууд, масштабын топологи, үүнтэй холбоотой асуудлууд, тэдгээрийг шийдвэрлэх сонголтууд, "нягт холбогдсон" орчин үеийн сүлжээний төхөөрөмжүүдийн чиглүүлэлт, дамжуулалтын хавтгай функцүүдийн талаар мэдэх болно. олон тооны ECMP чиглүүлэлт бүхий топологи . Үүнээс гадна Дима гадаад холболтын зохион байгуулалт, физик давхарга, кабелийн систем, хүчин чадлыг цаашид нэмэгдүүлэх арга замын талаар товч ярьсан.
- Бүгдэд нь өдрийн мэнд! Намайг Дмитрий Афанасьев гэдэг, би Yandex-ийн сүлжээний архитектор бөгөөд үндсэндээ мэдээллийн төвийн сүлжээг зохион бүтээдэг.
Миний түүх Yandex мэдээллийн төвийн шинэчлэгдсэн сүлжээний тухай байх болно. Энэ бол бидний хийсэн дизайны маш их хувьсал боловч үүнтэй зэрэгцэн зарим шинэ элементүүд бий. Цөөн хугацаанд багтаах маш их мэдээлэл байсан тул энэ бол тойм танилцуулга юм. Бид логик топологийг сонгох замаар эхэлнэ. Дараа нь хяналтын хавтгайн тойм, өгөгдлийн хавтгайн өргөтгөлтэй холбоотой асуудлууд, физик түвшинд юу тохиолдохыг сонгох, бид төхөөрөмжийн зарим онцлог шинж чанаруудыг авч үзэх болно. Хэсэг хугацааны өмнө бидний ярьж байсан MPLS-тэй дата төвд юу болж байгааг бага зэрэг хөндье.
Тэгэхээр, ачаалал, үйлчилгээний хувьд Yandex гэж юу вэ? Yandex бол ердийн hyperscaler юм. Хэрэв бид хэрэглэгчдийг харвал бид үндсэндээ хэрэглэгчийн хүсэлтийг боловсруулдаг. Мөн төрөл бүрийн стриминг үйлчилгээ, өгөгдөл дамжуулах, учир нь бидэнд хадгалах үйлчилгээ бас бий. Хэрэв арын хэсэгт ойрхон байвал хуваарилагдсан объект хадгалах, өгөгдлийг хуулбарлах, мэдээжийн хэрэг байнгын дараалал гэх мэт дэд бүтцийн ачаалал, үйлчилгээнүүд гарч ирнэ. Ажлын ачааллын үндсэн төрлүүдийн нэг бол MapReduce болон ижил төстэй системүүд, урсгал боловсруулах, машин сурах гэх мэт.
Дэд бүтэц нь яаж байгаа юм бэ, дээр нь энэ бүх зүйл болдог вэ? Дахин хэлэхэд, бид спектрийн бага гиперскалер тал руу арай илүү ойр байгаа хэдий ч бид нэлээд ердийн гиперскалер юм. Гэхдээ бидэнд бүх шинж чанарууд бий. Бид аль болох барааны техник хангамж болон хэвтээ масштабыг ашигладаг. Бид нөөцийг бүрэн нэгтгэдэг: бид бие даасан машинууд, тусдаа тавиуруудтай ажилладаггүй, гэхдээ тэдгээрийг төлөвлөлт, хуваарилалттай холбоотой зарим нэмэлт үйлчилгээнүүдийн хамт сольж болох нөөцийн том сан болгон нэгтгэж, бүхэл бүтэн сантай ажилладаг.
Тиймээс бид дараагийн түвшинд - тооцооллын кластерийн түвшний үйлдлийн системтэй байна. Бидний ашигладаг технологийн стекийг бүрэн хянах нь маш чухал юм. Бид төгсгөлийн цэгүүд (хостууд), сүлжээ болон програм хангамжийн стекийг хянадаг.
Бид Орос болон гадаадад хэд хэдэн томоохон дата төвтэй. Тэдгээрийг MPLS технологийг ашигладаг нуруу нэгтгэдэг. Манай дотоод дэд бүтэц бараг бүхэлдээ IPv6 дээр суурилагдсан боловч бид ихэвчлэн IPv4-ээр дамждаг гадаад траффикт үйлчлэх шаардлагатай байгаа тул IPv4-ээр дамжуулан ирж буй хүсэлтийг ямар нэгэн байдлаар урд талын серверт хүргэх, мөн гадаад IPv4-Интернэт рүү бага зэрэг хандах хэрэгтэй. Жишээ нь, индексжүүлэх.
Өгөгдлийн төвийн сүлжээний дизайны сүүлийн хэдэн давталт нь олон давхаргат Clos топологийг ашигласан бөгөөд зөвхөн L3 юм. Хэсэг хугацааны өмнө бид L2-оос гараад тайвширсан. Эцэст нь хэлэхэд, манай дэд бүтцэд хэдэн зуун мянган тооцоолох (сервер) тохиолдлууд багтдаг. Хэсэг хугацааны өмнө кластерын дээд хэмжээ 10 мянга орчим сервер байсан. Энэ нь кластер түвшний ижил үйлдлийн системүүд, хуваарь гаргагч, нөөцийн хуваарилалт гэх мэт зүйлс хэрхэн ажиллаж чадахаас ихээхэн шалтгаална.Дэд бүтцийн програм хангамжийн тал дээр ахиц дэвшил гарсан тул зорилтот хэмжээ нь нэг тооцооллын кластерт 100 мянга орчим сервер болж байна. Бидэнд ийм кластерт нөөцийг үр ашигтай нэгтгэх боломжийг олгодог сүлжээний үйлдвэрүүдийг бий болгох даалгавар байна.
Дата төвийн сүлжээнээс бид юу хүсч байна вэ? Юуны өмнө маш олон хямд, жигд тархсан зурвасын өргөн байдаг. Учир нь сүлжээ бол нөөцийг нэгтгэх гол тулгуур юм. Шинэ зорилтот хэмжээ нь нэг кластерт 100 мянга орчим сервер юм.
Мэдээжийн хэрэг, бид өргөтгөх боломжтой, тогтвортой удирдлагын онгоцыг хүсч байна, учир нь ийм том дэд бүтцэд санамсаргүй үйл явдлаас болж маш олон толгой өвддөг бөгөөд удирдлагын онгоц нь бидэнд толгой өвдөхийг хүсэхгүй байна. Үүний зэрэгцээ бид доторх төрийг багасгахыг хүсч байна. Нөхцөл байдал бага байх тусам бүх зүйл илүү сайн, тогтвортой ажиллаж, оношлоход хялбар болно.
Мэдээжийн хэрэг, ийм дэд бүтцийг гараар удирдах боломжгүй, хэсэг хугацаанд боломжгүй байсан тул бидэнд автоматжуулалт хэрэгтэй. Бидэнд аль болох үйл ажиллагааны дэмжлэг, үзүүлж болохуйц хэмжээнд CI/CD дэмжлэг хэрэгтэй байна.
Ийм хэмжээний дата төв, кластерууд байгаа тул үйлчилгээгээ тасалдуулахгүйгээр үе шаттайгаар байршуулах, өргөжүүлэх ажлыг дэмжих ажил нэлээд хурцаар тавигдаж байна. Хэрэв мянга мянган машин, магадгүй арван мянган машинтай кластерууд дээр тэдгээрийг нэг ажиллагаа болгон ашиглах боломжтой хэвээр байгаа бол, өөрөөр хэлбэл бид дэд бүтцийг өргөжүүлэхээр төлөвлөж байгаа бөгөөд нэг үйл ажиллагаанд хэдэн мянган машин нэмж оруулав. тэгвэл зуун мянган машинтай бөөгнөрөл тэр дороо ингэж үүсдэггүй, тодорхой хугацаанд баригддаг. Энэ бүх хугацаанд аль хэдийн шахагдсан зүйл, байршуулсан дэд бүтэц бэлэн байх нь зүйтэй юм.
Мөн бидний үлдээсэн нэг шаардлага: олон түрээслэлтийг дэмжих, өөрөөр хэлбэл виртуалчлал эсвэл сүлжээний сегментчилэл. Одоо бид үүнийг сүлжээний даавууны түвшинд хийх шаардлагагүй, учир нь хуваалт нь хостууд руу шилжсэн бөгөөд энэ нь бидний хувьд масштаблах ажлыг маш хялбар болгосон. IPv6 болон том хаягийн зайны ачаар бид дотоод дэд бүтцэд давхардсан хаяг ашиглах шаардлагагүй болсон; бүх хаяглалт аль хэдийн өвөрмөц байсан. Мөн бид хостуудад шүүлтүүр, сүлжээний сегментчилэл хийсэн тул өгөгдлийн төвийн сүлжээнд ямар нэгэн виртуал сүлжээний нэгж үүсгэх шаардлагагүй болсон.
Маш чухал зүйл бол бидэнд хэрэггүй зүйл юм. Хэрэв зарим функцийг сүлжээнээс устгах боломжтой бол энэ нь амьдралыг ихээхэн хөнгөвчлөх бөгөөд дүрмээр бол боломжтой тоног төхөөрөмж, програм хангамжийн сонголтыг өргөжүүлж, оношилгоог маш хялбар болгодог.
Тэгэхээр, бидэнд хэрэггүй зүйл юу вэ, юуг орхиж чадсан бэ, тэр үед үргэлж баярлаж биш, харин үйл явц дуусахад маш их тайвширч байсан уу?
Юуны өмнө L2-г орхих. Бидэнд L2 хэрэггүй, бодит ч биш, дуурайлган ч биш. Бид програмын стекийг хянадаг тул ашиглагдаагүй. Манай программууд нь хэвтээ байдлаар өргөтгөх боломжтой, L3 хаяглалттай ажилладаг, зарим нэг инстанц унтарчихлаа гэж санаа зовдоггүй, зүгээр л шинийг гаргадаг, хуучин хаягаар нь гаргах шаардлагагүй, учир нь кластерт байрлах машинуудын үйлчилгээг илрүүлэх, хянах тусдаа түвшний . Бид энэ ажлыг сүлжээнд даатгадаггүй. Сүлжээний ажил нь пакетуудыг А цэгээс В цэг хүртэл хүргэх явдал юм.
Сүлжээнд хаягууд шилжих тохиолдол бидэнд байдаггүй бөгөөд үүнийг хянах шаардлагатай. Олон загварт энэ нь ихэвчлэн VM-ийн хөдөлгөөнийг дэмжихэд шаардлагатай байдаг. Бид том Yandex-ийн дотоод дэд бүтцэд виртуал машинуудын хөдөлгөөнийг ашигладаггүй бөгөөд үүнээс гадна үүнийг хийсэн ч сүлжээний дэмжлэгтэйгээр ийм зүйл болохгүй гэж бид үзэж байна. Хэрэв үүнийг үнэхээр хийх шаардлагатай бол үүнийг хостын түвшинд хийж, давхар давхаргын чиглүүлэлтийн системд (тээврийн сүлжээ) хүрэхгүй, эсвэл хэт олон динамик өөрчлөлт оруулахгүйн тулд давхарлаж болох хаягуудыг түлхэх хэрэгтэй. .
Бидний ашигладаггүй өөр нэг технологи бол multicast юм. Хэрэв та хүсвэл би яагаад гэдгийг дэлгэрэнгүй хэлж чадна. Энэ нь амьдралыг ихээхэн хөнгөвчлөх болно, учир нь хэн нэгэн үүнийг шийдэж, хамгийн энгийн суурилуулалтаас бусад тохиолдолд олон дамжуулалтын удирдлагын онгоц яг ямар харагддагийг харвал энэ нь том толгойн өвчин болно. Үүнээс гадна, жишээ нь, сайн ажилладаг нээлттэй эхийн хэрэгжилтийг олоход хэцүү байдаг.
Эцэст нь бид сүлжээгээ хэт их өөрчлөхгүй байхаар зохион бүтээдэг. Чиглүүлэлтийн систем дэх гадны үйл явдлын урсгал бага байна гэдэгт бид найдаж болно.
Дата төвийн сүлжээг хөгжүүлэхэд ямар асуудал үүсч, ямар хязгаарлалтыг анхаарах ёстой вэ? Мэдээжийн хэрэг зардал. Өргөтгөх чадвар, бидний өсөхийг хүсч буй түвшин. Үйлчилгээг зогсоохгүйгээр өргөжүүлэх хэрэгцээ. зурвасын өргөн, хүртээмж. Хяналтын систем, үйл ажиллагааны багуудад зориулж сүлжээнд юу болж байгааг харуулах. Автоматжуулалтын дэмжлэг - өөр өөр даалгавруудыг өөр өөр түвшинд, түүний дотор нэмэлт давхаргыг нэвтрүүлэх боломжтой тул аль болох их. За, [магадгүй] борлуулагчдаас хамаарахгүй. Хэдийгээр өөр өөр түүхэн цаг үед аль хэсгийг нь харж байгаагаас хамааран энэ тусгаар тогтнолд хүрэх нь илүү хялбар эсвэл хэцүү байсан. Хэрэв бид сүлжээний төхөөрөмжийн чипүүдийн хөндлөн огтлолыг авч үзвэл, хэрэв бид өндөр дамжуулах чадвартай чип авахыг хүсч байвал үйлдвэрлэгчээс хараат бус байдлын талаар ярих нь маш нөхцөлтэй байсан.
Бид сүлжээгээ байгуулахдаа ямар логик топологийг ашиглах вэ? Энэ нь олон түвшний Clos байх болно. Үнэн хэрэгтээ одоогоор бодит хувилбар байхгүй байна. Clos топологи нь том радикс шилжүүлэгчтэй бол одоо эрдэм шинжилгээний сонирхлын талбарт илүү их байдаг төрөл бүрийн дэвшилтэт топологитой харьцуулахад ч сайн байна.
Олон түвшний Clos сүлжээ нь ойролцоогоор хэрхэн бүтэцлэгдсэн байдаг ба түүний өөр өөр элементүүдийг юу гэж нэрлэдэг вэ? Юуны өмнө хойд, өмнөд, зүүн, баруун хаана байна гэж өөрийгөө чиглүүлэхийн тулд салхи боссон. Энэ төрлийн сүлжээг ихэвчлэн баруунаас зүүн тийш маш их ачаалалтай хүмүүс барьдаг. Үлдсэн элементүүдийн хувьд дээд талд нь жижиг унтраалгауудаас угсарсан виртуал унтраалга байдаг. Энэ бол Clos сүлжээний рекурсив барилгын гол санаа юм. Бид ямар нэгэн төрлийн радикс бүхий элементүүдийг авч, тэдгээрийг холбодог бөгөөд ингэснээр бидний олж авсан зүйл нь илүү том цацраг бүхий шилжүүлэгч гэж тооцогддог. Хэрэв танд илүү их зүйл хэрэгтэй бол процедурыг давтаж болно.
Жишээлбэл, хоёр түвшний Clos-ийн тусламжтайгаар миний диаграммд босоо байрлалтай бүрэлдэхүүн хэсгүүдийг тодорхой тодорхойлох боломжтой тохиолдолд тэдгээрийг ихэвчлэн онгоц гэж нэрлэдэг. Хэрэв бид гурван түвшний нурууны унтраалгатай (бүгд нь хил хязгаар эсвэл ToR шилжүүлэгч биш бөгөөд зөвхөн дамжин өнгөрөхөд ашиглагддаг) Clos барих байсан бол онгоцууд илүү төвөгтэй харагдах болно; хоёр түвшнийх нь яг иймэрхүү харагдах болно. Бид ToR буюу навч шилжүүлэгчийн блок, тэдгээртэй холбоотой эхний түвшний нурууны шилжүүлэгчийг Pod гэж нэрлэдэг. 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 Gbit QSFP100-аас хямд биш юм. Мөн multimode-д зориулсан энэхүү задаргаа нь тийм ч сайн ажилладаггүй.
Өөр нэг хязгаарлалт бол тооцоолох кластеруудын хэмжээ, серверийн тоо зэргээс шалтгаалан манай дата төвүүд биет том хэмжээтэй болж хувирдаг. Энэ нь дор хаяж нэг нислэгийг singlemod ашиглан хийх шаардлагатай гэсэн үг юм. Дахин хэлэхэд, Pods-ийн физик хэмжээнээс шалтгаалан хоёр тэнхлэгийн twinax (зэс кабель) ажиллуулах боломжгүй болно.
Үүний үр дүнд, хэрэв бид үнийг оновчтой болгож, энэ дизайны геометрийг харгалзан үзвэл CWDM ашиглан нэг спам twinax, нэг спам мультимод, нэг спам singlemode авах болно. Энэ нь боломжит шинэчлэлийн замыг харгалзан үздэг.
Саяхан бид хаашаа явж байгаа, юу болох нь ийм байна. Наад зах нь multimode болон singlemode аль алинд нь 50 Гигабит SerDes руу хэрхэн шилжих нь тодорхой байна. Түүгээр ч барахгүй, хэрэв та одоо болон ирээдүйд 400G-ийн хувьд нэг горимт дамжуулагч дээр юу байгааг харвал ихэвчлэн 50G SerDes цахилгаан талаас ирсэн ч нэг эгнээнд 100 Гбит/с оптик руу шилжих боломжтой. Тиймээс 50 руу шилжихийн оронд 100 Гигабит SerDes, нэг эгнээнд 100 Gbps-д шилжих боломжтой, учир нь олон үйлдвэрлэгчдийн амлалтын дагуу тэдгээрийг ашиглах боломжтой болно гэж найдаж байна. 50G SerDes хамгийн хурдан байсан үе тийм ч удаан үргэлжлэхгүй бололтой, учир нь 100G SerDes-ийн анхны хуулбарууд бараг ирэх жил гарах болно. Хэсэг хугацааны дараа тэд боломжийн мөнгөтэй байх болно.
Физикийн сонголтын талаар бас нэг нюанс. Зарчмын хувьд бид 400G SerDes ашиглан 200 эсвэл 50 Гигабит портуудыг аль хэдийн ашиглаж болно. Гэхдээ энэ нь тийм ч утгагүй юм шиг санагдаж байна, учир нь би дээр хэлсэнчлэн бид унтраалга дээр нэлээд том радикс хүсч байгаа нь мэдээжийн хэрэг. Бид 128-ыг хүсч байна. Хэрэв бид чипийн хүчин чадал хязгаарлагдмал бөгөөд бид холбоосын хурдыг нэмэгдүүлбэл радикс аяндаа буурдаг, ямар ч гайхамшиг байхгүй.
Мөн бид онгоц ашиглан нийт хүчин чадлыг нэмэгдүүлэх боломжтой бөгөөд тусгай зардал гарахгүй, бид онгоцны тоог нэмж болно. Хэрэв бид радиксээ алдах юм бол бид нэмэлт түвшинг нэвтрүүлэх шаардлагатай болно, тиймээс одоогийн нөхцөл байдалд, нэг чип тутамд хамгийн их хүчин чадалтай байгаа бол 100 гигабит портыг ашиглах нь илүү үр дүнтэй болох нь харагдаж байна, учир нь тэдгээр нь танд боломжийг олгодог. илүү том цацраг авахын тулд.
Дараагийн асуулт бол физикийг хэрхэн зохион байгуулах вэ, гэхдээ кабелийн дэд бүтцийн үүднээс авч үзвэл. Энэ нь нэлээд инээдтэй байдлаар зохион байгуулагддаг нь харагдаж байна. Навч шилжүүлэгч ба нэгдүгээр түвшний нурууны хоорондох кабель - тэнд олон холбоос байдаггүй, бүх зүйл харьцангуй энгийн байдлаар хийгдсэн байдаг. Гэхдээ бид нэг онгоц авбал дотор нь юу болох вэ гэвэл эхний түвшний бүх нурууг хоёрдугаар түвшний бүх нуруутай холбох хэрэгтэй.
Үүнээс гадна, дүрмээр бол дата төв дотор хэрхэн харагдах талаар зарим хүсэл байдаг. Жишээлбэл, бид кабелиудыг багц болгон нэгтгэж, нэг өндөр нягтралтай нөхөөсийг бүхэлд нь нэг нөхөөсийн самбарт оруулан, уртын хувьд амьтны хүрээлэнгүй болгохыг үнэхээр хүсч байсан. Бид энэ асуудлыг шийдэж чадсан. Хэрэв та эхлээд логик топологийг харвал онгоцууд бие даасан, онгоц бүрийг бие даан барьж болно гэдгийг харж болно. Гэхдээ бид ийм багцыг нэмж, нөхөөсийн самбарыг бүхэлд нь нөхөх самбар руу чирэхийг хүсвэл бид нэг багц дотор өөр өөр онгоцуудыг хольж, тэдгээрийг хэрхэн угсарсанаас нь дахин савлахын тулд оптик хөндлөн холболтын хэлбэрээр завсрын бүтцийг нэвтрүүлэх хэрэгтэй. нэг сегмент дээр , тэдгээрийг өөр сегмент дээр хэрхэн цуглуулах талаар. Үүний ачаар бид сайхан шинж чанарыг олж авдаг: бүх нарийн төвөгтэй шилжүүлэлт нь тавиураас хэтрэхгүй. Хэрэв та ямар нэг зүйлийг маш хүчтэй холбох хэрэгтэй бол Clos сүлжээнд заримдаа "онгоцуудыг задлаарай" гэж нэрлэдэг бөгөөд энэ нь бүгд нэг тавиур дотор төвлөрдөг. Бид тавиур хооронд шилжих, бие даасан холбоосууд хүртэл маш их задаргаатай байдаггүй.
Кабелийн дэд бүтцийн логик зохион байгуулалт талаасаа ийм харагдаж байна. Зүүн талд байгаа зурган дээр олон өнгийн блокууд нь тус бүр найман хэсэг бүхий нэгдүгээр түвшний нурууны унтраалга, тэдгээрээс ирж буй дөрвөн багц кабелийг дүрсэлсэн бөгөөд тэдгээр нь нуруу-2 унтраалгын блокуудаас ирж буй багцуудтай огтлолцдог. .
Жижиг квадратууд нь уулзваруудыг заана. Зүүн дээд талд ийм огтлолцол бүрийн задаргаа байгаа бөгөөд энэ нь үнэндээ 512-оос 512 портын хөндлөн холболтын модуль бөгөөд кабелийг бүхэлд нь нэг тавиурт оруулдаг бөгөөд энэ нь зөвхөн нэг нуруу-2 хавтгайтай байдаг. Мөн баруун талд, энэ зургийг сканнердсан нь нуруу-1 түвшний хэд хэдэн хонхорцогтой холбоотой, мөн хөндлөн холболтоор хэрхэн савлагдсан, нуруу-2 түвшинд хэрхэн хүрч ирдэг талаар бага зэрэг нарийвчлан харуулсан болно.
Энэ нь иймэрхүү харагдаж байна. Бүрэн угсарч амжаагүй нуруу-2 тавиур (зүүн талд) ба хөндлөн холболтын тавиур. Харамсалтай нь тэнд үзэх юм бараг байхгүй. Энэ бүх бүтцийг яг одоо өргөжүүлж байгаа манай томоохон дата төвүүдийн нэгэнд байрлуулж байна. Энэ ажил үргэлжилж байна, энэ нь илүү сайхан харагдах болно, илүү сайн бөглөнө.
Чухал асуулт: бид логик топологийг сонгож, физикийг бүтээсэн. Хяналтын онгоцонд юу тохиолдох вэ? Үйл ажиллагааны туршлагаас сайн мэддэг, холболтын төлөвийн протоколууд сайн байдаг гэсэн хэд хэдэн тайлан байдаг, тэдэнтэй ажиллахад таатай байдаг, гэхдээ харамсалтай нь тэдгээр нь нягт холбогдсон топологи дээр сайн масштабтай байдаггүй. Үүнээс урьдчилан сэргийлэх нэг гол хүчин зүйл байдаг - үер нь холбоосын төлөвийн протоколд ийм байдлаар ажилладаг. Хэрэв та үерийн алгоритмыг аваад манай сүлжээ хэрхэн бүтэцлэгдсэнийг харвал алхам бүрт маш том сэнс гарч ирэх бөгөөд энэ нь удирдлагын онгоцыг шинэчлэлтүүдээр дүүргэх болно. Тодруулбал, ийм топологи нь холболтын төлөвийн протокол дахь уламжлалт үерийн алгоритмтай маш муу холилддог.
Сонголт нь BGP ашиглах явдал юм. Үүнийг хэрхэн зөв бэлтгэх талаар RFC 7938-д том мэдээллийн төвүүдэд BGP ашиглах талаар тайлбарласан болно. Үндсэн санаанууд нь энгийн: нэг хост бүрт угтварын хамгийн бага тоо, ерөнхийдөө сүлжээн дэх угтваруудын хамгийн бага тоо, боломжтой бол нэгтгэлийг ашиглах, зам хайлтыг дарах. Бид шинэчлэлтүүдийг маш болгоомжтой, хяналттай түгээхийг хүсч байна, үүнийг хөндий үнэгүй гэж нэрлэдэг. Бид шинэчлэлтүүдийг сүлжээгээр дамжих үед яг нэг удаа байршуулахыг хүсч байна. Хэрэв тэдгээр нь доод хэсгээс үүссэн бол дээшээ дээшилж, нэгээс илүүгүй удаа нээгддэг. Ямар ч зигзаг байх ёсгүй. Зигзаг нь маш муу юм.
Үүнийг хийхийн тулд бид үндсэн 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к-аас 64k хүртэл байна. Мөн энэ нь асуудал болж магадгүй юм. Эндээс бид сонирхолтой ухралт руу орлоо: мэдээллийн төв дэх MPLS-д юу тохиолдсон бэ? Зарчмын хувьд бид үүнийг хийхийг хүссэн.
Хоёр зүйл болсон. Бид хостууд дээр бичил сегментчилэл хийсэн тул сүлжээнд үүнийг хийх шаардлагагүй болсон. Энэ нь янз бүрийн үйлдвэрлэгчдийн дэмжлэг, тэр ч байтугай MPLS-тэй цагаан хайрцаг дээр нээлттэй хэрэгжүүлэлтээр тийм ч сайн байгаагүй. Мөн MPLS, ядаж түүний уламжлалт хэрэгжилт нь харамсалтай нь ECMP-тэй маш муу хосолсон байдаг. Тийм учраас л.
IP-д зориулсан ECMP дамжуулалтын бүтэц иймэрхүү харагдаж байна. Олон тооны угтварууд нь ижил бүлэг болон ижил Next Hops блокыг ашиглаж болно (эсвэл зэргэлдээх, өөр өөр төхөөрөмжүүдийн өөр баримт бичигт үүнийг өөрөөр нэрлэж болно). Гол нь үүнийг гадагш гарах порт гэж тодорхойлсон бөгөөд зөв Next Hop руу орохын тулд MAC хаягийг юугаар дахин бичих ёстойг зааж өгсөн. IP-ийн хувьд бүх зүйл энгийн харагддаг тул та ижил бүлэгт, ижил Next Hops блокт зориулж маш олон тооны угтваруудыг ашиглаж болно.
Сонгодог MPLS архитектур нь гарч буй интерфейсээс хамааран шошгыг өөр өөр утгаар дахин бичиж болно гэсэн үг юм. Тиймээс бид оролтын шошго бүрт бүлэг болон Next Hops блокыг хадгалах хэрэгтэй. Энэ нь харамсалтай нь масштабтай биш юм.
Хэрэв бид нуруу-4000-ээс нуруу-64 руу шилжих юм бол бидний дизайнд 1 орчим ToR шилжүүлэгч хэрэгтэйг харахад хялбар байдаг, хамгийн их өргөн нь 2 ECMP зам байсан. Зөвхөн ToR гэсэн нэг угтвар арилж, Next Hops хүснэгтэд огт орохгүй бол бид ECMP бүлгүүдийн нэг хүснэгтэд бараг л ордоггүй.
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