Le vocabulaire des hébergeurs et infogérants est parfois déroutant.

Finalement est-ce que 42 Mo de cache level 9 valent mieux que deux troupeaux de gnous encadrés par des pingouins ? Well difficile à dire si l’on ne parle pas des mêmes choses. Déjà la notion d’hébergement et d’infogérance fait débat, alors voici une tentative pour clarifier les choses.

Le but de cet article est donc, avant tout, de parler le même langage et de présenter de manière simples des concepts qui ne sont sommes toutes pas si complexes qu’on voudrait bien nous le faire croire.

Bande passante, tuyau et réseau

Bandwidth, bande passante

La bande passante, c’est la capacité du lien qui arrive aux serveurs. Ainsi, quand un infogérant ou un hébergeur vous propose une connexion, il vous parle de bande passante. Certain parlent de la capacité total de transfert sur un mois, par exemple 100 Go, d’autre d’une vitesse en Mb/s ou Mbps (Megabits par seconde). 8 bits = 1 octet (ou byte en anglais) donc 1 Mb/s font une vitesse de transfert de 128 Ko/s, cela peut paraitre ridicule car chez le particulier, les FAI vendent parfois du 5, du 10 ou du 20 Mbits/seconde.

Plus puissant que la bande passante de votre hébergeur ? Non.

Déjà 1 Mbps qui tourne à plein sur 24h, ca représente une capacité de transfert de ~1,4 Go. Deux films. Donc ca n’est pas ridicule comme unité, de surcroit, la bande passante des hébergeurs et infogérants est “symétrique”. On parle donc de bande passante symétrique quand la capacité d’envoi est la même que la capacité de réception.

En l’occurrence, chez vous, Free, Alice, Wanadoo et leurs copains vous propose de la bande passante de, par exemple 10 Mbps en download (téléchargement) et de 1/n de cette valeur en upload (envoie de données), en général 1/8, donc ~150 Ko/s.

Un hébergeur qui vous met à disposition 4 Mbps vous fournit 4 Mbps en réception comme en envoie et devinez quoi, ca ne coute pas du tout le même prix un lien symétrique, c’est nettement plus cher car c’est la bande passante dite “montante”, celle en envoie, qui coûte cher.

L’un des soucis sur ce point c’est que les offres présentent tantôt du trafic mensuel et tantôt de la bande passante dédiée. Si je vends 4 Mb/s de bande passante, ca fait un peu ridicule comparés au 500 Go/mois que me propose mon concurrent… Et pourant…

4 Mb/s * 3600 (pour le débit horaire) * 24 (pour le débit jour) * 30 (pour le débit mois) / 8 (pour avoir des Méga octets) = 1 296 000 Mo / mois soit ~1,3 To.

Ooops (Oook pour les initiés) une offre à 4 Mb/s est largement plus intéressante qu’une offre à 500 Go /mois et de loin !

Ratio de contention

Le ratio de contention est un indice permettant de savoir avec combien de personne on partage une bande passante donnée. Typiquement, ce ratio est peu utilisé en France (qui dispose d’excellentes infrastructures télécom dans l’ensemble) mais très présente en Angleterre ou aux US. Dans certain contextes comme l’usage d’une connexion satellitaire c’est une limitation indispensable.

L’idée c’est qu’avec un ratio de contention de 20:1 (lire 20 pour 1) on a 1 Mbps (un mégabit par seconde) de vendu à 50 personnes. Comme elles ne l’utilisent pas toute en même temps, l’opérateur prend (et vend) le risque statistique qu’en moyenne, tout le monde ne l’utilise pas en même temps. Le pire cas serait que les 50 personnes aient toutes besoin en même temps du même mégabit de bande passante mais cela n’arrive en pratique jamais.

Ceci étant, on est donc pas garantie de la capacité maximale de son tuyau de connexion, généralement montant puisque la contention s’applique la plupart du temps sur le sens de l’envoi de donnée et rarement sur celui de réception de données.

C’est à ne pas confondre avec une autre notion qu’est l’ADSL vs SDSL. L’Asymetric Digital Suscriber Line contient, par défaut, une notre d’asymétrie dans les débits, généralement de 1 pour 8. On peut télécharger huit fois plus vite que l’on ne peut envoyer des données. Les Symetric Digital Suscriber Line sont elles totalement symétrique en termes de débits, fournissant ainsi la même capacité d’envoi que de réception de données.

Les deux systèmes ont été conçus pour “épargner” la bande passante montante (l’envoi de donnée) à l’époque ou cette ressource était coûteuse, mais ne relève pas exactement des mêmes mécanismes.

95 percentiles

Le percentile est une notion qui s’applique à la bande passante. En effet, les opérateurs ont remarqué que les tuyaux Internet étaient chargés de manière non linéaire. De plus, la capacité des liens augmentant, pourquoi ne pas mettre à disposition la bande passante inutilisée, dans une certaine mesure.

Le 95 percentiles c’est cela. C’est proposer à un client de dépasser son quota, par exemple de 4 Mbps jusqu’à concourrance de la taille maximum de la connexion, par exemple 100 Mbps. Tant que le client ne dépasse pas 95% du temps, les 5% de dépassement, peut importe le dépassement, ne sont pas facturés. Par contre si il dépasse 5,1% du temps, la totalité du dépassement lui est facturé, généralement à un coût légèrement supérieur. J’ai 4 Mbps, je dépasse à 40 Mbps pendant 30 heures dans le mois, je reviens en dessous par la suite, je ne suis facturé que de 4 Mbps. J’ai 4 Mbps, je dépasse à 80 Mbps plus de 5% du temps, ca fait au final, de manière lissée, une consommation moyenne de 7 Mbps, je paye les 4 de base plus 3 en tarif “dépassement”.

Peering

Le peering est un autre point différenciant entre les différents opérateurs et FAI. Le peering c’est la carte des accords interopérateurs en fait. Si j’ai une connexion directe avec Free et une autre avec Orange, mes clients passant par Free ou Orange iront plus vite au but que s’ils doivent passer par un autre (ou plusieurs autres) tiers avant de me joindre. Avoir de bons accords de peering augmente donc l’efficacité de la rapidité des liens.

Avoir de nombreux accords peering avec plusieurs autres opérateurs permet donc d’avoir un échange de paquets plus rapide entre les parties.

Transist

Le Transit IP c’est un terme qui décrit le fait d’avoir une connexion vers l’extérieur. En fait dans un datacenter on peut avoir besoin de relier ses serveurs entres eux et très peu vers Internet ou l’inverse. Le Transit c’est donc la capacité de communication entre le point d’hébergement et Internet. On parle de Transit IP, Transit Internet, Tansit de 20 Mb/s etc… C’est donc la bande passante vers Internet en résumé même si le terme est parfois utilisé pour parler d’un transit d’un point à un autre.

Commit

Le commit c’est l’engagement prit entre un hébergeur et un opérateur.

Avoir un Commit de 50 Mb/s vous donnera accès à une tarification A et avoir un commit de 200 Mb/s un tarif B. Le commit c’est la réservation du tuyau qui vous est faite en réalité, la taille que l’opérateur vous doit. D’ailleurs to commit en Anglais veut dire s’engager.

QoS

Quality of Service.  C’est un terme au sens double puisque l’on peut parler de qualité d’un service ou du principe technique de qualité de service, ce qui est différent. La plupart du temps, quand l’acronyme QoS est utilisé, cela réfère au principe technique.

La QoS permet de régler des valeurs spécifiques dans certains des champs dans paquets qui sont envoyés sur le réseau pour privilégier un comportement ou un autre. Il faut que les éléments actifs (routeurs, siwtchs etc…) sur le chemin accepte de prendre en compte le champ de QoS et sache quoi en faire mais dans le principe les opérateurs utilise la QoS à bon escient.

Les valeurs de QoS peuvent par exemple être : “achemine le plus vite possible”, “achemine avec la latence minimum le premier paquet”, “ne fragmente pas les paquets” ou même d’ordre interne “premier arrivé premier servit”, “fair queuing” etc…

Ces mécanismes sont utilisés pour optimiser les routes et le trafic en fonction de sa sensibilité ou de ses besoins. (Par exemple une conversation VOIP supporte mal la latence mais à besoin de peu de débit).

Routeur/routage/BGP

Le Routage consiste à attribuer un chemin de parcours, une route, à une connexion. Les paquets à destination de telle machine ou réseau passe par un lien, ceux à destination d’un autre endroit par un autre. Le routeur est l’élément qui fait ces arbitrages et oriente les paquets.

Le BGP est un protocol (Border Gateway Protocol) qui permet l’échange de route entre les routeurs, notamment répandu sur Internet chez les opérateurs et entre les routeurs AS. Ce protocole sert aux grands routeurs (AS) à s’échanger des routages de réseaux entiers.

Shaping

Le Shaping c’est littéralement « mettre en forme » le trafic réseau. Il peut s’agir de le limiter la capacité maximale de transfert ou de donner une priorité à un flux ou une machine plutôt qu’à une autre.

On parle souvent de Trafic Shaping, le trafic shaper étant la machine en charge de réaliser cette organisation du trafic. Par extension, les QoS sont souvent appliquée par un shaper.

Load Balancer

Le load balancer est une machine, un serveur ou un boitier, capable de répartir le flux entrant et/ou sortant sur plusieurs liens ou plusieurs machines. C’est un lui qui va, par exemple si vous avez deux serveurs web frontaux, envoyer le premier client sur le premier serveur, le second sur le deuxième, le troisième sur le premier, le quatrième sur le deux etc… C’est du load balancing (balancement de la charge) entre serveurs.

Il existe bien sûr des algorithmes plus évolués pour faire cela et certains Load Balancer (charge parfois assumé par le Rproxy quand il s’agit de load balancing de serveurs) font des tests de charge pour connaitre le taux d’occupation des machines avant de confier la gestion d’un nouvel arrivant à un serveur ou un autre.

Le load balancer peut aussi être spécifiquement dédié aux liaisons, on parle alors de load balancing de connexions et non de serveurs. Il s’agit là d’utiliser deux ou plus connexions au mieux en fonction de leur charge actuelle et de leur disponibilité.

Hébergement, maintenance, architecture & support

Housing

L’Housing consiste, en général, à fournir uniquement l’espace, l’énergie et la climatisation au serveur.

Hosting / hébergement

L’hosting / hébergement consiste, en général, à fournir la même chose plus le serveur et la bande passante ainsi qu’un système de support et un panneau de contrôle basique.

Infogérance / Managed server : L’infogérance consiste à fournir, en plus de l’hébergement, un support niveau 1, un SN2 et un SN3 ainsi que du service autour de l’offre de base. Par exemple l’installation et l’entretient des serveurs, leur backup, la sécurité, le conseil, l’optimisation etc… La grande différence par rapport à l’hébergement est donc la valeur ajoutée humaine, le travail des spécialistes.

Cloud computing / Elastic Computing

Le Cloud computing a été classé par le groupe Gartner comme l’une des révolutions annoncées de cette décennie. Il consiste à exploiter un très grand nombre de ressources informatiques en les allouant à la volée en fonction de la demande. Par exemple Amazon, pour les besoins de son propre site, avait un système très important. Très vite compter en serveurs n’avait plus de sens et il fallait inventer des unités logiques et physiques, multipliables à l’infini et allouable au besoin, ainsi est né le Cloud Computing.

C’est, en résumé, une forme de “super cluster”. On ajoute parfois le terme Elastic ou élastique pour définir la capacité à augmenter ou réduire le nombre d’unités allouées en fonction du besoin réel. On parle alors d’Elastic Computing ou Elastic Cloud Computing. Cette forme de “super mutualisation” permet donc une rationalisation des usages, des méthodes et des dépenses.

SN 1 / SN 2 / SN 3, 24×7 / S.L.A

Le support des serveurs et applications nécessite différents niveaux de compétence. D’une manière générale, le Niveau 1 correspond à l’accueil de toutes les demandes pour orienter par la suite (escalader) vers le niveau supérieur si une réponse ne peut être apportée directement par le SN1 (Support Niveau 1). Le SN1 répond aux problèmes simples ou plus généralement aux FAQ, il doit résoudre ~70% des demandes.

Si ce SN1 ne peut venir à bout d’un souci client, il l’escalade au SN2. Les ingénieurs du SN2 vont étudier le problème plus en détail et faire les tests complémentaires pour apporter une solution au SN1 qui la répercutera au client.

Le SN3, quand il existe, se bat avec les problèmes les plus épineux. Problème de compatibilité entre un soft et un hardware, bug d’un firmware, sous optimisation d’un noyau etc… Normalement, ils n’ont pas de demandes mais quand ils en ont une, ca peut prendre quelques semaines car à ce stade, c’est de la R&D.

Le 24×7 correspond au fait de mener une action ou superviser 24 heures sur 24, 7 jours sur 7. Il faut faire attention à ce que cache cet acronyme car toutes les sociétés y glisse une couverture différente. De la simple supervision (nos sondes surveillent vos serveurs en continue et vous alerte en cas de soucis) au support offshoré (vous tombez au Maroc où quelqu’un qui ne vous connait pas répondra mais ne trouvera pas de solution) jusqu’à la prise en charge global par vos contacts habituels.

Le fait de tout faire, de jour comme de nuit, toute l’année, s’appel de l’astreinte. Cela consiste à faire tourner son staff par semaine ou par jour, pour qu’en permanence quelqu’un ait un téléphone auquel le support soit joignable. En résumer, ca plante, on se lève la nuit, on allume son PC et on regarde le souci. Là encore, il faut faire attention, toutes les entreprises ne prennent pas en charge sans surcout. Souvent vous payez donc le fait que l’ingénieur soit à disposition mais si vous lui demandez quelque chose, il vous facture en supplément, heureusement, ce n’est pas le cas partout.

Le S.L.A, c’est l’engagement de votre fournisseur de service vis-à-vis de vous. Combien de temps de coupure au maximum est il envisageable d’avoir, quel doit être la disponibilité moyenne de la plateforme, selon le type de pannes, en combien de temps il s’engage à vous remettre sur pied. S.L.A est un acronyme anglais qui veut dire Service Level Agreement, l’engagement sur le niveau de service.

MRTG/ Cacti / Oreon / Centreon / Mantis / OTRS

Tous ces outils sont la panoplie classique d’administration des TT (Trouble Ticket, ticket de support) et de supervision de l’activité. Les outils cités sont Opensource et concerne donc majoritairement le monde Linux. Il existe bien évidemment des outils payants et des outils pour Windows. Mantis s’occupe en général des tickets de la partie software (bugs) et OTRS des tickets d’hébergement.

Centréon et Oréon sont des consoles de supervision de l’activité du réseau et des serveurs. Ils permettent d’effectuer des tests de base (icmp) mais également des tests par scripts, plus évolués et se connecter à des services de type SNMP.

MRTG est généralement utiliser pour générer des graphiques et Cacti également présente une console assez agréable à lire.

SAAS / IAAS

S.A.A.S veut dire Software As A Service, IAAS, infrastructure as a service et bien sur, tout le principe du As A Service se développe et s’exporte à un peu tout et n’importe quoi. C’est devenu très marketing tout cela alors on obtient des CAAS (Cloud), et mon radiateur est un CAAS aussi (Chauffage As A service).

Bref, au-delà de la blague, l’idée de fond est d’externaliser le service et de le dimensionner à la volée en fonction du besoin du client.

Services / Démon / Daemon / Serveurs / fonctions

Un service, démon ou daemon est, en infogérance, un programme qui accueil des connexions clientes pour rendre un service. Par exemple, Apache et Mysql sont des services qui tournent sous forme de daemons (démons). PHP lui ne l’est pas car il est appelé au besoin et ne reste pas de manière permanente en mémoire (c’est rare en tout cas et souvent pas forcément bon signe).

Ces services/daemon/démons ont une ou plusieurs fonctions bien précises, par exemple apache sert des pages Web. Ces services tournent sur des serveurs (physiques).

Dns, registrar, Bind

Le DNS signifie Domain Name Service. Le principe c’est que ce service permet de donner une IP à partir d’un nom et un nom à partir d’une IP (l’autre sens). Quand une même IP à plusieurs sites, sur le serveur, ceci se caractérise par une gestion en VHOSTS, tous les noms de domaines arrivent sur la même machine et la même IP mais le contenu de la requête permet au service Web (Apache par exemple) de savoir vers quel contenu (le répertoire) rediriger le visiteur.

Bind, aussi appelé Named parfois, est le service le plus célèbre sous Unix pour gérer les associations nom/ip et réciproquement (reverse DNS).

Le Registrar est lui habiliter à enregistrer des noms de domaines auprès des autorités locales (Afnic pour le .fr par exemple) ou internationales (internic par exemple). Il enregistre donc les données pour le compte de l’utilisateur final. Gandi, OVH et de très nombreux autres s’occupent de ces services.

Rproxy / Squid/ Varnish / CDN / serveur de médias

Un Rproxy fait l’inverse d’un proxy. Au lieu de mettre en cache les requêtes sortantes des utilisateurs vers les serveurs distants, il met en cache les requêtes entrantes des utilisateurs vers les serveurs. En gros au lieu d’être à la sortie du réseau local des utilisateurs, il est en entrée des serveurs que ces utilisateurs contact.

Ces Reverse proxy se chargent de mettre en cache les éléments statiques (images, vidéos, css, ajax, html etc…) afin de ne pas solliciter les serveurs Web pour le faire. Quand la requête arrive, les pages dynamiques sont traitées par les serveurs Web, le reste vient souvent des Rproxy.

Les plus célèbres sont Apache (encore lui), Squid et Varnish. Les trois présentent des caractéristiques différentes mais peuvent remplir peu ou prou la même fonction.

Un CDN (Content Distribution Network) permet de faire la même chose qu’un Rproxy mais à une plus grande échelle car, en général, le contenu est délivré depuis un serveur géographiquement proche de vous. Si un fichier est posé sur un CDN (Akamaï par exemple), il sera servit depuis un serveur à Tokyo pour un Japonais et un serveur à Londres pour un Parisien. Ceci optimise les temps de transfert.

Un serveur de média permet de stocker tout cela sur un serveur dédié, le serveur Web est donc déchargé et le Reverse proxy également.

Nginx / Apache / Zeux / Lighttpd

Les 4 services pré cités sont des serveurs Web. Ils ont tous des performances différentes, des intérêts différents. Apache est le grand père de tous les services Web, il est complet, couvre tous les besoins mais a parfois une tendance à la boulimie de ressources.

Nginx est l’alternative qui monte en termes de performances, il est moins complet mais gère mieux les ressources. Zeus est un serveur Web payant qui affiche des performances très haut de gamme.

Lighttpd et tinyhttpd et leur centaine de copains sont des services Web simplissime et ultra légers, fait pour rendre un service minimal mais avec une consommation de ressources ultra légère.

Terminal / Accès shell / SSH

Les accès en terminal, aussi appelé Shell, sont fait, la plupart du temps, par SSH. SSH fonction à peu prêt comme l’ancien Telnet mais en crypté et il permet en plus de transférer des fichiers.

Cet accès peut avoir plusieurs niveaux, utilisateurs et administrateurs par exemple. Avoir un accès Shell donne accès aux outils d’administration Unix qui sont très puissants et permettent de gagner du temps, quelques posts ont été fait sur ce blog à ce sujet, notamment ici.

Uptime

L’uptime est le temps depuis lequel le serveur tourne sans avoir été éteint ou redémarré. Avoir un uptime élevé signifie que la machine est stable et bien entretenue et que les administrateurs savent s’en occuper sans la redémarrer. Selon les serveurs et leur usage, un reboot peut aussi être nécessaire, par exempe pour mettre à jour un Firmware ou un noyau.

Un de nos serveurs à NBS System, le mailer, à un uptime de 1096 jours, soit 3 ans ce jour !

Sessions Actives (SA) : nombre de personnes utilisant activement des ressources du serveur. Elles sont connectées et ont appuyées très récemment sur un bouton/lien/image, ce qui impose au serveur un traitement pour lui répondre, ou bien elles viennent de se connecter sur le site et attendent en retour la homepage.

Nombre Maximal de Sessions Actives (NMSA) :
Afin que le trafic reste fluide et que l’expérience de l’utilisateur soit correcte, on estime couramment que 5 secondes de temps de réponse constitue la borne haute de la zone de confort, un maximum. Le nombre de sessions actives doit donc toujours imposer au maximum 5s ou moins de temps de chargement à l’utilisateur.

Le nombre maximum de sessions actives s’entend donc comme étant “la limite du nombre de sessions actives à un même moment pour que chacune d’entre elle reçoive ses réponses en moins de 5 secondes”.

Sessions connectées (SC): Ce sont des sessions actives, telles que Magento les qualifie. Il garde le contexte de session de l’utilisateur afin de pouvoir lui apporter la réponse qu’il souhaite ou lui permettre de finaliser son achat. Dans cet état, une session connectée peut être inactive (l’utilisateur lit ce qu’il a reçu ou il ne regarde plus le site, mais il ne sollicite pas le serveur) ou active (équivalent d’une session active, il sollicite le serveur).

Visiteurs par jour : Personne ayant effectué session complète de surf entre minuit J-1 et minuit J.

Pages vues par jour : Nombre de pages vues de minuit J-1 à minuit J.

Voici quelques feedbacks, basés sur ce vocabulaire :

- L’activation du cache Zend fournit un gain de NMSA de 100% en doublant le nombre de NMSA (et donc celui de SA et de SC).

-> Le nombre de NMSA est passé, dans notre cas, de 25 à 50.

- L’ajout d’un index sur les customer_id on sales_order (non présent en 1.0.xxx) aide beaucoup sur les temps d’accès du backoffice. division par 4 du temps de chargement du BO en magento 1.0.xxx

- L’Opcode Cache APC founit un gain d’environ 40% de NMSA, nous testons actuellement d’autres opcode cache comme Eaccelerator, Xcache, ioncube, turck et les trois mod php : mod_php, php_cgi, php_fastcgi afin de déterminer la meilleure combinaison. Un autre serveur httpd qu’Apache sera éventuellement envisagé.

- Après plusieurs tests, le réglage optimal du système de cache des requêtes mysql semble être 128 Mo pour le cas du vieux campeur. Ce montant optimal peut bien évidemment varier en fonction de la base produit/client mais un montant trop élevé semble faire un tradeoff défavorable au moment de la purge du cache. On gagne moins en performances que l’on ne perd en nettoyage du cache (GC). Donc une valeur comprise entre 64 pour un site avec une petite DB et 256 pour un site avec une très grosse DB semble bon.

- La homepage et le 404 en static est une optimisation simple et efficace puisque l’on utilise pas php pour générer une page qui est toujours la même. Ce n’est possible que si la homepage est un minmum statique mais de toute façon le gain est important, même si on la génère régulièrement parcequ’elle change. C’est la seule page qui est chargée dans 99% des visites, c’est donc un point d’optimisation central.

- La séparation du Back Office qui est très couteux en Magento n’apporte finalement que peut de gain puisque l’essentiel du travail pour le BO est fournit par la base de données et non par PHP ou Apache.