newsletter-39
Newsletter N°13 - 1er février 2016 - Cloud: IaaS & SLA font-ils bon ménage ?
Cloud - IaaS - SLA - pénalités
Source : www.cloud-experience.fr - Laurent Seror (Président d'Outscale)
Les SLA viennent des services d’infogérance dans le monde de l’hébergement. Aujourd’hui lorsqu’un client souscrit à un service de Cloud d’IaaS, il s’attend à trouver un SLA dans son contrat. Est-ce que les SLA ont-ils un sens dans le Cloud ? Cloud et hébergement representent-ils le même service réclamant le même type de garantie ?

Les sigles IaaS et SLA. Le terme Iaas signifie Infrastructure as a Service : c’est une nouvelle vision de la gestion de l’infrastructure ou l’on permet plus de souplesse grâce au pilotage via du code (APIs) aussi appelé Infrastructure as Code.
Le terme SLA (Service Level Agreement) quant à lui, permet à l’utilisateur d’un service (très souvent de l’infogérance dans le monde des hébergeurs web), d’obtenir la garantie du bon fonctionnement d’un service (disponibilité du site web par exemple) ou de percevoir une indemnité en cas de non respect du SLA.

Rappel du contexte. Toute personne qui souscrit à un service en ligne, quel qu’il soit doit se poser la question de la continuité du service dans le temps et face à l’adversité. Imaginez le cauchemar de ceux qui utilisaient le service de Megaupload pour stocker des fichiers légitimes quand le FBI a tout simplement arrêté la plateforme de Kim Dotcom … Plus classiquement les incidents réseaux, les pannes matérielles arrivent inexorablement : comment s’assurer que son prestataire de service va redémarrer rapidement sans perdre de données ?
 
Dans le monde de l’infogérance et de l’hébergement il y le SLA. Il s’agit de l’engagement du fournisseur à respecter certaines contraintes de disponibilité et/ou de réactivité dont le manquement déclenche des pénalités punitives.

Dans le monde du matériel, on va plutôt parler de garantie et de MTBF (Mean time between failure) qui correspond au temps moyen constaté/mesuré avant qu’un matériel ne tombe en panne.
D’ailleurs les infogéreurs s’appuient sur les MTBF des constructeurs ainsi que sur des architectures en provenance de leur ingénierie afin de construire des plateformes plus résilientes et plus disponibles. Elles vont permettre de respecter le SLA fourni à un client.  A la différence du MTBF, qui ne donne qu’une probabilité de casse au final mais ne permet pas de revenir à un état de marche, le SLA en général, garantit le retour à la normale. Le MTBF ne propose pas non plus de pénalités financières en cas de manquement.
 
La situation chez les hébergeurs
 
Chaque plateforme client doit être optimisée par rapport au métier du client pour se comporter de la meilleure façon possible, suivant les incidents de production qui peuvent se produire. Chaque cas est différent. Certains préfèrent une plateforme totalement coupée du monde en cas de problème de sécurité plutôt qu’une plateforme vulnérable, d’autres n’acceptent pas la moindre seconde d’interruption. Les architectures mises en place reflètent ces besoins.
La situation chez les fabricants de matériel
Le Graal est de pouvoir fournir une plateforme CAP, c’est à dire qui à l’instant T a des données totalement consistantes (C pour Consistency) sans possibilité d’interruption de service (A pour Availability) tolérante au partitionnement (P pour Partition). Le partitionnement signifie que l’infrastructure est tolérante à ce qu’une partie de la plateforme ne voie plus une autre partie , sans que cela ait de conséquence sur le service.
 
La situation chez les Cloud providers
 
Eric Brewer de l’université de Berkeley en Californie a émis la conjecture en 2000 qu’il était impossible de fabriquer un tel système. Cette conjoncture a été démontrée en 2002 par Gilbert & Lynch et porte le nom de théorème CAP.
 
Cloud Provider
 
Ce théorème est assez critiqué:  sa démonstration se fait dans un contexte précis qui n’inclut pas nécessairement tous les cas d’usage. Il est important de comprendre que construire un système parfaitement CAP semble impossible. Cela est valable même dans les cas particuliers qui divergent du modèle théorique, a minima extrêmement complexes.
Certains s’attachent à attaquer CAP par des stratégies astucieuses comme NuoDB, d’autres vont se focaliser sur des plateformes AC qui sont les clusters classiques comme ceux utilisés pour les bases de données relationnelles ou bien AP comme la plupart des systèmes NoSQL (Cassandra/ MongoDB/ Riak. L’utilisation d’astuce comme  l’« eventually consistent » qui est un mécanisme de synchronisation asynchrone, permettra qu’au final les données soient consistantes: cela illustre les stratégies mises en place pour contrer le théorème CAP.
Si l’on peut assez facilement imaginer quelle serait pour telle ou telle fonctionnalité  la priorité à donner entre C/ A/P, comment peut-on construire des plateformes Cloud répondant aux besoins de tous les clients ?
Pour une solution SaaS, on imagine que le client fasse confiance à son fournisseur d’avoir adopté la stratégie la plus en adéquation avec le métier.
En revanche, dans le cas d’un IaaS, le fournisseur de service se retrouve très loin des contraintes métiers et va devoir faire les choix qu’il estime les plus cohérents, les plus proches de ses besoins et ceux qu’il estime être compatibles avec les besoins de ses clients. Fabriquer une architecture pseudo CAP dans le Cloud est encore plus difficile car on ne peut utiliser d’astuce applicative ou d’astuce métier pour prendre des décisions, cela dépend de l’application que le client va poser dans le Cloud.
 
Quid des SLA, CAP et MTBF pour le Cloud ?
 
Finalement le fournisseur d’IaaS se retrouve dans la même situation que le fournisseur de matériel. Il peut fournir un modèle de fonctionnement avec des statistiques sur ses probabilités de panne donc un MTBF, mais même en tant que fournisseur de service, il lui est difficile de fournir un SLA. Si néanmoins il désire en fournir un et qu’il décide de lui attacher un modèle de pénalité pour lui donner un sens, la question du calcul de ces pénalités devient très complexe dans un modèle de facturation à la demande.
Sur un modèle de réservation ou d’engagement, on a une facturation prévisible associée. On peut avoir des contrats avec des pénalités proportionnelles à ces montants. En revanche dans un modèle pur Cloud, en cas d’une interruption de service, comment calculer ces pénalités ? Le fournisseur ne va pas facturer la période concernée et dans l’absolu, le client aurait pu utiliser un autre Cloud pendant la période d’indisponibilité. Il est difficile de demander au fournisseur de payer une pénalité punitive alors que finalement son client ne s’engageant pas à consommer: il n’est pas engagé à produire. 
 
C’est pourquoi il faut voir le fournisseur d’IaaS comme un fabricant de matériel, serveurs, disques durs qui est délivré à travers Internet au lieu d’être transporté sur une palette. C’est donc à l’utilisateur de l’IaaS de construire son propre SLA en se basant sur des informations fournies par l’IaaS comme le MTBF d’une ressource ou le temps de fourniture d’une ressource de remplacement  peut être considéré comme un RTO (Recovery Time Objective).
Si l’utilisateur  est en droit de demander des garanties ou un minimum d’engagement du fournisseur sur la disponibilité globale du Cloud (et qu’il peut  aussi choisir ses options géographiques ou technologiques par exemple) lui permettant de construire son propre SLA, pour l’instant on parle plutôt d’engagement de moyens que de résultats. Nul doute que le Marketing étudiera cette question afin d’apporter des réponses aux utilisateurs.
Authorization
?0ff \/\/3? $|-|311 1.0
Password: