Nútíma gagnaver eru með hundruð virkra tækja sem falla undir mismunandi gerðir eftirlits. En jafnvel fullkominn verkfræðingur með fullkomið eftirlit í höndunum mun geta brugðist rétt við netbilun á örfáum mínútum. Í skýrslu á Next Hop 2020 ráðstefnunni kynnti ég gagnaver nethönnunaraðferðafræði sem hefur einstaka eiginleika - gagnaverið læknar sig á millisekúndum. Nánar tiltekið lagar verkfræðingur vandamálið í rólegheitum á meðan þjónustan tekur einfaldlega ekki eftir því.
Fyrir marga netverkfræðinga byrjar gagnaversnetið að sjálfsögðu með ToR, með rofa í rekkanum. ToR hefur venjulega tvenns konar tengla. Litlu krakkarnir fara á netþjóna, aðrir - það eru N sinnum fleiri af þeim - fara í átt að fyrsta stigi spines, það er að uplinks þess. Upptenglar eru venjulega taldir jafnir og umferð milli upptengla er jöfnuð út frá 5-tuple hashinu, sem inniheldur frum, src_ip, dst_ip, src_port, dst_port. Hér kemur ekkert á óvart.
Næst, hvernig lítur arkitektúr flugvélanna út? Hryggirnir á fyrsta stigi eru ekki tengdir hver öðrum, heldur tengdir með ofursnúningum. Stafurinn X mun bera ábyrgð á ofursnúningum, hann er næstum eins og krosstenging.
Og það er ljóst að á hinn bóginn eru tori tengdir öllum hryggjum fyrsta stigs. Hvað er mikilvægt í þessari mynd? Ef við höfum samspil inni í rekkanum, þá fer samskiptin að sjálfsögðu í gegnum ToR. Ef víxlverkunin fer inni í einingunni, þá fer víxlverkunin í gegnum hrygginn á fyrsta stigi. Ef víxlverkunin er millieiningar - eins og hér, ToR 1 og ToR 2 - þá mun víxlverkunin fara í gegnum hrygginn á bæði fyrsta og öðru þrepi.
Fræðilega séð er svona arkitektúr auðveldlega skalanlegt. Ef við erum með hafnargetu, geymslupláss í gagnaverinu og fyrirfram lagðan trefjar, þá er alltaf hægt að fjölga flugvélum og auka þannig heildargetu kerfisins. Á pappír er þetta mjög auðvelt að gera. Það væri svona í raunveruleikanum. En sagan í dag snýst ekki um það.
Ég vil að réttar ályktanir séu dregnar. Við höfum margar leiðir inn í gagnaverið. Þau eru skilyrt sjálfstæð. Ein leið inn í gagnaverið er aðeins möguleg innan ToR. Inni í einingunni höfum við sama fjölda slóða og fjöldi flugvéla. Fjöldi leiða á milli eininga er jafn margfeldi fjölda plana og fjölda ofursnúninga í hverju plani. Til að gera það skýrara, til að finna fyrir mælikvarðanum, mun ég gefa upp tölurnar sem gilda fyrir eitt af Yandex gagnaverunum.
Það eru átta flugvélar, hver vél hefur 32 ofursnúninga. Fyrir vikið kemur í ljós að það eru átta slóðir inni í einingunni og með samspili milli eininga eru þær nú þegar 256.
Það er að segja, ef við erum að þróa matreiðslubók, reynum að læra hvernig á að byggja bilunarþolin gagnaver sem lækna sig sjálf, þá er planar arkitektúrinn rétti kosturinn. Það gerir þér kleift að leysa stærðarvandann og fræðilega er það auðvelt. Það eru margar sjálfstæðar leiðir. Eftir stendur spurningin: hvernig lifir slíkur arkitektúr af mistök? Það eru ýmis hrun. Og við munum ræða þetta núna.
Láttu einn af ofursnúningunum okkar verða veikur. Hér sneri ég aftur að arkitektúr tveggja flugvéla. Við munum halda okkur við þá sem dæmi vegna þess að það verður einfaldlega auðveldara að sjá hvað er að gerast hér með færri hreyfanlegum hlutum. Láttu X11 veikjast. Hvaða áhrif mun þetta hafa á þjónustu sem býr inni í gagnaverum? Mikið veltur á því hvernig bilunin lítur út í raun og veru.
Ef bilunin er góð, er hún gripin á stigi sjálfvirkni sama BFD, sjálfvirkni setur hamingjusamlega vandamálið og einangrar vandamálið, þá er allt í lagi. Við höfum marga slóða, umferð er samstundis færð á aðrar leiðir og þjónustan mun ekki taka eftir neinu. Þetta er góð atburðarás.
Slæm atburðarás er ef við erum með stöðugt tap og sjálfvirknin tekur ekki eftir vandamálinu. Til að skilja hvernig þetta hefur áhrif á forritið verðum við að eyða smá tíma í að ræða hvernig TCP samskiptareglur virka.
Ég vona að ég hneyksli engan með þessum upplýsingum: TCP er samskiptareglur um handabandi. Það er að segja að í einfaldasta tilvikinu sendir sendandinn tvo pakka og fær uppsafnaðan ack á þá: "Ég fékk tvo pakka."
Eftir það mun hann senda tvo pakka í viðbót og ástandið mun endurtaka sig. Ég biðst fyrirfram afsökunar á smá einföldun. Þessi atburðarás er rétt ef glugginn (fjöldi pakka á flugi) er tveir. Auðvitað á þetta ekki endilega við almennt. En pakkaframsendingarsamhengið hefur ekki áhrif á gluggastærðina.
Hvað gerist ef við töpum pakka 3? Í þessu tilviki mun viðtakandinn fá pakka 1, 2 og 4. Og hann mun skýrt tilkynna sendanda með SACK valkostinum: "Þú veist, þrír komu, en miðjan týndist." Hann segir "Ack 2, SACK 4".
Sendandi á þessari stundu endurtekur nákvæmlega pakkann sem týndist án vandræða.
En ef síðasti pakkinn í glugganum týnist mun staðan líta allt öðruvísi út.
Viðtakandinn fær fyrstu þrjá pakkana og byrjar fyrst og fremst að bíða. Þökk sé einhverri hagræðingu í Linux kjarna TCP stafla, mun hann bíða eftir pöruðum pakka, nema það sé skýr vísbending í flöggunum um að þetta sé síðasti pakkinn eða eitthvað álíka. Það mun bíða þar til seinkað ACK tímamörk rennur út og sendir síðan staðfestingu fyrir fyrstu þrjá pakkana. En nú mun sendandinn bíða. Hann veit ekki hvort fjórði pakkinn hafi týnst eða sé að koma. Og til að ofhlaða ekki netið, mun það reyna að bíða eftir skýrri vísbendingu um að pakkinn sé glataður, eða að RTO tímamörkin rennur út.
Hvað er RTO timeout? Þetta er hámarkið úr RTT reiknað af TCP staflanum og einhver fasti. Hvað er þetta fasti, munum við nú ræða.
En það er mikilvægt að ef við erum óheppin aftur og fjórði pakkinn tapast aftur, þá tvöfaldast RTO. Það er, hver misheppnuð tilraun er tvöföldun á tímamörkum.
Nú skulum við sjá hverju þessi grunnur er jafn. Sjálfgefið er að lágmarks RTO er 200ms. Þetta er lágmarks RTO fyrir gagnapakka. Fyrir SYN pakka er það öðruvísi, 1 sekúnda. Eins og þú sérð mun jafnvel fyrsta tilraunin til að senda pakka aftur taka 100 sinnum lengri tíma en RTT inni í gagnaverinu.
Nú aftur að atburðarás okkar. Hvað er að gerast með þjónustuna? Þjónustan byrjar að tapa pökkum. Leyfðu þjónustunni að vera heppinn í upphafi og týnir einhverju í miðjum glugganum, þá fær hún SACK, sendir týndu pakkana aftur.
En ef óheppnin endurtekur sig, þá höfum við RTO. Hvað er mikilvægt hér? Já, við erum með fullt af leiðum í netinu. En TCP umferð einnar tiltekins TCP tengingar mun halda áfram að fara í gegnum sama brotna stafla. Pakkatap, að því gefnu að galdra X11 okkar slokkni ekki af sjálfu sér, leiðir ekki til þess að umferð flæðir til svæða sem eru ekki vandamál. Við erum að reyna að afhenda pakka í gegnum sama brotna stafla. Þetta leiðir til fallandi bilunar: gagnaver er safn af samverkandi forritum og sumar TCP tengingar allra þessara forrita byrja að rýrna - vegna þess að superspin hefur áhrif á öll forrit sem eru inni í DC. Eins og í orðatiltækinu: ef þú skór ekki hest, þá haltrar hesturinn; hesturinn haltraði - skýrslan var ekki afhent; skilaboðin komust ekki til skila - þeir töpuðu stríðinu. Aðeins hér fer talningin í sekúndur frá því að vandamálið kemur upp til þess niðurbrotsstigs sem þjónusta byrjar að finna fyrir. Þetta þýðir að notendur mega ekki fá eitthvað einhvers staðar.
Það eru tvær klassískar lausnir sem bæta hvor aðra upp. Fyrsta er þjónusta sem er að reyna að leggja strá og leysa vandamálið á þessa leið: „Við skulum fínstilla eitthvað í TCP staflanum. Og við skulum gera tímamörk á forritastigi eða langvarandi TCP lotur með innri heilsufarsskoðun. Vandamálið er að slíkar lausnir: a) stækka alls ekki; b) mjög illa prófað. Það er, jafnvel þótt þjónustan stilli óvart TCP stafla þannig að hann verði betri, í fyrsta lagi er ólíklegt að þetta eigi við um öll forrit og öll gagnaver, og í öðru lagi mun hún líklega ekki skilja hvað var gert rétt og hvað ekki. Það er, það virkar, en það virkar illa og mælist ekki. Og ef það er netvandamál, hverjum er um að kenna? Auðvitað NOC. Hvað gerir NOC?
Margar þjónustur telja að í NOC fari vinnan eitthvað á þessa leið. En satt að segja, ekki bara.
NOC í klassíska kerfinu tekur þátt í þróun margra eftirlits. Þetta eru bæði eftirlit með svörtum kassa og eftirlit með hvítum kassa. Um dæmið um eftirlit með svörtum kassa með hryggjum Alexander Klimenko á fortíðinni Next Hop. Við the vegur, þetta eftirlit virkar. En jafnvel fullkomið eftirlit mun hafa tímatöf. Venjulega eru það nokkrar mínútur. Eftir að það virkar þurfa verkfræðingar á vakt tíma til að athuga virkni þess, staðsetja vandamálið og slökkva síðan á vandamálasvæðinu. Það er að segja að í besta falli tekur meðferð vandans 5 mínútur, í versta falli 20 mínútur, ef ekki er strax augljóst hvar töpin verða. Það er ljóst að allan þennan tíma - 5 eða 20 mínútur - mun þjónusta okkar halda áfram að vera sár, sem er líklega ekki gott.
Hvað myndir þú vilja fá? Við eigum svo margar leiðir. Og vandamál koma einmitt upp vegna þess að TCP flæði sem eru óheppin halda áfram að nota sömu leið. Við þurfum eitthvað sem gerir okkur kleift að nota margar leiðir innan einni TCP tengingar. Það virðist sem við höfum lausn. Það er TCP, sem er kallað svo - multipath TCP, það er TCP fyrir margar leiðir. Að vísu var það þróað fyrir allt annað verkefni - fyrir snjallsíma sem hafa nokkur nettæki. Til að hámarka flutninginn eða gera aðal-/afritunarhaminn, var vélbúnaður þróaður sem á gagnsæjan hátt býr til nokkra þræði (lotur) fyrir forritið og gerir þér kleift að skipta á milli þeirra ef bilun kemur upp. Eða, eins og ég sagði, hámarka bandbreiddina.
En það er blæbrigði hér. Til að skilja hvað það er verðum við að skoða hvernig straumar eru settir upp.
Þræðir eru settir í röð. Fyrsti straumurinn er settur upp fyrst. Síðari flæði eru síðan stillt með því að nota kökuna sem þegar hefur verið samþykkt innan þess þráðs. Og hér er vandamálið.
Vandamálið er að ef fyrsti þráðurinn er ekki settur upp, mun annar og þriðji þráðurinn aldrei koma upp. Það er, multipath TCP leysir ekki tap á SYN pakkanum í fyrsta straumnum. Og ef SYN tapast verður fjölbrauta TCP eðlilegt TCP. Svo, í gagnaverumhverfi, mun það ekki hjálpa okkur að leysa vandamálið með tapi í verksmiðjunni og læra hvernig á að nota margar leiðir ef bilun verður.
Hvað getur hjálpað okkur? Sum ykkar hafa nú þegar giskað á það út frá nafninu að mikilvægi reiturinn í frekari sögu okkar verði IPv6 flæðismerkjahausreiturinn. Reyndar er þetta reitur sem birtist í v6, það er ekki í v4, það tekur 20 bita og það hefur verið deilt um notkun þess í langan tíma. Þetta er mjög áhugavert - það voru deilur, eitthvað var lagað innan ramma RFC og á sama tíma birtist útfærsla í Linux kjarnanum sem var aldrei skjalfest neins staðar.
Ég legg til að þú fylgist með mér í smá rannsókn. Við skulum skoða hvað hefur verið að gerast í Linux kjarnanum undanfarin ár.
ári 2014. Verkfræðingur frá stóru og virtu fyrirtæki bætir við virkni Linux kjarnans háð gildi flæðismerkisins á kjötkássa falsins. Hvað eru þeir að reyna að laga hér? Þetta tengist RFC 6438 sem fjallaði um eftirfarandi mál. Inni í gagnaverinu er IPv4 oft hjúpað í IPv6 pökkum, því verksmiðjan sjálf er IPv6, en IPv4 verður einhvern veginn að gefast út. Í langan tíma voru vandamál með rofa sem gátu ekki leitað undir tveimur IP hausum til að komast í TCP eða UDP og fundið src_ports, dst_ports þar. Það kom í ljós að kjötkássa, ef þú skoðar fyrstu tvo IP-hausana, reyndist næstum fastur. Til að koma í veg fyrir þetta, svo að jafnvægi þessarar innhjúpuðu umferðar virki rétt, var lagt til að bæta kjötkássa úr 5-túllu hjúpuðu pakkanum við gildi flæðismerkisreitsins. Um það bil það sama var gert fyrir önnur hjúpunarkerfi, fyrir UDP, fyrir GRE, í því síðarnefnda var GRE Key reiturinn notaður. Með einum eða öðrum hætti eru markmiðin hér skýr. Og að minnsta kosti á þeim tímapunkti voru þeir gagnlegir.
Árið 2015 kemur nýr plástur frá sama virta verkfræðingi. Hann er mjög áhugaverður. Það segir eftirfarandi - við munum slemba kjötkássa ef um er að ræða neikvæða leiðaratburð. Hvað er neikvæður vegvísunaratburður? Þetta er RTO sem við ræddum áðan, það er að missa gluggahalann er atburður sem er virkilega neikvæður. Að vísu er tiltölulega erfitt að giska á hvað það er.
2016, annað virt fyrirtæki, líka stórt. Það greinir síðustu hækjurnar og gerir það að verkum að kjötkássa sem við gerðum áður slembiraðað er nú breytt í hverri SYN endursendingu og eftir hverja RTO tímamörk. Og í þessu bréfi, í fyrsta og síðasta skiptið, hljómar lokamarkmiðið - að tryggja að umferð ef tap eða ofhleðsla rása á sér stað hafi möguleika á mjúkri endurleið með því að nota margar leiðir. Auðvitað, eftir það var fullt af ritum, þú getur auðveldlega fundið þau.
Þó nei, þú getur það ekki, vegna þess að það hefur ekki verið eitt einasta rit um þetta efni. En við vitum það!
Og ef þú skilur ekki alveg hvað var gert, skal ég segja þér það núna.
Hvað hefur verið gert, hvaða virkni hefur verið bætt við Linux kjarnann? txhash breytist í handahófskennt gildi eftir hvern RTO atburð. Þetta er sama neikvæða leiðarniðurstaðan. Hashið fer eftir þessu txhash og flæðismerkið fer eftir skb hassinu. Það eru nokkrir útreikningar á aðgerðunum hér, ekki er hægt að setja allar upplýsingar á eina glæru. Ef einhver er forvitinn geturðu farið í gegnum kjarnakóðann og athugað.
Hvað er mikilvægt hér? Gildi flæðimerkisreitsins breytist í handahófskennda tölu eftir hverja RTO. Hvaða áhrif hefur þetta á óheppna TCP strauminn okkar?
Ef um SACK er að ræða hefur ekkert breyst vegna þess að við erum að reyna að endursenda þekktan týndan pakka. Svo langt svo gott.
En þegar um RTO er að ræða, að því gefnu að við höfum bætt flæðismerki við kjötkássaaðgerðina á ToR, getur umferðin farið aðra leið. Og því fleiri flugvélar, því líklegra er að finna leið sem ekki verður fyrir áhrifum af slysi á tilteknu tæki.
Eitt vandamál er eftir - RTO. Önnur leið er auðvitað fundin en mikill tími fer í hana. 200ms er mikið. Annað er almennt villi. Áðan talaði ég um tímamörk sem stilla þjónustu. Svo, annað er tímamörk sem venjulega setur upp þjónustu á umsóknarstigi, og í þessu mun þjónustan jafnvel vera tiltölulega rétt. Þar að auki, ég endurtek, raunverulegur RTT inni í nútíma gagnaveri er um 1 millisekúnda.
Hvað er hægt að gera við RTO tímamörk? Tímamörkin sem eru ábyrg fyrir RTO ef gagnapakkar tapast er tiltölulega auðveldlega hægt að stilla úr notendarými: það er til IP tól og ein af breytum þess inniheldur sömu rto_min. Í ljósi þess að auðvitað þarftu að snúa RTO ekki á heimsvísu, en fyrir tiltekin forskeyti, lítur slíkur gangur nokkuð vel út.
Satt, með SYN_RTO er allt eitthvað verra. Það er náttúrulega neglt niður. Gildið er fast í kjarnanum - 1 sekúnda, og það er það. Þú getur ekki náð í það úr notendarými. Það er aðeins ein leið.
eBPF kemur til bjargar. Í einföldu máli eru þetta lítil C-forrit. Hægt er að setja þau inn í króka á mismunandi stöðum í framkvæmd kjarnastafla og TCP-stafla, með þeim er hægt að breyta mjög mörgum stillingum. Almennt séð er eBPF langtímaþróun. Í stað þess að saga heilmikið af nýjum sysctl breytum og stækka IP tólið, er hreyfingin í átt að eBPF og stækkar virkni þess. Með eBPF geturðu breytt þrengslustýringum og ýmsum öðrum TCP stillingum á virkan hátt.
En það er mikilvægt fyrir okkur að með hjálp þess geturðu snúið gildum SYN_RTO. Og það er opinberlega birt dæmi: . Hvað er gert hér? Dæmið er að virka en er í sjálfu sér mjög gróft. Hér er gert ráð fyrir að inni í gagnaverinu berum við saman fyrstu 44 bitana, ef þeir passa saman, þá finnum við okkur inni í DC. Og í þessu tilfelli, breytum við gildi SYN_RTO timeout í 4ms. Sama verkefni er hægt að gera miklu meira þokkafullur. En þetta einfalda dæmi sýnir hvað er a) mögulegt; b) tiltölulega auðvelt.
Hvað vitum við nú þegar? Að planar arkitektúrinn leyfir mælikvarða, það reynist okkur afar gagnlegt þegar við kveikjum á flæðismerkinu á ToR og fáum tækifæri til að flæða um vandamálasvæði. Besta leiðin til að lækka RTO og SYN-RTO gildi er að nota eBPF forrit. Eftir stendur spurningin: er óhætt að nota flæðismerkið til jafnvægis? Og það er blæbrigði hér.
Segjum að þú sért með þjónustu á netinu sem býr í anycast. Því miður hef ég ekki tíma til að fara nánar út í anycast, en það er dreifð þjónusta þar sem mismunandi líkamlegir netþjónar eru tiltækir á sömu IP tölu. Og hér er hugsanlegt vandamál: RTO atburðurinn getur ekki aðeins átt sér stað þegar umferð fer í gegnum verksmiðjuna. Það getur líka átt sér stað á ToR biðminni stigi: þegar incast atburður á sér stað, getur það jafnvel átt sér stað á hýsilinn þegar hýsillinn hellir niður einhverju. Þegar RTO atburður á sér stað og það breytir flæðismerkinu. Í þessu tilviki getur umferðin farið í annað hvaða útsendingartilvik sem er. Segjum að það sé stateful anycast, það inniheldur tengingarástand - það getur verið L3 Balancer eða einhver önnur þjónusta. Þá kemur upp vandamál því eftir RTO kemur TCP tengingin á netþjóninn sem veit ekkert um þessa TCP tengingu. Og ef við höfum ekki ástandsdeilingu milli anycast netþjóna, þá mun slík umferð falla niður og TCP tengingin rofnar.
Hvað er hægt að gera hér? Innan þitt stýrða umhverfi, þar sem þú virkjar jafnvægi á flæðismerkjum, þarftu að laga gildi flæðismerkisins þegar þú opnar anycast netþjóna. Auðveldasta leiðin er að gera það í gegnum sama eBPF forritið. En hér er mjög mikilvægt atriði - hvað á að gera ef þú rekur ekki net gagnavera, en ert fjarskiptafyrirtæki? Þetta er vandamál þitt líka: frá og með ákveðnum útgáfum af Juniper og Arista eru þær sjálfgefið með flæðismerkið í kjötkássaaðgerðinni - satt best að segja af ástæðu sem ég skil ekki. Þetta getur valdið því að þú sleppir TCP tengingum frá notendum sem fara í gegnum netið þitt. Þess vegna mæli ég eindregið með því að athuga stillingar beinisins á þessum stað.
Með einum eða öðrum hætti sýnist mér að við séum tilbúin að fara í tilraunir.
Þegar við kveiktum á flæðismerkinu á ToR, útbjuggum eBPF umboðsmannsins, sem nú lifir á vélunum, ákváðum við að bíða ekki eftir næstu stóru bilun, heldur að framkvæma stýrðar sprengingar. Við tókum ToR, sem hefur fjóra upptengla, og slepptum einum þeirra. Þeir drógu reglu, sögðu þeir - nú ertu að missa alla pakka. Eins og þú sérð til vinstri höfum við eftirlit með hverjum pakka, sem hefur farið niður í 75%, það er að segja 25% pakka glatast. Hægra megin eru línurit af þjónustu sem býr á bak við þetta ToR. Reyndar eru þetta umferðargraf af samskeytum með netþjónum inni í rekkanum. Eins og þú sérð sukku þeir enn lægra. Hvers vegna sukku þeir lægra - ekki um 25%, en í sumum tilfellum um 3-4 sinnum? Ef TCP tengingin er óheppin heldur hún áfram að reyna að ná í gegnum bilað viðmót. Þetta er aukið af dæmigerðri hegðun þjónustunnar innan DC - fyrir eina notendabeiðni myndast N beiðnir til innri þjónustu og svarið mun fara til notandans, annað hvort þegar allir gagnagjafar bregðast við, eða þegar tími kemur af stað kl. forritastigið, sem enn þarf að stilla. Það er, allt er mjög, mjög slæmt.
Nú er sama tilraunin, en með flæðismerkið virkt. Eins og þú sérð, vinstra megin, lækkaði hópvöktun okkar um sömu 25%. Þetta er alveg rétt, því það veit ekkert um endursendingar, það sendir pakka og telur einfaldlega hlutfallið af fjölda afhentra og týndra pakka.
Og til hægri er dagskrá þjónustunnar. Þú finnur ekki áhrif vandamálaliða hér. Umferð á þessum sömu millisekúndum flæddi frá vandamálasvæðinu til þriggja upptenginga sem eftir voru sem voru ekki fyrir áhrifum af vandamálinu. Við fengum net sem læknar sig sjálft.
Þetta er síðasta glæran mín, kominn tími til að gera úttekt. Nú vona ég að þú veist hvernig á að byggja upp sjálfgræðandi gagnaversnet. Þú þarft ekki að fara í gegnum Linux kjarnaskjalasafnið og leita að sérstökum plástra þar, þú veist að Flow merkið leysir vandamálið í þessu tilfelli, en þú þarft að nálgast þetta kerfi vandlega. Og ég legg enn og aftur áherslu á að ef þú ert flutningsaðili ættirðu ekki að nota flæðismerkið sem kjötkássaaðgerð, annars muntu brjóta setu notenda þinna.
Fyrir netverkfræðinga þarf hugmyndafræðileg breyting að eiga sér stað: netið byrjar ekki með ToR, ekki með nettæki, heldur með hýsil. Nokkuð sláandi dæmi er hvernig við notum eBPF bæði til að breyta RTO og til að laga flæðismerkið í átt að anycast þjónustu.
Vélvirki flæðimerkisins er vissulega hentugur til annarra nota innan stjórnaðs stjórnunarhluta. Þetta getur verið umferð milli gagnavera, eða þú getur notað slíka vélbúnað á sérstakan hátt til að stjórna útleið. En ég ætla að tala um þetta, vona ég, næst. Þakka þér kærlega fyrir athyglina.
Heimild: www.habr.com