fév 23

Alors me voila de retour sur Paris, après une semaine de mauvais temps dans un pays où la dernière fois où il a plu devait être en 1912… Du coup, je me remet en jambes avec quelques news du milieu Magento :

Sortie de la 1.4 CE

Bon, finalement c’est fait, la 1.4 de Magento est sortie. Vous pouvez la trouver ici et un compte rendu complet des nouveautés ici sur Fragento.

Donc après plusieurs mois d’absence, on va enfin pouvoir tester la bête en terme de performances et de sécurité. Je suis en tout cas rassuré que Varien n’ait pas mis de coté la CE plus longtemps car cela devenait politiquement problématique.

Bargento en régions = Apérogento ?

Gabriel et moi travaillons étroitement avec SeL et Varien à l’animation de la communauté Magento en France mais nous n’avons pas le temps de tout suivre ou de tout faire. J’ai appris avec surprise et joie que de nombreux évènements s’organisaient en région, des apérogentos notamment et je trouve cela super.

Vu de Paris, on ne peut pas beaucoup aider à cela me disais-je mais finalement j’ai revu mon jugement. Déjà, apéro ou autres horaires, on peut éventuellement passer faire un bonjour, ca nous fera plaisir, même si ca n’aide en rien les organisateurs :)

Par contre, on peut fournir un peu de logistique aux organisateurs ! De la visibilité en annonçant ca sur Wikigento, Bargento (et probablement Fragento même si je n’en ai pas encore parlé à Gabriel) voir même en faisant poster par Varien un billet avec un espèce d’agenda sur le blog FR.

Ensuite, j’ai des bases de données  assez complète de la sphère Magento en France, ca pourrait permettre de faire un petit mailing pour les organisateurs pour pousser la chose.

Bref, si vous voulez faire un Apérogento en région, comme à Lille, Toulouse et Lyon où on m’en a déjà parlé, je suis tout à fait prêt à donner un coup de main mailing et de la visibilité pour les organisateurs ! Il suffit de me contacter : philippe[at]wikigento.com

Des plugins sympas pour Magento

Déjà Cocorico, un plugin Français pour commencer. La communauté est active, les idées fusent et les modules émergent. La société Xhéos m’informe, par l’entremise de Michaël Thieulin, que l’extension AMF service permet une intégration complète de modules Air/Flex dans le core de Magento.

Le protocole AMF s’invite donc dans le core de Magento et permet également des traitements de plus grands volumes de manière plus efficace. Faire communiquer du Flash sur le front office avec votre Backoffice, c’est partit avec AMF Webservice.

Dans la série on s’y intéresse : les plugins de performances.

L’incontournable Fooman Speedster qui concatènent les JS et les CSS pour réduire leur taille et optimiser le transfert n’est plus seul en piste puisqu’en ce moment plusieurs initiatives visent à optimiser les transferts, les requêtes, les compilations. Où se situe l’avenir ?

Dans mon idée, vous le savez, sur la compilation du PHP.

Un langage interprété ne sera jamais aussi rapide qu’un compilé. En attendant que les initiatives en ce sens (dont une très prometteuse dont je vous reparlerai) voient le jour, des plugins visent à améliorer les temps de chargement.

Bien que je n’ai pas eu encore l’occasion de les essayer, Delorum propose des Magento lignthing hyper megaspeed modules (je vais essayer de benchmarker cela). J’ai vu une autre société proposant des modules similaires à la vente mais l’URL ne me revient pas (EDIT : ah si en fait c’est ici, magento Booster). Si  vous en avez, postez en commentaire, on fera un petit benchmark pour voir qui donne quoi !

Dans les facteurs externes pouvant améliorer les performances de la bête (qui ne cesse de progresser dans son core, reconnaissons le) le moteur de recherche SolR de l’apache consortium vous donnera des recherches de la plus grande rapidité, même dans des catalogues énormes comme dans le c as du Furet du Nord (réalisé par Smile, hébergé et optimisé par NBS System). Toujours dans les « externes » (même si Zend a un unified installer avec Magento), Zend Server améliore les performances avec son Full Page Cache et ses différents mécanismes.

La vitesse comme facteur de ranking Google

Matt Cutts de Google a expliqué en novembre dernier que Google avait une forte pression interne en ce moment, notamment de l’un de ses fondateurs, pour intégrer la vitesse de chargement d’une page comme facteur de ranking.

C’est l’avènement d’une chose que l’on suspectait tous et Google l’officialise quelque part en laissant l’info filtrer publiquement. Le plus étonnant en fait c’est que ce facteur était déjà probablement pris en compte depuis des mois d’après nos tests, sans que Google ne le dise.

La question qui subiste est donc de savoir si pour posséder un bon référencement naturel il faut avoir une page qui se charge vite ou une page qui se charge plus vite que les autres. La deuxième option me parait un peu radicale par contre il y a fort à parier que les sites lents à charger se verront sanctionner dans le référencement naturel puisque, dixit un fondateur du géant, « passer de la recherche au site doit se faire aussi naturellement que tourner une page d’un livre ».

Un Bargento International

Ok on y est, on passe au dessus du gouffre et on verra bien comment ca va se passer… Bargento devient international. En gros, on invite nos copains européens qui n’ont pas la chance d’avoir un évènement local à Paris pour venir échanger avec nous tous.

La décision a été complexe à prendre, le cafouillage de dates vient en partie de là mais Bargento va en ressortir plus grand, plus fort et plus beau. Avec des fournisseurs de solutions et de compétences de tous horizons, des plugins que vous ne soupçonniez même pas, des clients des quatre coins de l’Europe !

Venez donc faire la fête internationale avec nous le 28 mai 2010, plus d’info prochainement sur Bargento.fr

écrit par Philippe Humeau

fév 05

La 1.4 de Magento CE va sortir, enfin !

Hier j’ai échangé avec Yoav autour de la sortie de la version 1.4 de la C.E. Ca râle et c’est bien normal. Tout le monde retient son souffle, certain se sentent trahis par la EE qui a eu 2 MAJ et 0 pour la CE.

Lors du CAB meeting de décembre, Yoav nous avait promis la 1.4 pour la première semaine de Janvier 2010…

Le truc c’est que je ne sais pas si la date qu’il m’a donné est très officielle ou même si la cause du retard peut être expliquée ici, mais tant pis, je me lance. Un scoop est un scoop et le retard de la CE, les promesses de Varien, et mon statut de CAB m’impose de vous tenir au courant…

3D secure in the core

J’ai donc eu un mail assez concis m’expliquant que le retard est dûe à l’implémentation de 3D secure dans le code de Magento. Ce dispositif très important pour la sécurité des transactions bancaires est une avancée très très significatives dans le domaine des transactions en lignes, sur le E-commerce comme ailleurs. En gros, la transaction va être sécurisé par la demande d’un identifiant supplémentaire, un OTP (one time password), un mot de passe, une date de naissance etc…

Cette avancée est indispensable à l’économie numérique et l’on ne peut que se réjouir que Varien l’intègre à Magento en CE. Retard donc pour cette raison et parce qu’ils ont réorganiser leur production team également.

Alors la date ?

11 février.

Ce n’est pas officiel. C’est une conversation avec Yoav, pas un communiqué de presse. Donc le plus important pour nous tous : elle arrive dans peu de temps et oui, vous pouvez continuer vos devs sur la Beta 1.4 puisque le changement majeur, c’est l’arrivé de 3D secure donc tant que vous ne customisez pas ces points, no problem.

Bargento 4, décalage de la date


Il a été décidé par Gabriel, Koby (Varien en charge de la communauté) et moi même de décaler la date de Bargento 4 au 28 mai 2010 au lieu du 22 mars 2010 initialement prévu. Pourquoi ce changement de date alors ?

EDIT du 09/02/2010 : il n’aura échappé à personne que le 24 mai précédemment annoncé est le lundi de Pentecôte, que cette année, c’est de nouveau férié, donc la date est bien le vendredi 28 mai, définitivement ;)

- Varien préfère enchainer Paris et frankfort plutot que de faire plusieurs allers/retours, ce qui est compréhensible quand, comme Yoav et Roy, on passe 30% de son temps en dehors de son pays sur une année ;)

- La proximité de la date ne permettait pas à certains speakers importants de se déplacer pour donner leurs conférences, nous aurions donc perdu un peu en qualité, ce qui était inenvisageable.

- La salle était à priori trop petite. En tout cas, ce que nous avions pu réserver n’aurait pas tenu les 500 personnes qui semblent annoncer lors de B4, après une visite, l’espace que nous comptions prendre aurait été un peu limité.

- Bargento 4 a attiré des Espagnoles, des italiens, des Anglais, des Ukrainiens et peut être d’autres américains. Roy m’expliquait lors de Bargento 2 que seul l’Allemagne et la France disposait d’une communauté forte et structuré avec des personnes pour organiser des Meet magento ou Bargento et qu’en Angleterre, les US, l’espagne et l’italie, Varien n’avait pas ce type de support. Un groupe linkedin s’est donc monté pour voir si les personnes qui viendrait d’europe pouvait justifier que Bargento change un peu de forme pour les accueillir et cela semble effectivement pertinent.

Pertinent pour les annonceurs, sponsors et personnes disposant d’un stand puisque le savoir faire Français est reconnu et que ces sociétés pourront s’exporter en europe. Pertinent pour les clients finaux et porteurs de projet puisqu’ils pourront trouver des structures à l’étranger proposant d’autres services et d’autres approches. Pertinent enfin puisque cette internationalisation va permettre d’avoir des conférences pointues !

Que les Français ne parlant pas Anglais se rassure, les conférences seront en majorité données en Français et seul 3/4 conférences sur les 12 seront en anglais, seuls les supports seront en Anglais. Chacun pourra parler dans sa langue natale selon les interlocuteurs avec qui il voudra échanger et nous gagnerons tous à cette ouverture européenne.

Forcément, cette nouveauté complexifie un peu notre organisation mais « it’s worth it ».

Voici donc les raisons de ce décalage de Bargento 4 à la date du 28 mai 2010, nous vous communiquerons le lieu dans les meilleurs délais. (soit l’intégralité de l’espace Saint martin sur 3 étages, soit une autre salle plus grande).

EDIT du 09/02/2010 : il n’aura échappé à personne que le 24 mai précédemment annoncé est le lundi de Pentecôte, que cette année, c’est de nouveau férié, donc la date est bien le vendredi 28 mai, définitivement ;)

Vous trouverez l’information directement sur www.bargento.fr dès que nous aurons les mises à jour, moi je pars en vacances, visiblement je ne fais plus la différence entre un jour férié et un jour de boulot, il est temps. Allez, à dans 12 jours !

écrit par Philippe Humeau

fév 04

Résumé des épisodes précédents


- Janvier 2008 : Sun achète Mysql pour 1 Milliard là où Oracle proposait 750 Millions $
- Avril 2009 : Oracle rachète Sun pour plus de 7 milliards …
- Avril 2009 : Tout le monde flippe pour Mysql

La mariée


Sun c’est une société d’ingénierie vénérable qui a été parmi les premières à créer des serveurs. Chez Sun la conception c’est important, l’ingénierie encore plus et on fait tout à la main avec amour. Résultat, souvent précurseur incompris, Sun n’a pas que des réussites à son actif mais quand même de très belles choses, un parc, un savoir faire et des machines de pointes. Ses propres processeurs Ultraparc et Sparc64, ses architectures, ses bus de données, des milliers de brevets.

Sun c’est aussi du logiciel. Solaris et OpenSolaris pour les operating systems (performants et surtout très robustes), Java pour les langages, la suite openoffice pour le bureau. Mine de rien, déjà, ca pèse un peu lourd tout ca.

Et bien sur……. Mysql.

Mysql ne craint rien !


Mysql est la base de données qui a soutenu le développement de l’opensource. La plus répandue et utilisée au monde. Et Oracle, avant tout le métier d’origine… C’est la base de données. Mais…

Larry Ellison a parfois « acheté pour tuer » mais là, il domine complètement le segment de la base de données. De la TPE au très grand compte. Il peut faire migrer les Mysql vers de l’Oracle quand le compte grossit, faire de la pub sur la clientèle de Mysql, bref…

Pourquoi tuer Mysql ? De toute façon, ceux qui l’utilise n’ont pas le budget pour de l’Oracle.

En plus, tuer un soft opensource c’est très dur. En effet, d’autres feront une autre mouture demain et le pari sera perdu. C’est déjà un peu le cas avec MariaDB et Monty mais ca pourrait empirer si Oracle se montre agressif envers Mysql. Au bout de plus de 6 mois, Mysql existe toujours, il est maintenu, rien n’a réellement changé. Mysql est même sur la Home d’Oracle, déclaration sur la page de Mysql dans le site d’Oracle :

« Oracle will continue to develop and enhance MySQL along with Oracle’s other open source database technologies, Oracle Berkeley DB, the leading open source embedded database, and Oracle InnoDB, the most popular transactional storage engine for MySQL.MySQL customers will benefit from Oracle’s world-class support and training services. MySQL developers and partners will find new opportunities as MySQL becomes a certified part of Oracle’s open, complete, and integrated stack of technology—from application to disk. »

Si Elisson ne tient pas sa promesse, il va se mettre à dos le milieu de l’opensource et se faire détester… Pas très malin et Elisson, il est tout sauf idiot.

Conclusion


La raison de la fusion est (presque) expliquée en homepage du site de Sun et sur celui d’Oracle : « Hardware, Software, complete ». Car Oracle, ce n’est pas que la célèbre database, c’est aussi beaucoup d’autres softs critiques (ceux de peoplesoft par exemple) et de services. La chaine d’Elisson est donc maintenant verticale et horizontale, il a renforcé considérablement sa position.

Personnellement je ne m’inquiète pas pour Mysql mais plus pour IBM ou Microsoft. Larry a souvent protéger son pré carré en mettant dehors des concurrents. Là il possède Java, de quoi sérieusement enquiquiner IBM qui a très largement misé dessus et avec Openoffice, il a de quoi concurrencer Micrososft.

Il est hégémonique sur la base de données et en plus, toujours pour en**rd*r IBM, il a du hardware de qualité, du serveur de combat, un OS qui tient la route….. Alors qui c’est qui mange son chapeau ? C’est Steeve Balmer (Microsoft) et Sam Palmisano (IBM) pardi !

Le grand perdant, ce n’est pas Mysql que son statut de base opensource de référence préserve de toute mort subite ou même moyen terme, c’est IBM à mon sens qui va se faire concurrencer énormément par Oracle sur ses marchés de services. Et pour peu que Larry Elisson se fache sur le segment du soft de bureau, Microsoft va reculer sur Office, son chouchou pendant que Google tente de lui tailler les flancs.

Warning : funny things to come !

PS : Merci à Nicolas.T de Toulouse pour l’idée de ce post :)

écrit par Philippe Humeau \\ tags: , , , , ,

fév 01

Introduction

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 !

écrit par Philippe Humeau \\ tags: , , , ,