Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Bien comprendre les Infrastructures Programmables et le Software Defined Datacenter

Comprendre les différents niveaux d’automatisation du datacenter

Avec l’automatisation, les administrateurs n’ont désormais plus besoin de se concentrer sur chaque application et chaque serveur. Toutefois, il existe plusieurs d’automatisation. Cet article vous les détaille.

Trevor Pott
par
Publié le: 16 févr. 2017

L’automatisation n’est pas seulement un élément clé de la prochaine génération de datacenter ou d’environnement virtuel. Cela touche aussi notre société. Etre en concurrence avec d’autres pays dont le coût du travail est plus bas montre à quel point l’automatisation est une priorité en matière d’innovation à tous les niveaux et dans tous les secteurs. L’IT ne déroge pas à la règle. L’automatisation de nos datacenters ne fait que commencer.

Les réseaux programmables (SDN – Software-Defined Network), les infrastructures ouvertes aux APIs et des protocoles comme Redfish changent radicalement la façon dont nos datacenters sont administrés. Les jours de maintenance dédiés à des seules applications sur des serveurs dédiés sont aujourd’hui comptés.

Ce n’est pourtant pas une nouveauté dans l’IT. Il suffit d’observer les acquisitions et autres innovations de VMware ces dernières années pour être convaincu que le « Software-Defined anything » -dont l’objectif final est de proposer un concept d’infrastructure as Code – est bien une réalité.

VMware a développé une offre de Cloud hybride, proposé des produits self-service et même créé sa propre distribution OpenStack. Le groupe a également racheté Nicira pour NSX et développé VSAN, VVOls et implémenté des capacités de stockage virtuel soutenues par une administration au rôle.

Le « Software-Defined anything » représente aujourd’hui un élément concret de la virtualisation. Une terminologie standard a donc émergé pour décrire les différents niveaux d’automatisation dans le datacenter.

Un datacenter traditionnel, dans lequel chaque serveur est pris en compte de façon individuelle, avec un faible niveau d’automatisation, est généralement défini comme un datacenter de type « Pet ». Chaque serveur est  un animal domestique, choyé et entretenu.

Un datacenter qui a des niveaux élevés de virtualisation et d’automatisation au niveau des applications et des OS est désigné comme un datacenter de type « Cattle ». Les serveurs n’ont plus de noms et ne sont pas choyés individuellement : ils ne sont que des nombres. Ils sont créés automatiquement. Leur suppression est tout autant automatisée.

La prochaine étape en matière d’automatisation de datacenter : le datacenter de type « ant » (fourmi en Français). Dans ce cas, les applications sont principalement encapsulées dans des conteneurs au lieu de VMs. Les données sont clairement séparées de l’application en elle-même. Chaque élément de l’infrastructure, du réseau au stockage, est programmable, monitoré, automatisé et orchestré. Il existe aujourd’hui très peu d’entreprises dans le monde qui ont franchi le pas, du « cattle » vers du « ant ».

Au-delà, on retrouve pourtant un autre niveau d’automatisation. Cela n’a pas encore de nom, mais nous allons l’appeler ici « bacteria ». Comme les bactéries donc, ce niveau d’automatisation prend aussi en compte l’environnement. Les capteurs détectent les changements environnementaux et cela entraîne la migration de workloads d’une partie d’un datacenter vers une autre afin de gérer les amplitudes thermiques.

Comme les bactéries, qui créent notre atmosphère riche en oxygène, un datacenter de ce type peut modifier l’environnement dans lequel il se trouve. Par exemple, les systèmes de chauffage et climatisation se déclenchent de façon préventive pour s’adapter aux workloads programmées. Les composants des systèmes défaillants sont automatiquement commandés pour qu’ils soient fonctionnels quand les algorithmes prédisent la rupture d’un nœud. Les workloads sont déplacées pour une meilleure exécution et pour un traitement des données optimisé – celles-ci deviennent plus proche des utilisateurs censés les consommer.

Les datacenters de classe bactérie sont aussi bien plus qu’une simple infrastructure automatisée. Ils peuvent exploiter des systèmes Chaos Monkey (né chez Netflix) pour tester en permanence la stabilité du système et pousser les développeurs à s’adapter. Même son de cloche pour les tests A/B automatisés.

A ce jour, Google pourrait être le seul à avoir atteint ce niveau d’automatisation. Netflix et Facebook sont de bons candidats.

Le SDN pour y parvenir

Si l’on considère le niveau élevé de difficulté que représente la mise en place d’un tel datacenter, il peut en effet être décourageant de considérer une bascule de vos processus vers ce degré d’automatisation. Toutefois, si Google a du inventer lui-même ses propres technologies, les outils qui permettent cette automatisation sont de plus en plus accessibles.

Regardons du côté du SDN. Le but du SDN est de séparer le plan de contrôle de celui des données. Il s’agit là d’une façon élaborée de dire que la configuration du switch est centralisée, et ne nécessite pas de se connecter à chaque équipement.

Dans un environnement 100% SDN, le contrôleur fait de nombreux calculs pour s’assurer que les données sont acheminées là où elles doivent aller, de façon rapide, avec les switches et le câblage en place. Il y a beaucoup d’intelligence dans un réseau full SDN, mais cela ne veut pas forcément dire que le SDN s’applique à chaque maillon d’un réseau.

Considérons les deux switches Supermicro de mon laboratoire. Le premier est un Cumulus Linux Ready Switch SSE-X3648S (48x SFP+ 10GbE/6x QSFP 40GbE). Le second est un SSE-X3348T (48x 10 Gbase-T 10GbE/4x QSFP 40GbE).

Pour automatiser le SSE-X3348T, qui n’est pas un switch Cumulus, la procédure apparait assez traditionnelle. Il peut être configuré via une interface Web ou via des lignes de commandes, à la manière de Cisco IOS. Pour l’automatisation du datacenter, on utilise les lignes de commandes. Cela nécessite donc d’écrire des scripts pour communiquer avec les switchers et leur passer des commandes.

Finalement, ces scripts forment une brique middleware. Vous finissez par créer une API pour vos applications et un widget pour se connecter aux switches et leur indiquer la marche à suivre. Le SSE-X3348T est en fin de compte plus poussif que le SSE-X3648S et le temps de réponse pour les modifications est plus lent.

Ce qui ne fait pas du  SSE-X3348T un mauvais switch. Il fait ce qu’il doit faire et le fait bien. Il est parfaitement possible d’automatiser ce switch pour voir les modifications opérer en quelques secondes. Dans un datacenter « pet » et même « cattle », ce switch est parfaitement acceptable.

Mais vous ne pourrez pas atteindre un niveau « ant » avec le SSE-X3348T. Pour cela, il faut quelque chose comme le SSE-X3648S. Vous devez pouvoir réaliser des modifications  dans un temps inférieur à la seconde, et réaliser plusieurs changements simultanément. Vous avez besoin d’un switch avec un OS développé pour un environnement dynamique et ultra-rapide.

Au-delà du switch

Le commutateur est certes un exemple pratique, mais ce n’est pas le seul. Le stockage est un autre domaine où la rapidité des modifications et l’automatisation comptent. Les entreprises ne gagnent pas d’argent à redimensionner des LUNs. C’est pourquoi VMware a développé les VVOLs. C’est aussi pourquoi plusieurs technologies de stockage et standards ont vu le jour ces dernières années pour rivaliser avec le modèle traditionnel - celui qui consiste à faire une demande à l’administrateur de stockage et à attendre que la modification soit réalisée à la main.

De nos jours, une application doit être capable de capter des ressources de stockage et de réseau de façon automatique, de les allouer à l’infrastructure virtuelle, de créer des VM ou des conteneurs et d’y placer le bon OS, la bonne  application, configuration et données.

Docker et son écosystème contribuent à automatiser les conteneurs. OpenStack contribue à automatiser les VMs et fournit une plateforme où l’automatisation du stockage, du réseau ou d’autres ressources peut être conjuguée.

Pour gérer les environnements physiques, la Distributed Management Task Force (DMTF) a développé le standard Redfish. Il s’agit d’une alternative plus rapide et plus responsive que Intelligent Platform Management Interface pour gérer des serveurs physiques. L’objectif probable est que tout soit intégré à Redfish – des prises électriques aux capteurs thermiques en réseau.  Même les systèmes de climatisation et de chauffage pourraient aussi être pris en compte et contrôlés via Redfish.

Il y a une API pour tout de nos jours. Le concept « Infrastructure as Code »  est la formule adaptée. C’est certes concis, mais résume bien l’idée.

On ne parle pas d’applications automatisées uniquement parce qu’on peut l’installer via un script. On parle d’automatisation quand l’application peut assembler toutes les ressources pour sa création, les détruire et est monitorée pendant les opérations.

Pour parvenir à ce niveau, il suffit de sélectionner un élément et de commencer l’automatisation. Le stockage, le réseau, l’infrastructure virtuelle,  le champ du possible est ouvert. N’essayez pas de tout faire à la fois. Familiarisez-vous avec un aspect. Démarrez petit, mais poursuivez par tous les moyens.

Pas question que votre entreprise conserve son datacenter « pet » quand vos concurrents en sont à profiter de l’efficacité d’un centre « ant ».

 

Pour approfondir sur Administration et supervision du Cloud