ProHoster >> Blog >> Administrimi >> Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Përshëndetje, habrovçanë. Sot fillojnë mësimet në grupin e parë të kursit «PostgreSQL». Në lidhje me këtë, dëshirojmë t'ju tregojmë se si kaloi webinari i hapur mbi këtë kurs.

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Në mbi mësimin e hapur të radhës diskutuam se me cilat sfida ndodhen përballë databazat SQL në epokën e reve dhe Kubernetes. Gjithashtu shqyrtuam si databazat SQL përshtaten dhe mutojnë nën ndikimin e këtyre sfidave.

Webinarin e drejtoi Valerij Bezrukov, Menaxher i Dorëzimit në Praktikën e Re të Google në EPAM Systems.

Kur pemët ishin të vogla


Për të filluar, le të kujtojmë se si filloi zgjedhja e SGBD-ve në fund të shekullit të 20-të. Megjithatë, kjo nuk do të jetë e vështirë, sepse zgjedhja e SGBD-ve në ato kohë fillonte dhe përfundonte Oracle.

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Në fund të viteve '90 dhe fillimin e 2000-ve, nuk kishte shumë mundësi, nëse flasim për databazat industriale të shkallëzuara. Po, ekzistonin IBM DB2, Sybase dhe disa databaza të tjera që shfaqeshin dhe zhdukeshin, por mbi të gjitha ato nuk ishin aq të dukshme përballë Oracle. Si rezultat, aftësitë e inxhinierëve të atyre kohëve ishin lidhur në një mënyrë ose në tjetër me atë zgjedhje të vetme që ekzistonte.

Oracle DBA duhet të dinte:

  • tĂ« instaloni Oracle Server nga distribuimi;
  • tĂ« konfiguroni Oracle Server:

  • init.ora;
  • listener.ora;

— tĂ« krijoni:

  • hapĂ«sira tĂ« tabelave;
  • skemat;
  • pĂ«rdoruesit;

— tĂ« realizoni kopjim dhe rikuperim;
— tĂ« bĂ«ni monitorim;
— tĂ« luftoni me pyetje jo optimale.

Megjithatë, nga DBA e Oracle nuk pritej veçanërisht:

  • tĂ« dinte tĂ« zgjidhte njĂ« DBMS optimal ose njĂ« teknologji tjetĂ«r pĂ«r ruajtjen dhe pĂ«rpunimin e tĂ« dhĂ«nave;
  • tĂ« sigurojĂ« disponueshmĂ«ri tĂ« lartĂ« dhe shkallĂ«zim horizontal (kjo nuk ishte gjithmonĂ« çështje e DBA);
  • tĂ« kishte njohuri tĂ« mira mbi fushĂ«n pĂ«rkatĂ«se, infrastrukturĂ«n, arkitekturĂ«n aplikative, OS;
  • tĂ« realizonte ngarkimin dhe shkarkimin e tĂ« dhĂ«nave, migrimin e tĂ« dhĂ«nave midis DBMS-ve tĂ« ndryshme.

Në përgjithësi, nëse flasim për zgjedhjen në ato kohëra, ajo ngjasonte me zgjedhjen në një dyqan sovjetik në fund të viteve '80:

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Koha jonë

Që atëherë, natyrisht, pemët janë rritur, bota ka ndryshuar, dhe ka ndodhur kështu:

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Tregu i DBMS-ve ka ndryshuar gjithashtu, gjë që është e dukshme në raporin e fundit të kompanisë Gartner:

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Dhe këtu është e pamundur të mos theksohet se rethana kanë zënë një vend, popullariteti i të cilave po rritet. Nëse lexoni atë raport të kompanisë Gartner, ne do të shohim konkluzionet e mëposhtme:

  1. Shumë klientë janë në rrugën e shndërrimit të aplikacioneve në cloud.
  2. Teknologjitë e reja shfaqen fillimisht në cloud dhe nuk ka garanci që ato ndonjëherë do të kalojnë në infrastrukturë jo-cloud.
  3. Modeli i çmimeve pay-as-you-go është bërë tashmë i zakonshëm. Të gjithë duan të paguajnë vetëm për atë që përdorin, dhe kjo tashmë nuk është një trend, por thjesht një konstatim i faktit.

ÇfarĂ« ndodh tani?

Sot tĂ« gjithĂ« jemi nĂ« cloud. Çështjet qĂ« kemi, janĂ« pyetje zgjedhjeje. Dhe ato janĂ« tĂ« shumta, madje edhe kur flasim vetĂ«m pĂ«r zgjedhjen e teknologjive tĂ« bazave tĂ« tĂ« dhĂ«nave nĂ« formatin On-premises. Dhe kemi gjithashtu shĂ«rbime tĂ« menaxhuara dhe SaaS. KĂ«shtu, zgjedhja vetĂ«m bĂ«het mĂ« e komplikuar çdo vit.

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

  • çmimi. ShumĂ« teknologji ende kushtojnĂ« para;
  • aftĂ«si. NĂ«se flasim pĂ«r softin e lirĂ«, atĂ«herĂ« lind pyetja e aftĂ«sive, pasi softi falas kĂ«rkon nga njerĂ«zit qĂ« e implementojnĂ« dhe e pĂ«rdorin atĂ«, kompetencĂ« tĂ« mjaftueshme;
  • funksionaliteti. Jo tĂ« gjitha shĂ«rbimet qĂ« janĂ« nĂ« re dhe janĂ« ndĂ«rtuar, le tĂ« themi, madje edhe nĂ« bazĂ«n e Postgres tĂ« njĂ«jtĂ«, kanĂ« tĂ« njĂ«jtat veçori si Postgres On-premises. Ky Ă«shtĂ« njĂ« faktor thelbĂ«sor qĂ« duhet tĂ« dihet dhe kuptohet. MĂ« shumĂ« se kaq, ky faktor merr njĂ« rĂ«ndĂ«si mĂ« tĂ« madhe se njohja e ndonjĂ« mundĂ«sie tĂ« fshehtĂ« tĂ« njĂ« SGBD specifike.

ÇfarĂ« pritet tani nga DA/DE:

  • njĂ« kuptim tĂ« mirĂ« tĂ« fushĂ«s sĂ« subjektit dhe arkitekturĂ«s aplikative;
  • aftĂ«sinĂ« pĂ«r tĂ« zgjedhur teknologjinĂ« e duhur SGBD nĂ« pĂ«rputhje me detyrĂ«n e caktuar;
  • aftĂ«sinĂ« pĂ«r tĂ« zgjedhur metodĂ«n optimale tĂ« zbatimit tĂ« teknologjisĂ« sĂ« zgjedhur nĂ« kontekstin e kufizimeve ekzistuese;
  • aftĂ«sinĂ« pĂ«r tĂ« realizuar transferimin dhe migrimin e tĂ« dhĂ«nave;
  • aftĂ«sinĂ« pĂ«r tĂ« zbatuar dhe operuar zgjidhjet e zgjedhura.

Shembulli më poshtë në bazë të GCP tregon se si vendoset teknologjia e caktuar për punën me të dhëna në varësi të strukturës së tyre:

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Vini re se në diagram nuk përfshihet PostgreSQL, dhe kjo për shkak se ai fshihet pas terminologjisë Cloud SQL. Dhe kur arrijmë në Cloud SQL, na nevojitet të bëjmë përsëri një zgjedhje:

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Duhet të theksohet se kjo zgjedhje nuk është gjithmonë e qartë, prandaj zhvilluesit e aplikacionit shpesh drejtohen nga intuita.

Në përmbledhje:

  1. Sa më shumë që kalon koha, aq më i rëndësishëm bëhet pyetja e zgjedhjes. Edhe nëse shohim vetëm GCP, shërbimet e menaxhuara dhe SaaS, përmendja e RDBMS shfaqet vetëm në hapin e 4-të (dhe atje është Spanner). Plus, zgjedhja e PostgreSQL shfaqet në të 5-in, kur janë gjithashtu MySQL dhe SQL Server, domethënë ka shumë, por duhet të zgjedhim.
  2. Nuk duhet harruar as kufizimet përballë tundimeve. Në shumicën e rasteve, të gjithë dëshirojnë Spanner, por ai është i shtrenjtë. Në përfundim, kërkesa tipike duket kështu: «Na bëni, ju lutem, Spanner por me çmimin e Cloud SQL, ju jeni profesionistë!»

Si të mbijetosh një databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

ÇfarĂ« tĂ« bĂ«jmĂ« tani?

Pa pretenduar për të vërteta absolutiste, le të themi këtë:

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

  • nuk ka kuptim tĂ« mĂ«sojmĂ« siç i mĂ«suam mĂ« parĂ« DBA-tĂ«;
  • dija e njĂ« produkti tani Ă«shtĂ« e pamjaftueshme;
  • dhe tĂ« dish dhjetĂ«ra nĂ« nivelin e njĂ«rit — Ă«shtĂ« e pamundur.

Duhet të njohim jo vetëm produktin, por:

  • rastin e pĂ«rdorimit tĂ« tij;
  • metoda tĂ« ndryshme tĂ« implementimit;
  • pĂ«rparĂ«sitĂ« dhe disavantazhet e çdo metode;
  • produkte tĂ« ngjashme dhe alternative pĂ«r tĂ« bĂ«rĂ« njĂ« zgjedhje tĂ« informuar dhe optimale, pa u mbĂ«shtetur gjithmonĂ« nĂ« produktin e njohur.

Përveç kësaj, duhet të jeni në gjendje të migroni të dhënat dhe të kuptoni parimet bazë të integrimit me ETL.

Rasti i vërtetë

Në të kaluarën e afërt, isha duke zhvilluar një backend për një aplikacion mobil. Në momentin që fillova punën, backend kishte përfunduar dhe ishte gati për t'u implementuar, dhe ekipi i zhvilluesve kishte kaluar rreth dy vjet në këtë projekt. Gjatë kësaj periudhe u vendosën detyrat e mëposhtme:

  • tĂ« ndĂ«rtohet CI/CD;
  • tĂ« bĂ«hej review i arkitekturĂ«s;
  • tĂ« ndizet gjithçka nĂ« funksion.

Aplikacioni vetĂ« ishte mikroshtesĂ«, dhe kodi nĂ« Python/Django ishte zhvilluar nga zero dhe menjĂ«herĂ« nĂ« GCP. Sa i pĂ«rket audiencĂ«s synuese, supozohej se do tĂ« ishin dy rajone — SHBA dhe BE, dhe trafiku do tĂ« shpĂ«rndahej pĂ«rmes Balancuesit Global tĂ« NgarkesĂ«s. TĂ« gjitha Workloads dhe ngarkesat Computation 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ë databazë SQL në shekullin 21: re, Kubernetes dhe PostgreSQL multimaster

Mund tĂ« ngrihet njĂ« pyetje, pse u zgjodh Cloud SQL? NĂ« tĂ« vĂ«rtetĂ«, kjo pyetje ka shkaktuar njĂ« heshtje tĂ« çuditshme vitet e fundit - duket se njerĂ«zit po ndihen tĂ« turpĂ«ruar nga bazat e tĂ« dhĂ«nave relacionale, megjithatĂ« ata vazhdojnĂ« t’i pĂ«rdorin ato aktivisht ;-).

Sa i përket rastit tonë, Cloud SQL u zgjodh për arsyet e mëposhtme:

  1. Siç u përmend, aplikacioni u zhvillua me Django dhe përmban një model që shfaq të dhëna të qëndrueshme nga SQL në objekte Python (Django ORM).
  2. I vetmi framework mbështeti një listë mjaft të përfunduar të SGBD-ve:

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

Prandaj, PostgreSQL u zgjodh nga ky listë më shumë intuitivisht (nuk mund të zgjidhje Oracle, në të vërtetë).

ÇfarĂ« mungonte:

  • aplikacioni ishte deployuar vetĂ«m nĂ« 2 rajone, dhe tani kishte njĂ« plan pĂ«r njĂ« tĂ« tretĂ« (Azia);
  • Baza e tĂ« dhĂ«nave ndodhej nĂ« rajonin e AmerikĂ«s sĂ« Veriut (Iowa);
  • nga ana e klientit kishte shqetĂ«sime pĂ«r pengesat nĂ« qasje nga Evropa dhe Azia dhe ndĂ«rprerjet nĂ« shĂ«rbim nĂ« rast tĂ« ndĂ«rprerjes sĂ« SGBD-sĂ«.

Django mund tĂ« punojĂ« me disa baza tĂ« tĂ« dhĂ«nash paralelisht dhe t'i ndajĂ« ato pĂ«r lexim dhe shkruaj, por nĂ« aplikacion nuk kishte shumĂ« shĂ«nime (mĂ« shumĂ« se 90% — lexim). NĂ« pĂ«rgjithĂ«si, po tĂ« ishte e mundur tĂ« bĂ«hej njĂ« replikĂ« leximi tĂ« bazĂ«s kryesore nĂ« EvropĂ« dhe Azi, do tĂ« ishte njĂ« zgjidhje kompromisi. Por çfarĂ« Ă«shtĂ« kaq e komplikuar kĂ«tu?

E komplikuar ishte se klienti nuk donte të hiqte dorë nga përdorimi i shërbimeve të menaxhuara dhe Cloud SQL. Dhe mundësitë që ofron Cloud SQL në këtë moment janë të kufizuara. Cloud SQL mbështet disponueshmërinë e lartë (HA) dhe Replikat për Lexim (RR), por edhe RR mbështetet vetëm në një rajon. Duke krijuar një bazë të dhënash në rajonin amerikan, nuk mund të bëhej një replikë leximi në rajonin evropian me mjete të Cloud SQL, ndonëse PostgreSQL vetë nuk e pengon këtë. Korrespondenca me punonjësit e Google nuk çoi në asgjë dhe u përfundua me premtime në stilin 'e dimë për problemin dhe po punojmë mbi të, një ditë do të zgjidhet problemi.'

Nëse rendisim mundësitë e Cloud SQL në mënyrë të thjeshtë, ato do të duken më pak kështu:

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

  • brenda njĂ« rajoni;
  • nĂ«pĂ«rmjet replikimit tĂ« disqeve;
  • nuk pĂ«rdoren mekanizmat e PostgreSQL;
  • mundĂ«si pĂ«r menaxhim automat dhe manual — failover/failback;
  • nĂ« kalimin e DBMS nuk Ă«shtĂ« i disponueshĂ«m pĂ«r disa minuta.

2. Read Replica (RR):

  • brenda njĂ« rajoni;
  • hot standby;
  • replikimi streaming i PostgreSQL.

Përveç kësaj, siç është zakon, kur zgjedh teknologjinë përballesh gjithmonë me ndonjë kufizim:

  • klienti nuk dĂ«shironte tĂ« krijonte entitete dhe ta pĂ«rdorte IaaS, pĂ«rveç pĂ«rmes GKE;
  • klienti nuk do tĂ« donte tĂ« zbuste self service PostgreSQL/MySQL;
  • po ashtu, Google Spanner do tĂ« ishte i pĂ«rshtatshĂ«m, nĂ«se nuk do ishin çmimi i tij, e vĂ«rteta Ă«shtĂ« se me tĂ« Django ORM nuk mund tĂ« funksionojĂ«, por pĂ«rndryshe Ă«shtĂ« njĂ« gjĂ« e mirĂ«.

Duke marrë parasysh situatën, klienti bëri një pyetje të menjëhershme: "A mund të bëni diçka të ngjashme që të jetë si Google Spanner, por të punojë edhe me Django ORM?"

Zgjidhja e mundshme № 0

E para që më erdhi në mendje:

  • tĂ« qĂ«ndrojmĂ« brenda CloudSQL;
  • nuk do tĂ« ketĂ« replikim tĂ« integruar mes rajoneve nĂ« asnjĂ« formĂ«;
  • tĂ« pĂ«rpiqemi tĂ« lidhim njĂ« replikĂ« me Cloud SQL ekzistues nga PostgreSQL;
  • diku dhe si tĂ« nisim njĂ« instancĂ« PostgreSQL, por tĂ« paktĂ«n tĂ« mos prekim masterin.

FatkeqĂ«sisht, rezultoi se nuk mund tĂ« bĂ«hej kĂ«shtu, pĂ«r shkak se nuk kam qasje nĂ« host (ai Ă«shtĂ« krejt nĂ« njĂ« projekt tjetĂ«r) — pg_hba dhe kĂ«shtu me radhĂ«, dhe gjithashtu nuk ka qasje si superuser.

Zgjidhja e mundshme № 1

Pas disa reflektimeve dhe duke marrë parasysh rrethanat e mëparshme, mënyra e të menduarit ndryshoi disi:

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

— Ă«shtĂ« proxy pĂ«r MySQL-nĂ« e jashtme;
— duket si njĂ« instancĂ« MySQL;
— Ă«shtĂ« krijuar pĂ«r migrimin e tĂ« dhĂ«nave nga re tĂ« tjera ose nga On-premises.

Duke qenĂ« se konfigurimi i replikimit tĂ« MySQL-it nuk kĂ«rkon akses nĂ« host, nĂ« parim gjithçka funksiononte, por shumĂ« pa stabilitet dhe e shqetĂ«sueshme. Dhe kur shkuam mĂ« tej, gjithçka u bĂ« edhe mĂ« e frikshme, sepse ne po e zhvillonim tĂ«rĂ« strukturĂ«n me terraform-in, dhe ndoshta ishte e vĂ«rtetĂ« qĂ« master-i i jashtĂ«m nuk mbĂ«shtetet nga terraform-i. Po, Google ka CLI, por pĂ«r njĂ« arsye, gjithçka funksiononte ndonjĂ«herĂ« — herĂ« krijohet, herĂ« nuk krijohet. Ndoshta, sepse CLI ishte i krijuar pĂ«r migrimin e tĂ« dhĂ«nave nga jashtĂ«, jo pĂ«r replikat.

Në fakt, këtu u bë e qartë që Cloud SQL nuk është e përshtatshme fare. Siç thonë, ne bëmë gjithçka që mundëm.

Zgjidhja e mundshme № 2

Duke qenë se nuk arritëm të qëndrojmë brenda Cloud SQL, përpiqëm të formulojmë kërkesat për një zgjidhje kompromisi. Kërkesat rezultuan si më poshtë:

  • punimi nĂ« Kubernetes, maksimalizimi i burimeve dhe mundĂ«sive tĂ« Kubernetes (DCS, 
) dhe GCP (LB, 
);
  • mungesa e balastit nga njĂ« grumbull gjĂ«rash tĂ« panevojshme nĂ« re si HA proxy;
  • mundĂ«sia pĂ«r tĂ« nisur nĂ« rajonin kryesor HA PostgreSQL ose MySQL; nĂ« rajonet e tjera — HA nga RR e rajonit kryesor plus njĂ« kopje tĂ« saj (pĂ«r besueshmĂ«ri);
  • multi master (nuk doja ta lidhnim, por nuk ishte shumĂ« e rĂ«ndĂ«sishme)

.
Si rezultat i këtyre kërkesave, në horizont përfundimisht dolën pmundësi të përshtatshme të DBMS dhe lidhjeve:

  • MySQL Galera;
  • CockroachDB;
  • PostgreSQL tools

:
— pgpool-II;
— Patroni.

MySQL Galera

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

  • multi master;
  • replikimi sinkron;
  • leximi nga çdo nyje;
  • shkrimi nĂ« çdo nyje;
  • mekanizmi i integruar HA;
  • ka Helm chart nga Bitnami.

CockroachDB

Sipas përshkrimit, kjo është një gjë plotësisht e shkëlqyer dhe përbën një projekt open source, e shkruar në Go. Pjesëmarrësi kryesor është Cockroach Labs (e themeluar nga ish-pjesëtarë të Google). Kjo DB relacional fillimisht është krijuar për t'u shpërndarë (me shkallëzim horizontal 'nga kuti') dhe për të qenë e qëndrueshme. 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

Kjo është një shtesë mbi PostgreSQL, në të vërtetë, një entitet i ri që merr të gjitha lidhjet dhe i përpunon ato. Ka balancuesin e vet të ngarkesës dhe parserin, licencohet sipas licencës BSD. Ofron mundësi të gjera, por duket disi shqetësuese, pasi ekzistenca e një entiteti të ri mund të jetë burim i ndonjë aventure shtesë.

Patroni

Ky Ă«shtĂ« momenti i fundit qĂ« tĂ«rhoqi vĂ«mendjen time, dhe siç u tregua, nuk ishte kot. Patroni Ă«shtĂ« njĂ« mjet me kod tĂ« hapur qĂ«, nĂ« thelb, Ă«shtĂ« njĂ« demon nĂ« Python, i cili lejon menaxhimin automatik tĂ« klashtave PostgreSQL me lloje tĂ« ndryshme replikimi dhe kalimin automatik tĂ« rolleve. ËshtĂ« njĂ« gjĂ« shumĂ« interesante, pasi integrohet mirĂ« me Kubernetes dhe nuk sjell asnjĂ« entitet tĂ« ri.

ÇfarĂ« u zgjodh nĂ« fund

Zgjedhja nuk ishte e lehtë:

  1. CockroachDB — zjarri, por i frikshĂ«m;
  2. MySQL Galera — gjithashtu i mirĂ«, pĂ«rdoret shumĂ«, por MySQL;
  3. Pgpool — shumĂ« entitete ekstra, integrim i dobĂ«t me cloudin dhe K8s;
  4. Patroni — integrim tĂ« shkĂ«lqyer me K8s, pa entitete tĂ« tepĂ«rta, integrohet mirĂ« me GCP LB.

Prandaj, zgjedhja ra mbi Patroni.

PĂ«rfundimet

ËshtĂ« koha pĂ«r tĂ« pĂ«rmbledhur shkurtimisht. Po, bota e infrastrukturĂ«s IT ka ndryshuar ndjeshĂ«m, dhe kjo Ă«shtĂ« vetĂ«m fillimi. NĂ«se mĂ« parĂ« pĂ«rmendjet ishin njĂ« lloj tjetĂ«r infrastrukture, tani Ă«shtĂ« ndryshe. PĂ«r mĂ« tepĂ«r, inovacionet nĂ« cloud vazhdojnĂ« tĂ« shfaqen vazhdimisht, do tĂ« vazhdojnĂ« tĂ« shfaqen dhe, ndoshta, ato do tĂ« shfaqen fillimisht nĂ« cloud dhe mĂ« pas, falĂ« startupeve, do tĂ« transferohen nĂ« On-premises.

Sa i përket SQL, SQL do të jetojë. Kjo do të thotë se duhet të njohim dhe të punojmë me PostgreSQL dhe MySQL, por është më e rëndësishme të dimë si t'i aplikojmë ato saktësisht.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster