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

Introduction

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.1 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.

Flux de travail

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.

Architecture du flux de travail

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.
Diagramme de l'architecture de référence du cloud
Architecture de référence du cloud.

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.

Composants du flux de travail

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.

Bus de messages

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.

Orchestrateur

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é.

Contrôleur Cloud

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.

Contrôleur de cluster/Hyperviseur

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.

Surveillance

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.

DNS

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.

Stockage

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).

Contrôleur de distribution d'applications

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.

Visite guidée : Provisionnement manuel et automatisé

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é.

Provisionnement manuel

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 .

Étape 1 : Saisie de données du contrôleur de cloud

À 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.

Étape 2 : Lancer le flux de travail de provisionnement ; distribuer les métadonnées

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.

Étape 3 : Orchestrator distribue les métadonnées

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.

Étape 4 : Notification de machine virtuelle

À 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.

Provisionnement automatisé

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.

Étape 1 : Surveillance et alertes

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.

Étape 2 : Collecte de données

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.

Étape 3 : Lancement du flux de travail

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é.

Conclusion

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.

 

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

Publié le 10 janvier 2012
  • Partager sur Facebook
  • Partager sur X
  • Partager sur Linkedin
  • Partager par e-mail
  • Partager via AddThis

Connectez-vous avec F5

F5 Labs

Les dernières nouveautés en matière de renseignement sur les menaces applicatives.

DevCentral

La communauté F5 pour les forums de discussion et les articles d'experts.

Salle de presse F5

Actualités, blogs F5 et plus encore.