Hallo Habr-lezers. Met dit artikel openen we een serie waarin we het hebben over het hyperconverged systeem AERODISK vAIR dat we hebben ontwikkeld. Aanvankelijk wilden we in het eerste artikel alles over alles vertellen, maar het systeem is behoorlijk complex, dus we zullen de olifant in delen opeten.
Laten we het verhaal beginnen met de geschiedenis van de creatie van het systeem, ons verdiepen in het ARDFS-bestandssysteem, dat de basis vormt van vAIR, en ook wat vertellen over de positionering van deze oplossing op de Russische markt.
In toekomstige artikelen zullen we meer in detail praten over verschillende architecturale componenten (cluster, hypervisor, load balancer, monitoringsysteem, etc.), het configuratieproces, licentieproblemen aan de orde stellen, afzonderlijk crashtests tonen en natuurlijk schrijven over loadtests en maatvoering. We zullen ook een apart artikel wijden aan de communityversie van vAIR.
Is Aerodisk een verhaal over opslagsystemen? Of waarom zijn we überhaupt begonnen met hyperconvergentie?
Aanvankelijk ontstond het idee om onze eigen hyperconvergentie ergens rond 2010 te creëren. Op dat moment was er noch Aerodisk, noch soortgelijke oplossingen (commerciële hypergeconvergeerde boxsystemen) op de markt. Onze taak was de volgende: vanuit een reeks servers met lokale schijven, verenigd door een verbinding via het Ethernet-protocol, was het noodzakelijk om een uitgebreide opslag te creëren en daar virtuele machines en een softwarenetwerk te lanceren. Dit alles moest worden geïmplementeerd zonder opslagsystemen (omdat er simpelweg geen geld was voor opslagsystemen en de hardware ervan, en we onze eigen opslagsystemen nog niet hadden uitgevonden).
We hebben veel open source-oplossingen geprobeerd en uiteindelijk dit probleem opgelost, maar de oplossing was erg complex en moeilijk te herhalen. Bovendien viel deze oplossing in de categorie “Werkt het? Niet aanraken! Daarom hebben we, nadat we dat probleem hadden opgelost, het idee om het resultaat van ons werk om te zetten in een volwaardig product niet verder ontwikkeld.
Na dat incident zijn we van dit idee afgestapt, maar we hadden nog steeds het gevoel dat dit probleem volledig oplosbaar was en dat de voordelen van een dergelijke oplossing meer dan duidelijk waren. Vervolgens bevestigden de vrijgegeven HCI-producten van buitenlandse bedrijven dit gevoel alleen maar.
Daarom zijn we medio 2016 teruggekeerd naar deze taak als onderdeel van het creëren van een volwaardig product. We hadden toen nog geen relaties met investeerders, dus moesten we voor ons eigen niet al te grote geld een ontwikkelingsstand kopen. Nadat we gebruikte servers en switches op Avito hadden verzameld, gingen we aan de slag.
De belangrijkste initiële taak was om ons eigen, zij het eenvoudige, maar toch eigen bestandssysteem te creëren, dat automatisch en gelijkmatig gegevens kon distribueren in de vorm van virtuele blokken op het negende aantal clusterknooppunten, die verbonden zijn door een interconnectie via Ethernet. Tegelijkertijd moet de FS goed en gemakkelijk kunnen worden geschaald en onafhankelijk zijn van aangrenzende systemen, d.w.z. vervreemd worden van vAIR in de vorm van “slechts een opslagfaciliteit”.
Eerste vAIR-concept
We hebben bewust afgezien van het gebruik van kant-en-klare open source-oplossingen voor het organiseren van uitgerekte opslag (ceph, gluster, lustre en dergelijke) ten gunste van onze eigen ontwikkeling, omdat we er al veel projectervaring mee hadden. Natuurlijk zijn deze oplossingen zelf uitstekend, en voordat we aan Aerodisk gingen werken, hebben we er meer dan één integratieproject mee geïmplementeerd. Maar het is één ding om een specifieke taak voor één klant uit te voeren, personeel op te leiden en misschien de steun van een grote leverancier in te kopen, en iets heel anders om een gemakkelijk te repliceren product te creëren dat voor verschillende taken zal worden gebruikt, en dat wij, als leverancier, misschien zelfs iets over onszelf weten, zullen we niet weten. Voor het tweede doel waren bestaande open source-producten niet geschikt voor ons, dus besloten we zelf een gedistribueerd bestandssysteem te creëren.
Twee jaar later bereikten verschillende ontwikkelaars (die het werk aan vAIR combineerden met het werk aan het klassieke Engine-opslagsysteem) een bepaald resultaat.
In 2018 hadden we een eenvoudig bestandssysteem geschreven en aangevuld met de benodigde hardware. Het systeem combineerde fysieke (lokale) schijven van verschillende servers in één platte pool via een interne interconnect en ‘knipte’ deze in virtuele blokken. Vervolgens werden uit de virtuele blokken blokapparaten met een verschillende mate van fouttolerantie gemaakt, waarop virtuele blokken werden gemaakt. en uitgevoerd met behulp van de KVM-hypervisorauto's.
We hebben ons niet al te veel bezig gehouden met de naam van het bestandssysteem en hebben het kort en bondig ARDFS genoemd (raad eens waar het voor staat))
Dit prototype zag er goed uit (visueel niet natuurlijk, er was nog geen visueel ontwerp) en liet goede resultaten zien op het gebied van prestaties en schaling. Na het eerste echte resultaat hebben we dit project in gang gezet, waarbij we een volwaardige ontwikkelomgeving hebben ingericht en een apart team dat zich uitsluitend met vAIR bezighield.
Juist tegen die tijd was de algemene architectuur van de oplossing volwassen geworden, die nog geen grote veranderingen heeft ondergaan.
Duiken in het ARDFS-bestandssysteem
ARDFS is de basis van vAIR, dat gedistribueerde, fouttolerante gegevensopslag over het hele cluster biedt. Een van (maar niet de enige) onderscheidende kenmerken van ARDFS is dat het geen extra speciale servers gebruikt voor metadata en beheer. Dit was oorspronkelijk bedoeld om de configuratie van de oplossing te vereenvoudigen en de betrouwbaarheid ervan te vergroten.
Opslagstructuur
Binnen alle knooppunten van het cluster organiseert ARDFS een logische pool van alle beschikbare schijfruimte. Het is belangrijk om te begrijpen dat een pool nog geen gegevens of geformatteerde ruimte is, maar eenvoudigweg markup, d.w.z. Alle knooppunten waarop vAIR is geïnstalleerd, worden, wanneer ze aan het cluster worden toegevoegd, automatisch toegevoegd aan de gedeelde ARDFS-pool en schijfbronnen worden automatisch gedeeld door het hele cluster (en beschikbaar voor toekomstige gegevensopslag). Met deze aanpak kunt u knooppunten direct toevoegen en verwijderen zonder ernstige gevolgen voor het reeds draaiende systeem. Die. het systeem is zeer eenvoudig “in stenen” op te schalen, waarbij indien nodig knooppunten in het cluster kunnen worden toegevoegd of verwijderd.
Bovenop de ARDFS-pool worden virtuele schijven (opslagobjecten voor virtuele machines) toegevoegd, die zijn opgebouwd uit virtuele blokken van 4 megabytes groot. Virtuele schijven slaan gegevens rechtstreeks op. Het fouttolerantieschema wordt ook ingesteld op het niveau van de virtuele schijf.
Zoals je misschien al geraden hebt, gebruiken we voor fouttolerantie van het schijfsubsysteem niet het concept van RAID (Redundant array of independent Disks), maar gebruiken we RAIN (Redundant array of independent Nodes). Die. Fouttolerantie wordt gemeten, geautomatiseerd en beheerd op basis van de knooppunten, niet op de schijven. Schijven zijn natuurlijk ook een opslagobject, ze worden, net als al het andere, bewaakt, je kunt er alle standaardbewerkingen mee uitvoeren, inclusief het samenstellen van een lokale hardware-RAID, maar het cluster werkt specifiek op knooppunten.
In een situatie waarin je echt RAID wilt (bijvoorbeeld een scenario dat meerdere fouten op kleine clusters ondersteunt), weerhoudt niets je ervan om lokale RAID-controllers te gebruiken en daarbovenop uitgebreide opslag en een RAIN-architectuur te bouwen. Dit scenario is behoorlijk live en wordt door ons ondersteund, dus we zullen erover praten in een artikel over typische scenario's voor het gebruik van vAIR.
Schema's voor opslagfouttolerantie
Er kunnen twee fouttolerantieschema's zijn voor virtuele schijven in vAIR:
1) Replicatiefactor of simpelweg replicatie - deze methode van fouttolerantie is zo simpel als een stok en een touw. Er wordt synchrone replicatie uitgevoerd tussen knooppunten met een factor 2 (respectievelijk 2 exemplaren per cluster) of 3 (respectievelijk 3 exemplaren). RF-2 zorgt ervoor dat een virtuele schijf bestand is tegen het falen van één knooppunt in het cluster, maar ‘vreet’ de helft van het bruikbare volume op, en RF-3 is bestand tegen het falen van twee knooppunten in het cluster, maar reserveert 2/2 van het bruikbare volume. bruikbaar volume voor zijn behoeften. Dit schema lijkt sterk op RAID-3, dat wil zeggen dat een virtuele schijf geconfigureerd in RF-1 bestand is tegen het falen van een willekeurig knooppunt in het cluster. In dit geval komt alles goed met de gegevens en stopt zelfs de I/O niet. Wanneer het gevallen knooppunt weer in gebruik wordt genomen, begint het automatische gegevensherstel/synchronisatie.
Hieronder vindt u voorbeelden van de distributie van RF-2- en RF-3-gegevens in de normale modus en in een storingssituatie.
Wij beschikken over een virtuele machine met een capaciteit van 8MB aan unieke (nuttige) data, die draait op 4 vAIR-nodes. Het is duidelijk dat het in werkelijkheid onwaarschijnlijk is dat er zo'n klein volume zal zijn, maar voor een schema dat de logica van de ARDFS-werking weerspiegelt, is dit voorbeeld het meest begrijpelijk. AB zijn virtuele blokken van 4 MB die unieke virtuele machinegegevens bevatten. RF-2 maakt respectievelijk twee kopieën van deze blokken A1+A2 en B1+B2. Deze blokken worden over de knooppunten heen “opgemaakt”, waarbij de kruising van dezelfde gegevens op hetzelfde knooppunt wordt vermeden. Dat wil zeggen dat kopie A1 zich niet op hetzelfde knooppunt zal bevinden als kopie A2. Hetzelfde geldt voor B1 en B2.
Als een van de knooppunten faalt (bijvoorbeeld knooppunt nr. 3, dat een kopie van B1 bevat), wordt deze kopie automatisch geactiveerd op het knooppunt waar geen kopie van de kopie aanwezig is (dat wil zeggen een kopie van B2).
De virtuele schijf (en dienovereenkomstig de VM) kan dus gemakkelijk het falen van één knooppunt in het RF-2-schema overleven.
Het replicatieschema, hoewel eenvoudig en betrouwbaar, kampt met hetzelfde probleem als RAID1: niet genoeg bruikbare ruimte.
2) Wiscodering of wiscodering (ook bekend als “redundante codering”, “wiscodering” of “redundantiecode”) bestaat om het bovenstaande probleem op te lossen. EC is een redundantieschema dat een hoge beschikbaarheid van gegevens biedt met minder overhead op de schijfruimte in vergelijking met replicatie. Het werkingsprincipe van dit mechanisme is vergelijkbaar met RAID 5, 6, 6P.
Bij het coderen verdeelt het EC-proces een virtueel blok (standaard 4 MB) in verschillende kleinere "databrokken", afhankelijk van het EC-schema (een 2+1-schema verdeelt bijvoorbeeld elk blok van 4 MB in 2 brokken van 2 MB). Vervolgens genereert dit proces ‘pariteitsbrokken’ voor de ‘databrokken’ die niet groter zijn dan een van de eerder verdeelde delen. Bij het decoderen genereert EC de ontbrekende stukjes door de ‘overlevende’ gegevens over het hele cluster te lezen.
Een virtuele schijf met een 2 + 1 EC-schema, geïmplementeerd op 4 clusterknooppunten, zal bijvoorbeeld gemakkelijk het falen van één knooppunt in het cluster weerstaan, op dezelfde manier als RF-2. In dit geval zullen de overheadkosten lager zijn, met name de nuttige capaciteitscoëfficiënt voor RF-2 is 2 en voor EC 2+1 1,5.
Om het eenvoudiger te beschrijven: de essentie is dat het virtuele blok is verdeeld in 2-8 (waarom van 2 naar 8, zie hieronder) "stukken", en voor deze stukken worden "stukken" van pariteit met een vergelijkbaar volume berekend.
Als gevolg hiervan worden gegevens en pariteit gelijkmatig verdeeld over alle knooppunten van het cluster. Tegelijkertijd verdeelt ARDFS, net als bij replicatie, automatisch gegevens over knooppunten, zodat wordt voorkomen dat identieke gegevens (kopieën van gegevens en hun pariteit) op hetzelfde knooppunt worden opgeslagen, om de kans op gegevensverlies als gevolg van gegevensverlies te elimineren. aan het feit dat de gegevens en hun pariteit plotseling op één opslagknooppunt terechtkomen dat uitvalt.
Hieronder ziet u een voorbeeld, met dezelfde virtuele machine van 8 MB en 4 knooppunten, maar met een EC 2+1-schema.
Blokken A en B zijn verdeeld in twee stukken van elk 2 MB (twee omdat 2+1), dat wil zeggen A1+A2 en B1+B2. In tegenstelling tot een replica is A1 geen kopie van A2, maar een virtueel blok A, verdeeld in twee delen, hetzelfde als blok B. In totaal krijgen we twee sets van 4 MB, die elk twee stukken van twee MB bevatten. Vervolgens wordt voor elk van deze sets de pariteit berekend met een volume van niet meer dan één stuk (d.w.z. 2 MB), we verkrijgen een extra + 2 pariteitsstukken (AP en BP). In totaal hebben we 4×2 data + 2×2 pariteit.
Vervolgens worden de stukken tussen de knooppunten "uitgelegd", zodat de gegevens hun pariteit niet kruisen. Die. A1 en A2 bevinden zich niet op hetzelfde knooppunt als AP.
In het geval van een storing van één knooppunt (bijvoorbeeld ook het derde), wordt het gevallen blok B1 automatisch hersteld vanuit de BP-pariteit, die is opgeslagen op knooppunt nr. 2, en wordt geactiveerd op het knooppunt waar sprake is van geen B-pariteit, d.w.z. stukje BP. In dit voorbeeld is dit knooppunt nr. 1
Ik weet zeker dat de lezer een vraag heeft:
"Alles wat u beschrijft, wordt al lang geïmplementeerd, zowel door concurrenten als in open source-oplossingen. Wat is het verschil tussen uw implementatie van EC in ARDFS?"
En dan zullen er interessante kenmerken van ARDFS zijn.
Wiscodering met de nadruk op flexibiliteit
In eerste instantie hebben we een tamelijk flexibel EC X+Y-schema geboden, waarbij X gelijk is aan een getal van 2 tot en met 8, en Y gelijk is aan een getal van 1 tot en met 8, maar altijd kleiner dan of gelijk aan X. Dit schema is voorzien voor flexibiliteit. Door het aantal datastukken (X) waarin het virtuele blok is verdeeld te vergroten, kunnen de overheadkosten worden verlaagd, dat wil zeggen de bruikbare ruimte worden vergroot.
Het verhogen van het aantal pariteitssegmenten (Y) verhoogt de betrouwbaarheid van de virtuele schijf. Hoe groter de Y-waarde, hoe meer knooppunten in het cluster kunnen falen. Het vergroten van het pariteitsvolume vermindert uiteraard de hoeveelheid bruikbare capaciteit, maar dit is een prijs die moet worden betaald voor de betrouwbaarheid.
De afhankelijkheid van de prestaties van EC-circuits is vrijwel direct: hoe meer “stukken”, hoe lager de prestaties; hier is uiteraard een evenwichtige kijk nodig.
Met deze aanpak kunnen beheerders uitgebreide opslag met maximale flexibiliteit configureren. Binnen de ARDFS-pool kunt u alle fouttolerantieschema's en hun combinaties gebruiken, wat naar onze mening ook erg handig is.
Hieronder vindt u een tabel waarin verschillende (niet alle mogelijke) RF- en EC-schema's met elkaar worden vergeleken.
De tabel laat zien dat zelfs de meest “badstof” combinatie EC 8+7, die het verlies van maximaal 7 knooppunten in een cluster tegelijkertijd mogelijk maakt, minder bruikbare ruimte “in beslag neemt” (1,875 versus 2) dan standaardreplicatie, en 7 keer beter beschermt , wat dit beschermingsmechanisme, hoewel complexer, veel aantrekkelijker maakt in situaties waarin het nodig is om maximale betrouwbaarheid te garanderen in omstandigheden met beperkte schijfruimte. Tegelijkertijd moet u begrijpen dat elk “pluspunt” van X of Y een extra prestatieoverhead zal zijn, dus in de driehoek tussen betrouwbaarheid, besparingen en prestaties moet u zeer zorgvuldig kiezen. Om deze reden zullen we een apart artikel wijden aan de grootte van de wiscodering.
Betrouwbaarheid en autonomie van het bestandssysteem
ARDFS draait lokaal op alle knooppunten van het cluster en synchroniseert deze op eigen wijze via speciale Ethernet-interfaces. Het belangrijke punt is dat ARDFS niet alleen de gegevens onafhankelijk synchroniseert, maar ook de metagegevens met betrekking tot opslag. Terwijl we aan ARDFS werkten, bestudeerden we tegelijkertijd een aantal bestaande oplossingen en we ontdekten dat velen de meta van het bestandssysteem synchroniseren met behulp van een extern gedistribueerd DBMS, dat we ook gebruiken voor synchronisatie, maar alleen configuraties, geen FS-metagegevens (over dit en andere gerelateerde subsystemen in het volgende artikel).
Het synchroniseren van FS-metagegevens met behulp van een extern DBMS is natuurlijk een werkende oplossing, maar dan zou de consistentie van de gegevens die zijn opgeslagen op ARDFS afhangen van het externe DBMS en zijn gedrag (en eerlijk gezegd is het een wispelturige dame), die in onze mening is slecht. Waarom? Als de FS-metagegevens beschadigd raken, kan er ook afscheid worden genomen van de FS-gegevens zelf. Daarom hebben we besloten een complexer maar betrouwbaarder pad te volgen.
We hebben het metadatasynchronisatiesubsysteem voor ARDFS zelf gemaakt en het leeft volledig onafhankelijk van aangrenzende subsystemen. Die. geen enkel ander subsysteem kan ARDFS-gegevens beschadigen. Naar onze mening is dit de meest betrouwbare en correcte manier, maar de tijd zal leren of dit ook daadwerkelijk zo is. Bovendien is er nog een bijkomend voordeel aan deze aanpak. ARDFS kan onafhankelijk van vAIR worden gebruikt, net als stretched storage, die we zeker zullen gebruiken in toekomstige producten.
Als gevolg hiervan hebben we door de ontwikkeling van ARDFS een flexibel en betrouwbaar bestandssysteem gekregen dat de keuze biedt waar u kunt besparen op capaciteit of alles kunt opgeven op het gebied van prestaties, of ultrabetrouwbare opslag kunt maken tegen redelijke kosten, maar de prestatie-eisen kunt verlagen.
Samen met een eenvoudig licentiebeleid en een flexibel leveringsmodel (vAIR wordt per node gelicentieerd en als software of als softwarepakket geleverd), waardoor u de oplossing zeer nauwkeurig kunt afstemmen op een breed scala aan klantvereisten en behoud dan gemakkelijk dit evenwicht.
Wie heeft dit wonder nodig?
Aan de ene kant kunnen we zeggen dat er al spelers op de markt zijn die serieuze oplossingen hebben op het gebied van hyperconvergentie, en dit is waar we eigenlijk naartoe gaan. Het lijkt erop dat deze bewering waar is, MAAR...
Aan de andere kant, als we de velden in gaan en met klanten communiceren, zien wij en onze partners dat dit helemaal niet het geval is. Er zijn veel taken voor hyperconvergentie, op sommige plaatsen wisten mensen eenvoudigweg niet dat dergelijke oplossingen bestonden, op andere leek het duur, op andere waren er mislukte tests van alternatieve oplossingen, en op andere plaatsen verbieden ze kopen helemaal vanwege sancties. Over het algemeen bleek het veld niet geploegd te zijn, dus gingen we maagdelijke grond ophogen))).
Wanneer is een opslagsysteem beter dan GCS?
Terwijl we met de markt werken, wordt ons vaak gevraagd wanneer het beter is om een klassiek schema met opslagsystemen te gebruiken, en wanneer hyperconvergent? Veel bedrijven die GCS produceren (vooral degenen die geen opslagsystemen in hun portfolio hebben) zeggen: “Opslagsystemen raken verouderd, ze zijn alleen maar hypergeconvergeerd!” Dit is een gewaagde uitspraak, maar weerspiegelt niet geheel de werkelijkheid.
In werkelijkheid evolueert de opslagmarkt inderdaad richting hyperconvergentie en soortgelijke oplossingen, maar er is altijd een ‘maar’.
Ten eerste kunnen datacenters en IT-infrastructuren die zijn gebouwd volgens het klassieke schema met opslagsystemen niet gemakkelijk worden herbouwd, dus de modernisering en voltooiing van dergelijke infrastructuren is nog steeds een erfenis van 5 tot 7 jaar.
Ten tweede wordt de infrastructuur die momenteel voor het grootste deel wordt gebouwd (dat wil zeggen de Russische Federatie) gebouwd volgens het klassieke schema met behulp van opslagsystemen, en niet omdat mensen niets weten over hyperconvergentie, maar omdat de hyperconvergentiemarkt nieuw is, oplossingen en standaarden zijn nog niet vastgesteld, IT-mensen zijn nog niet opgeleid, ze hebben weinig ervaring, maar ze moeten hier en nu datacenters bouwen. En deze trend zal nog 3-5 jaar aanhouden (en dan nog een erfenis, zie punt 1).
Ten derde is er een puur technische beperking in de extra kleine vertragingen van 2 milliseconden per schrijfbewerking (uiteraard exclusief de lokale cache), wat de kosten zijn van gedistribueerde opslag.
Laten we het gebruik van grote fysieke servers die dol zijn op verticale schaalvergroting van het schijfsubsysteem niet vergeten.
Er zijn veel noodzakelijke en populaire taken waarbij opslagsystemen zich beter gedragen dan GCS. Hier zullen de fabrikanten die geen opslagsystemen in hun productportfolio hebben het natuurlijk niet met ons eens zijn, maar we zijn bereid om redelijk te argumenteren. Uiteraard zullen wij, als ontwikkelaars van beide producten, opslagsystemen en GCS zeker vergelijken in een van onze toekomstige publicaties, waar we duidelijk zullen aantonen welke beter is onder welke omstandigheden.
En waar zullen hypergeconvergeerde oplossingen beter werken dan opslagsystemen?
Op basis van bovenstaande punten kunnen drie voor de hand liggende conclusies worden getrokken:
- Waar een extra latentie van 2 milliseconden voor opname, die consequent in elk product voorkomt (nu hebben we het niet over synthetische stoffen, op synthetische stoffen kunnen nanoseconden worden weergegeven), niet kritisch is, is hyperconvergent geschikt.
- Waar de belasting van grote fysieke servers kan worden omgezet in vele kleine virtuele servers en kan worden verdeeld over knooppunten, zal hyperconvergentie daar ook goed werken.
- Waar horizontaal schalen een hogere prioriteit heeft dan verticaal schalen, zal GCS het daar ook prima doen.
Wat zijn deze oplossingen?
- Alle standaardinfrastructuurdiensten (directoryservice, mail, EDMS, fileservers, kleine of middelgrote ERP- en BI-systemen, enz.). We noemen dit 'algemeen computergebruik'.
- De infrastructuur van cloudproviders, waar het nodig is om snel en gestandaardiseerd horizontaal uit te breiden en eenvoudig een groot aantal virtuele machines voor klanten te ‘knippen’.
- Virtuele desktopinfrastructuur (VDI), waar veel virtuele machines voor kleine gebruikers draaien en stilletjes ‘zweven’ binnen een uniform cluster.
- Filiaalnetwerken, waarbij elke vestiging een standaard, fouttolerante, maar goedkope infrastructuur van 15-20 virtuele machines nodig heeft.
- Elke gedistribueerde computer (bijvoorbeeld big data-services). Waar de last niet ‘in de diepte’ gaat, maar ‘in de breedte’.
- Testomgevingen waar extra kleine vertragingen acceptabel zijn, maar er zijn budgetbeperkingen, omdat dit tests zijn.
Op dit moment hebben we voor deze taken AERODISK vAIR gemaakt en daarop concentreren we ons (tot nu toe met succes). Wellicht komt hier binnenkort verandering in, want... de wereld staat niet stil.
Zo…
Hiermee is het eerste deel van een grote reeks artikelen voltooid; in het volgende artikel zullen we het hebben over de architectuur van de oplossing en de gebruikte componenten.
Wij verwelkomen vragen, suggesties en constructieve geschillen.
Bron: www.habr.com