ProHoster > Blogg > Administrasjon > Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Innledning

For some time now, I have been tasked with developing a fault-tolerant cluster for PostgreSQL, operating across several data centers interconnected by fiber optics within a single city, and capable of withstanding the failure (for instance, power outage) of one data center. As the software responsible for fault tolerance, I chose Pacemaker, because it is the official solution from RedHat for creating fault-tolerant clusters. Its advantages include that RedHat provides support for it and that it is a universal (modular) solution. With it, we will be able to ensure fault tolerance not only for PostgreSQL but also for other services, either by using standard modules or by creating them for specific needs.

A reasonable question arose regarding this solution: how fault-tolerant will the fault-tolerant cluster be? To investigate this, I developed a test bench that simulates various failures on the nodes of the cluster, waits for recovery, restores the failed node, and continues testing in a cycle. Initially, this project was named hapgsql, but over time I grew weary of a name with only one vowel. Therefore, I began to name the fault-tolerant databases (and the float IPs pointing to them) krogan (a character from a video game, whose vital organs are all duplicated), while the nodes, clusters, and the project itself are named tuchanka (the planet where krogan live).

The management has now allowed to open the project for the open source community under the MIT license. The README will soon be translated into English (because it is expected that the primary users will be developers of Pacemaker and PostgreSQL), and I decided to format the old Russian version of the README (partially) as this article.

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Clusters are deployed on virtual machines VirtualBox. A total of 12 virtual machines (36GiB in total) will be deployed, forming 4 fault-tolerant clusters (different options). The first two clusters consist of two PostgreSQL servers located in different data centers and a shared witness med quorum device (hosted on an inexpensive virtual machine in the third data center), which resolves uncertainty 50%/50%, casting its vote for one of the sides. The third cluster involves three data centers: one master, two slaves, without quorum device. Den fjerde klyngen bestÄr av fire PostgreSQL-servere, to per datasenter: én master, de andre replikater, og bruker ogsÄ witness med quorum device. Den fjerde kan hÄndtere svikt av to servere eller ett datasenter. Dette alternativet kan, om nÞdvendig, skaleres opp med flere replikater.

Tjeneste for presis tid ntpd er ogsÄ omkonfigurert for feiltoleranse, men bruker metoden til ntpd (orphan mode). Den generelle serveren witness fungerer som en sentral NTP-server, som distribuerer sitt tid til alle klynger, og dermed synkroniserer alle servere med hverandre. Hvis witness blir ute av drift eller isolert, vil en av serverne i klyngen begynne Ä dele sin tid (innen klyngen). Den hjelpsomme cachende HTTP-proxy er ogsÄ lÞftet pÄ witness, ved hjelp av dette fÄr de andre virtuelle maskinene tilgang til Yum-repositorier. I virkeligheten vil slike tjenester som presis tid og proxy sannsynligvis bli plassert pÄ dedikerte servere, mens i oppsettet er de plassert pÄ witness bare for Ä spare antall virtuelle maskiner og plass.

Versjoner

v0. KjÞres med CentOS 7 og PostgreSQL 11 pÄ VirtualBox 6.1.

Struktur av klynger

Alle klynger er designet for Ä vÊre plassert i flere datasentre, koblet sammen i ett flatt nettverk og skal tÄle svikt eller nettverksisolering av ett datasenter. Derfor is not possible bruke for beskyttelse mot split-brain standardteknologien Pacemaker, som kalles STONITH (Shoot The Other Node In The Head) eller fencing. Essensen er: hvis noder i klyngen begynner Ä mistenke at det skjer noe galt med en av nodene, at den ikke svarer eller oppfÞrer seg unormalt, sÄ frakobler de den tvangsmessig via «eksterne» enheter, som for eksempel en kontrollert IPMI-kort eller UPS. Men dette vil fungere bare i tilfeller der ved en enkelt svikt av serveren, IPMI eller UPS fortsetter Ä fungere. Her planlegges beskyttelse mot en mye mer katastrofal svikt, nÄr hele datasenteret svikter (for eksempel ved strÞmbrudd). Ved en slik svikt vil alle stonith-enheter (IPMI, UPS og sÄ videre) ogsÄ slutte Ä fungere.

I stedet ligger ideen om kvorum til grunn for systemet. Alle noder har en stemme, og bare de som ser mer enn halvparten av alle noder kan fungere. Dette antallet «halvparten +1» kalles kvorummet. Hvis kvorum ikke oppnÄs, avgjÞr noden at den befinner seg i nettverksisolasjon og mÄ koble fra sine ressurser, det vil si at det er en slags beskyttelse mot split-brain. Hvis programvaren som svarer for slik atferd, ikke fungerer, mÄ watchdog, for eksempel basert pÄ IPMI, aktiveres.

Hvis antallet noder er jevnt (klyngen i to datasentre), kan det oppstĂ„ det som kalles usikkerhet 50%/50% (fifty-fifty), nĂ„r nettverksisolasjonen deler klyngen nĂžyaktig pĂ„ midten. Derfor blir det lagt til quorum device — en uvanlig demon som kan kjĂžres pĂ„ den billigste virtuelle maskinen i det tredje datasenteret. Den gir stemmen sin til en av segmentene (som den oppfatter) og lĂžser dermed usikkerheten pĂ„ 50%/50%. Serveren der quorum-enheten skal kjĂžres, kalte jeg witness (terminologi fra repmgr, jeg likte den).

Ressurser kan flyttes fra sted til sted, for eksempel fra defekte servere til fungerende, eller pÄ kommando fra systemadministratorer. For at kundene skal vite hvor de aktuelle ressursene er (hvor skal de koble seg til?), brukes flytende IP (float IP). Dette er IP-er som Pacemaker kan flytte mellom nodene (alt er i et flatt nettverk). Hver av dem symboliserer en ressurs (tjeneste) og vil vÊre der man mÄ koble seg til for Ä fÄ tilgang til denne tjenesten (i vÄrt tilfelle databasen).

Tuchanka1 (plattform med tetning)

Struktur

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Ideen var at vi har mange smÄ databaser med lav belastning, for hvilke det ikke er Þkonomisk Ä opprettholde en dedikert slave-server i hot standby for read-only transaksjoner (det er unÞdvendig ressursbruk).

I hvert datasenter er det Ă©n server. Hver server har to PostgreSQL-instanser (i PostgreSQL-terminologi kalles de klynger, men for Ă„ unngĂ„ forvirring vil jeg kalle dem instanser (pĂ„ lignende mĂ„te som andre databaser), og klynger vil jeg kun bruke om Pacemaker-klynger). Én instans fungerer i master-modus, og det er bare den som tilbyr tjenester (det er bare til den det lenkes float IP). Den andre instansen fungerer som slave for det andre datasenteret, og vil kun tilby tjenester hvis dens master svikter. Siden det meste av tiden kun Ă©n instans av de to (master) tilbyr tjenester (utfĂžrer forespĂžrselene), optimaliseres alle serverressurser mot master (minne tildeles til cache shared_buffers osv.), men sĂžrger for at den andre instansen ogsĂ„ har tilstrekkelige ressurser (selv om det er for suboptimal drift via filsystemcache) i tilfelle et av datasentrene svikter. Slaven tilbyr ingen tjenester (utfĂžrer ikke lese-forespĂžrselene) under normal drift av klyngen, for Ă„ unngĂ„ ressurskonflikter med master pĂ„ samme maskin.

I tilfelle med to noder er feiltoleranse kun mulig med asynkron replikering, ettersom ved synkron replikering vil feil i slaven fĂžre til at master stopper.

Feil i witness

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Feil i witness (quorum device) vil jeg kun vurdere for klyngen Tuchanka1, det vil vÊre den samme historien for alle andre. Ved feil i witness vil ingenting endres i klyngeoppsettelsen, alt vil fortsette Ä fungere som fÞr. Men kvorum vil bli lik 2 av 3, og derfor vil enhver annen neste feil vÊre fatal for klyngen. Det mÄ uansett fikses straks.

Feil i Tuchanka1

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Feil i ett av datasentrene for Tuchanka1. I dette tilfellet witness gir stemmen sin til den andre noden i det andre datasenteret. Der blir den tidligere slaven til master, slik at begge mestere kjÞrer pÄ én server og begge deres float IP-er peker til dem.

Tuchanka2 (klassisk)

Struktur

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Klassisk oppsett med to noder. Én kjĂžrer som master, den andre som slave. Begge kan utfĂžre forespĂžrseler (slaven kun lese), sĂ„ begge har float IP: krogan2 — for master, krogan2s1 — for slaven. Feiltoleranse vil vĂŠre for bĂ„de master og slave.

I tilfelle med to noder er feiltoleranse kun mulig med asynkron replikering, fordi ved synkron replikering vil feil i slaven fĂžre til at master stopper.

Feil i Tuchanka2

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Ved feil i ett av datasentrene witness stemmer for den andre. Den eneste fungerende datasenteret vil heve mesteren, og begge float IP-er vil peke mot den: mesteren og slave. SelvfÞlgelig mÄ instansen vÊre konfigurert slik at den har nok ressurser (grenser for tilkobling osv.) til Ä samtidig motta alle tilkoblinger og forespÞrselene fra master- og slave float IP. Det vil si at den mÄ ha en tilstrekkelig margin pÄ grensene under normal drift.

Tuchanka4 (mange slaver)

Struktur

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Det er allerede en annen ekstremitet. Det finnes databaser som mottar mange forespÞrselene for lesing (et typisk tilfelle med hÞytrafikk-nettsteder). Tuchanka4 er en situasjon hvor det kan vÊre tre eller flere slaver for Ä hÄndtere slike forespÞrselene, men ikke for mange. Med veldig mange slaver mÄ det oppfinnes et hierarkisk system for replikering. I minimumstilfellet (i bildet) er det to servere i hvert datasenter, og pÄ hver av dem er det en instans av PostgreSQL.

En annen funksjon ved dette systemet er at det allerede er mulig Ä organisere en synkron replikering. Den er konfigurert for Ä replikere, om mulig, til et annet datasenter, og ikke til en replika i samme datasenter som mesteren. BÄde pÄ mesteren og pÄ hver slave peker float IP. Ideelt sett mÄ det gjÞres lastbalansering av forespÞrselet mellom slavene ved hjelp av noe sql proxy, for eksempel, pÄ klientsiden. Ulike typer kunder kan kreve forskjellig typ sql proxy, og bare utviklerne av klientene vet hvem som trenger hva. Denne funksjonaliteten kan implementeres bÄde som en ekstern demon og som en klientbibliotek (tilkoblingspool), osv. Alt dette gÄr utover temaet for feiltolerante databaser (feiltoleranse SQL proxy kan implementeres uavhengig av klientens feiltoleranse).

Feil Tuchanka4

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Ved feil med ett datasenter (dvs. to servere) stemmer vitnet for den andre. Resultatet er at to servere fungerer i det andre datasenteret: pÄ den ene kjÞrer mesteren, og den peker mot master float IP (for Ä motta lesing-skriving forespÞrselene); og pÄ den andre serveren kjÞrer en slave med synkron replikering, og den peker mot en av slave float IP (for read only-forespÞrselen).

Det fÞrste som mÄ nevnes: ikke alle slave float IP-er vil vÊre aktive, kun én. Og for at den skal fungere korrekt, mÄ det vÊre kommandoer som sikrer det. sql proxy vider alle forespÞrselene til den eneste gjenvÊrende float IP; hvis ikke sql proxy , kan du liste opp alle float IP-ene til slavene med komma i URL-en for tilkobling. I sÄ fall vil libpq tilkoblingen vÊre til den fÞrste fungerende IP-en, slik det er gjort i automatisk testingssystem. Det kan hende at det ikke vil fungere pÄ andre biblioteker, for eksempel JDBC, og det vil vÊre nÞdvendig sql proxy. Det er gjort fordi float IP-ene til slavene har restriksjonen om at de ikke kan aktiveres samtidig pÄ én server, slik at de blir jevnt fordelt over slave-serverne hvis det er flere som jobber.

For det andre: selv i tilfelle av datasenterfeil vil synkron replikering bli bevart. Og selv om det skjer en sekundÊr feil, det vil si at en av de to serverne i det gjenvÊrende datasenteret svikter, vil klyngen, selv om den slutter Ä tilby tjenester, fortsatt beholde informasjon om alle bekreftede transaksjoner som den har gitt bekreftelse pÄ for kommittering (det vil ikke vÊre noen tap av informasjon ved sekundÊrfeil).

Tuchanka3 (3 datasentre)

Struktur

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Dette er en klynge for situasjonen der det finnes tre fullt fungerende datasentre, hvor hver av dem har en fullt fungerende databaseserver. I dette tilfellet quorum device er ikke nÞdvendig. I ett datasenter fungerer master, mens i de to andre er det slaver. Replikeringen er synkron, av typen ANY (slave1, slave2), noe som innebÊrer at klienten vil motta bekreftelse pÄ kommittering nÄr noen av slavene fÞrst svarer at de har mottatt kommitteringen. Ressursene peker pÄ én float IP for master og to for slavene. I motsetning til Tuchanka4 er alle tre float IP-ene feiltolerante. For Ä balansere read-only SQL-forespÞrslene kan man bruke sql proxy (med separat feiltoleranse), eller man kan tildele én slave float IP til halvparten av klientene og en annen til den andre halvparten.

Feil Tuchanka3

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Ved feil pÄ ett av datasentrene er det fortsatt to igjen. I ett er master og masterens float IP aktivert, mens i det andre er det slaver og begge slavernes float IP-er (instansen mÄ ha dobbelt sÄ mange ressurser tilgjengelig for Ä hÄndtere alle tilkoblinger fra begge slavernes float IP-er). Det er synkron replikering mellom masterne og slaven. Klyngen vil ogsÄ bevare informasjon om bekreftede og kommitterte transaksjoner (det vil ikke vÊre tap av informasjon) i tilfelle to datasentre blir Þdelagt (sÄ lenge de ikke blir Þdelagt samtidig).

Eg detaljert beskrivelse av filstrukturen og distribusjonen bestemte jeg meg for ikke Ă„ inkludere. De som Ăžnsker Ă„ eksperimentere, kan lese alt dette i README. Jeg gir bare en beskrivelse av automatisk testing.

Automatisk testingssystem

For Ä teste klusterets feilresistens med simulering av forskjellige feil er det laget et automatisk testingssystem. Det kjÞres av et skript test/failure. Skriptet kan ta som parametere nummer pÄ klusterne som skal testes. For eksempel, denne kommandoen:

test/failure 2 3

vil teste bare det andre og tredje klusteret. Hvis ingen parametere er angitt, vil alle klusterne bli testet. Alle klusterne testes parallelt, og resultatet vises i tmux-panelet. Tmux bruker en dedikert tmux-server, sÄ skriptet kan kjÞres fra standard tmux, og det vil bli en nestet tmux. Jeg anbefaler Ä bruke terminalen i et stort vindu med liten skrift. FÞr testing starter, tilbakestilles alle virtuelle maskiner til et snapshot fra tidspunktet da skriptet ble avsluttet. setup.

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Terminalen er delt inn i kolonner tilsvarende antall testede klustre; som standard (pÄ skjermbildet) er det fire. Innholdet i kolonnene vil jeg utbrodere med eksemplet Tuchanka2. Panelene pÄ skjermbildet er nummerert:

  1. Her vises statistikk for testene. Kolonner:
    • failure — navnet pĂ„ testen (funksjonen i skriptet) som simulerer en feil.
    • reaction — det aritmetiske gjennomsnittlige tiden i sekunder som klusteret gjenopprettet sin drift. MĂ„les fra skriptets start som simulerer feilen og til Ăžyeblikket da klusteret gjenoppretter sin drift og er i stand til Ă„ fortsette Ă„ tilby tjenester. Hvis tiden er veldig kort, for eksempel seks sekunder (slik som i kluster med flere slaver (Tuchanka3 og Tuchanka4)), betyr det at feilen oppstod pĂ„ en asynkron slave og ikke pĂ„virket driften; det var ingen tilstandsbytter i klusteret.
    • deviation — viser variasjon (presisjon) av verdien reaction metoden "standardavvik".
    • count — hvor mange ganger denne testen har blitt utfĂžrt.
  2. En kort logg gir en oversikt over hva klusteret jobber med akkurat nÄ. Den viser nummeret pÄ iterasjonen (testen), tidsstempelet og navnet pÄ operasjonen. En for lang utfÞrelse (> 5 minutter) indikerer et problem.
  3. heart (hjertet) — gjeldende tid. For visuell vurdering av ytelse mesteren i tabellen hans skrives hele tiden gjeldende tid med bruk av mesters float IP. Ved suksess vises resultatet i dette panelet.
  4. beat (puls) — «gjeldende tid», som tidligere ble registrert av skriptet heart i mesteren, nĂ„ leses fra slaven gjennom hans float IP. Tillater visuell vurdering av ytelsen til slaven og replikasjonen. I Tuchanka1 finnes det ingen slaver med float IP (ingen slaver som tilbyr tjenester), men her er det to instanser (DB), sĂ„ her vil det ikke bli vist beat, men heart den andre instansen.
  5. OvervÄking av klyngens tilstand ved hjelp av verktÞyet pcs mon. Viser strukturen, ressursfordelingen over nodene og annen nyttig informasjon.
  6. Her vises systemovervĂ„kning fra hver virtuell maskin i klyngen. Det kan vĂŠre flere slike paneler — sĂ„ mange virtuelle maskiner som det er i klyngen. To grafer CPU Load (i de virtuelle maskinene med to prosessorer), navnet pĂ„ den virtuelle maskinen, System Load (kalt Load Average, fordi det er gjennomsnittlig over 5, 10 og 15 minutter), prosessdata, og minnefordeling.
  7. Sporing av skriptet som utfĂžrer testing. Ved feil — plutselig avbrudd av arbeidet eller en uendelig venteloop — kan man her se Ă„rsaken til slik oppfĂžrsel.

Testing utfÞres i to trinn. FÞrst gÄr skriptet gjennom alle testtyper, tilfeldig velger en virtuell maskin som testen skal anvendes pÄ. Deretter utfÞres en uendelig testloop, hvor virtuelle maskiner og feil velges tilfeldig hver gang. Plutselig avslutning av testskriptet (nederste panel) eller en uendelig venteloop (mer enn 5 minutters kjÞretid for en operasjon, synlig i sporing) indikerer at en av testene pÄ denne klyngen har feilet.

Hver test bestÄr av fÞlgende operasjoner:

  1. Igangsetting av funksjonen som simulerer en feil.
  2. Klar? — venting pĂ„ gjenoppretting av klyngens arbeidsevne (nĂ„r alle tjenester er tilgjengelige).
  3. Venter pÄ gjenoppretting av klyngen (reaction).
  4. Fix — klyngen «fikses». Etter dette skal den komme tilbake til full drift og klar for neste feil.

Her er listen over tester med beskrivelse av hva de gjĂžr:

  • ForkBomb: skaper "Out of memory" ved hjelp av en fork-bombe.
  • OutOfSpace: fyller opp harddisken. Men testen er i sĂ„ mĂ„te symbolsk, med den ubetydelige belastningen som oppstĂ„r under testing; ved overfylling av harddisken skjer det vanligvis ikke en feil i PostgreSQL.
  • Postgres-KILL: dreper PostgreSQL ved hjelp av kommandoen killall -KILL postgres.
  • Postgres-STOP: setter PostgreSQL i ventemodus ved hjelp av kommandoen killall -STOP postgres.
  • PowerOff: «deaktiverer» virtualmaskinen med kommandoen VBoxManage controlvm "virtuell_maskin" poweroff.
  • Reset: omstarter virtualmaskinen med kommandoen VBoxManage controlvm "virtuell_maskin" reset.
  • SBD-STOP: setter SBD-demonen i ventemodus med kommandoen killall -STOP sbd.
  • ShutDown: sender en kommando til virtualmaskinen via SSH systemctl poweroff, systemet avslutter korrekt.
  • UnLink: nettverksisolering, kommando VBoxManage controlvm "virtuell_maskin" setlinkstate1 off.

Avslutning av testen, enten med den standard kommandoen tmux "kill-window" Ctrl-b &, eller med kommandoen "detach-client" Ctrl-b d: nÄr dette skjer, avsluttes testen, tmux lukkes, og virtualmaskinene slÄs av.

Problemer identifisert under testing

  • For Ăžyeblikket watchdog-demonen sbd hĂ„ndterer stopp av overvĂ„kede demoner, men ikke deres hengelĂ„s. Som en konsekvens hĂ„ndteres ikke feil riktig, noe som fĂžrer til hengelĂ„s av demoner Corosync og Pacemaker, men uten Ă„ faktisk fryse sbd. For Ă„ sjekke Corosync er allerede PR#83 (i GitHub i sbd), akseptert inn i grenen master. De lovet (i PR#83) at det ogsĂ„ ville vĂŠre noe lignende for Pacemaker, jeg hĂ„per at til RedHat 8 vil det bli gjort. Men slike «feil» er teoretiske, lett imiterbare kunstig, for eksempel killall -STOP corosync, men de forekommer aldri i virkeligheten.

  • Det Pacemaker i versjonen for CentOS 7 er sync_timeout feilaktig stilt til quorum device, som resulterer i at ved feil pĂ„ en node blir den andre noden med en viss sannsynlighet omstartet, som mesteren skulle ha flyttet til. Dette ble lĂžst ved Ă„ Ăžke feilaktig stilt til quorum device under distribusjon (i skriptet setup/setup1). Denne endringen ble ikke akseptert av utviklerne Pacemaker, i stedet lovte de Ă„ omarbeide infrastrukturen slik at den tidsavbruddet ble beregnet automatisk (i en uspesifisert fremtid).

  • NĂ„r du konfigurerer databasen, hvis det er angitt at LC_MESSAGES (tekstmeldinger) kan bruke Unicode, for eksempel ru_RU.UTF-8, sĂ„ ved oppstart postgres i et miljĂž der locale ikke er UTF-8, for eksempel i et tomt miljĂž (her pacemaker+pgsqlms(paf) starter postgres), then i loggen i stedet for UTF-8-tegn vil det vĂŠre spĂžrsmĂ„lstegn. Utviklerne av PostgreSQL ble aldri enige om hva de skulle gjĂžre i dette tilfellet. Dette kan omgĂ„s, man mĂ„ sette LC_MESSAGES=en_US.UTF-8 NĂ„r du konfigurerer (oppretter) en DB-instans.

  • Hvis wal_receiver_timeout er satt (standard 60s), sĂ„ ved testing av PostgreSQL-STOP pĂ„ masteren i klusterne tuchanka3 og tuchanka4 skjer det ingen gjenoppretting av replikasjonen til den nye masteren.. Replikasjonen der er synkron, sĂ„ nĂ„r den stoppe, stopper bĂ„de arbeidsenhet og ny master. Problemet lĂžses ved Ă„ sette wal_receiver_timeout=0 under PostgreSQL-oppsettet.

  • Jeg har sjelden sett replikasjonsfrysing i PostgreSQL under ForkBomb-testen (minneoverbelastning). Etter ForkBomb kan arbeidsenhetene noen ganger mislykkes i Ă„ koble til den nye masteren.. Jeg har bare sett dette i klusterne tuchanka3 og tuchanka4, hvor, siden replikasjonen er synkron, fryser masteren. Problemet gĂ„r vanligvis over av seg selv etter en viss tid (omtrent to timer). Det kreves ytterligere undersĂžkelse for Ă„ fikse dette. Symptomene ligner pĂ„ en tidligere feil, som forĂ„rsakes av en annen grunn, men med samme konsekvenser.

Krogan-bildet er hentet fra Deviant Art med tillatelse fra forfatteren:

Modellering av feiltolerante klynger basert pÄ PostgreSQL og Pacemaker

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster