Salut,
Alors c'est simple, dans le sens premier du terme:
- effectivement les 3 serveurs sur le même switch
- pas de vlan taggé, un seul global untag
- pas sur le switch en question
- 1 lien par serveur vers le switch (3 liens total sur un switch qui en
a actuellement une quinzaine)
- aucune techno software style aggregation ni HA
- c'est un nouveau déploiement, mais qui fonctionne sans problèmes sur
quelques autres installations du même type (web + mysql)
- j'ai le problème depuis 3 jours, et c'est suite à une migration depuis
une ancienne infrastructure (qui commencait à montrer des symptomes
similaires, je n'ai malheuresement pas pu tester ni faire de captures
sur cette ancienne installation)
- coté flux:
- aucun équipement de filtrage à ce niveau
les autres équipements n'interagissent pas avec les 3 serveurs en
question, et fonctionnent d'eux même très bien.
- Lorsque le problème survient, comme j'avais tenté de l'expliquer,
c'est uniquement les connexions entre un serveur web et le serveur mysql
qui font ce "bégaiement" TCP. toutes les autres communications entrantes
et sortantes du serveur web et mysql fonctionnent (ssh sur les 2
serveurs, le http qui marche sur le web sans problème, mysql qui
fonctionne sans problème avec l'autre serveur).
- la table arp n'a pas plus de 10 entrées et je controle le réseau local
de bout en bout, donc pas de connexion sauvage ou de conflit d'IP.
N'ayant aucune piste, j'ai déjà vérifié tous ces élements jusqu'au trucs
les plus absurdes sans rien trouver.
J'ajoute que lorsque le problème arrive, un netstat sur le serveur MySQL
montre tout un tas de connexions venant du serveur web en état
"SYN_RECV" prouvant bien que le serveur est en train d'attendre que le
client accepte la connexion. Le client de son côté a envoyé le SYN
initial, recu le ACK du serveur, mais au lieu de répondre, il attend 3
secondes et retransmet le SYN. Simultanément, le meme serveur accepte
les connexions de l'autre serveur web sans broncher.
Je n'ai par ailleurs trouvé aucun élement ou serveur qui pourrait
expliquer ce déclenchement du problème à intervalles si réguliers.
J'avoue que c'est le genre de problème interessant à comprendre mais ca
serait bien plus agréable si on me foutait pas autant la pression pour
que ca "marche" derrière :)
Gabriel
On 03/03/2008 11:17:11 PM +0100, "Christophe VIAUD" <[EMAIL PROTECTED]>
wrote:
Salut,
Je ne sais pas si ça intéresse tout le monde de suivre cette discussion,
si cela gêne du monde, merci de nous le faire savoir on continuera en
offline :D
Pour ton pb, difficile d'en faire l'analyse sans qques infos
complémentaires (pour ne rien perdre au passage et afin que l'on soit au
même niveau d'info que toi ^_^)
Côté architecture :
- Ton architecture réseau c'est bien les 2 serveurs web et le serveur
mysql sur le même switch ?
- dans le même vlan ?
- du spanning-tree ?
- question bête mais sais t'on jamais : ton serveur MySQL a combien de
lien physique vers ce switch ? fais-tu du teaming, channel bonding ou tout
autre techno d'aggrégation de lien ou de tolérance de panne (lan ha,...) ?
- lié à la question précédente : c'est un nouveau déploiement ? depuis
combien de temps que tu as le pb par rapport à la date de déploiement ?
Côté flux :
- Pour ce flux tu passes en direct ou par un équipement de filtrage ?
- quels sont les autres équipements (serveurs compris) qui sont dans le
même segment que ton serveur et qui potentiellement pourrait nuir au
trafic ?
- lorsque le pb survient, c'est juste le flux serveur web -> MySQL qui
pose pb ou tu as des pb de connexion vers les serveurs web aussi ?
as-tu vérifié les tables arp de tes serveurs web et de ton serveur MySQL
lorsque le pb survient ? => je pense à une machine qui a la même ip ou la
même adresse mac et qui pourrait émettre des trames de temps en temps,
provoquant un pb dans la table de forwarding du switch, le temps de la
ré-émission de paquet, ou encore un pb dans la config du teaming ou
channel bonding (pb de mac flapping)...
tu peux vérifier aussi dans ta capture réseau, mais le mieux c'est qd le
problème survient.
voilà c'est déjà pas mal pour un premier diag :) t'as de quoi faire ;)
--
Christophe VIAUD
Bonsoir,
J'ai actuellement un problème qui m'est pour le moment totalement
insoluble, et qui après 3 jours de farfouillage me permet de l'exposer
clairement. Je sais qu'ici n'est pas un support technique, mais peut
etre que certaines personnes ont déjà eu ce genre d'expérience alors je
tente le coup :-)
Problématique initiale:
* j'ai 2 serveurs web qui interrogent un serveur MySQL (super original).
Tout irait pour le mieux si *de temps en temps* l'un ou l'autre serveur
web ne se mettait pas a faire la tronche au serveur MySQL et a ne plus
vouloir se connecter.
En fouillant, j'obtiens de droles de données qui commencent à me rendre
dingue:
- Cela se produit pile poil toutes les 15 minutes (un coup c'est un
serveur, un coup c'est l'autre 15 minutes chacun en décalé) et dure à
peine 1 minute
- Lorsque cela se produit, le fait de telnet <ip de mysql> 3306 provoque
une latence d'*exactement* 3 secondes avant d'afficher le welcome de mysql
Après avoir cherché la ou ca ne donne rien, j'ai décidé de sortir
tcpdump, et au moment ou ca arrive, de le lancer sur le serveur et le
client en même temps (dans mon cas, un serveur web et un serveur mysql).
La capture des paquets m'indique que le client envoie un SYN au serveur,
qui répond par un SYN,ACK, puis 3 secondes précisément s'écoulent, et le
client renvoie de nouveau un SYN, puis le serveur répond SYN,ACK, et
enfin le client complète le 3-way handshake par un ACK (puis se met à
causer le mysql).
J'ai fait le rapprochement des 3 secondes d'attente avant retransmission
avec la variable "tcp_retries1" qui est le temps avant de ressayer une
transmission TCP sous linux.
La ou est l'énigme, c'est que la capture des paquets sur le client ET le
serveur sont exactement les mêmes, il n'y a donc pas de paquet qui à été
perdu en cours de route! Pourquoi cet idiot passe dans la procédure de
retry en attendant 3 secondes plus tard ?
Infos:
Le switch est un bête truc D-Link gigabit, qui commute sans problème
tout le reste du traffic, donc ce n'est pas la cause.
MySQL ne semble pas être en cause, car pendant qu'il galère a
communiquer avec un des 2 serveurs, l'autre continue ses conversations
sans accroc.
Ce n'est pas une histoire de charge car tout ce bazar ne dépasse pas les
0.3 même en crachant 400 requetes/seconde
Le fond du problème est: depuis quand le protocole TCP bégaye-t-il ???
Et pourquoi toutes les 15 minutes ? Quelqu'un à déja vu un truc pareil ?
A vôt bon coeur!
Gabriel
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
