OVHcloud Network Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
bhs-1a/b-n7
Scheduled Maintenance
Report for Network & Infrastructure
Completed
Afin d'apporter les derniers correctifs fonctionnels et de sécurité, nous allons mettre à jour ce couple de switchs le jeudi 21 avril à partir de 01h00 ET (07h00 CEST).
La mise à jour sera faite en ISSU.
Update(s):
Date: 2016-04-21 15:43:38 UTC
Lors de l'isolation de bhs-1b-n7 afin de préparer le processus de mise à jour, une erreur a été commise dans l'ordre de la procédure d'isolation.
Les deux équipements sont redondants et fonctionnent en virtual PortChannel (vPC). Cette technologie permet à 2 équipements de fonctionner ensemble et de former une seule entité logique pour les équipements qui y sont raccordés.
Ce matin, bhs-1a-n7 était \"vPC secondary\" et bhs-1b-n7 \"vPC primary\". Nous avons tout d'abord effectué la mise à jour sur bhs-1a-n7. Lorsque nous avons voulu mettre à jour bhs-1b-n7, nous avons tout d'abord coupé l'ensemble des liens : uplinks (vers le réseau OVH) et les downlinks (switchs sur lesquels sont connectés les hosts et le stockage). L'étape suivante était de couper les liens propres au fonctionnement de vPC : le vPC peer link (lien permettant de synchroniser les états et le trafic qui peut croiser dans certains cas) et le vPC peer keepalive link (lien dédié au monitoring des switchs entre eux : messages \"hello\").
C'est durant cette étape que l'ordre d’exécution de la procédure a été inversé : le peer link a été désactivé avant le peer keepalive. Dans ces conditions, le switch vPC secondary coupe l'intégralité de ses ports afin d'éviter un scénario de Dual Active. Nous avons immédiatement rallumé le port, mais ces quelques secondes de coupure ont eu un impact coupant l'accès à la patte publique et la communication entre le stockage et les hosts ce qui peut provoquer le passage des VMs en read-only.
Date: 2016-04-21 11:56:21 UTC
Le B est à jour, nous le rallumons.
Date: 2016-04-21 08:59:46 UTC
Un flap est survenu durant l'isolation du B, une interruption de quelques instants est survenue.
Certaines VMs peuvent être passées en read-only.
Date: 2016-04-21 08:43:55 UTC
Nous démarrons l'isolation du B.
Date: 2016-04-21 08:22:26 UTC
Le A est à jour, nous allons le remettre en production.
Date: 2016-04-21 05:06:20 UTC
Nous commençons l'isolation du switch A.
Date: 2016-04-21 04:48:46 UTC
Nous allons démarrer par bhs-1a-n7-pcc (vPC role: secondary).
Date: 2016-04-21 04:42:20 UTC
Nous commençons l'intervention, les opérations sont suspendues durant la maintenance.
La mise à jour sera faite en ISSU.
Update(s):
Date: 2016-04-21 15:43:38 UTC
Lors de l'isolation de bhs-1b-n7 afin de préparer le processus de mise à jour, une erreur a été commise dans l'ordre de la procédure d'isolation.
Les deux équipements sont redondants et fonctionnent en virtual PortChannel (vPC). Cette technologie permet à 2 équipements de fonctionner ensemble et de former une seule entité logique pour les équipements qui y sont raccordés.
Ce matin, bhs-1a-n7 était \"vPC secondary\" et bhs-1b-n7 \"vPC primary\". Nous avons tout d'abord effectué la mise à jour sur bhs-1a-n7. Lorsque nous avons voulu mettre à jour bhs-1b-n7, nous avons tout d'abord coupé l'ensemble des liens : uplinks (vers le réseau OVH) et les downlinks (switchs sur lesquels sont connectés les hosts et le stockage). L'étape suivante était de couper les liens propres au fonctionnement de vPC : le vPC peer link (lien permettant de synchroniser les états et le trafic qui peut croiser dans certains cas) et le vPC peer keepalive link (lien dédié au monitoring des switchs entre eux : messages \"hello\").
C'est durant cette étape que l'ordre d’exécution de la procédure a été inversé : le peer link a été désactivé avant le peer keepalive. Dans ces conditions, le switch vPC secondary coupe l'intégralité de ses ports afin d'éviter un scénario de Dual Active. Nous avons immédiatement rallumé le port, mais ces quelques secondes de coupure ont eu un impact coupant l'accès à la patte publique et la communication entre le stockage et les hosts ce qui peut provoquer le passage des VMs en read-only.
Date: 2016-04-21 11:56:21 UTC
Le B est à jour, nous le rallumons.
Date: 2016-04-21 08:59:46 UTC
Un flap est survenu durant l'isolation du B, une interruption de quelques instants est survenue.
Certaines VMs peuvent être passées en read-only.
Date: 2016-04-21 08:43:55 UTC
Nous démarrons l'isolation du B.
Date: 2016-04-21 08:22:26 UTC
Le A est à jour, nous allons le remettre en production.
Date: 2016-04-21 05:06:20 UTC
Nous commençons l'isolation du switch A.
Date: 2016-04-21 04:48:46 UTC
Nous allons démarrer par bhs-1a-n7-pcc (vPC role: secondary).
Date: 2016-04-21 04:42:20 UTC
Nous commençons l'intervention, les opérations sont suspendues durant la maintenance.
This scheduled maintenance affected: Infrastructure || BHS (BHS1, BHS2, BHS3, BHS4, BHS5, BHS6, BHS7).