Comment ajouter les services de mise à disposition d’applications F5 à OpenStack

Introduction

OpenStack, qui s’impose rapidement comme la plateforme cloud dominante pour la fourniture d’infrastructures en tant que service (IaaS), alimente désormais des clouds privés, publics et privés gérés. Alors que les clouds OpenStack hébergent de plus en plus d’applications de production stratégiques, les services avancés de mise à disposition d’applications pour les couches 4 à 7 deviennent indispensables. Ces services renforcent la sécurité, l’évolutivité et l’optimisation afin que ces applications stratégiques restent sécurisées, rapides et disponibles. F5 est le principal fournisseur de services avancés de mise à disposition d’applications pour les centres de données et les clouds publics et privés, notamment ceux reposant sur OpenStack. Les services de mise à disposition d’applications de F5 peuvent être intégrés dès la conception d’un cloud OpenStack. L’examen préalable des options disponibles permet de planifier efficacement l’architecture et le déploiement d’OpenStack.

Qu’est-ce qu’OpenStack ?

OpenStack est une plateforme logicielle open source utilisée pour fournir des services de cloud computing. OpenStack, qui a vu le jour sous la forme d’un projet conjoint entre la NASA et RackSpace Hosting, est actuellement géré par la fondation OpenStack, dont la mission est de promouvoir le logiciel et la communauté OpenStack.

Plusieurs entreprises proposent désormais leur propre distribution OpenStack ou des services complémentaires, tels que l’assistance, le conseil ou des appliances préconfigurées.

OpenStack se compose de plusieurs composants qui fournissent les différents services nécessaires à la création d’un environnement de cloud computing. Ces composants sont largement documentés ailleurs. Toutefois, certains modules concernent directement un déploiement F5 OpenStack.

L’un des éléments fondamentaux d’OpenStack est l’API RESTful, qui permet de configurer et d’automatiser les composants de l’infrastructure. Dans de nombreux cas d’usage d’OpenStack — comme la création d’un cloud mutualisé en libre-service ou d’une infrastructure prenant en charge les pratiques DevOps —, l’orchestration pilotée par API est essentielle. La possibilité de réduire les délais de déploiement de plusieurs semaines à quelques minutes, ou de déployer des centaines de services par jour, constitue souvent la principale motivation pour passer à une plateforme cloud. Pour que cette approche soit efficace, tous les composants de l’infrastructure doivent faire partie du cadre d’automatisation. De nombreuses applications nécessitent des services avancés de mise à disposition d’applications, tels que la sécurité des applications ou le contrôle d’accès, pour être véritablement prêtes pour la production. Il est donc essentiel que ces services s’intègrent aux outils d’orchestration et de provisionnement d’OpenStack.

Projets, locataires et réseaux

La mutualisation est un concept important dans OpenStack. Au sein d’OpenStack, un groupe d’utilisateurs est appelé projet ou locataire. (Les deux termes sont interchangeables.) Des quotas de ressources, telles que les ressources de calcul, de stockage ou les images, peuvent être attribués aux projets. Lors de la conception d’une architecture mutualisée, l’une des décisions les plus importantes concerne la manière dont le réseau est conçu pour les locataires. Les plateformes F5® BIG-IP® proposent un éventail d’options de mutualisation et de séparation des réseaux permettant d’assurer l’interopérabilité avec la mutualisation d’OpenStack.

Réseau de fournisseur

Les réseaux de fournisseurs utilisent généralement des réseaux plats (non balisés) ou, plus couramment, des réseaux VLAN (balisés 802.1Q). Ils correspondent étroitement aux réseaux traditionnels des centres de données. Les réseaux OpenStack sont définis et créés par l’administrateur, puis partagés entre les locataires.

Dans certains cas, les instances de calcul d’un locataire disposeront d’interfaces directement connectées au réseau du fournisseur. Les locataires ne définissent pas leurs propres réseaux, mais se connectent simplement aux réseaux du fournisseur configurés en utilisant les plages d’adresses IP définies par l’administrateur du fournisseur. Dans d’autres cas, les locataires créeront des configurations de réseaux virtuels au sein des réseaux du fournisseur.

Réseau des locataires

Les administrateurs peuvent permettre aux locataires de créer leurs propres architectures réseau, qui sont le plus souvent gérées par OpenStack Neutron au moyen d’instances Open vSwitch sur les nœuds de calcul, bien que d’autres solutions de réseau défini par logiciel (SDN) puissent également être utilisées. Des VLAN ou des tunnels Ethernet transparents utilisant la technologie GRE ou VXLAN permettent aux instances de calcul des locataires de communiquer entre elles tout en les isolant des autres locataires. Début 2016, les tunnels GRE constituaient la méthode de déploiement la plus courante. Les locataires peuvent créer leurs propres réseaux et plages d’adresses IP, qui peuvent se chevaucher d’un locataire à l’autre. Chaque locataire peut disposer d’un routeur OpenStack pour permettre les communications en dehors de ses réseaux. Pour ce faire, une ou plusieurs adresses IP flottantes sont attribuées au locataire, puis traduites par son routeur en l’adresse IP privée configurée pour le locataire. (Notez que les adresses IP flottantes d’OpenStack Neutron et de BIG-IP sont deux choses différentes ; la manière dont la plateforme BIG-IP gère l’isolation des locataires sera abordée ultérieurement.)

Services de mise à disposition d’applications F5

Les produits F5 proposent une gamme de services avancés de mise à disposition d’applications, conçus pour assurer l’évolutivité, la disponibilité et une sécurité multicouche. Parmi les principaux exemples, sans que cette liste soit exhaustive, figurent :

La plateforme BIG-IP

La plateforme BIG-IP est disponible en versions physique, virtuelle et cloud. Elle fournit des services applicatifs par l’intermédiaire de modules logiciels BIG-IP. Une plateforme BIG-IP peut exécuter un ou plusieurs modules logiciels pour répondre aux besoins des applications et être déployée en tant qu’unité autonome ou au sein de clusters à haute disponibilité.

La plateforme BIG-IP est un proxy bidirectionnel sans copie, avec état et à très hautes performances. Comprendre ce principe architectural fondamental permet de mieux saisir comment la plateforme BIG-IP fournit ses services et d’éclairer les choix architecturaux.

Figure 1 : Architecture de la plateforme BIG-IP

Les clients se connectent au dispositif ou à l’instance BIG-IP, qui se connecte aux serveurs back-end (ou, dans certains cas, notamment pour les services DNS, traite le trafic applicatif et répond directement au client). Cela crée un « sas » TCP, avec une régénération complète de la session TCP entre le client et le serveur. Au sein de cet espace logique, la plateforme BIG-IP fournit des services de mise à disposition des applications. Lorsque le trafic applicatif transite par la plateforme, il peut être inspecté, modifié et contrôlé. La plateforme BIG-IP permet ainsi de maîtriser entièrement le trafic applicatif entrant et sortant.

La plateforme BIG-IP bénéficie également de la certification ICSA Labs pour ses pare-feu réseau et ses pare-feu d’applications web. La séparation du trafic et la sécurité de la plateforme font l’objet de tests rigoureux dans le cadre de cette certification, offrant ainsi une garantie supplémentaire quant à la sécurité de la plateforme.

Mise en œuvre conjointe de F5 et OpenStack

Les services et plateformes de mise à disposition d’applications d’OpenStack et de F5 s’associent pour fournir des services de niveau production aux applications hébergées sur OpenStack. Les services de mise à disposition d’applications de F5 sont accessibles de deux manières dans OpenStack : via le service Neutron Load Balancing as a Service (LBaaS) version 2 et via l’orchestration Heat. (F5 prend également en charge l’intégration de LBaaS version 1 avec Neutron, mais la communauté OpenStack a rendu obsolète l’API version 1 à partir de la version Liberty d’OpenStack).

LBaaS

Neutron LBaaS fournit des services d’équilibrage de charge de base pour les instances de calcul (et donc les instances applicatives). Ces services se limitent à un sous-ensemble essentiel de fonctions et de fonctionnalités communes à un large éventail de plateformes d’équilibrage de charge.

Le modèle de fourniture de services LBaaS dissocie les ressources qui fournissent le service des services eux-mêmes. Les ressources assurant la fourniture des services font partie de l’infrastructure OpenStack plutôt que des ressources du locataire OpenStack. Ce modèle est parfois qualifié de « sous le cloud » (« under the cloud »).

Figure 2 : déploiement LBaaS sous le cloud

OpenStack LBaaS s’appuie sur plusieurs objets logiques pour créer une configuration d’équilibrage de charge.

Le modèle objet est présenté à la figure 3.

Figure 3 : le modèle objet OpenStack LBaaS

Comme pour toutes les opérations OpenStack, LBaaS est géré via une API RESTful. Cette API permet aux locataires d’effectuer des appels REST pour créer, mettre à jour et supprimer des objets LBaaS. Plusieurs étapes séparent l’appel d’API d’un locataire de la modification de la configuration sur une instance BIG-IP.

Figure 4 : L’architecture LBaaS d’OpenStack

La mise en correspondance des objets LBaaS avec les appels d’API permettant de les créer ou de les mettre à jour dans une configuration sur une instance BIG-IP est assurée par le pilote F5 OpenStack LBaaS. Le pilote LBaaS permet à une instance BIG-IP de fournir des services d’équilibrage de charge au sein d’un cloud basé sur OpenStack.

Le pilote F5 LBaaS se compose en réalité de deux composants distincts :

  • Le plug-in F5 LBaaS, qui est installé sur un serveur exécutant le service API Neutron
  • Le processus de l’agent F5 LBaaS (qui inclut le pilote) est installé sur l’hôte qui l’exécutera. Chaque groupe de services de périphériques (un ensemble de périphériques BIG-IP regroupés en cluster) nécessite un processus d’agent distinct.

Le pilote LBaaS reçoit des tâches à la suite d’appels à l’API LBaaS effectués par le locataire et les traduit en appels à l’API F5 iControl® afin de créer ou de mettre à jour des objets de configuration sur le dispositif BIG-IP ou l’édition virtuelle. Lorsque les locataires utilisent des réseaux de locataires isolés et des tunnels de superposition réseau ou des VLAN, le pilote LBaaS permet de desservir plusieurs locataires à partir d’une seule instance BIG-IP ou d’une configuration haute disponibilité (HA). Le plug-in F5 LBaaS crée les appels d’API nécessaires vers l’instance BIG-IP et Nova afin de garantir que le trafic du locataire est acheminé vers l’objet d’écoute isolé du locataire (VIP dans la terminologie BIG-IP) sur l’instance BIG-IP partagée.

Isolation des locataires

Dans les environnements mutualisés, l’un des rôles essentiels de Nova consiste à garantir l’isolation des locataires les uns par rapport aux autres. Les composants LBaaS de BIG-IP utilisent plusieurs fonctionnalités de mutualisation de BIG-IP afin d’assurer la séparation du trafic des locataires.

Pour mieux comprendre comment et dans quels cas ces fonctionnalités mutualisées sont utilisées, consultez le fichier README du pilote et de l’agent F5 OpenStack LBaaS.

LBaaS fournit un système simple, piloté par API, permettant de déployer des services d’équilibrage de charge dans OpenStack et d’assurer un équilibrage de charge de base pour un grand nombre de clients. Toutefois, l’API ne propose qu’un sous-ensemble des fonctions d’un contrôleur de mise à disposition d’applications (ADC) complet. Ce tableau compare LBaaS et les services BIG-IP natifs selon plusieurs propriétés clés de mise à disposition d’applications, telles que la prise en charge des protocoles, les services supplémentaires et les moniteurs d’intégrité.

Lorsque les fonctionnalités avancées d’un proxy complet de couche applicative sont requises, le déploiement des services de mise à disposition d’applications F5 à l’aide du service d’orchestration OpenStack Heat et des modèles associés permet de combiner une création de services simple et automatisée avec des configurations de services plus complexes.

Service d’orchestration Heat et modèles

OpenStack Heat est un service d’orchestration qui génère des applications opérationnelles à partir de modèles. Le modèle Heat décrit l’infrastructure dans un ou plusieurs fichiers texte, et le service Heat exécute les appels d’API appropriés afin de créer les composants requis. Le service Heat peut être étendu au-delà des modules de base grâce à l’utilisation de plug-ins personnalisés.

Le plug-in F5 Heat permet aux modèles Heat de créer des configurations avancées de mise à disposition d’applications sur tout appareil BIG-IP ou toute édition virtuelle disposant d’un accès réseau et accessible depuis le serveur exécutant le service Heat. L’instance BIG-IP devra également disposer d’une connectivité et d’un routage vers les instances du locataire, car cette connectivité n’est pas configurée par le plug-in Heat.

Les modèles Heat utilisent un langage de balisage simple, YAML, conçu pour être lisible par l’homme et facile à utiliser. Les modèles Heat sont déclaratifs, ce qui signifie qu’il vous suffit de définir les composants d’infrastructure souhaités et de laisser les fournisseurs sous-jacents créer la configuration que vous avez définie.

Les modèles Heat permettent de créer des scénarios de mise à disposition d’applications plus avancés, en particulier lorsqu’ils sont associés au système de modèles F5 iApps®. Les modèles iApps permettent de créer de manière reproductible des configurations de mise à disposition d’applications, simplement en fournissant le modèle requis et les valeurs propres à l’instance. Des configurations de mise à disposition complexes faisant appel à des fonctionnalités avancées, telles que des services de pare-feu pour applications web, l’accélération des applications et des algorithmes avancés d’équilibrage de charge, peuvent être mises en œuvre à l’aide de simples appels d’API.

Les modèles Heat fonctionnent avec des instances d’éditions virtuelles BIG-IP au sein de l’environnement réseau propre à chaque locataire (« dans le cloud »), ainsi qu’avec les appliances BIG-IP déployées sur le réseau physique sous-jacent. Le dispositif BIG-IP n’a pas besoin de participer aux appels d’API réseau Neutron, puisqu’il est traité comme n’importe quel autre nœud de calcul au sein de l’environnement du locataire.

Figure 5 : déploiement dans le cloud avec une appliance BIG-IP
Figure 6 : déploiement dans le cloud avec une édition virtuelle de BIG-IP

Le plug-in F5 Heat est disponible dans le dépôt GitHub de F5 . Ce dépôt contient à la fois le plug-in Heat, qui s’installe sur le serveur exécutant le moteur Heat, et des exemples de modèles Heat.

Options de plateforme flexibles

Les services de mise à disposition d’applications F5 sont disponibles sur plusieurs plateformes, qui offrent toutes les mêmes fonctionnalités de mise à disposition d’applications puisqu’elles utilisent le même système d’exploitation principal et le même micronoyau F5.

Appliances F5 et châssis F5 VIPRION®

Les plateformes matérielles F5 offrent des performances élevées et une évolutivité considérable pour les environnements nécessitant un grand nombre de clients ou de locataires, ou pour les cas d’utilisation exigeant un débit élevé. Une seule paire HA peut prendre en charge plusieurs centaines de locataires et des millions de clients. Les équipements matériels F5 proposent des accords de niveau de service (SLA) relatifs au taux de connexions et permettent de décharger considérablement l’environnement de calcul sous-jacent grâce à l’utilisation de composants matériels spécialisés pour le traitement SSL et TCP. Lorsque des services de sécurité réseau et une protection contre les attaques par déni de service distribué (DDoS) sont nécessaires, les plateformes matérielles F5 offrent d’excellentes performances et des niveaux de protection élevés. La prise en charge de plusieurs espaces d’adressage qui se chevauchent et des protocoles de superposition réseau permet d’utiliser les équipements matériels dans la plupart des environnements multilocataires.

Éditions virtuelles F5 BIG-IP

Les éditions virtuelles F5 BIG-IP sont disponibles pour la plupart des hyperviseurs (notamment KVM) et peuvent être utilisées auprès de fournisseurs de services d’infrastructure cloud public (IaaS), tels qu’Amazon AWS et Microsoft Azure. Les éditions virtuelles (VE) BIG-IP sont également proposées avec différentes capacités, allant d’une édition destinée aux environnements de laboratoire à des versions prêtes pour la production, avec des mises à niveau évolutives en fonction des besoins pour des débits compris entre 25 Mbit/s et 10 Gbit/s. Les licences en volume et les pools de licences flexibles permettent une gestion dynamique du cycle de vie des instances BIG-IP dans les environnements de test et de développement. Une facturation à l’usage est également disponible dans les environnements de cloud public. Les éditions virtuelles BIG-IP offrent les mêmes services de mise à disposition d’applications que les plateformes matérielles, mais ne disposent ni du matériel spécialisé ni de la capacité de montée en charge des appliances.

Les éditions virtuelles BIG-IP peuvent être entièrement intégrées à un réseau de locataire. Considérées par OpenStack comme de simples instances de calcul supplémentaires, elles sont configurées à l’aide de modèles Heat ou peuvent être utilisées comme fournisseur pour LBaaS.

1Consultez le guide d’intégration de F5 et OpenStack pour obtenir des informations détaillées.

Étant donné que le plug-in F5 LBaaS peut prendre en charge plusieurs instances d’agents et de pilotes F5, il est possible de combiner des appliances matérielles et des éditions virtuelles BIG-IP au sein d’une même configuration LBaaS.

Comme pour toute décision architecturale, la meilleure option est celle qui répond le mieux aux exigences propres à la solution. Il est possible de créer des solutions évolutives et hautement performantes à l’aide d’appliances matérielles ou d’éditions virtuelles BIG-IP. Les exigences globales en matière d’évolutivité et de services doivent aider les architectes d’infrastructure à choisir entre le matériel, le logiciel ou une combinaison des deux. Pour un consommateur ou un locataire qui souhaite simplement provisionner des services, le choix entre LBaaS et Heat est plus important que la plateforme de déploiement elle-même.

Haute disponibilité

La haute disponibilité est essentielle pour les infrastructures réseau et applicatives critiques. Comme on peut s’y attendre, la plateforme BIG-IP dispose d’une architecture de haute disponibilité robuste. Les appliances et les éditions virtuelles BIG-IP peuvent être déployées en tant que dispositifs autonomes (par exemple, pour les environnements de test et de développement), en paires à haute disponibilité ou en groupes actifs de N dispositifs pouvant en compter jusqu’à quatre. Tous ces types de déploiement sont pris en charge sur les plateformes OpenStack.

Évolutivité

La possibilité d’ajouter de la capacité aux ressources LBaaS ou BIG-IP des locataires permet aux administrateurs ou aux locataires de faire face à l’augmentation du débit des applications ou du nombre de locataires. La mise à l’échelle verticale ou horizontale sans interruption des services est essentielle pour créer un cloud agile et évolutif.

La plateforme BIG-IP peut évoluer aussi bien verticalement qu’horizontalement : les appliances et les éditions virtuelles peuvent évoluer verticalement grâce à des mises à niveau de licence, tandis que le châssis VIPRION peut évoluer verticalement par l’ajout de lames matérielles supplémentaires. Le plug-in BIG-IP LBaaS gère plusieurs agents et pilotes (chacun gérant une seule instance ou un seul cluster BIG-IP), ce qui permet une mise à l’échelle horizontale. Lorsque plusieurs agents sont utilisés, le plug-in F5 LBaaS conserve par défaut tous les objets d’équilibrage de charge LBaaS d’un locataire donné affectés à un même dispositif BIG-IP (ou cluster).

Lors de l’utilisation d’instances BIP-IP VE au sein d’un locataire, celles-ci peuvent là encore être mises à niveau au moyen d’une licence, ou des instances supplémentaires peuvent être ajoutées pour prendre en charge de nouvelles charges de travail.

Conclusion

À mesure que les déploiements OpenStack hébergent davantage d’applications de production critiques, le besoin de services de mise à disposition d’applications robustes et de haute qualité au sein d’OpenStack s’accroît. Les services de mise à disposition d’applications F5 offrent la capacité, la sécurité et les fonctionnalités avancées dont ces applications critiques ont besoin, tout en bénéficiant de l’agilité et de la faible charge opérationnelle qu’offre un cloud basé sur OpenStack.