Regiuni și rezidența datelor
Regiunea nu reprezintă un tichet de asistență pe această platformă — este o proprietate a site-ului, respectată de motorul de plasare de fiecare dată când este implementat ceva. Dumneavoastră alegeți centrul de date atunci când creați un site, din orașele pe care linia sa de găzduire le oferă astăzi, iar fiecare implementare ajunge pe capacitatea flotei din acea locație, având o rețea edge globală în fața sa. Fiecare pagină de găzduire listează acele orașe, citite în timp real.
În spatele fiecărei locații se află două elemente: flota de procese care vă rulează site-urile și planul de control care le gestionează. Ambele țin cont de regiune. Alegerea locației vă aparține în totalitate; capacitatea de la baza acesteia este propria noastră configurație și operăm în mod deliberat cu mai mulți furnizori, astfel încât niciunul să nu constituie singur întreaga platformă.
Fiecare linie de găzduire oferă propriul său set de centre de date. Dumneavoastră alegeți unul atunci când creați un site, iar formularul de comandă oferă doar un oraș în care linia respectivă are spațiu disponibil astăzi.
Orașele de pe fiecare pagină de găzduire și din formularul de comandă sunt preluate din motorul de alocare, astfel încât o nouă locație apare în ziua în care are capacitate disponibilă, iar o locație ocupată integral nu este oferită.
Regiunea este impusă în cod, în momentul în care este creat un site — nu de către un operator care își amintește ce casetă să folosească.
Fiecare gazdă din flotă se înregistrează cu o cheie de regiune, o listă de afinitate pentru linia de produse, un tip de server web și o valoare a capacității, apoi preia sarcini. Serviciul de plasare filtrează candidații mai întâi după regiune, apoi după linia de produse, apoi după capacitatea disponibilă și alege gazda eligibilă cel mai puțin încărcată.
Dacă ați fixat o regiune, numai instanțele worker din acea regiune sunt eligibile. Dacă nu ați făcut-o, site-ul moștenește regiunea instanței worker pe care aterizează și acea valoare este stocată pe site — astfel încât înregistrarea locației unde se află datele dumneavoastră este un câmp pe care îl puteți citi, nu o presupunere.
Alocarea revendică capacitate printr-o actualizare condiționată care reușește numai în timp ce procesul worker este încă activ, acceptă în continuare implementări și este sub limita capacității. Două implementări care concurează pentru ultimul slot nu pot câștiga ambele, astfel încât o regiune nu este niciodată suprasolicitată în mod silențios.
Dacă nicio resursă eligibilă din regiunea dumneavoastră nu are spațiu disponibil, implementarea generează o eroare de plasare și se oprește. Aceasta nu recurge la un alt continent pentru a finaliza cu succes cererea. Un eșec vizibil și o suplimentare a capacității sunt de preferat unui site care și-a schimbat țara în mod silențios.
Fiecare worker dispune de un comutator accepts-deploys. Trecerea acestuia pe drain oprește alocarea de noi site-uri, în timp ce site-urile existente continuă să funcționeze neafectate, permițându-ne astfel să efectuăm lucrări de întreținere, reînnoiri de hardware și dezafectări în cadrul unei regiuni fără a vă muta sarcinile de lucru.
Rezidența datelor este una dintre puținele decizii de găzduire care sunt cu adevărat greu de anulat, motiv pentru care platforma o tratează ca pe o dimensiune fundamentală, nu doar ca pe un detaliu de implementare. Opțiunea clientului privind rezidența constituie o intrare pentru plasare, regiunea este înregistrată pentru site, iar flota este etichetată corespunzător. Iată ce face ca un răspuns privind rezidența să fie auditabil, nu doar anecdotiv.
Modelul de colocare funcționează în paralel cu acesta. Fiecare înregistrare din motor include un domeniu de aplicare al organizației cu securitate la nivel de rând din PostgreSQL impusă la nivelul bazei de date, iar colocarea este ierarhică: o organizație de tip reseller deasupra organizațiilor clienților, deasupra site-urilor. Regiunea răspunde la întrebarea unde sunt stocate datele; securitatea la nivel de rând răspunde la întrebarea cine le poate accesa. Ambele aspecte sunt importante pentru un evaluator al conformității și niciunul nu este opțional.
Exportul și ștergerea datelor GDPR fac parte din aceeași arhitectură, nefiind un proces adăugat ulterior, iar acțiunile privilegiate și administrative sunt înregistrate în jurnalul de audit. Dacă în chestionarul cumpărătorului dumneavoastră se întreabă unde se află datele, cine le poate interoga și ce se întâmplă atunci când o persoană vizată le solicită înapoi, acestea sunt întrebări la care se poate răspunde aici.
Alegerea unei regiuni apropiate ajută, dar cea mai mare parte a latenței resimțite de vizitatorii dumneavoastră este decisă înainte ca o solicitare să ajungă la serverul de origine.
Multi-regiunea are o valoare foarte mică dacă totul împărtășește în continuare aceeași soartă. Arhitectura separă piesele care nu trebuie să cedeze împreună.
Motorul, baza de date, stratul fluxului de lucru și tablourile de bord rulează pe propriul lor plan de control Kubernetes, complet separat de flota de noduri de lucru care deservește site-urile clienților. Un incident la nivelul planului de control nu trebuie să întrerupă funcționarea site-urilor clienților, iar un incident la nivelul flotei nu trebuie să afecteze disponibilitatea platformei.
Panoul de control al clientului, consola de administrare și acest site de marketing sunt implementate pe Cloudflare independent de clusterul planului de control, astfel încât un incident de platformă să nu elimine și locul în care ați merge pentru a citi despre acesta.
Pagina de stare este găzduită în mod deliberat la un furnizor diferit, într-o regiune diferită. O pagină de stare care rulează pe infrastructura pe care o monitorizează este inutilă exact în momentul în care aveți nevoie de ea.
Copiile de rezervă per site sunt imuabile și externe, scrise în stocare de obiecte, cu restaurări testate, nu presupuse. Restaurările se realizează cu un singur clic din panou, alături de gestionarul de fișiere, domenii, DNS, SSL și jurnale.
Nu declarăm un acord privind nivelul serviciilor, un timp de răspuns sau o valoare a latenței pe această pagină — termenii SLA sunt stabiliți prin contract. Procentul de 99,99% asociat planurilor Footprint-Free este o garanție a timpului de funcționare, un obiectiv pe care îl vizăm, nu o evidență istorică măsurată a disponibilității.
În practică, decizia se rezumă la patru întrebări, iar majoritatea clienților le răspund în mai puțin de un minut.
Da. Regiunea este o intrare pentru motorul de plasare, nu o solicitare gestionată în afara benzii. Fixați o regiune și numai lucrătorii din flotă etichetați pentru acea regiune vor fi eligibili să primească site-ul; regiunea aleasă este apoi stocată în înregistrarea site-ului, astfel încât să puteți citi oricând unde rulează acesta. Lăsați-o nesetată, iar site-ul va moșteni regiunea lucrătorului pe care ajunge.
Depinde de linia de găzduire, deoarece fiecare linie funcționează pe capacitatea construită special pentru aceasta. Formularul de comandă și fiecare pagină de găzduire listează orașele pe care le puteți alege astăzi, citite în timp real din motorul de plasare, astfel încât acest răspuns nu este niciodată perimat. Pentru o rezidență strictă în EU, alegeți un centru de date din interiorul Uniunii Europene; în cazul în care achiziția impune o platformă de bază certificată, putem aloca pe o capacitate care îndeplinește aceste cerințe. Furnizorii din spatele fiecărei locații reprezintă propriul nostru aranjament comercial — dumneavoastră alegeți locația, nu furnizorul.
Nu — Zinn Digital® nu deține astăzi certificări proprii de conformitate și nu vom lăsa să se înțeleagă contrariul. Ceea ce putem face este să vă plasăm volumul de lucru pe o platformă subiacentă care le deține, acolo unde achizițiile unui cumpărător impun ca o platformă certificată aflată la baza site-urilor dumneavoastră să fie o cerință strictă. Separat, mecanismele de control proprii ale platformei sunt reale și inspectabile: izolare la nivel de site, securitate la nivel de rând pe fiecare tabel circumscris unui chiriaș, secrete păstrate în Vault, TLS pretutindeni și înregistrare de audit a acțiunilor privilegiate.
Implementarea eșuează vizibil cu o eroare de plasare, în loc să vă transfere silențios site-ul în altă parte. Acest lucru este deliberat: un site care și-a schimbat jurisdicția în mod discret este un rezultat mult mai grav decât o implementare care s-a oprit și v-a comunicat motivul. Capacitatea este suplimentată prin aducerea online a mai multor gazde în regiunea respectivă, unde acestea se înregistrează automat și încep imediat să preia sarcini.
Nu publicăm teste comparative de latență și nu vom promite o cifră specifică. Ceea ce putem descrie este arhitectura: Cloudflare se află în fața fiecărui site, astfel încât răspunsurile care pot fi stocate în cache să fie livrate dintr-o locație edge apropiată de vizitator, LSCache livrează pagini complete din worker fără a accesa PHP sau baza de date, iar un cache de obiecte Redis dedicat fiecărui site preia interogările repetate. Pentru majoritatea site-urilor de conținut, această combinație înseamnă că regiunea de origine contează mult mai puțin decât configurarea memoriei cache. Dacă publicul dumneavoastră este concentrat pe un singur continent, plasați originea acolo oricum.
Regiunea este stabilită atunci când un site este plasat și stocată în înregistrarea site-ului, astfel încât o schimbare de regiune reprezintă o migrare, nu o simplă comutare. Contactați-ne înainte de a construi dacă știți deja că urmează o mutare — este mult mai ieftin să plasați corect de prima dată decât să relocați un portofoliu activ.
Copiile de rezervă per site sunt imuabile, stocate în afara locației și izolate de flota activă, scrise în stocare de obiecte cu restaurări testate, nu doar presupuse, și restaurabile printr-un singur clic din panou. Dacă cerințele dumneavoastră de conformitate impun ca stocarea copiilor de rezervă să se afle într-o anumită jurisdicție, discutați direct cu noi — acesta este un detaliu contractual pe care îl convenim pentru fiecare client în parte, nu o afirmație generală pe care o facem pe o pagină web.
Da. Perioada de probă este de 14 zile și nu necesită card. Aceasta include Footprint-Free Hosting pentru maximum cinci site-uri, ceea ce este suficient pentru a vedea cum funcționează implementările, plasarea și nivelurile de memorie cache înainte de a decide unde ar trebui să fie găzduit portofoliul dumneavoastră de producție.
Porniți o perioadă de probă de 14 zile fără card sau comunicați-ne mai întâi cerințele privind rezidența datelor, iar noi vă vom plasa corect încă de la prima implementare.
Începeți gratuit