Hallo, Habr-lêzers. Mei dit artikel iepenje wy in searje dy't sil prate oer it hyperconverged systeem AERODISK vAIR dat wy hawwe ûntwikkele. Yn it earstoan woene wy alles oer alles fertelle yn it earste artikel, mar it systeem is frij kompleks, dus wy sille de oaljefant yn dielen ite.
Litte wy it ferhaal begjinne mei de skiednis fan 'e skepping fan it systeem, ferdjipje yn it ARDFS-bestânsysteem, dat de basis is fan vAIR, en ek in bytsje prate oer de posisjonearring fan dizze oplossing op' e Russyske merk.
Yn takomstige artikels sille wy yn mear detail prate oer ferskate arsjitektoanyske komponinten (kluster, hypervisor, load balancer, monitoaringsysteem, ensfh.), It konfiguraasjeproses, lisinsjeproblemen ophelje, crashtests apart sjen litte en, fansels, skriuwe oer load testen en sizing. Wy sille ek in apart artikel wije oan 'e mienskipferzje fan vAIR.
Is Aerodisk in ferhaal oer opslachsystemen? Of wêrom begûnen wy yn it foarste plak hyperkonverginsje te dwaan?
Yn it earstoan kaam it idee om ús eigen hyperkonverginsje te meitsjen earne om 2010 hinne. Op dat stuit wiene d'r noch Aerodisk noch ferlykbere oplossingen (kommersjele boxed hyperconverged systemen) op 'e merke. Us taak wie de folgjende: út in set fan tsjinners mei lokale skiven, ferienige troch in interconnect fia de Ethernet protokol, wie it nedich om te meitsjen in útwreide opslach en starte firtuele masines en in software netwurk dêr. Dit alles moast útfierd wurde sûnder opslachsystemen (omdat der gewoan gjin jild wie foar opslachsystemen en har hardware, en wy hiene ús eigen opslachsystemen noch net útfûn).
Wy hawwe in protte iepen boarne-oplossings besocht en dit probleem úteinlik oplost, mar de oplossing wie heul kompleks en lestich om te werheljen. Boppedat wie dizze oplossing yn 'e kategory "Wurkt it? Net oanreitsje! Dêrom, nei it oplossen fan dat probleem, hawwe wy it idee net fierder ûntwikkele om it resultaat fan ús wurk te transformearjen yn in folweardich produkt.
Nei dat ynsidint binne wy fuortgien fan dit idee, mar wy hienen noch it gefoel dat dit probleem folslein oplosber wie, en de foardielen fan sa'n oplossing wiene mear as dúdlik. Dêrnei befêstige de frijlitten HCI-produkten fan bûtenlânske bedriuwen dit gefoel allinich.
Dêrom, yn 'e midden fan 2016, wy werom nei dizze taak as ûnderdiel fan it meitsjen fan in folweardich produkt. Yn dy tiid hiene wy noch gjin relaasjes mei ynvestearders, dat wy moasten foar ús eigen net al te grutte jild in ûntwikkelingsstand keapje. Nei't wy brûkte servers en skeakels op Avito sammele hawwe, kamen wy oan 'e saak.
De wichtichste inisjele taak wie om ús eigen, hoewol ienfâldich, mar ús eigen bestânsysteem te meitsjen, dat gegevens automatysk en evenredich fersprieden koe yn 'e foarm fan firtuele blokken op it n-de oantal klusterknooppunten, dy't ferbûn binne troch in interconnect fia Ethernet. Tagelyk moat de FS goed en maklik skaalje en ûnôfhinklik wêze fan oanbuorjende systemen, d.w.s. wurde ferfrjemde fan vAIR yn 'e foarm fan "gewoan in opslachfoarsjenning".
Earste vAIR konsept
Wy hawwe bewust it gebrûk fan klearmakke iepen boarne-oplossingen foar it organisearjen fan stretched opslach (ceph, gluster, glâns en sa) ferlitten yn it foardiel fan ús eigen ûntwikkeling, om't wy al in protte projektûnderfining mei har hiene. Fansels binne dizze oplossingen sels poerbêst, en foardat wy oan Aerodisk wurkje, hawwe wy mear as ien yntegraasjeprojekt mei har ymplementearre. Mar it is ien ding om in spesifike taak foar ien klant út te fieren, personiel op te trenen en, miskien, de stipe fan in grutte ferkeaper te keapjen, en in hiel oar ding om in maklik te replikearjen produkt te meitsjen dat sil wurde brûkt foar ferskate taken, dy't wy, as in ferkeaper, kin sels witte oer ússels wy sille net. Foar it twadde doel wiene besteande iepen boarne produkten net geskikt foar ús, dus besleaten wy sels in ferspraat bestânsysteem te meitsjen.
Twa jier letter, ferskate ûntwikkelders (dy't kombinearre wurk op vAIR mei wurk oan de klassike Engine opslach systeem) berikte in bepaald resultaat.
Tsjin 2018 hienen wy in ienfâldich bestânsysteem skreaun en oanfolle mei de nedige hardware. It systeem kombinearre fysike (lokale) skiven fan ferskate tsjinners yn ien plat swimbad fia in ynterne ferbining en "knipte" se yn firtuele blokken, dan waarden blokapparaten makke mei ferskate graden fan fouttolerânsje út 'e firtuele blokken, wêrop firtuele blokken waarden makke. en útfierd mei help fan de KVM hypervisor auto's.
Wy makken ús net tefolle lestich mei de namme fan it bestânsysteem en neamden it ARDFS koartsein (riede wêr't it foar stiet))
Dit prototype seach der goed út (net visueel, fansels, d'r wie noch gjin fisueel ûntwerp) en liet goede resultaten sjen yn termen fan prestaasjes en skaalfergrutting. Nei it earste echte resultaat sette wy dit projekt yn beweging, organisearje in folweardige ûntwikkelingsomjouwing en in apart team dat allinich mei vAIR behannele.
Krekt tsjin dy tiid wie de algemiene arsjitektuer fan 'e oplossing matured, dy't noch gjin grutte feroarings ûndergien hat.
Dûk yn it ARDFS-bestânsysteem
ARDFS is de stifting fan vAIR, dy't ferdielde, fouttolerante gegevensopslach leveret oer it heule kluster. Ien fan (mar net de ienige) ûnderskiedende skaaimerken fan ARDFS is dat it gjin ekstra tawijd servers brûkt foar metadata en behear. Dit waard oarspronklik betocht om de konfiguraasje fan 'e oplossing te ferienfâldigjen en foar har betrouberens.
Opslach struktuer
Binnen alle knopen fan it kluster organisearret ARDFS in logyske pool fan alle beskikbere skiifromte. It is wichtich om te begripen dat in swimbad noch gjin gegevens of opmakke romte is, mar gewoan markearring, d.w.s. Alle knooppunten mei vAIR ynstalleare, as tafoege oan it kluster, wurde automatysk tafoege oan it dielde ARDFS-pool en skiifboarnen wurde automatysk dield oer it heule kluster (en beskikber foar takomstige gegevensopslach). Dizze oanpak lit jo knopen tafoegje en fuortsmite op 'e flecht sûnder serieuze ynfloed op it al rinnende systeem. Dy. it systeem is hiel maklik te skaaljen "yn bakstiennen", tafoegjen of fuortsmite knopen yn it kluster as it nedich is.
Firtuele skiven (opslachobjekten foar firtuele masines) wurde tafoege boppe op 'e ARDFS-pool, dy't binne boud út firtuele blokken fan 4 megabyte yn grutte. Firtuele skiven bewarje gegevens direkt. It fouttolerânsjeskema wurdt ek ynsteld op it firtuele skiifnivo.
Sa't jo miskien hawwe al rieden, foar skuld tolerânsje fan de skiif subsysteem, wy net brûke it konsept fan RAID (Oerstallige array fan ûnôfhinklike Disks), mar brûke RAIN (Oerstallige array fan ûnôfhinklike Nodes). Dy. Fouttolerânsje wurdt mjitten, automatisearre en beheard op basis fan 'e knopen, net de skiven. Disks, fansels, binne ek in opslachobjekt, se, lykas al it oare, wurde kontrolearre, jo kinne alle standert operaasjes mei har útfiere, ynklusyf it sammeljen fan in lokale hardware RAID, mar it kluster wurket spesifyk op knopen.
Yn in situaasje dêr't jo echt wolle RAID (Bygelyks, in senario dat stipet meardere mislearrings op lytse klusters), neat foarkomt jo út in gebrûk lokale RAID controllers, en bouwen stretched opslach en in RAIN arsjitektuer boppe. Dit senario is frij live en wurdt troch ús stipe, dus wy sille der oer prate yn in artikel oer typyske senario's foar it brûken fan vAIR.
Storage Fault Tolerance Schemes
D'r kinne twa fouttolerânsjeskema's wêze foar firtuele skiven yn vAIR:
1) Replikaasjefaktor as gewoan replikaasje - dizze metoade fan skuldtolerânsje is sa ienfâldich as in stôk en in tou. Syngroane replikaasje wurdt útfierd tusken knooppunten mei in faktor fan 2 (2 kopyen per kluster) of 3 (3 kopyen, respektivelik). RF-2 lit in firtuele skiif tsjin it mislearjen fan ien knooppunt yn it kluster, mar "eet" de helte fan it brûkbere folume, en RF-3 sil it mislearjen fan 2 knooppunten yn it kluster ferneare, mar reservearret 2/3 fan 'e brûkber folume foar syn behoeften. Dit skema is tige ferlykber mei RAID-1, dat is, in firtuele skiif konfigurearre yn RF-2 is resistint foar it mislearjen fan ien knooppunt yn it kluster. Yn dit gefal sil alles goed wêze mei de gegevens en sels de I / O sil net stopje. As it fallen knooppunt weromkomt yn tsjinst, sil automatyske gegevensherstel / syngronisaasje begjinne.
Hjirûnder binne foarbylden fan de ferdieling fan RF-2 en RF-3 gegevens yn normale modus en yn in flater situaasje.
Wy hawwe in firtuele masine mei in kapasiteit fan 8MB unike (nuttige) gegevens, dy't rint op 4 vAIR-knooppunten. It is dúdlik dat it yn werklikheid net wierskynlik is dat der sa'n lyts folume sil wêze, mar foar in skema dat de logika fan ARDFS-operaasje wjerspegelet, is dit foarbyld it meast begryplik. AB binne 4MB firtuele blokken mei unike firtuele masinegegevens. RF-2 makket respektivelik twa kopyen fan dizze blokken A1 + A2 en B1 + B2. Dizze blokken wurde "oanlein" oer knooppunten, om de krusing fan deselde gegevens op deselde knooppunt te foarkommen, dat is, kopy A1 sil net op deselde knoop lizze as kopy A2. Itselde mei B1 en B2.
As ien fan 'e knopen mislearret (bygelyks node No. 3, dy't in kopy fan B1 befettet), wurdt dizze kopy automatysk aktivearre op it node dêr't gjin kopy fan syn kopy is (dat is in kopy fan B2).
Sa kin de firtuele skiif (en de VM, dus) maklik it mislearjen fan ien knooppunt yn it RF-2-skema oerlibje.
It replikaasjeskema, hoewol ienfâldich en betrouber, lijt fan itselde probleem as RAID1 - net genôch brûkbere romte.
2) Erasure kodearring of wiskjen kodearring (ek wol bekend as "oerstallige kodearring", "wisskodearjen" of "oerstallige koade") bestiet om it probleem hjirboppe op te lossen. EC is in oerstallich skema dat jout hege gegevens beskikberens mei legere skiif romte overhead yn ferliking mei replikaasje. It bestjoeringssysteem prinsipe fan dit meganisme is fergelykber mei RAID 5, 6, 6P.
By kodearring ferdielt it EC-proses in firtuele blok (standert 4MB) yn ferskate lytsere "databrokken" ôfhinklik fan it EC-skema (bygelyks in 2+1-skema ferdielt elk 4MB-blok yn 2 2MB-brokken). Dêrnei genereart dit proses "paritychunks" foar de "databrokken" dy't net grutter binne as ien fan 'e earder ferdielde dielen. By it dekodearjen genereart EC de ûntbrekkende brokken troch de "oerlibjende" gegevens oer it heule kluster te lêzen.
Bygelyks, in firtuele skiif mei in 2 + 1 EC-skema, ymplementearre op 4 klusterknooppunten, sil maklik it mislearjen fan ien knooppunt yn it kluster op deselde wize as RF-2 ferneare. Yn dit gefal sille de overheadkosten leger wêze, benammen de nuttige kapasiteitskoëffisjint foar RF-2 is 2, en foar EC 2+1 sil it 1,5 wêze.
Om it ienfâldiger te beskriuwen, is de essinsje dat it firtuele blok ferdield is yn 2-8 (wêrom fan 2 oant 8, sjoch hjirûnder) "stikken", en foar dizze stikken wurde "stikken" fan pariteit fan in ferlykbere folume berekkene.
As resultaat wurde gegevens en pariteit lykwichtich ferdield oer alle knooppunten fan it kluster. Tagelyk, lykas by replikaasje, ferspriedt ARDFS automatysk gegevens oer knooppunten op sa'n manier om foar te kommen dat identike gegevens (kopyen fan gegevens en har pariteit) wurde opslein op deselde knooppunt, om de kâns op it ferliezen fan gegevens te eliminearjen oan it feit dat de gegevens en har pariteit ynienen op ien opslachknooppunt komme dy't mislearret.
Hjirûnder is in foarbyld, mei deselde 8 MB firtuele masine en 4 knopen, mar mei in EC 2+1 skema.
Blokken A en B wurde ferdield yn twa stikken fan 2 MB elk (twa omdat 2 + 1), dat is, A1 + A2 en B1 + B2. Oars as in replika, A1 is gjin kopy fan A2, it is in firtuele blok A, ferdield yn twa dielen, itselde mei blok B. Yn totaal krije wy twa sets fan 4MB, elk fan dat befettet twa twa-MB stikken. Folgjende, foar elk fan dizze sets, parity wurdt berekkene mei in folume fan net mear as ien stik (dus 2 MB), wy krije in ekstra + 2 stikken fan parity (AP en BP). Yn totaal hawwe wy 4 × 2 gegevens + 2 × 2 pariteit.
Dêrnei wurde de stikken "útlein" tusken de knopen, sadat de gegevens net krúst mei har pariteit. Dy. A1 en A2 sille net op itselde knooppunt wêze as AP.
Yn it gefal fan in mislearring fan ien knooppunt (bygelyks ek de tredde), sil it fallen blok B1 automatysk weromset wurde fan 'e BP-pariteit, dy't opslein is op knooppunt nr. 2, en sil aktivearre wurde op it knooppunt dêr't der is gjin B-parity, d.w.s. stik bp. Yn dit foarbyld is dit knooppunt nûmer 1
Ik bin der wis fan dat de lêzer in fraach hat:
"Alles wat jo beskreau is al lang ymplementearre sawol troch konkurrinten as yn iepen boarne-oplossingen, wat is it ferskil tusken jo ymplemintaasje fan EC yn ARDFS?"
En dan sille d'r ynteressante funksjes fan ARDFS wêze.
Kodearring wiskje mei in fokus op fleksibiliteit
Yn earste ynstânsje levere wy in frij fleksibel EC X+Y-skema, wêrby't X gelyk is oan in getal fan 2 oant 8, en Y is gelyk oan in getal fan 1 oant 8, mar altyd minder as of gelyk oan X. Dit skema is foarsjoen foar fleksibiliteit. It fergrutsjen fan it oantal gegevensstikken (X) wêryn it firtuele blok is ferdield makket it ferminderjen fan overheadkosten mooglik, dat is it fergrutsjen fan brûkbere romte.
It fergrutsjen fan it oantal parity chunks (Y) fergruttet de betrouberens fan de firtuele skiif. Hoe grutter de Y-wearde, hoe mear knopen yn it kluster kinne mislearje. Fansels, it fergrutsjen fan de parity folume ferleget it bedrach fan brûkbere kapasiteit, mar dit is in priis te beteljen foar betrouberens.
De ôfhinklikheid fan prestaasjes op EC-sirkels is hast direkt: hoe mear "stikken", hoe leger de prestaasjes; hjir is fansels in lykwichtige werjefte nedich.
Dizze oanpak lit behearders útwreide opslach konfigurearje mei maksimale fleksibiliteit. Binnen it ARDFS-swimbad kinne jo alle fouttolerânsjeskema's en har kombinaasjes brûke, dy't, nei ús miening, ek heul nuttich is.
Hjirûnder is in tabel dy't ferskate (net alle mooglike) RF- en EC-skema's fergeliket.
De tabel lit sjen dat sels de meast "terry" kombinaasje EC 8+7, wêrtroch it ferlies fan maksimaal 7 knopen yn in kluster tagelyk mooglik makket, minder brûkbere romte (1,875 tsjin 2) as standert replikaasje, en beskermet 7 kear better , wat dit beskermingsmeganisme makket, hoewol komplekser, folle oantrekliker yn situaasjes wêr't it nedich is om maksimale betrouberens te garandearjen yn betingsten fan beheinde skiifromte. Tagelyk moatte jo begripe dat elke "plus" oan X of Y in ekstra prestaasje-overhead sil wêze, dus yn 'e trijehoek tusken betrouberens, besparring en prestaasjes moatte jo tige soarchfâldich kieze. Om dizze reden sille wy in apart artikel wije oan it wiskjen fan kodearringsgrutte.
Betrouberens en autonomy fan it bestânsysteem
ARDFS rint lokaal op alle knopen fan it kluster en syngronisearret se mei syn eigen middels fia tawijd Ethernet-ynterfaces. It wichtige punt is dat ARDFS ûnôfhinklik syngronisearret net allinich de gegevens, mar ek de metadata relatearre oan opslach. Wylst wy wurke oan ARDFS, studearre wy tagelyk in oantal besteande oplossingen en wy ûntdutsen dat in protte de meta fan it bestânsysteem syngronisearje mei in ekstern ferspraat DBMS, dy't wy ek brûke foar syngronisaasje, mar allinich konfiguraasjes, net FS-metadata (oer dit en oare relatearre subsystemen yn it folgjende artikel).
Syngronisearjen fan FS-metadata mei in eksterne DBMS is fansels in wurkjende oplossing, mar dan soe de konsistinsje fan 'e gegevens op ARDFS ôfhingje fan' e eksterne DBMS en har gedrach (en, earlik sein, it is in grillige dame), dy't yn ús miening is min. Wêrom? As de FS-metadata skansearre wurdt, kinne de FS-gegevens sels ek "ôfskie" wurde sein, dus wy besletten in mear komplekse, mar betroubere paad te nimmen.
Wy makken it subsysteem foar syngronisaasje fan metadata foar ARDFS sels, en it libbet folslein ûnôfhinklik fan neistlizzende subsystemen. Dy. gjin oar subsysteem kin ARDFS-gegevens korrupsje. Neffens ús is dit de meast betroubere en korrekte manier, mar de tiid sil leare oft dat eins sa is. Dêrneist is der in ekstra foardiel mei dizze oanpak. ARDFS kin brûkt wurde ûnôfhinklik fan vAIR, krekt as stretched opslach, dat wy sille grif brûke yn takomstige produkten.
As gefolch, troch it ûntwikkeljen fan ARDFS, krigen wy in fleksibel en betrouber bestânsysteem dat in kar jout wêr't jo kinne besparje op kapasiteit of alles opjaan kinne op prestaasjes, of ultra-betroubere opslach meitsje tsjin in ridlike kosten, mar it ferminderjen fan prestaasjeseasken.
Tegearre mei in ienfâldich lisinsjebelied en in fleksibel leveringsmodel (foarútsjoen, is vAIR lisinsje fan knooppunt, en wurdt levere as software of as softwarepakket), kinne jo de oplossing heul presys oanpasse oan in breed ferskaat oan klanteasken en dan maklik behâlde dit lykwicht.
Wa hat dit wûnder nedich?
Oan 'e iene kant kinne wy sizze dat d'r al spilers op' e merk binne dy't serieuze oplossingen hawwe op it mêd fan hyperkonverginsje, en dit is wêr't wy eins hinne gean. It liket derop dat dizze útspraak wier is, MAAR ...
Oan 'e oare kant, as wy de fjilden yngeane en kommunisearje mei klanten, sjogge wy en ús partners dat dit hielendal net it gefal is. D'r binne in protte taken foar hyperkonverginsje, op guon plakken wisten minsken gewoan net dat sokke oplossingen bestie, yn oaren like it djoer, yn oaren wiene d'r mislearre tests fan alternative oplossingen, en yn oaren ferbiede se keapjen hielendal fanwege sanksjes. Yn 't algemien die bliken dat it fjild unplowed wie, dus wy gongen om heide grûn te ferheegjen))).
Wannear is opslachsysteem better dan GCS?
As wy wurkje mei de merk, wurde wy faak frege wannear't it better is om in klassike skema te brûken mei opslachsystemen, en wannear't jo hyperkonvergent brûke? In protte bedriuwen dy't GCS produsearje (benammen dyjingen dy't gjin opslachsystemen yn har portfolio hawwe) sizze: "Opslachsystemen wurde ferâldere, allinich hyperkonverge!" Dit is in fet útspraak, mar it reflektearret net hielendal de realiteit.
Yn wierheid beweecht de opslachmerk yndie nei hyperkonverginsje en ferlykbere oplossingen, mar d'r is altyd in "mar".
As earste kinne datasintra en IT-ynfrastruktueren boud neffens it klassike skema mei opslachsystemen net maklik wer opboud wurde, sadat de modernisearring en foltôging fan sokke ynfrastruktuer noch in legacy is foar 5-7 jier.
Twad, de ynfrastruktuer dy't op it stuit wurdt boud foar it grutste part (dat betsjut dat de Russyske Federaasje) is boud neffens it klassike skema mei help fan opslach systemen, en net omdat minsken net witte oer hyperkonverginsje, mar omdat de hyperkonverginsje merk is nij, oplossings en noarmen binne noch net fêststeld, IT-minsken binne noch net oplaat, se hawwe net folle ûnderfining, mar se moatte hjir en no datasintra bouwe. En dizze trend sil noch 3-5 jier duorje (en dan in oare legacy, sjoch punt 1).
Tredde is d'r in suver technyske beheining yn ekstra lytse fertragingen fan 2 millisekonden per skriuwen (útsein de lokale cache, fansels), dy't de kosten binne fan ferdielde opslach.
No, lit ús it gebrûk fan grutte fysike servers net ferjitte dy't fan fertikale skaalfergrutting fan it skiifsubsysteem hâlde.
D'r binne in protte needsaaklike en populêre taken wêr't opslachsystemen better gedrage as GCS. Hjir, fansels, dy fabrikanten dy't hawwe gjin opslach systemen yn harren produkt portfolio sil net iens mei ús, mar wy binne ree om te pleitsjen ridlik. Fansels sille wy, as ûntwikkelders fan beide produkten, perfoarst fergelykje opslachsystemen en GCS yn ien fan ús takomstige publikaasjes, wêr't wy dúdlik sille sjen litte wat better is ûnder hokker betingsten.
En wêr sille hyperconverged oplossingen better wurkje dan opslachsystemen?
Op grûn fan boppesteande punten kinne trije dúdlike konklúzjes lutsen wurde:
- Wêr't in ekstra 2 millisekonden fan latency foar opname, dy't konsekwint foarkomt yn elk produkt (no hawwe wy it net oer synthetics, nanosekonden kinne wurde toand op synthetics), binne unkritysk, hyperkonvergent is geskikt.
- Wêr't de lading fan grutte fysike servers kin wurde omset yn in protte lytse firtuele en ferdield oer knooppunten, sil hyperkonverginsje dêr ek goed wurkje.
- Wêr't horizontale skaalfergrutting in hegere prioriteit is dan fertikale skaalfergrutting, sil GCS dêr ek goed dwaan.
Wat binne dizze oplossingen?
- Alle standert ynfrastruktuer tsjinsten (directory tsjinst, mail, EDMS, triem servers, lytse of middelgrutte ERP en BI systemen, ensfh). Wy neame dit "algemien computing".
- De ynfrastruktuer fan wolkproviders, wêr't it nedich is om fluch en standerdisearre horizontaal út te wreidzjen en maklik in grut oantal firtuele masines foar kliïnten te "snijen".
- Firtuele buroblêdynfrastruktuer (VDI), wêr't in protte firtuele masines fan lytse brûkers rinne en rêstich "driuwe" binnen in unifoarm kluster.
- Branch netwurken, dêr't elke tûke nedich in standert, fout-tolerante, mar goedkeape ynfrastruktuer fan 15-20 firtuele masines.
- Elke ferdielde kompjûter (bygelyks grutte gegevenstsjinsten). Wêr't de lading net "yn 'e djipte" giet, mar "yn 'e breedte".
- Testomjouwings wêr't ekstra lytse fertragingen akseptabel binne, mar d'r binne budzjetbeheiningen, om't dit tests binne.
Op it stuit is it foar dizze taken dat wy AERODISK vAIR hawwe makke en it is op har dat wy rjochtsje (mei súkses oant no ta). Miskien feroaret dat gau, want... de wrâld stiet net stil.
Sa…
Dit foltôget it earste diel fan in grutte searje artikels; yn it folgjende artikel sille wy prate oer de arsjitektuer fan 'e oplossing en de brûkte komponinten.
Wy ferwolkomje fragen, suggestjes en konstruktive skelen.
Boarne: www.habr.com