Halló, lesendur Habr. Með þessari grein opnum við röð sem mun fjalla um ofsamrunakerfið AERODISK vAIR sem við höfum þróað. Upphaflega vildum við segja allt um allt í fyrstu greininni, en kerfið er frekar flókið, svo við munum éta fílinn í pörtum.
Við skulum byrja söguna með sögu stofnunar kerfisins, kafa ofan í ARDFS skráarkerfið, sem er undirstaða vAIR, og einnig tala aðeins um staðsetningu þessarar lausnar á rússneska markaðnum.
Í framtíðargreinum munum við ræða nánar um mismunandi byggingarhluta (þyrping, yfirsýn, álagsjafnvægi, vöktunarkerfi o.s.frv.), uppsetningarferlið, taka upp leyfisvandamál, sýna sérstaklega áreksturspróf og, að sjálfsögðu, skrifa um álagspróf og stærð. Við munum einnig verja sérstakri grein til samfélagsútgáfunnar af vAIR.
Er Aerodisk saga um geymslukerfi? Eða hvers vegna byrjuðum við að gera ofursamruna í fyrsta lagi?
Upphaflega kom hugmyndin um að búa til okkar eigin ofsamruna til okkar einhvers staðar í kringum 2010. Á þeim tíma voru hvorki Aerodisk né svipaðar lausnir (commercial boxed hyperconverged systems) á markaðnum. Verkefni okkar var eftirfarandi: úr hópi netþjóna með staðbundnum diskum, sameinuðum með samtengingu í gegnum Ethernet-samskiptareglur, var nauðsynlegt að búa til aukna geymslu og ræsa sýndarvélar og hugbúnaðarnet þar. Allt þetta þurfti að útfæra án geymslukerfa (vegna þess að það var einfaldlega ekki til peningur fyrir geymslukerfi og vélbúnað þeirra og við vorum ekki enn búin að finna upp okkar eigin geymslukerfi).
Við reyndum margar opnar lausnir og leystum að lokum þetta vandamál, en lausnin var mjög flókin og erfitt að endurtaka. Að auki var þessi lausn í flokknum „Virkar hún? Ekki snerta! Þess vegna, eftir að hafa leyst það vandamál, þróuðum við ekki frekar hugmyndina um að umbreyta niðurstöðu vinnu okkar í fullgilda vöru.
Eftir það atvik fórum við frá þessari hugmynd en höfðum samt á tilfinningunni að þetta vandamál væri algjörlega leysanlegt og ávinningurinn af slíkri lausn var meira en augljós. Í kjölfarið staðfestu útgefnar HCI vörur erlendra fyrirtækja aðeins þessa tilfinningu.
Þess vegna, um mitt ár 2016, snerum við aftur að þessu verkefni sem hluti af því að búa til fullgilda vöru. Á þeim tíma höfðum við enn engin tengsl við fjárfesta, svo við þurftum að kaupa þróunarstand fyrir okkar eigin ekki mjög stóra peninga. Eftir að hafa safnað notuðum netþjónum og rofum á Avito fórum við í gang.
Helsta upphafsverkefnið var að búa til okkar eigið, að vísu einfalt, en okkar eigið skráarkerfi, sem gæti sjálfkrafa og jafnt dreift gögnum í formi sýndarblokka á n. fjölda klasahnúta, sem eru tengdir með samtengingu í gegnum Ethernet. Jafnframt ætti FS að skalast vel og auðveldlega og vera óháð aðliggjandi kerfum, þ.e. vera fjarlægt vAIR í formi „bara geymsluaðstöðu“.
Fyrsta vAIR hugmyndin
Við hættum vísvitandi að nota tilbúnar opinn uppspretta lausnir til að skipuleggja teygða geymslu (ceph, gluster, ljóma og þess háttar) í þágu okkar eigin þróunar, þar sem við höfðum þegar mikla verkefnareynslu af þeim. Auðvitað eru þessar lausnir sjálfar frábærar og áður en unnið var að Aerodisk innleiddum við fleiri en eitt samþættingarverkefni með þeim. En það er eitt að útfæra ákveðið verkefni fyrir einn viðskiptavin, þjálfa starfsfólk og, ef til vill, kaupa stuðning frá stórum söluaðila, og allt annað að búa til vöru sem auðvelt er að endurtaka sem verður notuð í ýmis verkefni, sem við sem seljanda, gætu jafnvel vita af okkur sjálfum við munum ekki. Í öðrum tilgangi hentaði núverandi opinn hugbúnaður ekki fyrir okkur, svo við ákváðum að búa til dreifð skráarkerfi sjálf.
Tveimur árum síðar náðu nokkrir forritarar (sem sameinuðu vinnu við vAIR og vinnu við klassíska Engine geymslukerfið) ákveðnum árangri.
Árið 2018 höfðum við skrifað einfalt skráarkerfi og bætt við það með nauðsynlegum vélbúnaði. Kerfið sameinaði líkamlega (staðbundna) diska frá mismunandi netþjónum í eina flata laug í gegnum innri samtengingu og „klippti“ þá í sýndarblokkir, síðan voru blokkartæki með mismikið bilunarþol búin til úr sýndarblokkunum, sem sýndarblokkir voru búnar til. og framkvæmt með því að nota KVM hypervisor bíla.
Við nenntum ekki of mikið með nafn skráarkerfisins og kölluðum það í stuttu máli ARDFS (gettu fyrir hvað það stendur fyrir))
Þessi frumgerð leit vel út (ekki sjónrænt, auðvitað, það var engin sjónræn hönnun ennþá) og sýndi góðan árangur hvað varðar frammistöðu og mælikvarða. Eftir fyrstu alvöru niðurstöðuna settum við þetta verkefni af stað, skipulögðum fullbúið þróunarumhverfi og sérstakt teymi sem fjallaði eingöngu um vAIR.
Rétt á þeim tíma hafði almennur arkitektúr lausnarinnar þroskast, sem hefur ekki enn tekið miklum breytingum.
Að kafa inn í ARDFS skráarkerfið
ARDFS er grunnurinn að vAIR, sem veitir dreifða, villuþolna gagnageymslu yfir allan klasann. Eitt af (en ekki eini) sérkenni ARDFS er að það notar ekki neina sérstaka netþjóna til viðbótar fyrir lýsigögn og stjórnun. Þetta var upphaflega hugsað til að einfalda uppsetningu lausnarinnar og fyrir áreiðanleika hennar.
Geymsluuppbygging
Innan allra hnúta klasans skipuleggur ARDFS rökréttan hóp úr öllu tiltæku plássi. Það er mikilvægt að skilja að laug er ekki enn gögn eða sniðið rými, heldur einfaldlega markup, þ.e. Allir hnútar með vAIR uppsett, þegar þeim er bætt við klasann, er sjálfkrafa bætt við sameiginlega ARDFS laugina og diskaauðlindir verða sjálfkrafa deilt yfir allan klasann (og tiltækar fyrir framtíðargagnageymslu). Þessi nálgun gerir þér kleift að bæta við og fjarlægja hnúta á flugi án þess að hafa alvarleg áhrif á kerfið sem þegar er í gangi. Þeir. kerfið er mjög auðvelt að skala „í múrsteinum“, bæta við eða fjarlægja hnúta í þyrpingunni ef þörf krefur.
Sýndardiskum (geymsluhlutum fyrir sýndarvélar) er bætt ofan á ARDFS laugina, sem eru byggðir úr sýndarblokkum sem eru 4 megabæti að stærð. Sýndardiskar geyma gögn beint. Villuþolskerfið er einnig stillt á sýndardisksstigi.
Eins og þú gætir þegar giskað á, fyrir bilanaþol diska undirkerfisins, notum við ekki hugtakið RAID (Ofþörf array of independent Disks), heldur notum RAIN (Ofþörf array of independent Nodes). Þeir. Bilunarþol er mælt, sjálfvirkt og stjórnað út frá hnútunum, ekki diskunum. Diskar eru auðvitað líka geymsluhlutur, þeir, eins og allt annað, er fylgst með, þú getur framkvæmt allar staðlaðar aðgerðir með þeim, þar á meðal að setja saman staðbundið vélbúnaðar-RAID, en þyrpingin starfar sérstaklega á hnútum.
Í aðstæðum þar sem þú vilt virkilega RAID (til dæmis atburðarás sem styður margar bilanir á litlum klösum), kemur ekkert í veg fyrir að þú notir staðbundna RAID stýringar og byggir teygða geymslu og RAIN arkitektúr ofan á. Þessi atburðarás er alveg lifandi og er studd af okkur, svo við munum tala um hana í grein um dæmigerðar aðstæður fyrir notkun vAIR.
Geymsluvilluþolskerfi
Það geta verið tvö bilunarþolskerfi fyrir sýndardiska í vAIR:
1) Afritunarstuðull eða einfaldlega afritun - þessi aðferð við bilunarþol er eins einföld og stafur og reipi. Samstillt afritun er framkvæmd á milli hnúta með stuðlinum 2 (2 eintök á þyrping) eða 3 (3 eintök, í sömu röð). RF-2 gerir sýndardiski kleift að standast bilun í einum hnút í þyrpingunni, en „borðar“ helminginn af nytsamlegu magni, og RF-3 mun standast bilun í 2 hnútum í þyrpingunni, en áskilur sér 2/3 af gagnlegt bindi fyrir þarfir þess. Þetta kerfi er mjög svipað og RAID-1, það er að sýndardiskur sem er stilltur í RF-2 er ónæmur fyrir bilun í einhverjum hnút í þyrpingunni. Í þessu tilfelli mun allt vera í lagi með gögnin og jafnvel I/O mun ekki stoppa. Þegar falli hnúturinn fer aftur í notkun mun sjálfvirk gagnaendurheimt/samstilling hefjast.
Hér að neðan eru dæmi um dreifingu RF-2 og RF-3 gagna í venjulegum ham og í bilunaraðstæðum.
Við erum með sýndarvél með 8MB af einstökum (gagnlegum) gögnum sem keyrir á 4 vAIR hnútum. Það er ljóst að í raun og veru er ólíklegt að það verði svo lítið magn, en fyrir kerfi sem endurspeglar rökfræði ARDFS reksturs er þetta dæmi skiljanlegast. AB eru 4MB sýndarblokkir sem innihalda einstök sýndarvélagögn. RF-2 býr til tvö eintök af þessum kubbum A1+A2 og B1+B2, í sömu röð. Þessar blokkir eru „lagðar út“ yfir hnúta og forðast skurðpunkta sömu gagna á sama hnút, það er að eintak A1 verður ekki staðsett á sama hnút og afrit A2. Sama með B1 og B2.
Ef einn af hnútunum bilar (td hnút nr. 3, sem inniheldur afrit af B1), er þetta afrit sjálfkrafa virkjað á hnútnum þar sem ekkert afrit er til af afriti hans (þ.e. afrit af B2).
Þannig getur sýndardiskurinn (og VM, í samræmi við það) auðveldlega lifað af bilun eins hnúts í RF-2 kerfinu.
Afritunarkerfið, þó einfalt og áreiðanlegt, þjáist af sama vandamáli og RAID1 - ekki nóg nothæft pláss.
2) Eyðingarkóðun eða eyðingarkóðun (einnig þekkt sem „óþarfa kóðun“, „eyðingarkóðun“ eða „offramboðskóði“) er til til að leysa vandamálið hér að ofan. EC er offramboðskerfi sem veitir mikið gagnaframboð með lægra kostnaði á diskplássi samanborið við afritun. Starfsregla þessa vélbúnaðar er svipuð og RAID 5, 6, 6P.
Við kóðun skiptir EC-ferlið sýndarblokk (4MB sjálfgefið) í nokkra smærri "gagnabúta" eftir EC-kerfinu (til dæmis skiptir 2+1 kerfi hverjum 4MB blokk í 2 2MB bita). Næst myndar þetta ferli „jafnvægisbita“ fyrir „gagnaklumpana“ sem eru ekki stærri en einn af áður skiptum hlutum. Við afkóðun býr EC til klumpana sem vantar með því að lesa „lifandi“ gögnin yfir allan klasann.
Til dæmis mun sýndardiskur með 2 + 1 EC kerfi, útfært á 4 klasahnúta, auðveldlega standast bilun í einum hnút í klasanum á sama hátt og RF-2. Í þessu tilviki verður kostnaðurinn lægri, sérstaklega er nýtingargetustuðullinn fyrir RF-2 2 og fyrir EC 2+1 verður hann 1,5.
Til að lýsa því á einfaldari hátt er kjarninn sá að sýndarblokkinni er skipt í 2-8 (af hverju frá 2 til 8, sjá hér að neðan) „stykki“ og fyrir þessa stykki eru „hlutir“ af jöfnuði af svipuðu rúmmáli reiknaðir.
Fyrir vikið er gögnum og jöfnuði jafnt dreift yfir alla hnúta klasans. Á sama tíma, eins og með afritun, dreifir ARDFS gögnum sjálfkrafa á milli hnúta á þann hátt að koma í veg fyrir að sams konar gögn (afrit af gögnum og jöfnuður þeirra) séu geymd á sama hnút, til að útiloka líkurnar á að gögn tapist vegna til þess að gögnin og jöfnuður þeirra lendi allt í einu á einum geymsluhnút sem bilar.
Hér að neðan er dæmi, með sömu 8 MB sýndarvélinni og 4 hnútum, en með EC 2+1 kerfi.
Kubbum A og B er skipt í tvö stykki af 2 MB hvor (tveir vegna 2+1), það er A1+A2 og B1+B2. Ólíkt eftirlíkingu er A1 ekki afrit af A2, það er sýndarblokk A, skipt í tvo hluta, eins og blokk B. Alls fáum við tvö sett af 4MB, sem hvert um sig inniheldur tvö tveggja MB stykki. Næst, fyrir hvert þessara setta, er jöfnuður reiknaður með rúmmáli sem er ekki meira en eitt stykki (þ.e. 2 MB), við fáum viðbótar + 2 stykki af jöfnuði (AP og BP). Alls höfum við 4×2 gögn + 2×2 jöfnuður.
Næst eru stykkin „sett út“ á milli hnútanna svo að gögnin skerist ekki jöfnuður þeirra. Þeir. A1 og A2 verða ekki á sama hnút og AP.
Ef bilun verður í einum hnút (til dæmis líka þann þriðja), verður fallinn blokk B1 sjálfkrafa endurheimtur úr BP-jafnvægi, sem er geymt á hnút nr. 2, og verður virkjaður á hnútnum þar sem ekkert B-jafnvægi, þ.e. stykki af BP. Í þessu dæmi er þetta hnútur nr. 1
Ég er viss um að lesandinn hefur spurningu:
„Allt sem þú lýstir hefur lengi verið innleitt bæði af samkeppnisaðilum og í opnum lausnum, hver er munurinn á innleiðingu þinni á EC í ARDFS?
Og svo verða áhugaverðir eiginleikar ARDFS.
Eyða kóðun með áherslu á sveigjanleika
Upphaflega settum við upp nokkuð sveigjanlegt EC X+Y kerfi, þar sem X er jafnt og tölu frá 2 til 8, og Y er jafnt og tölu frá 1 til 8, en alltaf minna en eða jafnt og X. Þetta kerfi er gefið upp fyrir sveigjanleika. Með því að fjölga fjölda gagnahluta (X) sem sýndarreitnum er skipt í gerir það kleift að draga úr kostnaði, það er að auka nothæft pláss.
Með því að fjölga jöfnunarbitum (Y) eykst áreiðanleiki sýndardisksins. Því hærra sem Y gildið er, því fleiri hnútar í þyrpingunni geta bilað. Auðvitað dregur aukning á jöfnunarmagni úr nothæfri afkastagetu, en þetta er gjald sem þarf að greiða fyrir áreiðanleika.
Háð frammistöðu á EC rásum er nánast bein: því fleiri „stykki“, því lægri er frammistaðan; hér er auðvitað þörf á jafnvægi.
Þessi nálgun gerir stjórnendum kleift að stilla teygða geymslu með hámarks sveigjanleika. Innan ARDFS laugarinnar geturðu notað hvaða bilanaþolskerfi sem er og samsetningar þeirra, sem að okkar mati er líka mjög gagnlegt.
Hér að neðan er tafla sem ber saman nokkur (ekki öll möguleg) RF og EC kerfi.
Taflan sýnir að jafnvel „terry“ samsetningin EC 8+7, sem gerir kleift að missa allt að 7 hnúta í þyrpingu samtímis, „borðar“ minna nothæft pláss (1,875 á móti 2) en venjuleg afritun og verndar 7 sinnum betur , sem gerir þetta verndarkerfi, þó að það sé flóknara, miklu meira aðlaðandi í aðstæðum þar sem nauðsynlegt er að tryggja hámarks áreiðanleika við aðstæður með takmarkað pláss. Á sama tíma þarftu að skilja að sérhver „plús“ við X eða Y verður aukaframmistöðukostnaður, þannig að í þríhyrningnum á milli áreiðanleika, sparnaðar og frammistöðu þarftu að velja mjög vandlega. Af þessum sökum munum við verja sérstakri grein til að eyða kóðunarstærð.
Áreiðanleiki og sjálfstæði skráarkerfisins
ARDFS keyrir staðbundið á öllum hnútum þyrpingarinnar og samstillir þá með eigin aðferðum í gegnum sérstakt Ethernet tengi. Mikilvægur punktur er að ARDFS samstillir sjálfstætt ekki aðeins gögnin heldur einnig lýsigögnin sem tengjast geymslu. Meðan við unnum að ARDFS, rannsökuðum við samtímis fjölda núverandi lausna og við komumst að því að margir samstilla meta skráarkerfisins með því að nota utanaðkomandi dreifð DBMS, sem við notum einnig fyrir samstillingu, en aðeins stillingar, ekki FS lýsigögn (um þetta og önnur tengd undirkerfi í næstu grein).
Samstilling FS lýsigagna með því að nota utanaðkomandi DBMS er auðvitað vinnandi lausn, en þá myndi samkvæmni gagna sem geymd eru á ARDFS ráðast af ytri DBMS og hegðun þess (og í hreinskilni sagt, það er duttlungafull kona), sem í okkar skoðun er slæm. Hvers vegna? Ef FS lýsigögnin skemmast, er líka hægt að segja FS gögnin sjálf „bless,“ svo við ákváðum að fara flóknari en áreiðanlegri leið.
Við gerðum sjálf samstillingar undirkerfi lýsigagna fyrir ARDFS og það lifir algjörlega óháð aðliggjandi undirkerfum. Þeir. ekkert annað undirkerfi getur spillt ARDFS gögnum. Að okkar mati er þetta áreiðanlegasta og réttasta leiðin en tíminn mun leiða í ljós hvort svo er í raun og veru. Að auki er viðbótarkostur við þessa nálgun. ARDFS er hægt að nota óháð vAIR, rétt eins og teygða geymslu, sem við munum örugglega nota í framtíðarvörum.
Fyrir vikið, með því að þróa ARDFS, fengum við sveigjanlegt og áreiðanlegt skráarkerfi sem gefur val þar sem þú getur sparað afkastagetu eða gefið allt upp á afköstum, eða búið til ofuráreiðanlega geymslu á sanngjörnum kostnaði, en minnkar kröfur um afköst.
Ásamt einfaldri leyfisstefnu og sveigjanlegu afhendingarlíkani (horft fram á veginn er vAIR leyfi fyrir hnút, og afhent annað hvort sem hugbúnaður eða hugbúnaðarpakki), gerir þetta þér kleift að sníða lausnina mjög nákvæmlega að margs konar kröfum viðskiptavina og þá auðveldlega halda þessu jafnvægi.
Hver þarf þetta kraftaverk?
Annars vegar má segja að það séu nú þegar aðilar á markaðnum sem hafa alvarlegar lausnir á sviði ofsamruna og þangað erum við í raun að stefna. Svo virðist sem þessi fullyrðing sé sönn, EN...
Á hinn bóginn, þegar við förum út á tún og höfum samskipti við viðskiptavini, sjáum við og samstarfsaðilar okkar að svo er alls ekki. Það eru mörg verkefni fyrir ofsamruna, sums staðar vissi fólk einfaldlega ekki að slíkar lausnir væru til, á öðrum virtust þær dýrar, á öðrum voru árangurslausar prófanir á öðrum lausnum og annars staðar banna þeir alls kaup vegna refsiaðgerða. Almennt reyndist akurinn vera óplægður, þannig að við fórum að ala upp jómfrúar jarðveg))).
Hvenær er geymslukerfi betra en GKS?
Þegar við vinnum með markaðinn erum við oft spurð hvenær betra sé að nota klassískt kerfi með geymslukerfum og hvenær eigi að nota ofsamruna? Mörg fyrirtæki sem framleiða GCS (sérstaklega þau sem eru ekki með geymslukerfi í eigu sinni) segja: "Geymslukerfi eru að verða úrelt, aðeins ofsamrunin!" Þetta er djörf fullyrðing, en hún endurspeglar ekki að öllu leyti raunveruleikann.
Í sannleika sagt er geymslumarkaðurinn að færast í átt að ofsamruna og svipuðum lausnum, en það er alltaf „en“.
Í fyrsta lagi er ekki auðvelt að endurbyggja gagnaver og upplýsingatækniinnviði sem byggð eru samkvæmt klassísku kerfinu með geymslukerfum, þannig að nútímavæðing og frágangur slíkra innviða er enn arfleifð í 5-7 ár.
Í öðru lagi, innviðir sem nú er verið að byggja að mestu leyti (sem þýðir að Rússland) er byggður í samræmi við klassíska kerfið með því að nota geymslukerfi, og ekki vegna þess að fólk veit ekki um ofsamruna, heldur vegna þess að ofsamrunamarkaðurinn er nýr, lausnir og staðlar hafa ekki enn verið settir, upplýsingatæknifólk er ekki enn þjálfað, það hefur litla reynslu, en það þarf að byggja gagnaver hér og nú. Og þessi þróun mun vara í 3-5 ár í viðbót (og svo önnur arfleifð, sjá lið 1).
Í þriðja lagi, það er eingöngu tæknileg takmörkun á frekari smátöfum upp á 2 millisekúndur á hverja skrif (að undanskildum staðbundnu skyndiminni, auðvitað), sem eru kostnaður við dreifða geymslu.
Jæja, við skulum ekki gleyma notkun stórra líkamlegra netþjóna sem elska lóðrétta stærðarstærð diska undirkerfisins.
Það eru mörg nauðsynleg og vinsæl verkefni þar sem geymslukerfi hegða sér betur en GCS. Hér munu þeir framleiðendur sem ekki eru með geymslukerfi í vörusafninu að sjálfsögðu ekki vera sammála okkur, en við erum tilbúnir til að rökræða sanngjarnt. Auðvitað munum við, sem þróunaraðilar beggja vara, örugglega bera saman geymslukerfi og GCS í einni af framtíðarútgáfum okkar, þar sem við munum greinilega sýna fram á hver er betri við hvaða aðstæður.
Og hvar munu ofsamræmdar lausnir virka betur en geymslukerfi?
Út frá ofangreindum atriðum má draga þrjár augljósar ályktanir:
- Þar sem 2 millisekúndna leynd til viðbótar fyrir upptöku, sem á sér stað stöðugt í hvaða vöru sem er (nú erum við ekki að tala um gerviefni, hægt er að sýna nanósekúndur á gerviefnum), er ofursamruni hentugur.
- Þar sem hægt er að breyta álagi frá stórum líkamlegum netþjónum í marga litla sýndarþjóna og dreifa á milli hnúta mun ofsamruni einnig virka vel þar.
- Þar sem lárétt mælikvarði er í meiri forgangi en lóðrétt mælikvarði mun GCS standa sig líka þar.
Hverjar eru þessar lausnir?
- Öll hefðbundin innviðaþjónusta (skráaþjónusta, póstur, EDMS, skráaþjónar, lítil eða meðalstór ERP og BI kerfi o.s.frv.). Við köllum þetta „almenna tölvumál“.
- Innviðir skýjaveitna, þar sem nauðsynlegt er að stækka hratt og staðlað lárétt og auðveldlega „klippa“ fjölda sýndarvéla fyrir viðskiptavini.
- Sýndarskrifborðsinnviðir (VDI), þar sem margar litlar sýndarvélar notenda keyra og „svífa“ hljóðlega innan einsleits klasa.
- Útibúanet, þar sem hvert útibú þarf staðlaða, bilanaþolna, en ódýra innviði 15-20 sýndarvéla.
- Allar dreifðar tölvur (stórgagnaþjónustur, til dæmis). Þar sem álagið fer ekki „í dýpt“ heldur „í breidd“.
- Prófunarumhverfi þar sem frekari litlar tafir eru ásættanlegar, en það eru takmarkanir á fjárhagsáætlun, vegna þess að þetta eru próf.
Í augnablikinu er það fyrir þessi verkefni sem við höfum búið til AERODISK vAIR og það er á þau sem við einbeitum okkur (með árangri hingað til). Kannski breytist þetta fljótlega, því... heimurinn stendur ekki kyrr.
Svo ...
Þetta lýkur fyrsta hluta stórrar greinaflokks; í næstu grein munum við tala um arkitektúr lausnarinnar og íhlutina sem notaðir eru.
Við tökum vel á móti spurningum, ábendingum og uppbyggilegum deilum.
Heimild: www.habr.com