Vous l’avez peut être déjà constaté, si vous avez installé la version 11.2.0.4 de grid infrastructure sous Linux, lorsque vous avez tenté de basculer une adresse scan-vip vers un autre serveur ou si une des adresses a basculée suite à l’arrêt du serveur, que cette adresse scan-vip peut rester inaccessible un certain temps par les postes client. Cela s’explique par un bug apparu avec la version 11.2.0.4 de grid infrastructure.
Cela arrive lorsque vous êtes dans la configuration suivante:
Les adresses IP de votre scan sont dans un VLAN et vos clients sont dans un VLAN différent. Dans cette configuration, lorsque l’adresse scan-vip bascule, la table de routage du VLAN n’est pas mise à jour automatiquement. Il faut dont attendre que l’équipement réseau fasse sa mise à jour pour pouvoir de nouveau accéder à l’adresse du scan qui a basculé, et cela peut prendre un certain temps. Les autres adresses restent disponibles.
Pour corriger le problème sans attendre, on utilise la commande arping
/sbin/arping -U -c2 -I eth0 adresse.a.re.enregistrée
Pour savoir si vous êtes dans ce cas de figure, vous pouvez vous livrer à cette petite expérience.
Dans un premier temps, repérez une adresse scan-vip à déplacer
En tant que user root et après avoir positionner l’environnement grid infra, lancez la commande suivante:
srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node serveur1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node serveur2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node serveur3
Déplacez l’adresse vip scan1 vers serveur3
srvctl relocate scan -i 3 -n serveur3
vérifiez que l’adresse a bien été déplacée
srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node serveur3 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node serveur2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node serveur3
Le déplacement ayant bien été effectué, testez la visibilité de l’adresse en dehors du VLAN avec la commande ping
ping nomcluster-scan
Si vous êtes dans la configuration du bug, une des adresses sur les trois ne répondra pas au ping.
Pour corriger cela, sur le serveur hébergeant l’adresse scan-vip déplacée, dans notre cas le serveur3, lancez en tant que root les commandes suivantes :
ifconfig
bond0 Link encap:Ethernet HWaddr 00:21:5A:9B:02:9C
inet adr:xxx.yyy.zzz.22 Bcast:xxx.yyy.zzz.255 Masque:255.255.255.0
adr inet6: fe80::221:5aff:fe9b:29c/64 Scope:Lien
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:5771136023 errors:0 dropped:0 overruns:0 frame:0
TX packets:1029427608 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:8182298008107 (7.4 TiB) TX bytes:619931360845 (577.3 GiB)
bond0:1 Link encap:Ethernet HWaddr 00:21:5A:9B:02:9C
inet adr: xxx.yyy.zzz.scan3 Bcast:xxx.yyy.zzz.255 Masque:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
bond0:2 Link encap:Ethernet HWaddr 00:21:5A:9B:02:9C
inet adr: xxx.yyy.zzz.scan1 Bcast:xxx.yyy.zzz.255 Masque:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
Puis
/sbin/arping -U -c2 -I eth0 xxx.yyy.zzz.scan1
Les 3 adresses scan sont maintenant accessibles en dehors du VLAN
