Docker Swarm pe trei continente: disponibilitate ridicată, proiectată pentru un uptime de 100%

Un server într-un centru de date este un punct unic de defecțiune, oricât de bune ar fi hardware-ul și rețeaua. Dacă locația cade, de exemplu din cauza unei avarii la alimentarea cu energie sau la rețea ori pur și simplu a unei erori în timpul unei lucrări de întreținere, aplicația nu mai este disponibilă. Docker Swarm în mai multe centre de date rezolvă exact această problemă: containerele rulează în trei locații independente, ideal pe trei continente, iar dacă una dintre ele cade complet, celelalte două preiau sarcina fără ca utilizatorii să observe ceva.

Acest articol arată pas cu pas cum construiți un cluster Docker Swarm proiectat pentru un uptime de 100%: câte un server în America de Nord, Europa și Asia, o rețea WireGuard criptată între noduri, un cvorum de manageri care supraviețuiește căderii unui continent întreg, un punct de intrare pentru fiecare regiune și un failover DNS care îi direcționează automat pe utilizatori către cea mai apropiată locație funcțională. Totodată explicăm sincer ce mai poate cădea chiar și cu această arhitectură și cum contracarați și aceste riscuri.

Se poate obține un uptime de 100% cu Docker Swarm?

Un Docker Swarm pe trei continente este proiectat pentru un uptime de 100%: niciun server, niciun centru de date și niciun continent nu poate opri singur aplicația. Totuși, nimeni nu poate garanta o disponibilitate absolută, nici măcar marii furnizori de cloud, ale căror angajamente maxime se situează între 99,99 și 99,999%. Cauza nu sunt centrele de date, ci lucrurile pe care toate locațiile le au în comun. Tocmai pe acestea le tratează și acest articol, ca să vă apropiați de 100% cât de mult este tehnic posibil.

Ce înseamnă disponibilitatea în cifre

Calculul pornește de la 8.760 de ore pe an și 730 de ore pe lună. Fiecare 9 în plus reduce la o zecime timpul de nefuncționare permis, iar exact aici începe munca pe care un singur server nu o mai poate face.

De ce contează atât de mult trei continente

Trei locații independente una de alta, fiecare cu o disponibilitate de 99,9%, cad toate deodată, matematic vorbind, numai dacă toate trei au o problemă în același moment: 0,1% ori 0,1% ori 0,1% înseamnă 0,0000001%. Cu cât locațiile sunt mai îndepărtate una de alta, cu atât sunt mai independente în realitate: rețele electrice proprii, conexiuni de rețea proprii, condiții meteo proprii, ferestre de întreținere proprii. De aceea, distribuirea pe America de Nord, Europa și Asia este cea mai puternică formă de toleranță la defecțiuni care se poate construi cu servere.

Ce poate cădea chiar și cu trei continente

Riscurile rămase sunt dependențele comune ale tuturor locațiilor, iar pentru fiecare există o contramăsură:

• O actualizare defectă ajunge prin cluster în toate locațiile la fel de sigur ca una bună. Contramăsură: health check-uri și rollback automat, plus actualizări regiune cu regiune.
• DNS-ul este singurul punct prin care trec toți utilizatorii. Contramăsură: un furnizor DNS cu rețea distribuită la nivel mondial și failover, TTL scurt.
• Baza de date trebuie să aibă aceleași date în toate locațiile. Contramăsură: replicare cu comutare automată, vedeți secțiunea despre date.
• Certificatele și domeniile expirate afectează toate locațiile în același timp. Contramăsură: reînnoire automată și monitorizarea datelor de expirare.
• Comutarea în sine durează până când health check-urile și DNS-ul reacționează, de obicei un minut sau două, timp în care unele cereri pot eșua. Contramăsură: intervale scurte de verificare, TTL scurt și clienți care repetă cererile eșuate.

Privire de ansamblu asupra arhitecturii

Un Docker Swarm pe mai multe continente este format din șase componente. Fiecare dintre ele elimină un anumit punct de defecțiune:

Câți manageri și unde?

Nodurile manager ale unui Swarm administrează starea clusterului cu ajutorul algoritmului de consens Raft. Fiecare modificare are nevoie de acordul majorității managerilor, așa-numitul cvorum. Dacă majoritatea se pierde, containerele existente continuă să ruleze, dar clusterul nu mai poate nici să replanifice, nici să compenseze căderile, nici să distribuie actualizări.

Docker recomandă un număr impar de manageri și distribuirea lor în cel puțin trei zone: la trei manageri în raport de 1-1-1, la cinci în raport de 2-2-1. De aici rezultă cea mai importantă regulă a acestui articol: două locații nu sunt suficiente. Cu două locații, într-una dintre ele se află inevitabil mai mulți manageri, iar dacă tocmai aceasta cade, majoritatea se pierde. Abia cu trei locații cvorumul supraviețuiește căderii oricărui centru de date, deci, la trei continente, căderii unui continent întreg.

Trei continente sau un singur continent: compromisul

Fiecare modificare a clusterului, fiecare implementare și fiecare replanificare a unui container așteaptă confirmarea majorității managerilor. Între Europa, America de Nord și Asia, fiecare astfel de confirmare costă o latență de aproximativ 80 până la 250 de milisecunde. Pentru utilizatori acest lucru nu contează, deoarece cererile lor primesc răspuns local; implementările și replanificările durează însă simțitor mai mult decât într-un cluster cu distanțe scurte.

Pentru aplicațiile cu utilizatori pe mai multe continente și cu obiectivul unei disponibilități cât mai ridicate, varianta cu trei continente este cea potrivită, iar pe aceasta o construim în ghid. Importantă este aici o regulă care se regăsește în toți pașii: fiecare cerere primește răspuns în regiunea ei și nu face niciodată naveta între continente.

Ce locații KernelHost sunt potrivite

KernelHost operează servere în centrul de date maincubes din Frankfurt am Main și oferă servere virtuale în alte locații din Europa, America de Nord și Asia-Pacific, printre care trei locații în SUA, precum și Canada, Londra, Strasbourg, Varșovia, Helsinki, Singapore, Japonia, Sydney și Mumbai. Lista completă, cu hartă, se află pe pagina Locații servere. Pentru exemplul din acest articol folosim Frankfurt am Main pentru Europa, Coasta de Est a SUA pentru America de Nord și Singapore pentru Asia.

Ghid: construirea unui Docker Swarm pe trei continente

Exemplul folosește trei servere: swarm-eu în Frankfurt am Main, swarm-us pe Coasta de Est a SUA și swarm-asia în Singapore. Adresele publice provin din rețeaua de documentare 203.0.113.0/24, iar rețeaua WireGuard folosește 10.10.0.0/24. Înlocuiți-le pe amândouă cu valorile dumneavoastră. Toate cele trei noduri îndeplinesc simultan rolul de manager și de worker; pentru mai multă performanță, adăugați ulterior în fiecare regiune noduri exclusiv worker.

Pasul 1: provizionați servere pe trei continente

Comandați trei servere cu Debian 12 sau 13 în trei regiuni și aplicați securizarea de bază: SSH doar cu cheie, actualizări de securitate automate, utilizatori proprii. Lista de verificare pentru servere root noi acoperă toate acestea. Alegeți nume de gazdă sugestive, ca să vedeți imediat în docker node ls care nod unde se află.

hostnamectl set-hostname swarm-eu

Pasul 2: instalați Docker pe toate nodurile

Instalați Docker Engine din depozitul oficial Docker pe toate cele trei servere, așa cum este descris în articolul Instalarea Docker pe Debian și Ubuntu. Verificați apoi versiunea pe fiecare nod; toate trei ar trebui să aibă aceeași versiune majoră:

docker version --format '{{.Server.Version}}'

Pasul 3: construiți o rețea WireGuard între continente

Nodurile comunică între ele prin internetul public. Pentru ca tot traficul clusterului să fie criptat, iar porturile Swarm să nu fie niciodată accesibile public, cele trei servere sunt conectate printr-o rețea WireGuard. Pe fiecare nod generați mai întâi o pereche de chei:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

Apoi fiecare nod primește un fișier /etc/wireguard/wg0.conf. Pe swarm-eu arată astfel, iar pe celelalte două noduri este construit în oglindă:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = CHEIA_PRIVATA_SWARM_EU
MTU = 1420

[Peer]
PublicKey = CHEIA_PUBLICA_SWARM_US
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = CHEIA_PUBLICA_SWARM_ASIA
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Dacă toate nodurile răspund pe adresele lor 10.10.0.x, rețeaua este gata. PersistentKeepalive menține conexiunea deschisă și în spatele firewallurilor stateful. Latențele pe care ping le afișează acum între continente sunt exact timpii de așteptare pe care îi costă fiecare modificare a clusterului.

Pasul 4: firewallul lasă să intre doar nodurile Swarm

Între noduri, Docker Swarm are nevoie de portul 2377/TCP pentru administrarea clusterului, de 7946/TCP și UDP pentru comunicarea dintre noduri și de 4789/UDP pentru rețeaua overlay. Permiteți aceste porturi exclusiv pe interfața WireGuard; public rămâne deschis doar WireGuard însuși, și numai pentru celelalte noduri. Cu ufw, pe swarm-eu arată astfel:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Important: porturile pe care Docker le publică pentru containere ocolesc ufw, deoarece Docker își setează propriile reguli iptables. De aceea, publicați doar porturile punctului de intrare (80 și 443) și niciodată porturi de baze de date sau de administrare.

Pasul 5: inițializați clusterul Swarm și adăugați managerii

Pe swarm-eu inițializați clusterul Swarm și vă asigurați că administrarea și traficul de date trec prin WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

A doua comandă afișează comanda de aderare pentru alți manageri. Pe swarm-us și swarm-asia o rulați cu adresa WireGuard proprie fiecăruia, aici pentru swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

docker node ls afișează apoi trei noduri, unul cu starea Leader, celelalte două cu Reachable. Tokenul de aderare este un secret: oricine îl cunoaște poate strecura un manager propriu în clusterul dumneavoastră. După configurare, înnoiți-l cu docker swarm join-token --rotate manager.

Pasul 6: activați Autolock

Managerii stochează starea clusterului, împreună cu cheile cu care sunt criptate jurnalele Raft, în /var/lib/docker/swarm/. Cu Autolock, chiar aceste chei sunt criptate, iar un manager repornit revine în cluster abia după introducerea unei chei de deblocare:

docker swarm update --autolock=true
docker swarm unlock

Prima comandă afișează cheia de deblocare, pe care o păstrați într-un manager de parole. Pe a doua o folosiți după fiecare repornire a unui manager. Fără această cheie, clusterul Swarm nu poate fi restaurat nici dintr-un backup, de aceea păstrați-o separat de servere.

Pasul 7: etichetați nodurile după regiune

Etichetele îi spun planificatorului unde se află un nod. Pe ele se bazează regulile de plasare din pașii următori:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Pasul 8: creați o rețea overlay cu MTU potrivit

Containerele din locații diferite comunică între ele printr-o rețea overlay. Deoarece aceasta trece prin tunelul WireGuard, MTU-ul ei trebuie să fie mai mic: WireGuard lucrează cu 1420 de octeți, rețeaua overlay (VXLAN) are nevoie de 50 de octeți din aceștia pentru propriile antete, deci rămân 1370 de octeți:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Un MTU prea mare se manifestă perfid: cererile mici funcționează, răspunsurile mari se blochează. Cine renunță la WireGuard poate cripta în schimb rețeaua overlay cu --opt encrypted; în acest caz, între noduri trebuie permis suplimentar protocolul IP 50 (ESP), iar Docker avertizează explicit asupra unor pierderi de performanță simțitoare. Recomandăm WireGuard, deoarece acoperă tot traficul, inclusiv administrarea.

Pasul 9: rulați aplicația în fiecare regiune

Un serviciu Swarm obișnuit distribuie cererile, prin adresa serviciului, către toate replicile din cluster, deci și către celelalte continente. Cu trei continente, una din două sau din trei cereri ar traversa astfel jumătate de glob. De aceea, fiecare regiune primește un serviciu propriu, care rămâne în regiunea sa printr-o regulă de plasare. Setările de actualizare asigură că versiunile noi sunt lansate container cu container și retrase automat în caz de eroare:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Pentru ca Swarm să recunoască dacă un container chiar funcționează, nu doar rulează, imaginea trebuie să conțină un health check, de exemplu această linie în Dockerfile-ul aplicației dumneavoastră:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Un container al cărui health check eșuează de trei ori la rând este înlocuit, iar în timpul unei actualizări un health check eșuat oprește lansarea.

Pasul 10: un punct de intrare pentru fiecare regiune

Rolul de punct de intrare îl preia un reverse proxy precum Caddy, Traefik sau nginx. Și acesta rulează în fiecare regiune ca serviciu separat și redirecționează cererile doar către aplicația din regiunea sa. În modul host, publică porturile 80 și 443 direct pe serverul regiunii sale. O configurație comună este suficientă, deoarece Caddy citește destinația dintr-o variabilă de mediu:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Toate regiunile au nevoie de un certificat TLS pentru același domeniu. De aceea, obțineți certificatele prin challenge-ul DNS, care funcționează indiferent de regiunea spre care indică în acel moment înregistrarea DNS; pentru aceasta, Caddy are nevoie de modulul furnizorului dumneavoastră de DNS. Noțiunile de bază despre proxy le găsiți în articolul Configurarea nginx ca reverse proxy.

Pasul 11: configurați Geo-DNS cu failover

Ultima componentă îi conduce pe utilizatori către regiunea potrivită. Un serviciu DNS cu rutare geografică și health check-uri trimite utilizatorii din Europa către Frankfurt am Main, pe cei din America către Coasta de Est a SUA și pe cei din Asia către Singapore. Dacă o regiune cade, health check-ul detectează acest lucru în 30 până la 60 de secunde și trimite utilizatorii ei către cea mai apropiată regiune funcțională. Setați durata de valabilitate (TTL) a înregistrărilor la 60 de secunde, pentru ca resolverele să preia rapid o modificare. Mai multe înregistrări A fără health check sunt doar o soluție de avarie: browserele încearcă adesea următoarea adresă, dar nu orice client face asta, iar o regiune căzută rămâne în răspuns.

Faceți un calcul onest: între cădere și comutare trec intervalul de verificare plus TTL-ul, în exemplu deci un minut sau două, timp în care o parte dintre utilizatorii regiunii afectate ajung încă la locația căzută. Aplicațiile, inclusiv cele mobile, care repetă cererile eșuate după o scurtă pauză fac ca acest interval să treacă aproape neobservat.

Pasul 12: testați căderea unei regiuni

Un failover care nu a fost exersat niciodată funcționează rareori atunci când contează. Simulați căderea unei regiuni scoțând nodul ei din funcțiune și urmăriți cum reacționează clusterul și DNS-ul:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Deoarece serviciile regiunii sunt legate de nodul lor printr-o regulă de plasare, ele nu se mută, ci intră în pauză; utilizatorii regiunii sunt preluați de failoverul DNS. În acest test verificați deci în primul rând dacă health check-ul scoate regiunea din răspunsuri și dacă regiunea vecină face față sarcinii suplimentare. Pentru un test mai dur, deconectați complet nodul de la rețea, de exemplu oprind WireGuard. Repetați testul după modificări mai mari și cel puțin o dată pe trimestru.

Datele: partea cea mai dificilă a disponibilității ridicate

Docker Swarm replică containere, nu date. Un volum se află întotdeauna pe nodul pe care rulează containerul. De aceea, serviciile fără stare, precum interfețele web și API-urile, pot rula fără probleme în fiecare regiune, dar pentru tot ce conține date aveți nevoie de o replicare separată.

Replicarea bazelor de date între continente

Bazele de date au propria replicare, iar aceasta este întotdeauna preferabilă unei stocări partajate între centre de date. Între continente s-a dovedit eficientă o instanță primară într-o regiune, cu replici asincrone în celelalte două: la PostgreSQL, de exemplu, prin Streaming Replication, cu un instrument precum Patroni pentru comutarea automată, la MariaDB și MySQL prin replicarea integrată. Cererile de citire primesc atunci răspuns local în fiecare regiune, iar scrierile merg către instanța primară. Sincer vorbind, asincron înseamnă și următorul lucru: dacă regiunea primară cade, pot lipsi ultimele secunde de scrieri. Cine vrea să scrie la nivel mondial fără să piardă nimic alege baze de date construite pentru mai multe regiuni, precum CockroachDB sau YugabyteDB. Legați ferm nodurile bazei de date de regiunea lor printr-o regulă de plasare, pentru ca Swarm să nu le mute niciodată fără datele lor:

docker service create --name db-asia --constraint node.labels.region==asia ...

Fișiere și încărcări

Fișierele încărcate nu își au locul într-un volum local, ci într-o stocare de obiecte compatibilă S3, cu replicare într-o a doua regiune, sau într-un sistem de stocare propriu, replicat. Sistemele de fișiere în rețea, precum NFS, întinse peste continente sunt lente și reprezintă ele însele un punct unic de defecțiune.

Sesiuni și cache-uri

Dacă aplicația stochează sesiunile în memoria RAM a unui container, utilizatorii sunt deconectați la comutare. Stocați sesiunile într-o bază de date replicată sau într-un cache replicat precum Redis ori folosiți tokenuri semnate, pe care fiecare regiune le poate verifica singură.

Backupurile rămân obligatorii

Replicarea protejează împotriva căderii unei locații, dar nu și împotriva erorilor: o înregistrare ștearsă accidental este ștearsă câteva secunde mai târziu în toate regiunile. De aceea, orice arhitectură cu disponibilitate ridicată are nevoie de backupuri regulate și testate într-o locație independentă, așa cum este descris în articolul Strategia de backup pentru servere.

Operare: actualizări, întreținere și monitorizare

Actualizări regiune cu regiune

Nu lansați versiunile noi în toate regiunile deodată, ci pe rând, și urmăriți fiecare regiune un scurt timp înainte să treceți la următoarea. Astfel, o eroare pe care niciun health check nu o detectează ajunge în cel mult o regiune, iar celelalte două continuă să deservească utilizatorii acesteia:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Dacă o actualizare eșuează, Swarm o anulează automat datorită setărilor din pasul 9, iar || break încheie bucla de îndată ce comanda raportează o eroare. O actualizare ale cărei probleme ies la iveală abia mai târziu o anulați manual cu docker service rollback web-asia.

Întreținerea unei regiuni

Dacă un server trebuie repornit sau actualizat, scoateți-l din funcțiune cu docker node update --availability drain și lăsați în prealabil failoverul DNS să îi redirecționeze utilizatorii către regiunile vecine. După întreținere, îl readuceți în funcțiune cu --availability active. Înainte de următorul manager, așteptați până când docker node ls îi afișează din nou pe toți trei ca accesibili, pentru ca niciodată să nu lipsească doi manageri în același timp.

Monitorizare din exterior

Monitorizați fiecare regiune separat și din afara clusterului: accesibilitatea punctelor de intrare, health check-urile serviciilor, starea managerilor, întârzierea replicării bazei de date și datele de expirare ale certificatelor și domeniilor. O alertă trebuie să ajungă chiar și atunci când o regiune întreagă tace. Cum construiți acest lucru pentru servere individuale arată articolul Configurarea monitorizării serverelor.

Distribuirea sigură a secretelor

Parolele și cheile nu își au locul în variabile de mediu sau în fișiere Compose, ci în Docker Secrets. Acestea sunt stocate criptat în jurnalul Raft și livrate doar serviciilor cărora li le atribuiți explicit:

printf '%s' 'PAROLA_BAZEI_DE_DATE' | docker secret create db_password -
docker service update --secret-add db_password web-eu

De ce KernelHost pentru un Swarm pe mai multe continente

Un cluster pe mai multe continente impune furnizorului alte cerințe decât un singur server. În practică, aceste aspecte sunt decisive:

O privire de ansamblu asupra tuturor tarifelor cloud, cu prețuri, și o comparație a costurilor cu marii furnizori de cloud găsiți pe pagina Închiriere server cloud.

Erori frecvente și cum le evitați

• Manageri în doar două locații. Dacă locația cu majoritatea cade, clusterul se blochează. Soluție: trei locații, distribuție 1-1-1 sau 2-2-1.
• Număr par de manageri. Patru manageri nu suportă mai multe căderi decât trei, dar cresc efortul de coordonare. Soluție: 3, 5 sau 7.
• Cererile circulă între continente. O adresă de serviciu comună tuturor regiunilor trimite utilizatorii pe jumătate de glob. Soluție: un serviciu și un punct de intrare pentru fiecare regiune.
• Porturile Swarm accesibile public. Portul 2377 și rețeaua overlay nu au ce căuta niciodată în internetul deschis. Soluție: doar prin WireGuard; public doar 80, 443 și WireGuard pentru celelalte noduri.
• MTU-ul uitat. Răspunsurile mari se blochează, cele mici funcționează. Soluție: MTU overlay 1370 la WireGuard cu 1420.
• Încrederea în ufw pentru porturile containerelor. Docker ocolește ufw la porturile publicate. Soluție: publicați doar punctul de intrare.
• Bază de date într-un volum, fără replicare. Dacă regiunea cade, datele nu sunt accesibile. Soluție: replicarea bazei de date, plasare fixă în regiune.
• Actualizare în toate regiunile deodată. O eroare îi afectează atunci pe toți utilizatorii din lume. Soluție: lansare regiune cu regiune.
• TTL DNS mare. Cu un TTL de o zi, failoverul intră în acțiune abia a doua zi. Soluție: 60 de secunde.
• Replicare în loc de backup. O eroare este replicată la fel ca datele bune. Soluție: în plus, backupuri testate într-o locație independentă.

Pe scurt

• Un Docker Swarm pe trei continente este proiectat pentru un uptime de 100%: o locație sau un continent întreg poate cădea fără ca aplicația să se oprească.
• Nimeni nu poate garanta absolut o anumită disponibilitate; riscurile rămase sunt DNS-ul, actualizările defecte, baza de date și certificatele, iar pentru fiecare există o contramăsură.
• Trei manageri în trei locații reprezintă minimul; două locații nu sunt suficiente pentru un cvorum tolerant la defecțiuni.
• Fiecare cerere rămâne în regiunea ei: un serviciu și un punct de intrare pentru fiecare regiune, plus Geo-DNS cu health check-uri și TTL scurt.
• WireGuard criptează traficul clusterului, porturile Swarm rămân invizibile, iar MTU-ul rețelei overlay scade la 1370.
• Swarm replică containere, nu date: bazele de date au nevoie de replicare proprie, iar backupurile rămân obligatorii.
• KernelHost oferă locații în Europa, America de Nord și Asia-Pacific, trafic nelimitat, protecție DDoS în fiecare locație și facturare PrePaid fără durată minimă.