Cosa facciamo · Dati e web: Web tier ad alta disponibilità, N+1 a ogni livello
Ogni livello del vostro sito esiste almeno due volte: terminazione TLS, page cache, web server e PHP. Gli indirizzi floating si spostano da soli quando un nodo si guasta, e dimensioniamo lo stack perché giri a piena velocità con un nodo di ogni livello mancante.
Cos'è: load balancing e clustering per i web tier
Una piattaforma web per siti che non possono stare giù: news, e-commerce, editoria, front end SaaS. L'edge termina il TLS e mette in cache le pagine, il web tier esegue nginx con PHP-FPM, e il tutto è costruito in modo che perdere un nodo, riavviarne uno o applicargli le patch sia qualcosa che i vostri visitatori non vedono mai.
Come lo costruiamo
Un edge incrociato. Due nodi edge per proprietà eseguono HAProxy per TLS, instradamento e health check, Varnish per il full page caching e keepalived per gli indirizzi floating. Ogni edge è primario per un indirizzo pubblico e standby per l'altro, così entrambi trasportano traffico tutto il tempo. Uno script di salute declassa un edge il cui HAProxy smette di rispondere, e il peer prende il suo indirizzo in pochi secondi.
Un web tier senza favoriti. Dietro l'edge, due o più nodi web eseguono nginx e PHP-FPM con un pool per sito, pesati allo stesso modo. Il percorso di amministrazione è fissato su un nodo, che è anche la sorgente della replica unidirezionale dei file, così upload e modifiche ai plugin raggiungono gli altri nodi in pochi secondi senza cancellazioni in conflitto.
Una cache che serve anche nei guai. Varnish sta su storage all-flash su SAN con un pool di memoria limitato, il che gli permette di tenere molti più oggetti di quanti ne terrebbe la RAM, praticamente alla stessa velocità. Se ogni backend è in cattiva salute, Varnish continua a servire l'ultima copia buona di ogni pagina fino a un giorno. L'invalidazione della cache è guidata dagli eventi del CMS, così un articolo pubblicato appare subito invece di aspettare un timer.
Riavvii che nessuno vede. HAProxy ritenta e reindirizza una richiesta quando un backend si riavvia, gli health check sono tarati perché la rotazione dei log non causi mai flapping, e PHP-FPM può essere riavviato un nodo alla volta mentre l'edge assorbe il vuoto.
Dual-homed nel fabric. Ogni nodo web è dual-homed nel nostro fabric con entrambi i link in uso; come sono costruiti i bond è nella pagina del fabric del datacenter.
Da cosa vi protegge
- Un singolo nodo web, cache o load balancer che si guasta o ha bisogno di un riavvio.
- Un problema di backend (manutenzione del database, un pool PHP bloccato) che si trasforma in una pagina bianca: i lettori continuano a ricevere contenuti dalla cache.
- Riavvii di sicurezza e aggiornamenti PHP che producono errori visibili.
- Un picco di traffico che travolge PHP quando la maggior parte delle richieste potrebbe essere servita dalla cache.
In pratica
Test di carico prima del lancio. Sulla nuova coppia di edge di un editore lifestyle abbiamo fatto girare decine di migliaia di utenti virtuali per quindici minuti, sostenendo oltre diecimila richieste al secondo con zero 503 e zero fallimenti di health check sui backend.
Un aggiornamento di sicurezza PHP in piena giornata lavorativa. Abbiamo applicato le patch a entrambi i nodi web di un portale sportivo a caldo, un nodo alla volta. L'origin ha visto brevi vuoti di riavvio di circa un secondo ciascuno; l'edge ha ritentato e servito i contenuti dalla cache, e il numero di errori ricevuti dai visitatori è stato zero.
Più cache, meno memoria. Spostare una coppia di edge da una cache in RAM a storage su flash ha liberato una grande quantità di memoria per altro lavoro.
Perché EuroVPS
- N+1 a ogni livello, load balancer compresi, non solo «due web server dietro un proxy».
- Failover testato e misurato prima della consegna.
- La cache è progettata per tenere il vostro sito online quando il backend non lo è.
- Tariamo health check, ritentativi e reindirizzamento, i dettagli che decidono se un failover di backend è invisibile o soltanto breve.
- Gli stessi ingegneri gestiscono la rete, lo storage e lo stack, così nulla cade tra un team e l'altro.
Domande frequenti
- Ci serve anche un CDN? Non per la disponibilità. Molti clienti ne aggiungono uno per la copertura globale; lo stack funziona con o senza, e configuriamo Varnish e HAProxy perché lo rispettino.
- Quanto dura un failover dell'edge? Secondi. Lo misuriamo a ogni build e vi diamo il numero alla consegna.
- Potete farci girare WordPress, Magento e PrestaShop? Sì, insieme a Laravel e PHP personalizzato. Ogni sito riceve il proprio pool PHP-FPM.
- Che cosa succede agli utenti autenticati e ai checkout? Quelle richieste bypassano la cache per progetto e vengono distribuite sul web tier. Perdere un nodo web sposta le nuove richieste sui superstiti.
- Possiamo fare i deploy del codice da soli? Sì. I deploy atterrano sul nodo di amministrazione e si replicano verso gli altri, oppure passano dalla vostra pipeline su ogni nodo.
Volete un sito che continui a servire mentre ci lavoriamo sopra? Parla con un ingegnere.
Il vostro prossimo partner per l'infrastruttura
Guardiamo la vostra infrastruttura.
Raccontateci cosa fate girare oggi e cosa deve migliorare. Un ingegnere esaminerà la vostra richiesta e vi aiuterà a pianificare il passo successivo.
+357 222 32280
Partiamo dalla vostra infrastruttura.
Un po' di contesto ci aiuta a iniziare la conversazione giusta.