| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Gestion des performances du réseau Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Présentation de la gestion des performances du réseau
2. Utilisation des groupements de liaisons
3. Utilisation des réseaux locaux virtuels (VLAN)
4. Administration des réseaux pontés (tâches)
5. Présentation de la fonctionnalité de chemins d'accès multiples sur réseau IP (IPMP)
6. Administration de la fonctionnalité de chemins d'accès multiples sur réseau IP (tâches)
7. Echange d'informations sur la connectivité réseau à l'aide du protocole LLDP
8. Utilisation des fonctionnalités Data Center Bridging dans Oracle Solaris
9. Pontage virtuel d'extrémité dans Oracle Solaris
10. Equilibreur de charge intégré (présentation)
Topologie DSR (Direct Server Return)
Topologie NAT (Network Address Translation)
Fonctionnement de l'équilibreur de charge intégré
Utilitaire de gestion des services (SMF)
Interface de ligne de commande ILB
Commandes et sous-commandes ILB
11. Configuration de l'équilibreur de charge intégré
12. Gestion de l'équilibreur de charge intégré
13. Protocole de redondance de routeur virtuel (présentation)
A. Types de groupements de liaisons : comparaison des fonctionnalités
B. Groupement de liaisons et IPMP : comparaison des fonctionnalités
ILB prend en charge les modes DSR (Direct Server Return) et NAT (Network Address Translation) sans conservation de statut pour IPv4 et IPv6 dans les topologies à une ou deux branches.
Topologie DSR sans conservation de statut
Topologie NAT (modes Full-NAT et Half-NAT)
En mode DSR, ILB répartit les demandes entrantes sur les serveurs backend. Le trafic de retour en provenance de ces serveurs vers les clients contourne ILB. Toutefois, vous pouvez également configurer ILB en tant que routeur d'un serveur backend. Dans ce cas, la réponse du serveur backend envoyée au client est acheminée par le biais du système qui exécute ILB. L'implémentation actuelle de l'équilibreur de charge intégré en mode DSR n'offre pas de fonction de suivi des connexions TCP (sans conservation de statut). En mode DSR sans conservation de statut, ILB n'enregistre pas d'informations relatives à l'état des paquets traités, excepté dans le cadre de statistiques. Dans la mesure où ILB n'enregistre pas de statut dans ce mode, les performances sont comparables aux performances normales assurées en mode de transfert IP. Ce mode est particulièrement adapté aux protocoles sans connexion.
Avantages
Cette topologie offre de meilleures performances que le mode NAT car seule l'adresse MAC de destination des paquets est modifiée et les serveurs répondent directement aux clients.
Vous bénéficiez d'une transparence totale entre le serveur et le client. Les serveurs perçoivent une connexion directement à partir de l'adresse IP client et répondent au client via la passerelle par défaut.
Inconvénients
Le serveur backend doit répondre à la fois aux demandes envoyées à sa propre adresse IP (vérifications de l'état) et à l'adresse IP virtuelle (trafic avec équilibrage de la charge).
Etant donné que l'équilibreur de charge ne gère aucun état de connexion (sans conservation de statut), l'ajout ou le retrait de serveurs entraîne l'interruption des connexions en cours.
Le schéma ci-dessous illustre l'implémentation de l'équilibreur de charge intégré dans la topologie DSR.
Figure 10-1 Topologie DSR (Direct Server Return)
Dans ce schéma, les deux serveurs backend sont situés dans le même sous-réseau (192.168.1.0/24) que l'équilibreur de charge intégré. Ces serveurs sont également connectés au routeur de manière à pouvoir répondre directement aux clients après avoir reçu une demande transférée par ILB.
ILB utilise la topologie NAT en mode autonome exclusivement à des fins d'équilibrage de la charge. Dans ce mode, l'équilibreur de charge intégré réécrit les informations d'en-tête, et gère aussi bien le trafic entant que le trafic sortant. ILB fonctionne en mode Half-NAT ou Full-NAT. Toutefois, la topologie Full-NAT réécrit également l'adresse IP source de sorte que le serveur considère que toutes les connexions proviennent de l'équilibreur de charge. Le mode NAT offre une fonction de suivi des connexions TCP (avec conservation de statut). Le mode NAT renforce la sécurité et s'adapte mieux au trafic HTTP (Hypertext Transfer Protocol) et SSL (Secure Sockets Layer).
Avantages
Cette topologie fonctionne avec tous les serveurs backend en modifiant la passerelle par défaut pour pointer vers l'équilibreur de charge.
Etant donné que l'équilibreur de charge gère l'état de connexion (avec conservation de statut), l'ajout ou le retrait de serveurs n'entraîne pas l'interruption des connexions en cours.
Inconvénients
Ce mode est moins rapide que la topologie DSR car le traitement implique la manipulation de l'en-tête IP et les serveurs envoient des réponses à l'équilibreur de charge.
Tous les serveurs backend doivent utiliser l'équilibreur de charge en tant que passerelle par défaut.
Le schéma ci-dessous illustre l'implémentation de l'équilibreur de charge intégré dans la topologie NAT.
Figure 10-2 Topologie NAT (Network Address Translation)
Dans ce cas, toutes les demandes envoyées à l'adresse IP virtuelle passent par l'équilibreur de charge intégré puis sont transférées aux serveurs backend. En mode NAT, toutes les réponses provenant des serveurs backend passent par ILB.
![]() | Attention - Le chemin d'accès au code NAT implémenté dans l'équilibreur de charge intégré ne correspond pas à celui de la fonction de filtre IP d'Oracle Solaris. N'utilisez pas ces deux chemins d'accès aux codes simultanément. |
En mode Half-NAT, l'équilibreur de charge intégré réécrit uniquement l'adresse IP de destination dans l'en-tête des paquets. Si vous mettez en oeuvre l'implémentation Half-NAT, vous ne pouvez pas vous connecter à l'adresse IP virtuelle (VIP) du service à partir du sous-réseau sur lequel réside le serveur. Le tableau suivant répertorie les adresses IP des paquets circulant entre un client et ILB, puis entre ILB et un serveur backend.
Tableau 10-1 Flux de demande et de réponse dans la topologie Half-NAT lorsque le serveur et le client résident sur différents réseaux
|
Si vous connectez le système client au réseau des serveurs, le serveur concerné répond directement au client. La quatrième étape n'est pas exécutée. Aussi, l'adresse IP source de la réponse que le serveur envoie au client n'est pas valide. Lorsque le client envoie une demande de connexion à l'équilibreur de charge, la réponse parvient au serveur concerné. Par conséquent, la pile IP du client transmet correctement toutes les réponses.
Dans ce cas, les flux de demande et de réponse suivent les étapes du tableau ci-dessous.
Tableau 10-2 Flux de demande et de réponse dans la topologie Half-NAT lorsque le serveur et le client résident sur le même réseau
|
En mode Full-NAT, les adresses IP source et de destination sont réécrites pour garantir que le trafic passe par l'équilibreur de charge dans les deux directions. La topologie Full-NAT permet de se connecter à l'adresse VIP à partir du sous-réseau sur lequel sont situés les serveurs.
Le tableau suivant répertorie les adresses IP des paquets circulant entre un client et ILB, puis entre ILB et un serveur backend dans la topologie Full-NAT. Aucun routage par défaut par le biais de l'équilibreur de charge intégré n'est requis dans ces serveurs. Mais notez que l'administrateur doit impérativement réserver une adresse IP ou une plage d'adresses qui feront office d'adresses source de l'équilibreur de charge intégré dans le cadre des communications avec les serveurs backend dans une topologie Full-NAT. Partons du principe que les adresses utilisées appartiennent au sous-réseau C. Dans ce scénario, ILB se comporte comme un proxy.
Tableau 10-3 Flux de demande et de réponse dans la topologie Full-NAT
|