Messieurs,

Je soupçonne un de mes serveurs de perdre momentanément l'accès à un partage qui se situe sur un file serveur.
Je pourrais demander à l'équipe réseau ici d'y regarder mais leur mauvaise foi est telle que je préfère y regarder de mon coté.

En gros, un de mes 6 serveurs Kofax génère pas mal d'erreur, hors quand on est dessus, il semblerait qu'on perde l'accès à ses fichiers de config que l'on joint via \\mrbc\kofax (file serveur)

Qu'est-ce que je pourrais facilement mettre en place pour monitorer ceci et savoir si il y a bien des pertes de connexion (même momentanées) ?

Merci.

Y a pas des logs sous Windows qui te permettent de voir tout ça ?

En solution "brute", je dirai : fais un script qui écrit chaque x secondes dans un fichier distant, et qui y inscrit l'heure courante. S'il manque une entrée, tu auras l'heure du souci (et si rien ne manque, soit c'est que ça marche, soit c'est que la panne a été plus courte que l'intervalle de temps que tu as choisi).

Identifier que le problème existe ne te permettra pas directement de rejeter la faute sur quelqu'un En outil de monitoring sympa, y a Wireshark. Ca intercepte tout (ou presque) de ce qui se passe au niveau réseau. Si tu configures quelques filtres, tu devrais assez facilement pouvoir isoler tout ce qui concerne le protocole de partage (samba, je suppose ?).

Merci, je vais en effet voir pour le script c'est plutot facile.
Ce qui me gène dans cet histoire, c'est que on a l'impression qu'il n'y a des soucis qu'avec 1 des 6 serveurs. Donc le problème ne viendrait pas de la source mais du serveur lui-même.

Y a t'il une raison pour que les fichiers de configs ne soient pas locaux mais sur un partage réseau ? Est-ce que ceux-ci changent suffisamment souvent dans une même journée pour nécessiter une telle solution plutôt que des copies locales et des écrasements de ces copies toutes les x heures/jours ?

Oui, si la solution était optimale, ça ferait tâche dans un ministère public

Lol, je t'avoue que je sais que ca fonctionne comme ca mais je ne sais pas si c'est la meilleure solution ;)
Mon job consiste à faire en sorte que le bouzin qu'on me donne et qui fonctionne continue à fonctionner.

Ici, on m'a filé une petit utilitaire qui fonctionne en ligne de commande et qui écrit et lit un fichier sur le partage en boucle.
J'ai déjà eu une perte de connexion donc j'ai déjà ouvert un incident.
Je continue le monitoring pour bien prouver qu'ils sont de mauvaises fois quand ils disent que tout va bien et qu'ils ne voient rien qui ne fonctionne pas.

Ça à l’air super opti pour bosser le service public dis donc …

Si tu as 6 serveurs, dont 1 seul perd l’accès à un serveur de fichier, le problème n’est pas à chercher du côté du serveur de fichier de prime d’abord.

La configuration du machin m’échappe cependant … Si le file serveur « tombe » ; vous perdez tous les serveurs qui en dépendent, c’est comme jouer à la roulette russe mais avec un flingue automatique. (Ou avec 6 balles dans le barillet …)

Avant de taper sur une autre équipe, je ferai basiquement plusieurs « ping –t » vers différents éléments du réseau. 1 vers le swicth le plus proche, 1 vers le DC et 1 vers le file server.

En éliminant déjà une perte de connectivité, tu pourras avancer.

Car en écrivant un fichier à la bourrin, tu pourras dire "J'ai plus accès au partage à telle et telle heure" , mais tu ne peux toujours pas éliminer une perte de réseau locale.

Cela dit, quand on voit que le premier FAI belge a eu trois pannes pratiquement nationale ces 6 derniers mois, alors que la panne n'a concerné à chaque fois qu'un seul centre de données, on peut se demander si le privé connait également les "single point of failure" et les concepts de redondance Ils sont rares, les endroits où "on fait les choses correctement" :(

L'excuse du "on a toujours fait comme ça" n'est pas valable.
Sinon, on habiterait encore dans des cavernes et on se chaufferait au feu de bois - on a toujours fait comme ça

GuybrushCela dit, quand on voit que le premier FAI belge a eu trois pannes pratiquement nationale ces 6 derniers mois, alors que la panne n'a concerné à chaque fois qu'un seul centre de données, on peut se demander si le privé connait également les "single point of failure" et les concepts de redondance Ils sont rares, les endroits où "on fait les choses correctement" :(

Bof, la panne concerne une petite partie des services. (Sauf quand il y a eu destruction physique du backbone) Ou + de clients ont été impacté mais c’est compliqué à redonder …
Pour le dernier cas, ce n’est pas une « panne » ; quoi qu’en dise la version « officielle » car par exemple, j’ai été impacté dès le dimanche soir pour la TV et le Datacenter se portait comme un charme.

Et même des techniciens de la firme ne croient pas à la version officielle pp

Par expérience, quand ça merde, tu as toujours + d’un truc qui va foirer en même temps …. Donc tu ne peux pas tout prévoir (sinon le comptable va mettre ta tête à prix xD) mais entre tout redonder … et se mettre soi-même en difficulté avec une architecture bancale, y’a un gap.

Pire, si ça tombe, c’est des DEV qui ont exiger ce type de fonctionnement « C’est plus simple pour pusher directement la dernière version en prod’ m’voyez, faut pas déranger les admins ainsi … »
Pire encore que des Dev, des prestas externes … et si ça tombe, c’est le combo, dev presta externe … Le cancer de la profession …. Si tu ajoutes le côté marché public … je n’ose pas imaginer le merdier.

Manquerait plus que ce soit écrit en java, tiens.

C’est bien beau les process machin brol ITIL compliant 45.17 revison 3.12, si derrnière, on croise les effluves … et chacun le sait, il ne faut jamais croiser les effluves !