nga St-Pete
Përshëndetje të gjithëve! Unë jam Mons Anderson, arkitekt i platformës , do të flas për mënyrën se si ndërtuam ruajtjen tonë S3, si funksionon ajo, cilat zgjidhje ishin të suksesshme dhe cilat do të kishim ndryshuar nëse do të fillonim një projekt të tillë nga zero tani.
Artikulli është përgatitur mbi bazën e një prezantimi në nga Mail.ru Cloud Solutions & Tarantool. Në artikull do të flasim për:
- si ishte ndërtuar ruajtja e Mail.ru, mbi të cilën ndërtuam ruajtjen S3;
- çfarë shtuam për të krijuar Mail.ru Cloud Storage;
- si funksionon modeli i ruajtjes objektuale dhe cilat hapa janë ndjekur për të kaluar në prodhim;
- për përmirësimet e sistemit operativ: dështimi dhe shkallëzimi;
- si e realizuam ndarjen dhe rishpërndarjen;
- si dhe për punën me certifikatat SSL.
Nëse nuk dëshironi të lexoni, mund të .
Si ishte ndërtuar ruajtja e Mail.ru, mbi të cilën ndërtuam ruajtjen S3
Zhvillimi i S3-tonë filloi mbi ruajtjen e Oblaqeve Mail.ru, prandaj fillimisht duhet të flasim për mënyrën se si është ndërtuar dhe çfarë mund të bëjë.
Ruajtja e oblakut Mail.ru pĂ«rbĂ«het nga servera me disqe. NĂ« mesatarje, njĂ« server storage modern ka 36 disqe prej 12â14 terabajtĂ«sh. MĂ« parĂ«, disqet ishin mĂ« tĂ« vogla, por pĂ«r tre vjet, kapaciteti i disqeve Ă«shtĂ« rritur dhe sot arrin pothuajse njĂ« pĂ«r tĂ« dhĂ«nat e papĂ«rpunuara.
Disqet nga serverat e ndryshëm të ruajtjes bashkohen në ato që quhen "çifti" (pair). Një çift është njësi e vetme për ruajtjen e skedarëve. Në thelb, është një disk i montuar në një seksion të caktuar në një rrugë të caktuar, ku mund të ndodhen skedarë të identifikuar me hash.
Ăifti Ă«shtĂ« njĂ« emĂ«r historik, qĂ« Ă«shtĂ« ruajtur deri sot, megjithĂ«se tani nĂ« njĂ« çift nuk ka domosdoshmĂ«risht vetĂ«m dy disqe. Mund tĂ« ketĂ« tre disqe dhe gjithashtu mund tĂ« ketĂ« ruajtje tĂ« ndryshme hibride, pĂ«r shembull 3/2.
Ăifti (pair) â njĂ«sitĂ« e ruajtjes sĂ« objekteve
TĂ« gjitha çifti ruajten nĂ« PairDB â kjo Ă«shtĂ« njĂ« aplikacion i bazuar nĂ« Tarantool. TĂ« gjitha bazat nĂ« ruajtjen tonĂ«, duke filluar nga ato mĂ« tĂ« para, janĂ« Tarantool; ne nuk pĂ«rdorim baza tĂ« tjera.
PairDB ruan të gjitha çifti, gjendjet e tyre, hapësirat e lira, mundësitë e dështimit dhe gabimet e fundit. Ajo gjithashtu mund të hyjë në çifti vetë, të përditësojë gjendjen e tyre, të kontrollojë nëse ato funksionojnë apo jo. Pra, PairDB është një pamje e përgjithshme e gjendjes së të gjithë disqeve në sistemin tonë.
Pair DB: baza e të dhënave me gjendjen e çifteve
NĂ« çifti ruajten skedarĂ« dhe, pĂ«r tĂ« ditur se nĂ« cilin çift ndodhet cila skedar, ne kemi nevojĂ« pĂ«r njĂ« bazĂ« tjetĂ«r â FileDB. Ajo ruan mapimin, pĂ«rcaktimin e lidhjes: skedari i tillĂ« ruhet nĂ« çiftin e tillĂ«, si dhe njĂ« sasi tĂ« vogĂ«l atributesh tĂ« nevojshme.
File DB: vendi ku ruhet skedari
Një tjetër element i rëndësishëm është shërbimi Nylon, një ruter për punën me të dhënat. Ai është pika e vetme e hyrjes, duke lejuar të punoni përmes një ndërfaqe të vetme si me PairDB ashtu edhe me FileDB. Ky është një shërbim pa shtet, ai bën balancimin e kërkesave, kupton se në cilin shard FileDB duhet të shkohet dhe di se cilat çifti janë aktivë e cilat jo.
Nylon: ruter për punën me të dhënat
Gjithashtu nĂ« ruajtje duhet tĂ« vendosim ndonjĂ« pĂ«rmbajtje. PĂ«r kĂ«tĂ« ka njĂ« shĂ«rbim â Streamer. Ai ofron dy metoda HTTP: metoda PUT, pĂ«r tĂ« ngarkuar pĂ«rmbajtje nĂ« ruajtje, dhe metoda GET, pĂ«r ta marrĂ« atĂ«. HTTP Ă«shtĂ« njĂ« protokoll mjaft popullor dhe i pĂ«rshtatshĂ«m pĂ«r transferimin e tĂ« dhĂ«nave.
Kur ne drejtohemi te Streamerâi, ai pĂ«rmes Nylon-i drejton njĂ« kĂ«rkesĂ« nĂ« PairDB, ku qĂ« mund tĂ« ngarkohet skedari, pas sĂ« cilĂ«s dĂ«rgon tĂ« dhĂ«nat pĂ«rmes WebDAV nĂ« kĂ«tĂ« çift.
Në thelb, çdo server ruajtës është nginx plus disqe që janë të montuar në rrugë të caktuara. Ne mund të ngarkojmë një skedar në ruajtje nga Streamer, ta fshijmë, ta ripërkufizojmë ose ta kontrollojmë për integritet. Pra, kjo është një ndërfaqe e përshtatshme për ndërveprimin e ulët me ruajtjen.
Streamer: pika e hyrjes në ruajtje
ĂfarĂ« shtuam pĂ«r tĂ« bĂ«rĂ« ruajtjen S3
Pra, ne shqyrtuam ndërtimin bazë të ruajtjes në momentin kur ne kishim për të nisur ruajtjen S3. Me metodën PUT, ne mund të vendosim përmbajtje të rastësishme dhe të marrim si identifikues të këtyre të dhënave një hash. Me këtë identifikues, më vonë mund të rikthehesh dhe të merrni skedarin origjinal. Por kjo nuk është e mjaftueshme për të realizuar S3. Në protokollin S3, përveç ruajtjes së objekteve, ka:
- ruajtja e meta tĂ« dhĂ«nave â pronave shtesĂ« tĂ« objekteve;
- organizimi i qasjeve në objekte përmes HTTP;
- grupimi i objekteve nĂ« koleksione â barek;
- HTTP-S3 Endpoint. S3 organizon tĂ« dhĂ«nat nĂ« struktura tĂ« caktuara â barek, secila prej tĂ« cilave ofron njĂ« pikĂ« hyrje pĂ«r ruajtjen e skedarĂ«ve.
Për të realizuar këtë logjikë, ishte e nevojshme një shërbim i veçantë. Poashtu donim të mendonim në fillim për arkitekturën për rritjen e shërbimit me shkallëzim linear.
Komponentët e parë
Demon, i cili realizon S3 API. Ky është standardi S3 API i Amazon, i cili mbështet funksionimin me XML për metadatat dhe lejon transferimin e drejtpërdrejtë të përmbajtjes. Nuk na duhej të shpiknim diçka, gjithçka është e përshkruar dhe e dokumentuar.
Po ashtu, para shërbimit vendosëm Nginx. E përdorëm atë për terminimin e SSL, balancimin e ngarkesës, si dhe për disa logjikë në Lua (metrika, regjistrimi dhe gjurmimi).
Për ruajtjen e metadatatëve S3, ne zgjodhëm gjithashtu Tarantool. Në versionin e parë, demon S3 i kërkonte këto të dhëna në këtë bazë, ndërsa përmbajtja vetë ruhesha në një depo të madhe përmes Streamer.
Nginx + S3 API + metadatat
Modeli objektor i ruajtjes
Le tĂ« shohim se si funksionon S3. PĂ«rdoruesi mund tĂ« krijojĂ« njĂ« bucket â njĂ« koleksion objektesh. Bucket adresohet me emrin e hostit dhe Ă«shtĂ« njĂ« subdomen i shĂ«rbimit. Brenda bucket-it, pĂ«rdoruesi mund tĂ« krijojĂ« objekte. Identifikuesi i objektit do tĂ« jetĂ« URL. PĂ«rmbajtja e objektit Ă«shtĂ« njĂ« blob, njĂ« array tĂ« dhĂ«nash binare, tĂ« cilat do tâi ruajmĂ« nĂ« depo. Po ashtu, objekti ka atribute: emri â ai vetĂ« URL, ACL (lista e kontrollit tĂ« aksesit), atribute tĂ« tjera shtesĂ« ose tĂ« rastĂ«sishme â gjithçka ruhen nĂ« metadatat.
Schemi normale e këtyre të dhënave mund të duket kështu: ka projekte që kanë bucket-e, që kanë objekte dhe objektet mund të jenë kompozita. Pasi një nga mënyrat për të ngarkuar objektet është në pjesë, për ngarkimin ekzistojnë dy tabela ndihmëse: uploads dhe chunks. Po ashtu, projektet kanë kredenciale për akses dhe faturim.
Schema e të dhënave
Pasi bëmë një shërbim b2b me qasje të paguar, në këtë skemë na duheshin faturimi.
Shërbimin e faturimit e realizuam gjithashtu në Tarantool.
Përmirësimet e S3 depo: hapat drejt prodhimit
Kemi krijuar një model funksional, të cilin mund ta përdorim: objektet dhe metadatat ruheshin, por për të dalë në prodhim mungonin disa aspekte.
Së pari, sistemi i rregullimeve të normave. Nëse e startojmë shërbimin pa të, në ngarkesa pikore mund të mbingarkohej ndonjë pjesë e sistemit. Rregullimi i normave duhet të punojë kështu: çdo kërkesë S3 vjen në një host specifik, ky host është identifikuesi i bucket-it, dhe bucket-i përket ndonjë klienti. Na nevojitet të përcaktojmë një funksion nga bucket-i, i cili do të na lejojë të llogarisim rregullimin e normave.
Përveç kësaj, sistemi i rregullimeve të normave duhet të jetë mjaft produktiv për të përballuar ngarkesën që vjen në S3.
PĂ«r kĂ«to pĂ«rdorĂ«m pĂ«rsĂ«ri Tarantool. Rregullimet e normave janĂ« njĂ« klaster prej 21 instancash, instancat janĂ« tĂ« shpĂ«rndara nĂ« grupe, tĂ« ndara nĂ« tri nyje fizike dhe tĂ« bashkuara nĂ« njĂ« klaster tĂ« madh topologjik. NĂ« tĂ« pĂ«rhapet automatikisht ndryshimet konfiguruese: caktuesit e rregullimeve, tĂ« dhĂ«nat e parazgjedhura dhe konfigurimi. Ădo bucket trajtohet nĂ« mĂ«nyrĂ« strikte nga njĂ« instancĂ«. Kur njĂ« kĂ«rkesĂ« vjen pĂ«r njĂ« bucket tĂ« caktuar, llogaritet instanca pĂ«rgjegjĂ«se pĂ«r atĂ« bucket. Brenda kĂ«saj nyjeje bĂ«het llogaritja e normĂ«s aktuale tĂ« kĂ«rkesave sipas njĂ« algoritmi tĂ« ngjashĂ«m me Token Bucket. MĂ« pas, sistemi i rregullimeve tĂ« normave, nĂ« bazĂ« tĂ« parametrave aktualĂ« tĂ« ngarkesĂ«s dhe veçorive tĂ« caktuara pĂ«r bucket-in e caktuar, tregon nĂ«se kĂ«rkesa mund tĂ« ekzekutohet apo jo. Kontrolli i limitit bĂ«het nĂ« fazĂ«n mĂ« tĂ« hershme tĂ« ekzekutimit tĂ« kĂ«rkesĂ«s S3, duke mbrojtur tĂ« gjitha elementet e tjera tĂ« sistemit nga mbingarkesa.
Po ashtu, nën ngarkesë është mjaft e vështirë të kalosh pa keq. Në S3 supozohet se duhen bërë shumë kërkesa për të njëjtat objekte, pra ky është një depo e nxehtë. Në rastin normal, një kërkesë për një skedar të vetëm trajtohet nga e gjithë zinxhiri: Streamer, FileDB, PairDB, Storage. Por kur bëhen shumë kërkesa për një skedar, ne optimizojmë qasjen në këtë përmbajtje nëpërmjet një cache lokal.
Cache-i është shumë-njësor dhe realizohet përmes nginx, SSD dhe RAM diskëve lokalë. Këtu nuk përdorëm Tarantool, sepse dorëzimi i objekteve është më i lehtë nga sistemi i skedarëve, kështu që mund të bëjmë tirazh të cache-it. Për më tepër, ne kemi objekte të mëdha me dimensionin maksimal prej 32 gigabajt, dhe në Tarantool mund të cache-osh vetëm objekte të vogla.
Ky ishte sistemi i parë, me të cilin kërkuam, që kishte një kapacitet të llogaritur, e cila mjaftoi për hulumtimin, për të kuptuar produktin, se do të funksiononte.
Përmirësimet e sistemit në punë: failover dhe shkallëzim
Sistemi ishte tashmĂ« nĂ« punĂ«, por nĂ« fillim ne humbĂ«m disa detaje â duhej tĂ« shtonim failover dhe shkallĂ«zim.
Demoni ynĂ« S3 kĂ«rkoi metadatat me protokollin Tarantool. NĂ« vend tĂ« bazĂ«s origjinale, instaluam Tarantool, i cili vepronte si njĂ« router proxy pĂ«r kĂ«rkesat pĂ«r metadatat. Nga perspektiva e aplikacionit qĂ« implementonte API-nĂ«, nuk ndryshoi asgjĂ« â vazhdoi tĂ« bĂ«nte kĂ«rkesat nĂ« bazĂ« me protokollin Tarantool, por routeri siguroi njĂ« aktivizim tĂ« dĂ«shtimit. KĂ«shtu, mundĂ«m tĂ« kontrollonim disponueshmĂ«rinĂ« e nodit, tĂ« mbanim njĂ« pauzĂ« gjatĂ« kalimeve dhe dĂ«shtimeve, etj. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, nuk e modifikuam aplikacionin vetĂ«.
Më shumë detaje rreth mënyrës si realizuam shardimin
Pyetja tjetër që duhej të merrej parasysh ishte shredimi. Sistemi po rritej, numri i objekteve po rritej dhe ne duhej të siguronim mundësi për rritje të mëtejshme.
Le të kthehemi te skema e të dhënave: ka projekte, ka bakete, kredenciale dhe faturim. Këto janë objekte që me shumë probabilitet në të ardhmen e afërt nuk do të rriten përtej një instance as për nga volumi, as për nga kërkesat. Kështu, nuk ka kuptim t'i shardojmë ato dhe ne i transferuam në një instancë të veçantë, e cila do të mbetet pa shardim. Kjo lejon menaxhim më konsistent të projekteve dhe baketeve, pasi ka një pikë të vetme pa shardim.
Po ashtu, nĂ« skemĂ« ka objekte qĂ« rriten nĂ« mĂ«nyrĂ« lineare â fillimisht ishin qindra mijĂ«ra, tani numri i tyre matet nĂ« disa miliarda. KĂ«to objekte, sĂ« bashku me pjesĂ«t e tyre, duhej tĂ« migronin nĂ« njĂ« grup tĂ« sharduar.
E ndamë skemën, por objektet kanë nevojë të punojnë me baketet: çdo objekt i përket një baketi të caktuar, plus në baket funksionon ACL. Prandaj, për çdo shard me objekte mbajmë një kopje të errët të çdo baketi. Për më tepër, gjatë modifikimit të objekteve dhe kryerjes së kërkesave, nevojitet të llogaritet volumi për të realizuar faturimin, kështu që në çdo shard ka numërues nga faturimi.
Po ashtu, ne shtuam disa tabela dhe komponente të tjera:
- kosha, për shkatërrimin e projekteve të vjetra që fshihen ose ngrijnë;
- radhë për detyrat në sfond, dmth, ruajtja kryesore mund të realizojë detyra në sfond që nevojiten të bëhen në grup;
- mbĂ«shtetje pĂ«r lifecycle â njĂ« mekanizĂ«m qĂ« lejon punĂ«n me objekte, duke menaxhuar ciklin e jetĂ«s sĂ« tyre.
Duke qenë se disa të dhëna i transferuam në sharde, nevojitej një proxy shardimi. Ka qenë e mundur të ripërdoret routeri për këtë rol, por një proxy e veçantë për shardim, e cila merret vetëm me shardimin e të dhënave, lejon që routeri të kërkojë të dhënat në tërësi, pa menduar për shardimin.
Do të flas veçmas për arsyen se pse nuk morëm një zgjidhje të gatshme dhe dëshiruam të bëjmë një funksion personal të shardimit.
Le tĂ« shohim se si Ă«shtĂ« strukturuar. Ne kemi 256 sharde tĂ« disponueshme. PĂ«r çdo baket, ne strukurojmĂ« njĂ« gamĂ« duke pĂ«rdorur njĂ« funksion konsistent. ĂshtĂ« e thjeshtĂ« â ashtu siç definoni, me njĂ« funksion konsistent, pĂ«rkatĂ«sinĂ« pĂ«r njĂ« shard, pĂ«rcaktoni shardin fillestar dhe ndajnĂ« gamĂ«n:
f(bucket, shards) = subset
Kështu, nëse marrim baketin, mund të themi se ai dhe të dhënat e tij do të jenë gjithmonë në një nëngrup të caktuar nga të gjithë shardet. Kjo ndihmon në pakësimin e ndikimit të baketeve të ndryshme mbi njëra-tjetrën dhe në thjeshtimin e punës me kërkesat map-reduce, kur nevojitet, për shembull, të listojmë objektet e baketit. Për këtë, duhet të anketojmë të gjitha shardet ku këto objekte ruhen. Nëse objektet do ishin në të gjitha shardet, çdo listim do të godiste sistemin në tërësi, ndërsa këtu godet vetëm një nëngrup të caktuar.
Pastaj, çdo objekt i përket një baketi të caktuar, kështu që kur kërkohemi për një objekt, ne kërkojmë për objektin me emrin në baketin specifik. Pra, mund të përcaktojmë një funksion për objektin jo nga e gjithë gama e shardeve, por vetëm nga nëngrupi i baketit të tij:
f(object, subset) = shard
Ne marrim objektin specifik, si argumente tĂ« funksionit ne futim jo tĂ« gjithĂ« shardet, por nĂ«ngrupin e baketit tĂ« tij â dhe marrim shardin e caktuar.
Tani, shredimi Ă«shtĂ« realizuar, ka njĂ« proxy shardimi. MĂ« pas, mbetet vetĂ«m qĂ« nga routeri dhe baza e tĂ« dhĂ«nave me metadata tĂ« lidhemi me proxy-in e shardimit. PĂ«r shembull, pĂ«r krijimin e objekteve tĂ« kopjeve tĂ« errta â kur krijojmĂ« njĂ« baket, ruajtja kryesore duhet tĂ« krijojĂ« njĂ« pĂ«rfaqĂ«sues tĂ« kĂ«tij baketi nĂ« tĂ« gjithĂ« shardet ku ai duhet tĂ« jetĂ« i pranishĂ«m.
Si e realizuam rikthimin e shardimit
Problemi më i madh me shardimin është rikthimi i shardimit. Ishte e rëndësishme për ne ta bënim këtë pa kohë të ndaluar, pasi sistemi tashmë ishte në prodhim. Do të tregoj se si e zgjidhëm problemin në shembullin e një detyre të ngjashme me migërimin e gjallë të të dhënave nga një projekt në një tjetër.
Më poshtë është skema e klasterit tonë, e cila u krijua pas implementimit të sharding. Ne kemi nginx, S3 API, një router, bazën kryesore me projektet, një proxy sharding dhe vetë shardet.
Më sipër kam lënë jashtë momentin se në një fazë të caktuar të projektit kishte një detyrë produkti: "Të niste një depo tjetër, Icebox, - si Hotbox, vetëm për të dhënat e ftohta". Në thelb, një depo e ngjashme, por me URL të tjera dhe pa cache.
Icebox u përdor më pak se Hotbox, prandaj ai kaloi një kohë të gjatë pa asnjë sharding. Në fund, ne vendosëm ta heqim atë dhe të bashkojmë Hotbox dhe Icebox në një shërbim, thjesht duke ndarë klasat e ruajtjes.
Bucket në depo nuk ishin të ndërthurura, ato mund të merreshin lehtësisht dhe të shkrinin bashkë, por klientët përdornin si njëri ashtu edhe tjetrin depo, prandaj duhej të zgjidhim problemin e mungesës së downtime. Nuk mund të thjesht fiknim dhe të kopjonim. Ne bëmë migrimin në disa etapa.
Për fillim, ne synchimizuam depo kryesore. Ne kishim Tarantool dhe mund të bënim në krijimin e një objekti:
- baza merr një kërkesë për të krijuar një bucket, për shembull në Hotbox;
- Tarantool kontrollet në një bazë tjetër (në këtë rast - në Icebox), që nuk ekziston asnjë bucket i tillë;
- nëse bucket ekziston, baza thotë se nuk mund të krijohet dhe ai është sinkronizuar si ekzistues.
Sinkronizimi i buckets
Në atë depo, e cila duhet të merrte të gjitha të dhënat, u fut një atribut për projektet dhe buckets që thoshte se ku ruhej ky objekt. Ai mund të ruhej lokal, pra në Hotbox, në Icebox - atëherë në depo të re nuk ka asnjë të dhënë, ose mund të jetë në gjendjen e migrimit.
Nëse një projekti ose bucket kishte atributin Migrating, atëherë gjatë migrimit kërkesa kryhej fillimisht në depo të re, ku duhet të ishin të dhënat, dhe nëse ato nuk ishin atje, kërkesat përcilleshin në depo alternative.
Më pas ne ndryshuam trafikun. Meqë API mund të shërbejë dhe kërkesat për Icebox, dhe kërkesat për Hotbox, ne arritëm të ndryshojmë trafikun pa downtime, thjesht duke transferuar hostet dhe duke shtuar regjistrimet përkatëse në Nginx.
Pas transferimit të trafikut, Nginx dhe API nga Icebox mund të hiqeshin.
Më pas heqëm Icebox nginx dhe S3 API - dhe gjithçka filloi të funksionojë:
Më pas filluam një proces të prapshëm migrimi, i cili punonte brenda bazës - ndjek çdo projekt dhe buckets e tij, vendos atributin Migrating për ta, transferon të dhënat dhe pas përfundimit të transferimit vendos atributin Local.
Pas transferimit të të dhënave nuk na nevojitet më depo e vjetër, dhe ne heqim pjesët e mbetura të sistemit të vjetër, si dhe heqim nga kodi mbështetje për statusin e migrimit.
Sipas të njëjtave principe u realizua dhe reshërdimi nga depoja e vjetër në të sharding:
- Kemi shënuar të gjitha buckets si
Non-sharded. Të gjitha kërkesat për to shkonin në depo origjinale, që nuk ishte sharded. - Buckets e reja krijoheshin menjëherë në statusin
Sharded. - Marim një në një buckets, vendosim statusin
Migratingdhe transferojmë të dhënat.
Kërkesat në këtë rast shërbehen sipas parimit:
- Lexojmë në të re, pastaj në të vjetra.
- Krijojmë vetëm në të re.
- Përditësojmë në dy faza: nëse nuk ka në të re, transferojmë nga e vjetra në të re, pastaj përditësojmë.
Puna me certifikatat SSL
Në frontend përdorim Nginx. Në rastin tonë, ky nuk është Nginx i zakonshëm, por OpenResty, Nginx me mbështetje për LuaJIT.
Një pjesë tjetër e sistemit është puna me certifikatat SSL. Në depo S3 mund të vendosni një domen tuaj për qasje në një bucket të veçantë, thjesht përmes CNAME. Por pa HTTPS sot nuk është e mundur: një domen tuaj sugjeron një certifikatë SSL tuaj.
Siç e kam thënë më parë, për balancimin dhe përfundimin e SSL përgjigjet Nginx. Në rastin tonë, ky nuk është Nginx i zakonshëm, por OpenResty, Nginx me mbështetje për LuaJIT.
Kjo na lejon të mësojmë mjaft lehtë Nginx tonë për të ofruar certifikata të ndryshme. Dhe na nevojitej t'i ofronim certifikatat dinamikisht (pa nevojën për t'i shkruar në dosjen e konfigurimit). Ne përdorëm zgjerimin ssl_certificate_by_lua, i cili lejon të lexoni certifikatën nga një burim të rastësishëm gjatë TLS-handshake. Si depo e certifikatave, ne gjithashtu morëm Tarantool: kjo na lejon të menaxhojmë certifikatat nga jashtë dhe siguron një përgjigje shumë të shpejtë.
Gjithashtu u realizua njĂ« demon i veçantĂ«, me detyrĂ« pĂ«r tĂ« pĂ«rditĂ«suar rregullisht certifikatat, tĂ« cilat ishin lĂ«shuar pĂ«rmes Letâs Encrypt.
ĂfarĂ« do tĂ« mbaja, dhe çfarĂ« do tĂ« bĂ«ja ndryshe nĂ«se do tĂ« zhvilloja depo nga e para
ĂfarĂ« duhej tĂ« ishte pĂ«rdorur qĂ« nĂ« fillim
Sharding menjĂ«herĂ«. Ka pasur shumĂ« probleme me shardingun. ĂshtĂ« e lehtĂ« tĂ« bĂ«het, por megjithatĂ«, nĂ«se filloni projekte qĂ« nevojiten pĂ«r tâu shkallĂ«zuar, Ă«shtĂ« mĂ« mirĂ« tĂ« merrni menjĂ«herĂ« njĂ« klaster tĂ« sharduar, ndonĂ«se me numrin minimal tĂ« nyjave. Zbatimi i shardingut nĂ« fillim Ă«shtĂ« pothuajse falas krahasuar me integrimin e shardingut nĂ« njĂ« sistem nĂ« punĂ«.
Puna me Tarantool përmes balancuesve. Aktualisht, ne lidhemi me të gjitha bazat e reja direkt nëpërmjet balancuesve. Kjo lejon zgjerimin e funksionalitetit dhe arritjen e një qëndrueshmërie më të madhe.
Auto-failover. Do të instalonim të gjitha mjetet që kërkohen për auto-failover, pasi dështimet e para pas lançimit ishin të lidhura me mungesën e tij. Pas përvojës me S3, të gjithë produktet e ardhshme u lançuan duke e mbajtur këtë në mend.
Karakteristika S3 "Versionimi". Fillimisht dukej se kjo funksionalitet nuk ishte shumë i kërkuar. Integraimi i kësaj mundësie në arkitekturën e një sistemi në punë është jashtëzakonisht i vështirë.
Billing i veçantë. Menyxhimi i faturimit në sistemin tonë tregoi rezultate të mira në fillim, por më vonë u bë pengesë, do të ishte më mirë ta kishim si një shërbim plotësisht të veçantë.
ĂfarĂ« ishte njĂ« vendim i suksesshĂ«m
Modeli i të dhënave. Historia tregon se ndërsa shërbimi evoluoi, ne përputheshim mjaft saktë me modelin e të dhënave të Amazon-it, prandaj mund të realizonim ato karakteristika që janë aty.
Schema e shardingut. Do ta mbështesja ndarjen e njëjtë të shardingut nëpër bucket-e, pasi kjo lejon shpërndarjen e mirë të kërkesave nga bucket-et e ndryshme në një klaster të madh.
Përdorimi i Tarantool. Tarantool ndihmoi shumë në zhvillimin dhe modifikimin e shërbimit, ne punonim lehtësisht me të dhënat, transformonim dhe shardonim fondin, pa pasur nevojë të kalonim në nivelin e aplikacionit.
Ky raport u shpërnda për herë të parë në nga Mail.ru Cloud Solutions&Tarantool. Shikoni prezantime të tjera dhe abonohuni për njoftimet mbi ngjarjet në Telegram .
Gjithashtu mund të shihni prezantimin tim të vjetër mbi S3 ose të lexoni artikullin e kolegut tim mbi ruajtjen me bllok.
- .
- .
Burimi: habr.com
