Ce que nous faisons · Données et web: Tiers web haute disponibilité, N+1 à chaque couche
Chaque couche de votre site existe au moins en double : terminaison TLS, cache de pages, serveur web et PHP. Les adresses flottantes se déplacent d'elles-mêmes quand un nœud tombe, et nous dimensionnons la stack pour qu'elle tourne à pleine vitesse avec un nœud manquant à chaque tier.
De quoi il s'agit : répartition de charge et clustering pour tiers web
Une plateforme web pour les sites qui ne peuvent pas être hors ligne : presse, e-commerce, édition, front-ends SaaS. L'edge termine TLS et met les pages en cache, le tier web fait tourner nginx avec PHP-FPM, et l'ensemble est construit pour que perdre un nœud, en redémarrer un ou en corriger un soit quelque chose que vos visiteurs ne voient jamais.
Comment nous le construisons
Un edge croisé. Deux nœuds edge par propriété font tourner HAProxy pour TLS, le routage et les contrôles de santé, Varnish pour le cache de pages complètes, et keepalived pour les adresses flottantes. Chaque edge est primaire pour une adresse publique et en standby pour l'autre, de sorte que les deux portent du trafic en permanence. Un script de santé rétrograde un edge dont le HAProxy cesse de répondre, et son pair reprend son adresse en quelques secondes.
Un tier web sans favori. Derrière l'edge, deux nœuds web ou plus font tourner nginx et PHP-FPM avec un pool par site, pondérés à égalité. Le chemin d'administration est épinglé sur un nœud, qui est aussi la source d'une réplication de fichiers à sens unique, de sorte que les uploads et les changements de plugins atteignent les autres nœuds en quelques secondes sans suppressions conflictuelles.
Un cache qui sert malgré les ennuis. Varnish repose sur un stockage all-flash adossé au SAN avec un pool mémoire plafonné, ce qui lui permet de retenir bien plus d'objets que la RAM ne le ferait, à pratiquement la même vitesse. Si chaque backend est en mauvaise santé, Varnish continue de servir la dernière bonne copie de chaque page pendant jusqu'à une journée. L'invalidation du cache est pilotée par les événements du CMS, de sorte qu'un article publié apparaît immédiatement au lieu d'attendre un minuteur.
Des redémarrages que personne ne voit. HAProxy réessaie et redispatche une requête lorsqu'un backend redémarre, les contrôles de santé sont réglés pour que la rotation des logs ne provoque jamais de flapping, et PHP-FPM peut être redémarré un nœud à la fois pendant que l'edge absorbe le creux.
Double attache dans le fabric. Chaque nœud web est double-attaché dans notre fabric, les deux liens en service ; la façon dont les bonds sont construits est décrite sur la page fabric du datacenter.
Ce dont il vous protège
- Un seul nœud web, cache ou load balancer qui tombe ou doit redémarrer.
- Un problème de backend (maintenance de la base, pool PHP coincé) qui tourne à la page blanche : les lecteurs continuent de recevoir le contenu en cache.
- Des redémarrages de sécurité et des mises à jour PHP qui produisent des erreurs visibles.
- Un pic de trafic qui submerge PHP alors que la plupart des requêtes pourraient être servies depuis le cache.
En pratique
Testé en charge avant le lancement. Sur la nouvelle paire d'edges d'un éditeur lifestyle, nous avons fait tourner des dizaines de milliers d'utilisateurs virtuels pendant quinze minutes, en soutenant plus de dix mille requêtes par seconde avec zéro 503 et zéro échec de santé des backends.
Une mise à jour de sécurité PHP en pleine journée de travail. Nous avons corrigé à chaud les deux nœuds web d'un portail sportif, un nœud à la fois. L'origine a vu de brefs creux de redémarrage d'environ une seconde chacun ; l'edge a réessayé et servi le contenu en cache, et le nombre d'erreurs reçues par les visiteurs a été de zéro.
Plus de cache, moins de mémoire. Faire passer une paire d'edges d'un cache en RAM à un stockage adossé au flash a libéré une grande quantité de mémoire pour d'autres travaux.
Pourquoi EuroVPS
- N+1 à chaque couche, load balancers compris, pas seulement « deux serveurs web derrière un proxy ».
- Failover testé et mesuré avant la livraison.
- Le cache est conçu pour garder votre site en ligne quand le backend ne l'est pas.
- Nous réglons les contrôles de santé, les retries et le redispatch, les détails qui décident si un failover de backend est invisible ou juste court.
- Les mêmes ingénieurs exploitent le réseau, le stockage et la stack, de sorte que rien ne tombe entre les équipes.
Questions fréquentes
- Avons-nous aussi besoin d'un CDN ? Pas pour la disponibilité. Beaucoup de clients en ajoutent un pour la portée mondiale ; la stack fonctionne avec ou sans, et nous configurons Varnish et HAProxy pour le respecter.
- Combien de temps prend un failover d'edge ? Quelques secondes. Nous le mesurons sur chaque construction et vous donnons le chiffre à la livraison.
- Pouvez-vous faire tourner WordPress, Magento et PrestaShop là-dessus ? Oui, ainsi que Laravel et du PHP sur mesure. Chaque site reçoit son propre pool PHP-FPM.
- Qu'advient-il des utilisateurs connectés et des paiements ? Ces requêtes contournent le cache par conception et sont réparties sur le tier web. Perdre un nœud web déplace les nouvelles requêtes vers les survivants.
- Pouvons-nous déployer le code nous-mêmes ? Oui. Les déploiements arrivent sur le nœud d'administration et se répliquent, ou passent par votre propre pipeline vers chaque nœud.
Vous voulez un site qui continue de servir pendant que nous travaillons dessus ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.