OpenStack & SLA

Les premiers déploiements commencent à avoir lieu et vont s'intensifier courant 2012. Alors quel va être le SLA associé? Comme il s'agit d'une offre de services IaaS, il ne devrait pas y en avoir qu'un seul. En effet, un seul SLA pour le SaaS a un sens, mais pour la qualité de services de l'infrastructure, il en est pas de même. On peut avoir une garantie de services sur chaque composante IT: storage, compute et network.

Une rupture de services sur l'une de ces composantes n'entraîne pas systématiquement une rupture de services de la fonction utilisée par le client. Par exemple, si ce dernier utilise l'environnement pour effectuer de gros calculs sur des données locales et qu'il y a une incidence de services sur le LAN de bordure avec le WAN (ex: routeur défaillant et dont le basculement sur la redondance active a rencontré un problème), le traitement de calcul en cours n'est pas impacté. Je me rappelle avoir étudié en fin 2009, le SLA sur les services AWS et il y avait du flou avec celui pour EC2, mais pas pour S3 (99,99%, voire +) et rien sur EBS. On se rend bien compte que le niveau de services pour OpensStack dépendra des ressources mises en oeuvre et sur ce point c'est un véritable puzzle à réaliser. La maîtrise de la solution logicielle n'est plus en question, il s'agit maintenant de très bien connaître l'ensemble des choix et alternatives des composants dans l'architecture ouverte d'OpenStack. A vrai dire, la réelle différence entre les fournisseurs de services (cloud public), voire pour les SI d'entreprises (cloud privé) va se faire par cette alchimie de mise en oeuvre. Un aspect non maîtrisé par la plupart des intéressés de ce type de plate-forme OpenSource est l'aspect multi-zones, le scheduler, le stockage, la sécurité, etc. Pour en revenir au SLA pour IaaS, l'ordre d'importance des services d'infrastructure est; le réseau, le stockage et le calcul. Le réseau sans lequel l'accès aux données et aux éléments de calcul est impossible. Le stockage parce que la finalité de l'informatique est bien les données. Et pour finir le calcul, qui s'en lequel les données ne peuvent évoluer. Alors pour une mise en oeuvre d'OpenStack, il faut, à minima, bien maîtriser :

• la redondance de chaque réseau physique et équipement associé (switches, routers, ...), plusieurs coupleurs réseaux par serveur (ex: Quantum + plugins), etc.,
• l'environnement IaaS multi-zones nécessaires, en autre, à offrir différents hyperviseurs par zone,
• la politique de placement des instances de VM en fonction des SLA proposés,
• le stockage qui offre les fonctionnalités de snapshots,de déduplication (driver Nexenta avec ZFS sous iSCSI  > 1Gb/s sur des réseaux dédiés), de choix de supports différents (VSA), etc.,
• le choix, à minima,  de 2 hyperviseurs (haut de gamme offrant la redondance active, c'est-à-dire ESX et standard sans redondance XCP ou KVM) avec gestion réseaux multiples et sécurisée (VLAN avec la mise en oeuvre d'OpenvSwitch, voire vSwitch), l'accès sécurisé à la console système, un panel d'images OS représentatives de l'activité client, etc.,
• la sécurité à tous les niveaux de l'environnement (imputabilité, intégrité, confidentialité, traçabilité, etc.), sans oublier la supervision de disponibilité et de performance des services et la supervision de sécurité basée essentiellement sur la journalisation.

Mettre en ouvre une garantie de services nécessite qu'elle soit mesurable par les 2 parties (client et fournisseur). En conséquence, il faut en plus de les décrire et de les afficher, définir les indicateurs pertinents associés, réaliser leur implémentation (fiable, c'est-à-dire à minima de même SLA) et les fournir à la demande.

Si les projets de la communauté OpenStack ne couvrent pas ces besoins minimum nécessaires à l'ouverture de services avec SLA, il est nécessaire de réaliser les parties manquantes en conformité avec une roadmap cohérente avec celle d'OpenStack. A ce stade de l'avancé des travaux plusieurs acteurs doivent rentrer en scène, avec tout d'abord, aussi bien pour de  l'IaaS privé que public:

• des acteurs définissant le Business Model (SLA, prix, ...) et d'autres définissant la communication appropriée,
• un chef de projet (réel acteur de terrain) qui orchestre tous ces travaux de réalisation, d'intégration et de qualification,
• un architecte d'infrastructure connaissant très bien OpenStack, à défaut s'appuyer ponctuellement sur un architecte Rackspace,

• des développeurs et des experts techniques réseau, stockage et d'hyperviseurs.

Bref, vous l'aurez compris, sans un effort important, seuls les fournisseurs de services importants (ex: HP, Dell, Citrix, ...) et les grands comptes pourront être en mesure de mettre correctement en oeuvre ce type de plate-forme OpenSource.