OVHcloud Web Hosting Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
P19 - Mutu
Incident
Report for Web Cloud
Resolved
Details
Nous constatons de forts ralentissements sur l’accès aux filers.Cela provoque un fort load de nos serveurs et une indisponibilité de vos services. Nous recherchons la cause de cet incident.
--
We have an issue with our filers access. This lead to our servers beeing highly loaded and unavailability of you services. We're working on it.
Update(s):
Date: 2016-12-05 22:32:15 UTC
Bonsoir,
L'origine du problème:
Pour faire arriver les requetes web de sites sur le serveur web
spécifique nous utilisons le système basé sur les Cookies. En fonction
du site web, nous déterminons quel serveur web va répondre aux
requêtes web. Et on s'assure que toutes les requêtes d'un même site
arrivent toujours sur le même serveur web. Cela permet de garantir
les ressources utilisées par un site web et d'utiliser le cache
stockage et donc d’accélérer l’exécution de pages. Et en cas de
panne du serveur web, le système recalcule le Cookie pour faire
arriver les requêtes web de ce même site sur un autre serveur web
en fonctionnement dans le cluster. Ainsi, on assure la haute
disponibilité.
Chaque serveur web a donc son numéro de cookie qui est basé sur
l'algorithme de Cisco utilisé par les ACEs. Nous connaissons la
formule et redirige ainsi la 1ere requête, vers le bon serveur
web. En suite, les requêtes web ont déjà le bon Cookie et c'est
l'ACE qui assure le load balancing et la redirection de la
requête sur le bon serveur web.
Aujourd'hui vers 14h00, la formule de calcule de Cookie a changé
de comportement suite à une modification d'une fonction qui donne
la liste de serveur web disponibles dans le cluster. Il s'agit
d'un effet de bord d'un patch. Du coup les Cookies calculés ne
correspondait à aucun Cookie reconnue par ACE et dans ce cas là,
l'ACE fait du load balancing brute sur tous les serveurs web
en même temps. C'est le comportement que le cluster avait il y a
5 ans: tous les serveurs web travaillaient pour tous les sites
web. Dans ce cas là chaque serveur web cherchaient les informations
sur tous les filers pour tous les sites. C'est ça qui a provoqué
une augmentation de trafic interne de 6x car les serveurs web ne
cachaient plus d'information en local. Cette augmentation a provoqué
les saturations de certains liens et les latences dans le réseau.
Et c'est la boule de neige qui a provoqué les coupures totales ou
partielles d'accès aux sites web :( Si le réseau n'avait pas saturé,
on n'aurait pas eu d'impact sur l'activité même avec le load balancing
sur tous les serveurs web.
L'origine du problème a été complexe à identifié. On a bien vu
que les serveurs web ne cachaient plus les informations mais on
ne trouvait pas pourquoi. Nous avons décidé d'augmenter rapidement
les capacités dans le réseau en ajoutant plusieurs liens de 10G
entre les switchs. Ceci a permit de stabiliser la situation et
nous donner le temps pour trouver l'origine du problème.
Nous avons trouvé l'origine du problème, et nous avons fait le
rollback du patch, puis nous avons repoussé le bon code sur tous
les serveurs web. Le trafic a redescendu au niveau standard.
Comment éviter que cela ne se reproduise ?
1) Dans quelques semaines, nous allons sortir du load balancing
pour le mutu basé sur l'ACE. On va ainsi savoir générer le système
de Cookie autrement et on sera moins dépendant d'un calcul précis
du Cookie. Nous avons développé notre propre système de LB qu'on
deploit progressivement en remplacement des ACEs de Cisco.
2) Aussi, on a prévu refaire le réseau à P19 en le passant de 10G
à 40G/100G et nous allons le passer sous la même technologie que
vRack avec beaucoup plus de capacité entre les équipements réseaux
et grâce à ECMP en L3 on saura mieux équilibrer les capacités dans
le réseau.
3) Malgré, pas mal d'outils de monitoring, visiblement il faut tout
remettre en cause pour faire des outils qui permettent d'avoir le
vrai point de vue de fonctionnement de l'infrastructure. Nous
n'avons pas su constater rapidement pourquoi le load balancing
ne marchait plus.
Nous sommes sincèrement désolés pour la panne. En aucun cas elle
n'aurait jamais dû être aussi longe et aussi large. Dans les
prochains jours vous allez recevoir un email d'invitation pour
les compensations liées au non respect de SLA.
Amicalement
Octave
Date: 2016-12-05 22:01:05 UTC
input rate 67.19 Mbps, 11.67 Kpps; output rate 20.54 Mbps, 9.29 Kpps
Nous avons retrouvé le niveau de trafic normal sur les
stockages.
Date: 2016-12-05 21:09:57 UTC
Le patch fixe le souci ! On a donc trouvé l'origine du probleme.
on finit le déploiement du patch pour réduire l'utilisation du
réseau et revenir sur les niveaux standards.
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 974.47 Mbps, 108.70 Kpps; output rate 95.95 Mbps, 82.92 Kpps
...
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 350.95 Mbps, 44.27 Kpps; output rate 82.87 Mbps, 28.78 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 228.52 Mbps, 31.10 Kpps; output rate 39.44 Mbps, 21.24 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 226.64 Mbps, 30.85 Kpps; output rate 37.90 Mbps, 21.05 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 208.08 Mbps, 29.10 Kpps; output rate 36.65 Mbps, 20.58 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 206.52 Mbps, 28.96 Kpps; output rate 36.72 Mbps, 20.55 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 197.82 Mbps, 27.83 Kpps; output rate 36.49 Mbps, 19.90 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 187.65 Mbps, 26.49 Kpps; output rate 35.02 Mbps, 19.16 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 155.02 Mbps, 22.82 Kpps; output rate 32.48 Mbps, 17.50 Kpps
p19-90-n6#
Au fur et à mesure que le patch se propage sur les 10000 serveurs web
on voit que le trafic vers un filer diminue progressivement. Nous avons
plus de 2000 filers ..
Date: 2016-12-05 21:01:24 UTC
Nous continuons à chercher l'origine du probleme. On pense
l'avoir trouvé. On regarde si le patch fixe le souci et
on fournit une explication à cette journée noire.
Date: 2016-12-05 17:45:51 UTC
Les sites sont UP, mais on continue à chercher l'origine du probleme.
Date: 2016-12-05 17:32:26 UTC
Nous avons forcé le redémarrage tous les sites web.
Nous avons forcé la répartition de charge vers un serveur web.
Date: 2016-12-05 17:31:49 UTC
Nous venons d'augementer la bande passante vers un couple
de N6. Ca fixe une partie de probleme. Nous avons toujours
beaucoup de trafic.
On pense que ça peut être lié à la désactivation du cache
local de serveurs web qui peut être lié à la mauvaise
répartition de charge. Le système doit rediriger les
requêtes d'un site web sur un serveur web et donc profiter
du cache local. Si la relation de charge ne se fait pas
correctement et le système balance les requêtes sur tous
les serveurs web, ça peut expliquer pourquoi nous avons
beaucoup de trafic vers les filers.
Date: 2016-12-05 17:08:04 UTC
Nous avons 4x plus de trafic sur le réseau depuis le 14H00
ce qui sature certains liens entre les baies. On ne trouve
pas encore l'origine du probleme. On va ajouter de liens
en plus dans le réseau afin d’éviter la saturation de ces
liens.
Date: 2016-12-05 16:09:38 UTC
Nous avons de saturations sur l'un de couples de N6K
(P19-90/91) ce qui provoque de ralentissements entre
les serveurs web et les filers. Du coup, les serveurs
NFS se déconnectent de serveurs WEB puis reviennent.
On cherche pourquoi les 600 liens sur ce couple sont
d'un coup passé de 2-3Gbps à 10Gbps et ont généré
plus de 300Gbps de trafic interne.
Nous constatons de forts ralentissements sur l’accès aux filers.Cela provoque un fort load de nos serveurs et une indisponibilité de vos services. Nous recherchons la cause de cet incident.
--
We have an issue with our filers access. This lead to our servers beeing highly loaded and unavailability of you services. We're working on it.
Update(s):
Date: 2016-12-05 22:32:15 UTC
Bonsoir,
L'origine du problème:
Pour faire arriver les requetes web de sites sur le serveur web
spécifique nous utilisons le système basé sur les Cookies. En fonction
du site web, nous déterminons quel serveur web va répondre aux
requêtes web. Et on s'assure que toutes les requêtes d'un même site
arrivent toujours sur le même serveur web. Cela permet de garantir
les ressources utilisées par un site web et d'utiliser le cache
stockage et donc d’accélérer l’exécution de pages. Et en cas de
panne du serveur web, le système recalcule le Cookie pour faire
arriver les requêtes web de ce même site sur un autre serveur web
en fonctionnement dans le cluster. Ainsi, on assure la haute
disponibilité.
Chaque serveur web a donc son numéro de cookie qui est basé sur
l'algorithme de Cisco utilisé par les ACEs. Nous connaissons la
formule et redirige ainsi la 1ere requête, vers le bon serveur
web. En suite, les requêtes web ont déjà le bon Cookie et c'est
l'ACE qui assure le load balancing et la redirection de la
requête sur le bon serveur web.
Aujourd'hui vers 14h00, la formule de calcule de Cookie a changé
de comportement suite à une modification d'une fonction qui donne
la liste de serveur web disponibles dans le cluster. Il s'agit
d'un effet de bord d'un patch. Du coup les Cookies calculés ne
correspondait à aucun Cookie reconnue par ACE et dans ce cas là,
l'ACE fait du load balancing brute sur tous les serveurs web
en même temps. C'est le comportement que le cluster avait il y a
5 ans: tous les serveurs web travaillaient pour tous les sites
web. Dans ce cas là chaque serveur web cherchaient les informations
sur tous les filers pour tous les sites. C'est ça qui a provoqué
une augmentation de trafic interne de 6x car les serveurs web ne
cachaient plus d'information en local. Cette augmentation a provoqué
les saturations de certains liens et les latences dans le réseau.
Et c'est la boule de neige qui a provoqué les coupures totales ou
partielles d'accès aux sites web :( Si le réseau n'avait pas saturé,
on n'aurait pas eu d'impact sur l'activité même avec le load balancing
sur tous les serveurs web.
L'origine du problème a été complexe à identifié. On a bien vu
que les serveurs web ne cachaient plus les informations mais on
ne trouvait pas pourquoi. Nous avons décidé d'augmenter rapidement
les capacités dans le réseau en ajoutant plusieurs liens de 10G
entre les switchs. Ceci a permit de stabiliser la situation et
nous donner le temps pour trouver l'origine du problème.
Nous avons trouvé l'origine du problème, et nous avons fait le
rollback du patch, puis nous avons repoussé le bon code sur tous
les serveurs web. Le trafic a redescendu au niveau standard.
Comment éviter que cela ne se reproduise ?
1) Dans quelques semaines, nous allons sortir du load balancing
pour le mutu basé sur l'ACE. On va ainsi savoir générer le système
de Cookie autrement et on sera moins dépendant d'un calcul précis
du Cookie. Nous avons développé notre propre système de LB qu'on
deploit progressivement en remplacement des ACEs de Cisco.
2) Aussi, on a prévu refaire le réseau à P19 en le passant de 10G
à 40G/100G et nous allons le passer sous la même technologie que
vRack avec beaucoup plus de capacité entre les équipements réseaux
et grâce à ECMP en L3 on saura mieux équilibrer les capacités dans
le réseau.
3) Malgré, pas mal d'outils de monitoring, visiblement il faut tout
remettre en cause pour faire des outils qui permettent d'avoir le
vrai point de vue de fonctionnement de l'infrastructure. Nous
n'avons pas su constater rapidement pourquoi le load balancing
ne marchait plus.
Nous sommes sincèrement désolés pour la panne. En aucun cas elle
n'aurait jamais dû être aussi longe et aussi large. Dans les
prochains jours vous allez recevoir un email d'invitation pour
les compensations liées au non respect de SLA.
Amicalement
Octave
Date: 2016-12-05 22:01:05 UTC
input rate 67.19 Mbps, 11.67 Kpps; output rate 20.54 Mbps, 9.29 Kpps
Nous avons retrouvé le niveau de trafic normal sur les
stockages.
Date: 2016-12-05 21:09:57 UTC
Le patch fixe le souci ! On a donc trouvé l'origine du probleme.
on finit le déploiement du patch pour réduire l'utilisation du
réseau et revenir sur les niveaux standards.
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 974.47 Mbps, 108.70 Kpps; output rate 95.95 Mbps, 82.92 Kpps
...
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 350.95 Mbps, 44.27 Kpps; output rate 82.87 Mbps, 28.78 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 348.19 Mbps, 43.96 Kpps; output rate 81.15 Mbps, 28.56 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 265.41 Mbps, 35.56 Kpps; output rate 57.98 Mbps, 24.28 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 254.96 Mbps, 34.32 Kpps; output rate 51.54 Mbps, 23.34 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 228.52 Mbps, 31.10 Kpps; output rate 39.44 Mbps, 21.24 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 226.64 Mbps, 30.85 Kpps; output rate 37.90 Mbps, 21.05 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 208.08 Mbps, 29.10 Kpps; output rate 36.65 Mbps, 20.58 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 206.52 Mbps, 28.96 Kpps; output rate 36.72 Mbps, 20.55 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 197.82 Mbps, 27.83 Kpps; output rate 36.49 Mbps, 19.90 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 187.65 Mbps, 26.49 Kpps; output rate 35.02 Mbps, 19.16 Kpps
p19-90-n6# sh inter Eth104/1/38 | i \" input rate\"
input rate 155.02 Mbps, 22.82 Kpps; output rate 32.48 Mbps, 17.50 Kpps
p19-90-n6#
Au fur et à mesure que le patch se propage sur les 10000 serveurs web
on voit que le trafic vers un filer diminue progressivement. Nous avons
plus de 2000 filers ..
Date: 2016-12-05 21:01:24 UTC
Nous continuons à chercher l'origine du probleme. On pense
l'avoir trouvé. On regarde si le patch fixe le souci et
on fournit une explication à cette journée noire.
Date: 2016-12-05 17:45:51 UTC
Les sites sont UP, mais on continue à chercher l'origine du probleme.
Date: 2016-12-05 17:32:26 UTC
Nous avons forcé le redémarrage tous les sites web.
Nous avons forcé la répartition de charge vers un serveur web.
Date: 2016-12-05 17:31:49 UTC
Nous venons d'augementer la bande passante vers un couple
de N6. Ca fixe une partie de probleme. Nous avons toujours
beaucoup de trafic.
On pense que ça peut être lié à la désactivation du cache
local de serveurs web qui peut être lié à la mauvaise
répartition de charge. Le système doit rediriger les
requêtes d'un site web sur un serveur web et donc profiter
du cache local. Si la relation de charge ne se fait pas
correctement et le système balance les requêtes sur tous
les serveurs web, ça peut expliquer pourquoi nous avons
beaucoup de trafic vers les filers.
Date: 2016-12-05 17:08:04 UTC
Nous avons 4x plus de trafic sur le réseau depuis le 14H00
ce qui sature certains liens entre les baies. On ne trouve
pas encore l'origine du probleme. On va ajouter de liens
en plus dans le réseau afin d’éviter la saturation de ces
liens.
Date: 2016-12-05 16:09:38 UTC
Nous avons de saturations sur l'un de couples de N6K
(P19-90/91) ce qui provoque de ralentissements entre
les serveurs web et les filers. Du coup, les serveurs
NFS se déconnectent de serveurs WEB puis reviennent.
On cherche pourquoi les 600 liens sur ce couple sont
d'un coup passé de 2-3Gbps à 10Gbps et ont généré
plus de 300Gbps de trafic interne.