Regioni e residenza dei dati
La regione non è un ticket di supporto su questa piattaforma: è una proprietà del sito, rispettata dal motore di posizionamento a ogni rilascio. Scegli Europa, Stati Uniti o Asia-Pacifico, e ogni distribuzione viene eseguita sulla capacità della flotta etichettata per quella regione, con un edge globale a monte. Disponibilità: la capacità della nostra flotta al di fuori del Regno Unito è in fase di sviluppo attivo e non è ancora disponibile. Tutto il resto descritto qui è già attivo oggi.
Dietro ogni regione ci sono due elementi: la flotta di worker che esegue i tuoi siti e il control plane che li gestisce. Entrambi sono consapevoli della regione e posizionati per gli stessi motivi: il miglior rapporto prezzo/prestazioni che possiamo garantire in Europa e negli Stati Uniti, una copertura che va oltre questi due mercati e un'opzione con piattaforma sottostante certificata per i clienti i cui requisiti di acquisto lo richiedono. La scelta della regione spetta a te; la capacità sottostante è una nostra organizzazione e operiamo deliberatamente su più di un fornitore, in modo che nessuno di essi diventi mai l'unica piattaforma.
La nostra capacità in Germania è la regione principale e offre il miglior rapporto prezzo/prestazioni che offriamo ovunque. La nuova capacità viene distribuita qui per prima, motivo per cui è l'impostazione predefinita per i clienti europei e per chiunque non abbia specifici requisiti di residenza.
La Finlandia offre ai carichi di lavoro europei una seconda località EU, fisicamente separata. Utile quando si desidera la residenza EU ma non si vuole che un intero portfolio si trovi nel dominio di errore di un solo paese.
La nostra capacità negli Stati Uniti si estende dalla Virginia a est all'Oregon a ovest, coprendo entrambe le coste. Stesso motore, stessi driver, stesso pannello: l'unico cambiamento è il tag di regione che il motore di posizionamento accetterà per i vostri siti.
Asia-Pacific è attiva a Tokyo, Singapore e Seoul. Questo è il modello su cui è interamente costruita la piattaforma: la capacità sottostante a una regione è un'infrastruttura intercambiabile dietro il nostro motore, mai il motore stesso, e nella regione utilizziamo più di un fornitore in modo che un sito non sia mai legato a uno solo.
Laddove un contratto richieda un'infrastruttura EU nativa per il GDPR, o gli acquisti di un acquirente insistano affinché la piattaforma sottostante disponga di attestazioni SOC 2, ISO 27001 o HIPAA, possiamo posizionare il tuo carico di lavoro su capacità che detengono tali certificazioni. Si tratta delle certificazioni della piattaforma sottostante, non delle nostre: non ne possediamo alcuna e non lasceremo mai intendere il contrario.
La regione viene imposta via codice nel momento in cui un sito viene creato, e non da un operatore che deve ricordarsi quale server utilizzare.
Ciascun host del parco si registra con una chiave di area geografica, un elenco di affinità di linea di prodotto, un tipo di server web e un valore di capacità, quindi preleva il lavoro. Il servizio di posizionamento filtra i candidati prima per area geografica, poi per linea di prodotto e infine per capacità libera, e seleziona l'host idoneo con il carico minore.
Se hai fissato una regione, solo i worker in quella regione sono idonei. Se non l'hai fatto, il sito eredita la regione del worker su cui si posiziona e tale valore viene memorizzato sul sito: pertanto la registrazione del luogo in cui risiedono i tuoi dati è un campo che puoi leggere, non un'ipotesi.
Il placement richiede la capacità tramite un aggiornamento condizionale che ha esito positivo solo se il worker è ancora attivo, accetta ancora deploy ed è ancora al di sotto della capacità massima. Due deploy che competono per l'ultimo slot non possono vincere entrambi, quindi una regione non viene mai sovrascritta in modo imprevisto.
Se non c'è spazio disponibile per nulla di idoneo nella tua regione, il deployment genera un errore di posizionamento e si interrompe. Non effettua il fallback su un altro continente per far sì che la richiesta vada a buon fine. Un errore visibile e un'aggiunta di capacità sono preferibili a un sito che ha cambiato paese silenziosamente.
Ogni lavoratore dispone di un interruttore accetta-distribuzioni. Portandolo in modalità di svuotamento si impedisce l'arrivo di nuovi siti, mentre quelli esistenti continuano a funzionare inalterati, ed è così che effettuiamo manutenzione, aggiornamenti hardware e dismissione all'interno di una regione senza spostare i tuoi carichi di lavoro.
La residenza dei dati è una delle poche decisioni di hosting che è davvero difficile da invertire, quindi la piattaforma la tratta come una dimensione di primo livello anziché come un dettaglio di deployment. La scelta di residenza del cliente è un input per il posizionamento, la regione viene registrata in relazione al sito e la flotta è etichettata di conseguenza. È questo che rende una risposta sulla residenza verificabile anziché aneddotica.
Il modello di tenancy agisce in parallelo. Ogni record nel motore include un ambito di organizzazione con sicurezza a livello di riga PostgreSQL applicata a livello di database, e la tenancy è gerarchica: un'organizzazione di rivenditori sopra le organizzazioni dei clienti, sopra i siti. La regione definisce dove si trovano i dati; la sicurezza a livello di riga definisce chi può accedervi. Entrambi sono importanti per un revisore della conformità e nessuno dei due è facoltativo.
L'esportazione e la cancellazione dei dati ai sensi del GDPR fanno parte dello stesso design anziché essere un processo aggiunto, e le azioni privilegiate e amministrative vengono registrate nei log di audit. Se il questionario del vostro acquirente chiede dove risiedono i dati, chi può consultarli e cosa succede quando un interessato ne richiede la restituzione, qui troverete risposte certe.
La scelta di una regione vicina è d'aiuto, ma gran parte della latenza percepita dai tuoi visitatori viene decisa prima ancora che una richiesta raggiunga la tua origine.
Il multi-region vale ben poco se tutto condivide ancora lo stesso destino. L'architettura separa le componenti che non devono guastarsi insieme.
Il motore, il database, il livello dei flussi di lavoro e le dashboard funzionano su un proprio piano di controllo Kubernetes, completamente separato dalla flotta di worker che serve i siti dei clienti. Un incidente sul piano di controllo non deve mettere offline i siti dei clienti, e un incidente sulla flotta non deve mettere offline la piattaforma.
Il dashboard del cliente, la console di amministrazione e questo sito di marketing sono distribuiti su Cloudflare indipendentemente dal cluster del piano di controllo, in modo che un incidente della piattaforma non rimuova anche il luogo in cui andresti a leggere informazioni al riguardo.
La pagina dello stato è ospitata intenzionalmente presso un provider differente in una regione diversa. Una pagina dello stato in esecuzione sull'infrastruttura che monitora è inutile proprio nel momento in cui ne hai bisogno.
I backup per singolo sito sono immutabili e remoti, scritti su object storage, con ripristini testati anziché dati per scontati. I ripristini si effettuano con un clic dal pannello, insieme al file manager, ai domini, al DNS, a SSL e ai log.
Su questa pagina non forniamo un accordo sul livello di servizio (SLA), un tempo di risposta o un valore di latenza; i termini SLA vengono concordati caso per caso. Il valore del 99,99% associato ai piani Footprint-Free è una garanzia di uptime, un obiettivo di progettazione e non un dato storico di disponibilità misurata.
In pratica la decisione si riduce a quattro domande e la maggior parte dei clienti risponde in meno di un minuto.
Sì. La regione è un input per il motore di posizionamento, non una richiesta gestita fuori banda. Blocca una regione e solo i worker della flotta taggati per quella regione saranno idonei a ricevere il sito; la regione scelta viene quindi memorizzata sul record del sito in modo da poter sempre verificare dove è in esecuzione. Lasciala non impostata e il sito erediterà la regione del worker su cui viene allocato.
Europa in Germania e Finlandia; Stati Uniti in Virginia e Oregon; e Asia-Pacifico a Tokyo, Singapore e Seoul. L'Europa è la regione principale e predefinita se non esprimi alcuna preferenza. Per una rigida residenza EU, o laddove gli acquisti richiedano una piattaforma sottostante certificata, possiamo allocare su capacità che soddisfano tali requisiti. I fornitori dietro ciascuna regione sono un nostro accordo commerciale: tu scegli la regione, non il fornitore.
No — Zinn Digital® non possiede attualmente certificazioni di conformità proprie, e non lasceremo intendere il contrario. Ciò che possiamo fare è collocare il vostro carico di lavoro su una piattaforma sottostante che le possiede, nei casi in cui l'ufficio acquisti di un acquirente ponga come requisito fondamentale la presenza di una piattaforma certificata al di sotto dei vostri siti. Separatamente, i controlli della piattaforma sono reali e verificabili: isolamento per singolo sito, sicurezza a livello di riga su ogni tabella con ambito tenant, segreti custoditi in Vault, TLS end-to-end e registrazione dei log di audit per le azioni privilegiate.
Il deployment fallisce in modo evidente con un errore di posizionamento anziché pubblicare silenziosamente il tuo sito altrove. È una scelta deliberata: un sito che sposta silenziosamente la propria giurisdizione è un esito molto peggiore rispetto a un deployment che si interrompe e ti spiega il perché. La capacità viene aggiunta portando online altri host in quella regione, dove si registrano e iniziano immediatamente ad accettare lavoro.
Non pubblichiamo benchmark di latenza e non promettiamo una cifra specifica. Quello che possiamo descrivere è l'architettura: Cloudflare gestisce ogni sito in modo che le risposte memorizzabili nella cache vengano fornite da una posizione edge vicina al visitatore, LSCache serve pagine complete dal worker senza toccare PHP o il database, e una cache di oggetti Redis per singolo sito assorbe le query ripetute. Per la maggior parte dei siti di contenuti, questa combinazione fa sì che la regione di origine conti molto meno rispetto alla configurazione della cache. Se il tuo pubblico è concentrato in un continente, posiziona comunque l'origine lì.
La regione viene impostata quando un sito viene posizionato e memorizzata nel record del sito, pertanto un cambio di regione è una migrazione anziché una semplice attivazione. Parla con noi prima di procedere allo sviluppo se sai già che ci sarà un trasferimento: è molto meno costoso posizionare correttamente la prima volta piuttosto che rilocare un portfolio attivo.
I backup specifici per sito sono immutabili, esterni e isolati dalla flotta in esecuzione, scritti su object storage con ripristini testati anziché dati per scontati, e ripristinabili con un clic dal pannello. Se la vostra posizione di conformità richiede che lo storage dei backup si trovi in una specifica giurisdizione, parlatene direttamente con noi: è un dettaglio contrattuale che concordiamo con ciascun cliente anziché una dichiarazione generica su una pagina web.
Sì. La prova dura 14 giorni, senza carta di credito, e inizia nella regione europea predefinita. Include Footprint-Free Hosting con un massimo di cinque siti, sufficienti per verificare il comportamento dei rilasci, del posizionamento e dei livelli di cache prima di decidere dove collocare il tuo portfolio di produzione.
Avvia una prova di 14 giorni in Europa senza carta di credito, oppure comunicaci prima la tua residenza e ti collocheremo correttamente fin dal primo rilascio.
Inizia gratis