Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement corriger)
un comportement bizarre dans le cadre de l'utilisation de l'équilibrage de
charge/tolérance de panne NLB sur des serveurs 2003 Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est connectée
à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre elles
via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes sites
sous IIS sont bien accessibles sur Srv2 via l'IP du cluster 10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé sur
toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement corriger)
un comportement bizarre dans le cadre de l'utilisation de l'équilibrage de
charge/tolérance de panne NLB sur des serveurs 2003 Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est connectée
à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre elles
via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes sites
sous IIS sont bien accessibles sur Srv2 via l'IP du cluster 10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé sur
toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement corriger)
un comportement bizarre dans le cadre de l'utilisation de l'équilibrage de
charge/tolérance de panne NLB sur des serveurs 2003 Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est connectée
à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre elles
via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes sites
sous IIS sont bien accessibles sur Srv2 via l'IP du cluster 10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé sur
toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonsoir,
Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
construisant ses tables de routage de manière dynamique. Le système a donc
très certainement estimé que les carte configurée pour le réseau public
était la passerelle optimale. Pour contrer le comportement vous pouvez
implémenter des routes statiques.
Je me pose toutefois une question sur l'utilité du réseau privé relié par
câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
également un cluster de type MSCS, pour un serveur de base de données par
ex?
Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
il est préférable de réaffecter en transport pour les communications
"back-end' (AD, base de donnée etc...) et mettre en place les routes
statiques.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
news:Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement
corriger) un comportement bizarre dans le cadre de l'utilisation de
l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
connectée à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
elles via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé
sur toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonsoir,
Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
construisant ses tables de routage de manière dynamique. Le système a donc
très certainement estimé que les carte configurée pour le réseau public
était la passerelle optimale. Pour contrer le comportement vous pouvez
implémenter des routes statiques.
Je me pose toutefois une question sur l'utilité du réseau privé relié par
câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
également un cluster de type MSCS, pour un serveur de base de données par
ex?
Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
il est préférable de réaffecter en transport pour les communications
"back-end' (AD, base de donnée etc...) et mettre en place les routes
statiques.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
news:eB4jjkHiJHA.4372@TK2MSFTNGP02.phx.gbl...
Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement
corriger) un comportement bizarre dans le cadre de l'utilisation de
l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
connectée à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
elles via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé
sur toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonsoir,
Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
construisant ses tables de routage de manière dynamique. Le système a donc
très certainement estimé que les carte configurée pour le réseau public
était la passerelle optimale. Pour contrer le comportement vous pouvez
implémenter des routes statiques.
Je me pose toutefois une question sur l'utilité du réseau privé relié par
câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
également un cluster de type MSCS, pour un serveur de base de données par
ex?
Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
il est préférable de réaffecter en transport pour les communications
"back-end' (AD, base de donnée etc...) et mettre en place les routes
statiques.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
news:Bonjour à tous.
J'ai besoin d'un coup de main pour comprendre (et éventuellement
corriger) un comportement bizarre dans le cadre de l'utilisation de
l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
Standard.
J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
réseau comme préconisé sur la TechNet Microsoft :
Srv1 :
- Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
publique : 10.32.0.12/24
- Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
10.0.0.1/29
Srv2 :
- Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
publique : 10.32.0.13/24
- Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
10.0.0.2/29
J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
connectée à notre réseau via un switch.
Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
elles via un câble croisé.
Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
signaux de gestion par 10.0.0.3.
Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
10.32.0.20.
Le problème réside dans le routeur qui dessert notre société. Il est
configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
mon cluster privé. Et c'est mal...
D'où ma question : Comment se fait-il que des cartes réseau avec IP
privées et sous un sous réseau logique différent du plan d'IP général
puissent tout de même transiter sur un autre sous réseau ?
J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
cartes d'une même machine. De plus, le protocole NetBios est désactivé
sur toutes les cartes réseau.
Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
ce problème ?
Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
m'aider sur ce problème.
--
Cordialement,
Eric
Bonsoir Marc et merci pour la réponse.
Pour mettre en place ce NLB, je me suis basé sur la documentation en la
matière
donnée dans la TechNet de Microsoft :
http://technet.microsoft.com/fr-fr/library/bb742455.aspx
Il y est précisé qu'il est recommandé d'utiliser 2 cartes réseau par
serveur. Une pour
gérer les flux de données et l'autre pour la gestion de charge. Ceci afin
d'améliorer les performances.
Maintenant, j'avoue avoir eu besoin de relire plusieurs fois cette doc avant
de la comprendre :-/
La traduction approximative ? Il est possible que je me sois fourvoyé.
L'idée d'implémenter des routes statiques est intéressante mais si vous me
dites que la
configuration que j'ai adoptée n'est pas optimale / nécessaire, je ferai
peut-être mieux de
revenir à une configuration NLB sur une seule carte réseau par serveur.
Je n'utilise pas de cluster MSCS pour mes serveurs Web. En fait, j'utilise
IIS pour
supporter PHP et MySql. Les bases de données MySql se répliquent
automatiquement
entre elle sur un schémas Master-Master par le "canal" principal (IPs
publiques).
Je pourrai effectivement affecter les 2eme cartes réseau aux communications
back-end.
Merci pour la suggestion ;-)
--
Cordialement,
Eric
"Lognoul Marc [MVP]" a écrit dans le message de
groupe de discussion : #
> Bonsoir,
>
> Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
> construisant ses tables de routage de manière dynamique. Le système a donc
> très certainement estimé que les carte configurée pour le réseau public
> était la passerelle optimale. Pour contrer le comportement vous pouvez
> implémenter des routes statiques.
>
> Je me pose toutefois une question sur l'utilité du réseau privé relié par
> câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
> également un cluster de type MSCS, pour un serveur de base de données par
> ex?
> Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
> il est préférable de réaffecter en transport pour les communications
> "back-end' (AD, base de donnée etc...) et mettre en place les routes
> statiques.
>
> --
> Marc [MCSE, MCTS, MVP]
> [Heureux celui qui a pu pénétrer les causes secrètes des choses]
> [Blog: http://www.marc-antho-etc.net/blog/]
>
>
> "Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
> news:
>> Bonjour à tous.
>>
>> J'ai besoin d'un coup de main pour comprendre (et éventuellement
>> corriger) un comportement bizarre dans le cadre de l'utilisation de
>> l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
>> Standard.
>>
>> J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
>> tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
>> réseau comme préconisé sur la TechNet Microsoft :
>> Srv1 :
>> - Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.12/24
>> - Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.1/29
>> Srv2 :
>> - Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.13/24
>> - Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.2/29
>>
>> J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
>> sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
>> Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
>> connectée à notre réseau via un switch.
>> Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
>> adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
>> prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
>> elles via un câble croisé.
>> Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
>> signaux de gestion par 10.0.0.3.
>>
>> Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
>> sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
>> 10.32.0.20.
>>
>> Le problème réside dans le routeur qui dessert notre société. Il est
>> configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
>> des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
>> C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
>> mon cluster privé. Et c'est mal...
>>
>> D'où ma question : Comment se fait-il que des cartes réseau avec IP
>> privées et sous un sous réseau logique différent du plan d'IP général
>> puissent tout de même transiter sur un autre sous réseau ?
>>
>> J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
>> cartes d'une même machine. De plus, le protocole NetBios est désactivé
>> sur toutes les cartes réseau.
>>
>> Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
>> ce problème ?
>>
>> Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
>> m'aider sur ce problème.
>>
>> --
>> Cordialement,
>>
>> Eric
>
Bonsoir Marc et merci pour la réponse.
Pour mettre en place ce NLB, je me suis basé sur la documentation en la
matière
donnée dans la TechNet de Microsoft :
http://technet.microsoft.com/fr-fr/library/bb742455.aspx
Il y est précisé qu'il est recommandé d'utiliser 2 cartes réseau par
serveur. Une pour
gérer les flux de données et l'autre pour la gestion de charge. Ceci afin
d'améliorer les performances.
Maintenant, j'avoue avoir eu besoin de relire plusieurs fois cette doc avant
de la comprendre :-/
La traduction approximative ? Il est possible que je me sois fourvoyé.
L'idée d'implémenter des routes statiques est intéressante mais si vous me
dites que la
configuration que j'ai adoptée n'est pas optimale / nécessaire, je ferai
peut-être mieux de
revenir à une configuration NLB sur une seule carte réseau par serveur.
Je n'utilise pas de cluster MSCS pour mes serveurs Web. En fait, j'utilise
IIS pour
supporter PHP et MySql. Les bases de données MySql se répliquent
automatiquement
entre elle sur un schémas Master-Master par le "canal" principal (IPs
publiques).
Je pourrai effectivement affecter les 2eme cartes réseau aux communications
back-end.
Merci pour la suggestion ;-)
--
Cordialement,
Eric
"Lognoul Marc [MVP]" <lognoulm@hotmail.com> a écrit dans le message de
groupe de discussion : #6tnHYIiJHA.2516@TK2MSFTNGP05.phx.gbl...
> Bonsoir,
>
> Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
> construisant ses tables de routage de manière dynamique. Le système a donc
> très certainement estimé que les carte configurée pour le réseau public
> était la passerelle optimale. Pour contrer le comportement vous pouvez
> implémenter des routes statiques.
>
> Je me pose toutefois une question sur l'utilité du réseau privé relié par
> câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
> également un cluster de type MSCS, pour un serveur de base de données par
> ex?
> Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
> il est préférable de réaffecter en transport pour les communications
> "back-end' (AD, base de donnée etc...) et mettre en place les routes
> statiques.
>
> --
> Marc [MCSE, MCTS, MVP]
> [Heureux celui qui a pu pénétrer les causes secrètes des choses]
> [Blog: http://www.marc-antho-etc.net/blog/]
>
>
> "Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
> news:eB4jjkHiJHA.4372@TK2MSFTNGP02.phx.gbl...
>> Bonjour à tous.
>>
>> J'ai besoin d'un coup de main pour comprendre (et éventuellement
>> corriger) un comportement bizarre dans le cadre de l'utilisation de
>> l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
>> Standard.
>>
>> J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
>> tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
>> réseau comme préconisé sur la TechNet Microsoft :
>> Srv1 :
>> - Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.12/24
>> - Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.1/29
>> Srv2 :
>> - Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.13/24
>> - Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.2/29
>>
>> J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
>> sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
>> Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
>> connectée à notre réseau via un switch.
>> Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
>> adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
>> prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
>> elles via un câble croisé.
>> Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
>> signaux de gestion par 10.0.0.3.
>>
>> Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
>> sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
>> 10.32.0.20.
>>
>> Le problème réside dans le routeur qui dessert notre société. Il est
>> configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
>> des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
>> C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
>> mon cluster privé. Et c'est mal...
>>
>> D'où ma question : Comment se fait-il que des cartes réseau avec IP
>> privées et sous un sous réseau logique différent du plan d'IP général
>> puissent tout de même transiter sur un autre sous réseau ?
>>
>> J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
>> cartes d'une même machine. De plus, le protocole NetBios est désactivé
>> sur toutes les cartes réseau.
>>
>> Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
>> ce problème ?
>>
>> Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
>> m'aider sur ce problème.
>>
>> --
>> Cordialement,
>>
>> Eric
>
Bonsoir Marc et merci pour la réponse.
Pour mettre en place ce NLB, je me suis basé sur la documentation en la
matière
donnée dans la TechNet de Microsoft :
http://technet.microsoft.com/fr-fr/library/bb742455.aspx
Il y est précisé qu'il est recommandé d'utiliser 2 cartes réseau par
serveur. Une pour
gérer les flux de données et l'autre pour la gestion de charge. Ceci afin
d'améliorer les performances.
Maintenant, j'avoue avoir eu besoin de relire plusieurs fois cette doc avant
de la comprendre :-/
La traduction approximative ? Il est possible que je me sois fourvoyé.
L'idée d'implémenter des routes statiques est intéressante mais si vous me
dites que la
configuration que j'ai adoptée n'est pas optimale / nécessaire, je ferai
peut-être mieux de
revenir à une configuration NLB sur une seule carte réseau par serveur.
Je n'utilise pas de cluster MSCS pour mes serveurs Web. En fait, j'utilise
IIS pour
supporter PHP et MySql. Les bases de données MySql se répliquent
automatiquement
entre elle sur un schémas Master-Master par le "canal" principal (IPs
publiques).
Je pourrai effectivement affecter les 2eme cartes réseau aux communications
back-end.
Merci pour la suggestion ;-)
--
Cordialement,
Eric
"Lognoul Marc [MVP]" a écrit dans le message de
groupe de discussion : #
> Bonsoir,
>
> Le phénomène que vous décrivez n'est pas anormal étant donné que Windows
> construisant ses tables de routage de manière dynamique. Le système a donc
> très certainement estimé que les carte configurée pour le réseau public
> était la passerelle optimale. Pour contrer le comportement vous pouvez
> implémenter des routes statiques.
>
> Je me pose toutefois une question sur l'utilité du réseau privé relié par
> câble croisé. Quelle en est l'utilité sur un cluster NLB? tournez-vous
> également un cluster de type MSCS, pour un serveur de base de données par
> ex?
> Si vous opérer uniquement un cluster NLB, ce réseau privé est inutile et
> il est préférable de réaffecter en transport pour les communications
> "back-end' (AD, base de donnée etc...) et mettre en place les routes
> statiques.
>
> --
> Marc [MCSE, MCTS, MVP]
> [Heureux celui qui a pu pénétrer les causes secrètes des choses]
> [Blog: http://www.marc-antho-etc.net/blog/]
>
>
> "Eric26" <lucifer[point]nospam[at]infernoweb[point]net> wrote in message
> news:
>> Bonjour à tous.
>>
>> J'ai besoin d'un coup de main pour comprendre (et éventuellement
>> corriger) un comportement bizarre dans le cadre de l'utilisation de
>> l'équilibrage de charge/tolérance de panne NLB sur des serveurs 2003
>> Standard.
>>
>> J'ai 2 serveur Web 2003 identiques et je souhaite mettre en place la
>> tolérance de panne entre eux. Chaque machine est équipée de 2 cartes
>> réseau comme préconisé sur la TechNet Microsoft :
>> Srv1 :
>> - Carte réseau 1 (CR1a) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.12/24
>> - Carte réseau 2 (CR2a) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.1/29
>> Srv2 :
>> - Carte réseau 1 (CR1b) = Carte de flux de données publique -> Adresse
>> publique : 10.32.0.13/24
>> - Carte réseau 2 (CR2b) = Carte de gestion privée -> Adresse privée :
>> 10.0.0.2/29
>>
>> J'ai ensuite configuré un cluster NLB entre les deux cartes CR1a et CR1b
>> sous une adresse virtuelle 10.32.0.20/24 en multidiffusion. J'ai défini
>> Srv1 comme prioritaire par rapport à Srv2. Chaque carte CR1x est
>> connectée à notre réseau via un switch.
>> Puis un deuxième cluster NLB entre les deux cartes CR2a et CR2b sous une
>> adresse virtuelle 10.0.0.3/29 en monodiffusion. Là aussi, Srv1 est
>> prioritaire sur Srv2. Les cartes CR2x sont reliées directement entre
>> elles via un câble croisé.
>> Ainsi, j'ai les données qui transitent par 10.32.0.20 et les heatbeat et
>> signaux de gestion par 10.0.0.3.
>>
>> Jusque là, tout va bien. Lors de mes tests, sur coupure de Srv1, mes
>> sites sous IIS sont bien accessibles sur Srv2 via l'IP du cluster
>> 10.32.0.20.
>>
>> Le problème réside dans le routeur qui dessert notre société. Il est
>> configuré pour un plan d'adressage IP précis 10.32.0.0/24 et nous remonte
>> des logs lorsque des machines ne respectent pas ce plan sur notre réseau.
>> C'est précisément ce qu'il se passe pour les IP 10.0.0.1 et 10.0.0.2 de
>> mon cluster privé. Et c'est mal...
>>
>> D'où ma question : Comment se fait-il que des cartes réseau avec IP
>> privées et sous un sous réseau logique différent du plan d'IP général
>> puissent tout de même transiter sur un autre sous réseau ?
>>
>> J'ai vérifié qu'il n'y a pas de logiciel pouvant créer un pont entre les
>> cartes d'une même machine. De plus, le protocole NetBios est désactivé
>> sur toutes les cartes réseau.
>>
>> Est-ce que le pilote de l'équilibrage de charge pourrait être la cause de
>> ce problème ?
>>
>> Merci d'avance à ceux qui voudront bien prendre un peu de temps pour
>> m'aider sur ce problème.
>>
>> --
>> Cordialement,
>>
>> Eric
>
bonjour,
votre réseau public et privé ne doivent pas être dans la même classe
d'adresses IP, d'ou votre problème.
Faite votre réseau public en 10.x.x.x et votre réseau privé en 192.168 par
ex.
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
bonjour,
votre réseau public et privé ne doivent pas être dans la même classe
d'adresses IP, d'ou votre problème.
Faite votre réseau public en 10.x.x.x et votre réseau privé en 192.168 par
ex.
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
bonjour,
votre réseau public et privé ne doivent pas être dans la même classe
d'adresses IP, d'ou votre problème.
Faite votre réseau public en 10.x.x.x et votre réseau privé en 192.168 par
ex.
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
> Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
> Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
> Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
En effet. Je pense, sans être certain à 100%, que ce comportment a été
modifié à partir de Vista/2008 suite à l'introduction du Windows Filtering
Platform qui permet d'interagir plus finement au niveau des communications
entre cartes réseau.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
En effet. Je pense, sans être certain à 100%, que ce comportment a été
modifié à partir de Vista/2008 suite à l'introduction du Windows Filtering
Platform qui permet d'interagir plus finement au niveau des communications
entre cartes réseau.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
Il semble que lorsqu'on ajoute des cartes réseau sur un système existant,
elles utilisent la même table de routage
En effet. Je pense, sans être certain à 100%, que ce comportment a été
modifié à partir de Vista/2008 suite à l'introduction du Windows Filtering
Platform qui permet d'interagir plus finement au niveau des communications
entre cartes réseau.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]