Voici le contexte:
- 1 serveur W2K3 Edt. Std SP1 avec IIS 6.0, qui accueille le site Web d'une
application, un serveur d'application Apache Tomcat. La base de données
Oracle est rattachée sur un serveur Unix via Odbc/Jndi (application).
- 1 second serveur W2K3 Edt. std SP1 avec IIS 6.0.
Les deux serveurs sont membre d'une AD 2000.
L'application métier en question (développée en JAVA / .NET) consomme
énormément de ressources et le nombre de connexions simultanées peut
atteindre 400 (en moyenne 350). Les serveurs sont des HP Lame Xeon 3,6 Ghz
avec 3 Go Ram en Raid1.
Pour des raisons de performances, je souhaiterai mettre en place le NLB
(équilibrage de charge) maintenant en standard dans toutes les versions
serveurs 2003. Les requêtes clientes entrantes seraient donc réparties vers
les 2 serveurs HTTP. D'où une première question:
- il existe une sorte de "répartition" naturelle dans les services DNS (le
tourniquet "japonais" Round Robin). Est-ce un complément de NLB ou peut-on
réellement réaliser du NLB avec. Je crois que cela fonctionne sur le principe
de la résolution de noms d'hôtes DNS et de polling...
Si je mets en place NLB, je n'ai pas de matériel supplémentaire à rajouter
(chaque serveur possède une interface réseau). Le site Web de cette
application est localisé sur le 1er serveur, dois-je aussi l'installer sur le
2ème serveur ou bien faire pointer le second serveur IIS 6.0 sur le premier ?
Autre question: le NLB est "une sorte de cluster", dans le sens groupe de
noeuds. Le client (IE) va donc normalement envoyer sa requête vers la machine
"virtuelle" du cluster NLB. Le site Web de l'application doit-il être
installé sur ce serveur virtuel ?
Dans la documentation MS sur le Net (MSDN), il est indiqué que de nombreux
flux multicast sont employés pour gérer le NLB. Quels sont les précautions à
prendre pour la gestion des flux multicast ?
NB: j'ai imprimer toutes les docs que j'ai pu trouver sur MSDN et je remerce
les personnes qui m'ont envoyés des liens, et je précise que je n'ai pas les
moyens matériels pour mettre une maquette NLB en place, donc, si je pouvais
avoir des réponses précises (elles le sont toujours de votre part), ce serait
bien.
Merci d'avance pour votre aide.
Cordialement,
Houdini.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stéphane [MS]
Bonjour,
Pour que le NLB fonctionne, il faut impérativement que vos 2 serveurs membres de la ferme soit parfaitement identiques du point de vus des sites Web. Le NLB ne fonctionnant qu'au niveau IP, la synchronisation des données et réglages entre vos 2 serveurs reste à votre charge (à moins de regarder du coté d'Application Center, mais c'est une autre histoire).
Le Round Robin DNS est à la fois, complémentaire et concurrent du NLB. Il peut permettre de distribuer de manière identique des demandes de clients vers plusieurs serveurs. A la différence du NLB, il ne détecte pas d'indisponibilité des serveurs et peut conduire à diriger un client sur un serveur qui est en maintenance. C'est la raison pour laquelle un site comme www.microsoft.com l'utilise conjointement avec du NLB (plusieures adresses sont renvoyées aux clients qui correspondent chacune à une adresse virtuelle d'une ferme NLB, mais je doute que vous ayiez besoin d'une telle montée en charge).
Le NLB ne nécessite pas de matériel supplémentaire. C'est son point fort.
Le NLB assure la rédirection d'une requête client d'une adresse virtuelle vers l'adresse dédiée d'un serveur. Votre site Web doit continuer à être lié à cette adresse dédiée.
Les précautions sur le multicast sont d'avantages pour protéger d'autres serveurs qui seraient sur le même segment de réseau que vos serveurs en NLB. Idéalement, vous pouvez allouer un VLAN à ces serveurs.
Autre précaution à prendre, il faut être sûr que votre applications stocke l'état des sessions à un autre endroit qu'en mémoire du serveur Web. Les clients ne sont pas nécessairement renvoyés systématiquement sur le même serveur entre 2 pages vues.
-- Cdlt Stéphane
Bonjour à toutes et à tous,
Voici le contexte: - 1 serveur W2K3 Edt. Std SP1 avec IIS 6.0, qui accueille le site Web d'une application, un serveur d'application Apache Tomcat. La base de données Oracle est rattachée sur un serveur Unix via Odbc/Jndi (application).
- 1 second serveur W2K3 Edt. std SP1 avec IIS 6.0. Les deux serveurs sont membre d'une AD 2000.
L'application métier en question (développée en JAVA / .NET) consomme énormément de ressources et le nombre de connexions simultanées peut atteindre 400 (en moyenne 350). Les serveurs sont des HP Lame Xeon 3,6 Ghz avec 3 Go Ram en Raid1.
Pour des raisons de performances, je souhaiterai mettre en place le NLB (équilibrage de charge) maintenant en standard dans toutes les versions serveurs 2003. Les requêtes clientes entrantes seraient donc réparties vers les 2 serveurs HTTP. D'où une première question:
- il existe une sorte de "répartition" naturelle dans les services DNS (le tourniquet "japonais" Round Robin). Est-ce un complément de NLB ou peut-on réellement réaliser du NLB avec. Je crois que cela fonctionne sur le principe de la résolution de noms d'hôtes DNS et de polling...
Si je mets en place NLB, je n'ai pas de matériel supplémentaire à rajouter (chaque serveur possède une interface réseau). Le site Web de cette application est localisé sur le 1er serveur, dois-je aussi l'installer sur le 2ème serveur ou bien faire pointer le second serveur IIS 6.0 sur le premier ?
Autre question: le NLB est "une sorte de cluster", dans le sens groupe de noeuds. Le client (IE) va donc normalement envoyer sa requête vers la machine "virtuelle" du cluster NLB. Le site Web de l'application doit-il être installé sur ce serveur virtuel ?
Dans la documentation MS sur le Net (MSDN), il est indiqué que de nombreux flux multicast sont employés pour gérer le NLB. Quels sont les précautions à prendre pour la gestion des flux multicast ?
NB: j'ai imprimer toutes les docs que j'ai pu trouver sur MSDN et je remerce les personnes qui m'ont envoyés des liens, et je précise que je n'ai pas les moyens matériels pour mettre une maquette NLB en place, donc, si je pouvais avoir des réponses précises (elles le sont toujours de votre part), ce serait bien.
Merci d'avance pour votre aide. Cordialement, Houdini.
Bonjour,
Pour que le NLB fonctionne, il faut impérativement que vos 2 serveurs
membres de la ferme soit parfaitement identiques du point de vus des sites
Web. Le NLB ne fonctionnant qu'au niveau IP, la synchronisation des données
et réglages entre vos 2 serveurs reste à votre charge (à moins de regarder du
coté d'Application Center, mais c'est une autre histoire).
Le Round Robin DNS est à la fois, complémentaire et concurrent du NLB. Il
peut permettre de distribuer de manière identique des demandes de clients
vers plusieurs serveurs. A la différence du NLB, il ne détecte pas
d'indisponibilité des serveurs et peut conduire à diriger un client sur un
serveur qui est en maintenance. C'est la raison pour laquelle un site comme
www.microsoft.com l'utilise conjointement avec du NLB (plusieures adresses
sont renvoyées aux clients qui correspondent chacune à une adresse virtuelle
d'une ferme NLB, mais je doute que vous ayiez besoin d'une telle montée en
charge).
Le NLB ne nécessite pas de matériel supplémentaire. C'est son point fort.
Le NLB assure la rédirection d'une requête client d'une adresse virtuelle
vers l'adresse dédiée d'un serveur. Votre site Web doit continuer à être lié
à cette adresse dédiée.
Les précautions sur le multicast sont d'avantages pour protéger d'autres
serveurs qui seraient sur le même segment de réseau que vos serveurs en NLB.
Idéalement, vous pouvez allouer un VLAN à ces serveurs.
Autre précaution à prendre, il faut être sûr que votre applications stocke
l'état des sessions à un autre endroit qu'en mémoire du serveur Web. Les
clients ne sont pas nécessairement renvoyés systématiquement sur le même
serveur entre 2 pages vues.
--
Cdlt
Stéphane
Bonjour à toutes et à tous,
Voici le contexte:
- 1 serveur W2K3 Edt. Std SP1 avec IIS 6.0, qui accueille le site Web d'une
application, un serveur d'application Apache Tomcat. La base de données
Oracle est rattachée sur un serveur Unix via Odbc/Jndi (application).
- 1 second serveur W2K3 Edt. std SP1 avec IIS 6.0.
Les deux serveurs sont membre d'une AD 2000.
L'application métier en question (développée en JAVA / .NET) consomme
énormément de ressources et le nombre de connexions simultanées peut
atteindre 400 (en moyenne 350). Les serveurs sont des HP Lame Xeon 3,6 Ghz
avec 3 Go Ram en Raid1.
Pour des raisons de performances, je souhaiterai mettre en place le NLB
(équilibrage de charge) maintenant en standard dans toutes les versions
serveurs 2003. Les requêtes clientes entrantes seraient donc réparties vers
les 2 serveurs HTTP. D'où une première question:
- il existe une sorte de "répartition" naturelle dans les services DNS (le
tourniquet "japonais" Round Robin). Est-ce un complément de NLB ou peut-on
réellement réaliser du NLB avec. Je crois que cela fonctionne sur le principe
de la résolution de noms d'hôtes DNS et de polling...
Si je mets en place NLB, je n'ai pas de matériel supplémentaire à rajouter
(chaque serveur possède une interface réseau). Le site Web de cette
application est localisé sur le 1er serveur, dois-je aussi l'installer sur le
2ème serveur ou bien faire pointer le second serveur IIS 6.0 sur le premier ?
Autre question: le NLB est "une sorte de cluster", dans le sens groupe de
noeuds. Le client (IE) va donc normalement envoyer sa requête vers la machine
"virtuelle" du cluster NLB. Le site Web de l'application doit-il être
installé sur ce serveur virtuel ?
Dans la documentation MS sur le Net (MSDN), il est indiqué que de nombreux
flux multicast sont employés pour gérer le NLB. Quels sont les précautions à
prendre pour la gestion des flux multicast ?
NB: j'ai imprimer toutes les docs que j'ai pu trouver sur MSDN et je remerce
les personnes qui m'ont envoyés des liens, et je précise que je n'ai pas les
moyens matériels pour mettre une maquette NLB en place, donc, si je pouvais
avoir des réponses précises (elles le sont toujours de votre part), ce serait
bien.
Merci d'avance pour votre aide.
Cordialement,
Houdini.
Pour que le NLB fonctionne, il faut impérativement que vos 2 serveurs membres de la ferme soit parfaitement identiques du point de vus des sites Web. Le NLB ne fonctionnant qu'au niveau IP, la synchronisation des données et réglages entre vos 2 serveurs reste à votre charge (à moins de regarder du coté d'Application Center, mais c'est une autre histoire).
Le Round Robin DNS est à la fois, complémentaire et concurrent du NLB. Il peut permettre de distribuer de manière identique des demandes de clients vers plusieurs serveurs. A la différence du NLB, il ne détecte pas d'indisponibilité des serveurs et peut conduire à diriger un client sur un serveur qui est en maintenance. C'est la raison pour laquelle un site comme www.microsoft.com l'utilise conjointement avec du NLB (plusieures adresses sont renvoyées aux clients qui correspondent chacune à une adresse virtuelle d'une ferme NLB, mais je doute que vous ayiez besoin d'une telle montée en charge).
Le NLB ne nécessite pas de matériel supplémentaire. C'est son point fort.
Le NLB assure la rédirection d'une requête client d'une adresse virtuelle vers l'adresse dédiée d'un serveur. Votre site Web doit continuer à être lié à cette adresse dédiée.
Les précautions sur le multicast sont d'avantages pour protéger d'autres serveurs qui seraient sur le même segment de réseau que vos serveurs en NLB. Idéalement, vous pouvez allouer un VLAN à ces serveurs.
Autre précaution à prendre, il faut être sûr que votre applications stocke l'état des sessions à un autre endroit qu'en mémoire du serveur Web. Les clients ne sont pas nécessairement renvoyés systématiquement sur le même serveur entre 2 pages vues.
-- Cdlt Stéphane
Bonjour à toutes et à tous,
Voici le contexte: - 1 serveur W2K3 Edt. Std SP1 avec IIS 6.0, qui accueille le site Web d'une application, un serveur d'application Apache Tomcat. La base de données Oracle est rattachée sur un serveur Unix via Odbc/Jndi (application).
- 1 second serveur W2K3 Edt. std SP1 avec IIS 6.0. Les deux serveurs sont membre d'une AD 2000.
L'application métier en question (développée en JAVA / .NET) consomme énormément de ressources et le nombre de connexions simultanées peut atteindre 400 (en moyenne 350). Les serveurs sont des HP Lame Xeon 3,6 Ghz avec 3 Go Ram en Raid1.
Pour des raisons de performances, je souhaiterai mettre en place le NLB (équilibrage de charge) maintenant en standard dans toutes les versions serveurs 2003. Les requêtes clientes entrantes seraient donc réparties vers les 2 serveurs HTTP. D'où une première question:
- il existe une sorte de "répartition" naturelle dans les services DNS (le tourniquet "japonais" Round Robin). Est-ce un complément de NLB ou peut-on réellement réaliser du NLB avec. Je crois que cela fonctionne sur le principe de la résolution de noms d'hôtes DNS et de polling...
Si je mets en place NLB, je n'ai pas de matériel supplémentaire à rajouter (chaque serveur possède une interface réseau). Le site Web de cette application est localisé sur le 1er serveur, dois-je aussi l'installer sur le 2ème serveur ou bien faire pointer le second serveur IIS 6.0 sur le premier ?
Autre question: le NLB est "une sorte de cluster", dans le sens groupe de noeuds. Le client (IE) va donc normalement envoyer sa requête vers la machine "virtuelle" du cluster NLB. Le site Web de l'application doit-il être installé sur ce serveur virtuel ?
Dans la documentation MS sur le Net (MSDN), il est indiqué que de nombreux flux multicast sont employés pour gérer le NLB. Quels sont les précautions à prendre pour la gestion des flux multicast ?
NB: j'ai imprimer toutes les docs que j'ai pu trouver sur MSDN et je remerce les personnes qui m'ont envoyés des liens, et je précise que je n'ai pas les moyens matériels pour mettre une maquette NLB en place, donc, si je pouvais avoir des réponses précises (elles le sont toujours de votre part), ce serait bien.
Merci d'avance pour votre aide. Cordialement, Houdini.
