Créer un Cloud d'entreprise avec F5 et IBM

Selon certaines estimations, le cloud d’entreprise, également connu sous le nom de cloud privé, est adopté à un rythme plus rapide que le cloud public. Le cabinet de conseil aux entreprises Accenture estime que la pénétration du cloud privé dans les entreprises s'élèvera à 77 % d'ici la fin de l'année 2011.¹ Une grande partie de cette évolution rapide vers la création d’une infrastructure agile sur site découle de la nécessité, de la part des services informatiques des grandes et petites entreprises, de maintenir le contrôle et la gestion internes de l’infrastructure et des données.

Une fois la décision prise d’adopter une infrastructure cloud, le choix entre interne/privé et externe/public se résume à une analyse des coûts, des risques et de la valeur. Un cloud public offre généralement une approche flexible et les économies de coûts les plus importantes ; cependant, il comporte des risques liés à la sécurité, aux accords de niveau de service (SLA), à la disponibilité et à la gestion. L’informatique peut bénéficier d’une échelle quasi illimitée à un faible coût d’entrée, mais elle sacrifie le contrôle. Passer d’un centre de données traditionnel sur site ou hébergé vers un cloud public externe revient en quelque sorte à transférer l’intégralité de votre centre de données entre les mains de quelqu’un d’autre.

Avec un cloud d’entreprise, l’informatique dispose du niveau de contrôle dont elle a besoin et évite les risques associés à un cloud public ; mais un cloud privé est plus coûteux à déployer, nécessite des niveaux de connaissances et d’expertise supplémentaires de la part du personnel et ajoute un niveau de complexité plus élevé au centre de données sur site. L’infrastructure cloud de l’entreprise peut être mise à l’échelle selon les besoins et offre un provisionnement et une agilité dynamiques, mais cette évolutivité et ce contrôle s’accompagnent souvent d’un coût d’entrée plus élevé.

Ensemble, F5 Networks® et IBM ont conçu une architecture de référence pour le cloud d’entreprise qui atténue de nombreux défis associés à la complexité. Il intègre de nombreux composants d'architecture et d'évolutivité d'un cloud public sur site pour réduire considérablement le coût de création d'un système interne fragmenté. En prédéfinissant les composants requis et en décrivant comment ces composants fonctionnent ensemble, F5 et IBM ont créé une infrastructure cloud d'entreprise complète, dynamique et agile.

L’élément le plus important d’un système d’approvisionnement à la demande est la capacité de prendre des décisions et d’agir en fonction des événements. Un événement quelque part dans le système crée une alerte ou un message qui est récupéré par un composant (soit celui qui s'est abonné au bus de messages, soit celui qui a été directement demandé via un appel API), qui agit ensuite sur ce message. Le flux de travail est le processus et l’ordre dans lesquels les composants agissent sur les messages système.

Dans un cloud d'entreprise, le flux de travail se décompose généralement en composants de provisionnement qui demandent ou abandonnent des ressources, ainsi qu'en étapes requises pour gérer l'allocation des ressources. Lorsqu'une machine virtuelle (VM) a besoin de ressources CPU supplémentaires, un flux de travail est lancé pour déterminer d'où proviendront ces ressources CPU, démarrer une nouvelle VM, allouer une adresse IP, etc.

L'architecture cloud d'entreprise de F5 et d'IBM repose sur deux principes essentiels :

1. Il existe un bus de messages centralisé utilisé pour transporter les messages de notification d'événements, et tous les composants qui doivent agir sur les événements sont liés au bus.

Au-delà de ces deux principes, l’architecture de référence F5 et IBM est extrêmement malléable, ce qui signifie qu’elle peut s’intégrer dans n’importe quelle architecture de datacenter ou cloud existante. Si un moteur d'orchestration existe déjà pour gérer le déploiement de machines virtuelles, par exemple, cette architecture de référence peut être adaptée afin que le moteur existant puisse être utilisé. L’une des idées fausses concernant la création d’un cloud d’entreprise est que l’ensemble de l’infrastructure doit être remplacé ; la solution F5 et IBM a été créée pour s’intégrer aux composants existants à chaque étape possible.

Quels que soient les composants déjà existants et ceux qui sont nouveaux, le flux de travail cloud de l'entreprise est composé de composants spécifiques qui exécutent des tâches spécifiques. L’ensemble du système cloud est composé de ces composants individuels, qui fonctionnent ensemble pour fournir l’infrastructure cloud complète. Cette infrastructure est alimentée et contrôlée par des flux de travail de composants : des tâches coordonnées qui gèrent un événement cloud.

Le bus de messages est le système qui transporte des messages basés sur des événements et des alertes à chaque composant affecté. Lorsqu'un événement déclenche un message, ce message est envoyé via le bus de messages à un composant particulier, qui a des règles sur ce qu'il faut faire avec ce message. Le bus de messages est également responsable de la normalisation des messages en fonction de règles pour des composants spécifiques.

L'architecture cloud de référence F5 et IBM utilise la solution IBM Tivoli Netcool OMNIbus comme bus de messages central. Toutefois, n'importe quel bus de messages d'entreprise peut être utilisé pour transporter des notifications d'événements dans l'ensemble du système.

L'orchestrateur peut être considéré comme le cerveau du cloud d'entreprise : le composant chargé de prendre la plupart des décisions de provisionnement des macros en fonction des messages reçus sur le bus. L'orchestrateur lancera des événements et des flux de travail majeurs dans l'architecture cloud, tels que le démarrage du flux de travail « provisionner une nouvelle machine virtuelle». L'orchestrateur est également chargé de récupérer les données requises pour chaque flux de travail et de les fournir aux composants concernés ; par exemple, l'orchestrateur fournirait les informations d'adresse IP nécessaires pour provisionner une nouvelle machine virtuelle.

Pour l'architecture de référence, l'orchestrateur est créé à l'aide d'une série de scripts interprétés qui agissent sur les messages du bus et démarrent des événements de workflow. Tout type d'orchestrateur, tel qu'IBM Tivoli Intelligent Orchestrator, HP Operations Orchestration ou VMware vCenter Orchestrator, peut être utilisé.

Le contrôleur cloud est le système frontal chargé de collecter et d'agréger les données préliminaires requises pour démarrer un processus de provisionnement. Au départ, ces informations sont fournies par un administrateur dans le cadre du processus de création et sont spécifiques à chaque type de workflow utilisé pour le provisionnement. Par exemple, le contrôleur cloud collecte des informations qui incluent l’emplacement de la machine virtuelle, la classe d’ application (serveur Web, serveur de base de données, serveur de messagerie, etc.) et les exigences minimales en matière de ressources.

Lors d'un événement de provisionnement automatisé, et une fois que ces données préliminaires ont déjà été stockées dans le système, l'orchestrateur demande et extrait les informations existantes pour amorcer le flux de travail de provisionnement. Les exemples de contrôleurs cloud incluent Eucalyptus Cloud Controller, VMware vCloud Director ou Amazon EC2. Pour une croissance future et une extensibilité vers d'autres plateformes cloud, il est recommandé de choisir un contrôleur cloud capable d'intégrer ou de communiquer avec un ensemble standard d'API cloud. Cela permet au contrôleur cloud de s'étendre à un fournisseur de cloud hybride sans réorganiser la plate-forme cloud de l'entreprise.

Le contrôleur de cluster est le composant du cloud d'entreprise chargé de gérer la machine virtuelle en cours de provisionnement, ainsi que le stockage et les métadonnées nécessaires à l'exécution de la machine virtuelle. En tant qu’environnement d’exécution de la machine virtuelle, le contrôleur de cluster inclut l’hyperviseur de la plate-forme virtuelle et peut également inclure l’environnement de gestion de l’hyperviseur plus vaste. Par exemple, le contrôleur de cluster peut être un hyperviseur simple, tel que VMware ESXi, ou une collection plus grande de systèmes d'hyperviseurs distribués, tels que VMware vSphere ou VMware vCloud.

La surveillance de l’état et de la santé sont des éléments essentiels de tout déploiement application d’entreprise. La surveillance fournit également des mises à jour d'état pour les systèmes de provisionnement, par exemple lorsqu'une machine virtuelle est opérationnelle et répond aux connexions sur le réseau. La surveillance continue du système peut fournir des alertes en temps réel qui alimentent en fin de compte de nouveaux flux de travail et affectent les décisions de provisionnement. Tout composant capable de surveiller l'état des application et du réseau peut être utilisé dans le déploiement du cloud d'entreprise ; cependant, le logiciel IBM Tivoli Monitoring est utilisé dans l'architecture de référence F5 et IBM.

Le système de noms de domaine (DNS) joue un rôle essentiel dans l'architecture de référence du cloud d'entreprise F5 et IBM : Il est responsable du stockage non seulement des informations IP et du nom de domaine pour IPv4 et IPv6, mais également des métadonnées du système, telles que les informations collectées par le contrôleur cloud et les informations d'identification uniques de la machine. Pour cette architecture de référence, le DNS a été choisi comme emplacement de stockage des métadonnées car il s'agit d'un système basé sur des normes qui existe déjà dans la plupart des réseaux, il est disponible pour tous les composants cloud et il réduit la nécessité d'ajouter un stockage de type base de données supplémentaire à l'infrastructure. Toute solution DNS gérée par le service informatique et permettant d’ajouter des zones et des fichiers de zone supplémentaires peut être utilisée.

Pour l'architecture de référence F5 et IBM, le contrôleur de cluster exécute la machine virtuelle à partir du stockage local ; toutefois, lorsqu'il n'est pas en cours d'exécution, le disque virtuel de la machine virtuelle se trouve sur un stockage virtualisé. Lors d'un événement de provisionnement de workflow, le contrôleur de cluster demandera le disque virtuel au périphérique de stockage virtuel via le système de fichiers réseau (NFS).

Le dernier composant du cloud d'entreprise est le contrôleur de distribution application (également appelé équilibreur de charge), qui, dans l'architecture de référence F5 et IBM, est F5® BIG-IP® Local Traffic Manager™ (LTM). BIG-IP LTM gère les connexions, les services et la livraison des données application provenant de la machine virtuelle. En fin de compte, BIG-IP LTM est la dernière partie du système qui agit sur un événement de provisionnement de flux de travail.

L’objectif de l’architecture de référence du cloud d’entreprise F5 et IBM est de fournir une plate-forme basée sur des ressources réelles pour le déploiement dynamique applications. Une fois tous les composants en place, ils fonctionnent ensemble, via différents flux de travail, pour fournir de nouveaux services application selon les besoins. Il existe deux manières de provisionner les systèmes en place dans le cloud d'entreprise : le provisionnement manuel et le provisionnement automatisé.

En règle générale, le premier flux de travail dans le cloud d’entreprise est lancé à partir d’un processus manuel basé sur les entrées de l’administrateur système ou du demandeur application . Cela ne veut pas dire que le flux de travail est manuel ; seul le fait de saisir des informations dans le système pour la première fois est manuel. Une fois les données collectées auprès de l'administrateur, le système lance des événements de workflow automatisés prédéfinis pour le provisionnement des application .

À l’aide de l’interface graphique du contrôleur cloud, l’administrateur (ou le demandeur application , selon la personne responsable du démarrage d’un nouvel événement de provisionnement) saisit les informations requises pour lancer une nouvelle machine virtuelle et mettre une application en ligne. Ces informations sont généralement des données d’infrastructure de niveau supérieur, telles que :

• Type de application : Une liste prédéfinie de types application disponibles, tels que Microsoft SharePoint, un serveur Web, un serveur de messagerie, une base de données Oracle, etc.
• Informations sur le réseau : Adresse IP du cluster, URL du front-end, si cette application sera publique ou interne uniquement, etc.
• Informations de provisionnement : Toute information supplémentaire requise pour le système de provisionnement, telle que l'emplacement du réseau (souvent une référence géographique liée à un centre de données physique, par exemple, « Europe – Centre de données de Copenhague ») et toute restriction sur le nombre minimum et maximum d'instances autorisées d'un type application donné.

Ces informations sont utilisées comme métadonnées pour le provisionnement automatisé dans l’ensemble du cloud de l’entreprise.

Une fois que l'administrateur a soumis les données requises, l'étape suivante consiste pour le contrôleur cloud à regrouper ces informations, ainsi qu'un ID d'instance unique créé de manière dynamique et utilisé dans tout le système pour identifier cette instance à des fins de provisionnement, tel que « vm12345 », et à les distribuer à l'orchestrateur via le bus de messages.

Toutes les informations fournies lors de la première étape sont normalisées par le bus de messages avant d’être livrées à l’orchestrateur.

En tandem, le contrôleur cloud fournit les mêmes métadonnées et l’ID d’instance unique à l’hyperviseur, via une API, et lui demande de déployer l’image application requise. Cet événement invite l’hyperviseur à demander l’image de disque de la machine virtuelle applicable à partir du stockage basé sur le cloud. Le périphérique de stockage récupère l’image disque appropriée via NFS et commence à copier cette image sur le stockage local.

Une fois que l'orchestrateur a reçu les informations d'événement normalisées et les métadonnées du bus de messages, il lance deux flux de travail différents qui transmettent simultanément les métadonnées au(x) système(s) de surveillance et au DNS. Les systèmes de surveillance utilisent ces informations pour configurer un calendrier de surveillance automatisé pour l' application et commencer à surveiller l' application après notification qu'elle est opérationnelle. Au cours de cette étape, l'orchestrateur définira également des seuils pour les événements du système de surveillance, par exemple en demandant au moniteur d'envoyer une notification d'événement lorsque le processeur de cette instance virtuelle dépasse 75 % d'utilisation.

L'orchestrateur transmet également les métadonnées de l'instance virtuelle au DNS, où ces données sont stockées pour être utilisées dans l'ensemble du cloud de l'entreprise. L'orchestrateur est responsable de la soumission des métadonnées dans le format de zone DNS approprié. Il doit donc construire des noms de domaine en fonction de l'ID d'instance, créer des enregistrements DNS IPv4 et IPv6, ajouter des informations d'instance à partir du contrôleur cloud et ajouter les nouvelles informations d'instance à la zone appropriée. Par exemple, l’orchestrateur prendra l’ID d’instance unique, créera une entrée DNS pour « vm12345.vm.cloud.example.com » et l’ajoutera à la zone example.com existante.

L’étape finale de la distribution des métadonnées dans l’ensemble du cloud d’entreprise consiste à renseigner le contrôleur de distribution application BIG-IP LTM avec les nouvelles informations d’instance, telles que le nom d’hôte, l’adresse IP, le type application (ou le pool sur BIG-IP LTM) et les informations de surveillance.

À l’étape 2, le contrôleur cloud a demandé à l’hyperviseur de démarrer la machine virtuelle associée à l’instance nouvellement provisionnée. Une fois que la machine virtuelle est opérationnelle comme prévu et disponible pour les connexions, elle avertira l'orchestrateur via une alerte d'événement sur le bus de messages. L'orchestrateur prendra cette alerte d'événement et démarrera un flux de travail qui demande à BIG-IP LTM de marquer la nouvelle VM comme disponible dans le pool et de commencer à envoyer et à distribuer de nouvelles connexions à l'instance virtuelle en fonction de la méthode d'équilibrage de charge. BIG-IP LTM commencera également à surveiller la nouvelle instance avec le moniteur application précédemment configuré attribué au pool application .

L'alerte d'événement de la machine virtuelle nouvellement exécutée invitera également l'orchestrateur à informer le système global de surveillance du cloud de l'entreprise pour commencer à surveiller l'instance virtuelle. À ce stade, l’instance virtuelle nouvellement provisionnée est opérationnelle dans le cloud de l’entreprise et gère les demandes de service application . Il s’agit du mode de fonctionnement normal de tous les services qui font partie du cloud d’entreprise.

Le provisionnement manuel est la première étape du workflow dans le provisionnement des services au sein du cloud d’entreprise, mais ce n’est pas la forme de provisionnement la plus fréquente. Dans un système fonctionnant correctement, le cloud d’entreprise évolue vers un système d’autosurveillance plus dynamique et plus fluide, et il s’auto-approvisionne en nouveaux services selon les besoins et la demande. Cet auto-provisionnement agile est au cœur de toute plateforme cloud et nécessite des événements et des flux de travail de provisionnement automatisés supplémentaires pour surveiller et réagir aux événements en temps réel.

La première étape de tout système d’approvisionnement automatique est la surveillance : la collecte et la détection des événements dans l’ensemble du système. Au cours de la première série de provisionnements manuels, les systèmes de surveillance ont été renseignés avec des informations sur les instances virtuelles telles que le nom, l’emplacement, le type de surveillance et les seuils d’événements. Ces informations sont utilisées pour surveiller automatiquement la disponibilité et les performances des applications et des instances virtuelles. Une fois qu'un événement (par exemple, une instance virtuelle donnée consommant plus de 75 % des ressources CPU disponibles) est détecté par le système de surveillance, il génère un événement sur le bus de messages qui alerte l'orchestrateur de l'épuisement des ressources.

Dans un scénario de provisionnement automatisé typique, l'orchestrateur est chargé de créer une nouvelle instance virtuelle qui contribuera à alléger la charge des ressources sur l'instance actuelle. Deux ou plusieurs instances virtuelles seront utilisées pour répartir les charges de calcul et de réseau de application .

Pour lancer un flux de travail de provisionnement automatisé, l'orchestrateur doit être chargé de collecter les événements des composants, ainsi que de demander les métadonnées requises pour provisionner une nouvelle instance virtuelle. Dans l'architecture de référence F5 et IBM, les métadonnées sont stockées dans DNS et renseignées dans le cadre du flux de travail de provisionnement manuel d'origine. Le DNS renverra des informations (par exemple, le type application’ application , l’emplacement géographique et les seuils de provisionnement) à l’orchestrateur.

Dans la dernière étape d’un flux de travail de provisionnement automatisé, l’orchestrateur transmet les métadonnées acquises auprès du DNS au contrôleur cloud via le bus de messages. Essentiellement, cette étape automatisée simule l’étape au cours de laquelle un administrateur saisit les informations de la machine et démarre manuellement le flux de travail de provisionnement. Le contrôleur cloud prendra en compte ces informations (comme il le ferait auprès de l'administrateur lors du provisionnement manuel) et lancera un nouveau flux de travail de provisionnement d'instance virtuelle. À partir de ce point, les étapes de provisionnement et les flux de travail détaillés ci-dessus sont répétés jusqu'à ce que la nouvelle instance virtuelle soit opérationnelle et accepte de nouvelles connexions.

Un déploiement cloud d’entreprise typique comprendra des flux de travail de provisionnement manuels et automatisés. Les nouveaux services ou applications seront initialement déployés à l’aide d’un flux de travail manuel afin qu’un administrateur puisse contrôler comment et où le service est déployé. Une fois qu'un service est opérationnel, les flux de travail de provisionnement automatisés géreront le provisionnement en fonction des besoins en ressources et de la disponibilité.

Le choix de déployer un cloud d’entreprise privé ne doit pas se faire au détriment d’une complexité accrue ou d’une inopérabilité. L’objectif de tout déploiement cloud est de réduire les obstacles à la création de nouveaux services et de fournir une infrastructure informatique plus agile. Un cloud d’entreprise apporte cette agilité au centre de données pour une facilité de gestion et un contrôle considérablement améliorés.

Avec IBM, F5 a créé une architecture de référence pour un cloud d’entreprise à provisionnement automatique. Cette architecture est conçue pour être modulaire et flexible, permettant l’intégration des composants existants selon les besoins et la connexion de l’ensemble du cloud d’entreprise à n’importe quelle autre plateforme cloud via des API et une infrastructure de messagerie partagée. Aucun cloud d’entreprise privé n’est exactement le même ; cependant, l’architecture F5 et IBM s’adaptera à différents environnements, tout en apportant les avantages d’une infrastructure agile à tout déploiement application ou centre de données.

¹ Babcock, Charles (2011, 18 janvier). « Les clouds privés prennent leur envol. » Semaine d'information. La toile.