Rydym wedi datblygu cynllun rhwydwaith canolfan ddata sy'n caniatáu defnyddio clystyrau cyfrifiadurol sy'n fwy na 100 mil o weinyddion gyda lled band hanner rhaniad brig o dros un petabyte yr eiliad.
O adroddiad Dmitry Afanasyev byddwch yn dysgu am egwyddorion sylfaenol y dyluniad newydd, topolegau graddio, y problemau sy'n codi gyda hyn, opsiynau ar gyfer eu datrys, nodweddion llwybro a graddio swyddogaethau awyren anfon ymlaen dyfeisiau rhwydwaith modern mewn “cyswllt trwchus” topolegau gyda nifer fawr o lwybrau ECMP . Yn ogystal, siaradodd Dima yn fyr am drefniadaeth cysylltedd allanol, yr haen ffisegol, y system geblau a ffyrdd o gynyddu gallu ymhellach.
- Prynhawn da pawb! Fy enw i yw Dmitry Afanasyev, rwy'n bensaer rhwydwaith yn Yandex ac yn dylunio rhwydweithiau canolfan ddata yn bennaf.
Bydd fy stori yn ymwneud â'r rhwydwaith diweddaraf o ganolfannau data Yandex. Mae'n esblygiad o'r dyluniad oedd gennym ni, ond ar yr un pryd mae rhai elfennau newydd. Mae hwn yn gyflwyniad trosolwg oherwydd roedd llawer o wybodaeth i'w bacio i ychydig o amser. Byddwn yn dechrau trwy ddewis topoleg resymegol. Yna bydd trosolwg o'r awyren reoli a phroblemau gyda scalability awyren data, dewis o beth fydd yn digwydd ar y lefel ffisegol, a byddwn yn edrych ar rai o nodweddion y dyfeisiau. Gadewch i ni gyffwrdd ychydig ar yr hyn sy'n digwydd mewn canolfan ddata gyda MPLS, y buom yn siarad amdano beth amser yn ôl.
Felly, beth yw Yandex o ran llwythi a gwasanaethau? Mae Yandex yn hyperscaler nodweddiadol. Os edrychwn ar y defnyddwyr, rydym yn prosesu ceisiadau defnyddwyr yn bennaf. Hefyd gwasanaethau ffrydio amrywiol a throsglwyddo data, oherwydd mae gennym hefyd wasanaethau storio. Os yw'n agosach at y pen ôl, yna mae llwythi seilwaith a gwasanaethau'n ymddangos yno, megis storio gwrthrychau wedi'u dosbarthu, dyblygu data ac, wrth gwrs, ciwiau parhaus. Un o'r prif fathau o lwythi gwaith yw MapReduce a systemau tebyg, prosesu ffrydiau, dysgu peiriannau, ac ati.
Sut mae'r seilwaith y mae hyn i gyd yn digwydd ar ei ben? Unwaith eto, rydym yn hyperscaler eithaf nodweddiadol, er ein bod efallai ychydig yn nes at ochr hyperscaler llai y sbectrwm. Ond mae gennym ni'r holl briodoleddau. Rydym yn defnyddio caledwedd nwyddau a graddio llorweddol lle bynnag y bo modd. Mae gennym gronni adnoddau llawn: nid ydym yn gweithio gyda pheiriannau unigol, raciau unigol, ond yn eu cyfuno i mewn i gronfa fawr o adnoddau ymgyfnewidiol gyda rhai gwasanaethau ychwanegol sy'n ymdrin â chynllunio a dyrannu, ac yn gweithio gyda'r gronfa gyfan hon.
Felly mae gennym y lefel nesaf - y system weithredu ar lefel clwstwr cyfrifiadura. Mae’n bwysig iawn inni reoli’r pentwr technoleg a ddefnyddiwn yn llawn. Rydyn ni'n rheoli'r pwyntiau terfyn (gwestewyr), y rhwydwaith a'r stac meddalwedd.
Mae gennym nifer o ganolfannau data mawr yn Rwsia a thramor. Maent yn cael eu huno gan asgwrn cefn sy'n defnyddio technoleg MPLS. Mae ein seilwaith mewnol bron yn gyfan gwbl wedi'i adeiladu ar IPv6, ond gan fod angen i ni wasanaethu traffig allanol sy'n dal i ddod yn bennaf dros IPv4, mae'n rhaid i ni rywsut gyflwyno ceisiadau sy'n dod dros IPv4 i'r gweinyddwyr frontend, ac ychydig mwy ewch i IPv4 allanol - Rhyngrwyd - ar gyfer enghraifft, ar gyfer mynegeio.
Mae'r ychydig fersiynau diwethaf o ddyluniadau rhwydwaith canolfannau data wedi defnyddio topolegau Clos aml-haen ac maent yn L3 yn unig. Gadawsom L2 ychydig yn ôl ac anadlu ochenaid o ryddhad. Yn olaf, mae ein seilwaith yn cynnwys cannoedd o filoedd o achosion cyfrifiadurol (gweinydd). Yr uchafswm maint clwstwr beth amser yn ôl oedd tua 10 mil o weinyddion. Mae hyn yn bennaf oherwydd sut y gall yr un systemau gweithredu lefel clwstwr, amserlenwyr, dyraniad adnoddau, ac ati weithio Gan fod cynnydd wedi digwydd ar ochr meddalwedd seilwaith, mae'r maint targed bellach tua 100 mil o weinyddion mewn un clwstwr cyfrifiadurol, a Mae gennym dasg - gallu adeiladu ffatrïoedd rhwydwaith sy'n caniatáu cronni adnoddau'n effeithlon mewn clwstwr o'r fath.
Beth ydym ni ei eisiau o rwydwaith canolfan ddata? Yn gyntaf oll, mae yna lawer o led band rhad ac wedi'i ddosbarthu'n weddol unffurf. Oherwydd y rhwydwaith yw asgwrn cefn y gallwn gronni adnoddau drwyddo. Y maint targed newydd yw tua 100 mil o weinyddion mewn un clwstwr.
Rydym hefyd, wrth gwrs, eisiau awyren reoli scalable a sefydlog, oherwydd ar seilwaith mor fawr mae llawer o gur pen yn codi hyd yn oed o ddigwyddiadau ar hap yn unig, ac nid ydym am i'r awyren reoli ddod â chur pen inni hefyd. Ar yr un pryd, rydym am leihau'r cyflwr ynddo. Po leiaf yw'r cyflwr, y gorau a'r mwyaf sefydlog y mae popeth yn gweithio, a'r hawsaf yw gwneud diagnosis.
Wrth gwrs, mae angen awtomeiddio, oherwydd mae'n amhosibl rheoli seilwaith o'r fath â llaw, ac mae wedi bod yn amhosibl ers peth amser. Mae arnom angen cymorth gweithredol cymaint â phosibl a chymorth CI/CD i'r graddau y gellir ei ddarparu.
Gyda chymaint o ganolfannau data a chlystyrau, mae'r dasg o gefnogi defnydd cynyddrannol ac ehangu heb ymyrraeth gwasanaeth wedi dod yn eithaf difrifol. Os ar glystyrau o faint o fil o beiriannau, efallai yn agos at ddeg mil o beiriannau, gellid dal i'w cyflwyno fel un gweithrediad - hynny yw, rydym yn bwriadu ehangu'r seilwaith, ac ychwanegir miloedd o beiriannau fel un gweithrediad, yna nid yw clwstwr o faintioli can' mil o beiriannau yn codi ar unwaith fel hyn, mae yn cael ei adeiladu dros ysbaid o amser. Ac mae'n ddymunol drwy'r amser hwn bod yr hyn sydd eisoes wedi'i bwmpio, sef y seilwaith sydd wedi'i ddefnyddio, ar gael.
Ac un gofyniad a oedd gennym ac a adawodd: cefnogaeth ar gyfer aml-denantiaeth, hynny yw, rhithwiroli neu segmentu rhwydwaith. Nawr nid oes angen i ni wneud hyn ar lefel ffabrig y rhwydwaith, oherwydd mae'r darnio wedi mynd i'r gwesteiwyr, ac mae hyn wedi gwneud graddio'n hawdd iawn i ni. Diolch i IPv6 a gofod cyfeiriad mawr, nid oedd angen i ni ddefnyddio cyfeiriadau dyblyg yn y seilwaith mewnol; roedd pob cyfeiriad eisoes yn unigryw. A diolch i'r ffaith ein bod wedi mynd â hidlo a segmentu rhwydwaith i'r gwesteiwyr, nid oes angen i ni greu unrhyw endidau rhwydwaith rhithwir mewn rhwydweithiau canolfannau data.
Peth pwysig iawn yw'r hyn nad oes ei angen arnom. Os gellir tynnu rhai swyddogaethau o'r rhwydwaith, mae hyn yn gwneud bywyd yn llawer haws, ac, fel rheol, yn ehangu'r dewis o offer a meddalwedd sydd ar gael, gan wneud diagnosteg yn syml iawn.
Felly, beth nad oes ei angen arnom, beth rydym wedi gallu rhoi’r gorau iddi, nid bob amser gyda llawenydd ar yr adeg y digwyddodd, ond gyda rhyddhad mawr pan fydd y broses wedi’i chwblhau?
Yn gyntaf oll, rhoi'r gorau i L2. Nid oes angen L2 arnom, nid yw'n real nac yn efelychiad. Heb ei ddefnyddio yn bennaf oherwydd y ffaith ein bod yn rheoli'r pentwr cais. Mae ein cymwysiadau yn raddadwy yn llorweddol, maen nhw'n gweithio gyda chyfeiriadau L3, nid ydyn nhw'n poeni'n fawr bod rhai achosion unigol wedi mynd allan, maen nhw'n syml yn cyflwyno un newydd, nid oes angen ei gyflwyno yn yr hen gyfeiriad, oherwydd mae yna un lefel gwasanaeth ar wahân o ddarganfod a monitro peiriannau sydd wedi'u lleoli yn y clwstwr. Nid ydym yn dirprwyo'r dasg hon i'r rhwydwaith. Gwaith y rhwydwaith yw dosbarthu pecynnau o bwynt A i bwynt B.
Nid oes gennym ychwaith sefyllfaoedd lle mae cyfeiriadau yn symud o fewn y rhwydwaith, ac mae angen monitro hyn. Mewn llawer o ddyluniadau mae angen hyn yn nodweddiadol i gefnogi symudedd VM. Nid ydym yn defnyddio symudedd peiriannau rhithwir yn seilwaith mewnol y Yandex mawr, ac, ar ben hynny, credwn, hyd yn oed os gwneir hyn, na ddylai ddigwydd gyda chefnogaeth rhwydwaith. Os oes gwir angen i chi wneud hyn, mae angen i chi ei wneud ar lefel y gwesteiwr, a gwthio cyfeiriadau a all fudo i droshaenau, er mwyn peidio â chyffwrdd neu wneud gormod o newidiadau deinamig i system llwybro'r ishaen ei hun (rhwydwaith trafnidiaeth) .
Technoleg arall nad ydym yn ei defnyddio yw aml-ddarllediad. Os dymunwch, gallaf ddweud wrthych yn fanwl pam. Mae hyn yn gwneud bywyd yn llawer haws, oherwydd os yw rhywun wedi delio ag ef ac wedi edrych yn union sut olwg sydd ar yr awyren reoli aml-gast, ym mhob un ond y gosodiadau symlaf, mae hwn yn gur pen mawr. Ac yn fwy na hynny, mae'n anodd dod o hyd i weithrediad ffynhonnell agored sy'n gweithredu'n dda, er enghraifft.
Yn olaf, rydym yn dylunio ein rhwydweithiau fel nad ydynt yn newid gormod. Gallwn ddibynnu ar y ffaith bod llif digwyddiadau allanol yn y system llwybro yn fach.
Pa broblemau sy'n codi a pha gyfyngiadau y mae'n rhaid eu hystyried pan fyddwn yn datblygu rhwydwaith canolfan ddata? Cost, wrth gwrs. Scalability, y lefel yr ydym am dyfu iddi. Yr angen i ehangu heb atal y gwasanaeth. Lled band, argaeledd. Amlygrwydd yr hyn sy'n digwydd ar y rhwydwaith ar gyfer systemau monitro, ar gyfer timau gweithredol. Cefnogaeth awtomeiddio - eto, cymaint â phosib, gan y gellir datrys gwahanol dasgau ar wahanol lefelau, gan gynnwys cyflwyno haenau ychwanegol. Wel, nid [o bosibl] yn ddibynnol ar werthwyr. Er mewn gwahanol gyfnodau hanesyddol, yn dibynnu ar ba adran rydych chi'n edrych arni, roedd yr annibyniaeth hon yn haws neu'n anos i'w chyflawni. Os byddwn yn cymryd trawstoriad o sglodion dyfais rhwydwaith, yna tan yn ddiweddar roedd yn amodol iawn i siarad am annibyniaeth oddi wrth werthwyr, os ydym hefyd eisiau sglodion gyda mewnbwn uchel.
Pa dopoleg resymegol y byddwn yn ei defnyddio i adeiladu ein rhwydwaith? Clos aml-lefel fydd hwn. Mewn gwirionedd, nid oes unrhyw ddewisiadau amgen go iawn ar hyn o bryd. Ac mae topoleg Clos yn eithaf da, hyd yn oed o'i gymharu â thopolegau datblygedig amrywiol sy'n fwy ym maes diddordeb academaidd nawr, os oes gennym ni switshis radix mawr.
Sut mae rhwydwaith Clos aml-lefel wedi'i strwythuro'n fras a beth yw'r gwahanol elfennau a elwir ynddo? Yn gyntaf oll, cododd y gwynt, i gyfeirio'ch hun ble mae'r gogledd, ble mae'r de, lle mae'r dwyrain, ble mae'r gorllewin. Mae rhwydweithiau o'r math hwn fel arfer yn cael eu hadeiladu gan y rhai sydd â thraffig mawr iawn o'r gorllewin-ddwyrain. O ran yr elfennau sy'n weddill, ar y brig mae switsh rhithwir wedi'i ymgynnull o switshis llai. Dyma'r prif syniad o adeiladu rhwydweithiau Clos yn rheolaidd. Rydym yn cymryd elfennau gyda rhyw fath o radix ac yn eu cysylltu fel y gellir ystyried yr hyn a gawn fel switsh gyda radix mwy. Os oes angen mwy fyth arnoch, gellir ailadrodd y weithdrefn.
Mewn achosion, er enghraifft, gyda Clos dwy lefel, pan mae'n bosibl nodi'n glir y cydrannau sy'n fertigol yn fy niagram, fe'u gelwir fel arfer yn awyrennau. Pe baem yn adeiladu Clos gyda thair lefel o switshis meingefn (nad yw pob un ohonynt yn switshis ffin neu ToR ac sy'n cael eu defnyddio ar gyfer cludo yn unig), yna byddai'r awyrennau'n edrych yn fwy cymhleth; mae rhai dwy lefel yn edrych yn union fel hyn. Rydym yn galw bloc o ToR neu switshis dail a'r switshis meingefn lefel gyntaf sy'n gysylltiedig â nhw yn Pod. Mae switshis asgwrn cefn lefel asgwrn cefn-1 ar frig y Pod ar frig Pod, sef top y Pod. Y switshis sydd wedi'u lleoli ar frig y ffatri gyfan yw haen uchaf y ffatri, Top of fabric.
Wrth gwrs, mae'r cwestiwn yn codi: mae rhwydweithiau Clos wedi'u hadeiladu ers peth amser; mae'r syniad ei hun yn gyffredinol yn dod o amseroedd teleffoni clasurol, rhwydweithiau TDM. Efallai bod rhywbeth gwell wedi ymddangos, efallai y gellir gwneud rhywbeth yn well? Ydw a nac ydw. Yn ddamcaniaethol ie, yn ymarferol yn y dyfodol agos yn bendant ddim. Oherwydd bod yna nifer o dopolegau diddorol, mae rhai ohonynt hyd yn oed yn cael eu defnyddio mewn cynhyrchu, er enghraifft, defnyddir Dragonfly mewn cymwysiadau HPC; Mae yna hefyd dopolegau diddorol fel Xpander, FatClique, Jellyfish. Os edrychwch ar adroddiadau mewn cynadleddau fel SIGCOMM neu NSDI yn ddiweddar, gallwch ddod o hyd i nifer eithaf mawr o weithiau ar dopolegau amgen sydd â phriodweddau gwell (un neu'r llall) na Clos.
Ond mae gan yr holl dopolegau hyn un nodwedd ddiddorol. Mae'n atal eu gweithredu mewn rhwydweithiau canolfannau data, yr ydym yn ceisio adeiladu ar galedwedd nwyddau ac sy'n costio arian eithaf rhesymol. Ym mhob un o'r topolegau amgen hyn, yn anffodus nid yw'r rhan fwyaf o'r lled band yn hygyrch ar y llwybrau byrraf. Felly, rydym yn colli'r cyfle ar unwaith i ddefnyddio'r awyren reoli draddodiadol.
Yn ddamcaniaethol, mae'r ateb i'r broblem yn hysbys. Mae'r rhain, er enghraifft, yn addasiadau o gyflwr cyswllt gan ddefnyddio llwybr k-byrraf, ond, unwaith eto, nid oes unrhyw brotocolau o'r fath a fyddai'n cael eu gweithredu wrth gynhyrchu ac ar gael yn eang ar offer.
Ar ben hynny, gan nad yw'r rhan fwyaf o'r capasiti yn hygyrch trwy'r llwybrau byrraf, mae angen i ni addasu mwy na dim ond yr awyren reoli i ddewis pob un o'r llwybrau hynny (a gyda llaw, mae hyn yn llawer mwy cyflwr yn yr awyren reoli). Mae angen inni addasu'r awyren anfon ymlaen o hyd, ac, fel rheol, mae angen o leiaf ddwy nodwedd ychwanegol. Dyma'r gallu i wneud pob penderfyniad am anfon pecynnau ymlaen un-amser, er enghraifft, ar y gwesteiwr. Mewn gwirionedd, llwybro ffynhonnell yw hwn, weithiau yn y llenyddiaeth ar rwydweithiau rhyng-gysylltiad gelwir hyn yn benderfyniadau anfon ymlaen i gyd-ar-unwaith. Ac mae llwybro addasol yn swyddogaeth sydd ei hangen arnom ar elfennau rhwydwaith, sy'n berwi, er enghraifft, i'r ffaith ein bod yn dewis yr hop nesaf yn seiliedig ar wybodaeth am y llwyth lleiaf ar y ciw. Er enghraifft, mae opsiynau eraill yn bosibl.
Felly, mae'r cyfeiriad yn ddiddorol, ond, gwaetha'r modd, ni allwn ei gymhwyso ar hyn o bryd.
Iawn, fe wnaethom setlo ar dopoleg resymegol Clos. Sut byddwn ni'n ei raddio? Gawn ni weld sut mae'n gweithio a beth ellir ei wneud.
Mewn rhwydwaith Clos mae dau brif baramedr y gallwn rywsut eu hamrywio a chael canlyniadau penodol: radix yr elfennau a nifer y lefelau yn y rhwydwaith. Mae gen i ddiagram sgematig o sut mae'r ddau yn effeithio ar y maint. Yn ddelfrydol, rydym yn cyfuno'r ddau.
Gellir gweld bod lled terfynol rhwydwaith Clos yn gynnyrch pob lefel o switshis asgwrn cefn y radix deheuol, faint o gysylltiadau sydd gennym i lawr, sut mae'n canghennau. Dyma sut rydym yn graddio maint y rhwydwaith.
O ran capasiti, yn enwedig ar switshis ToR, mae dau opsiwn graddio. Naill ai gallwn, wrth gynnal y topoleg gyffredinol, ddefnyddio cysylltiadau cyflymach, neu gallwn ychwanegu mwy o awyrennau.
Os edrychwch ar y fersiwn estynedig o rwydwaith Clos (yn y gornel dde isaf) a dychwelyd i'r llun hwn gyda rhwydwaith Clos isod...
... yna mae hyn yn union yr un topoleg, ond ar y sleid hon mae'n cwympo'n fwy cryno ac mae awyrennau'r ffatri wedi'u harosod ar ei gilydd. Yr un ydyw.
Sut olwg sydd ar raddio rhwydwaith Clos mewn niferoedd? Yma rwy'n darparu data ar ba led uchaf y gellir ei gael rhwydwaith, pa nifer uchaf o raciau, switshis ToR neu switshis dail, os nad ydynt mewn raciau, gallwn eu cael yn dibynnu ar ba radix o switshis a ddefnyddiwn ar gyfer meingefn -levels, a faint o lefelau rydyn ni'n eu defnyddio.
Dyma faint o raciau y gallwn eu cael, faint o weinyddion a thua faint y gall hyn i gyd ei fwyta yn seiliedig ar 20 kW fesul rac. Ychydig yn gynharach soniais ein bod yn anelu at glwstwr o tua 100 mil o weinyddion.
Gellir gweld bod dau opsiwn a hanner o ddiddordeb yn y dyluniad cyfan hwn. Mae yna opsiwn gyda dwy haen o asgwrn cefn a switshis 64-porthladd, sy'n disgyn ychydig yn fyr. Yna mae opsiynau cwbl addas ar gyfer switshis asgwrn cefn 128-port (gyda radix 128) gyda dwy lefel, neu switshis gyda radix 32 gyda thair lefel. Ac ym mhob achos, lle mae mwy o radixau a mwy o haenau, gallwch chi wneud rhwydwaith mawr iawn, ond os edrychwch ar y defnydd disgwyliedig, yn nodweddiadol mae gigawat. Mae’n bosibl gosod cebl, ond rydym yn annhebygol o gael cymaint â hynny o drydan mewn un safle. Os edrychwch ar ystadegau a data cyhoeddus ar ganolfannau data, ychydig iawn o ganolfannau data sydd â chapasiti amcangyfrifedig o fwy na 150 MW. Mae'r rhai mwy fel arfer yn gampysau canolfannau data, sawl canolfan ddata fawr wedi'u lleoli'n eithaf agos at ei gilydd.
Mae yna baramedr pwysig arall. Os edrychwch ar y golofn chwith, rhestrir lled band defnyddiadwy yno. Mae'n hawdd gweld bod rhan sylweddol o'r porthladdoedd yn cael eu defnyddio mewn rhwydwaith Clos i gysylltu switshis â'i gilydd. Mae lled band defnyddiadwy, stribed defnyddiol, yn rhywbeth y gellir ei roi y tu allan, tuag at y gweinyddwyr. Yn naturiol, dwi'n sôn am borthladdoedd amodol ac yn benodol am y band. Fel rheol, mae cysylltiadau o fewn y rhwydwaith yn gyflymach na chysylltiadau â gweinyddwyr, ond fesul uned o led band, cymaint ag y gallwn ei anfon at ein hoffer gweinydd, mae rhywfaint o led band o fewn y rhwydwaith ei hun o hyd. A pho fwyaf o lefelau a wnawn, y mwyaf yw'r gost benodol o ddarparu'r streipen hon i'r tu allan.
Ar ben hynny, nid yw hyd yn oed y band ychwanegol hwn yn union yr un peth. Er bod y rhychwantau'n fyr, gallwn ddefnyddio rhywbeth fel DAC (copr atodi'n uniongyrchol, hynny yw, ceblau twinax), neu opteg amlfodd, sy'n costio hyd yn oed mwy neu lai o arian rhesymol. Cyn gynted ag y byddwn yn symud i rhychwantau hirach - fel rheol, mae'r rhain yn opteg modd sengl, ac mae cost y lled band ychwanegol hwn yn cynyddu'n amlwg.
Ac eto, gan ddychwelyd i'r sleid flaenorol, os ydym yn creu rhwydwaith Clos heb ordanysgrifio, yna mae'n hawdd edrych ar y diagram, gweld sut mae'r rhwydwaith wedi'i adeiladu - gan ychwanegu pob lefel o switshis asgwrn cefn, rydym yn ailadrodd y stribed cyfan a oedd yn y gwaelod. Lefel plws - ynghyd â'r un band, yr un nifer o borthladdoedd ar switshis ag a oedd ar y lefel flaenorol, a'r un nifer o drosglwyddyddion. Felly, mae'n ddymunol iawn lleihau nifer y lefelau o switshis asgwrn cefn.
Yn seiliedig ar y llun hwn, mae'n amlwg ein bod wir eisiau adeiladu ar rywbeth fel switshis gyda radix o 128.
Yma, mewn egwyddor, mae popeth yr un peth â'r hyn yr wyf newydd ei ddweud; dyma sleid i'w ystyried yn nes ymlaen.
Pa opsiynau sydd ar gael y gallwn eu dewis fel switshis o'r fath? Mae'n newyddion dymunol iawn i ni y gellir adeiladu rhwydweithiau o'r fath o'r diwedd ar switshis un sglodyn. Ac mae hyn yn cŵl iawn, mae ganddyn nhw lawer o nodweddion braf. Er enghraifft, nid oes ganddynt bron unrhyw strwythur mewnol. Mae hyn yn golygu eu bod yn torri'n haws. Maent yn torri mewn pob math o ffyrdd, ond yn ffodus maent yn torri'n llwyr. Mewn dyfeisiau modiwlaidd mae yna nifer fawr o ddiffygion (annifyr iawn), pan mae'n ymddangos ei fod yn gweithio o safbwynt cymdogion a'r awyren reoli, ond, er enghraifft, mae rhan o'r ffabrig wedi'i golli ac nid yw'n gweithio. yn llawn. Ac mae'r traffig iddo yn gytbwys yn seiliedig ar y ffaith ei fod yn gwbl weithredol, a gallwn gael ein gorlwytho.
Neu, er enghraifft, mae problemau'n codi gyda'r backplane, oherwydd y tu mewn i'r ddyfais fodiwlaidd mae SerDes cyflym hefyd - mae'n wirioneddol gymhleth y tu mewn. Naill ai mae'r arwyddion rhwng elfennau anfon ymlaen yn cael eu cydamseru neu heb eu cydamseru. Yn gyffredinol, mae unrhyw ddyfais modiwlaidd cynhyrchiol sy'n cynnwys nifer fawr o elfennau, fel rheol, yn cynnwys yr un rhwydwaith Clos y tu mewn iddo'i hun, ond mae'n anodd iawn gwneud diagnosis. Yn aml mae'n anodd i'r gwerthwr ei hun wneud diagnosis.
Ac mae ganddo nifer fawr o senarios methiant lle mae'r ddyfais yn diraddio, ond nid yw'n disgyn allan o'r topoleg yn llwyr. Gan fod ein rhwydwaith yn fawr, mae cydbwyso rhwng elfennau union yr un fath yn cael ei ddefnyddio'n weithredol, mae'r rhwydwaith yn rheolaidd iawn, hynny yw, nid yw un llwybr y mae popeth mewn trefn arno yn wahanol i'r llwybr arall, mae'n fwy proffidiol i ni golli rhywfaint o y dyfeisiau o'r topoleg nag i ddiweddu mewn sefyllfa lle mae rhai ohonynt yn ymddangos i weithio, ond nid yw rhai ohonynt.
Nodwedd braf nesaf dyfeisiau un sglodyn yw eu bod yn esblygu'n well ac yn gyflymach. Maent hefyd yn dueddol o fod â gallu gwell. Os cymerwn y strwythurau cydosod mawr sydd gennym ar gylch, yna mae'r gallu fesul uned rac ar gyfer porthladdoedd o'r un cyflymder bron ddwywaith cystal ag un dyfeisiau modiwlaidd. Mae dyfeisiau sydd wedi'u hadeiladu o amgylch un sglodyn yn amlwg yn rhatach na rhai modiwlaidd ac yn defnyddio llai o ynni.
Ond, wrth gwrs, mae hyn i gyd am reswm, mae yna anfanteision hefyd. Yn gyntaf, mae'r radix bron bob amser yn llai na radix dyfeisiau modiwlaidd. Os gallwn gael dyfais wedi'i hadeiladu o amgylch un sglodyn gyda 128 o borthladdoedd, yna gallwn gael un modiwlaidd gyda rhai cannoedd o borthladdoedd nawr heb unrhyw broblemau.
Mae hwn yn faint amlwg llai o dablau anfon ymlaen ac, fel rheol, popeth sy'n ymwneud â graddadwyedd awyrennau data. Byfferau bas. Ac, fel rheol, ymarferoldeb braidd yn gyfyngedig. Ond mae'n ymddangos, os ydych chi'n gwybod y cyfyngiadau hyn ac yn cymryd gofal mewn pryd i'w hosgoi neu eu cymryd i ystyriaeth, yna nid yw hyn mor frawychus. Nid yw'r ffaith bod y radix yn llai bellach yn broblem ar ddyfeisiau â radix o 128 sydd wedi ymddangos o'r diwedd yn ddiweddar; gallwn adeiladu dwy haen o asgwrn cefn. Ond mae'n dal yn amhosibl adeiladu unrhyw beth llai na dau sy'n ddiddorol i ni. Gydag un lefel, ceir clystyrau bach iawn. Roedd hyd yn oed ein dyluniadau a'n gofynion blaenorol yn dal i ragori arnynt.
Mewn gwirionedd, os yn sydyn mae'r ateb yn rhywle ar fin, mae yna ffordd i raddfa o hyd. Gan mai'r lefel olaf (neu gyntaf), isaf lle mae gweinyddwyr wedi'u cysylltu yw switshis ToR neu switshis dail, nid yw'n ofynnol i ni gysylltu un rac â nhw. Felly, os yw'r datrysiad yn brin o tua hanner, gallwch chi feddwl am ddefnyddio switsh gyda radix mawr ar y lefel is yn unig a chysylltu, er enghraifft, dau neu dri rac i mewn i un switsh. Mae hwn hefyd yn opsiwn, mae ganddo ei gostau, ond mae'n gweithio'n eithaf da a gall fod yn ateb da pan fydd angen i chi gyrraedd tua dwywaith y maint.
I grynhoi, rydym yn adeiladu ar dopoleg gyda dwy lefel o asgwrn cefn, gydag wyth haen ffatri.
Beth fydd yn digwydd i ffiseg? Cyfrifiadau syml iawn. Os oes gennym ddwy lefel o bigau, yna dim ond tair lefel o switshis sydd gennym, a disgwyliwn y bydd tair segment cebl yn y rhwydwaith: o weinyddion i switshis dail, i asgwrn cefn 1, i asgwrn cefn 2. Yr opsiynau y gallwn defnydd yw - mae'r rhain yn twinax, amlfodd, modd sengl. Ac yma mae angen inni ystyried pa stribed sydd ar gael, faint y bydd yn ei gostio, beth yw'r dimensiynau ffisegol, pa rhychwantau y gallwn eu cwmpasu, a sut y byddwn yn uwchraddio.
O ran cost, gellir trefnu popeth. Mae twinaxes gryn dipyn yn rhatach nag opteg weithredol, yn rhatach na throsglwyddyddion amlfodd, os cymerwch ef fesul hediad o'r diwedd, ychydig yn rhatach na phorthladd switsh 100-gigabit. A, nodwch, mae'n costio llai nag opteg modd sengl, oherwydd ar deithiau hedfan lle mae angen modd sengl, mewn canolfannau data am nifer o resymau mae'n gwneud synnwyr i ddefnyddio CWDM, tra nad yw modd sengl cyfochrog (PSM) yn gyfleus iawn i weithio gyda, pecynnau mawr iawn yn cael eu sicrhau ffibrau, ac os ydym yn canolbwyntio ar y technolegau hyn, rydym yn cael tua'r hierarchaeth prisiau canlynol.
Un nodyn arall: yn anffodus, nid yw'n bosibl iawn defnyddio porthladdoedd amlfodd 100 i 4x25 wedi'u dadosod. Oherwydd nodweddion dylunio transceivers SFP28, nid yw'n llawer rhatach na 28 Gbit QSFP100. Ac nid yw'r dadosod hwn ar gyfer amlfodd yn gweithio'n dda iawn.
Cyfyngiad arall yw oherwydd maint y clystyrau cyfrifiadurol a nifer y gweinyddwyr, mae ein canolfannau data yn troi allan i fod yn gorfforol fawr. Mae hyn yn golygu y bydd yn rhaid gwneud o leiaf un hediad gyda mod sengl. Unwaith eto, oherwydd maint ffisegol y Podiau, ni fydd yn bosibl rhedeg dau rychwant o twinax (ceblau copr).
O ganlyniad, os ydym yn optimeiddio am bris ac yn ystyried geometreg y dyluniad hwn, rydym yn cael un rhychwant o twinax, un rhychwant o amlfodd ac un rhychwant o singlemode gan ddefnyddio CWDM. Mae hyn yn cymryd i ystyriaeth y posibilrwydd o uwchraddio llwybrau.
Dyma sut mae'n edrych yn ddiweddar, i ble rydyn ni'n mynd a beth sy'n bosibl. Mae'n amlwg, o leiaf, sut i symud tuag at 50-Gigabit SerDes ar gyfer amlfodd a singlemode. Ar ben hynny, os edrychwch ar yr hyn sydd mewn trosglwyddyddion un modd nawr ac yn y dyfodol ar gyfer 400G, yn aml hyd yn oed pan fydd 50G SerDes yn cyrraedd o'r ochr drydanol, gall 100 Gbps y lôn fynd i opteg eisoes. Felly, mae'n eithaf posibl, yn lle symud i 50, y bydd trosglwyddiad i 100 Gigabit SerDes a 100 Gbps y lôn, oherwydd yn ôl addewidion llawer o werthwyr, disgwylir eu hargaeledd yn eithaf buan. Mae'n ymddangos na fydd y cyfnod pan oedd 50G SerDes y cyflymaf, mae'n ymddangos, yn hir iawn, oherwydd mae'r copïau cyntaf o 100G SerDes yn cael eu cyflwyno bron y flwyddyn nesaf. Ac ymhen peth amser ar ôl hynny mae'n debyg y byddan nhw'n werth arian rhesymol.
Un naws arall am y dewis o ffiseg. Mewn egwyddor, gallwn eisoes ddefnyddio 400 neu 200 o borthladdoedd Gigabit gan ddefnyddio 50G SerDes. Ond mae'n troi allan nad yw hyn yn gwneud llawer o synnwyr, oherwydd, fel y dywedais yn gynharach, rydym am gael radix eithaf mawr ar y switshis, o fewn rheswm, wrth gwrs. Rydyn ni eisiau 128. Ac os oes gennym ni gapasiti sglodion cyfyngedig ac rydyn ni'n cynyddu'r cyflymder cyswllt, yna mae'r radix yn lleihau'n naturiol, nid oes unrhyw wyrthiau.
A gallwn gynyddu cyfanswm y capasiti gan ddefnyddio awyrennau, ac nid oes unrhyw gostau arbennig; gallwn ychwanegu nifer yr awyrennau. Ac os byddwn yn colli'r radix, bydd yn rhaid i ni gyflwyno lefel ychwanegol, felly yn y sefyllfa bresennol, gyda'r uchafswm presennol o gapasiti sydd ar gael fesul sglodion, mae'n troi allan ei bod yn fwy effeithlon defnyddio porthladdoedd 100-gigabit, oherwydd eu bod yn caniatáu ichi i gael radix mwy.
Y cwestiwn nesaf yw sut mae ffiseg yn cael ei drefnu, ond o safbwynt seilwaith cebl. Mae'n ymddangos ei fod wedi'i drefnu mewn ffordd eithaf doniol. Ceblau rhwng switshis dail a pigau lefel gyntaf - nid oes llawer o gysylltiadau yno, mae popeth wedi'i adeiladu'n gymharol syml. Ond os cymerwn un awyren, yr hyn sy'n digwydd y tu mewn yw bod angen i ni gysylltu holl asgwrn cefn y lefel gyntaf â holl asgwrn cefn yr ail lefel.
Hefyd, fel rheol, mae rhai dymuniadau ar gyfer sut y dylai edrych y tu mewn i'r ganolfan ddata. Er enghraifft, roeddem wir eisiau cyfuno ceblau i mewn i fwndel a'u tynnu fel bod un panel patsh dwysedd uchel yn mynd yn gyfan gwbl i mewn i un panel clwt, fel nad oedd unrhyw sw o ran hyd. Llwyddom i ddatrys y broblem hon. Os edrychwch i ddechrau ar y topoleg resymegol, gallwch weld bod yr awyrennau'n annibynnol, gellir adeiladu pob awyren ar ei phen ei hun. Ond pan fyddwn yn ychwanegu bwndel o'r fath ac eisiau llusgo'r panel clwt cyfan i mewn i banel patch, mae'n rhaid i ni gymysgu gwahanol awyrennau y tu mewn i un bwndel a chyflwyno strwythur canolradd ar ffurf croes-gysylltiadau optegol i'w hail-bacio o'r ffordd y cawsant eu cydosod. ar un segment , yn y modd y byddant yn cael eu casglu ar segment arall . Diolch i hyn, rydyn ni'n cael nodwedd braf: nid yw'r holl newid cymhleth yn mynd y tu hwnt i'r raciau. Pan fydd angen i chi gydblethu rhywbeth yn gryf iawn, “datguddio'r awyrennau,” fel y'i gelwir weithiau yn rhwydweithiau Clos, mae'r cyfan wedi'i grynhoi y tu mewn i un rac. Nid ydym wedi dadosod iawn, i lawr i gysylltiadau unigol, newid rhwng raciau.
Dyma sut mae'n edrych o safbwynt trefniadaeth resymegol y seilwaith cebl. Yn y llun ar y chwith, mae'r blociau aml-liw yn darlunio blociau o switshis meingefn lefel gyntaf, wyth darn yr un, a phedwar bwndel o geblau yn dod ohonynt, sy'n mynd ac yn croestorri â'r bwndeli sy'n dod o'r blociau o switshis meingefn-2. .
Mae sgwariau bach yn dynodi croestoriadau. Ar y chwith uchaf mae dadansoddiad o bob croestoriad o'r fath, mewn gwirionedd mae hwn yn fodiwl croes-gysylltu porthladd 512 wrth 512 sy'n ailbacio'r ceblau fel eu bod yn dod yn gyfan gwbl i mewn i un rac, lle nad oes ond un awyren asgwrn cefn-2. Ac ar y dde, mae sgan o'r llun hwn ychydig yn fwy manwl mewn perthynas â sawl Pod ar lefel asgwrn cefn-1, a sut mae'n cael ei becynnu mewn croes-gysylltu, sut mae'n dod i lefel asgwrn cefn-2.
Dyma sut mae'n edrych. Y stand meingefn-2 nad yw eto wedi'i ymgynnull yn llawn (ar y chwith) a'r stand croesgysylltu. Yn anffodus, nid oes llawer i'w weld yno. Mae'r strwythur cyfan hwn yn cael ei ddefnyddio ar hyn o bryd yn un o'n canolfannau data mawr sy'n cael ei ehangu. Mae hwn yn waith ar y gweill, bydd yn edrych yn brafiach, bydd yn cael ei lenwi'n well.
Cwestiwn pwysig: fe wnaethom ddewis y topoleg resymegol ac adeiladu'r ffiseg. Beth fydd yn digwydd i'r awyren reoli? Mae'n eithaf adnabyddus o brofiad gweithredu, mae yna nifer o adroddiadau bod protocolau cyflwr cyswllt yn dda, mae'n bleser gweithio gyda nhw, ond, yn anffodus, nid ydynt yn graddio'n dda ar dopoleg gysylltiedig ddwys. Ac mae un prif ffactor sy'n atal hyn - dyma sut mae llifogydd yn gweithio mewn protocolau cyflwr cyswllt. Os cymerwch yr algorithm llifogydd ac edrych ar sut mae ein rhwydwaith wedi'i strwythuro, gallwch weld y bydd gwyntyll mawr iawn ar bob cam, a bydd yn gorlifo'r awyren reoli gyda diweddariadau. Yn benodol, mae topolegau o'r fath yn cymysgu'n wael iawn â'r algorithm llifogydd traddodiadol mewn protocolau cyflwr cyswllt.
Y dewis yw defnyddio BGP. Disgrifir sut i'w baratoi'n gywir yn RFC 7938 am y defnydd o BGP mewn canolfannau data mawr. Mae'r syniadau sylfaenol yn syml: lleiafswm nifer y rhagddodiaid fesul gwesteiwr ac yn gyffredinol lleiafswm nifer y rhagddodiaid ar y rhwydwaith, defnyddio agregu os yn bosibl, ac atal hela llwybrau. Rydym eisiau dosbarthiad gofalus iawn, rheoledig iawn o ddiweddariadau, yr hyn a elwir yn valley free. Rydym am i ddiweddariadau gael eu rhoi ar waith yn union unwaith wrth iddynt fynd drwy'r rhwydwaith. Os ydynt yn tarddu yn y gwaelod, maent yn mynd i fyny, heb eu plygu mwy nag unwaith. Ni ddylai fod unrhyw igam-ogam. Mae igam ogam yn ddrwg iawn.
I wneud hyn, rydym yn defnyddio dyluniad sy'n ddigon syml i ddefnyddio'r mecanweithiau BGP sylfaenol. Hynny yw, rydym yn defnyddio eBGP yn rhedeg ar ddolen leol, ac mae systemau ymreolaethol yn cael eu neilltuo fel a ganlyn: system ymreolaethol ar ToR, system ymreolaethol ar y bloc cyfan o switshis meingefn-1 o un Pod, a system ymreolaethol gyffredinol ar y Top cyfan o Ffabrig. Nid yw'n anodd edrych a gweld bod hyd yn oed ymddygiad arferol BGP yn rhoi'r dosbarthiad diweddariadau yr ydym ei eisiau i ni.
Yn naturiol, mae'n rhaid dylunio cyfeiriadau a chyfeirio cyfeiriadau fel ei fod yn gydnaws â'r ffordd y caiff llwybro ei adeiladu, fel ei fod yn sicrhau sefydlogrwydd yr awyren reoli. Mae cyfeiriadau L3 mewn trafnidiaeth yn gysylltiedig â’r dopoleg, oherwydd heb hyn mae’n amhosibl cyflawni agregu; heb hyn, bydd cyfeiriadau unigol yn ymledu i’r system lwybro. Ac un peth arall yw nad yw agregu, yn anffodus, yn cymysgu'n dda iawn ag aml-lwybr, oherwydd pan fydd gennym ni aml-lwybr ac mae gennym ni agregu, mae popeth yn iawn, pan fydd y rhwydwaith cyfan yn iach, nid oes unrhyw fethiannau ynddo. Yn anffodus, cyn gynted ag y bydd methiannau’n ymddangos yn y rhwydwaith a chymesuredd y dopoleg yn cael ei golli, gallwn ddod at y pwynt y cyhoeddwyd yr uned ohono, ac ni allwn fynd ymhellach oddi yno i’r man lle mae angen inni fynd. Felly, mae'n well agregu lle nad oes mwy o aml-lwybr, yn ein hachos ni switshis ToR yw'r rhain.
Mewn gwirionedd, mae'n bosibl agregu, ond yn ofalus. Os gallwn wneud dadgyfuno rheoledig pan fydd methiannau rhwydwaith yn digwydd. Ond mae hon yn dasg eithaf anodd, roeddem hyd yn oed yn meddwl tybed a fyddai'n bosibl gwneud hyn, a oedd yn bosibl ychwanegu awtomeiddio ychwanegol, a pheiriannau cyflwr cyfyngedig a fyddai'n cicio BGP yn gywir i gael yr ymddygiad a ddymunir. Yn anffodus, nid yw prosesu achosion cornel yn amlwg ac yn gymhleth iawn, ac nid yw'r dasg hon yn cael ei datrys yn dda trwy atodi atodiadau allanol i BGP.
Mae gwaith diddorol iawn yn hyn o beth wedi’i wneud o fewn fframwaith y protocol RIFT, a fydd yn cael ei drafod yn yr adroddiad nesaf.
Peth pwysig arall yw sut mae awyrennau data yn graddio mewn topolegau trwchus, lle mae gennym ni nifer fawr o lwybrau amgen. Yn yr achos hwn, defnyddir sawl strwythur data ychwanegol: grwpiau ECMP, sydd yn eu tro yn disgrifio grwpiau Next Hop.
Mewn rhwydwaith sy'n gweithio fel arfer, heb fethiannau, pan fyddwn yn mynd i fyny topoleg Clos, mae'n ddigon i ddefnyddio un grŵp yn unig, oherwydd disgrifir popeth nad yw'n lleol yn ddiofyn, gallwn fynd i fyny. Pan awn ni o'r top i'r gwaelod i'r de, yna nid yw pob llwybr yn ECMP, maen nhw'n llwybrau un llwybr. Mae popeth yn iawn. Y drafferth yw, a hynodrwydd topoleg glasurol Clos yw, os edrychwn ar y Top of fabric, ar unrhyw elfen, dim ond un llwybr sydd i unrhyw elfen isod. Os bydd methiannau'n digwydd ar hyd y llwybr hwn, yna mae'r elfen benodol hon ar frig y ffatri yn dod yn annilys yn union ar gyfer y rhagddodiaid hynny sydd y tu ôl i'r llwybr toredig. Ond ar gyfer y gweddill mae'n ddilys, ac mae'n rhaid i ni ddosrannu'r grwpiau ECMP a chyflwyno gwladwriaeth newydd.
Sut olwg sydd ar scalability awyrennau data ar ddyfeisiau modern? Os gwnawn LPM (cyfatebiad rhagddodiad hiraf), mae popeth yn eithaf da, dros 100k o rhagddodiaid. Os ydym yn sôn am grwpiau Next Hop, yna mae popeth yn waeth, 2-4 mil. Os ydym yn sôn am dabl sy'n cynnwys disgrifiad o Next Hops (neu gymariaethau), yna mae hyn rhywle o 16k i 64k. A gall hyn ddod yn broblem. A dyma ni'n dod at wyriad diddorol: beth ddigwyddodd i MPLS mewn canolfannau data? Mewn egwyddor, roeddem am ei wneud.
Digwyddodd dau beth. Gwnaethom ficro-segmentu ar y gwesteiwyr; nid oedd angen i ni ei wneud ar y rhwydwaith mwyach. Nid oedd yn dda iawn gyda chefnogaeth gan wahanol werthwyr, a hyd yn oed yn fwy felly gyda gweithrediadau agored ar flychau gwyn gyda MPLS. Ac mae MPLS, o leiaf ei weithrediadau traddodiadol, yn anffodus, yn cyfuno'n wael iawn ag ECMP. A dyna pam.
Dyma sut olwg sydd ar strwythur anfon ymlaen ECMP ar gyfer IP. Gall nifer fawr o rhagddodiaid ddefnyddio'r un grŵp a'r un bloc Next Hops (neu gymariaethau, gellir galw hyn yn wahanol mewn gwahanol ddogfennaeth ar gyfer dyfeisiau gwahanol). Y pwynt yw bod hwn yn cael ei ddisgrifio fel y porthladd sy'n mynd allan a beth i ailysgrifennu'r cyfeiriad MAC iddo er mwyn cyrraedd y Next Hop cywir. Ar gyfer IP mae popeth yn edrych yn syml, gallwch ddefnyddio nifer fawr iawn o rhagddodiaid ar gyfer yr un grŵp, yr un bloc Next Hops.
Mae pensaernïaeth glasurol MPLS yn awgrymu, yn dibynnu ar y rhyngwyneb sy'n mynd allan, y gellir ailysgrifennu'r label i wahanol werthoedd. Felly, mae angen inni gadw grŵp a bloc Next Hops ar gyfer pob label mewnbwn. Ac nid yw hyn, gwaetha'r modd, yn graddio.
Mae'n hawdd gweld bod angen tua 4000 o switshis ToR yn ein dyluniad, y lled uchaf oedd 64 llwybr ECMP, os symudwn i ffwrdd o asgwrn cefn-1 tuag at asgwrn cefn-2. Prin y byddwn yn mynd i mewn i un tabl o grwpiau ECMP, os mai dim ond un rhagddodiad gyda ToR sy'n mynd i ffwrdd, ac nad ydym yn mynd i mewn i'r tabl Next Hops o gwbl.
Nid yw'r cyfan yn anobeithiol, oherwydd mae pensaernïaeth fel Segment Routing yn cynnwys labeli byd-eang. Yn ffurfiol, byddai'n bosibl cwympo'r holl flociau Next Hops hyn eto. I wneud hyn, mae angen gweithrediad cerdyn gwyllt arnoch chi: cymerwch label a'i ailysgrifennu i'r un un heb werth penodol. Ond yn anffodus, nid yw hyn yn bresennol iawn yn y gweithrediadau sydd ar gael.
Ac yn olaf, mae angen inni ddod â thraffig allanol i'r ganolfan ddata. Sut i'w wneud? Yn flaenorol, cyflwynwyd traffig i rwydwaith Clos oddi uchod. Hynny yw, roedd llwybryddion ymyl sy'n cysylltu â holl ddyfeisiau ar y Top o ffabrig. Mae'r datrysiad hwn yn gweithio'n eithaf da ar feintiau bach i ganolig. Yn anffodus, er mwyn anfon traffig yn gymesur i'r rhwydwaith cyfan yn y modd hwn, mae angen inni gyrraedd yr holl elfennau Top of fabric ar yr un pryd, a phan fo mwy na chant ohonynt, mae'n ymddangos bod angen radix mawr arnom hefyd. y llwybryddion ymyl. Yn gyffredinol, mae hyn yn costio arian, oherwydd bod llwybryddion ymyl yn fwy swyddogaethol, bydd y porthladdoedd arnynt yn ddrutach, ac nid yw'r dyluniad yn brydferth iawn.
Opsiwn arall yw cychwyn traffig o'r fath oddi isod. Mae'n hawdd gwirio bod topoleg Clos wedi'i hadeiladu yn y fath fodd fel bod traffig sy'n dod oddi isod, hynny yw, o'r ochr ToR, wedi'i ddosbarthu'n gyfartal rhwng y lefelau ledled y Top of fabric cyfan mewn dau iteriad, gan lwytho'r rhwydwaith cyfan. Felly, rydym yn cyflwyno math arbennig o Pod, Edge Pod, sy'n darparu cysylltedd allanol.
Mae un opsiwn arall. Dyma beth mae Facebook yn ei wneud, er enghraifft. Maent yn ei alw'n Fabric Aggregator neu HGRID. Mae lefel asgwrn cefn ychwanegol yn cael ei chyflwyno i gysylltu canolfannau data lluosog. Mae'r dyluniad hwn yn bosibl os nad oes gennym swyddogaethau ychwanegol neu newidiadau mewngapsiwleiddio yn y rhyngwynebau. Os ydynt yn bwyntiau cyffwrdd ychwanegol, mae'n anodd. Yn nodweddiadol, mae mwy o swyddogaethau a math o bilen yn gwahanu gwahanol rannau o'r ganolfan ddata. Nid oes unrhyw ddiben gwneud pilen o'r fath yn fawr, ond os oes ei hangen mewn gwirionedd am ryw reswm, yna mae'n gwneud synnwyr ystyried y posibilrwydd o'i thynnu, gan ei gwneud mor eang â phosibl a'i throsglwyddo i'r gwesteiwyr. Gwneir hyn, er enghraifft, gan lawer o weithredwyr cwmwl. Mae ganddyn nhw droshaenau, maen nhw'n dechrau o'r gwesteiwyr.
Pa gyfleoedd datblygu a welwn? Yn gyntaf oll, gwella cefnogaeth ar gyfer y biblinell CI/CD. Rydyn ni eisiau hedfan y ffordd rydyn ni'n ei brofi a phrofi'r ffordd rydyn ni'n hedfan. Nid yw hyn yn gweithio'n dda iawn, oherwydd mae'r seilwaith yn fawr ac mae'n amhosibl ei ddyblygu ar gyfer profion. Mae angen i chi ddeall sut i gyflwyno elfennau profi i'r seilwaith cynhyrchu heb ei ollwng.
Nid yw gwell offeryniaeth a gwell monitro bron byth yn ddiangen. Mae'r cwestiwn cyfan yn gydbwysedd o ymdrech a dychweliad. Os gallwch chi ei ychwanegu gydag ymdrech resymol, da iawn.
Systemau gweithredu agored ar gyfer dyfeisiau rhwydwaith. Protocolau gwell a gwell systemau llwybro, fel RIFT. Mae angen ymchwil hefyd i ddefnyddio gwell cynlluniau rheoli tagfeydd ac efallai cyflwyno, o leiaf ar rai adegau, cymorth RDMA o fewn y clwstwr.
Wrth edrych ymhellach i'r dyfodol, mae arnom angen topolegau datblygedig ac o bosibl rhwydweithiau sy'n defnyddio llai o orbenion. O'r pethau ffres, bu cyhoeddiadau yn ddiweddar am y dechnoleg ffabrig ar gyfer HPC Cray Slingshot, sy'n seiliedig ar Ethernet nwyddau, ond gyda'r opsiwn o ddefnyddio penawdau llawer byrrach. O ganlyniad, mae gorbenion yn cael eu lleihau.
Dylid cadw popeth mor syml â phosibl, ond nid yn symlach. Cymhlethdod yw gelyn scalability. Symlrwydd a strwythurau rheolaidd yw ein ffrindiau. Os gallwch chi wneud raddfa yn rhywle, gwnewch hynny. Ac yn gyffredinol, mae'n wych bod yn rhan o dechnolegau rhwydwaith nawr. Mae llawer o bethau diddorol yn digwydd. Diolch.
Ffynhonnell: hab.com