Tumeunda muundo wa mtandao wa kituo cha data ambao unaruhusu uwekaji wa makundi ya kompyuta yenye ukubwa wa zaidi ya seva elfu 100 zilizo na kipimo data cha juu cha sehemu mbili cha zaidi ya petabyte moja kwa sekunde.
Kutoka kwa ripoti ya Dmitry Afanasyev utajifunza juu ya kanuni za msingi za muundo mpya, kuongeza viwango vya juu, shida zinazotokea na hii, chaguzi za kuzitatua, sifa za kuelekeza na kuongeza kazi za ndege za usambazaji wa vifaa vya kisasa vya mtandao katika "vilivyounganishwa sana" topolojia na idadi kubwa ya njia za ECMP. Kwa kuongeza, Dima alizungumza kwa ufupi juu ya shirika la uunganisho wa nje, safu ya kimwili, mfumo wa cabling na njia za kuongeza uwezo zaidi.
- Mchana mzuri kila mtu! Jina langu ni Dmitry Afanasyev, mimi ni mbunifu wa mtandao huko Yandex na kimsingi hutengeneza mitandao ya kituo cha data.
Hadithi yangu itakuwa juu ya mtandao uliosasishwa wa vituo vya data vya Yandex. Ni mageuzi mengi ya muundo tuliokuwa nao, lakini wakati huo huo kuna mambo mapya. Hili ni wasilisho la muhtasari kwa sababu kulikuwa na taarifa nyingi za kupakiwa kwa muda mfupi. Tutaanza kwa kuchagua topolojia ya kimantiki. Kisha kutakuwa na maelezo ya jumla ya ndege ya udhibiti na matatizo na scalability ya ndege ya data, uchaguzi wa nini kitatokea katika ngazi ya kimwili, na tutaangalia baadhi ya vipengele vya vifaa. Hebu tuguse kidogo juu ya kile kinachotokea katika kituo cha data na MPLS, ambacho tulizungumzia wakati fulani uliopita.
Kwa hiyo, Yandex ni nini katika suala la mizigo na huduma? Yandex ni hyperscaler ya kawaida. Ikiwa tunaangalia watumiaji, tunashughulikia maombi ya watumiaji. Pia huduma mbalimbali za utiririshaji na uhamishaji data, kwa sababu pia tuna huduma za uhifadhi. Ikiwa karibu na mazingira ya nyuma, basi mizigo na huduma za miundombinu huonekana hapo, kama vile hifadhi ya kitu kilichosambazwa, urudufishaji wa data na, bila shaka, foleni zinazoendelea. Moja ya aina kuu za mzigo wa kazi ni MapReduce na mifumo sawa, usindikaji wa mkondo, kujifunza kwa mashine, nk.
Je, miundombinu ikoje juu yake ambayo yote haya hutokea? Tena, sisi ni mkadiriaji wa kawaida, ingawa labda tuko karibu kidogo na upande mdogo wa wigo. Lakini tuna sifa zote. Tunatumia maunzi ya bidhaa na kuongeza mlalo inapowezekana. Tuna ujumuishaji kamili wa rasilimali: hatufanyi kazi na mashine za kibinafsi, rafu za kibinafsi, lakini tunazichanganya katika kundi kubwa la rasilimali zinazoweza kubadilishwa na huduma zingine za ziada zinazohusika na kupanga na ugawaji, na kufanya kazi na kundi hili lote.
Kwa hiyo tuna ngazi inayofuata - mfumo wa uendeshaji katika ngazi ya nguzo ya kompyuta. Ni muhimu sana tudhibiti kikamilifu rundo la teknolojia tunalotumia. Tunadhibiti sehemu za mwisho (wenyeji), mtandao na mrundikano wa programu.
Tuna vituo kadhaa vikubwa vya data nchini Urusi na nje ya nchi. Vimeunganishwa na uti wa mgongo kwa kutumia teknolojia ya MPLS. Miundombinu yetu ya ndani imejengwa karibu kabisa kwenye IPv6, lakini kwa kuwa tunahitaji kuhudumia trafiki ya nje, ambayo bado inakuja hasa kupitia IPv4, ni lazima kwa namna fulani tuwasilishe maombi yanayokuja kupitia IPv4 hadi mwisho wa mbele.seva, na pia nenda kidogo kwenye Mtandao wa nje wa IPv4 - kwa mfano, kwa ajili ya kuorodhesha.
Marudio machache ya mwisho ya miundo ya mtandao wa kituo cha data yametumia topolojia ya Clos ya safu nyingi na ni ya L3 pekee. Tuliondoka L2 muda mfupi uliopita na kupumua kwa utulivu. Hatimaye, miundombinu yetu inajumuisha mamia ya maelfu ya matukio ya kukokotoa (seva). Ukubwa wa juu zaidi wa nguzo wakati fulani uliopita ulikuwa karibu seva elfu 10. Hii kwa kiasi kikubwa inatokana na jinsi mifumo hiyo hiyo ya uendeshaji ya kiwango cha nguzo, vipanga ratiba, ugawaji wa rasilimali, n.k. Kwa kuwa maendeleo yamefanyika kwa upande wa programu ya miundombinu, saizi inayolengwa sasa ni takriban seva elfu 100 katika nguzo moja ya kompyuta, na. Tuna kazi - kuwa na uwezo wa kujenga viwanda vya mtandao vinavyoruhusu kukusanya rasilimali kwa ufanisi katika nguzo kama hiyo.
Je, tunataka nini kutoka kwa mtandao wa kituo cha data? Kwanza kabisa, kuna bandwidth nyingi za bei nafuu na zilizosambazwa kwa usawa. Kwa sababu mtandao ndio uti wa mgongo ambao tunaweza kuunganisha rasilimali. Saizi mpya inayolengwa ni takriban seva elfu 100 kwenye nguzo moja.
Sisi pia, bila shaka, tunataka ndege ya udhibiti yenye hatari na imara, kwa sababu kwenye miundombinu kubwa kama hiyo maumivu mengi ya kichwa hutokea hata kutokana na matukio ya nasibu, na hatutaki ndege ya udhibiti ituletee maumivu ya kichwa pia. Wakati huo huo, tunataka kupunguza hali ndani yake. Hali ndogo, bora na imara zaidi kila kitu hufanya kazi, na ni rahisi zaidi kutambua.
Bila shaka, tunahitaji automatisering, kwa sababu haiwezekani kusimamia miundombinu hiyo kwa manually, na imekuwa haiwezekani kwa muda fulani. Tunahitaji usaidizi wa uendeshaji kadri tuwezavyo na usaidizi wa CI/CD kwa kiwango ambacho kinaweza kutolewa.
Kwa ukubwa kama huu wa vituo vya data na makundi, kazi ya kusaidia utumaji na upanuzi unaoongezeka bila kukatizwa kwa huduma imekuwa kubwa sana. Ikiwa kwenye nguzo za ukubwa wa mashine elfu, labda karibu na mashine elfu kumi, bado zinaweza kutekelezwa kama operesheni moja - ambayo ni, tunapanga upanuzi wa miundombinu, na mashine elfu kadhaa zinaongezwa kama operesheni moja, basi nguzo ya ukubwa wa mashine laki moja haitokei mara moja hivi, inajengwa kwa muda. Na ni kuhitajika kwamba wakati huu wote kile ambacho tayari kimepigwa nje, miundombinu ambayo imetumiwa, inapaswa kupatikana.
Na hitaji moja ambalo tulikuwa nalo na tuliloliacha: usaidizi wa multitenancy, ambayo ni, uboreshaji au mgawanyiko wa mtandao. Sasa hatuna haja ya kufanya hivyo kwa kiwango cha kitambaa cha mtandao, kwa sababu sharding imekwenda kwa majeshi, na hii imefanya kuongeza rahisi sana kwetu. Shukrani kwa IPv6 na nafasi kubwa ya anwani, hatukuhitaji kutumia nakala rudufu za anwani katika miundombinu ya ndani. Na kutokana na ukweli kwamba tumechukua uchujaji na mgawanyiko wa mtandao kwa wasimamizi, hatuhitaji kuunda vyombo vyovyote vya mtandao kwenye mitandao ya kituo cha data.
Kitu muhimu sana ni kile ambacho hatuhitaji. Ikiwa baadhi ya kazi zinaweza kuondolewa kwenye mtandao, hii hurahisisha maisha, na, kama sheria, huongeza uchaguzi wa vifaa na programu zinazopatikana, na kufanya uchunguzi rahisi sana.
Kwa hiyo, ni nini ambacho hatuhitaji, tumeweza kuacha nini, si mara zote kwa furaha wakati ulipotokea, lakini kwa msamaha mkubwa wakati mchakato ukamilika?
Kwanza kabisa, kuachana na L2. Hatuhitaji L2, si halisi wala kuigwa. Haitumiki kwa kiasi kikubwa kutokana na ukweli kwamba tunadhibiti mkusanyiko wa programu. Maombi yetu yanaweza kuongezeka kwa usawa, yanafanya kazi na anwani ya L3, hawana wasiwasi sana kuwa mfano fulani umetoka, wanatoa mpya tu, hauitaji kusambaza kwa anwani ya zamani, kwa sababu kuna kiwango tofauti cha ugunduzi wa huduma na ufuatiliaji wa mashine zilizo kwenye nguzo. Hatukabidhi jukumu hili kwa mtandao. Kazi ya mtandao ni kutoa pakiti kutoka sehemu A hadi uhakika B.
Pia hatuna hali ambapo anwani huhamia ndani ya mtandao, na hii inahitaji kufuatiliwa. Katika miundo mingi hii kawaida inahitajika kusaidia uhamaji wa VM. Hatutumii uhamaji wa mashine za kawaida katika miundombinu ya ndani ya Yandex kubwa, na, zaidi ya hayo, tunaamini kwamba hata ikiwa hii imefanywa, haipaswi kutokea kwa msaada wa mtandao. Ikiwa unahitaji kweli kufanya hivi, unahitaji kuifanya katika kiwango cha seva pangishi, na kushinikiza anwani ambazo zinaweza kuhamia kwenye viwekeleo, ili usiguse au ufanye mabadiliko mengi yanayobadilika kwenye mfumo wa uelekezaji wa underlay yenyewe (mtandao wa usafiri) .
Teknolojia nyingine ambayo hatutumii ni multicast. Ikiwa unataka, naweza kukuambia kwa undani kwa nini. Hii hurahisisha maisha zaidi, kwa sababu ikiwa mtu ameshughulikia na kuangalia haswa jinsi ndege ya kudhibiti upeperushaji anuwai inavyoonekana, katika usakinishaji wote isipokuwa rahisi zaidi, hii ni maumivu ya kichwa. Na nini zaidi, ni vigumu kupata utekelezaji wa chanzo wazi unaofanya kazi vizuri, kwa mfano.
Hatimaye, tunatengeneza mitandao yetu ili isibadilike sana. Tunaweza kutegemea ukweli kwamba mtiririko wa matukio ya nje katika mfumo wa uelekezaji ni mdogo.
Ni matatizo gani yanayotokea na ni vikwazo gani vinavyopaswa kuzingatiwa tunapotengeneza mtandao wa kituo cha data? Gharama, bila shaka. Scalability, kiwango ambacho tunataka kukua. Haja ya kupanua bila kusimamisha huduma. Bandwidth, upatikanaji. Kuonekana kwa kile kinachotokea kwenye mtandao kwa mifumo ya ufuatiliaji, kwa timu za uendeshaji. Usaidizi wa otomatiki - tena, iwezekanavyo, kwani kazi tofauti zinaweza kutatuliwa kwa viwango tofauti, pamoja na kuanzishwa kwa tabaka za ziada. Kweli, sio [labda] tegemezi kwa wachuuzi. Ingawa katika vipindi tofauti vya kihistoria, kulingana na sehemu gani unayotazama, uhuru huu ulikuwa rahisi au mgumu zaidi kupatikana. Ikiwa tunachukua sehemu ya msalaba wa chips za kifaa cha mtandao, basi hadi hivi karibuni ilikuwa ni masharti sana kuzungumza juu ya uhuru kutoka kwa wachuuzi, ikiwa pia tulitaka chips na bandwidth ya juu.
Je, ni topolojia gani ya kimantiki tutakayotumia kujenga mtandao wetu? Hii itakuwa Clos ya ngazi nyingi. Kwa kweli, hakuna mbadala halisi kwa sasa. Na topolojia ya Clos ni nzuri kabisa, hata ikilinganishwa na topolojia kadhaa za hali ya juu ambazo ziko zaidi katika eneo la maslahi ya kitaaluma sasa, ikiwa tuna swichi kubwa za radix.
Je, mtandao wa ngazi nyingi wa Clos umeundwaje na vipengele tofauti vinaitwaje ndani yake? Awali ya yote, upepo ulipanda, ili ujielekeze ambapo ni kaskazini, wapi kusini, wapi mashariki na magharibi. Mitandao ya aina hii kawaida hujengwa na wale ambao wana trafiki kubwa sana ya magharibi-mashariki. Kama ilivyo kwa vitu vilivyobaki, juu ni swichi ya kawaida iliyokusanywa kutoka kwa swichi ndogo. Hili ndilo wazo kuu la ujenzi wa kujirudia wa mitandao ya Clos. Tunachukua vipengele vilivyo na aina fulani ya radix na kuviunganisha ili kile tunachopata kinaweza kuchukuliwa kama swichi yenye radix kubwa zaidi. Ikiwa unahitaji hata zaidi, utaratibu unaweza kurudiwa.
Katika kesi, kwa mfano, na Clos ya ngazi mbili, wakati inawezekana kutambua wazi vipengele vilivyo wima kwenye mchoro wangu, kwa kawaida huitwa ndege. Ikiwa tungejenga Clos yenye viwango vitatu vya swichi za mgongo (zote sio za mpaka au za ToR na ambazo hutumiwa tu kwa usafiri), basi ndege zingeonekana kuwa ngumu zaidi; Tunaita kizuizi cha ToR au swichi za majani na swichi za kiwango cha kwanza zinazohusiana nazo Pod. Swichi za mgongo za kiwango cha uti wa mgongo-1 juu ya Pod ni sehemu ya juu ya Pod, sehemu ya juu ya Pod. Swichi ambazo ziko juu ya kiwanda kizima ni safu ya juu ya kiwanda, Juu ya kitambaa.
Bila shaka, swali linatokea: Mitandao ya Clos imejengwa kwa muda fulani; Labda kitu bora zaidi kimeonekana, labda kitu kinaweza kufanywa vizuri zaidi? Ndiyo na hapana. Kinadharia ndiyo, katika mazoezi katika siku za usoni dhahiri si. Kwa sababu kuna idadi ya topolojia ya kuvutia, baadhi yao hutumiwa hata katika uzalishaji, kwa mfano, Dragonfly hutumiwa katika maombi ya HPC; Kuna pia topolojia za kupendeza kama vile Xpander, FatClique, Jellyfish. Ukiangalia ripoti kwenye mikutano kama SIGCOMM au NSDI hivi majuzi, unaweza kupata idadi kubwa ya kazi kuhusu topolojia mbadala ambazo zina sifa bora (moja au nyingine) kuliko Clos.
Lakini topolojia hizi zote zina mali moja ya kuvutia. Inazuia utekelezaji wao katika mitandao ya kituo cha data, ambayo tunajaribu kuunda kwenye maunzi ya bidhaa na ambayo hugharimu pesa nzuri. Katika topolojia hizi zote mbadala, bandwidth nyingi kwa bahati mbaya hazipatikani kupitia njia fupi zaidi. Kwa hiyo, mara moja tunapoteza fursa ya kutumia ndege ya udhibiti wa jadi.
Kinadharia, suluhisho la tatizo linajulikana. Hizi ni, kwa mfano, marekebisho ya hali ya kiungo kwa kutumia njia fupi ya k, lakini, tena, hakuna itifaki kama hizo ambazo zingetekelezwa katika uzalishaji na zinapatikana sana kwenye vifaa.
Zaidi ya hayo, kwa kuwa uwezo mwingi haupatikani kupitia njia fupi zaidi, tunahitaji kurekebisha zaidi ya ndege ya udhibiti ili kuchagua njia hizo zote (na kwa njia, hii ni hali zaidi katika ndege ya udhibiti). Bado tunahitaji kurekebisha ndege ya usambazaji, na, kama sheria, angalau vipengele viwili vya ziada vinahitajika. Huu ni uwezo wa kufanya maamuzi yote kuhusu usambazaji wa pakiti mara moja, kwa mfano, kwa mwenyeji. Kwa kweli, hii ni njia ya chanzo, wakati mwingine katika fasihi kwenye mitandao ya unganisho hii inaitwa maamuzi ya usambazaji mara moja. Na njia ya kurekebisha ni kazi ambayo tunahitaji kwenye vipengele vya mtandao, ambavyo vinapungua, kwa mfano, kwa ukweli kwamba tunachagua hop inayofuata kulingana na taarifa kuhusu mzigo mdogo kwenye foleni. Kwa mfano, chaguzi zingine zinawezekana.
Kwa hivyo, mwelekeo unavutia, lakini, ole, hatuwezi kuitumia hivi sasa.
Sawa, tulitulia kwenye topolojia ya kimantiki ya Clos. Je, tutaiweka vipi? Wacha tuone jinsi inavyofanya kazi na nini kinaweza kufanywa.
Katika mtandao wa Clos kuna vigezo viwili kuu ambavyo tunaweza kwa namna fulani kutofautiana na kupata matokeo fulani: radix ya vipengele na idadi ya ngazi katika mtandao. Nina mchoro wa kimuundo wa jinsi zote zinavyoathiri saizi. Kwa kweli, tunachanganya zote mbili.
Inaweza kuonekana kuwa upana wa mwisho wa mtandao wa Clos ni bidhaa ya viwango vyote vya swichi za mgongo wa radix ya kusini, ni viungo ngapi tuna chini, jinsi matawi. Hivi ndivyo tunavyoongeza ukubwa wa mtandao.
Kuhusu uwezo, haswa kwenye swichi za ToR, kuna chaguzi mbili za kuongeza kiwango. Tunaweza, huku tukidumisha topolojia ya jumla, kutumia viungo vya haraka, au tunaweza kuongeza ndege zaidi.
Ukiangalia toleo lililopanuliwa la mtandao wa Clos (katika kona ya chini kulia) na kurudi kwenye picha hii na mtandao wa Clos hapa chini...
... basi hii ni topolojia sawa, lakini kwenye slide hii imeanguka zaidi na ndege za kiwanda zimewekwa juu ya kila mmoja. Ni sawa.
Kuongeza mtandao wa Clos kunaonekanaje kwa nambari? Hapa ninatoa data juu ya upana wa juu wa mtandao unaweza kupatikana, ni idadi gani ya juu ya racks, swichi za ToR au swichi za majani, ikiwa haziko kwenye rafu, tunaweza kupata kulingana na ni radix gani ya swichi tunayotumia kwa viwango vya mgongo, na tunatumia viwango vingapi.
Hapa kuna racks ngapi tunaweza kuwa nazo, seva ngapi na takriban ni kiasi gani hiki kinaweza kutumia kulingana na kW 20 kwa rack. Hapo awali kidogo nilitaja kuwa tunalenga saizi ya nguzo ya seva elfu 100 hivi.
Inaweza kuonekana kuwa katika kubuni hii yote, chaguzi mbili na nusu ni za riba. Kuna chaguo na safu mbili za miiba na swichi za bandari 64, ambazo huanguka kidogo. Kisha kuna chaguo zinazofaa kabisa kwa 128-bandari (na radix 128) swichi za mgongo zilizo na viwango viwili, au swichi zilizo na radix 32 zilizo na viwango vitatu. Na katika hali zote, ambapo kuna radix zaidi na tabaka zaidi, unaweza kufanya mtandao mkubwa sana, lakini ikiwa unatazama matumizi yaliyotarajiwa, kwa kawaida kuna gigawati. Inawezekana kuweka kebo, lakini hatuna uwezekano wa kupata umeme mwingi kwenye tovuti moja. Ukiangalia takwimu na data ya umma kwenye vituo vya data, unaweza kupata vituo vichache sana vya data vilivyo na makadirio ya uwezo wa zaidi ya 150 MW. Kubwa kwa kawaida ni kampasi za kituo cha data, vituo kadhaa vikubwa vya data vilivyo karibu kabisa na kila mmoja.
Kuna parameter nyingine muhimu. Ukiangalia safu wima ya kushoto, kipimo data kinachoweza kutumika kimeorodheshwa hapo. Ni rahisi kuona kwamba katika mtandao wa Clos sehemu kubwa ya bandari hutumiwa kuunganisha swichi kwa kila mmoja. Bandwidth inayoweza kutumika, kipande muhimu, ni kitu ambacho kinaweza kutolewa nje, kuelekea seva. Kwa kawaida, ninazungumza juu ya bandari za masharti na haswa juu ya bendi. Kama sheria, viungo ndani ya mtandao ni haraka zaidi kuliko viungo kuelekea seva, lakini kwa kila kitengo cha kipimo data, kadiri tunavyoweza kuituma kwa vifaa vya seva yetu, bado kuna kipimo data ndani ya mtandao wenyewe. Na kadiri tunavyotengeneza viwango vingi, ndivyo gharama mahususi inavyokuwa kubwa zaidi ya kutoa mstari huu kwa nje.
Aidha, hata bendi hii ya ziada si sawa kabisa. Ingawa nafasi ni fupi, tunaweza kutumia kitu kama DAC (ambatisha shaba moja kwa moja, yaani, nyaya za twinax), au optics za multimode, ambazo hugharimu pesa nyingi zaidi au kidogo. Mara tu tunapohamia kwa vipindi virefu - kama sheria, hizi ni optics za hali moja, na gharama ya upelekaji data huu wa ziada huongezeka dhahiri.
Na tena, tukirudi kwenye slaidi iliyopita, ikiwa tunaunda mtandao wa Clos bila usajili zaidi, basi ni rahisi kutazama mchoro, angalia jinsi mtandao umejengwa - kuongeza kila ngazi ya swichi za mgongo, tunarudia kamba nzima iliyokuwa kwenye chini. Kiwango cha pamoja - pamoja na bendi sawa, idadi sawa ya bandari kwenye swichi kama ilivyokuwa katika ngazi ya awali, na idadi sawa ya transceivers. Kwa hiyo, ni yenye kuhitajika kupunguza idadi ya viwango vya swichi za mgongo.
Kulingana na picha hii, ni wazi kuwa tunataka kweli kujenga juu ya kitu kama swichi zilizo na radix ya 128.
Hapa, kimsingi, kila kitu ni sawa na kile nilichosema hivi punde; hii ni slaidi ya kuzingatiwa baadaye.
Kuna chaguzi gani ambazo tunaweza kuchagua kama swichi kama hizo? Ni habari za kupendeza sana kwetu kwamba sasa mitandao kama hii inaweza hatimaye kujengwa kwenye swichi za chip moja. Na hii ni nzuri sana, wana sifa nyingi nzuri. Kwa mfano, karibu hawana muundo wa ndani. Hii inamaanisha kuwa wanavunjika kwa urahisi zaidi. Wanavunja kwa kila aina ya njia, lakini kwa bahati nzuri huvunja kabisa. Katika vifaa vya msimu kuna idadi kubwa ya makosa (haifurahishi sana), wakati kutoka kwa mtazamo wa majirani na ndege ya kudhibiti inaonekana kuwa inafanya kazi, lakini, kwa mfano, sehemu ya kitambaa imepotea na haifanyi kazi. kwa uwezo kamili. Na trafiki kwa hiyo ni ya usawa kulingana na ukweli kwamba inafanya kazi kikamilifu, na tunaweza kupata overloaded.
Au, kwa mfano, shida huibuka na ndege ya nyuma, kwa sababu ndani ya kifaa cha kawaida pia kuna SerDes za kasi kubwa - ni ngumu sana ndani. Ishara kati ya vipengele vya usambazaji husawazishwa au hazijasawazishwa. Kwa ujumla, kifaa chochote cha msimu kinachozalisha kinachojumuisha idadi kubwa ya vipengele, kama sheria, kina mtandao sawa wa Clos ndani yenyewe, lakini ni vigumu sana kutambua. Mara nyingi ni vigumu kwa hata muuzaji mwenyewe kutambua.
Na ina idadi kubwa ya matukio ya kushindwa ambayo kifaa hupungua, lakini haitoke nje ya topolojia kabisa. Kwa kuwa mtandao wetu ni mkubwa, kusawazisha kati ya vitu vinavyofanana hutumiwa kikamilifu, mtandao ni wa kawaida sana, ambayo ni, njia moja ambayo kila kitu kiko katika mpangilio sio tofauti na njia nyingine, ni faida zaidi kwetu kupoteza tu baadhi yao. vifaa kutoka kwa topolojia kuliko kuishia katika hali ambapo baadhi yao wanaonekana kufanya kazi, lakini baadhi yao hawana.
Kipengele kizuri kinachofuata cha vifaa vya chip-moja ni kwamba vinabadilika vizuri na haraka. Pia huwa na uwezo bora zaidi. Ikiwa tunachukua miundo mikubwa iliyokusanyika ambayo tunayo kwenye mduara, basi uwezo wa kila kitengo cha rack kwa bandari za kasi sawa ni karibu mara mbili kuliko ile ya vifaa vya kawaida. Vifaa vilivyojengwa karibu na chip moja ni nafuu zaidi kuliko za kawaida na hutumia nishati kidogo.
Lakini, bila shaka, hii yote ni kwa sababu, pia kuna hasara. Kwanza, radix ni karibu kila wakati ndogo kuliko ile ya vifaa vya kawaida. Ikiwa tunaweza kupata kifaa kilichojengwa karibu na chip moja na bandari 128, basi tunaweza kupata moduli yenye bandari mia kadhaa sasa bila matatizo yoyote.
Hii ni saizi ndogo zaidi ya jedwali za usambazaji na, kama sheria, kila kitu kinachohusiana na upanuzi wa ndege ya data. Vibafa vifupi. Na, kama sheria, utendaji mdogo. Lakini zinageuka kuwa ikiwa unajua vikwazo hivi na kutunza kwa wakati ili kuvizuia au kuzizingatia tu, basi hii sio ya kutisha sana. Ukweli kwamba radix ni ndogo sio shida tena kwenye vifaa vilivyo na radix ya 128 ambayo hatimaye imeonekana hivi karibuni tunaweza kujenga katika tabaka mbili za miiba. Lakini bado haiwezekani kujenga kitu kidogo kuliko mbili ambacho kinatuvutia. Kwa ngazi moja, makundi madogo sana yanapatikana. Hata miundo na mahitaji yetu ya awali bado yalizidi.
Kwa kweli, ikiwa ghafla suluhisho liko mahali fulani kwenye ukingo, bado kuna njia ya kuongeza kiwango. Kwa kuwa kiwango cha mwisho (au cha kwanza), cha chini kabisa ambapo seva zimeunganishwa ni swichi za ToR au swichi za majani, hatuhitajiki kuunganisha rack moja kwao. Kwa hiyo, ikiwa suluhisho linapungua kwa karibu nusu, unaweza kufikiri juu ya kutumia tu kubadili na radix kubwa kwenye ngazi ya chini na kuunganisha, kwa mfano, racks mbili au tatu kwenye kubadili moja. Hii pia ni chaguo, ina gharama zake, lakini inafanya kazi vizuri na inaweza kuwa suluhisho nzuri wakati unahitaji kufikia karibu mara mbili ya ukubwa.
Kwa muhtasari, tunajenga juu ya topolojia yenye viwango viwili vya miiba, yenye tabaka nane za kiwanda.
Nini kitatokea kwa fizikia? Mahesabu rahisi sana. Ikiwa tuna viwango viwili vya miiba, basi tuna ngazi tatu tu za swichi, na tunatarajia kuwa kutakuwa na sehemu tatu za cable kwenye mtandao: kutoka kwa seva hadi swichi za jani, kwa mgongo 1, kwa mgongo 2. Chaguzi ambazo tunaweza matumizi ni - hizi ni twinax, multimode, mode moja. Na hapa tunahitaji kuzingatia ni strip gani inapatikana, ni kiasi gani itagharimu, ni vipimo gani vya mwili, ni nafasi gani tunaweza kufunika, na jinsi tutakavyoboresha.
Kwa suala la gharama, kila kitu kinaweza kupangwa. Twinaxes ni nafuu zaidi kuliko optics hai, nafuu zaidi kuliko transceivers ya multimode, ikiwa unaichukua kwa ndege kutoka mwisho, kwa kiasi fulani nafuu kuliko bandari ya kubadili 100-gigabit. Na, tafadhali kumbuka, inagharimu chini ya optics ya hali moja, kwa sababu kwenye ndege ambapo hali moja inahitajika, katika vituo vya data kwa sababu kadhaa ni mantiki kutumia CWDM, wakati hali ya sambamba (PSM) haifai sana kufanya kazi. na, pakiti kubwa sana hupatikana nyuzi, na ikiwa tunazingatia teknolojia hizi, tunapata takriban safu zifuatazo za bei.
Kumbuka moja zaidi: kwa bahati mbaya, haiwezekani kutumia bandari za multimode 100 hadi 4x25. Kutokana na vipengele vya kubuni vya transceivers za SFP28, sio nafuu zaidi kuliko 28 Gbit QSFP100. Na disassembly hii kwa multimode haifanyi kazi vizuri sana.
Kikwazo kingine ni kwamba kutokana na ukubwa wa makundi ya kompyuta na idadi ya seva, vituo vyetu vya data vinageuka kuwa vikubwa kimwili. Hii inamaanisha kuwa angalau ndege moja italazimika kufanywa na singlemod. Tena, kwa sababu ya saizi ya mwili ya Pods, haitawezekana kuendesha safu mbili za twinax (nyaya za shaba).
Kwa hivyo, ikiwa tutaboresha kwa bei na kuzingatia jiometri ya muundo huu, tunapata span moja ya twinax, span moja ya multimode na span moja ya singlemode kwa kutumia CWDM. Hii inazingatia njia zinazowezekana za uboreshaji.
Hivi ndivyo inavyoonekana hivi karibuni, tunakoelekea na kile kinachowezekana. Ni wazi, angalau, jinsi ya kuelekea 50-Gigabit SerDes kwa multimode na singlemode. Zaidi ya hayo, ukiangalia kilicho katika vipitishio vya modi moja sasa na katika siku zijazo kwa 400G, mara nyingi hata 50G SerDes inapofika kutoka upande wa umeme, Gbps 100 kwa kila njia tayari inaweza kwenda kwa optics. Kwa hiyo, inawezekana kabisa kwamba badala ya kuhamia 50, kutakuwa na mpito kwa 100 Gigabit SerDes na 100 Gbps kwa mstari, kwa sababu kulingana na ahadi za wauzaji wengi, upatikanaji wao unatarajiwa hivi karibuni. Kipindi ambacho 50G SerDes zilikuwa za haraka zaidi, inaonekana, haitakuwa ndefu sana, kwa sababu nakala za kwanza za 100G SerDes zitatolewa karibu mwaka ujao. Na baada ya muda baada ya hapo watakuwa na thamani ya pesa nzuri.
Nuance moja zaidi kuhusu uchaguzi wa fizikia. Kimsingi, tunaweza tayari kutumia bandari 400 au 200 za Gigabit kwa kutumia 50G SerDes. Lakini inabadilika kuwa hii haina maana sana, kwa sababu, kama nilivyosema hapo awali, tunataka radix kubwa kwenye swichi, kwa sababu, bila shaka. Tunataka 128. Na ikiwa tuna uwezo mdogo wa chip na tunaongeza kasi ya kiungo, basi radix hupungua kwa kawaida, hakuna miujiza.
Na tunaweza kuongeza uwezo wa jumla kwa kutumia ndege, na hakuna gharama maalum tunaweza kuongeza idadi ya ndege. Na ikiwa tunapoteza radix, tutalazimika kuanzisha kiwango cha ziada, kwa hiyo katika hali ya sasa, na uwezo wa sasa wa juu unaopatikana kwa kila chip, inageuka kuwa ni ufanisi zaidi kutumia bandari za gigabit 100, kwa sababu zinakuwezesha. kupata radix kubwa.
Swali linalofuata ni jinsi fizikia inavyopangwa, lakini kutoka kwa mtazamo wa miundombinu ya cable. Inageuka kuwa imepangwa kwa njia ya kuchekesha. Kuunganisha kati ya swichi za majani na miiba ya kiwango cha kwanza - hakuna viungo vingi hapo, kila kitu kimejengwa kwa urahisi. Lakini ikiwa tunachukua ndege moja, kinachotokea ndani ni kwamba tunahitaji kuunganisha miiba yote ya ngazi ya kwanza na miiba yote ya ngazi ya pili.
Pamoja, kama sheria, kuna matakwa ya jinsi inapaswa kuonekana ndani ya kituo cha data. Kwa mfano, tulitaka sana kuchanganya nyaya kwenye kifungu na kuzivuta ili paneli moja ya kiraka yenye msongamano wa juu iingie kabisa kwenye paneli moja ya kiraka, ili kusiwe na bustani ya wanyama kulingana na urefu. Tulifanikiwa kutatua tatizo hili. Ikiwa mwanzoni unatazama topolojia ya mantiki, unaweza kuona kwamba ndege zinajitegemea, kila ndege inaweza kujengwa peke yake. Lakini tunapoongeza mshikamano kama huu na kutaka kuburuta kibandiko kizima kwenye paneli ya kiraka, inabidi tuchanganye ndege tofauti ndani ya kifungu kimoja na kuanzisha muundo wa kati kwa njia ya miunganisho ya macho ili kuzipakia tena kutoka kwa jinsi zilivyokusanywa. kwenye sehemu moja, jinsi watakavyokusanywa kwenye sehemu nyingine. Shukrani kwa hili, tunapata kipengele kizuri: ubadilishaji wote ngumu hauendi zaidi ya racks. Unapohitaji kuunganisha kitu kwa nguvu sana, "funua ndege," kama inavyoitwa wakati mwingine katika mitandao ya Clos, yote yamejilimbikizia ndani ya rack moja. Hatuna disassembled sana, chini ya viungo binafsi, byte kati ya racks.
Hivi ndivyo inavyoonekana kutoka kwa mtazamo wa shirika la mantiki la miundombinu ya cable. Katika picha iliyo upande wa kushoto, vizuizi vya rangi nyingi vinaonyesha vitalu vya swichi za kiwango cha kwanza za uti wa mgongo, vipande nane kila kimoja, na vifurushi vinne vya nyaya zinazotoka kwao, ambazo huenda na kukatiza na vifurushi vinavyotoka kwenye sehemu za swichi za spine-2. .
Viwanja vidogo vinaonyesha makutano. Katika sehemu ya juu kushoto kuna mgawanyiko wa kila makutano kama haya, kwa kweli hii ni moduli ya unganisho la bandari ya 512 kwa 512 ambayo hupakia tena nyaya ili zije kabisa kwenye rafu moja, ambapo kuna ndege moja tu ya mgongo-2. Na upande wa kulia, skanisho ya picha hii ni ya kina zaidi kuhusiana na Pods kadhaa kwenye kiwango cha mgongo-1, na jinsi inavyowekwa kwenye unganisho la msalaba, jinsi inavyokuja kwenye kiwango cha mgongo-2.
Hivi ndivyo inavyoonekana. Simama ya mgongo-2 ambayo bado haijakusanyika kikamilifu (upande wa kushoto) na sehemu ya kuunganisha msalaba. Kwa bahati mbaya, hakuna mengi ya kuona huko. Muundo huu wote unatumwa sasa hivi katika mojawapo ya vituo vyetu vikubwa vya data ambavyo vinapanuliwa. Hii ni kazi inayoendelea, itaonekana kuwa nzuri zaidi, itajazwa vizuri zaidi.
Swali muhimu: tulichagua topolojia ya kimantiki na tukajenga fizikia. Nini kitatokea kwa ndege ya kudhibiti? Inajulikana sana kutoka kwa uzoefu wa kufanya kazi, kuna ripoti kadhaa ambazo itifaki za serikali zilizounganishwa ni nzuri, ni raha kufanya kazi nazo, lakini, kwa bahati mbaya, hazilingani na topolojia iliyounganishwa sana. Na kuna jambo moja kuu linalozuia hili - hii ni jinsi mafuriko yanavyofanya kazi katika itifaki za hali ya kiungo. Ukichukua tu algoriti ya mafuriko na kuangalia jinsi mtandao wetu ulivyoundwa, unaweza kuona kwamba kutakuwa na fanout kubwa sana kwa kila hatua, na itafurika ndege ya udhibiti na masasisho. Hasa, topolojia kama hizo huchanganyika vibaya sana na algoriti ya jadi ya mafuriko katika itifaki za hali ya kiungo.
Chaguo ni kutumia BGP. Jinsi ya kuitayarisha kwa usahihi imeelezwa katika RFC 7938 kuhusu matumizi ya BGP katika vituo vikubwa vya data. Mawazo ya kimsingi ni rahisi: idadi ya chini ya viambishi awali kwa kila seva pangishi na kwa ujumla idadi ndogo ya viambishi awali kwenye mtandao, tumia ujumlisho ikiwezekana, na kandamiza uwindaji wa njia. Tunataka usambazaji makini sana, unaodhibitiwa sana wa sasisho, kile kinachoitwa valley free. Tunataka masasisho yasambazwe mara moja tu yanapopitia mtandao. Ikiwa zinatoka chini, huenda juu, zisizozidi mara moja. Haipaswi kuwa na zigzags. Zigzags ni mbaya sana.
Ili kufanya hivyo, tunatumia muundo ambao ni rahisi kutosha kutumia mifumo ya msingi ya BGP. Hiyo ni, tunatumia eBGP inayoendesha kwenye kiunga cha ndani, na mifumo inayojitegemea imepewa kama ifuatavyo: mfumo wa uhuru kwenye ToR, mfumo unaojitegemea kwenye kizuizi kizima cha swichi za mgongo-1 za Pod moja, na mfumo wa jumla wa uhuru kwenye Juu nzima. ya Kitambaa. Si vigumu kuangalia na kuona kwamba hata tabia ya kawaida ya BGP inatupa usambazaji wa sasisho ambazo tunataka.
Kwa kawaida, anwani na ujumlishaji wa anwani lazima zibuniwe ili ziendane na jinsi uelekezaji unavyojengwa, ili kuhakikisha uthabiti wa ndege ya kudhibiti. Ushughulikiaji wa L3 katika usafirishaji umefungwa kwa topolojia, kwa sababu bila hii haiwezekani kufikia mkusanyiko, bila anwani hii ya kibinafsi itaingia kwenye mfumo wa uelekezaji. Na jambo moja zaidi ni kwamba mkusanyiko, kwa bahati mbaya, hauchanganyiki vizuri na njia nyingi, kwa sababu tunapokuwa na njia nyingi na tunayo mkusanyiko, kila kitu kiko sawa, wakati mtandao wote una afya, hakuna makosa ndani yake. Kwa bahati mbaya, mara tu kushindwa kunapoonekana kwenye mtandao na ulinganifu wa topolojia unapotea, tunaweza kufikia hatua ambayo kitengo kilitangazwa, ambacho hatuwezi kwenda mbali zaidi ambapo tunahitaji kwenda. Kwa hivyo, ni bora kujumlisha mahali ambapo hakuna njia nyingi zaidi, kwa upande wetu hizi ni swichi za ToR.
Kwa kweli, inawezekana kwa jumla, lakini kwa uangalifu. Ikiwa tunaweza kufanya utenganishaji unaodhibitiwa wakati hitilafu za mtandao zinatokea. Lakini hii ni kazi ngumu sana, hata tulijiuliza ikiwa ingewezekana kufanya hivi, ikiwa inawezekana kuongeza otomatiki ya ziada, na mashine za hali ya kikomo ambazo zingepiga BGP kwa usahihi kupata tabia inayotaka. Kwa bahati mbaya, kesi za kona za usindikaji sio wazi sana na ngumu, na kazi hii haijatatuliwa vizuri kwa kuambatanisha viambatisho vya nje kwa BGP.
Kazi ya kuvutia sana katika suala hili imefanywa ndani ya mfumo wa itifaki ya RIFT, ambayo itajadiliwa katika ripoti inayofuata.
Jambo lingine muhimu ni jinsi ndege za data zinavyokua katika topolojia mnene, ambapo tuna idadi kubwa ya njia mbadala. Katika kesi hii, miundo kadhaa ya ziada ya data hutumiwa: Vikundi vya ECMP, ambavyo vinaelezea vikundi vya Next Hop.
Katika mtandao wa kawaida wa kufanya kazi, bila kushindwa, tunapopanda topolojia ya Clos, inatosha kutumia kikundi kimoja tu, kwa sababu kila kitu ambacho si cha ndani kinaelezewa na default, tunaweza kwenda juu. Tunapotoka juu hadi chini hadi kusini, basi njia zote sio ECMP, ni njia za njia moja. Kila kitu kiko sawa. Shida ni kwamba, na upekee wa topolojia ya Clos ya kawaida ni kwamba ikiwa tunatazama Juu ya kitambaa, kwa kipengele chochote, kuna njia moja tu ya kipengele chochote hapa chini. Ikiwa hitilafu zitatokea kwenye njia hii, basi kipengele hiki kilicho juu ya kiwanda kinakuwa si sahihi kwa viambishi awali ambavyo viko nyuma ya njia iliyovunjika. Lakini kwa wengine ni halali, na inabidi tuchanganue vikundi vya ECMP na kutambulisha hali mpya.
Je, uboreshaji wa ndege ya data unaonekanaje kwenye vifaa vya kisasa? Ikiwa tutafanya LPM (kinalingana cha kiambishi kirefu zaidi), kila kitu ni kizuri kabisa, zaidi ya viambishi awali 100k. Ikiwa tunazungumza juu ya vikundi vya Next Hop, basi kila kitu ni mbaya zaidi, 2-4 elfu. Ikiwa tunazungumzia juu ya meza ambayo ina maelezo ya Next Hops (au adjacencies), basi hii ni mahali fulani kutoka 16k hadi 64k. Na hii inaweza kuwa shida. Na hapa tunakuja kwenye hali ya kupendeza: nini kilifanyika kwa MPLS katika vituo vya data? Kimsingi, tulitaka kuifanya.
Mambo mawili yalitokea. Tulifanya sehemu ndogo kwenye wapangishaji hatukuhitaji tena kuifanya kwenye mtandao. Haikuwa nzuri sana kwa msaada kutoka kwa wachuuzi tofauti, na hata zaidi na utekelezaji wazi kwenye masanduku nyeupe na MPLS. Na MPLS, angalau utekelezaji wake wa jadi, kwa bahati mbaya, unachanganya vibaya sana na ECMP. Na ndiyo maana.
Hivi ndivyo muundo wa usambazaji wa ECMP wa IP unavyoonekana. Idadi kubwa ya viambishi awali inaweza kutumia kundi moja na kizuizi sawa Next Hops (au adjacencies, hii inaweza kuitwa tofauti katika nyaraka mbalimbali kwa ajili ya vifaa mbalimbali). Jambo ni kwamba hii inaelezewa kama bandari inayotoka na nini cha kuandika tena anwani ya MAC ili kufikia Next Hop sahihi. Kwa IP kila kitu kinaonekana rahisi, unaweza kutumia idadi kubwa sana ya viambishi awali kwa kundi moja, kizuizi sawa cha Next Hops.
Usanifu wa kawaida wa MPLS unamaanisha kuwa, kulingana na kiolesura kinachotoka, lebo inaweza kuandikwa upya kwa maadili tofauti. Kwa hivyo, tunahitaji kuweka kikundi na kizuizi cha Next Hops kwa kila lebo ya ingizo. Na hii, ole, haina kiwango.
Ni rahisi kuona kwamba katika muundo wetu tulihitaji kuhusu swichi 4000 za ToR, upana wa juu ulikuwa njia 64 za ECMP, ikiwa tutaondoka kwenye mgongo-1 kuelekea mgongo-2. Ni kwa shida sana tunaingia kwenye jedwali moja la vikundi vya ECMP, ikiwa kiambishi awali kimoja tu na ToR kitatoweka, na hatuingii kwenye jedwali la Next Hops hata kidogo.
Siyo yote ya kukatisha tamaa, kwa sababu usanifu kama vile Upangaji wa Sehemu unahusisha lebo za kimataifa. Rasmi, itawezekana kukunja vitalu hivi vyote vya Next Hops tena. Ili kufanya hivyo, unahitaji operesheni ya aina ya kadi ya mwitu: chukua lebo na uandike tena kwa moja bila thamani maalum. Lakini kwa bahati mbaya, hii haipo sana katika utekelezaji unaopatikana.
Na hatimaye, tunahitaji kuleta trafiki ya nje kwenye kituo cha data. Jinsi ya kufanya hivyo? Hapo awali, trafiki ilianzishwa kwenye mtandao wa Clos kutoka juu. Hiyo ni, kulikuwa na ruta za makali ambazo ziliunganishwa na vifaa vyote kwenye Juu ya kitambaa. Suluhisho hili linafanya kazi vizuri kwa ukubwa mdogo hadi wa kati. Kwa bahati mbaya, ili kutuma trafiki kwa ulinganifu kwa mtandao mzima kwa njia hii, tunahitaji kufika wakati huo huo kwa vipengele vyote vya Juu ya kitambaa, na wakati kuna zaidi ya mia moja yao, inageuka kuwa tunahitaji pia kubwa. radix kwenye ruta za makali. Kwa ujumla, hii ina gharama ya fedha, kwa sababu routers makali ni kazi zaidi, bandari juu yao itakuwa ghali zaidi, na kubuni si nzuri sana.
Chaguo jingine ni kuanza trafiki kama hiyo kutoka chini. Ni rahisi kuthibitisha kuwa topolojia ya Clos imeundwa kwa njia ambayo trafiki inayotoka chini, ambayo ni, kutoka upande wa ToR, inasambazwa sawasawa kati ya viwango kote Juu ya kitambaa kwa marudio mawili, ikipakia mtandao mzima. Kwa hiyo, tunaanzisha aina maalum ya Pod, Edge Pod, ambayo hutoa uunganisho wa nje.
Kuna chaguo moja zaidi. Hivi ndivyo Facebook hufanya, kwa mfano. Wanaiita Fabric Aggregator au HGRID. Kiwango cha ziada cha mgongo kinaanzishwa ili kuunganisha vituo vingi vya data. Muundo huu unawezekana ikiwa hatuna utendakazi wa ziada au mabadiliko ya usimbaji kwenye violesura. Ikiwa ni sehemu za ziada za kugusa, ni vigumu. Kwa kawaida, kuna utendaji zaidi na aina ya utando unaotenganisha sehemu tofauti za kituo cha data. Hakuna maana katika kufanya utando huo mkubwa, lakini ikiwa ni kweli inahitajika kwa sababu fulani, basi ni mantiki kuzingatia uwezekano wa kuiondoa, kuifanya kwa upana iwezekanavyo na kuihamisha kwa majeshi. Hii inafanywa, kwa mfano, na waendeshaji wengi wa wingu. Wana vifuniko, huanza kutoka kwa majeshi.
Je, tunaona fursa gani za maendeleo? Kwanza kabisa, kuboresha msaada kwa bomba la CI/CD. Tunataka kuruka jinsi tunavyojaribu na kujaribu jinsi tunavyoruka. Hii haifanyi kazi vizuri, kwa sababu miundombinu ni kubwa na haiwezekani kurudia kwa vipimo. Unahitaji kuelewa jinsi ya kutambulisha vipengele vya majaribio kwenye miundombinu ya uzalishaji bila kuiangusha.
Uwekaji ala bora na ufuatiliaji bora karibu sio wa kupita kiasi. Swali zima ni usawa wa juhudi na kurudi. Ikiwa unaweza kuiongeza kwa bidii inayofaa, nzuri sana.
Fungua mifumo ya uendeshaji kwa vifaa vya mtandao. Itifaki bora na mifumo bora ya uelekezaji, kama vile RIFT. Utafiti unahitajika pia katika matumizi ya mipango bora ya kudhibiti msongamano na pengine kuanzishwa, angalau katika baadhi ya maeneo, ya usaidizi wa RDMA ndani ya nguzo.
Tukiangalia zaidi siku zijazo, tunahitaji topolojia za hali ya juu na ikiwezekana mitandao inayotumia gharama ndogo. Kati ya mambo mapya, hivi karibuni kumekuwa na machapisho kuhusu teknolojia ya kitambaa cha HPC Cray Slingshot, ambayo inategemea bidhaa Ethernet, lakini kwa chaguo la kutumia vichwa vifupi zaidi. Matokeo yake, overhead ni kupunguzwa.
Kila kitu kinapaswa kuwekwa rahisi iwezekanavyo, lakini si rahisi. Utata ni adui wa scalability. Urahisi na miundo ya kawaida ni marafiki zetu. Ikiwa unaweza kufanya kiwango nje mahali fulani, fanya hivyo. Na kwa ujumla, ni vizuri kushiriki katika teknolojia za mtandao sasa. Kuna mambo mengi ya kuvutia yanayoendelea. Asante.
Chanzo: mapenzi.com
