ProHoster > Blog > Administrim > Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Përshëndetje, habrovcanë. Sot fillojnë mësimet në grupin e parë të kursit «PostgreSQL». Për këtë arsye, duam të flasim me ju për webinarin e hapur që u mbajt për këtë kurs.

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Në mësimi i hapur të radhës diskutuar për sfidat që kanë hasur bazat e të dhënave SQL në epokën e cloud dhe Kubernetes. Po ashtu, shqyrtuam si bazat e të dhënave SQL përshtaten dhe transformohen nën ndikimin e këtyre sfidave.

Webinari u drejtua nga Valeriy Bezrukov, Menaxher i Praktikës së Dërgimit Cloud në EPAM Systems.

Kur pemët ishin të vogla...

Së pari, le të kujtojmë se si filloi zgjedhja e DBMS në fund të shekullit të kaluar. Megjithatë, kjo nuk do të jetë e vështirë, sepse zgjedhja e DBMS në atë kohë fillonte dhe përfundonte Oracle.

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Në fund të viteve '90 - fillimi të viteve 2000, nuk kishte shumë zgjedhje, në thelb, për sa i përket DB të shkallëzueshme industriale. Po, ekzistonin IBM DB2, Sybase dhe disa baza të tjera të dhënash që shfaqeshin dhe zhdukeshin, por në tërësi ato nuk ishin aq të dukshme përballë Oracle. Si rezultat, aftësitë e inxhinierëve të asaj kohe ishin në një farë forme të lidhura me atë zgjedhje të vetme që ekzistonte.

Dhe një Oracle DBA duhet të dinte se si:

  • tĂ« instalonte Oracle Server nga distribuimi;
  • tĂ« konfiguronte Oracle Server:

  • init.ora;
  • listener.ora;

të krijonte:

  • hapĂ«sira tabelash;
  • skemat;
  • pĂ«rdoruesit;

të kryente kopje rezervë dhe rikuperim;
të bënte monitorim;
të luftonte me kërkesat jo optimale.

Në këtë mënyrë, nga Oracle DBA nuk kërkohej shumë:

  • tĂ« dinte tĂ« zgjidhte DBMS-in optimal ose njĂ« teknologji tjetĂ«r pĂ«r ruajtjen dhe pĂ«rpunimin e tĂ« dhĂ«nave;
  • tĂ« sigurojĂ« disponueshmĂ«rinĂ« e lartĂ« dhe shkallĂ«zimin horizontal (kjo nuk ishte gjithmonĂ« njĂ« çështje pĂ«r DBA);
  • tĂ« njihte mirĂ« fushĂ«n pĂ«rkatĂ«se, infrastrukturĂ«n, arkitekturĂ«n aplikative, sistemin operativ;
  • tĂ« realizonte ngarkimin dhe shkarkimin e tĂ« dhĂ«nave, migrimin e tĂ« dhĂ«nave midis DB tĂ« ndryshme.

Në tërësi, kur flasim për zgjedhjen në atë kohë, ajo përngjason me zgjedhjen në një dyqan sovjetik në fund të viteve '80:

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Koha jonë

Që nga atëherë, sigurisht, pemët janë rritur, bota ka ndryshuar, dhe gjërat janë bërë siç janë:

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Tregu i DBMS është ndryshuar gjithashtu, gjë që është shumë e dukshme nga raporti i fundit i kompanisë Gartner:

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Dhe kĂ«tu nuk mund tĂ« mos pĂ«rmendet se njĂ« niĆŸĂ« e re Ă«shtĂ« zĂ«nĂ« nga cloud, tĂ« cilat po rriten nĂ« popullaritet. NĂ«se e lexoni tĂ« njĂ«jtin raport tĂ« kompanisĂ« Gartner, do tĂ« shihni kĂ«to pĂ«rfundime:

  1. Shumë klientë janë në rrugën për të transferuar aplikacionet në cloud.
  2. Teknologjitë e reja shfaqen së pari në cloud dhe nuk është e sigurt se ato ndonjëherë do të kalojnë në një infrastrukturë jo-cloud.
  3. Modeli i çmimit sipas parimit pay-as-you-go është bërë i zakonshëm. Të gjithë dëshirojnë të paguajnë vetëm për atë që përdorin, dhe kjo tashmë nuk është vetëm një trend, por një konstatim i faktit.

ÇfarĂ« ndodhi tani?

Sot të gjithë jemi në cloud. Dhe pyetjet që kemi janë pyetje zgjedhjeje. Dhe ajo zgjedhje është e madhe, edhe nëse flasim vetëm për zgjedhjen e teknologjive DBMS në formatin On-premises. Po ashtu kemi shërbime të menaxhuara dhe SaaS. Kështu, zgjedhja vetëm sa komplikohet çdo vit.

Përveç pyetjeve të zgjedhjes, veprojnë gjithashtu faktorët kufizues:

  • çmimi. ShumĂ« teknologji ende kushtojnĂ« para;
  • aftĂ«sitĂ«. NĂ«se flasim pĂ«r softuerin e lirĂ«, atĂ«herĂ« lind pyetja e aftĂ«sive, pasi softueri falas kĂ«rkon nga njerĂ«zit, qĂ« e implementojnĂ« dhe e pĂ«rdorin, kompetencĂ« tĂ« mjaftueshme;
  • funksionaliteti. Jo tĂ« gjitha shĂ«rbimet qĂ« janĂ« nĂ« cloud dhe janĂ« ndĂ«rtuar, le tĂ« themi, edhe mbi bazĂ«n e Postgres, kanĂ« ato karakteristika qĂ« ka Postgres On-premises. Ky Ă«shtĂ« njĂ« faktor thelbĂ«sor qĂ« duhet tĂ« dihet dhe kuptohet. PĂ«r mĂ« tepĂ«r, ky faktor merr njĂ« rĂ«ndĂ«si edhe mĂ« tĂ« madhe se njohuria e ndonjĂ« mundĂ«sie tĂ« fshehtĂ« tĂ« njĂ« DBMS tĂ« veçantĂ«.

ÇfarĂ« presin tani nga DA/DE:

  • njĂ« kuptim tĂ« mirĂ« tĂ« fushĂ«s dhe arkitekturĂ«s aplikative;
  • aftĂ«sinĂ« pĂ«r tĂ« zgjedhur teknologjinĂ« e pĂ«rshtatshme DBMS duke marrĂ« parasysh detyrĂ«n e vendosur;
  • aftĂ«sinĂ« pĂ«r tĂ« zgjedhur metodĂ«n optimale tĂ« implementimit tĂ« teknologjisĂ« sĂ« zgjedhur nĂ« kontekstin e kufizimeve tĂ« disponueshme;
  • aftĂ«sinĂ« pĂ«r tĂ« realizuar transferimin dhe migrimin e tĂ« dhĂ«nave;
  • aftĂ«sinĂ« pĂ«r tĂ« implementuar dhe pĂ«rdorur zgjidhjet e zgjedhura.

Shembulli në vijim në GCP demonstron se si ndodh zgjedhja e teknologjisë së punës me të dhëna në varësi të strukturës së tyre:

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Vini re se në skemë mungon PostgreSQL, dhe kjo është për shkak se ai fshihet pas terminologjisë Cloud SQL. Dhe kur hyjmë në Cloud SQL, na nevojitet përsëri të bëjmë zgjedhje:

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Duhet të theksohet se kjo zgjedhje nuk është gjithmonë e kuptueshme, prandaj zhvilluesit e aplikacioneve shpesh udhëhiqen nga intuicioni.

Pra, në përfundim:

  1. Sa më shumë që kalon koha, bëhet më aktual çështja e zgjedhjes. Edhe nëse shohim vetëm GCP, shërbimet e menaxhuara dhe SaaS, ndonjë përmendje e RDBMS shfaqet vetëm në hapin e katërt (dhe aty është Spanner pranë). Përveç kësaj, zgjedhja e PostgreSQL shfaqet gjithashtu vetëm në hapin e pestë, ku përmenden edhe MySQL dhe SQL Server, domethënë ka shumë mundësi, por duhet të zgjedhim.
  2. Nuk duhet harruar as kufizimet pĂ«rballĂ« joshjeve. Kryesisht, tĂ« gjithĂ« duan Spanner, por ai Ă«shtĂ« i shtrenjtĂ«. Si rezultat, njĂ« kĂ«rkesĂ« tipike duket kĂ«shtu: «Na bĂ«ni, ju lutem, Spanner por me çmimin e Cloud SQL, ju jeni profesionistĂ«!》

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

ÇfarĂ« duhet bĂ«rĂ«?

Pa pretenduar të jem i fundit në autoritet, le të themi këto:

Duhet të ndryshojmë qasjen në mësim:

  • tĂ« mĂ«sosh si mĂ«suan mĂ« parĂ« DBA, nuk ka kuptim;
  • njohuritĂ« pĂ«r njĂ« produkt tani janĂ« tĂ« pamjaftueshme;
  • dhe tĂ« njohĂ«sh dhjetĂ«ra nĂ« nivelin e njĂ«rit — Ă«shtĂ« e pamundur.

Duhet të dish jo vetëm se çfarë është produkti, por:

  • rastin e pĂ«rdorimit tĂ« tij;
  • metoda tĂ« ndryshme tĂ« implementimit;
  • avantazhet dhe disavantazhet e çdo metode;
  • produkte tĂ« ngjashme dhe alternativĂ«, pĂ«r tĂ« bĂ«rĂ« njĂ« zgjedhje tĂ« qartĂ« dhe optimale dhe jo gjithmonĂ« nĂ« favor tĂ« produktit tĂ« njohur.

Dhe gjithashtu duhet të dish si të migrosh të dhënat dhe të kuptosh parimet e bazës së integrimit me ETL.

Rasti real

Në të kaluarën e afërt, ishte e nevojshme të krijohej një backend për një aplikacion mobil. Në momentin që filluam punën mbi të, backend-i tashmë ishte zhvilluar dhe i gatshëm për implementim, dhe ekipi i zhvilluesve kishte shpenzuar rreth dy vjet në këtë projekt. Ndërkohë, ishin vendosur këto detyra:

  • tĂ« ndĂ«rtosh CI/CD;
  • tĂ« bĂ«sh njĂ« rishikim tĂ« arkitekturĂ«s;
  • tĂ« nisĂ«sh gjithçka nĂ« pĂ«rdorim.

Aplikacioni ishte mikro-shĂ«rbim, dhe kodi nĂ« Python/Django ishte zhvilluar nga zero dhe menjĂ«herĂ« nĂ« GCP. Sa i pĂ«rket audiencĂ«s, supozohej se do tĂ« ishin dy rajone — SHBA dhe BE, dhe trafiku shpĂ«rndaheshin pĂ«rmes Global Load balancer. TĂ« gjitha Workloads dhe ngarkesa llogaritĂ«se punonin nĂ« Google Kubernetes Engine.

Sa i përket të dhënave, ishin 3 struktura:

  • Cloud Storage;
  • Datastore;
  • Cloud SQL (PostgreSQL).

Si të mbijetosh një baze të dhënash SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster.

Mund tĂ« lindĂ« pyetja, pse u zgjodh Cloud SQL? Duke folur me tĂ« vĂ«rtetĂ«, njĂ« pyetje e tillĂ« nĂ«nkupton njĂ« pauzĂ« tĂ« pakĂ«ndshme — krijohet njĂ« ndjesi se njerĂ«zit filluan tĂ« ndihen tĂ« turpĂ«ruar pĂ«r bazat e tĂ« dhĂ«nave relacional, por megjithatĂ« ata vazhdojnĂ« t'i pĂ«rdorin aktivisht ;-).

Sa i përket rastit tonë, Cloud SQL u zgjodh për këto arsye:

  1. Si e përmendur, aplikacioni u zhvillua me Django, dhe ai ka një model që shfaq të dhënat e qëndrueshme nga baza e të dhënave SQL në objekte Python (Django ORM).
  2. Korniza mbështeste një listë të përfunduar të DBMS-ve:

  • PostgreSQL;
  • MariaDB;
  • MySQL;
  • Oracle;
  • SQLite.

Përkatësisht, PostgreSQL u zgjodh nga ky listë më shumë intuitivisht (nuk është si të zgjidhje Oracle, vallë).

ÇfarĂ« mungonte:

  • aplikacioni ishte zbatuar vetĂ«m nĂ« 2 rajone, dhe tani kishte njĂ« plan pĂ«r njĂ« tĂ« tretĂ« (AzinĂ«);
  • DB u ndodhte nĂ« rajonin e AmerikĂ«s Veriore (Iowa);
  • nga ana e klientit kishte shqetĂ«sime lidhur me vonesat nĂ« akses nga Evropa dhe Azia dhe ndĂ«rprerjet nĂ« shĂ«rbim nĂ« rast tĂ« papĂ«rputhjes sĂ« DB.

MegjithĂ«se Django vetĂ« mund tĂ« punojĂ« me disa DB paralelisht dhe t'i ndajĂ« ato sipas leximit dhe shkrimit, shkrimet nĂ« aplikacion nuk ishin aq tĂ« shumta (mĂ« shumĂ« se 90% — lexim). Dhe nĂ« pĂ«rgjithĂ«si, nĂ«se ishte e mundur tĂ« bĂ«hej njĂ« read-replica e bazĂ«s kryesore nĂ« EvropĂ« dhe Azi, do tĂ« ishte njĂ« mundĂ«si kompromisi pĂ«r zgjidhje. Por çfarĂ« ka kaq tĂ« komplikuar kĂ«tu?

Komplikimi ishte se klienti nuk dëshironte të hiqte dorë nga shërbimet e menaxhuara dhe Cloud SQL. Dhe mundësitë e Cloud SQL në atë moment ishin të kufizuara. Cloud SQL mbështet Disponueshmëri të Lartë (HA) dhe Read Replica (RR), por e njëjta RR mbështetet vetëm në një rajon. Duke krijuar një DB në rajonin amerikan, nuk është e mundur të bësh një read-replica në rajonin evropian me mjetet e Cloud SQL, megjithëse PostgreSQL vetë nuk e pengon këtë. Korrespondenca me punonjësit e Google nuk çoi në asgjë dhe përfundoi me premtime në stilin "ne e dimë problemin dhe po punojmë mbi të, një ditë do të zgjidhet."

Nëse i rendisim mundësitë e Cloud SQL në pikë, do të duket më në këtë mënyrë:

1. Disponueshmëri e Lartë (HA):

  • nĂ« kuadĂ«r tĂ« njĂ« rajoni;
  • nĂ«pĂ«rmjet riprodhimit tĂ« diskut;
  • nuk pĂ«rdoren mekanizmat PostgreSQL;
  • mundĂ«si pĂ«r menaxhim automatik dhe manual — failover/failback;
  • nĂ« kalimin e DB, nuk Ă«shtĂ« e disponueshme pĂ«r disa minuta.

2. Read Replica (RR):

  • nĂ« kuadĂ«r tĂ« njĂ« rajoni;
  • hot standby;
  • riprodhimi streaming i PostgreSQL.

Më tej, siç është zakonshme, kur zgjidhni një teknologji gjithmonë përballeni me ndonjë kufizime:

  • klienti nuk dĂ«shironte tĂ« krijonte entitete dhe tĂ« pĂ«rdorte IaaS, pĂ«rveç nĂ«pĂ«rmjet GKE;
  • klienti nuk dĂ«shironte tĂ« zbuste njĂ« self service PostgreSQL/MySQL;
  • TĂ« paktĂ«n, Google Spanner do tĂ« ishte njĂ« zgjidhje e mirĂ«, po sikur tĂ« mos ishte çmimi i tij. MegjithatĂ«, Django ORM nuk mund tĂ« punojĂ« me tĂ«, por Ă«shtĂ« njĂ« gjĂ« e mirĂ«.

Duke marrë parasysh situatën, nga klienti erdhi një pyetje për të vështirë: «A mund të bëni diçka të ngjashme që të jetë si Google Spanner, por të funksionojë edhe me Django ORM?»

Zgjidhja e mundshme № 0

E para që më erdhi në mendje ishte:

  • tĂ« mbeteshim brenda CloudSQL;
  • nuk do tĂ« ketĂ« replikim tĂ« integruar midis rajoneve nĂ« asnjĂ« formĂ«;
  • tĂ« pĂ«rpiqemi tĂ« lidhnim njĂ« replikĂ« me Cloud SQL ekzistues nga PostgreSQL;
  • tĂ« nisnim njĂ« instancĂ« PostgreSQL diku dhe siç duhet, por tĂ« mos e prekim master-in.

PĂ«r fat tĂ« keq, doli qĂ« nuk mund ta bĂ«nim kĂ«tĂ«, pasi nuk kishte akses nĂ« host (ai ishte nĂ« njĂ« projekt tjetĂ«r) – pg_hba dhe kĂ«shtu me radhĂ«, dhe gjithashtu nuk kishte akses si superuser.

Zgjidhja e mundshme № 1

Pas më shumë reflektimesh dhe duke marrë parasysh rrethanat e mëparshme, mendimi ynë ndërrua pak:

  • ende pĂ«rpiqemi tĂ« mbetemi brenda CloudSQL, por kalojmĂ« nĂ« MySQL, pasi Cloud SQL nga MySQL ka njĂ« master tĂ« jashtĂ«m, i cili:

– shĂ«rben si proxy pĂ«r MySQL-in e jashtĂ«m;
– duket si njĂ« instancĂ« MySQL;
– Ă«shtĂ« krijuar pĂ«r migrimin e tĂ« dhĂ«nave nga re tĂ« tjera ose On-premises.

Duke qenë se konfigurimi i replikimit të MySQL nuk kërkon qasje në host, në parim gjithçka funksiononte, por shumë në mënyrë të paqëndrueshme dhe të pak rahat. Dhe kur shkuam më tutje, gjithçka u bë akoma më e frikshme, pasi ne po zhvillonim të gjithë strukturën me terraform, dhe është ndjerë se master i jashtëm nuk mbështetet nga terraform. Po, Google ka CLI, por për një arsye tjetër gjithçka punonte në rast se, ndonjëherë krijohet, ndonjëherë jo. Ndoshta sepse CLI është menduar për migrimin e të dhënave nga jashtë, e jo për replikat.

Në fakt, këtu u bë e qartë se Cloud SQL nuk është aspak i përshtatshëm. Siç thonë, bëmë gjithçka që mundëm.

Zgjidhja e mundshme № 2

Duke qenë se nuk arritëm të mbetemi brenda Cloud SQL, përpiqem të formuloj kërkesat për një zgjidhje kompromisi. Kërkesat janë si më poshtë:

  • punimi nĂ« Kubernetes, pĂ«rdorimi maksimal i burimeve dhe mundĂ«sive tĂ« Kubernetes (DCS,
) dhe GCP (LB,
);
  • mungesa e njĂ« bari nga shumĂ« gjĂ«ra tĂ« panevojshme nĂ« re si HA proxy;
  • mundĂ«sia pĂ«r tĂ« nisur njĂ« HA PostgreSQL ose MySQL nĂ« rajonin kryesor; nĂ« rajonet e tjera – njĂ« HA nga RR i rajonit kryesor plus kopjen e saj (pĂ«r besueshmĂ«ri);
  • multi master (nuk do tĂ« doja tĂ« lidhesha me tĂ«, por nuk ishte shumĂ« thelbĂ«sore)

.
Si rezultat i këtyre kërkesave, në horizont më në fund u shfaq njëmundësi të përshtatshme për DBMS dhe lidhjen e saj:

  • MySQL Galera;
  • CockroachDB;
  • mjetet PostgreSQL

:
— pgpool-II;
— Patroni.

MySQL Galera

Teknologjia MySQL Galera është zhvilluar nga kompania Codership dhe është një plugin për InnoDB. Karakteristikat:

  • multi master;
  • repikim sinkron;
  • lexim nga çdo nyje;
  • shkrim nĂ« çdo nyje;
  • mekanizĂ«m tĂ« integruar HA;
  • ka Helm chart nga Bitnami.

CockroachDB

Sipas pĂ«rshkrimit, kjo Ă«shtĂ« diçka pĂ«r t'u habitur dhe pĂ«rfaqĂ«son njĂ« projekt open source, e shkruar nĂ« Go. PjesĂ«marrĂ«si kryesor — Cockroach Labs (tĂ« themeluar nga ish-punonjĂ«s tĂ« Google). Ky DBMS relational Ă«shtĂ« krijuar pĂ«r t'u shpĂ«rndarĂ« (me shkallĂ«zim horizontal "nga kutia") dhe pĂ«r tĂ« qenĂ« rezistent ndaj dĂ«shtimeve. AutorĂ«t e saj nga kompania kanĂ« pĂ«rcaktuar qĂ«llimin "tĂ« kombinojnĂ« pasurinĂ« e funksionalitetit SQL me disponueshmĂ«rinĂ« horizontale, tĂ« zakonshme pĂ«r zgjidhjet NoSQL."

Si njĂ« bonus i kĂ«ndshĂ«m — mbĂ«shtetje pĂ«r protokollin e lidhjes PostgreSQL.

Pgpool

Ky është një shtresë mbi PostgreSQL, në të vërtetë, një entitet i ri që merr të gjitha lidhjet dhe i proceson ato. Ka një balancues ngarkese dhe analist të vetin, dhe licencohet nën licencën BSD. Oferon mundësi të gjera, por duket disi frikësuese, pasi prania e një entiteti të ri mund të shkaktojë disa aventura të tjera.

Patroni

Ky ishte i fundit nĂ« tĂ« cilin u pĂ«rqendrua shikimi dhe, siç u duk, jo pa arsye. Patroni — njĂ« utilitar open source, qĂ« nĂ« thelb Ă«shtĂ« njĂ« daemon nĂ« Python, i cili lejon menaxhimin automatik tĂ« grupeve PostgreSQL me lloje tĂ« ndryshme replikimi dhe kalimin automatik tĂ« roleve. Kjo rezultoi shumĂ« interesante, pasi integron mirĂ« me Kubernetes dhe nuk sjell asnjĂ« entitet tĂ« ri.

ÇfarĂ« u zgjodh nĂ« fund

Zgjedhja ishte e vështirë:

  1. CockroachDB — zjarr, por i rrezikshĂ«m;
  2. MySQL Galera — gjithashtu e mirĂ«, pĂ«rdoret nĂ« shumĂ« vende, por MySQL;
  3. Pgpool — shumĂ« entitete tĂ« tepĂ«rta, integrimi me re dhe K8s Ă«shtĂ« i dobĂ«t;
  4. Patroni — integrim tĂ« shkĂ«lqyer me K8s, pa entitete tĂ« tepĂ«rta, integrohet mirĂ« me GCP LB.

Pra, zgjedhja ra mbi Patroni.

PĂ«rfundimet

Ka ardhur koha për të përmbledhur përfundimet. Po, bota e infrastrukturës IT ka ndryshuar ndjeshëm, dhe kjo është vetëm fillimi. Dhe nëse më parë re siç ishin vetëm një lloj tjetër infrastrukture, tani gjërat janë ndryshe. Jo vetëm kaq, inovacionet në re po shfaqen vazhdimisht, do të vazhdojnë të shfaqen dhe, ndoshta, do të shfaqen vetëm në re dhe më pas, nga startup-et, do të transferohen në On-premises.

Sa SQL, SQL do të vazhdojë të jetë një e përhershme. Kjo do të thotë se duhet të njihni PostgreSQL dhe MySQL dhe të jeni në gjendje t'i përdorni ato, por është edhe më e rëndësishme të dini si t'i aplikoni ato saktë.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster