CloudLinux OS 9 : fonctionnalités et limites en hébergement mutualisé

Bien comprendre CloudLinux OS 9

CloudLinux OS 9 est une génération de système d'exploitation dont la documentation est toujours disponible pour hébergement partagé basée sur AlmaLinux 9. Elle ne doit toutefois pas être confondue avec CloudLinux OS 10, que le fabricant considère comme une branche majeure distincte. Le numéro de version à lui seul ne décrit ni l'étendue de la licence ni les composants d'hébergement mutualisé disponibles sur un serveur donné.

Pour la classification, il faut tenir compte du Noyau AlmaLinux Important : CloudLinux OS 9 n'utilise plus son propre noyau CloudLinux, mais celui d'AlmaLinux. C'est pourquoi la présence d'un élément de nom tel que „ LVE “ dans la version du noyau ne constitue pas un critère approprié pour évaluer l'isolation active des ressources. La présence de LVE doit être vérifiée via les composants CloudLinux installés et leur état de fonctionnement, et non via la chaîne de caractères figurant dans le nom du noyau.

Cette distinction permet d'éviter une idée fausse très répandue concernant un Mise à jour de CloudLinux: Une mise à niveau vers OS 9 ne remplace pas la vérification des limites, de CageFS, des gestionnaires PHP ou du contrôle de la base de données. La version du système d'exploitation fournit la base technique ; les fonctionnalités visibles pour les clients dépendent de la combinaison de la licence, des packs et de l'intégration au panneau de contrôle. Ces niveaux peuvent varier les uns par rapport aux autres, en particulier sur les serveurs qui ont évolué au fil du temps.

En option, pour CloudLinux OS 9, un Noyau LTS disponible. Selon le fabricant, il contient des correctifs de sécurité et intègre moins de modifications en amont que le noyau AlmaLinux standard. Cela peut convenir aux environnements où la planification des changements est prudente, mais ce n'est pas nécessairement un meilleur choix dans tous les cas. Les fournisseurs doivent évaluer les exigences en matière de pilotes matériels, de logiciels utilisés, de processus de maintenance et de stratégie de noyau pour l'ensemble de leur parc de serveurs.

Distinguer clairement les éditions et les licences

Le numéro de version « CloudLinux OS 9 » ne désigne ni une édition ni une licence. En matière d'hébergement mutualisé, il convient notamment de distinguer CloudLinux OS Legacy, anciennement CloudLinux OS Shared, de CloudLinux OS Shared Pro. Legacy prend en charge un nombre illimité de comptes d'hébergement et comprend des composants bien établis tels que LVE, CageFS, MySQL Governor, PHP Selector et les sélecteurs de langue.

Shared Pro doit être considéré séparément : l'aperçu des éditions attribue à cette édition des fonctionnalités telles que PHP X-Ray, Centralized Monitoring et AccelerateWP. Une mise à jour CloudLinux de la version OS 8 vers la version OS 9 n'active donc pas ces fonctionnalités si la licence Pro correspondante et les conditions d'installation et de panneau de contrôle requises ne sont pas remplies.

CloudLinux OS Admin n'est pas non plus une version allégée de Shared Pro. Cette édition cible un autre niveau de fonctionnalités ; entre autres, elle ne comprend pas MySQL Governor. Si vous souhaitez limiter la surcharge d'une base de données par compte d'hébergement, vous ne devez donc pas déduire la disponibilité de cet outil uniquement à partir d'une installation CloudLinux existante.

Avant de garantir le bon fonctionnement, il convient de répondre séparément à trois questions : quelle édition est sous licence, quels paquets sont installés et le panneau existant prend-il en charge le composant souhaité ? De plus, les versions des différents paquets peuvent modifier les prérequis. Une conversion réussie du système d'exploitation ne prouve que la réussite de l'étape de conversion ; elle ne confirme pas automatiquement que tous les modules optionnels sont opérationnels.

Isolation et limites de l'hébergement mutualisé

Dans le cadre de l'hébergement mutualisé, LVE la mission consistant à limiter la consommation de ressources par compte. Cela inclut notamment l'utilisation du processeur, la mémoire vive, les opérations d'entrée-sortie, les processus et les accès Web simultanés. Si un projet atteint ses limites, sa consommation ne doit pas peser de manière disproportionnée sur les autres comptes. Il s’agit d’une protection contre la surconsommation, mais pas d’une correction automatique des applications lentes ou des requêtes de base de données erronées.

Dans le cas des offres destinées aux revendeurs, les limites de revendeur viennent compléter les limites du compte. Elles limitent la consommation cumulée des sous-comptes d'un revendeur. Certains forfaits peuvent théoriquement offrir des valeurs plus élevées, mais les sous-comptes ne peuvent pas, ensemble, dépasser la limite globale. Cela rend les capacités et les engagements tarifaires plus transparents, mais nécessite une planification adaptée de la limite globale.

CageFS poursuit un objectif différent de celui de LVE : celui de Isolation du système de fichiers limite l'environnement système visible d'un utilisateur et vise à empêcher l'accès aux fichiers d'autres comptes d'hébergement. Elle ne remplace toutefois pas une architecture de sécurité complète. Sur les serveurs cPanel, la documentation du fabricant cite notamment WebDAV, le gestionnaire de fichiers, la messagerie Web et les serveurs FTP sans « chrooting » correct comme des cas de figure dans lesquels CageFS n'est pas efficace. La protection des liens symboliques et une configuration sécurisée des services restent des tâches distinctes.

PHP Selector permet de sélectionner des versions et des extensions PHP mises à disposition de manière centralisée et nécessite l'installation de CageFS. MySQL Governor surveille l'utilisation de la base de données par utilisateur et peut limiter les comptes qui surchargent le système ; mod_lsapi, quant à lui, est un gestionnaire PHP pour Apache. Ces composants se complètent, mais ne sont pas interchangeables. Leur disponibilité et leur combinaison optimale dépendent de l'édition, du serveur web et de la configuration.

L'intégration du panneau de contrôle nécessite une attention particulière. Sur les systèmes cPanel, les clients ne devraient pas trouver à la fois le sélecteur PHP et une option MultiPHP concurrente comme des options équivalentes, car cela peut entraîner des paramètres contradictoires. De plus, tous les panneaux de contrôle n'intègrent pas toutes les fonctionnalités dans la même mesure. Pour une distinction plus approfondie entre l’isolation des comptes et celle des sites web, consultez l’article consacré à SecureLVE et l'isolation des processus dans l'hébergement mutualisé; toutefois, la licence, la prise en charge documentée du panneau et la configuration concrète du serveur restent déterminantes.

Sélectionner les composants en fonction de l'application

Pour faire votre choix, c'est l'activité concrète de l'entreprise qui compte, et pas seulement l'appellation « CloudLinux OS 9 ». Le système d'exploitation, l'édition, la licence, les paquets installés et le panneau de configuration constituent autant de critères à vérifier séparément. Les extensions Shared-Pro ne sont pas automatiquement disponibles lors d'une mise à niveau du système d'exploitation ; il convient d'examiner conjointement l'aperçu des éditions et les exigences de chaque composant.

Ce tableau sert d'aide à la décision et ne constitue pas une autorisation d'installation. Avant de donner ton accord, vérifie la version du panneau prise en charge, le gestionnaire PHP, la licence spécifique et la version du paquet. CloudLinux documente ses propres conditions d'intégration pour chaque composant ; c'est pourquoi une fonctionnalité qui existe en principe peut faire défaut dans un environnement de panneau donné ou être gérée différemment.

Cette distinction est particulièrement importante pour la planification tarifaire : Limites LVE protègent la capacité partagée du serveur au niveau du compte, tandis que les limites de revendeur fixent un plafond commun supplémentaire pour les sous-comptes. CageFS, PHP Selector et MySQL Governor remplissent quant à eux d'autres fonctions. Le choix d'un composant doit donc découler du goulot d'étranglement observé ou du besoin de protection, et non d'une liste de fonctionnalités générique.

Planifier efficacement les limites et la gestion de PHP

Lorsqu'une boutique WordPress génère des pics de charge, les limites du compte restreignent l'utilisation du processeur, de la mémoire vive, des opérations d'entrée-sortie, des processus ainsi que des accès Web simultanés. Cela permet de maintenir la consommation du compte concerné dans des limites définies et peut protéger les autres comptes contre une surconsommation. Pour analyser les causes, il est essentiel de déterminer quelle limite est effectivement atteinte, plutôt que de se contenter de supposer un ralentissement général du serveur.

Le fait d'atteindre une limite ne permet toutefois pas de diagnostiquer le problème de la boutique en ligne. Une extension défectueuse, des requêtes de base de données coûteuses, une importation ou l'absence de mise en cache peuvent être à l'origine de la charge. Des valeurs plus élevées repoussent la limite, mais n'éliminent pas la cause. Vérifiez donc d’abord les données relatives aux ressources et l’application ; ce n’est qu’ensuite qu’il convient de décider si une optimisation, un autre forfait ou une capacité supplémentaire est appropriée.

Chez un revendeur proposant de nombreux petits forfaits, une Limite des revendeurs les limites de chaque client final. Les sous-comptes peuvent chacun avoir leurs propres valeurs, mais leur consommation totale cumulée ne doit pas dépasser la limite supérieure. Cela empêche un revendeur d'utiliser, en raison du nombre de clients actifs, plus de ressources que ce qui est prévu pour son offre.

Pour PHP, il convient de définir exactement une seule interface de sélection claire par compte client. Le PHP Selector nécessite CageFS. Sur les systèmes cPanel, une utilisation parallèle avec MultiPHP peut entraîner des incohérences si les clients modifient les versions à différents endroits. Définissez donc quelle interface est visible, quelles versions sont autorisées et qui gère les exceptions.

Cet article interne explique comment les termes CPU, PMEM, I/O, IOPS, EP et NPROC peuvent être traduits en profils tarifaires concrets. Configurer correctement CloudLinux LVE Manager dans un hébergement mutualisé. Les valeurs indiquées ici ne sont pas automatiquement transposables à tous les matériels ou à toutes les architectures client. Les performances de stockage, la composition des applications et l'analyse des défaillances réelles restent des facteurs déterminants pour chaque configuration.

Isoler plusieurs sites web par compte

Un seul compte d'hébergement comprend souvent le site principal, la boutique en ligne, l'environnement de test et les projets clients. La limite du compte ne suffit pas à elle seule à séparer ces applications les unes des autres. CloudLinux Isolates est globalement qualifiée de « bêta » par le fabricant. Cette fonctionnalité permet de mettre en place une isolation du système de fichiers par domaine, de sorte que l'accès d'un site web aux fichiers d'autres sites web du même compte soit restreint. Elle constitue donc une option à envisager pour les comptes comportant des projets présentant des niveaux de risque ou des responsabilités différents.

Les limites LVE par domaine constituent un cas à part. Elles permettent de limiter les ressources au niveau de chaque site web, et non plus uniquement au niveau du compte client dans son ensemble. CloudLinux qualifie également explicitement cette couche de « bêta » et la mentionne pour les versions OS 8 et OS 9. La séparation du système de fichiers et les limites de ressources par domaine constituent donc deux niveaux distincts avec des conditions préalables différentes.

• Pour les limites LVE des domaines, CloudLinux recommande au minimum les versions lve-stats3 5.1.0-1 et lve-utils 6.6.40-1.
• Le gestionnaire PHP et le panneau de configuration doivent prendre en charge la configuration d'Isolates correspondante.
• La séparation des systèmes de fichiers par domaine peut être possible, même si les conditions requises pour les limites par domaine ne sont pas encore remplies.

Tu dois donc vérifier ces conditions séparément : tout d'abord, si la fonctionnalité bêta « Isolates » est documentée avec le panneau de configuration et le gestionnaire utilisés pour la couche de système de fichiers souhaitée, puis les versions des paquets et le statut bêta des limites de ressources. Pour LiteSpeed en version autonome, CloudLinux ne documente actuellement la prise en charge que de cPanel. Il ne faut pas en déduire que d’autres combinaisons envisageables bénéficient d’une prise en charge équivalente.

La fonctionnalité « Isolates » peut réduire le périmètre d'action au sein d'un compte, mais ne remplace pas la maintenance des applications. La mise à jour des plugins, l'utilisation d'identifiants distincts, les sauvegardes et une gestion appropriée des droits restent indispensables. Pour un compte comportant plusieurs projets clients indépendants, la Isolation des domaines après un test de compatibilité documenté, cela pourrait néanmoins constituer une limite supplémentaire plus adaptée que les seules limites communes aux comptes.

Préparer la migration vers OS 9

La migration vers CloudLinux OS 9 est une conversion planifiée et non une simple mise à jour de paquets. Elle peut avoir des répercussions sur les paquets installés, les configurations des dépôts et l'intégration du panneau d'hébergement. Avant de commencer, vérifie donc le système d'exploitation d'origine, l'architecture du processeur, l'environnement de virtualisation et la prise en charge de l'intégration CloudLinux par le panneau de contrôle concerné.

Définissez une fenêtre de maintenance et travaillez à partir de sauvegardes complètes et testées ou d'instantanés de machines virtuelles cohérents, qui peuvent être restaurés conformément à la procédure de restauration en vigueur. En tant que bonne pratique administrative, il est également recommandé de documenter au préalable les sources de paquets, les services actifs et les configurations divergentes. Cela permet de retracer de manière ciblée les différences après la conversion, sans pour autant considérer la documentation comme un substitut à une sauvegarde.

Une fois la migration effectuée, la vérification ne doit pas s'arrêter à la réussite de la conversion. Vérifiez les référentiels intégrés ainsi que l’intégration au panneau de contrôle, et traitez les composants supplémentaires séparément. PHP Selector, X-Ray ou AccelerateWP ont leurs propres exigences en matière d’installation, de licence et d’intégration au panneau de contrôle ; le fait que la base OS-9 soit opérationnelle ne garantit pas automatiquement leur disponibilité.

Une limite importante concerne le chemin de version : la conversion conserve la version majeure de la base de départ. Elle ne transforme donc pas directement un système CentOS 7 en un système CloudLinux OS 9. Pour un tel changement de génération, tu as besoin d'un processus de migration adapté, par exemple une réinstallation avec transfert des données et des comptes, plutôt que de considérer la conversion comme une mise à niveau couvrant plusieurs versions majeures.

Vérifier les paquets, le noyau et les erreurs

Après l'installation ou la mise à niveau, le test de fonctionnement commence par un état des lieux. Vérifiez d'abord le noyau en cours d'exécution. CloudLinux OS 9 utilise le noyau AlmaLinux ; l'absence de la partie „ LVE “ dans la sortie ne signifie donc pas que les fonctionnalités LVE sont manquantes. La commande se contente de lire la version du noyau actuellement en cours d'exécution.

uname -r

Ensuite, vous vérifiez les paquets principaux installés. Le résultat affiche les noms des paquets et leurs versions, ou signale si un paquet n'est pas installé. Cela ne remplace ni la vérification de la licence, ni la vérification que le panneau de configuration utilisé intègre correctement l'interface et les fonctionnalités correspondantes.

rpm -q lve lvemanager cagefs lve-utils

Si vous souhaitez évaluer les limites par domaine à l'aide de CloudLinux Isolates, vérifiez également les versions des paquets documentées à cet effet. Cette requête ne modifie aucune configuration. Les LVE par domaine sont signalées comme étant en version bêta ; un numéro de version de paquet correspondant ne garantit donc pas à lui seul la compatibilité pratique du gestionnaire PHP ni la prise en charge par le panneau de contrôle.

rpm -q lve-stats3 lve-utils

Pour l'analyse des causes, il faut Erreurs et les données relatives aux ressources sont plus pertinentes qu'une augmentation forfaitaire de toutes les limites. Lorsqu'un compte atteint une limite, tu détermines d'abord si ce sont le processeur, la mémoire vive, les E/S, les processus ou les accès simultanés qui sont concernés. Vous examinez ensuite l'application et les requêtes de base de données, évaluez la mise en cache et, en cas de besoin permanent, réévaluez la capacité ou le niveau de forfait.

Éviter les idées reçues courantes

Il est important de préciser que « CloudLinux OS 9 » désigne la génération du système d’exploitation, et non l’ensemble des fonctionnalités d’une licence d’hébergement. CloudLinux OS 10 constitue une branche majeure distincte ; les informations concernant OS 9 ne s’appliquent donc pas automatiquement à OS 10. Shared Pro reste par ailleurs une édition à part entière, dotée de fonctionnalités supplémentaires telles que PHP X-Ray, Centralized Monitoring et AccelerateWP.

De même, une conversion réussie ne doit pas être considérée comme une mise en service complète de tous les modules. Après la migration, la connexion au panneau de contrôle, les versions des paquets, l’étendue des licences et les conditions requises pour chaque fonctionnalité supplémentaire doivent être vérifiées séparément. Cela permet d’éviter de promettre aux clients des fonctionnalités qui, bien qu’elles puissent faire partie de l’édition choisie, ne sont pas encore configurées ou prises en charge sur le serveur concerné.

Les « Isolates » de CloudLinux nécessitent une grande prudence. La documentation du fabricant précise que les « Isolates » sont globalement en version bêta. De plus, la séparation des systèmes de fichiers entre les sites web au sein d’un même compte et les limites LVE optionnelles par domaine ne doivent pas être confondues ; les limites par domaine sont elles aussi expressément en version bêta. Avant toute mise en service, il convient de vérifier les gestionnaires PHP, le panneau de configuration et les prérequis des paquets indiqués dans la documentation.

Voir aussi Limites de ressources ne permettent pas d'identifier les causes au sein d'une application. Pour l'analyse de l'exploitation, il est judicieux d'évaluer d'abord les « Faults » et le type de ressource concerné : CloudLinux peut signaler les dépassements de limites pour le CPU, la mémoire, les E/S, les IOPS, les connexions simultanées et les processus. Ce n’est qu’ensuite que vous évaluez l’application, les requêtes de base de données, les tâches cron et la mise en cache, ainsi que la question de savoir si une capacité supplémentaire est réellement nécessaire.

Pour la prise de décision opérationnelle, les limites par compte suffisent lorsque l'objectif est avant tout de séparer les projets des clients les uns des autres et de limiter les pics de charge. Les limites de revendeur sont également adaptées lorsqu’un revendeur doit restreindre la capacité globale de ses sous-comptes. L’isolation des sites web doit être considérée comme une option bêta pour plusieurs projets présentant des niveaux de risque différents au sein d’un même compte, mais uniquement après un test de compatibilité documenté et avec une indication claire de leur statut.