> Tech > Boîte à  outils System iNews : Période de rétention i5/OS /Problème de débit transactionnel i5 / Windows 2003 Server

Boîte à  outils System iNews : Période de rétention i5/OS /Problème de débit transactionnel i5 / Windows 2003 Server

Tech - Par Mel Beckman - Publié le 24 juin 2010
email

Période de rétention i5/OS
Problème de débit transactionnel i5 / Windows 2003 Server

Boîte à  outils System iNews : Période de rétention i5/OS /Problème de débit transactionnel i5 / Windows 2003 Server

Nous utilisons sur notre LAN un ensemble de serveurs Unix Web, en secours. Ces serveurs ne viennent en ligne que quand nos serveurs principaux sont arrêtés pour la maintenance. Nous faisons cela tout simplement en déconnectant les serveurs principaux du réseau et en connectant les serveurs de secours, qui ont les mêmes adresses IP que les principaux. Les utilisateurs n’ont pas de mal à atteindre les serveurs de secours, mais nos serveurs i5 se plaignent toujours de ne plus pouvoir voir les serveurs. Le problème disparaît après 10 ou 15 minutes, mais ressurgit quand nous ramenons les serveurs principaux en ligne. Comment corriger cela ?

Vous êtes victime d’un déplaisant phénomène i5/OS connu sous le nom de Stick ARP Syndrome. Vous le savez, chaque unité participant à votre LAN a une adresse matérielle, dite adresse MAC, qui est associée à son adresse IP via l’ARP (Address Resolution Protocol). Dès lors qu’un hôte de réseau, comme votre iSeries, établit cette association pour un IP particulier, il met la réponse en cache afin que le processus ARP n’ait pas à être répété pour chaque paquet transmis à l’unité cible.

C’est dans la durée d’existence de ce cache que réside la difficulté. Sous i5/OS, la période de rétention par défaut est de 15 minutes, mais elle peut être plus brève si la machine i5 « remarque » du trafic provenant d’une nouvelle adresse MAC pour l’IP cible. Généralement, cela se produit quand la machine cible noue le contact avec l’iSeries. Dans votre cas, votre serveur n’a pas à établir le contact avec l’iSeries, aussi vous devez attendre le timeout du cache.

Une première solution consiste à ordonner au serveur d’interroger périodiquement la machine iSeries avec un trafic inerte, comme un ping. Un ping toutes les cinq secondes devrait faire l’affaire, sans alourdir sensiblement le trafic du réseau. Si vous ne pouvez pas faire cela, une autre solution consiste à effacer le cache ARP i5 aussitôt après avoir changé de serveur sur le LAN. L’i5/OS n’a aucune commande intégrée pour accomplir cela, mais vous pouvez facilement en créer une avec le programme CL suivant :

pgm parm(&cline)
dcl &cline *char 10
callprc
prc(‘qtocrmvarptble’) +
parm(&cline 0 ‘*ALL ‘ X’00000000’)
end: endpgm

Pour créer un programme CL lié à partir de cette source, exécutez la commande suivante :

CRTBNDCL
PGM(<library>/CLRARP) +
SRCFILE(<library>/QCLSRC) +
SRCMBR(CLRARP)

Vous pouvez maintenant effacer le cache ARP i5/OS à tout moment par CALL CLRARP ou, si vous le souhaitez créer un objet de commande pour l’invoquer. L’effacement du cache ARP n’affecte aucune application, mais il ne faut pas le pratiquer de manière continue sous peine de générer beaucoup de trafic ARP inutile.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par Mel Beckman - Publié le 24 juin 2010