Sveiki, Habr skaitytojai. Šiuo straipsniu atidarome seriją, kurioje bus kalbama apie mūsų sukurtą hiperkonverguotą sistemą AERODISK vAIR. Iš pradžių norėjome apie viską papasakoti pirmame straipsnyje, bet sistema gana sudėtinga, todėl dramblį valgysime dalimis.
Pradėkime pasakojimą nuo sistemos sukūrimo istorijos, pasigilinkime į ARDFS failų sistemą, kuri yra vAIR pagrindas, taip pat šiek tiek pakalbėkime apie šio sprendimo pozicionavimą Rusijos rinkoje.
Kituose straipsniuose plačiau kalbėsime apie skirtingus architektūrinius komponentus (klasteris, hipervizorius, apkrovos balansavimo priemonė, stebėjimo sistema ir kt.), konfigūravimo procesą, kelsime licencijavimo problemas, atskirai parodysime avarijų testus ir, žinoma, rašysime apie apkrovos testavimą ir dydžio nustatymas. Taip pat atskirą straipsnį skirsime vAIR bendruomenės versijai.
Ar „Aerodisk“ yra istorija apie saugojimo sistemas? Arba kodėl mes iš pradžių pradėjome daryti hiperkonvergenciją?
Iš pradžių idėja sukurti savo hiperkonvergenciją mums kilo maždaug 2010 m. Tuo metu rinkoje nebuvo nei Aerodisk, nei panašių sprendimų (komercinių dėžučių hiperkonverguotų sistemų). Mūsų užduotis buvo tokia: iš serverių rinkinio su vietiniais diskais, sujungtų per Ethernet protokolą, reikėjo sukurti išplėstinę saugyklą ir ten paleisti virtualias mašinas bei programinės įrangos tinklą. Visa tai teko įgyvendinti be saugojimo sistemų (nes tiesiog nebuvo pinigų saugojimo sistemoms ir jų techninei įrangai, o savo saugojimo sistemų dar nebuvome išradę).
Išbandėme daugybę atvirojo kodo sprendimų ir galiausiai išsprendėme šią problemą, tačiau sprendimas buvo labai sudėtingas ir sunkiai pakartojamas. Be to, šis sprendimas buvo priskirtas kategorijai „Ar tai veikia? Nelieskite! Todėl išsprendę šią problemą toliau neplėtojome idėjos savo darbo rezultatą paversti visaverčiu produktu.
Po to incidento mes nuo šios minties nutolome, bet vis tiek jautėmės, kad ši problema visiškai išsprendžiama, o tokio sprendimo nauda buvo daugiau nei akivaizdi. Vėliau užsienio kompanijų HCI produkcija tik patvirtino šį jausmą.
Todėl 2016 m. viduryje grįžome prie šios užduoties, kurdami visavertį produktą. Tuo metu dar neturėjome jokių santykių su investuotojais, todėl už savo ne itin didelius pinigus teko įsigyti plėtros stendą. Surinkę naudotus serverius ir Avito jungiklius, ėmėmės darbo.
Pagrindinė pradinė užduotis buvo sukurti savo, nors ir paprastą, bet savo failų sistemą, kuri galėtų automatiškai ir tolygiai paskirstyti duomenis virtualių blokų pavidalu n-tame klasterio mazgų, kurie yra sujungti jungtimi per Ethernet, skaičių. Tuo pačiu metu FS turėtų gerai ir lengvai keistis bei būti nepriklausoma nuo gretimų sistemų, t.y. būti susvetimiems nuo vAIR kaip „tik saugykla“.
Pirmoji vAIR koncepcija
Sąmoningai atsisakėme paruoštų atvirojo kodo sprendimų, skirtų ištemptam saugojimui organizuoti (ceph, gluster, luster ir panašiai), savo plėtrai, nes jau turėjome su jais daug projektų patirties. Žinoma, patys šie sprendimai yra puikūs, ir prieš dirbdami su Aerodisk su jais įgyvendinome ne vieną integracijos projektą. Tačiau vienas dalykas yra įgyvendinti konkrečią užduotį vienam klientui, apmokyti darbuotojus ir, galbūt, nusipirkti didelio pardavėjo palaikymą, o visai kas kita – sukurti lengvai atkartojamą produktą, kuris bus naudojamas įvairioms užduotims, kurias mes, kaip pardavėjas, galbūt net nežinosime apie save. Antram tikslui esami atvirojo kodo produktai mums netiko, todėl nusprendėme patys sukurti paskirstytą failų sistemą.
Po dvejų metų keli kūrėjai (sujungę darbą su vAIR su klasikinės variklio saugojimo sistemos darbu) pasiekė tam tikrą rezultatą.
Iki 2018 metų buvome parašę paprastą failų sistemą ir papildėme ją reikiama technine įranga. Sistema per vidinį sujungimą sujungė fizinius (vietinius) diskus iš skirtingų serverių į vieną plokščią baseiną ir „supjaustė“ į virtualius blokus, tada iš virtualių blokų buvo sukurti blokiniai įrenginiai su įvairaus laipsnio atsparumu gedimams, ant kurių buvo sukurti virtualūs. ir įvykdytas naudojant KVM hipervizorinius automobilius.
Mes per daug nesijaudinome dėl failų sistemos pavadinimo ir glaustai pavadinome ją ARDFS (atspėk, ką tai reiškia))
Šis prototipas atrodė gerai (žinoma, ne vizualiai, vizualinio dizaino dar nebuvo) ir parodė gerus rezultatus našumo ir mastelio atžvilgiu. Po pirmojo realaus rezultato mes paleidome šį projektą, suorganizuodami visavertę kūrimo aplinką ir atskirą komandą, kuri užsiėmė tik vAIR.
Kaip tik iki to laiko subrendo bendra sprendimo architektūra, kuri dar nepatyrė didelių pokyčių.
Nardymas ARDFS failų sistemoje
ARDFS yra vAIR pagrindas, kuris suteikia paskirstytą, gedimams atsparią duomenų saugyklą visame klasteryje. Viena iš (bet ne vienintelė) išskirtinių ARDFS savybių yra ta, kad metaduomenims ir tvarkymui nenaudojami jokie papildomi dedikuoti serveriai. Iš pradžių tai buvo sukurta siekiant supaprastinti sprendimo konfigūraciją ir užtikrinti jo patikimumą.
Sandėliavimo struktūra
Visuose klasterio mazguose ARDFS organizuoja loginį telkinį iš visos turimos vietos diske. Svarbu suprasti, kad baseinas dar nėra duomenys ar suformatuota erdvė, o tiesiog žymėjimas, t.y. Visi mazgai su įdiegta vAIR, kai jie pridedami prie klasterio, automatiškai pridedami prie bendrinamo ARDFS telkinio, o disko ištekliai automatiškai tampa bendrinami visame klasteryje (ir galimi ateityje saugoti duomenis). Šis metodas leidžia pridėti ir pašalinti mazgus be jokio rimto poveikio jau veikiančiai sistemai. Tie. Sistemą labai lengva suskirstyti į plytas, prireikus pridedant arba pašalinant mazgus klasteryje.
Virtualūs diskai (virtualiųjų mašinų saugojimo objektai) pridedami prie ARDFS telkinio, kurie yra sukurti iš 4 megabaitų virtualių blokų. Virtualūs diskai tiesiogiai saugo duomenis. Gedimų tolerancijos schema taip pat nustatyta virtualaus disko lygiu.
Kaip jau galėjote atspėti, disko posistemio gedimams toleruoti nenaudojame RAID (nepriklausomų diskų perteklinis masyvas), o RAIN (nepriklausomų mazgų perteklinis masyvas). Tie. Gedimų tolerancija matuojama, automatizuota ir valdoma remiantis mazgais, o ne diskais. Diskai, žinoma, yra ir saugojimo objektas, jie, kaip ir visa kita, yra stebimi, su jais galima atlikti visas standartines operacijas, įskaitant ir vietinio aparatūros RAID surinkimą, tačiau klasteris veikia būtent mazguose.
Esant tokiai situacijai, kai tikrai norite RAID (pavyzdžiui, scenarijus, palaikantis kelis gedimus mažose grupėse), niekas netrukdo naudoti vietinių RAID valdiklių ir sukurti ištemptą saugyklą bei RAIN architektūrą. Šis scenarijus yra gana gyvas ir jį palaikome, todėl apie jį kalbėsime straipsnyje apie tipinius vAIR naudojimo scenarijus.
Saugyklos gedimų tolerancijos schemos
VAIR gali būti dvi virtualių diskų gedimų tolerancijos schemos:
1) Replikacijos koeficientas arba tiesiog replikacija – šis atsparumo gedimams metodas yra toks pat paprastas kaip lazda ir virvė. Sinchroninis replikavimas atliekamas tarp mazgų, kurių koeficientas yra 2 (2 kopijos viename klasteryje) arba 3 (atitinkamai 3 kopijos). RF-2 leidžia virtualiam diskui atlaikyti vieno klasterio mazgo gedimą, tačiau „suvalgo“ pusę naudingo tūrio, o RF-3 atlaikys 2 klasterio mazgų gedimą, tačiau pasilieka 2/3 naudingo tūrio jos poreikiams. Ši schema yra labai panaši į RAID-1, tai yra, virtualus diskas, sukonfigūruotas RF-2, yra atsparus bet kurio klasterio mazgo gedimui. Tokiu atveju su duomenimis viskas bus gerai ir net I/O nesustos. Kai nukritęs mazgas grįš į paslaugą, prasidės automatinis duomenų atkūrimas / sinchronizavimas.
Žemiau pateikiami RF-2 ir RF-3 duomenų paskirstymo įprastu režimu ir gedimo atveju pavyzdžiai.
Turime virtualią mašiną su 8MB unikalių (naudingų) duomenų talpa, kuri veikia 4 vAIR mazgais. Aišku, kad realybėje vargu ar bus tokia maža apimtis, bet schemai, kuri atspindi ARDFS veikimo logiką, šis pavyzdys yra labiausiai suprantamas. AB yra 4 MB virtualūs blokai, kuriuose yra unikalių virtualios mašinos duomenų. RF-2 sukuria atitinkamai dvi šių blokų kopijas A1+A2 ir B1+B2. Šie blokai yra „išdėstyti“ per mazgus, vengiant tų pačių duomenų susikirtimo tame pačiame mazge, ty kopija A1 nebus tame pačiame mazge kaip kopija A2. Tas pats su B1 ir B2.
Jei vienas iš mazgų sugenda (pavyzdžiui, mazgas Nr. 3, kuriame yra B1 kopija), ši kopija automatiškai suaktyvinama mazge, kuriame nėra jo kopijos (ty B2 kopijos).
Taigi virtualus diskas (ir atitinkamai VM) gali lengvai išgyventi vieno mazgo gedimą RF-2 schemoje.
Replikacijos schema, nors ir paprasta ir patikima, kenčia nuo tos pačios problemos kaip ir RAID1 – nepakanka naudingos vietos.
2) Ištrynimo kodavimas arba trynimo kodavimas (taip pat žinomas kaip „perteklinis kodavimas“, „ištrynimo kodavimas“ arba „perteklinis kodas“) egzistuoja, kad išspręstų aukščiau pateiktą problemą. EC yra atleidimo schema, užtikrinanti didelį duomenų prieinamumą ir mažesnę disko vietos sąnaudą, palyginti su replikacija. Šio mechanizmo veikimo principas panašus į RAID 5, 6, 6P.
Koduojant EC procesas padalija virtualų bloką (pagal nutylėjimą 4 MB) į keletą mažesnių "duomenų gabalų", priklausomai nuo EC schemos (pavyzdžiui, schema 2+1 padalija kiekvieną 4 MB bloką į 2 2 MB dalis). Be to, šis procesas generuoja „duomenų gabalų“ paritetus, kurie yra ne didesni už vieną iš anksčiau padalytų dalių. Dekoduodamas EC generuoja trūkstamus gabalus, nuskaitydamas „išlikusius“ duomenis visame klasteryje.
Pavyzdžiui, virtualus diskas su 2 + 1 EC schema, įdiegtas 4 klasterio mazguose, lengvai atlaikys vieno klasterio mazgo gedimą taip pat, kaip ir RF-2. Tokiu atveju pridėtinės sąnaudos bus mažesnės, ypač naudingo pajėgumo koeficientas RF-2 yra 2, o EC 2+1 - 1,5.
Paprasčiau apibūdinti, esmė ta, kad virtualus blokas yra padalintas į 2-8 (kodėl nuo 2 iki 8, žr. toliau) „gabalėlius“ ir šiems gabalams apskaičiuojami panašaus tūrio pariteto „gabalai“.
Dėl to duomenys ir paritetas yra tolygiai paskirstomi visuose klasterio mazguose. Tuo pačiu metu, kaip ir replikuojant, ARDFS automatiškai paskirsto duomenis tarp mazgų taip, kad tame pačiame mazge nebūtų saugomi identiški duomenys (duomenų kopijos ir jų paritetas), kad būtų išvengta duomenų praradimo. į tai, kad duomenys ir jų paritetas staiga atsidurs viename sugedusiame saugojimo mazge.
Žemiau pateikiamas pavyzdys su ta pačia 8 MB virtualia mašina ir 4 mazgais, bet su EC 2+1 schema.
Blokai A ir B yra padalinti į dvi dalis po 2 MB (du, nes 2+1), tai yra A1+A2 ir B1+B2. Skirtingai nuo replikos, A1 nėra A2 kopija, tai yra virtualus blokas A, padalintas į dvi dalis, tas pats su bloku B. Iš viso gauname du 4MB rinkinius, kurių kiekviename yra po du dviejų MB gabalus. Toliau kiekvienam iš šių rinkinių paritetas apskaičiuojamas, kai tūris yra ne didesnis kaip vienas gabalas (t. y. 2 MB), gauname papildomus + 2 pariteto gabalus (AP ir BP). Iš viso turime 4×2 duomenis + 2×2 paritetą.
Tada gabalai „išdėstomi“ tarp mazgų, kad duomenys nesikirstų su jų paritetu. Tie. A1 ir A2 nebus tame pačiame mazge kaip AP.
Sugedus vienam mazgui (pavyzdžiui, ir trečiam), nukritęs blokas B1 bus automatiškai atkurtas iš BP pariteto, kuris saugomas mazge Nr. 2, ir bus aktyvuotas mazge, kuriame yra nėra B pariteto, t.y. BP gabalas. Šiame pavyzdyje tai yra mazgas Nr. 1
Esu tikras, kad skaitytojui kyla klausimas:
„Viskas, ką apibūdinote, jau seniai buvo įdiegta tiek konkurentų, tiek atvirojo kodo sprendimuose. Kuo skiriasi jūsų EC diegimas ARDFS?
Ir tada bus įdomių ARDFS funkcijų.
Ištrinkite kodavimą, sutelkiant dėmesį į lankstumą
Iš pradžių pateikėme gana lanksčią EC X+Y schemą, kur X yra lygus skaičiui nuo 2 iki 8, o Y lygus skaičiui nuo 1 iki 8, bet visada mažesnis arba lygus X. Ši schema pateikiama už lankstumą. Duomenų vienetų (X), į kuriuos padalintas virtualus blokas, skaičiaus padidinimas leidžia sumažinti pridėtines išlaidas, tai yra padidinti naudingą erdvę.
Padidinus pariteto dalių (Y) skaičių, padidėja virtualaus disko patikimumas. Kuo didesnė Y reikšmė, tuo daugiau mazgų klasteryje gali sugesti. Žinoma, padidinus pariteto apimtį, sumažėja naudingos talpos kiekis, tačiau tai yra kaina, kurią reikia mokėti už patikimumą.
Veikimo priklausomybė nuo EC grandinių yra beveik tiesioginė: kuo daugiau „gabalų“, tuo mažesnis našumas; čia, žinoma, reikia subalansuoto požiūrio.
Šis metodas leidžia administratoriams maksimaliai lanksčiai konfigūruoti ištemptą saugyklą. ARDFS baseine galite naudoti bet kokias gedimų tolerancijos schemas ir jų derinius, o tai, mūsų nuomone, taip pat labai naudinga.
Žemiau yra lentelė, kurioje palyginamos kelios (ne visos galimos) RF ir EB schemos.
Lentelėje matyti, kad net pats „kiltinis“ derinys EC 8+7, leidžiantis vienu metu prarasti iki 7 mazgų klasteryje, „suvalgo“ mažiau naudingos vietos (1,875, palyginti su 2) nei standartinė replikacija ir apsaugo 7 kartus geriau. , todėl šis apsaugos mechanizmas, nors ir sudėtingesnis, yra daug patrauklesnis situacijose, kai reikia užtikrinti maksimalų patikimumą esant ribotai vietai diske. Tuo pačiu metu jūs turite suprasti, kad kiekvienas „pliusas“ prie X ar Y bus papildomos veiklos sąnaudos, todėl patikimumo, taupymo ir našumo trikampyje reikia rinktis labai atsargiai. Dėl šios priežasties trynimo kodo dydžio nustatymui skirsime atskirą straipsnį.
Failų sistemos patikimumas ir savarankiškumas
ARDFS veikia lokaliai visuose klasterio mazguose ir sinchronizuoja juos naudodamas savo priemones per tam skirtas Ethernet sąsajas. Svarbu tai, kad ARDFS savarankiškai sinchronizuoja ne tik duomenis, bet ir su saugojimu susijusius metaduomenis. Dirbdami su ARDFS, vienu metu ištyrėme daugybę esamų sprendimų ir pastebėjome, kad daugelis sinchronizuoja failų sistemos meta naudodami išorinę paskirstytą DBVS, kurią taip pat naudojame sinchronizavimui, bet tik konfigūracijas, o ne FS metaduomenis (apie šią ir kitas susijusias posistemes). kitame straipsnyje).
FS metaduomenų sinchronizavimas naudojant išorinę DBVS, žinoma, yra veikiantis sprendimas, tačiau tada ARDFS saugomų duomenų nuoseklumas priklausytų nuo išorinės DBVS ir jos elgesio (o, atvirai kalbant, tai kaprizinga ponia), kuri mūsų nuomonė bloga. Kodėl? Jei FS metaduomenys bus sugadinti, patys FS duomenys taip pat gali būti pasakyti „sudie“, todėl nusprendėme pasirinkti sudėtingesnį, bet patikimesnį kelią.
Mes patys sukūrėme ARDFS metaduomenų sinchronizavimo posistemį ir jis veikia visiškai nepriklausomai nuo gretimų posistemių. Tie. jokia kita posistemė negali sugadinti ARDFS duomenų. Mūsų nuomone, tai yra patikimiausias ir teisingiausias būdas, tačiau laikas parodys, ar taip yra iš tikrųjų. Be to, šis metodas turi papildomų pranašumų. ARDFS gali būti naudojamas nepriklausomai nuo vAIR, kaip ištempta saugykla, kurią tikrai naudosime būsimuose gaminiuose.
Dėl to, kurdami ARDFS, gavome lanksčią ir patikimą failų sistemą, kuri suteikia galimybę sutaupyti talpos arba atsisakyti visko dėl našumo, arba sukurti itin patikimą saugyklą už priimtiną kainą, tačiau sumažinant našumo reikalavimus.
Kartu su paprasta licencijavimo politika ir lanksčiu pristatymo modeliu (žvelgiant į ateitį, vAIR licencijuoja mazgas ir tiekiamas kaip programinė įranga arba kaip programinės įrangos paketas), tai leidžia labai tiksliai pritaikyti sprendimą pagal įvairius klientų poreikius ir tada nesunku išlaikyti šią pusiausvyrą.
Kam reikalingas šis stebuklas?
Viena vertus, galime teigti, kad rinkoje jau yra žaidėjų, kurie turi rimtų sprendimų hiperkonvergencijos srityje, ir čia mes iš tikrųjų einame. Atrodo, kad šis teiginys yra teisingas, BET...
Kita vertus, kai išeiname į laukus ir bendraujame su klientais, mes ir mūsų partneriai matome, kad taip nėra. Hiperkonvergencijos užduočių yra daug, kai kur žmonės tiesiog nežinojo, kad tokie sprendimai egzistuoja, kitur atrodė brangu, kitur buvo nesėkmingi alternatyvių sprendimų bandymai, o kitur dėl sankcijų apskritai draudžiama pirkti. Apskritai laukas pasirodė nesuartas, todėl nuėjome auginti neapdorotą dirvą))).
Kada saugojimo sistema yra geresnė nei GKS?
Kai dirbame su rinka, mūsų dažnai klausia, kada su saugojimo sistemomis geriau naudoti klasikinę schemą, o kada naudoti hiperkonvergentinę? Daugelis įmonių, gaminančių GCS (ypač tos, kurių portfelyje nėra saugojimo sistemų) sako: „Saugojimo sistemos pasensta, tik hiperkonverguojamos! Tai drąsus teiginys, tačiau jis nevisiškai atspindi tikrovę.
Tiesą sakant, saugyklų rinka iš tiesų juda link hiperkonvergencijos ir panašių sprendimų, tačiau visada yra „bet“.
Pirma, duomenų centrai ir IT infrastruktūros, pastatytos pagal klasikinę schemą su saugojimo sistemomis, negali būti lengvai atkuriamos, todėl tokių infrastruktūrų modernizavimas ir užbaigimas vis dar yra 5-7 metų palikimas.
Antra, didžioji dalis šiuo metu kuriamos infrastruktūros (turima omenyje Rusijos Federacija) yra kuriama pagal klasikinę schemą naudojant saugojimo sistemas ir ne todėl, kad žmonės nežinotų apie hiperkonvergenciją, o todėl, kad hiperkonvergencijos rinka yra nauja, sprendimai ir standartai dar nenustatyti , IT žmonės dar neapmokyti, turi mažai patirties, bet duomenų centrus reikia kurti čia ir dabar. Ir ši tendencija tęsis dar 3–5 metus (o tada – kitas palikimas, žr. 1 punktą).
Trečia, yra grynai techninis apribojimas, susijęs su papildomu nedideliu 2 milisekundžių vėlavimu vienam įrašymui (žinoma, išskyrus vietinę talpyklą), o tai yra paskirstytos saugyklos kaina.
Na, nepamirškime apie didelių fizinių serverių, kurie mėgsta vertikalų disko posistemio mastelį, naudojimą.
Yra daug reikalingų ir populiarių užduočių, kuriose saugojimo sistemos veikia geriau nei GCS. Čia, žinoma, tie gamintojai, kurių produktų portfelyje nėra saugojimo sistemų, su mumis nesutiks, tačiau esame pasirengę argumentuotai ginčytis. Žinoma, mes, kaip abiejų produktų kūrėjai, tikrai palyginsime saugojimo sistemas ir GCS viename iš savo būsimų leidinių, kur aiškiai parodysime, kuri kokiomis sąlygomis yra geriau.
O kur hiperkonverguoti sprendimai veiks geriau nei saugojimo sistemos?
Remiantis aukščiau išdėstytais punktais, galima padaryti tris akivaizdžias išvadas:
- Ten, kur papildomos 2 milisekundės įrašymo delsos, kurios nuolat pasitaiko bet kuriame gaminyje (dabar nekalbame apie sintetiką, nanosekundės gali būti rodomos ant sintetikos), yra nekritiškos, tinka hiperkonvergentas.
- Ten, kur didelių fizinių serverių apkrovą galima paversti daugybe mažų virtualių ir paskirstyti tarp mazgų, hiperkonvergencija ten taip pat puikiai veiks.
- Jei horizontalus mastelio keitimas yra didesnis prioritetas nei vertikalus mastelio keitimas, GCS taip pat puikiai tiks.
Kokie tai sprendimai?
- Visos standartinės infrastruktūros paslaugos (katalogų paslauga, paštas, EDMS, failų serveriai, mažos ar vidutinės ERP ir BI sistemos ir kt.). Mes tai vadiname „bendraisiais skaičiavimais“.
- Debesų tiekėjų infrastruktūra, kur reikia greitai ir standartizuotai horizontaliai išplėsti ir lengvai „iškirpti“ daugybę virtualių mašinų klientams.
- Virtualios darbalaukio infrastruktūra (VDI), kurioje veikia daug mažų naudotojų virtualių mašinų ir tyliai „plaukioja“ vienodame klasteryje.
- Filialų tinklai, kur kiekvienai šakai reikalinga standartinė, gedimams atspari, bet nebrangi 15-20 virtualių mašinų infrastruktūra.
- Bet koks paskirstytasis kompiuteris (pavyzdžiui, didelių duomenų paslaugos). Kur krovinys eina ne „į gylį“, o „į plotį“.
- Testavimo aplinkos, kuriose yra priimtini papildomi nedideli vėlavimai, tačiau yra biudžeto apribojimų, nes tai yra bandymai.
Šiuo metu būtent šioms užduotims mes sukūrėme AERODISK vAIR ir būtent į jas orientuojamės (kol kas sėkmingai). Galbūt tai greitai pasikeis, nes... pasaulis nestovi vietoje.
Taigi…
Taip užbaigiama pirmoji didelės straipsnių serijos dalis; kitame straipsnyje kalbėsime apie sprendimo architektūrą ir naudojamus komponentus.
Laukiame klausimų, pasiūlymų ir konstruktyvių ginčų.
Šaltinis: www.habr.com