A propos des équilibreurs de charge d'application
Utilisez l'équilibreur de charge d'application (IBM Cloud® Application Load Balancer for VPC) pour répartir le trafic entre plusieurs instances de serveur dans la même région de votre VPC.
Si vous disposez de charges de travail publiques et privées et d'un trafic de couche 7, utilisez un équilibreur de charge d'application.
Types d'équilibreurs de charge d'application
Comme indiqué dans la rubrique Présentation des équilibreurs de charge pour VPC, vous pouvez créer un équilibreur de charge d'application public ou privé.
Ce tableau présente une comparaison entre les fonctionnalités publiques et privées.
| Fonction | Equilibreur de charge public | Equilibreur de charge privé |
|---|---|---|
| Accessible sur Internet? | Oui, mais avec un nom de domaine qualifié complet | Non, uniquement par les clients internes, dans les mêmes région et VPC |
| Accepte tout le trafic ? | Oui | Oui (la restriction consistant à n'accepter que le trafic provenant de l'espace d'adressage RFC-1918 a été supprimée.) |
| Comment enregistrer un nom de domaine? | Adresses IP publiques | Adresses IP privées |
Equilibreur de charge d'application public
Une instance publique d'équilibreur de charge d'applications se voit attribuer un nom de domaine complet (FQDN) accessible au public, que vous devez utiliser pour accéder à vos applications hébergées derrière l'équilibreur de charge. Ce nom de domaine peut être enregistré avec une ou plusieurs adresses IP publiques.
Avec le temps, le nombre et la valeur de ces adresses IP publiques peuvent changer en raison d'activités de maintenance et de mise à l'échelle. Les instances de serveurs virtuels back-end qui hébergent votre application doivent s'exécuter dans la même région et au sein du même VPC.
Utilisez le nom de domaine qualifié complet attribué pour envoyer le trafic vers l'équilibreur de charge d'application public afin d'éviter des problèmes de connectivité dans vos applications lors de la maintenance du système ou de la réduction des activités.
Equilibreur de charge d'application privé
Un équilibreur de charge d'application privé est accessible via vos sous-réseaux privés que vous avez configurés pour créer l'équilibreur de charge.
Tout comme pour un équilibreur de charge d'application public, un FDQN est attribué à votre instance d'équilibreur de charge d'application privé. Toutefois, ce nom de domaine est enregistré avec une ou plusieurs adresses IP privées.
Les opérations IBM Cloud peuvent toutefois changer le nombre et la valeur des adresses IP privées qui vous sont affectées au fil du temps, en fonction d'activités de maintenance et de mise à l'échelle. Les instances de serveurs virtuels back-end qui hébergent votre application doivent s'exécuter dans la même région et au sein du même VPC.
Utilisez le nom de domaine qualifié complet attribué pour envoyer le trafic vers l'équilibreur de charge d'application privé afin d'éviter des problèmes de connectivité dans vos applications lors de la maintenance du système ou de la réduction des activités.
Méthodes d'équilibrage de charge
Trois méthodes d'équilibrage de charge sont disponibles pour répartir le trafic sur les serveurs d'applications de back-end :
Circulaire
Il s'agit de la méthode d'équilibrage de charge par défaut. Avec cette méthode, un équilibreur de charge d'application achemine les connexions client entrantes en mode circulaire vers les serveurs de back-end. En résultat, tous les serveurs de back-end reçoivent approximativement un nombre égal de connexions client.
Circulaire pondéré
Avec cette méthode, un équilibreur de charge d'application transfère les connexions entrantes des clients vers les serveurs back-end proportionnellement au poids qui a été attribué à ces serveurs. Un poids par défaut de 50 est
attribué à chaque serveur. Le poids peut être personnalisé à n'importe quelle valeur comprise dans la plage 0- 100.
Par exemple, si les serveurs d'applications A, B et C ont les poids 60, 60 et 30, les serveurs A et B reçoivent un nombre égal de connexions, tandis que le serveur C reçoit la moitié de ce nombre de connexions.
L'affectation d'un poids 0 à un serveur signifie qu'aucune nouvelle connexion n'est réacheminée vers ce serveur, mais le trafic existant continue de circuler. L'utilisation d'un poids de 0 peut aider à arrêter un
serveur en douceur et à le retirer de la rotation des services.
Les valeurs de pondération des serveurs ne sont applicables qu'avec la méthode circulaire pondérée. Elles sont ignorées avec les méthodes Permutation circulaire, Nombre minimal de connexions et équilibrage de charge.
Nombre minimal de connexions
Avec cette méthode, l'instance de serveur back-end qui gère le moins de connexions à un moment donné reçoit la prochaine connexion client.
Ecouteurs de front-end et pools de back-end
Les écouteurs de front-end sont les ports d'application des équilibreurs de charge qui reçoivent les demandes entrantes, tandis que les pools de back-end sont les serveurs d'application derrière les équilibreurs de charge.
Instructions pour l'utilisation des écouteurs
Passez en revue les instructions suivantes pour les programmes d'écoute de front-end:
- Vous pouvez définir jusqu'à 10 écouteurs front-end et les associer à des pools back-end sur vos serveurs d'applications back-end.
- Le nom de domaine complet qualifié complet affecté à votre équilibreur de charge et aux ports d'écouteurs de front-end sont exposés au réseau Internet public. Les demandes d'utilisateurs entrantes sont reçues sur ces ports.
- Les protocoles d'écouteur de front-end et de pool de back-end pris en charge sont HTTP, HTTPS et TCP.
- Vous pouvez configurer un écouteur de front-end HTTP/HTTPS avec un pool de back-end HTTP/HTTPS.
- HTTP/2 est pris en charge uniquement pour les auditeurs.
- Les écouteurs et les pools HTTP et HTTPS sont interchangeables.
- Vous ne pouvez configurer qu'un listener frontal TCP avec un pool arrière TCP.
- Vous pouvez connecter jusqu'à 50 instances de serveur virtuel à un pool de back-end. Le trafic est envoyé à chaque instance sur le port de données spécifié. Ce port de données ne doit pas nécessairement être identique au port de l'écouteur de front-end.
- Les points de terminaison privés uniquement pour Secrets Manager ne sont pas pris en charge avec les écouteurs HTTPS. Pour configurer un programme d'écoute HTTPS dans un ALB, vous devez télécharger vos certificats TLS sur un point de terminaison « Public et privé ».
Ecouteur de redirection HTTPS
Les écouteurs de redirection HTTPS redirigent le trafic d'un écouteur HTTP vers un écouteur HTTPS. Cette action ne nécessite l'application d'aucune règle sur l'écouteur.
Par exemple, si un service écoute sur le port 443 à l'adresse HTTPS et qu'un utilisateur tente d'accéder au service sur le port 80 en utilisant l'adresse HTTP, la requête est alors automatiquement redirigée vers le port 443 à l'adresse HTTPS.
Si des stratégies sont présentes sur l'écouteur de redirection HTTPS, elles sont évaluées en premier. Si aucune correspondance de politique n'est trouvée, la requête est redirigée vers un écouteur HTTPS configuré.
Propriétés de l'écouteur de redirection HTTPS
| Propriété | Description |
|---|---|
| Programme d'écoute | Ecouteur HTTPS vers lequel une demande est redirigée. |
| Codes de statut HTTP | Code d'état de la réponse renvoyée par l'équilibreur de charge de l'application. Les valeurs admises sont : 301, 302, 303, 307 ou 308. |
| URI | URI relatif vers lequel une demande est redirigée. Cette propriété est facultative. |
Politiques de sécurité du pool de back-end
Lors de l'édition d'un pool back-end dans un équilibreur de charge, vous pouvez spécifier l'une des actions de politique à sécurité intégrée suivantes :
- Transférer : L'équilibreur de charge achemine les demandes vers un pool de sauvegarde désigné. Cela permet d'obtenir un chemin de basculement propre vers un autre ensemble de serveurs d'application. Un pool de sauvegarde existant doit être configuré et prêt à recevoir du trafic.
- Abandon : l'équilibreur de charge abandonne toutes les demandes entrantes et le client ne reçoit aucune réponse.
- Échec : L'équilibreur de charge rejette les demandes avec un code d'état HTTP 503 ("Service Unavailable"), informant le client que le service est temporairement indisponible.
Vous pouvez choisir une cible à sécurité intégrée dans une liste de pools de sauvegarde applicables.
Exigences du pool de cibles à sécurité intégrée (si l'action est Forward):
- doivent appartenir au même équilibreur de charge
- doivent avoir le même protocole ou un protocole compatible ( TCP n'est compatible qu'avec TCP, mais toute combinaison de HTTP et HTTPS est compatible)
Seuls les équilibreurs de charge d'application permettent d'associer plus d'un pool à un seul auditeur. Assurez-vous qu'au moins un pool existe déjà dans l'équilibreur de charge.
Dans une configuration d'équilibreur de charge, un auditeur est considéré comme la ressource parentale. Vous pouvez associer des pools à cet auditeur de deux manières, en les référençant directement ou indirectement. Pour l'association directe,
configurez le pool en tant que default_pool de l'auditeur. Pour une association indirecte, référencez le pool à partir d'un autre pool par le biais d'une relation failsafe_policy.target, en vous assurant que l'autre
pool est déjà lié à l'auditeur.
Elasticité
L'équilibreur de charge d'application se met à l'échelle en ajoutant des ressources de calcul lorsque la charge augmente.
Déchargement SSL et autorisations requises
Le déchargement SSL (Secure Sockets Layer, SSL ) permet à l'équilibreur de charge d'applications de mettre fin à toutes les connexions HTTPS entrantes.
Lorsqu'un écouteur HTTPS est configuré avec un pool HTTP, la demande HTTPS est arrêtée au front-end et l'équilibreur de charge établit une communication HTTP en texte brut avec l'instance de serveur de back-end. Avec cette technique, les établissements de liaison SSL et les tâches de chiffrement ou de déchiffrement (gros consommateurs des ressources d'unité centrale) sont transférés en dehors des instances de serveur back-end, ce qui permet à ces dernières d'utiliser tous leurs cycles d'unité centrale pour traiter le trafic des applications.
Le déchargement SSL nécessite de fournir un certificat SSL pour l'équilibreur de charge d'application afin d'effectuer des tâches de déchargement SSL. Vous pouvez gérer les certificats SSL via IBM Cloud Secrets Manager.
Vous pouvez créer une autorisation via la section « Autorisations » d'IAM. Assurez-vous de choisir Services d'infrastructure VPC comme service Source, puis sélectionnez Ressources spécifiques. Cliquez sur Sélectionnez un attribut et choisissez Type de ressource de la liste. Sélectionnez « Équilibreur de charge pour VPC » comme type de ressource, puis cliquez sur « Suivant ». Pour le service « Target », sélectionnez Secrets Manager. Définissez l'accès à l'instance du service cible sur « Toutes les instances » ou sur votre instance spécifique d' IBM Cloud Secrets Manager. Affectez le rôle d'accès au service Editeur. Pour plus d'informations, voir Octroi d'accès entre services.
Pour éviter les erreurs, vous devez établir l'autorisation requise entre votre équilibreur de charge et IBM Cloud Secrets Manager. De plus, la mise à jour des certificats dans Secrets Manager ne met pas automatiquement à jour votre ALB. Pour que votre équilibreur de charge reflète les modifications apportées au certificat, effectuez une petite mise à jour (par exemple, la modification de l'intervalle de vérification de santé ou de la valeur de délai d'attente) pour provoquer une actualisation. Cette action met à jour le certificat sur votre équilibreur de charge afin qu'il corresponde au certificat dans Secrets Manager. Vous pouvez ensuite rétablir les valeurs d'origine des modifications que vous avez apportées.
Les protocoles TLS (Transport Layer Security) 1.2 et 1.3 sont pris en charge. Cependant, TLS 1.3 est utilisé par défaut, sauf si vous configurez spécifiquement le client pour qu'il utilise 1.2. Les répartiteurs de charge acceptent tous les algorithmes de chiffrement TLS 1.3 pris en charge qui sont envoyés par la requête côté client.
La liste suivante répertorie les chiffrements pris en charge (par ordre de priorité) :
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Localisation du CRN de certificat
Lors de la configuration de l'authentification pour un équilibreur de charge d'application pendant le provisionnement dans la console, vous pouvez choisir de spécifier le certificat Secrets Manager et SSL, ou le CRN du certificat. Vous pouvez procéder ainsi si vous ne voyez pas l'option Secrets Manager dans le menu déroulant, ce qui signifie que vous n'avez pas accès à l'instance Secrets Manager. N'oubliez pas que vous devez saisir le CRN si vous utilisez l'API pour créer un ALB.
Pour obtenir le CRN, vous devez disposer d'une autorisation d'accès à l'instance d' Secrets Manager.
Pour rechercher le CRN d'un certificat, procédez comme suit :
- Dans la console d' IBM Cloud, accédez à
'icône Menu de navigation > Liste des ressources. - Cliquez pour développer la section Sécurité, puis sélectionnez l' Secrets Manager e pour lequel vous souhaitez trouver le CRN.
- Sélectionnez n'importe où dans la ligne de la table du certificat pour ouvrir le panneau latéral des détails du certificat. Le CRN du certificat est indiqué.
Chiffrement SSL de bout en bout
La configuration d'un écouteur HTTPS avec un pool HTTPS active le chiffrement SSL de bout en bout. L'ALB met fin à la requête entrante HTTPS au niveau du listener frontal et établit une connexion HTTPS avec les instances back-end. Le chiffrement de bout en bout permet de chiffrer, via HTTPS, l'ensemble du trafic transitant par l'équilibreur de charge vers les nœuds du back-end.
Pour configurer le chiffrement SSL de bout en bout :
- Configurez un écouteur frontal d' HTTPS avec votre certificat SSL, comme vous le feriez lors de la configuration du déchargement de l' SSL.
- Configurez un pool de back-end HTTPS.
- Ajoutez votre instance de membre de back-end au pool de back-end HTTPS. Assurez-vous que vos instances back-end sont configurées pour gérer le trafic HTTPS.
- Configurez le contrôle d'intégrité avec le type HTTPS pour effectuer des contrôles d'intégrité chiffrées avec les membres de back-end.
Un équilibreur de charge d'application ne vérifie pas les certificats SSL des instances de membre de back-end.
Mise à l'échelle horizontale
Un équilibreur de charge d'application ajuste automatiquement sa capacité en fonction de la charge. Quand cet ajustement se produit, vous pouvez remarquer un changement au niveau du nombre d'adresses IP associées au nom DNS de l'équilibreur de charge.
Support MZR
IBM Cloud Application Load Balancer for VPC prend en charge les régions multi-zones (MZR). Vous pouvez mettre en place la haute disponibilité et la redondance en déployant un équilibreur de charge d'application avec des sous-réseaux de différentes zones. Si des sous-réseaux de plusieurs zones sont utilisés pour mettre à disposition un équilibreur de charge d'application, les dispositifs de ce dernier sont déployés sur plusieurs zones.
Intégration à des groupes d'instances
IBM Cloud Application Load Balancer for VPC s'intègre à des groupes d'instances, qui peuvent effectuer une mise à l'échelle automatique (auto scale) de vos membres de back-end. Les membres du pool sont ajoutés et supprimés de manière
dynamique en fonction de votre utilisation et de vos exigences.
Acheminement des journaux de chemin de données
Lorsque la journalisation du chemin de données est activée, les journaux de l'équilibreur de charge sont transmis au service IBM Cloud Logs, où vous pouvez consulter vos journaux de chemin de données.
Prise en charge de HTTP2
Les équilibreurs de charge d'application prennent en charge le trafic HTTP2 de bout en bout et fonctionnent avec des protocoles d'écoute définis comme HTTPS ou TCP.
Prise en charge de WebSocket
WebSocket fournit des canaux de communication en duplex intégral sur une seule connexion TCP. Les équilibreurs de charge d'application prennent en charge WebSocket avec chaque type de protocole d'écoute ( HTTP / HTTPS / TCP ).
Haute disponibilité et équilibreurs de charge applicative
Pour vous assurer que la haute disponibilité (HA) fonctionne avec votre ALB, associez trois sous-réseaux provenant de zones différentes à l'ALB et déployez des appliances dans ces zones. Pour ce faire, vous sélectionnez d'abord vos sous-réseaux
lors du processus de création de l'ALB. Vous pouvez sélectionner deux sous-réseaux dans différentes zones (telles que us-south-1 et us-south-2). Cela permet de créer les adresses IP de l'ALB (telles que les adresses
IP des appliances) dans deux sous-réseaux différents.
Vous pouvez également le faire avec des ALB déjà existants. Allez dans la section Ressources attachées de la page de détails de votre équilibreur de charge. Dans la section Sous-réseau, cliquez sur Modifier les sous-réseaux. Ensuite, ajoutez d'autres sous-réseaux. L'ALB passe à l'état « Migration ». Une fois la migration terminée, vous obtenez une nouvelle adresse IP pour l'appareil à partir du sous-réseau que vous venez de connecter. Vous disposez désormais de deux adresses IP provenant de sous-réseaux différents dans des zones différentes.