rssLink RSS for all categories
 
icon_red
icon_green
icon_orange
icon_red
icon_red
icon_green
icon_green
icon_red
icon_red
icon_blue
icon_green
icon_green
icon_green
icon_orange
icon_orange
icon_red
icon_green
icon_green
icon_red
icon_orange
icon_green
icon_green
icon_red
icon_blue
icon_orange
icon_green
icon_green
icon_green
icon_green
icon_green
icon_red
 

FS#4440 — Split de vss - Travaux cette nuit 21-22/09 sur Roubaix3

Attached to Project— Reseau Internet et Baies
Maintenance
Tout le réseau
CLOSED
100%
Bonsoir,
Pour le datacentre Roubaix 2, nous avons décidé de mettre en place
le réseau avec un objectif de 100% de disponibilité. Pour cela
nous avons utilisé les switchs Cisco 6509 dans la configuration
VSS. Il s'agit d'une système basé sur 2 châssis fonctionnant comme
1 seul. Avec 2 châssis, tout est doublé, et donc on devrait avoir
100% de disponibilité.

Dans le monde réel, nous avons plusieurs problèmes avec les VSS qui
provoqué de coupure dans le service et donc n'ont pas remplit le
contrat initial. A la base, nous avons un problème chronique sur
le BGP. A moindre modification de table de routage, le CPU du
routeur est à 100% pendant 15 minutes minimum. Pas grave. Mais fin
2009, nous avons mis en place de protections fortes sur le réseau
interne qui consistent à isoler chaque serveur d'un autre. On le réalise
à travers les vlan privé et la mise en place d'un proxy arp. Très
standard comme solution. Le routeur répond à la place de tous les
serveurs et assure le routage même dans un même vlan. Tout est donc
très secure. Par contre le routeur doit répondre à toutes les demandes
de MAC de tous les serveurs et le processes qui le gère sur le VSS
prend beaucoup de CPU.

En temps normal tout ceci fonctionne sans problème. Mais il suffit
que le réseau recalcule les tables de routage pour que le BGP prennent
100% du CPU et empêche le processes MAC de fonctionner. La conséquence:
les serveurs ne connaissent plus les MAC et il y a une coupure dans
le service pendant 1, 3, ou 8 minutes, suivant l'importance de
recalcule de tables BGP.

On pense fixer le problème BGP avec les routeurs spécifique qui
ne vont faire que ça. Route reflector. Normalement on devait recevoir
le matériel ce mois-ci mais la commande a été mal enregistrée entre
le distributeur et le fabriquant ... et on va le recevoir au mieux fin
septembre ... On a décidé de ne plus attendre cette livraison, et
mettre en place une solution ce week-end.

Mais on aura toujours le problème de MAC. On a donc décidé de
casser les configurations VSS et repartir sur ce qui a toujours
bien fonctionner: le routeur dans un seul châssis. Nous avons
un peu moins de 30 routeurs dans la configuration mono châssis
qui ne posent aucun problème. C'est uniquement dans la configuration
double châssis que nous avons de problèmes. On va donc casser les
châssis.

Donc à partir de la semaine passée, nous allons effectuer les
modifications sur les VSS afin de passer sur une configuration basée
sur un seul châssis.

Nous allons l'effectuer en 4 étapes:
- tous les liens du datacentre connectés sur le châssis 2 seront
reconnectés sur le châssis 1. pas de coupure dans le service
puisque tout fonctionnera sur le châssis 1.
- tous les liens vers internet connectés sur le châssis 2 seront
reconnectés sur le châssis 1. pas de coupure dans le service,
puisque tout fonctionnera sur le châssis 1.
- coupure électrique du châssis 2. pas de coupure dans le service
puisque le châssis 2 ne sera plus utilisé.
- changement de la configuration du châssis 1 vers la version
mono châssis. là il faudra qu'on redémarre le routeur en hard.
et donc il faudra compter 15 minutes de coupure dans le service.
on va l'effectuer à 4 heures du matin fin de la semaine prochaine
si on avance bien.

On va attaquer d'abord le vss-2 qui pose le plus de problèmes.

Normalement, au maximum à l'étape 4, on n'aura plus de problèmes
BGP. Il se peut qu'à travers les configurations sur 2 châssis ce
problèmes là puisse être résolu dés l'étape 3 voir 2, car tout
fonctionnera sur 1 seul châssis. Mais on n'est pas sûr. En tout
cas à la fin de l'étape 4 ça sera fixé.

Et comme le BGP sera fixé, on pense qu'il est probable que le
problèmes de MAC le soit aussi. Si le BGP ne fonctionne pas
bien en double châssis, alors peut être d'autres processes ne
fonctionnent pas non plus bien en double châssis ? On va voir
ça aussi.

On regrette toutes les petites coupures que les clients de
Roubaix 2 ont subit dernièrement qui sont principalement dû
aux problèmes décrites ici. Le mauvais choix dans le matériel
qu'on assume entièrement. On pensait que le fabricant allait
régler le problèmes de CPU mais d'après lui c'est normal. Ce
matériel là est donc incompatible avec nos besoins. On va le
changer. Nous avons mal gère la situation et on aurait dû
ne pas demander de l'aide du fabriquant mais agir de suite
pour trouver une autre solution tout simplement. Erreur dans
la gestion de problème.

Pour continuer dans la transparence, vous avez peut être dû
remarquer les problèmes sur London, Amsterdam et Frankfurt
il y a 14 jours environ. Nous avons en effet ajouté de liens
de sécurisation il y a 14 jours. Entre London/Amsterdam et
Paris/Frankfurt. De gros investissements très lourd qui ont
été décidés pour rendre la backbone totalement secure et 100%
disponible même en cas de problèmes sur la fibre optique.
Le fait d'ajouter ces liens là sur les routeurs, ceci a provoqué
la saturation de la RAM disponible de routeurs et le crash de
London. Ce qui a entraîné Amsterdam et Frankfurt dans la foulé
pour les mêmes raisons. Qui dit crash de routeurs, dit recalcule
de BGP et donc 100% de CPU sur les vss ... voilà pourquoi ces
crashs ont eu la conséquence sur le service à Roubaix 2 :(
Nous avons fixé le problème en désactivant le MPLS qui n'est pas
nécessaire mais qui prend 20% de la RAM. Depuis c'est stable.

On pensait changer tous les routeurs pendant les vacances,
mais le matériel qu'on a souhaité mettre en place n'est pas
disponible et ce qui est disponible ne fonctionne pas. Nous
avons en effet reçu le nouveau Cisco Nexus 7000 et le BGP
ne marche pas mais génère des messages d'erreurs ... Matériel
neuf et voilà ... Mauvais choix de matériel encore. Et donc
de grosses remises en cause en perspective ... Par contre
ça va génère aussi du retard dans les changements de routeurs
prévus. Alors on sert les mains en ce moment de tous les
fabriquant du marché pour voir ce qu'on va mettre en place
à la place de ce que nous avons prévu. Du boulot imprévu
qui provoquera de retard sur d'autres projets ...

Bref ...

Je pense qu'on ne peut pas être plus transparent sur les
derniers évènements.

Amicalement
Octave

Date:  Wednesday, 22 September 2010, 01:19AM
Reason for closing:  Done
Comment by OVH - Monday, 09 August 2010, 14:50PM

Nous commencons les travaux au niveau du vss-2. Les uplinks de chaque vlan sont progressivement migrés du chassis #2 vers le chassis #1.


Comment by OVH - Monday, 09 August 2010, 17:13PM

Nous avons déplacé un peu plus de la moitié des uplinks du chassis #2 sur le chassis #1 ce qui déséquilibre le trafic sur les uplinks. Nous commencons donc la migration de certains 10G du chassis #2 vers #1 (fra, ams, rbx-97).


Comment by OVH - Tuesday, 10 August 2010, 11:36AM

La migration de port 1G et 10G est terminé. Nous sommes prêts à couper le chassis 2.


Comment by OVH - Tuesday, 10 August 2010, 11:38AM

Toujours le probleme de CPU sur l'ARP Input

vss-2-6k#sh proc cpu | i \ ARP Input
11 1302640401311514886 99 8.55% 9.33% 9.74% 0 ARP Input
11 1302642001311514965 99 8.77% 9.28% 9.73% 0 ARP Input
11 1302655801311515094 99 24.14% 10.47% 9.97% 0 ARP Input
11 1302662441311515330 99 10.87% 10.51% 9.98% 0 ARP Input
11 1302667641311515581 99 7.03% 10.23% 9.93% 0 ARP Input
11 1302673601311515785 99 8.47% 10.09% 9.91% 0 ARP Input
11 1302680561311516086 99 10.39% 10.11% 9.92% 0 ARP Input
11 1302688121311516406 99 12.03% 10.27% 9.95% 0 ARP Input
11 1302696081311516695 99 9.83% 10.23% 9.95% 0 ARP Input


Comment by OVH - Tuesday, 10 August 2010, 23:40PM

Nous allons déconnecter définitivement les liens "virtual link" entre les 2 chassis de vss-2.


Comment by OVH - Wednesday, 11 August 2010, 10:52AM

Le split de vss-2 a été effectué. Il a l'air de mieux
fonctionner et prend moins de CPU.

http://travaux.ovh.com/?do=details&id=4461


Comment by OVH - Thursday, 26 August 2010, 16:44PM

Nous allons effectuer la même opération sur vss-1. Nous commencons à préparer le terrain avec le déplacement des uplinks de switchs du chassis #2 vers le chassis #1.


Comment by OVH - Friday, 27 August 2010, 15:33PM

Nous avons basculé 1x10G vers Francfort et 1x10G vers Amsterdam du chassis #2 vers le chassis #1 afin de rééquilibrer le trafic entre les 2 chassis. Nous poursuivons les basculements d'uplinks de switchs de baie.


Comment by OVH - Tuesday, 31 August 2010, 12:25PM

Les basculements des uplinks des switchs de baies sont terminés. Nous devons maintenant procéder au renommage des ports-channels car en mode standalone seuls les numéros < 255 sont utilisables.


Comment by OVH - Tuesday, 31 August 2010, 15:49PM

Nous déplacons le lien de backup vss-1 <> bru-1 sur le vss-2 afin de récupérer l'un des ports 10G sur le vss-1.


Comment by OVH - Wednesday, 01 September 2010, 16:19PM

Ce soir, à partir de minuit, nous programmons la même opération de split sur vss-1 que celle effectuée le 10/08 sur vss-2. Nous prévoyons environ 30min de coupure du traffic pour les réseaux routés par vss-1-6k.


Comment by OVH - Thursday, 02 September 2010, 00:32AM

Nous commencons la maintenance. Le trafic des réseaux routés par vss-1 sera indisponible ainsi que celui des ip failovers vers les HG2010 (mais pour le HG2010 le trafic s'écoulera normalement vers les ip principales)? Nous terminons actuellement les préparatifs. La coupure proprement dites devrait survenir d'ici 30min environ.


Comment by OVH - Thursday, 02 September 2010, 00:58AM

Nous avons coupé électriquement le chassis #2 de vss-1-6k. Nous nous préparons au redémarrage du chassis #1


Comment by OVH - Thursday, 02 September 2010, 01:24AM

Nous redémarrons les chassis #1.


Comment by OVH - Thursday, 02 September 2010, 01:55AM

Le routeur n'a pas redémarré en mode standalone à cause de résidus de commandes vss dans la config (les ports peer-links). Il a donc booté en mode vss single chassis et non standalone. Nous avons nettoyé complètement la config de ces ports et rechargé la conf via une autre chassis sur la carte CF. Nous allons rebooter à nouveau le chassis.


Comment by OVH - Thursday, 02 September 2010, 02:40AM

Impossible de redémarrer le routeur en mode standalone. Nous redémarrons en mode vss pour l'instant.


Comment by OVH - Thursday, 02 September 2010, 03:29AM

Nous fonctionnons maintenant en mono-chassis sur vss-1 mais toujours donc en mode vss. Plus de downtime à prévoir pour cette nuit. Nous allons nous pencher sur la config afin de déterminer pourquoi le routeur détecte un mode vss au démarrage et reprogrammer une intervention pour le basculement. Cette nouvelle intervention aura probablement lieu la nuit prochaine, a confirmer. Nous nous excusons pour ce downtime plus long que prévu.


Comment by OVH - Thursday, 02 September 2010, 03:44AM

Bon on va reprendre.


Comment by OVH - Thursday, 02 September 2010, 04:39AM

C'et reparti


Comment by OVH - Thursday, 02 September 2010, 04:48AM

ça a booté
*Sep 2 02:34:19.707: %SYS-SP-6-BOOTTIME: Time taken to reboot after reload = 340 seconds

le routeur est en train de detecter les cartes et va
remonter tous les liens.


Comment by OVH - Thursday, 02 September 2010, 04:57AM

Tout est up. Il faut environ 20 minutes au routeur pour revenir
et tout faire booter.


Comment by OVH - Thursday, 02 September 2010, 05:07AM

On a activé un meilleur load balancing L2

vss-1-6k(config)#port-channel load-balance src-dst-mixed-ip-port


Comment by OVH - Thursday, 02 September 2010, 05:09AM

Sep 2 04:08:58 GMT: %L2_AGING-SP-4-ENTRY_DNLDFAIL: Slot 8: Download entries failed, reason EARL_ICC_ERR
Sep 2 04:08:58 GMT: %ONLINE-SP-6-LCC_CONFIG_FAIL: Module 8. LCC Client UNSOLICITED SCP failed to configure at 41636D60
Sep 2 04:08:58 GMT: %ONLINE-SP-6-INITFAIL: Module 8: Failed to configure forwarding
sm(cygnus_oir_bay slot8), running yes, state wait_til_online
Last transition recorded: (disabled)-> disabled2 (restart)-> wait_til_disabled (timer)-> may_be_occupied (timer)-> occupied (known)-> can_power_on (yes_power)-> powered_on (real_power_on)-> check_power_on (timer)-> check_power_on (power_on_ok)-> wait_til_online (reset_timer_online)-> wait_til_online
Sep 2 04:08:58 GMT: %C6KPWR-SP-4-DISABLED: power to module in slot 8 set off (Module Failed SCP dnld)


Comment by OVH - Thursday, 02 September 2010, 06:01AM

la carte a booté.

les IP FO HG sont up aussi.

bon on va en rester là avec les catastrophes.


Comment by OVH - Wednesday, 08 September 2010, 15:07PM

Nous avons commencé la migration des uplinks des switchs clients vers le chassis #1 de vss-3.


Comment by OVH - Tuesday, 21 September 2010, 18:25PM

Nous effectuerons cette nuit la dernière opération de split vss sur le vss-3. Comme pour les interventions sur vss-1 et 2, démarrage à partir de minuit.


Comment by OVH - Tuesday, 21 September 2010, 20:52PM

nous allons spliter le dernier vss en configuration
standalone. ça va prendre 30 minutes à partir de
minuit.


Comment by OVH - Tuesday, 21 September 2010, 23:33PM

Nous coupons le chassis #2.


Comment by OVH - Wednesday, 22 September 2010, 00:24AM

Nous redémarrons maintenant le chassis #1 en mode standalone. Le traffic sera coupé sur Roubaix3 pendant la durée du reboot


Comment by OVH - Wednesday, 22 September 2010, 00:26AM

go


Comment by OVH - Wednesday, 22 September 2010, 00:43AM

Le chassis est de nouveau en ligne en mode standalone. Le trafic est rétabli sur Roubaix3 (environ 10min de noir).


Comment by OVH - Wednesday, 22 September 2010, 01:19AM

on a fini avec les vss :)