Isolation par site

Chaque site dans sa propre cage, pour qu’un mauvais voisin reste un seul mauvais voisin.

L’isolation fait toute la différence entre un incident et une interruption de service. Chaque site que nous hébergeons fonctionne au sein d’une cage CloudLinux LVE au niveau du noyau, dotée de ses propres plafonds de processeur, de mémoire vive, d’E/S et de processus, de sa propre vue du système de fichiers CageFS, de sa propre version de PHP et de sa propre régulation de base de données. Un site qui subit une attaque, qui est compromis ou qui exécute simplement une requête exigeante est confiné là où il se trouve — et le socle d’isolation est inclus dans chaque offre, sans vous être revendu sous la forme d’une mise à niveau. Disponibilité : la régulation de base de données par site et les statistiques de ressources par site sont en cours de développement actif et ne sont pas encore disponibles. Tout le reste décrit ici est opérationnel dès aujourd’hui.

Un site unique entouré de sa propre limite de confinement, distinct de ses voisins.
  • 700 000+sites hébergés dans le monde entier
  • Par siteLimites de CPU, RAM, E/S, IOPS et processus
  • 99,99 %Garantie de disponibilité
  • InclusIsolation de base sur chaque forfait

L’isolation au niveau du noyau, pas dans un fichier de configuration

Le parc de serveurs de traitement fonctionne sous CloudLinux OS, ce qui intègre le multi-hébergement au cœur même du noyau. Chaque site bénéficie d’un environnement virtuel léger — un LVE — qui constitue une frontière stricte plutôt qu’une simple convention de courtoisie. Rien de ce qu’un site effectue dans sa cage ne peut être débité du budget de quelqu’un d’autre.

Plafonds stricts de ressources par site

LVE limite de manière indépendante le processeur (CPU), la RAM, les E/S (IO), les IOPS, les processus et les processus d’entrée pour chaque site. Lorsqu’un site dépasse son plafond, ses ressources sont bridées au sein de son propre espace isolé — l’erreur est consignée pour ce site et les sites adjacents continuent de fonctionner sans être affectés.

Les processus incontrôlés sont confinés, non pourchassés

Une extension bloquée dans une boucle, une tâche cron mal codée ou un robot d’exploration qui sature un point de terminaison atteignent d’abord les limites de processus et de processus d’entrée du site lui-même. Un seul site ne peut pas simplement accaparer toute la machine.

Le trafic d’attaque est limité par site

Les processus d’entrée étant plafonnés par cage, un afflux massif visant un site ne peut pas ouvrir un nombre illimité de tâches sur l’hôte. La régulation des connexions et des requêtes de LiteSpeed ainsi que le pare-feu réseau Imunify360 sont placés en amont, de sorte que l’attaque reste le seul problème de la cible.

Les défaillances de ressources deviennent des signaux, pas des surprises

Chaque erreur LVE est enregistrée par site et transmise au moteur de stratégies de la plateforme, qui peut durcir ou assouplir les limites automatiquement. Vous voyez pourquoi un site a été bridé, et quand — de manière graduée, réversible et journalisée.

Une vue de système de fichiers qui vous est propre

L’isolation des ressources empêche un site de perturber les autres. L’isolation du système de fichiers l’empêche d’être indiscret. CageFS offre à chaque locataire une vue privée et restreinte de la machine.

Sous CageFS, un locataire ne voit que ses propres fichiers et un ensemble minimal et assaini de binaires système — et ne peut pas voir les autres locataires, leurs sites ou les fichiers système sensibles. Le mode de défaillance habituel de l’hébergement mutualisé, où un compte compromis devient un poste de lecture sur tous les autres comptes de la machine, est neutralisé au niveau du noyau.

Cela prend toute son importance le jour où un problème survient. Si un site est compromis — via une extension obsolète, un identifiant volé, un thème vulnérable —, CageFS est ce qui confine le rayon d’impact à cette seule cage. Notre spécification de sécurité est délibérée quant au choix des termes : CageFS contient les failles. Le confinement est la promesse honnête, et c’est ce qui détermine si un incident nécessite le nettoyage d’un seul site ou de l’ensemble du parc.

Les sauvegardes renforcent cette même frontière. Les sauvegardes par site sont immuables, délocalisées et isolées de l’infrastructure en cours d’exécution, avec des restaurations testées, de sorte que même dans le pire des cas de compromission sur un site, il existe une voie de récupération propre et indépendante qui ne dépend pas de l’état de la machine sur laquelle il fonctionnait.

La base de données est également isolée — c’est généralement là que l’hébergement devient bruyant

L’isolation de la couche Web n’est que la moitié de l’histoire. Sur une flotte WordPress, ce qui ralentit le plus souvent un serveur, ce sont les requêtes d’un seul site, et non son trafic. Cela est géré de manière explicite.

MySQL Governor

CloudLinux MySQL Governor régule l’utilisation de la base de données par site, afin que les requêtes lourdes d’un site ne puissent pas ralentir le serveur pour tous les autres. Il s’agit du contrôle anti-ralentissement, et il fonctionne que le site bruyant remarque ou non qu’il est restreint.

MariaDB pour les charges de travail WordPress

Le parc fonctionne sous MariaDB (ou Percona), choisi spécifiquement pour les charges de travail WordPress plutôt qu’hérité par défaut, avec Governor placé au-dessus comme couche d’équité par locataire.

Cache d’objets Redis en amont

Un cache d’objets Redis par site absorbe les lectures répétées avant qu’elles n’atteignent la base de données, ce qui réduit d’emblée la pression que Governor doit arbitrer. La mise en cache et l’isolation fonctionnent comme un seul système.

PHP par site, sécurisé

CloudLinux alt-PHP offre à chaque site son propre sélecteur de version de PHP, ses propres extensions (imagick, gd, redis et les autres) et ses propres paramètres renforcés — avec des processus de travail LSAPI limités par les plafonds LVE de ce site, de sorte que la simultanéité PHP fait partie intégrante de la cage plutôt que de constituer une échappatoire.

L’échec est progressif, réversible et expliqué

L’isolation détermine l’étendue de la propagation d’un problème. L’application détermine ce qui se passe ensuite. Nous avons remplacé la suspension binaire activé/désactivé par une machine à états, pilotée par des flux de travail durables et appliquée sur le worker via LiteSpeed, LVE et Imunify.

  • Régulé — limites LVE plus strictes et limitation du débit, le site restant en ligne et fonctionnel. Il s’agit généralement d’un abus de ressources ou d’un signal modéré, et la situation se rétablit automatiquement dès que la cause est résolue.
  • Restreint — les e-mails sortants, les tâches cron ou les requêtes POST sont désactivés tandis que le site reste visible. Utilisé en cas de suspicion de compromission ou d’envoi de spam, il se rétablit automatiquement après correction.
  • Suspendu — le site est mis hors ligne derrière une page d’attente personnalisée indiquant le motif (facturation, maintenance ou abus) plutôt que derrière une page d’erreur. La situation est rétablie lors du paiement, de la correction ou de l’appel.
  • Mis en quarantaine — hors ligne, fichiers verrouillés, aucune exécution, isolé pour analyse médico-légale. Réservé aux logiciels malveillants ou au hameçonnage confirmés, et ne s’annule qu’après nettoyage et examen ; il n’y a pas de libération automatique lors d’une nouvelle analyse.
  • Chaque transition est consignée dans le journal d’audit avec son motif, son auteur et ses preuves, vous est notifiée avec des instructions pour la résoudre, et peut faire l’objet d’un recours. Le délai d’application est configurable par ligne de produit, de sorte que la facturation, les abus et les questions juridiques s’intensifient chacun selon leur propre calendrier.

La même isolation sur les deux gammes de produits — et un palier plus puissant lorsque vous en avez besoin

L’isolation n’est pas une fonctionnalité d’offre qui apparaît trois niveaux plus haut. C’est une propriété de l’infrastructure sous-jacente, elle est donc identique que vous gériez une seule boutique WooCommerce ou deux mille sites en réseau.

Hébergement Footprint-Free

Les réseaux de masse et de PBN fonctionnent sur le même substrat LVE et CageFS, avec une rotation des comptes CDN tenant compte de l’empreinte et une distribution HTML statique. L’isolation est ce qui rend la densité sûre : les sites partagent une flotte sans partager le même sort.

Zinn® Managed WordPress

Les sites gérés WordPress, WooCommerce, PHP, statiques et Node bénéficient des mêmes environnements isolés ainsi que d’un libre-service complet : votre propre version et extensions PHP, cache d’objets Redis, staging et déploiement en production.

Conteneur par site en tant que variante premium

Pour les charges de travail nécessitant une isolation plus stricte que celle par défaut optimisée pour la densité, une isolation complète par conteneur dédié par site est proposée comme variante du pilote de provisionnement : même moteur, même plan de contrôle, placement différent, avec une surcharge plus élevée.

Inclus, sans survente

L’isolation LVE et CageFS, le WAF proactif et l’analyse des logiciels malveillants sont inclus pour chaque client, car un site infecté ou hors de contrôle menace ses voisins et notre réputation d’IP. Le nettoyage des logiciels malveillants en un clic et les niveaux de protection avancés sont des modules complémentaires payants — le niveau de base ne l’est pas.

Pourquoi l’isolation n’est jamais facultative ici

La tentation commerciale dans l’hébergement consiste à vendre la sécurité par niveaux : placer les clients économiques sur un serveur partagé aux limites souples, et facturer ceux qui se soucient d’un cloisonnement. Nous ne le faisons pas, car le client qui n’a pas payé pour l’isolation est précisément celui dont le site compromis devient l’incident de tout le monde.

Nous hébergeons plus de 700 000 sites dans le monde entier, sur un parc où la densité constitue l’ensemble de la proposition économique. Cela ne fonctionne que si l’isolation sous-jacente est inconditionnelle. Des compartiments au niveau du noyau, une vue privée du système de fichiers, une régulation de la base de données par site et du PHP par site sont le prix à payer pour opérer à cette échelle sans destin partagé — ils sont donc activés pour tout le monde, sur chaque forfait, dès le premier site que vous déployez.

Le résultat est une plateforme au comportement prévisible, même lors des pires journées d’autrui. Elle s’appuie sur une garantie de disponibilité de 99.99 %, des sauvegardes hors site immuables par site avec des restaurations testées, ainsi qu’un historique d’audit complet de chaque mesure d’exécution appliquée à vos sites.

Foire aux questions

Le site d’un autre client peut-il ralentir le mien ?

L’isolation est spécialement conçue pour empêcher cela. LVE plafonne CPU, RAM, IO, IOPS et processus par site, MySQL Governor régule l’utilisation de la base de données par site, et les workers LSAPI sont délimités par le propre cage du site — ainsi, un pic de trafic ou une lourde charge de requêtes d’un voisin est bridé par rapport à son propre plafond, et non le vôtre. Chaque anomalie est journalisée par site, et le moteur de règles peut automatiquement restreindre les limites d’un site bruyant.

Si un site sur le même serveur est piraté, le mien est-il menacé ?

La réponse honnête est l’endiguement plutôt qu’une garantie. CageFS offre à chaque locataire une vue isolée du système de fichiers — un locataire compromis ne peut pas voir les autres locataires, leurs sites ou les fichiers système sensibles — et un cas avéré de logiciel malveillant ou d’hameçonnage place ce site en quarantaine : hors ligne, fichiers verrouillés, aucune exécution, isolé pour l’analyse médico-légale. C’est ce qui limite le rayon d’impact. Parallèlement, nous exécutons une analyse des logiciels malveillants et un WAF proactif sur chaque site, ainsi que des sauvegardes externes immuables par site avec des restaurations testées, de sorte que la récupération ne dépende jamais de l’état de la machine concernée.

L’isolation est-elle incluse ou entraîne-t-elle un coût supplémentaire ?

C’est inclus dans chaque formule. L’isolation LVE et CageFS, le WAF proactif et l’analyse des logiciels malveillants constituent la norme pour chaque client, car un site infecté ou hors de contrôle menace ses voisins et notre réputation d’IP — nous ne pouvons raisonnablement pas laisser cela optionnel. Ce qui est vendu comme option payante comprend le nettoyage et la remédiation des logiciels malveillants en un clic, ainsi que des niveaux de protection avancés tels que des règles WAF améliorées, l’analyse prioritaire, la gestion des robots et des paliers de protection DDoS plus élevés.

Qu’advient-il de mon site s’il dépasse ses limites de ressources ?

Il est bridé à l’intérieur de son propre espace isolé (cage) plutôt que d’être désactivé. Le bridage implique des limites LVE plus strictes et une limitation de débit, tandis que le site reste en ligne et fonctionnel, et il se rétablit automatiquement dès que la cause disparaît. Vous êtes informé(e) du motif, la transition est consignée avec ses preuves et elle peut faire l’objet d’un recours. Si la charge est due à une croissance réelle plutôt qu’à une anomalie, la solution consiste en un forfait supérieur, et non en un bridage permanent.

Un site suspendu devient-il simplement vide ?

Non — un site suspendu affiche une page d’attente personnalisée indiquant la raison spécifique (facturation, maintenance ou abus) afin qu’il apparaisse comme délibérément indisponible et non en panne. La suspension est levée après paiement, correction ou recours. La mise en quarantaine est plus stricte et fonctionne différemment : elle n’est levée qu’après nettoyage et examen, jamais automatiquement.

Puis-je choisir ma propre version et mes propres extensions PHP ?

Sur Zinn® Managed WordPress, oui — CloudLinux alt-PHP offre à chaque site son propre sélecteur de version PHP, ses propres extensions telles que imagick, gd et redis, ainsi que ses propres paramètres renforcés, le tout encadré par les limites LVE de ce site. L’hébergement Footprint-Free applique délibérément une configuration par site plus standardisée et verrouillée, car la diversité des configurations constitue en elle-même une empreinte (footprint).

Existe-t-il une option d’isolation plus forte que le modèle à noyau partagé ?

Oui. CloudLinux LVE et CageFS constituent la valeur par défaut optimisée pour la densité sur les deux gammes de produits. Pour les charges de travail nécessitant une délimitation plus stricte, une isolation complète par conteneur individuel par site est proposée en tant que variante du pilote de provisionnement — le même moteur et le même plan de contrôle avec un placement différent, échangeant de la surcharge contre une séparation plus forte.

Puis-je l’essayer avant de m’engager ?

Oui. L’hébergement Footprint-Free commence par un essai de 14 jours sans carte bancaire couvrant jusqu’à cinq sites — aucune information de paiement requise, aucun engagement. Déployez quelques sites, appliquez-leur une certaine charge et observez le comportement des cages avant de prendre votre décision.

Voyez comment les cages se comportent sous votre propre charge

Commencez un essai de 14 jours sans carte bancaire sur l’hébergement Footprint-Free — jusqu’à cinq sites, sans coordonnées de paiement, sans engagement. L’isolation au niveau du noyau, le WAF proactif et l’analyse des logiciels malveillants sont inclus dès le premier déploiement.

Commencer gratuitement