F5 et AWS : Services avancés de diffusion application dans le cloud

Amazon Web Services (AWS) est devenu le fournisseur le plus important et le plus répandu d'infrastructures de cloud public en tant que service (IaaS). Les organisations peuvent désormais créer, tester et déployer des piles application entières sans acheter ni reconfigurer l’infrastructure sur site. Les applications de production peuvent bénéficier de services de distribution application avancés tels qu'un pare-feu application Web (WAF), une accélération SSL, un routage basé sur le contenu, un équilibrage de charge, une atténuation des attaques DDoS, une gestion des accès et une agilité des protocoles, qui rendent ces applications clés plus rapides, plus intelligentes et plus sûres. Pour les déploiements AWS cloud natifs, les solutions F5 permettent une livraison simple et facile de ces services application aux environnements cloud AWS.

En tant que fournisseur d'IaaS, Amazon Web Services (AWS) propose une infrastructure de calcul louée suffisante pour développer des applications. Sans dépenser d’argent en dépenses d’investissement ou en maintenance, une suite application complète peut être développée et déployée. En plus de fournir une infrastructure de calcul similaire à celle trouvée sur site, AWS fournit des services application , met automatiquement à l'échelle l'infrastructure et héberge des applications dans de nombreux emplacements. En raison de ces fonctionnalités supplémentaires, les meilleures pratiques pour AWS sont différentes des meilleures pratiques pour un centre de données classique. Pour mieux apprécier les différences entre AWS et un centre de données traditionnel, il est important de comprendre comment AWS fournit ses services.

Pour tirer le meilleur parti d'AWS, examinons plusieurs attributs importants de son offre IaaS, tels que la distribution géographique, les instances de calcul, la mise en réseau et les concepts de stockage.

La compréhension d’AWS commence par une description physique de la manière dont les ressources sont distribuées. Au plus haut niveau, AWS dispose de plusieurs régions, chacune couvrant une vaste zone géographique, comme la partie est des États-Unis. Chaque région géographique contient plusieurs zones de disponibilité, ainsi nommées car elles sont conçues pour être isolées des pannes entre elles. Une défaillance dans une zone de disponibilité (AZ) ne se répercutera pas sur une autre AZ au sein d’une région. Bien que chaque AZ soit isolé, les AZ d’une région sont connectées via des liaisons réseau à faible latence. À des fins de disponibilité, des modèles de conception existent pour une capacité redondante sur plusieurs zones de disponibilité au sein d'une région.

Les instances de calcul commencent sous la forme d'une image de disque logiciel, appelée Amazon Machine Image (AMI). Chaque AMI est immuable, ce qui signifie qu'il est en lecture seule par l'ordinateur qui l'utilise. Le démarrage d’une instance de calcul sur une AMI crée une machine virtuelle en cours d’exécution dans le cloud. Les caractéristiques matérielles virtuelles de l'instance de calcul peuvent varier, telles que le nombre de processeurs et de RAM disponibles pour l'instance.

Chaque instance de calcul existe dans un cloud privé virtuel (VPC), ce qui équivaut à peu près à un réseau local dans le monde physique. Chaque VPC est logiquement séparé. Un VPC peut être constitué de plusieurs sous-réseaux avec un routage implicite entre les sous-réseaux. Les sous-réseaux publics sont routables depuis Internet, tandis que les sous-réseaux privés ne sont disponibles qu'en interne. Pour déployer une application complète, une ou plusieurs instances de calcul sont déployées au sein d'un VPC. La communication entre les VPC peut avoir lieu lorsqu'une entrée DNS est attribuée à une instance de calcul ou à un équilibreur de charge.

Comme indiqué ci-dessus, chaque AMI est immuable par rapport à l’instance qui l’utilise. Pour le stockage persistant, AWS propose de nombreuses solutions, principalement Simple Storage Service (S3) et Elastic Block Storage (EBS). S3 est un service de stockage d'objets où un objet peut être stocké et accessible par son nom. La taille de l’objet peut varier de zéro octet à 5 To. En fait, chaque AMI est implicitement un objet S3. Les objets ne peuvent pas être modifiés, seulement créés et supprimés, ce qui les rend idéaux pour un contenu relativement statique, comme des photographies ou des images de machine virtuelle .

EBS offre un stockage plus proche du stockage traditionnel. Une instance de calcul attachée à EBS voit l’EBS comme un disque dur traditionnel. Une seule instance en cours d'exécution à la fois peut être attachée à un volume EBS. EBS ne peut donc pas être utilisé pour le stockage partagé.

Outre la fourniture de composants d’infrastructure clés, AWS fournit des services supplémentaires qui permettent la mise à l’échelle des application . Étant donné qu’AWS peut rapidement provisionner des ressources d’infrastructure, Amazon a développé des solutions qui permettent la mise à l’échelle automatique et l’équilibrage de la charge de ces ressources.

AWS fournit un service d'équilibrage de charge élastique (ELB). Initialement, ELB faisait référence à un simple équilibreur de charge fonctionnant au niveau 4 qui répartissait le trafic sur plusieurs nœuds sains dans un pool. Le pool peut s'étendre sur plusieurs zones de disponibilité, créant ainsi une redondance automatique en cas de défaillance dans une zone de disponibilité. Bien que cet équilibreur de charge offre certaines fonctionnalités de base de la couche réseau 7, il fonctionne principalement au niveau de la couche 4, en acheminant simplement le trafic TCP de manière circulaire vers les nœuds du pool. Les contrôles de santé déterminent quels nœuds sont disponibles et sont donc candidats au trafic. AWS fait désormais référence à cet équilibreur de charge initial sous le nom d'équilibreur de charge classique pour le différencier du nouvel équilibreur de charge application (ALB).

Étant donné qu'AWS dispose d'une capacité de secours disponible, il peut offrir la possibilité de faire évoluer les nœuds au sein d'un pool. Le service AWS CloudWatch surveille les mesures de performances de chaque nœud au sein d'un pool. Lorsque des seuils prédéfinis (tels qu’une utilisation du processeur supérieure à 60 % pendant 5 minutes) sont dépassés, un autre nœud est provisionné. Inversement, lorsqu’un seuil inférieur a été franchi, un nœud est supprimé. Le concepteur peut déterminer le nombre maximal et minimal de nœuds dans un pool et les seuils qui déclenchent l'instanciation ou la suppression d'un nœud. L’utilisation de la mise à l’échelle automatique derrière un équilibreur de charge permet au pool de nœuds de s’étendre ou de se contracter selon les besoins en fonction de la charge.

Bien que les applications gèrent les règles et la logique métier, elles manquent souvent du renforcement requis pour le déploiement, la gestion et l’exploitation de la production à grande échelle. Les solutions F5 permettent aux applications d'être plus rapides, plus intelligentes et plus sûres en fournissant les services de diffusion application avancés détaillés dans le tableau ci-dessous.

F5 Services de diffusion application avancées

Surveillance au niveau des applications

• Contrôles avancés de l'état des application (à l'aide d'un moniteur à plusieurs étapes)
• Contrôles de santé à plusieurs niveaux (par exemple, vérifier que la base de données et application sont disponibles)
• Contrôles de santé non HTTP (tels que SIP, Microsoft Windows SQL Server et FTP)
• Des algorithmes avancés pour mieux répartir le trafic vers les serveurs fonctionnant le mieux

Disponibilité mondiale

• Disponibilité des application sur un mélange hétérogène de différents fournisseurs de cloud ou centres de données
• Intégration avec les moniteurs avancés BIG-IP
• Prise en charge DNSSec

Les services avancés de distribution application permettent aux applications de fonctionner à un niveau supérieur, tout en étant disponibles et plus sécurisées. Ces services peuvent exister à un point de contrôle stratégique indépendant de chaque application. Le découplage des services de la logique métier de l’ application permet aux applications de répondre aux besoins de l’entreprise sans surcharger les équipes de développement avec des problèmes d’infrastructure, de gestion et de performances. Un point de contrôle stratégique permet également de traiter les questions de gouvernance de manière uniforme et indépendante de chaque application.

En fournissant une intégration cloud native avec l'infrastructure AWS, F5 permet aux organisations de tirer le meilleur parti de leurs déploiements AWS, en dotant leurs applications de meilleures performances, d'une plus grande disponibilité et d'une sécurité renforcée. Dans la section suivante, nous examinerons comment AWS et F5 fonctionnent ensemble.

Lorsqu'une instance de serveur démarre à partir d'une image générique, il est souvent judicieux de modifier les paramètres ou de définir des configurations, telles que le nom d'hôte et l'adresse IP. Sur les machines clientes, ces paramètres sont définis via DHCP, mais la définition des paramètres du serveur via DHCP peut souvent entraîner des problèmes. Au-delà des paramètres réseau, une instance particulière nécessite parfois des packages logiciels spécifiques ou certaines configurations logicielles.

Dans le cas d'un déploiement BIG-IP, un administrateur peut souhaiter automatiser la configuration de chacun des modules, tels que les serveurs virtuels et les configurations de pool pour BIG-IP Local Traffic Manager (LTM), les configurations WAF spécifiques pour BIG-IP Application Security Manager ou peut-être les paramètres de pare-feu pour BIG-IP Advanced Firewall Manager. Les mêmes problèmes se posent à toute personne installant une instance de serveur : l'image de base nécessite une configuration supplémentaire pour fonctionner correctement.

AWS propose deux approches principales pour configurer une instance : la création d'une nouvelle AMI ou l'utilisation de cloud-init pour modifier un serveur pendant le processus de démarrage. La création d’une nouvelle AMI est plus appropriée pour les modifications communes à plusieurs instances qui sont moins susceptibles d’être mises à jour souvent. En revanche, cloud-init est plus adapté aux modifications qui impactent moins d’instances et ont une espérance de vie plus courte.

Pour les modifications qui devraient persister pendant une période plus longue (et pour les modifications communes à plusieurs instances), une bonne approche consiste à créer une nouvelle AMI en démarrant une machine à partir d’une AMI similaire à la configuration souhaitée. Une fois que l’administrateur a apporté les modifications nécessaires à l’instance en cours d’exécution, l’instance est arrêtée et une nouvelle AMI est générée et enregistrée auprès d’AWS. Toutes les futures instances démarrant à partir de cette AMI verront les modifications déjà appliquées. Étant donné que cette approche rend les modifications effectivement permanentes (et que la génération de la nouvelle AMI peut prendre du temps), les modifications intégrées à l’AMI sont généralement celles qui dureront longtemps et sont utilisables sur plusieurs instances. Une autre raison d’utiliser AMI est qu’il permet des temps de démarrage plus rapides, car certains processus cloud-init peuvent prendre beaucoup de temps.

Les modifications nécessaires qui ne conviennent pas à l’intégration dans une nouvelle AMI sont de bons candidats pour cloud-init, qui active essentiellement un script de démarrage à chaque démarrage de l’instance. L'utilisation de cloud-init permet d'intégrer des modifications simples et spécifiques à l'instance dans l'instance.

Les inconvénients de cloud-init incluent le fait que les modifications de configuration, telles que les installations de packages, doivent être exécutées au démarrage, ce qui allonge le temps de démarrage. Un temps de démarrage long a un impact réel dans les scénarios de mise à l’échelle automatique où un temps de démarrage allongé pourrait rendre la mise à l’échelle automatique inefficace. Pour ces raisons, les modifications qui prennent beaucoup de temps doivent être incluses dans une nouvelle AMI au lieu d'effectuer les modifications via cloud-init.

La gestion de la configuration peut également être fastidieuse lorsqu'une modification peut être utilisée sur plusieurs instances, mais pas sur toutes. Par exemple, supposons qu’un déploiement BIG-IP particulier soit utilisé dans un groupe de mise à l’échelle automatique avec une configuration de serveur virtuel spécifique. Une seule AMI pourrait servir à ces machines et une autre AMI pourrait servir à d'autres machines BIG-IP dans un autre groupe de mise à l'échelle automatique. L'utilisation d'une seule AMI pour chaque groupe de mise à l'échelle automatique garantit que seules les modifications spécifiques à chaque hôte sont nécessaires dans le processus cloud-init. Toutes les modifications communes au groupe peuvent être intégrées dans l'AMI. L'inconvénient de cette approche est qu'elle nécessite une mise à jour de l'AMI pour chaque modification commune à toutes les machines.

Les applications offrent une capacité, généralement à plusieurs utilisateurs simultanément. À mesure que l’ application devient plus performante, elle peut dépasser la capacité de l’ordinateur sur lequel elle s’exécute. Une fois que les besoins de application dépassent ceux de votre ordinateur, des options permettant d'augmenter la capacité doivent être évaluées. Il existe trois approches génériques de mise à l'échelle : la mise à l'échelle verticale, le pipelining et la mise à l'échelle horizontale.

La mise à l’échelle est l’approche la plus simple pour augmenter la capacité, car elle consiste simplement à remplacer l’ordinateur existant par un ordinateur plus rapide. En installant un ordinateur plus rapide, tous les aspects de l’ application et tous les autres services sur l’ordinateur deviennent plus rapides sans qu’aucune modification ne soit nécessaire à l’ application ou à l’infrastructure. L’inconvénient de la mise à l’échelle est que les coûts ont tendance à augmenter de manière exponentielle avec l’augmentation des performances, conduisant à un point de rendement décroissant. Une fois le seuil franchi, le passage à l’échelle devient prohibitif.

Le pipelining est le résultat de la décomposition de la charge de travail en étapes séquentielles, semblable à une chaîne de montage. Lorsque différents ordinateurs peuvent travailler indépendamment à chaque étape, le débit global peut être augmenté. Cependant, le pipeline n’augmente que le débit, et il le fait souvent au détriment de la latence. En d’autres termes, le pipelining peut augmenter les performances globales, mais peut diminuer les performances d’un seul utilisateur ou d’une seule requête. L’autre inconvénient du pipelining est qu’il nécessite une compréhension approfondie du flux de travail décomposable et que l’infrastructure corresponde à cette compréhension. Il relie étroitement les décisions d’infrastructure à la logique métier, ce qui est exactement le contraire de ce que de nombreuses organisations tentent de faire.

La mise à l'échelle consiste à laisser l' application et l'ordinateur tranquilles et à choisir plutôt de répartir les demandes de manière uniforme sur un pool de serveurs. Étant donné que les applications traitent généralement plusieurs requêtes indépendantes simultanément, les requêtes peuvent être réparties en toute sécurité sur un pool de serveurs application identiques. La mise à l'échelle présente l'avantage supplémentaire de la redondance dans la mesure où la défaillance d'un membre du pool n'entraînera pas de panne de l'ensemble de l' application. L’inconvénient de la mise à l’échelle est qu’elle nécessite une orchestration complexe externe à l’ application afin de garantir que les demandes sont équilibrées entre les nœuds du pool.

La mise à l’échelle automatique AWS utilise une approche évolutive pour augmenter la capacité des applications qui en ont besoin. Le service CloudWatch surveille les nœuds d'un pool. Lorsque les nœuds dépassent des seuils prédéfinis, CloudWatch démarre automatiquement de nouveaux nœuds ou arrête les nœuds du pool, selon le cas. Avec la plateforme BIG-IP, ce processus peut se dérouler de deux manières : en modifiant le nombre d’instances BIG-IP ou en modifiant le nombre de nœuds dans un pool derrière une seule instance BIG-IP. La différence entre les deux approches est fonction de ce qui est mis à l’échelle : soit l’instance BIG-IP, soit un pool.

Dans le premier scénario, un pool BIG-IP se trouve entre une paire de périphériques ELB. Le premier périphérique ELB contrôle l'instanciation et la terminaison des membres BIG-IP, tandis que le deuxième périphérique ELB est la seule entrée dans un pool de serveurs pour chacune des instances BIG-IP. Cette approche est logique lorsque l’instance BIG-IP fournit des services de distribution application avancés, tels que la terminaison SSL ou agit comme un pare-feu application Web. Le premier périphérique ELB effectue l'équilibrage de la charge tout en augmentant ou en réduisant le pool selon le cas.

Dans le deuxième scénario, le nombre de membres du pool back-end augmente et diminue via CloudWatch, mais l'instance BIG-IP effectue l'équilibrage de charge. L'instance BIG-IP communique avec AWS pour découvrir les nœuds ajoutés ou supprimés du pool. Cette approche est logique lors de l’utilisation de fonctionnalités avancées d’équilibrage de charge, telles que le langage de script iRules, ou lors de l’orientation de requêtes en fonction de l’URL ou du contenu. Dans ces cas, une seule instance BIG-IP suffit à gérer la charge des serveurs du pool back-end.

L'instance BIG-IP doit interagir avec l'infrastructure AWS dans au moins deux scénarios. Tout d’abord, un déploiement AWS sur plusieurs zones nécessite la modification de l’adresse IP derrière une IP élastique AWS. Deuxièmement, une instance BIG-IP a besoin d’une visibilité sur les membres du pool ajoutés et supprimés par le service AWS CloudWatch, qui augmente et diminue les serveurs au sein d’un pool. Chaque interaction avec l'infrastructure s'effectue via des appels API et, comme tout autre logiciel effectuant des appels API, l'instance BIG-IP doit s'authentifier auprès d'AWS. En général, il existe deux approches pour s’authentifier auprès d’AWS : via des informations d’identification ou des rôles IAM.

L’approche la plus simple pour l’authentification consiste à inclure les informations d’identification appropriées avec l’appel d’API. Les informations d'identification AWS se composent d'une clé d'accès et d'une clé secrète, qui correspondent approximativement à un nom d'utilisateur et à un mot de passe. L'administrateur génère les informations d'identification, que le développeur intègre ensuite dans l' application. Cela donne à l' application l'accès aux appels API appropriés.

Bien que simple, l’intégration d’informations d’identification dans une application comporte des risques de sécurité. Si le développeur ne sécurise pas les informations d’identification dans l’ application, d’autres personnes ou logiciels pourraient les récupérer et les utiliser de manière malveillante. Cette approche rend également difficile la modification des informations d’identification sans modifier également le logiciel. Bien que l’utilisation d’informations d’identification soit une approche raisonnable pour des tests rapides, une solution de production doit utiliser une autre approche d’authentification. C'est pourquoi les bonnes pratiques AWS recommandent de ne pas utiliser les informations d'identification stockées dans une application.

Une approche plus sécurisée pour l’authentification des appels d’API consiste à utiliser des rôles IAM. AWS Identity and Gestion Des Accès (IAM) permet aux utilisateurs de gérer l'accès à l'infrastructure AWS. Toute instance de calcul, telle qu’une machine BIG-IP, peut se voir attribuer un rôle IAM qui autorise un ensemble spécifique de fonctionnalités. Lorsque l’instance démarre, IAM génère un ensemble temporaire d’informations d’identification pour l’instance. Ces informations d’identification durent tant que l’instance fonctionne et activent uniquement les fonctionnalités API spécifiées. Lorsqu'elle est configurée avec un rôle IAM, l'instance BIG-IP ne stocke pas les informations d'identification, mais a accès uniquement aux API d'infrastructure nécessaires, offrant ainsi plus de sécurité que l'authentification basée sur les informations d'identification.

Comme mentionné précédemment, les centres de données AWS existent dans des régions géographiques, chacune pouvant exister dans une zone de disponibilité (AZ). Chaque AZ au sein d'une région ne partage rien avec les autres AZ : pas d'alimentation électrique, de réseau ou de bâtiments partagés. En fait, chaque AZ est géographiquement séparée des autres au sein d’une région. En raison de la séparation entre les zones, les abonnés AWS peuvent être sûrs qu’un événement impactant une zone de disponibilité n’aura pas d’impact sur une autre zone de disponibilité. En d'autres termes, en règle générale, au plus une AZ au sein d'une région devrait être indisponible à un moment donné. Cela signifie que tout service déployé sur deux ou plusieurs zones de disponibilité doit être disponible en permanence.

La plateforme BIG-IP prend en charge la haute disponibilité sur les zones de disponibilité AWS à l'aide d'une adresse IP élastique AWS, qui est une adresse IP non intrinsèquement associée à une instance de calcul. Au lieu de cela, l’adresse IP peut être transmise dynamiquement à une adresse IP privée d’une instance de calcul en cours d’exécution. Pour permettre une haute disponibilité multizone, des ensembles identiques d'instances BIG-IP et de serveurs application sont chacun placés dans leur propre AZ. Initialement, l’IP élastique est attribuée à l’une des instances BIG-IP. Des connexions sont établies à partir de chaque client vers l'IP élastique qui les transmet à son tour à l'adresse IP privée sur l'une des instances BIG-IP. En cas de panne, l'autre instance BIG-IP assumera les responsabilités en effectuant un appel API vers AWS, demandant que l'adresse IP élastique lui soit transmise.

En s'intégrant à l'ELB, la plateforme BIG-IP peut fournir des services application qui s'intègrent parfaitement aux fonctionnalités AWS telles que plusieurs AZ et les nœuds BIG-IP à mise à l'échelle automatique.

Placer l'ELB devant une instance BIG-IP simplifie le déploiement sur plusieurs AZ, car l'ELB peut équilibrer de manière transparente le trafic vers les piles application individuelles dans chaque AZ où une instance BIG-IP fournit des services application . Cette approche simplifie l’équilibrage de charge sur plusieurs zones de disponibilité.

Lorsque l'élasticité des instances BIG-IP est nécessaire, un ELB avec mise à l'échelle automatique peut automatiquement augmenter et diminuer un pool d'appliances virtuelles BIG-IP, fournissant des services application tels qu'un pare-feu application Web, une gestion des identités ou une terminaison SSL. À l’aide d’un sandwich ELB, le trafic est acheminé vers le premier ELB qui équilibre et met automatiquement à l’échelle le trafic vers un pool d’instances BIG-IP. Pour simplifier la configuration sur le pool BIG-IP, chaque instance BIG-IP possède une seule adresse ELB dans le pool de serveurs. Le deuxième ELB achemine ensuite le trafic vers le pool de serveurs en aval.

Différentes combinaisons de topologies ELB et BIG-IP offrent une mise à l'échelle automatique, une disponibilité et des services application qui ne sont pas disponibles avec l'une ou l'autre seule. En exploitant les avantages de la plateforme ELB et BIG-IP, l’architecte peut fournir le niveau de services nécessaire à un déploiement particulier.

Pour permettre des déploiements répétables et scriptés, AWS fournit des modèles Cloud Formation (CFT), qui simplifient à la fois le déploiement et la gestion continue. Après la création d'un CFT pour l'architecture de service ou application souhaitée, AWS peut l'utiliser pour provisionner une application rapidement et de manière fiable. Les CFT sont particulièrement utiles dans les environnements DevOps, permettant aux équipes de créer facilement des processus reproductibles pour les tests et le déploiement en production.

F5 prend non seulement en charge l'utilisation de CFT pour déployer des instances BIG-IP, mais fournit également plusieurs fichiers CFT de référence pour les déploiements BIG-IP typiques .

Le réglage des paramètres dans les fichiers CFT de référence permet des déploiements scriptés de solutions BIG-IP pour différents scénarios, y compris la mise à l'échelle automatique des instances BIG-IP ou des serveurs back-end derrière les instances BIG-IP, ainsi que des scénarios plus complexes. En automatisant les déploiements répétables au sein d'AWS à l'aide de solutions CFT et F5, des environnements application complexes peuvent être déployés rapidement et avec peu de travail.

Bien entendu, la technologie n’a que peu d’utilité si elle ne peut pas être pleinement exploitée. À cette fin, F5 fournit une documentation complète. Une documentation est disponible pour la plateforme BIG-IP en général et pour les spécificités d'une instance BIG-IP dans AWS. Un bon point de départ pour toute question est Ask F5 .

L'onglet documentation fournit des informations sur des modules BIG-IP spécifiques ainsi qu'une section entière sur l'intégration AWS. Le portail AWS fournit une interface consultable pour la documentation, les articles, la communauté et les ressources, de la mise en route aux scénarios de déploiement complexes.

Pour les questions auxquelles la documentation ne répond pas, la communauté F5 DevCentral est prête à fournir des réponses et de l'aide.

La marche vers l’adoption du cloud public n’est plus une mode, mais une tendance durable dans l’informatique. Amazon Web Services, en tant que fournisseur mondial de services de cloud public le plus important et le plus complet, offre aux organisations la possibilité de créer, de tester et de déployer des applications sans aucun équipement sur site. F5 a mis à disposition ses services avancés de distribution application dans le cadre de l’écosystème AWS et les a configurés pour aider les applications à être plus rapides, plus intelligentes et plus sûres dans les environnements cloud AWS.