Moderne datasentrums het honderde aktiewe toestelle geïnstalleer, gedek deur verskillende tipes monitering. Maar selfs 'n ideale ingenieur met perfekte monitering in die hand sal binne 'n paar minute korrek op 'n netwerkfout kan reageer. In 'n verslag by die Next Hop 2020-konferensie het ek 'n DC-netwerkontwerpmetodologie aangebied, wat 'n unieke kenmerk het - die datasentrum genees homself in millisekondes. Meer presies, die ingenieur los die probleem rustig op, terwyl die dienste dit eenvoudig nie agterkom nie.
Vir baie netwerkingenieurs begin 'n datasentrumnetwerk natuurlik met ToR, met 'n skakelaar in die rek. ToR het gewoonlik twee tipes skakels. Die kleintjies gaan na die bedieners, ander - daar is N keer meer van hulle - gaan na die stekels van die eerste vlak, dit wil sê na sy opskakels. Opskakels word gewoonlik as gelyk beskou, en verkeer tussen opskakels word gebalanseer op grond van 'n hash van 5-tuple, wat proto, src_ip, dst_ip, src_port, dst_port insluit. Geen verrassings hier nie.
Vervolgens, hoe lyk die plan-argitektuur? Stekels van die eerste vlak is nie aan mekaar verbind nie, maar word deur superstekels verbind. Die letter X sal verantwoordelik wees vir superspines; dit is amper soos 'n kruisverbinding.
En dit is duidelik dat, aan die ander kant, tori gekoppel is aan alle stekels van die eerste vlak. Wat is belangrik in hierdie prentjie? As ons interaksie binne die rek het, dan gaan die interaksie natuurlik deur ToR. As die interaksie binne die module plaasvind, vind die interaksie plaas deur die eerste vlak ruggraat. As die interaksie intermodulêr is - soos hier, ToR 1 en ToR 2 - dan sal die interaksie deur stekels van beide die eerste en tweede vlak gaan.
In teorie is so 'n argitektuur maklik skaalbaar. As ons hawekapasiteit, spaarspasie in die datasentrum en voorafgelegde vesel het, kan die aantal bane altyd vermeerder word en sodoende die algehele kapasiteit van die stelsel verhoog. Dit is baie maklik om op papier te doen. Dit sou in die lewe so wees. Maar vandag se storie gaan nie daaroor nie.
Ek wil hê dat die regte gevolgtrekkings gemaak moet word. Ons het baie paaie binne die datasentrum. Hulle is voorwaardelik onafhanklik. Een pad binne die datasentrum is slegs moontlik binne ToR. Binne die module het ons die aantal paaie gelyk aan die aantal bane. Die aantal paaie tussen modules is gelyk aan die produk van die aantal vlakke en die aantal superspines in elke vlak. Om dit duideliker te maak, om 'n gevoel van die skaal te kry, sal ek nommers gee wat geldig is vir een van die Yandex-datasentrums.
Daar is agt vliegtuie, elke vliegtuig het 32 superstekels. As gevolg hiervan blyk dit dat daar agt paaie binne die module is, en met intermodule-interaksie is daar reeds 256 van hulle.
Dit wil sê, as ons Kookboek ontwikkel en probeer leer hoe om foutverdraagsame datasentrums te bou wat hulself genees, dan is planargitektuur die regte keuse. Dit los die skaalprobleem op, en in teorie is dit maklik. Daar is baie onafhanklike paaie. Die vraag bly: hoe oorleef so 'n argitektuur mislukkings? Daar is verskeie mislukkings. En ons sal dit nou bespreek.
Laat een van ons superspies "siek word". Hier het ek teruggekeer na die twee-vlak argitektuur. Ons sal by hierdie as 'n voorbeeld hou, want dit sal eenvoudig makliker wees om te sien wat aangaan met minder bewegende dele. Laat X11 siek word. Hoe sal dit die dienste wat binne datasentrums woon, raak? Baie hang af van hoe die mislukking eintlik lyk.
As die mislukking goed is, word dit op die outomatiseringsvlak van dieselfde BFD vasgevang, die outomatisering sit gelukkig die problematiese gewrigte en isoleer die probleem, dan is alles in orde. Ons het baie paaie, verkeer word onmiddellik na alternatiewe roetes herlei, en dienste sal niks opmerk nie. Dit is 'n goeie draaiboek.
'n Slegte scenario is as ons konstante verliese het, en die outomatisering sien nie die probleem op nie. Om te verstaan hoe dit 'n toepassing raak, sal ons 'n bietjie tyd moet spandeer om te bespreek hoe TCP werk.
Ek hoop nie ek skok enigiemand met hierdie inligting nie: TCP is 'n transmissiebevestigingsprotokol. Dit wil sê, in die eenvoudigste geval stuur die sender twee pakkies en ontvang 'n kumulatiewe aantekening daarop: "Ek het twee pakkies ontvang."
Daarna sal hy nog twee pakkies stuur, en die situasie sal herhaal. Ek vra by voorbaat om verskoning vir 'n mate van vereenvoudiging. Hierdie scenario is korrek as die venster (die aantal pakkies in vlug) twee is. In die algemene geval is dit natuurlik nie noodwendig die geval nie. Maar die venstergrootte beïnvloed nie die pakketaanstuurkonteks nie.
Wat gebeur as ons pakkie 3 verloor? In hierdie geval sal die ontvanger pakkies 1, 2 en 4 ontvang. En hy sal uitdruklik vir die sender sê deur die SACK-opsie te gebruik: "Jy weet, drie het aangekom, maar die middel was verlore." Hy sê: "Ak 2, SAK 4."
Op hierdie oomblik herhaal die sender sonder enige probleme presies die pakkie wat verlore gegaan het.
Maar as die laaste pakkie in die venster verlore gaan, sal die situasie heeltemal anders lyk.
Die ontvanger ontvang die eerste drie pakkies en begin eers wag. Danksy sommige optimaliserings in die Linux-kern se TCP-stapel, sal dit wag vir 'n gepaarde pakkie, tensy die vlae uitdruklik aandui dat dit die laaste pakkie of iets soortgelyks is. Dit sal wag totdat die vertraagde ACK-tydperk verstryk en dan 'n erkenning op die eerste drie pakkies stuur. Maar nou sal die sender wag. Hy weet nie of die vierde pakkie verlore is of op die punt is om te arriveer nie. En om nie die netwerk te oorlaai nie, sal dit probeer om te wag vir 'n eksplisiete aanduiding dat die pakkie verlore is, of dat die RTO-timeout verval.
Wat is RTO-time-out? Dit is die maksimum van die RTT wat deur die TCP-stapel bereken word en 'n paar konstante. Watter soort konstante dit is, sal ons nou bespreek.
Maar die belangrike ding is dat as ons weer ongelukkig is en die vierde pakkie is weer verlore, dan verdubbel die RTO. Dit wil sê, elke onsuksesvolle poging beteken die verdubbeling van die time-out.
Kom ons kyk nou waaraan hierdie basis gelyk is. By verstek is die minimum RTO 200 ms. Dit is die minimum RTO vir datapakkette. Vir SYN-pakkies is dit anders, 1 sekonde. Soos u kan sien, sal selfs die eerste poging om pakkies weer te stuur 100 keer langer neem as die RTT in die datasentrum.
Kom ons keer nou terug na ons scenario. Wat gaan aan met die diens? Die diens begin pakkies verloor. Laat die diens eers voorwaardelik gelukkig wees en verloor iets in die middel van die venster, dan ontvang dit 'n SAK en stuur weer die pakkies wat verlore was.
Maar as ongeluk homself herhaal, dan het ons 'n RTO. Wat is hier belangrik? Ja, ons het baie paaie in ons netwerk. Maar die TCP-verkeer van een spesifieke TCP-verbinding sal voortgaan om deur dieselfde stukkende stapel te gaan. Pakkieverliese, mits hierdie magiese X11 van ons nie op sy eie uitgaan nie, lei nie daartoe dat verkeer na gebiede vloei wat nie problematies is nie. Ons probeer om die pakkie deur dieselfde stukkende stapel af te lewer. Dit lei tot 'n deurlopende mislukking: 'n datasentrum is 'n stel interaksie-toepassings, en sommige van die TCP-verbindings van al hierdie toepassings begin agteruitgaan - want superspine beïnvloed alle toepassings wat binne die datasentrum bestaan. Soos die spreekwoord sê: as jy nie 'n perd geskoen het nie, het die perd lam geword; die perd het lam geword - die rapport is nie gelewer nie; die verslag is nie gelewer nie – ons het die oorlog verloor. Slegs hier is die telling in sekondes vanaf die oomblik dat die probleem opduik tot die stadium van agteruitgang wat die dienste begin voel. Dit beteken dat gebruikers dalk iewers iets mis.
Daar is twee klassieke oplossings wat mekaar aanvul. Die eerste is dienste wat probeer om strooitjies in te sit en die probleem soos volg op te los: “Kom ons pas iets in die TCP-stapel aan. Kom ons maak time-outs op toepassingsvlak of langlewende TCP-sessies met interne gesondheidsondersoeke.” Die probleem is dat sulke oplossings: a) glad nie skaal nie; b) is baie swak nagegaan. Dit wil sê, selfs al konfigureer die diens per ongeluk die TCP-stapel op 'n manier wat dit beter maak, eerstens is dit onwaarskynlik dat dit van toepassing sal wees op alle toepassings en alle datasentrums, en tweedens, waarskynlik, sal dit nie verstaan dat dit gedoen is nie. korrek, en wat nie. Dit wil sê, dit werk, maar dit werk swak en skaal nie. En as daar 'n netwerkprobleem is, wie is die skuld? Natuurlik, NOC. Wat doen NOC?
Baie dienste glo dat in NOC-werk so iets gebeur. Maar om eerlik te wees, nie net dit nie.
NOC in die klassieke skema is besig met die ontwikkeling van baie moniteringstelsels. Dit is beide swart boks en wit boks monitering. Oor 'n voorbeeld van swart boks ruggraat monitering Alexander Klimenko by die laaste Next Hop. Terloops, hierdie monitering werk. Maar selfs ideale monitering sal 'n tydsvertraging hê. Gewoonlik is dit 'n paar minute. Nadat dit afgegaan het, het die ingenieurs aan diens tyd nodig om die werking daarvan na te gaan, die probleem te lokaliseer en dan die probleemarea te blus. Dit wil sê, in die beste geval neem die behandeling van die probleem 5 minute, in die ergste geval, 20 minute, as dit nie onmiddellik duidelik is waar die verliese voorkom nie. Dit is duidelik dat ons dienste al hierdie tyd - 5 of 20 minute - sal aanhou ly, wat waarskynlik nie goed is nie.
Wat sou jy regtig graag wou ontvang? Ons het soveel maniere. En probleme ontstaan juis omdat TCP-vloeie wat ongelukkig is, steeds dieselfde roete gebruik. Ons het iets nodig wat ons in staat sal stel om verskeie roetes binne 'n enkele TCP-verbinding te gebruik. Dit wil voorkom asof ons 'n oplossing het. Daar is TCP, wat multipath TCP genoem word, dit wil sê, TCP vir veelvuldige paaie. Dit is waar, dit is ontwikkel vir 'n heeltemal ander taak - vir slimfone wat verskeie netwerktoestelle het. Om oordrag te maksimeer of primêre/rugsteunmodus te maak, is 'n meganisme ontwikkel wat veelvuldige drade (sessies) deursigtig vir die toepassing skep en jou toelaat om tussen hulle te wissel in die geval van 'n mislukking. Of, soos ek gesê het, maksimeer die streep.
Maar hier is 'n nuanse. Om te verstaan wat dit is, sal ons moet kyk hoe drade gevestig word.
Drade word opeenvolgend geïnstalleer. Die eerste draad word eerste geïnstalleer. Daaropvolgende drade word dan gestel met behulp van die koekie wat reeds binne daardie draad ooreengekom is. En hier is die probleem.
Die probleem is dat as die eerste draad nie homself vestig nie, die tweede en derde draad nooit sal ontstaan nie. Dit wil sê, multipath TCP los nie die verlies van 'n SYN-pakkie in die eerste vloei op nie. En as die SYN verlore gaan, verander multipath TCP in gewone TCP. Dit beteken dat dit in 'n datasentrum-omgewing ons nie sal help om die probleem van verliese in die fabriek op te los en te leer om verskeie paaie te gebruik in die geval van 'n mislukking nie.
Wat kan ons help? Sommige van julle het reeds uit die titel geraai dat 'n belangrike veld in ons verdere storie die IPv6-vloeietiket-opskrifveld sal wees. Inderdaad, dit is 'n veld wat in v6 verskyn, dit is nie in v4 nie, dit beslaan 20 bisse, en daar was 'n lang tyd kontroversie oor die gebruik daarvan. Dit is baie interessant - daar was dispute, iets is binne die RFC reggestel, en terselfdertyd het 'n implementering in die Linux-kern verskyn, wat nêrens gedokumenteer is nie.
Ek nooi jou uit om saam met my te gaan vir 'n bietjie ondersoek. Kom ons kyk na wat die afgelope paar jaar in die Linux-kern gebeur het.
jaar 2014. 'n Ingenieur van een groot en gerespekteerde maatskappy voeg by die funksionaliteit van die Linux-kern die afhanklikheid van die vloeietiketwaarde op die socket-hash. Wat het hulle hier probeer regmaak? Dit hou verband met RFC 6438, wat die volgende kwessie bespreek het. Binne die datasentrum word IPv4 dikwels in IPv6-pakkies ingekapsuleer, want die fabriek self is IPv6, maar IPv4 moet op een of ander manier buite gegee word. Vir 'n lang tyd was daar probleme met skakelaars wat nie onder twee IP-opskrifte kon kyk om by TCP of UDP uit te kom en src_ports, dst_ports daar te vind nie. Dit het geblyk dat die hash, as jy na die eerste twee IP-opskrifte kyk, amper reggemaak is. Om dit te vermy, sodat die balansering van hierdie ingekapselde verkeer korrek werk, is voorgestel om die hash van die 5-tuple-ingekapsuleerde pakkie by die waarde van die vloeietiketveld te voeg. Ongeveer dieselfde ding is gedoen vir ander inkapselingskemas, vir UDP, vir GRE, laasgenoemde het die GRE-sleutelveld gebruik. Op die een of ander manier is die doelwitte hier duidelik. En ten minste op daardie tydstip was hulle nuttig.
In 2015 kom 'n nuwe pleister van dieselfde gerespekteerde ingenieur. Hy is baie interessant. Dit sê die volgende - ons sal die hash ewekansig maak in die geval van 'n negatiewe roeteergebeurtenis. Wat is 'n negatiewe roete-gebeurtenis? Dit is die RTO wat ons vroeër bespreek het, dit wil sê, die verlies van die stert van die venster is 'n gebeurtenis wat werklik negatief is. Dit is waar, dit is relatief moeilik om te raai dat dit dit is.
2016, nog 'n betroubare maatskappy, ook groot. Dit haal die laaste krukke uitmekaar en maak dit so dat die hash, wat ons voorheen ewekansig gemaak het, nou verander vir elke SYN-heruitsending en na elke RTO-tydverstreke. En in hierdie brief word vir die eerste en laaste keer die uiteindelike doel gestel - om te verseker dat verkeer in die geval van verliese of kanaalopeenhoping die vermoë het om saggies herlei te word en verskeie paaie te gebruik. Natuurlik, hierna was daar baie publikasies, jy kan dit maklik vind.
Alhoewel nee, jy kan nie, want daar was nie 'n enkele publikasie oor hierdie onderwerp nie. Maar ons weet!
En as jy nie ten volle verstaan wat gedoen is nie, sal ek jou nou vertel.
Wat is gedoen, watter funksionaliteit is by die Linux-kern gevoeg? txhash verander na 'n ewekansige waarde na elke RTO-gebeurtenis. Dit is die baie negatiewe gevolg van roetering. Die hash hang af van hierdie txhash, en die vloeietiket hang af van die skb hash. Daar is 'n paar berekeninge oor funksies hier; al die besonderhede kan nie op een skyfie geplaas word nie. As iemand nuuskierig is, kan jy deur die kernkode gaan en kyk.
Wat is hier belangrik? Die waarde van die vloeietiketveld verander na 'n ewekansige getal na elke RTO. Hoe beïnvloed dit ons ongelukkige TCP-stroom?
As 'n SACK plaasvind, verander niks nie, want ons probeer om 'n bekende verlore pakkie weer te stuur. So ver so goed.
Maar in die geval van RTO, mits ons 'n vloeietiket by die hash-funksie op ToR gevoeg het, kan die verkeer 'n ander roete neem. En hoe meer bane, hoe groter is die kans dat dit 'n pad sal vind wat nie deur 'n fout op 'n spesifieke toestel geraak word nie.
Een probleem bly oor - RTO. Natuurlik is daar 'n ander roete, maar baie tyd word hierop gemors. 200 ms is baie. ’n Tweede is absoluut wild. Voorheen het ek gepraat oor tyd-outs wat dienste opgestel is. Dus, 'n tweede is 'n time-out, wat gewoonlik deur die diens op toepassingsvlak gekonfigureer word, en hierin sal die diens selfs relatief reg wees. Boonop, ek herhaal, die werklike RTT binne 'n moderne datasentrum is ongeveer 1 millisekonde.
Wat kan jy doen met RTO-timeouts? Die uitteltyd, wat verantwoordelik is vir RTO in die geval van verlies van datapakkies, kan relatief maklik vanuit gebruikersspasie gekonfigureer word: daar is 'n IP-nutsding, en een van sy parameters bevat dieselfde rto_min. As in ag geneem word dat RTO natuurlik nie wêreldwyd aangepas moet word nie, maar vir gegewe voorvoegsels, lyk so 'n meganisme redelik werkbaar.
Dit is waar, met SYN_RTO is alles ietwat erger. Dit is natuurlik vasgespyker. Die kern het 'n vaste waarde van 1 sekonde, en dit is dit. Jy kan nie van gebruikersspasie af daarheen kom nie. Daar is net een manier.
eBPF kom tot die redding. Om dit eenvoudig te stel, dit is klein C-programme.. Hulle kan op verskillende plekke in hake ingevoeg word in die uitvoering van die kernstapel en die TCP-stapel, waarmee jy 'n baie groot aantal instellings kan verander. Oor die algemeen is eBPF 'n langtermyn-tendens. In plaas daarvan om tientalle nuwe sysctl-parameters te sny en die IP-nut uit te brei, beweeg die beweging na eBPF en brei die funksionaliteit daarvan uit. Deur eBPF te gebruik, kan jy opeenhopingskontroles en verskeie ander TCP-instellings dinamies verander.
Maar dit is vir ons belangrik dat dit gebruik kan word om die SYN_RTO-waardes te verander. Boonop is daar 'n voorbeeld wat in die openbaar geplaas is: . Wat is hier gedoen? Die voorbeeld werk, maar is op sigself baie rof. Hier word aanvaar dat ons binne die datasentrum die eerste 44 bisse vergelyk; as hulle ooreenstem, dan is ons binne die datasentrum. En in hierdie geval verander ons die SYN_RTO timeout waarde na 4ms. Dieselfde taak kan baie meer elegant gedoen word. Maar hierdie eenvoudige voorbeeld wys dat dit a) moontlik is; b) relatief eenvoudig.
Wat weet ons reeds? Die feit dat die vliegtuigargitektuur skaal moontlik maak, blyk uiters nuttig te wees vir ons wanneer ons die vloeietiket op ToR aktiveer en die vermoë kry om om probleemareas te vloei. Die beste manier om RTO- en SYN-RTO-waardes te verminder, is om eBPF-programme te gebruik. Die vraag bly: is dit veilig om 'n vloeietiket vir balansering te gebruik? En hier is 'n nuanse.
Gestel jy het 'n diens op jou netwerk wat in anycast woon. Ongelukkig het ek nie tyd om in detail te gaan oor wat anycast is nie, maar dit is 'n verspreide diens met verskillende fisiese bedieners wat via dieselfde IP-adres toeganklik is. En hier is 'n moontlike probleem: die RTO-gebeurtenis kan nie net plaasvind wanneer verkeer deur die stof beweeg nie. Dit kan ook op die ToR-buffervlak voorkom: wanneer 'n incast-gebeurtenis plaasvind, kan dit selfs op die gasheer voorkom wanneer die gasheer iets mors. Wanneer 'n RTO-gebeurtenis plaasvind en dit verander die vloeietiket. In hierdie geval kan verkeer na 'n ander uitsaai-instansie gaan. Kom ons neem aan dit is 'n stateful anycast, dit bevat 'n verbindingstoestand - dit kan 'n L3 Balancer of 'n ander diens wees. Dan ontstaan daar 'n probleem, want na RTO kom die TCP-verbinding by die bediener aan, wat niks van hierdie TCP-verbinding weet nie. En as ons nie staatsdeling tussen enige uitsending-bedieners het nie, sal sulke verkeer laat vaar word en die TCP-verbinding sal verbreek word.
Wat kan jy hier doen? Binne jou beheerde omgewing, waar jy vloeietiketbalansering aktiveer, moet jy die waarde van die vloeietiket aanteken wanneer jy toegang tot enige uitsending-bedieners kry. Die maklikste manier is om dit deur dieselfde eBPF-program te doen. Maar hier is 'n baie belangrike punt - wat om te doen as jy nie 'n datasentrumnetwerk bedryf nie, maar 'n telekommunikasie-operateur is? Dit is ook jou probleem: begin met sekere weergawes van Juniper en Arista, sluit hulle by verstek 'n vloeietiket in hul hash-funksies in - eerlikwaar, om 'n rede wat vir my onduidelik is. Dit kan veroorsaak dat jy TCP-verbindings laat val van gebruikers wat deur jou netwerk gaan. Ek beveel dus sterk aan om jou router-instellings hier na te gaan.
Op die een of ander manier lyk dit vir my of ons gereed is om aan te beweeg na eksperimente.
Toe ons die vloeietiket op ToR geaktiveer het, die eBPF-agent voorberei het, wat nou op die gashere woon, het ons besluit om nie te wag vir die volgende groot mislukking nie, maar om beheerde ontploffings uit te voer. Ons het ToR, wat vier opskakels het, geneem en drops op een van hulle opgestel. Hulle het 'n reël getrek en gesê - nou verloor jy alle pakkies. Soos u aan die linkerkant kan sien, het ons per-pakkie-monitering, wat tot 75% gedaal het, dit wil sê, 25% van die pakkies is verlore. Aan die regterkant is grafieke van dienste wat agter hierdie ToR woon. In wese is dit verkeersgrafieke van die koppelvlakke met bedieners binne die rek. Soos jy kan sien, het hulle selfs laer gesink. Hoekom het hulle laer gedaal - nie met 25% nie, maar in sommige gevalle met 3-4 keer? As die TCP-verbinding ongelukkig is, gaan dit voort om deur die stukkende aansluiting te probeer bereik. Dit word vererger deur die tipiese gedrag van die diens binne die GS - vir een gebruikerversoek word N versoeke na interne dienste gegenereer, en die antwoord sal na die gebruiker gaan óf wanneer alle databronne reageer, óf wanneer 'n uitteltyd by die toepassing plaasvind vlak, wat nog gekonfigureer moet word. Dit wil sê, alles is baie, baie sleg.
Nou dieselfde eksperiment, maar met die vloeietiketwaarde geaktiveer. Soos u kan sien, het ons bondelmonitering aan die linkerkant met dieselfde 25% gedaal. Dit is absoluut korrek, want dit weet niks van heruitsendings nie, dit stuur pakkies en tel bloot die verhouding van die aantal afgelewerde en verlore pakkies.
En aan die regterkant is die diensrooster. Jy sal nie die effek van 'n problematiese gewrig hier vind nie. In daardie selfde millisekondes het verkeer van die probleemarea na die drie oorblywende opskakels gevloei wat nie deur die probleem geraak is nie. Ons het 'n netwerk wat homself genees.
Dit is my laaste skyfie, tyd om op te som. Nou, ek hoop jy weet hoe om 'n selfgenesende datasentrumnetwerk te bou. Jy hoef nie deur die Linux-kern-argief te gaan en spesiale pleisters daar te soek nie; jy weet dat die Flow-etiket in hierdie geval die probleem oplos, maar jy moet hierdie meganisme versigtig benader. En ek beklemtoon weereens dat as jy 'n telekommunikasie-operateur is, jy nie vloeietiket as 'n hash-funksie moet gebruik nie, anders sal jy jou gebruikers se sessies ontwrig.
Netwerkingenieurs moet 'n konseptuele verskuiwing ondergaan: die netwerk begin nie met die ToR nie, nie met die netwerktoestel nie, maar met die gasheer. 'n Redelik treffende voorbeeld is hoe ons eBPF gebruik om beide die RTO te verander en om die vloeietiket na enige uitsending-dienste vas te stel.
Die vloeietiketmeganika is beslis geskik vir ander toepassings binne die beheerde administratiewe segment. Dit kan verkeer tussen datasentrums wees, of jy kan sulke meganika op 'n spesiale manier gebruik om uitgaande verkeer te bestuur. Maar ek sal jou volgende keer hieroor vertel, hoop ek. Baie dankie vir u aandag.
Bron: will.com