[CENTRA][LA COLLE DU JOUR] - 006 - c:\>Win

[Toorist]

Fu le hard et le réseau

On (je) veut du dev !

les loadbalancers sont configurés en mode "sticky IP" pour qu'une même agence soit toujours orientée vers le même serveur applicatif.

toutes les agences qui utilisent le serveur 3 ne branlent rien

je pense que les gens ne sont pas redirigé vers le 3ème serveur ce qui explique qu'il ne fasse rien ( et récupérer 100% + 100% des autres => service dégradé ou owned )

[Wildduck]

@Killator: à cause des tuyaux peut-être?

[ano_634765235136126340]

on peut avoir un indice? y'a de la charge sur le proxy 2? parce que bon la on est plus dans le hardware et c'est un incident un poil plus balaise que les soucis de rad.. déja on peut excluse le MPSL si tu as bel et bien de la charge et qu'aucun problème d'accès aux 2 serveurs n'est signalé par les sucursales

[Killator]

Allez, petits indices pour relancer l'INtêret du sujet

Oui, la charge est bien répartie 50/50 entre les DEUX reverse-proxy et les deux loadbalancer n'ont pas d'instructions particulières quand à la répartition de charge (n machines éligibles pour le traitement des requêtes donc tu orientes vers SRV1, puis vers 2 SRV2, puis vers SRV3, puis vers SRVn, puis à nouveau SRV1, SRV2, SRV3, SRVn, etc.) exceptés si IP d'origine déjà connue car "Sticky IP"...

Cherchez juste la cause... Je vous donnerai la solution au problème qui ne s'invente pas si on ne connait pas

[ano_634765235136126340]

je pense a deuix choses, le dimentionnement sticky ip si certaines sucursales ont un nombre plus élevées que d'autres ce qui engorge le serv2. si hipotétiquement tu bosses avec une DB, une db mal dimentionnée bloquée sur des requetes non optimisées ce qui engedrerai un engorgement et un crash.

mais ce ne sont que des hipothèses, je bosse pas du tout dans ce domaine la

[Killator]

@Leoleandro: ne cherche pas de piste "exotique" (base de donnée, etc)... Tout ce qui concerne le problème est mentionné dans l’énoncé...

Et comme tu fais l'effort de chercher, je poursuis un peu mes précisions: chaque agence est vue comme une IP unique par le siège (n agences = n IP capable d'adresser des requêtes)... S'il y a plusieurs ordinateurs dans une agence, il y a un routeur sur place qui gère un sous-réseau, mais c'est complétement transparent ici...

"L'astuce" réside bien dans la gestion faites par l'infra réseau... C'est "presque" de la logique...

[Higapeon]

Les deux RP sont 2 IP "source" pour le loadbalancer 2, qui ne voit que 2 IP source et distribue les flux sur Serv 1 & Serv 2, à cause de son sticky IP. Il n'est pas au courant que ça provient de n agences différentes : il n'a que 2 reverse comme interlocuteurs.

Je vois que ça. Mes connaissances sont pas assez développées pour voir autre chose = /

[Invité]

Bon bah ça a pas rameuté beaucoup de participants ^^

[Invité]

Allez killator il est temps de donner la réponse que je puisse mettre la 4 !!!

[Killator]

Dans le métro... Je rentre tout juste du boulot !

Laissez moi 1/2 heures et je vous donne la réponse, sorry

[ano_634765235136126340]

franchement.... apars

le serveur 3 qui est set en DRP dans la configuration du load balancer 2.... ce qui donnerait serv1 50%+serv2 50% +DRP au lieux de serv1 33%+ serv2 33% + serv3 33% , je vois franchement pas la comme ça de tête

j'ai hate de voir la reponse

[Killator]

Me revoilou... Pour le dénouement final... Je suis juste passé par la case conférence IBM sur le cloud computing (un peu trop commerciale à mon gout), puis par la case resto, qui n'était pas prévue à la base...

Alors, la réponse exacte a été trouvé par Higapeon ! Bravo à lui

Effectivement, le LoadBalancer n°1 "stickait" bien les IP de chaque agence vers les reverse proxy n°1 et n°2 MAIS sur le même fonctionnement, le LoadBalancer n°2 "stickait" les IP des reverse proxy n°1 et n°2 sur le serveur applicatif n°1 et n°2 ET PUIS C'EST TOUT...

L'admin réseau a payé le champagne pour cette "petite" boulette qui a fait perdre énormément de temps et d'argent au projet car avant d'auditer le réseau (qui se disait blanc comme neige) on pensait que ça venait du framework "custom" de l'appli et de fuites mémoires...

La solution à notre problème: passer les load-balancer du mode "sticky IP" au mode "sticky cookies". Ici le discriminant n'est plus l'adresse IP de la source mais le cookie de session de l'utilisateur présent dans l'entête HTTP envoyée par le navigateur...

Ce paramétrage, en plus de résoudre notre problème, avait l'avantage de brasser les requêtes au niveau de chaque machine cliente et non plus pour chaque IP d'agence...

Voili voulou... Cette colle assez technique n'était pas forcément accessible à tout le monde, mais j'espère au moins qu'elle vous a INtéressé

A une prochaine

[Invité]

COLLE N° 4 disponible

[Killator]

Il s'agit de cartes USB noname avec un contrôleur USB exotique n'ayant pas "encore" de drivers appropriés pour Vista ou W7... L'OS utilise alors un driver générique approximatif qui n'autorise (au mieux) que l'USB1... Beaucoup de périphériques ne sont pas montés ou le sont seulement en USB1 (comme la vieille clef USB)

Ca me rappelle les premiers périphériques USB sous W98...

[Invité]

J'ai apporté une petite modif à l'énoncé

[John Shaft]

Si tu pouvais mettre un lien vers le 1er post quand tu postes une nouvelle colle, ça serait et !

« ce périphérique peut fonctionner plus rapidement » => Bon, à priori, ça signifie que la carte fonctionne en USB 1 (ou 1.1) et on peut parier qu'il s'agit d'un modèle un peu vieux nécéssitant des drivers spécifiques, dont W7 ne dispose pas et qui ne fonctionne pas avec les drivers génériques de Seven qui n'arrive du coup à les faire marcher qu'en USB 1

[Ellierys]

Ca sent le controleur made in ouzbekistan a 10¤. Pas de driver sous Vista/Se7en, l'OS charge un Driver générique qui ne fait fonctionner le controleur qu'en USB 1.1.

Concernant les appareils qui ne fonctionnent pas, il consomment surement plus de 100mA intensité autorisée par la norme USB 1.1, alors que la norme USB 2.0 permet 500mA, d'ou leur non fonctionnement complet.

[Toorist]

Pour ma part, ce sera un soupçon de drivers agrémenté d'un zeste de distribution d'énergie sans les drivers

édit: ah ba le Mr au dessus il dit plus ou moins comme moi mais il s'y connait plus

[Wildduck]

les cartes additionnelles n'avaient pas de driver correct par défaut dans Win7 ou plutôt étaient mal reconnues vu que Win a rien demandé de plus mais les prenaient pour de l'USB1. L’informaticien a juste du aller dans le gestionnaire de périphériques et mettre à jour le pilote.

Edit: ah ouais ça explique pas que seule la vieille clé soit reconnue. Pour ça Ellierys doit tenir la solution

[Invité]

mmmmh... vous croyez que j'aurais posé une question sur un driver qui n'existe pas ?

[Toorist]

Ba du coup c'est pas juste l'alimentation des cartes USB qui était mal réglée et qui donnait pas assez de jus ?

[Killator]

Pour info, la petite modif qu'à fait Philo après ma proposition est l'ajout de ce paragraphe:

L'informaticien du coin résoud le problème en deux minutes chrono, juste en bidouillant dans les opaques paramêtres de Windows qui sont aussi compréhensibles par vous que l'interprétation des réalités quantiques au travers du prisme de la pensée de Svâmi Prajnanpad.

Je crois que l'histoire du prisme lumière de Sailor Moon est une piste

[Invité]

J'ai pas attendu que tu écrive, tu m'as pas laissé le temps de me relire mdr

[keneda212]

Sans ce rajout de ligne, j'aurai dit que les usb2 n'ont pas été activé dans le bios... mais la, je vois pas, une bidouille dans seven... j'ai jamais eu de seven

genre desinstallation des drivers pour qu'ils les reinstall correctement ensuite pour chaque hub usb?

[Invité]

mmmmh... On s'éloigne