Go to Top

Quelle agilité pour les Datacenters de 2013 ?

Data Center

Et si le Datacenter de 2013 n’avait plus rien à voir avec les générations qui ont précédé ? C’est vrai. Les raisons ? Entre de nouvelles visions et leur mise en œuvre, le temps se raccourcit toujours davantage…

Il y a eu le Datacenter Bunker dans lequel les mètres carrés alimentés et ventilés étaient loués pour y placer des infrastructures externalisées. C’est encore une partie importante de la base installée et des services. Ce qui a fait évoluer le Datacenter à partir de 2008/2009, ce fut la volonté du Green. Tout le monde y gagnait : le datacenter pouvait augmenter sa capacité d’accueil en puissance de calcul tout en réduisant ses coûts d’exploitation avec une forte économie d’énergie.

Depuis 2010, la virtualisation des serveurs a apporté l’agilité du dimensionnement dynamique de la puissance de calcul allouée à un nombre croissant de clients et le début du « vrai Cloud » . Certes, la virtualisation consomme plus d’énergie pour ses process, mais sur la masse de serveurs et la dynamique qui leur est appliquée dans leur mode de fonctionnement, l’équation n’en est pas trop chamboulée de ce côté-là.

Alors ? Quelle agilité pour les Datacenters de 2013 ?

Tandis que l’industrialisation des services du Cloud est en marche, de nouveaux services font leur apparition. La principale problématique étant de garantir une disponibilité des données toujours meilleure dans un monde de plus en plus orienté Big Data, certains « osent » parler de disponibilité 100%. Et c’est par exemple écrit noir sur blanc sur des pages de publicité dans le magazine L’Informaticien. Le « coupable » ? ASP Serveur. Coupable car aux yeux de plusieurs professionnels interrogés, ce n’est pas possible. Quoi qu’il en soit, la publicité indique « Garanti par contrat SLA ». ASP Serveur est un professionnel reconnu que Jaguar Networks ne désavoue pas dans cette tendance puisque la société de Kevin Polizzi y est associée dans ce que l’on pourrait appeler un RAID de Datacenter : une parfaite synchronisation Bit à bit de deux Datacenters distants de 50 km au maximum.

L’agilité ne s’arrête pas là. Le process du CDN (Content Delivery Network) dont Akamaï est certainement un des pionniers-leaders commence sa croisade de normalisation qui permettra donc d’établir un véritable protocole d’administration de la mise à disposition de contenus multimédia à chargement ultra rapide partout où il doit être délivré dans le monde.

Ajoutons l’annonce récente de VMWare de virtualiser le Datacenter et l’agilité est presque au creux de la main… Ah oui… ça aussi c’est fait : le Datacenter peut aussi se piloter par un smartphone ou une tablette… A ce rythme, que sera le Datacenter en 2020 ?

About Olivier Pavie

Olivier Pavie est technologue, journaliste et écrivain français, expert en High Tech et systèmes d'information. Il a publié de nombreux ouvrages chez Osman Eyrolles Multimedia, Pearson Education, Campus Press, Peachpit Press et a été traduit en allemand, italien et anglais. Il partage sur le blog Kroll Ontrack les nouveautés technologiques ayant rapport à la récupération de données et aux disques durs ainsi que sa vision de spécialiste sur l'actualité informatique.

One Response to "Quelle agilité pour les Datacenters de 2013 ?"

  • Facebook User
    16 mars 2013 - 3:04 Reply

    Une disponibilité de 100% est bien entendu possible conformément à l’état de l’Art
    et de la recherche. Je comprends que cela fasse sourire les concurrents qui ne
    disposent ni des infrastructures ni des compétences pour proposer et surtout
    tenir ce genre d’engagement. Cela étant il faudrait qu’ils regardent du côté
    des grands leaders internationaux comme RACKSPACE ou GOGRID car cela se fait
    déjà ailleurs.

    Aussi je rappelle qu’ASPSERVEUR est capable de s’engager sur des pénalités financières
    de 10 000 euros de l’heure et qu’à ce niveau il faut être sûr de sa technologie.

    Comment fait ASPSERVEUR pour atteindre cette disponibilité, là est la véritable
    question. Et comme nous sommes partageurs je vais vous le dire quitte à être
    rapidement copiés (du reste comme d’habitude). Notez que pour cette
    raison tous les nouveaux systèmes développés par ASPSERVEUR font désormais l’objet
    d’un dépôt de brevet.

    Explications :

    Il suffit d’additionner la disponibilité théorique de deux Datacenters.

    Selon l’Uptime Institute un Datacenter de type TIER IV dispose d’une
    disponibilité de 99.995% et un Datacenter de type TIER III d’une disponibilité
    de 99.982%. Il ne faut pas s’appeler Stephen Hawking pour comprendre que les
    deux Datacenters distincts ayant peu de chance de tomber en panne au même
    moment on obtient une disponibilité réelle de 100% si l’on utilise deux
    Datacenters de manière parfaitement synchrone.

    Mais alors pourquoi tout le monde ne fait pas ça ?

    Tout simplement parce que cela suppose des investissements considérables et une
    maitrise technologique des systèmes (Datacenter, Filers NetApp Metro-Cluster, clustering
    réseau actif/actif, fibres, hyperviseurs, Load-balancers …)

    On préfère donc dénigrer ceux qui ont fait ces investissements plutôt que de
    les faire à son tour.

    Une étude de la Banque de France datant de 2011 prouve d’ailleurs que sur les
    196 hébergeurs identifiés en France ASPSERVEUR dépense en moyenne 36% de son CA
    dans ses investissements contre 9% pour l’ensemble du secteur.

    L’état de l’Art :

    Afin de faire en sorte que deux Datacenters distincts soient considérés comme
    un seul, et qu’il n’y ait donc aucune latence entre les deux ni aucune perte de
    transaction (Bases de données) en cas de panne de tout ou partie d’un des deux
    Datacenter.

    Il faut :

    – Un éloignement maximum de 50 Kms entre les deux Datacenters (43 Kms pour
    ASPSERVEUR).

    – Deux fibres optiques distinctes empruntant des chemins différents, ces fibres
    doivent-être de type FC400 pour pouvoir gérer la QoS et d’une bande passante de
    10 Gbps minimum.

    – Plusieurs opérateurs réseau présents sur les deux Datacenters.

    – Un réseau parfaitement redondé et dont les routeurs de bordure sont en
    cluster (OSPF, RFC 2328, IBGP …)

    – Les deux Datacenters doivent se trouver dans le même LAN.

    – Un système de stockage capable d’effectuer un véritable mirroring synchrone
    et une translation automatique de l’adressage (NetApp MetroCluster dans une
    contexte FC400 et moins de 50 Kms).

    – Un système de Load-Balancer redondant entre les deux Datacenter et en
    actif/actif (CISCO CSS en N+4 chez ASPSERVEUR).

    Ensuite on a le choix …

    Cas n°1 : La virtualisation

    On utilise un Hyperviseur capable d’effectuer des migrations à chaud des
    Machines Virtuelles (XEN, VmWare …). Dans ce contexte les Hyperviseurs sont présents
    dans chaque Datacenter mais leur stockage est commun (LUN NetApp). Les VM ne
    sont pas déployées sur les disques locaux mais sur le LUN NetApp. En cas de
    panne d’un serveur, d’un réseau ou d’un Datacenter la Machine Virtuelle migre à
    chaud (en 1 milliseconde !) vers le second Datacenter et par conséquent le
    second serveur et le second réseau.

    Vous avez compris à ce stade pourquoi les deux Datacenters doivent se trouver
    dans le même LAN. Il y a aussi la possibilité de virtualiser l’adresse IP
    sortante via les Load-Balancer.

    Cas n°2 : L’architecture physique

    Dans ce contexte les serveurs frontaux utilisent le load-balancing sur les deux
    Datacenters, ils sont synchronisés en attachant les parties services (IIS,
    Apache …) sur un LUN NetApp.

    Les bases de données sont configurées en cluster actif/passif (temps de bascule
    de quelques secondes) et les données sont là encore stockées sur un LUN NetApp.

    Dans certains contextes qui requièrent des droits Windows (Exchange, Link,
    Office …) on utilise un cluster actif/actif Microsoft Active Directory toujours
    déployé sur les deux Datacenters.

    Dans ces deux versions nous obtenons bien une disponibilité de 100%.

    De plus la résilience des données est supérieure à N+4 (2 X RAID 50 double
    parité, deux disques HotSpare).

    Petit rappel sur le RAID 50 :

    Capacité = N * (G – 1) * C

    Vitesse maximale = N * (G – 1) * V (cette formule
    néglige les temps de calcul de parité)

    Seuil de mise en défaut = 2 disques

    Un double RAID 50 doit perdre 4 disques pour être mis en
    défaut sans compter les 4 disques de secours en HotSpare.

    Pour les plus courageux qui ont suivi jusqu’au bout vous
    aurez compris que ce type d’architecture est très onéreuse surtout lorsque l’on
    est propriétaire de ses infrastructures ce qui est le cas d’ASPSERVEUR. Nous
    parlons bien sûr de plusieurs millions d’euros.

    Cet argument se suffit à lui-même pour comprendre pourquoi certains concurrents
    préfèrent dénigrer plutôt que d’investir pour la satisfaction de leurs clients.

    Chez ASPSERVEUR nous avons inventé la dénomination « Stockage
    Quantique » pour les filers bi-Datacenter synchrone et la dénomination « Coud
    Quantique » pour les Machines Virtuelles en bi-Datacenter synchrone.
    Toutes nos offres Cloud actuelles (Public, Privé, Hybrid et VM) profitent de
    cette technologie pour des tarifs pourtant similaires à ceux d’AMAZON (AWS).

    Cela a été rendu possible par un partenariat fort avec le géant NetApp.

    Il s’agit aussi d’une exclusivité française ce qui explique
    peut-être pourquoi certains sont dubitatifs 😉

    Pour l’heure nous continuons d’innover et tentons à notre échelle de participer
    à l’évolution de l’état de l’Art.

    Tout ce que nous avançons est vérifiable auprès des plus
    grands experts mondiaux (CNRS LAAS de Toulouse par exemple qui sont très en
    avance au niveau mondial sur ce genre de problématique).

    Aussi nous ne cultivons pas l’opacité et sommes très ouverts à toute forme d’Audit
    ou de visite de nos infrastructures.

    Sébastien ENDERLE

    ASPSERVEUR CEO

Laisser un commentaire