Passer au contenu principal

Créer un load balancer

Un load balancer (équilibreur de charge) reçoit le trafic entrant et le distribue vers des VM (Virtual Machine) de backend (serveur dorsal). Par défaut, la création produit un load balancer internet‑facing (exposé à Internet) : la résolution DNS (Domain Name System) renvoie une IP publique. Pour créer un load balancer interne dans un VPC (Virtual Private Cloud) (résolution DNS → IP privée), utilisez le paramètre LoadBalancerType. Vous devez fournir soit des subnet (sous-réseaux) soit des AvailabilityZoneNames.

Permissions​

info

Cette action nécessite les permissions IAM (Identity and Access Management) suivantes :

  • compute.loadBalancer.create
Prérequis (API)
  • Région : https://api.{region}.numspot.com
  • Auth : Bearer token (tous les endpoints Load Balancer sont protégés).
  • spaceId requis dans l'URL.
  • Nom du LB : max 32 chars, a-zA-Z0-9- uniquement (s'applique aux ressources nommées : LB, listeners, règles, etc.).
  • HTTPS : Si vous terminez TLS (Transport Layer Security) sur le LB, créez d'abord un certificat serveur (endpoint CreateServerCertificate), puis attachez‑le via UpdateLoadBalancer.

Étapes via l'API​

Créer le load balancer​

POST /compute/spaces/{spaceId}/loadBalancers Le LB reçoit un nom DNS unique. Choisissez internal ou internet-facing via LoadBalancerType. Fournissez Subnets ou AvailabilityZoneNames.

Ajouter un ou plusieurs listeners​

POST /compute/spaces/{spaceId}/loadBalancers/{id}/listeners Les listeners définissent protocole/ports (ex. HTTP/HTTPS/TCP) et portent éventuellement un certificat TLS.

(Optionnel) Créer une politique de session persistante — stickiness (persistance de session)​

POST /compute/spaces/{spaceId}/loadBalancers/{id}/policies Deux modes : cookie géré par le LB (durée = cookie navigateur) ou cookie applicatif (durée = cookie de l'app). HTTP/HTTPS uniquement.

Enregistrer des VM backend​

PUT /compute/spaces/{spaceId}/loadBalancers/{id}/backendMachines/link Fournissez au moins BackendVmIds ou BackendIps. Les VM peuvent être dans d'autres subnet/AZ tant que tout est dans le même VPC. L'enregistrement peut prendre un peu de temps.

Contrôler l'état des VM​

GET /compute/spaces/{spaceId}/loadBalancers/{id}/vmsHealth retourne la santé des backends enregistrés.

Cas d'usage rapides​

  • Site public : LB internet‑facing + listeners 80/443, VM web.
  • Micro‑services privés : LB interne dans un VPC, exposé uniquement aux workloads internes.
  • Terminaison TLS : certificat via CreateServerCertificate puis attachement côté LB.
  • Sessions persistantes pour applis stateful (panier, portail) : stickiness (persistance de session) HTTP/HTTPS.

Bonnes pratiques​

  • Nommage : respectez la contrainte 32 chars / alphanum + tiret pour éviter les 400.
  • Sécurité : ouvrez uniquement les ports nécessaires dans les security group (groupes de sécurité) et isolez les LBs internes dans le VPC.
  • Évolution : pour changer de certificat ou de policy, passez par UpdateLoadBalancer (un seul attribut par appel).
  • Traçabilité : utilisez des tags (étiquettes) pour env/projet/service.

Erreurs fréquentes (et résolution)​

  • Création sans Subnets ni AvailabilityZoneNames → 400 : fournissez l'un des deux.
  • Politique de stickiness (persistance de session) sur TCP → 400 : stickiness HTTP/HTTPS seulement.
  • Impossible de supprimer une policy encore activée sur un listener → désactivez d'abord la policy sur le listener (via UpdateLoadBalancer), puis appelez DELETE /compute/spaces/{spaceId}/loadBalancers/{id}/policies.
  • Détacher un Internet Gateway d'un VPC qui a des LBs internet‑facing → interdit : supprimez/convertissez d'abord les LBs publics.

Console​

info

La création d'un load balancer n'est pas disponible depuis la console Numspot.

Utilisez l'API ou Terraform (voir les onglets correspondants).

Cette page vous a-t-elle été utile ?