Aller au contenu

Solution · Répartition de charge

Des répartiteurs de charge virtuels, conçus et opérés pour vous.

Stack Harbor conçoit et opère des répartiteurs de charge virtuels qui étalent le trafic sur vos serveurs et survivent à leurs propres pannes, sur notre cloud ou devant une infrastructure qui reste exactement où elle est : AWS, OVH, serveurs dédiés ou sur site. HAProxy, Nginx, LiteSpeed WebADC ou une couche HA orchestrée sur notre PaaS.

Demander une revue de répartition de charge Voir ce que nous opérons

Sites à fort trafic, API SaaS, parcs cPanel et LiteSpeed, et environnements en cluster.

Quand c'est pertinent

Un serveur, c'est une file d'attente. Un bassin réparti, c'est un service.

La répartition de charge transforme un ensemble de serveurs en service : le trafic s'étale sur les serveurs en santé, les nœuds défaillants sortent de la rotation, les déploiements drainent les connexions au lieu de les couper, et le répartiteur lui-même est redondant. Sans elle, chaque pointe de trafic, correctif de noyau et panne matérielle atterrit sur vos utilisateurs.

  • Un lancement ou un robot double le trafic et l'origine unique expire.
  • Un serveur meurt et les utilisateurs voient des erreurs jusqu'à ce que quelqu'un édite le DNS.
  • Les déploiements coupent des connexions en cours parce que rien ne draine un nœud de la rotation.
  • Les certificats TLS vivent sur chaque serveur, et il y en a toujours un qui expire en premier.
  • Le « répartiteur » est une seule VM. Quand elle redémarre, tout ce qui est derrière disparaît.
  • Les sessions persistantes n'ont jamais été configurées, alors les connexions cassent dès qu'un deuxième serveur apparaît.
  • Les contrôles de santé testent le ping, pas l'application, alors des serveurs morts continuent de recevoir du trafic.
  • Personne ne peut voir ce que fait le bassin en ce moment.

À qui ça s'adresse

Conçu pour les charges qui ont dépassé une seule origine.

  • WordPress

    WordPress et WooCommerce à fort trafic

    Tiers applicatifs répartis derrière HAProxy ou LiteSpeed WebADC, avec coordination de cache et passage à la caisse sûr pour les sessions.

    Voir la portée

  • SaaS

    Plateformes SaaS et API

    Contrôles de santé, reprises, drainage de connexions et règles par route pour le trafic API.

    Voir la portée

  • Hébergement

    Parcs cPanel et LiteSpeed

    LiteSpeed WebADC à travers des serveurs cPanel : conscient de LSCache, prêt pour HTTP/3, sûr pour les sessions.

    Voir la portée

  • Votre infra

    Infrastructure existante

    Une couche de répartition infogérée devant des serveurs qui restent où ils sont.

    Voir la portée

  • HA

    Clusters haute disponibilité

    La porte d'entrée d'un cluster : répartiteurs jumelés, tiers de données répliqués, bascule testée.

    Voir la portée

  • PaaS

    Environnements PaaS

    Répartiteurs jumelés provisionnés et redimensionnés automatiquement devant le tier applicatif.

    Voir la portée

Portée

Les piles de répartition que Stack Harbor opère.

  • HAProxy

    Répartition couche 4 et couche 7 pour services web, API et TCP : ACL et aiguillage de contenu, sessions persistantes, protocole PROXY, rechargements à chaud, et page de stats branchée à la surveillance.

  • Répartition Nginx

    Répartition en proxy inverse avec bassins upstream, stratégies least-connection et par hachage, terminaison TLS, HTTP/2, cache en périphérie et passage WebSocket.

  • LiteSpeed WebADC

    Pour les parcs LiteSpeed et cPanel : coordination LSCache à travers les serveurs, HTTP/3 / QUIC à l'entrée, affinité de session et maintenance du bassin sans arrêt.

  • Appliances virtuelles de répartition

    Paires actif-passif avec keepalived / VRRP, IP flottante qui bascule en quelques secondes, et capacité dimensionnée à votre profil de trafic.

  • Couches HA orchestrées sur PaaS

    Répartiteurs jumelés provisionnés automatiquement devant le tier applicatif, qui se redimensionnent avec lui et participent aux déploiements sans arrêt.

  • Contrôles de santé, bascule et observabilité

    Contrôles de santé applicatifs, éjection et réadmission automatiques des serveurs, drainage de connexions pour les déploiements, automatisation TLS, et alertes branchées à la surveillance 24/7.

Topologie de référence

Aucun répartiteur de charge n’est un point unique de défaillance.

Une couche de répartition de charge en production est une paire, pas une boîte : un répartiteur actif et un passif partagent une IP flottante, les health checks décident quels serveurs reçoivent le trafic, et un nœud défaillant sort de la rotation avant que les utilisateurs s'en aperçoivent. La même forme fonctionne pour HAProxy, Nginx et LiteSpeed WebADC — sur notre cloud, devant votre infrastructure ou orchestrée dans le PaaS.

Patrons et intégrations

Les patrons autour du répartiteur.

Le proxy n'est qu'une partie du tout. Les sessions, la santé des points de terminaison, le redimensionnement du bassin, le tier de données et la couche DNS au-dessus doivent tous s'accorder.

Formes de déploiement

Trois endroits où la couche de répartition peut vivre.

  • Forme 1

    Sur le cloud Stack Harbor

    Paires de répartiteurs infogérées sur notre capacité en région canadienne, devant des serveurs hébergés chez nous. La forme la plus intégrée.

    Devis sur mesure, cadré selon le profil de trafic et le nombre de serveurs.

  • La plus courante

    Forme 2

    Devant votre infrastructure

    Une couche de répartition infogérée devant des serveurs qui restent exactement où ils sont. Aucune migration requise.

    Devis sur mesure, cadré selon la joignabilité, le SLA et le nombre de services.

  • Forme 3

    Orchestrée dans le PaaS

    La plateforme provisionne et redimensionne la couche de répartiteurs jumelés avec le tier applicatif. Vous ne possédez aucune configuration.

    Devis sur mesure, cadré avec l'environnement PaaS lui-même.

Comment le mandat fonctionne

Revoir. Concevoir. Déployer. Opérer.

  1. Revoir

    On examine votre profil de trafic, les points uniques de défaillance, le modèle de session, la posture TLS, et ce qui se passe aujourd'hui quand un serveur meurt.

  2. Concevoir

    On propose la couche par écrit avant de rien construire : HAProxy, Nginx, WebADC ou orchestrée par le PaaS; découpage L4 / L7; points de contrôle de santé; persistance; topologie de bascule.

  3. Déployer

    On monte les répartiteurs jumelés, on câble les contrôles de santé et le TLS, on répète la bascule, puis on fait passer le trafic avec un chemin de retour arrière, habituellement un changement DNS réversible.

  4. Opérer

    Surveillance de la couche et du bassin, rechargements sans arrêt pour la configuration et les certificats, revue de capacité à mesure que le trafic grandit, et réponse aux incidents avec escalade senior.

Pourquoi les équipes nous font confiance

Pourquoi les équipes confient leur porte d'entrée à Stack Harbor.

  • Redondant par défaut

    Les couches de répartition sont livrées en paires actif-passif avec IP flottante. Un répartiteur seul est signalé comme risque, jamais déployé en silence.

  • Des piles éprouvées

    HAProxy, Nginx, LiteSpeed WebADC, keepalived : des logiciels ennuyants, documentés, largement compris, configurés correctement.

  • Surveillance 24/7 et réponse aux incidents

    La couche et le bassin sont surveillés jour et nuit, avec escalade senior écrite au contrat.

  • Opérations sans arrêt

    Rechargements à chaud, drainage de connexions et renouvellements de certificats qui ne coupent jamais une requête. La maintenance cesse d'être une panne.

  • Centres de données à Montréal, basse latence

    Capacité de répartition dans nos centres de données de Montréal avec peering bas-latence, sous juridiction canadienne des données.

  • Observable, documenté, à vous

    Des pages de stats et des tableaux de bord visibles, un runbook écrit et une configuration standard que vous pourriez emporter ailleurs.

FAQ

Les questions que les équipes posent avant d'engager.

  • Quels répartiteurs de charge opérez-vous ?

    HAProxy et Nginx pour la majorité du trafic, LiteSpeed WebADC pour les parcs LiteSpeed et cPanel, keepalived/VRRP pour les paires d'appliances actif-passif, et les couches de répartition que notre PaaS provisionne automatiquement. Sur AWS, on opère aussi ALB et NLB quand ils conviennent mieux.

  • Couche 4 ou couche 7 : laquelle me faut-il ?

    La couche 4 répartit des connexions TCP : rapide, agnostique au protocole, le bon choix pour les bases de données, le courriel et le débit brut. La couche 7 comprend HTTP, donc elle peut router par hôte et par chemin, terminer le TLS, poser des en-têtes et réessayer un serveur en échec, ce dont la plupart des applications web ont besoin. Beaucoup de couches utilisent les deux.

  • Pouvez-vous répartir la charge de serveurs qu’on opère déjà, sans les migrer ?

    Oui. La couche se place devant une infrastructure qui reste exactement où elle est : cloud Stack Harbor, AWS, OVH, serveurs dédiés ou sur site. Il faut une joignabilité réseau vers les serveurs, des points de contrôle de santé convenus et un changement DNS à la bascule. Les serveurs ne bougent pas.

  • Que se passe-t-il quand le répartiteur lui-même tombe ?

    La couche tourne en paire actif-passif partageant une IP flottante via VRRP (keepalived). Si le nœud actif cesse de répondre, le nœud passif réclame l'IP en quelques secondes et le trafic continue, sans changement DNS ni étape manuelle. Un répartiteur seul, sans paire, est un risque qu'on signale, jamais quelque chose qu'on déploie en silence.

  • Soutenez-vous les sessions persistantes, les WebSockets et les connexions longues ?

    Oui : persistance par témoin ou par IP source, passage WebSocket, et délais ajustés pour le long-polling et la diffusion. On vous dira aussi quand la persistance masque un problème applicatif qu'un magasin de sessions partagé règle mieux.

  • Comment le TLS est-il géré ?

    Habituellement au répartiteur. Les certificats sont automatisés (ACME / Let's Encrypt ou vos certificats achetés) et renouvelés sans interruption. HTTP/2 est activé à l'entrée, plus HTTP/3 quand la pile le permet. Le rechiffrement vers les serveurs est disponible quand la politique l'exige.

  • Pouvez-vous répartir un parc LiteSpeed ou cPanel spécifiquement ?

    Oui. LiteSpeed WebADC est conçu pour ça : coordination LSCache à travers le bassin, HTTP/3 et affinité de session pour les applications hébergées sur cPanel. Pour les parcs mixtes, on place WebADC ou HAProxy devant avec le tuning LiteSpeed par serveur derrière. Le côté cPanel reste pleinement compatible.

  • À quoi ressemble l'option PaaS ?

    Des répartiteurs Nginx ou LiteSpeed jumelés sont provisionnés automatiquement devant le tier applicatif, se redimensionnent avec lui et participent aux déploiements sans arrêt. La bonne forme quand vous voulez la couche HA sans posséder la configuration.

  • Pouvez-vous gérer les répartiteurs AWS (ALB) et les Auto Scaling Groups ?

    Oui. On conçoit et opère les listeners ALB, les target groups et les contrôles de santé câblés aux Auto Scaling Groups : target-tracking ou par paliers, warm pools, lifecycle hooks, drainage de connexions au rafraîchissement d'instances. On vous dira aussi quand HAProxy ou un NLB convient mieux : connexions longues, IP fixes ou règles qu'ALB ne peut pas exprimer.

  • Pouvez-vous répartir la charge des bases de données aussi ?

    Oui, et elle suit la conception de la réplication, jamais l'inverse. ProxySQL pour MySQL et MariaDB (séparation lecture/écriture, routage des replicas conscient du lag), PgBouncer avec routage de bascule devant des replicas PostgreSQL en flux, RDS Proxy sur AWS. Le trafic d'écriture reste sur le primaire.

  • Faites-vous de la répartition au niveau DNS avec Cloudflare ou Route 53 ?

    Oui. Cloudflare Load Balancing offre l'aiguillage avec contrôles de santé et le routage géographique en périphérie; Route 53 couvre les politiques pondérées, par latence et de bascule. Le DNS convient pour aiguiller entre régions ou fournisseurs et ne convient pas pour la bascule instantanée, parce que les résolveurs honorent les TTL approximativement. On combine les deux.

  • Comment fonctionne le prix ?

    Cadré selon le profil de trafic, le nombre de services et de serveurs répartis, le SLA, et si la couche tourne sur notre cloud ou devant votre infrastructure. Pas de grille publiée. La revue nous donne assez pour mettre un devis fixe par écrit.

  • Qu'est-ce qu'un répartiteur de charge virtuel ?

    Une couche de répartition qui tourne comme machine virtuelle plutôt que comme boîtier matériel : la même distribution du trafic et les mêmes contrôles de santé sans appareil physique. On opère HAProxy, Nginx ou LiteSpeed WebADC en paires actif-passif avec IP flottante, pour qu'un nœud en panne ne fasse pas tomber la couche.

Base de connaissances

Répartition de charge, lecture en profondeur.

Runbooks HAProxy, Nginx et répartition de charge façonnés pour la production, derrière la couche infogérée ci-dessus.

Voir tous les articles Répartition de charge

Sur le blogue

Des guides pour la décision que vous devez prendre

Tous les articles →

Donnez une vraie porte d'entrée à votre infrastructure.

Des répartiteurs de charge infogérés avec bascule jumelée, contrôles de santé et opérations 24/7 derrière, sur notre cloud ou devant le vôtre.

Demander une revue de répartition de charge Parcourir la base de connaissances Répartition de charge