Serveur web mutualisé (2/5) : Les limites

05/02/2014 Mickael Dorigny 0 commentaire Cloud

Sommaire

I. Présentation
II. Un espace dans un Datacenter avec des limites ?
- A. Disque dur, RAM, CPU, Réseau
- B. Tu ne seras pas libre de ta configuration !

I. Présentation

Dans un précédent billet, j'ai tenté d'expliquer de façon non technique ce qu'était un serveur et un hébergement web mutualisé. Nous avons vu que ce type d'hébergement permettait d'avoir assez simplement un espace qui nous est réservé dans l'infrastructure d'un hébergeur afin d'y mettre nos sites web et nos applications web. Nous allons ici voir les différentes limites que peut présenter le choix d'un hébergement dans un serveur web mutualisé.

II. Un espace dans un Datacenter avec des limites ?

Eh bien oui, un hébergeur a tout intérêt, pour que la colocation de tous ses clients se passe bien au sein d'un même serveur, à instaurer des limites (voulues ou non), par le biais de droits par exemple mais aussi techniquement. Nous avons précédemment vu qu'un serveur web mutualisé consistait en l'utilisation d'une même ressource (la plus simple étant l'espace du disque dur) par plusieurs clients (comprendre sites web). Un site web (avec sa base de données) peut avoir une taille qui varie de quelques Mo à plusieurs Go assez facilement. Les ressources n'étant pas illimitées (bien que très abondantes dans un Datacenter), il est important de cadrer les choses pour que chacun reste à sa place est n'empiète pas sur l'emplacement des autres.

Dans une démarche plus logique, on ne peut admettre que sur un serveur web mutualisé, une base de données du site1 occupe 80% de l'espace disponible sur notre disque dur (en simplifiant, en réalité on a plutôt affaire à des clusters de baie de disque..) et que les centaines de clients restant se contentent du reste. On aurait alors affaire au même rush que pour les noms de domaines au début de l'ère Internet : premier arrivé, premier servi. Ce ne sera pas admissible et cela irait à l'encontre de l'offre que fait l'hébergeur.

Pour revenir à nos restrictions, quand vous louez un espace chez un hébergeur sur un serveur web mutualisé, vous louez un espace qui est très strictement contrôlé et suivi. Ces restrictions sont à taille variable bien sûr, variable selon le prix que vous y mettez. Disons par exemple qu'une offre standard vous offrira l'accès à 10 bases de données de 50 Mo max chacune, que votre espace web fera quelque giga et que vous aurez droit à mettre en place une dizaine de comptes FTP différents (accès utilisateurs). Plus rarement (pas tant que ça), les hébergeurs mettent également en place une restriction au niveau du transit (attention à la différence entre transit et débit que j'ai précisé dans mon précédent billet). Par exemple au-delà de la consommation de 5 Go de transit au cours du mois, votre accès sera fortement limité en débit (votre site se chargera plus lentement). Certains hébergeurs coupent même directement l'accès au site web (après un avertissement pour les chanceux), réfléchissez y donc à deux fois avant d'y placer un site web d'e-commerce par exemple !

Ok, mais donc si le site de mon concurrent est sur ce type d'hébergement, je n'ai qu'à lui envoyer 5 Go de transit le 1er du mois et son site sera handicapé jusqu'au mois suivant ?

La réponse est oui, un sacrée limite n'est-ce pas ? On est d'accord, il s'agit d'un cas de réflexion et d'action plutôt rare.

A. Disque dur, RAM, CPU, Réseau

Nous avons pris précédemment un exemple avec l'espace disque de notre hébergement. Mais la même réflexion est valable pour les ressources plus volatiles et dynamiques. Si mon site web utilise du PHP et que pour chaque requête, une page dynamique est calculée, puis construite, puis envoyée, il y a consommation de CPU ainsi que de RAM. Pour un seul site web, ce calcul (même avec beaucoup de requêtes simultanées), n'a pas un effet désastreux sur le serveur en lui-même. En revanche quand des milliers de requêtes arrivent sur des milliers de sites web différents qui calculent des milliers de pages différentes avec les millions de variables et opérations qui vont avec, là ça peut avoir de l'effet.

En reprenant l'exemple des 80% d'espace disque consumé par mon "client1" de tout à l'heure, imaginez la même chose pour une consommation CPU. Plus clairement, le pourcentage CPU utilisé pour un site les rend indisponibles pour les autres. Si un site se fait attaquer (par exemple) et que le CPU/RAM se voit accaparé par le calcul de ses pages web au détriment des autres sites, il est plutôt difficile de lui en empêcher. Cela reste possible par des systèmes de sécurité que votre hébergeur aura (ou pas) mis en place mais ils sont plutôt rare.

Encore une fois, la réflexion peut s'étendre à la partie réseau qui peut être assimilée en schématisant à une autoroute. Les requêtes (voitures) qui passent dans le tuyau pour aller questionner un site, c'est une place en moins sur la route pour les autres sites.

Entendons-nous bien, les Datacenter hébergeant des serveurs web mutualisés ou assimilés prennent soin de calibrer leur infrastructure en conséquence (On atteint facilement les 10G au niveau du débit réseau). Cependant, les effets de bords au niveau CPU/RAM dû à des attaques sont moins rares qu'on ne le pense.

Ces restrictions/limites sont les principales, elles sont obligatoirement présentes sur toutes les offres. Néanmoins, la majorité des offres imposent également des limites concernant un nombre maximal de fichiers présents sur l'hébergement, le nombre de connexions simultanées sur le service web/la base MySQL ou la mémoire allouée à PHP pour votre vHost, le nombre de requêtes MySQL, la taille maximale des fichiers, le nombre d'update MySQL sans parler des limites d'envoi de mail qui est un service dont nous ne parlons pas ici. Il faut donc être prudent et au fait des visites et ressources dont doit disposer votre site web avant d'aller l'héberger sur un serveur mutualisé.

B. Tu ne seras pas libre de ta configuration !

Nous avons précédemment vu que l'un des avantages de l'hébergement mutualisé est que nous n'avons pas à nous occuper de la configuration et du maintien de notre infrastructure et serveur web. Cela signifie également que si l'hébergeur ne souhaite pas mettre à jour la version de PHP qui vient de voir découvrir une faille de sécurité très inquiétante pour votre site web, il ne le mettra pas à jour.

Il peut également arriver que vous ayez besoin d'un module supplémentaire, d'une fonction présente dans la version X+1 de PHP, de MySQL ou du service web utilisé. Auquel cas votre hébergeur vous orientera vers un serveur dédié (plus cher). C'est une limite que les techniciens jugeront critiques. Même si pour les blogs/sites "standards", les hébergeurs prennent en général soin d'activer les fonctionnalités et modules souvent utilisés. Nous verrons que cela est un bien comme un mal car certaines de ces fonctions sont parfois dangereuses et qu'il est généralement judicieux de les désactiver. Seulement en faisant cela, l'hébergeur ferme la porte à certains clients...

Pour la même raison, nous ne pourrons pas installer n'importe quel outil sur notre serveur web, on ne pourra pas (par exemple) changer le port de son accès FTP pour "brouiller les pistes", il ne nous restera plus qu'à espérer que notre hébergeur aura pris certaines dispositions pour protéger notre accès (ce qui est loin d'être systématique).

On observe donc que le serveur web mutualisé présente, pour des cas de figure de configurations un peu plus techniques, des limites :

Au niveau des ressources disponibles.
Au niveau de la liberté de configuration.
Au niveau de l'utilisation de l'accès.

La mutualisation implique un ensemble de bonne conduite qui dépend d’une part de l’hébergeur qui se doit de mettre à disposition de ses clients son expertise technique notamment au niveau de la sécurité mais d’autres part de l’ensemble des clients qui mettent du contenu sur leur espace pouvant être vu comme vulnérable. La mutualisation d’un serveur web peut s’apparenter à la location d’une chambre dans une maison, on est restreint dans l’espace que nous avons mais nous ne savons pas à côté de qui nous le louons et ce que les autres en font !

Les autres articles :