OVHcloud Private Cloud Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
1000v et host 10G
Incident
Report for Hosted Private Cloud
Resolved
Nous avons détecté une défaillance dans nos infrastructures qui concerne les
hosts avec une connectivité 10G (host L2 et XL) dans des datacenters
où le cisco nexus 1000v a été activé.
Cette défaillance, suite à un évènement sur le réseau et à une mauvaise configuration
du dvUplink des 1000v, amène le host à ne plus pouvoir fournir en réseau les
machines virtuelles qu'il héberge.
En effet, le dvUplink est composé de 3 cartes réseaux, 2 10G et une 100M.
Le 1000v ne permet pas d'appliquer une configuration à l'identique du vSS
ou du vDS qu'il remplace, et considérait la carte 100M comme une carte 10G.
Dans certaines conditions, nous avons retrouvé le host utiliser cette carte
100M et devenir ainsi injoignable. En retirant la carte 100M, nous avons
retrouvé la connectivité du host.
Dès que les 10G étaient revenus dans le port-channel, les VMs auraient du repartir, mais le 1000v
a refusé de switcher dessus :
Dans un cas normal :
~ # vemcmd show port
LTL VSM Port Admin Link State PC-LTL SGID Vem Port Type
19 Eth5/3 UP UP F/B* 0 2 vmnic2
20 Eth5/4 UP UP F/B* 0 3 vmnic3
49 Veth33 UP UP FWD 0 2 vmk1
50 Veth41 UP UP FWD 0 2 vmk0
51 Veth385 UP UP FWD 0 2 vmk2 VXLAN
59 Veth342 UP UP FWD 0 3 vm1.localhost.eth0
On voit que le SGID est 3 => vm1.localhost.eth0 passe par vmnic3 pour sortir.
vmk0-2 => vmnic2
Ici :
~ # vemcmd show port
LTL VSM Port Admin Link State PC-LTL SGID Vem Port Type
19 Eth5/3 UP UP F/B* 0 2 vmnic2
20 Eth5/4 UP UP F/B* 0 3 vmnic3
49 Veth33 UP UP FWD 0 vmk1
50 Veth41 UP UP FWD 0 vmk0
51 Veth385 UP UP FWD 0 vmk2 VXLAN
59 Veth342 UP UP FWD 0 vm1.localhost.eth0
Le vem ne sait plus attribuer le pinning dans le port-channel.
Le host et le 1000v acceptent une VM sur un vMotion, mais la VM ne ping plus.
Pour que le vem retrouve le moyen de pinner correctement les VMs et les vmk nous
sommes obligés de faire un hotswap du vem :
~ # hotswap.sh -u && sleep 3 && hotswap.sh -l && sleep 5 && vem restart
The following switch is of type cisco_nexus_1000v: DvsPortset-0
Starting time: Fri May 24 16:36:01 UTC 2013
stopDpa
VEM SwISCSI PID is
returning
watchdog-vemdpa: Terminating watchdog with PID 5393551
Unload N1k switch modules
stop stun
Module vem-v152-stun being unloaded..
Module vem-v152-stun unloaded..
Module vem-v152-vssnet being unloaded..
Module vem-v152-vssnet unloaded..
Module vem-v152-n1kv being unloaded..
Module vem-v152-n1kv unloaded..
Module vem-v152-l2device being unloaded..
Module vem-v152-l2device unloaded..
Unload of N1k modules done.
startDpa
Ending time: Fri May 24 16:36:12 UTC 2013
stopDpa
VEM SwISCSI PID is
returning
watchdog-vemdpa: Terminating watchdog with PID 5791406
startDpa
Ce qui reset complètement le module vem.
Nous allons passer sur toutes les infrastructure pour fixer le problème et
ajouter un monitoring spécial pour ce use case.
1 - coupure des robots impactés
1 - remove de l'uplink 100M du port-channel
2 - check de l'état du port-channel (pinning opérationnel)
3 - patch des robots et remise en route des robots
4 - mise en place du monitoring si la défaillance du pinning se reproduit sur la prod
Le ticket 626085527 ouvert ches cisco est en cours de résolution. (/n1k/dc1003a-n1/4.2.1.SV2.1.1a/1000v and 10G behavior)
Update(s):
Date: 2013-05-30 11:55:25 UTC
Plus aucun comportement lié à ce bug n'a été remonté depuis.
Nous restons vigilent et le ticket reste ouvert chez cisco et nous l'alimenterons suite aux remontées du monitoring.
Date: 2013-05-24 23:15:15 UTC
Le monitoring est en place, nous surveillons maintenant tous ces comportements.
Le ticket chez Cisco reste ouvert, nous continuons avec les ingénieurs cisco lundi dans la journée.
Date: 2013-05-24 22:56:23 UTC
3 - patch des robots et remise en route des robots
Les robots sont opérationnels, le cartes 100M n'existent plus.
4 - la mise en place du monitoring est en cours
Date: 2013-05-24 22:30:57 UTC
1 - remove de l'uplink 100M du port-channel
Tous les hosts impactés ont maintenant le port-channel composé d'uniquement les ports 10G
2 - check de l'état du port-channel (pinning opérationnel)
Tous les pinning sont rétablis et la redondance est assurée
3 - patch des robots et remise en route des robots
Nous sommes en train de patcher les robots
hosts avec une connectivité 10G (host L2 et XL) dans des datacenters
où le cisco nexus 1000v a été activé.
Cette défaillance, suite à un évènement sur le réseau et à une mauvaise configuration
du dvUplink des 1000v, amène le host à ne plus pouvoir fournir en réseau les
machines virtuelles qu'il héberge.
En effet, le dvUplink est composé de 3 cartes réseaux, 2 10G et une 100M.
Le 1000v ne permet pas d'appliquer une configuration à l'identique du vSS
ou du vDS qu'il remplace, et considérait la carte 100M comme une carte 10G.
Dans certaines conditions, nous avons retrouvé le host utiliser cette carte
100M et devenir ainsi injoignable. En retirant la carte 100M, nous avons
retrouvé la connectivité du host.
Dès que les 10G étaient revenus dans le port-channel, les VMs auraient du repartir, mais le 1000v
a refusé de switcher dessus :
Dans un cas normal :
~ # vemcmd show port
LTL VSM Port Admin Link State PC-LTL SGID Vem Port Type
19 Eth5/3 UP UP F/B* 0 2 vmnic2
20 Eth5/4 UP UP F/B* 0 3 vmnic3
49 Veth33 UP UP FWD 0 2 vmk1
50 Veth41 UP UP FWD 0 2 vmk0
51 Veth385 UP UP FWD 0 2 vmk2 VXLAN
59 Veth342 UP UP FWD 0 3 vm1.localhost.eth0
On voit que le SGID est 3 => vm1.localhost.eth0 passe par vmnic3 pour sortir.
vmk0-2 => vmnic2
Ici :
~ # vemcmd show port
LTL VSM Port Admin Link State PC-LTL SGID Vem Port Type
19 Eth5/3 UP UP F/B* 0 2 vmnic2
20 Eth5/4 UP UP F/B* 0 3 vmnic3
49 Veth33 UP UP FWD 0 vmk1
50 Veth41 UP UP FWD 0 vmk0
51 Veth385 UP UP FWD 0 vmk2 VXLAN
59 Veth342 UP UP FWD 0 vm1.localhost.eth0
Le vem ne sait plus attribuer le pinning dans le port-channel.
Le host et le 1000v acceptent une VM sur un vMotion, mais la VM ne ping plus.
Pour que le vem retrouve le moyen de pinner correctement les VMs et les vmk nous
sommes obligés de faire un hotswap du vem :
~ # hotswap.sh -u && sleep 3 && hotswap.sh -l && sleep 5 && vem restart
The following switch is of type cisco_nexus_1000v: DvsPortset-0
Starting time: Fri May 24 16:36:01 UTC 2013
stopDpa
VEM SwISCSI PID is
returning
watchdog-vemdpa: Terminating watchdog with PID 5393551
Unload N1k switch modules
stop stun
Module vem-v152-stun being unloaded..
Module vem-v152-stun unloaded..
Module vem-v152-vssnet being unloaded..
Module vem-v152-vssnet unloaded..
Module vem-v152-n1kv being unloaded..
Module vem-v152-n1kv unloaded..
Module vem-v152-l2device being unloaded..
Module vem-v152-l2device unloaded..
Unload of N1k modules done.
startDpa
Ending time: Fri May 24 16:36:12 UTC 2013
stopDpa
VEM SwISCSI PID is
returning
watchdog-vemdpa: Terminating watchdog with PID 5791406
startDpa
Ce qui reset complètement le module vem.
Nous allons passer sur toutes les infrastructure pour fixer le problème et
ajouter un monitoring spécial pour ce use case.
1 - coupure des robots impactés
1 - remove de l'uplink 100M du port-channel
2 - check de l'état du port-channel (pinning opérationnel)
3 - patch des robots et remise en route des robots
4 - mise en place du monitoring si la défaillance du pinning se reproduit sur la prod
Le ticket 626085527 ouvert ches cisco est en cours de résolution. (/n1k/dc1003a-n1/4.2.1.SV2.1.1a/1000v and 10G behavior)
Update(s):
Date: 2013-05-30 11:55:25 UTC
Plus aucun comportement lié à ce bug n'a été remonté depuis.
Nous restons vigilent et le ticket reste ouvert chez cisco et nous l'alimenterons suite aux remontées du monitoring.
Date: 2013-05-24 23:15:15 UTC
Le monitoring est en place, nous surveillons maintenant tous ces comportements.
Le ticket chez Cisco reste ouvert, nous continuons avec les ingénieurs cisco lundi dans la journée.
Date: 2013-05-24 22:56:23 UTC
3 - patch des robots et remise en route des robots
Les robots sont opérationnels, le cartes 100M n'existent plus.
4 - la mise en place du monitoring est en cours
Date: 2013-05-24 22:30:57 UTC
1 - remove de l'uplink 100M du port-channel
Tous les hosts impactés ont maintenant le port-channel composé d'uniquement les ports 10G
2 - check de l'état du port-channel (pinning opérationnel)
Tous les pinning sont rétablis et la redondance est assurée
3 - patch des robots et remise en route des robots
Nous sommes en train de patcher les robots