Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Configuration réseau

Configuration réseau

Niveau 4, niveau 7, même configuration

Du point de vue de l’architecture réseau, la répartition de charge de niveau 7 est très semblable à celle au niveau 4 : un équipement est placé en amont des serveurs, analyse le flux, et répartit les connexions. Et d’ailleurs, ce sont souvent les mêmes équipements qui peuvent répartir au niveau 4 ou au niveau 7.

Le schéma de principe de la répartition de charge est donc comme suit :

image054

On représente ici un petit nombre de serveurs, mais on peut en intégrer plusieurs dizaines sans difficulté.

Répartition de charge inter-datacenter

Les dispositifs cités ici n’impliquent pas que tous les serveurs soient dans un même datacenter. Rien n’interdit de ressortir sur l’Internet pour trouver un serveur ailleurs. Mais bien sûr, cela impliquerait une forte consommation de bande passante, essentiellement inutile.

C’est pourquoi pour des répartitions intercentres, on préfère généralement les dispositifs de niveau DNS, cités plus haut.

Néanmoins, dans certains cas on peut disposer d’un débit dédié sur fibre optique entre deux centres. Du moins jusqu’à des distances de quelques dizaines de kilomètres, car à l’échelle des continents, le très haut débit coûte très cher, et induit inévitablement un temps de latence important. Si un internaute est d’abord dirigé sur un datacenter DCA, et que toutes ses requêtes transitent ensuite par ce datacenter A pour atteindre un datacenter DCB situé dans un autre pays, alors la qualité de service ne pourra être que médiocre. Et la tolérance aux pannes sera médiocre aussi, puisque DCA reste point de passage obligé.

image056

Ici, typiquement, le load-balancer du datacenter DCA serait configuré en mode « priority activation », de sorte qu’il commence par charger ses propres serveurs, puis au delà d’un certain seuil, il part en débordement sur le second datacenter.

Configuration réseau et tolérance aux pannes de l’équipement

Etant seul, en frontal de tous les serveurs de la plateforme, l’équipement de répartition de charge est un point de fragilité de l’architecture, un « Single Point of Failure ». Il est donc nécessaire qu’il soit secouru, avec un dispositif transparent de bascule en secours.

Toutes les solutions de répartition de charge intègrent un tel mécanisme, y compris celles basées sur OpenBSD ou Linux.

On met classiquement en place deux équipements en parallèle, dont l’un est actif et l’autre est passif, en standby. Les deux équipements sont interconnectés, soit par le switch, soit par un câble croisé, soit par une liaison série dédiée. Sur ce lien, le serveur passif surveille le serveur actif par un échange de « heartbeat », de battements de cœur. S’il détecte une panne, le serveur passif devient actif, et reprend l’adresse IP à son compte.

En fait, pour un passage en secours réellement transparent, les deux équipements doivent échanger plus qu’un simple heartbeat, ils doivent partager la table d’allocation des connexions, de sorte que même les connexions TCP/IP ne soient pas cassées lors du passage en secours.

image057
image060

On a fait figurer ici un switch en amont et un autre en aval.

Ici, la configuration avec un switch unique.

Pour une réelle tolérance à la panne d’un équipement, on aura la configuration suivante :

image058
image060

Enfin, dans le cas de load-balancer logiciels, on peut aisément combiner plusieurs fonctions sur les mêmes serveurs, typiquement routeur, firewall et load-balancer, comme suit :

image066