OVHcloud Web Hosting Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
Class 4
Incident
Report for Web Cloud
Resolved
Nous rencontrons actuellement des difficultés dans l'établissement de certains appels entrants concernant un équipement en particulier.
L'équipement en question a été redémarré.
Nous surveillons l'activité.
Update(s):
Date: 2014-06-14 16:12:45 UTC
La suite du task est sur
http://travaux.ovh.net/?do=details&id=10957
Date: 2014-06-14 10:29:28 UTC
Le plan de réallocation est défini.
Nous démarrons la réorganisation des circuits un par un pour isoler les inputs/outputs.
Les circuits sont bloqués avant migration, il n'y a pas d'impact sur les appels en cours.
Date: 2014-06-13 16:59:44 UTC
l'état actuel:
- l'infra passe par le VAC qui nettoie quelques
packets pas catholiques
- ce week-end on va basculer tous les circuits un par
un pour les réallouer pour un équipement. On a
3 input/output avec FT et 3 input/output avec
sfr. On va les isoler l'un des autres
- cirpack continue de regarder dans les dumps
quel packet pose le probleme
- on regarde avec un autre équipemetier pourqu'il
nous fixe un bug sur son boitier. Il doit livrer
les patchs dans quelques heures. Si c'est le cas
on va tester le basculement d'une interco dessus et
voir si c'est stable. Si c'est stable, on va le
pousser pour déterrer 2 autres boitiers demain
ou dimanche puis on basculera les 3 sfr sur 3 boitiers
Date: 2014-06-13 13:56:45 UTC
Le flux de voix passe correctement à travers le vac.
Date: 2014-06-13 13:52:38 UTC
Nous passons c5b derrière le vac.
Date: 2014-06-13 13:46:11 UTC
Nous allons aspirer l'ip d'un relai de voix via le vac afin de surveiller le traffic.
Date: 2014-06-12 16:42:31 UTC
Nous avons retiré le dernier patch des infrastructures class 5 qui avait été testé depuis plusieurs mois sur c5c et mise en place ce week-end sur c5a et c5b.
Celui-ci résoud des problèmes de boucle d'appels mais il semble qu'il ne libère pas bien les ressources et provoque des surcharges.
Depuis le retrait vers 16h30 nous n'avons pas détecté de congestion et donc de pertes d'appels. Il faut valider cette hypothèse dans la journée de demain.
En parallèle nous mettons ce soir en place une nouvelle infrastructure class 4 pour les interconnections, dans le but de réduire la charge et diviser l'impact
d'un problème éventuel. Tout les détails de l’intervention seront suivi dans une nouvelle tâche.
Date: 2014-06-12 13:31:30 UTC
Nous avons de nouveaux des congestions sur les cartes d’interconnexions.
Nous allons mettre en place un autre class4 cette nuit et séparer les interconnections entrantes et sortantes.
Date: 2014-06-12 12:36:02 UTC
La situation semble se stabiliser. Les logs et les tickets d'appels
sont correct et ne remontent pas les soucis de ce matin et d'hier.
Les cartes communiquent correctement avec le controleur.
Nous poursuivons nos observations sur l'infrastructure.
Date: 2014-06-12 12:05:44 UTC
La nouvelle carte est installé.
Nous la remettons en service.
Date: 2014-06-12 11:54:45 UTC
Nous démarrons le remplacement de la carte.
Date: 2014-06-12 10:56:36 UTC
Une carte a crashé et ne remonte pas.
Les 2 nouvelles cartes commandées ce matin vont arriver d'ici quelques minutes.
Nous passerons donc de 2 cartes (hier matin) à 8 pour gérer les appels entrants et sortants de notre réseaux téléphoniques.
Date: 2014-06-12 10:18:41 UTC
Tous les circuits remontent, les premiers sont revenus en moins de 2 minutes.
Date: 2014-06-12 10:10:19 UTC
Avant d'effectuer le basculement, par précaution, nous avons rebooter l'équipement de secours.
Une fois que ce sera fait, nous allons vérifier son bon comportement et enfin lancer la bascule.
Date: 2014-06-12 10:05:37 UTC
Nous allons commencer la bascule sur l'équipement de secours.
La manipulation devrait prendre 3 minutes.
Date: 2014-06-12 09:41:36 UTC
Nous vérifions aussi la totalité des branchements de l'infrastructure Voip dans le datacentre.
Date: 2014-06-12 09:31:34 UTC
La carte en cause a été bloqué, mais les autres cartes saturent comme hier.
Des ressources sont utilisées alors qu'elles ne correspondent à aucun appel en cours.
Plusieurs pistes sont en cours d'étude par la cellule Cirpack/OVH.
Les actions actuellement en cours :
- cartes en cours de transit pour remplacer celle qui reboot aléatoirement
- basculement des infrastructures sur les équipements redondants prévu vers midi dans le creux d'appel : le but est d'exclure un défaut possible sur ces équipements principaux
- analyse du traffic IP
Date: 2014-06-12 08:56:46 UTC
Une des nouvelles cartes installées cette nuit montrent des instabilités.
Avec Cirpack nous sommes en train de bloquer la carte et préparer son remplacement au plus vite, délai estimé de 3h max.
Date: 2014-06-12 00:10:01 UTC
la migration de tous les circuits est terminée
les ressources de chaque carte sera utilisé uniformément.
Date: 2014-06-11 23:24:36 UTC
la moitié des circuits sortants a été déplacé.
nous terminons la deuxieme moitié.
Date: 2014-06-11 22:46:03 UTC
les circuits sur les appels entrants sont équilibrés sur toutes les cartes.
nous avancons sur les circuits d'appels sortants.
Date: 2014-06-11 21:51:50 UTC
le processus de migration est très long.
il faut refaire l'acheminement complet de l'E1 et vérifier circuit apres circuit.
nous sommes à 20% de la migration.
Date: 2014-06-11 20:49:21 UTC
Les cartes sont initialisés et configurés.
Elles sont prêtes à recevoir les E1.
Date: 2014-06-11 19:54:40 UTC
les fibres sont tirés dans le datacentres.
les nouvelles cartes sont allumés. nous démarrons la configuration et le déplacement des liens.
Date: 2014-06-11 19:47:50 UTC
nous démarrons les opérations de migration
Date: 2014-06-11 14:12:52 UTC
Le remplacement de la carte n'a pas corrigé le problème.
Nous recherchons activement avec le constructeur la source du problème : une surconsommation des ressources qui ne corresponde pas aux nombres d'appels simultanés en cours.
En parallèle nous préparons de 2 nouvelles cartes pour baisser le niveau d'utilisation cette carte. Ces cartes sont déjà dans le datacenter en cours de raccordement.
L'installation se fera durant la soirée.
Date: 2014-06-11 12:31:00 UTC
Nous avons recu les nouvelles cartes.
La carte qui posait le plus de probleme ce matin vient encore de poser probleme.
Nous la remplacons.
Date: 2014-06-11 12:06:43 UTC
Les indicateurs posaient par nous et par notre fournisseur sur la nouvelle interco ne montre pas de defaut sur les nouveaux liens.
Nous continuons notre surveillance sur le bon acheminement des appels.
Date: 2014-06-11 10:27:21 UTC
Les tests de circuits sont terminées.
Nous avons ouvert le traffic vers la nouvelle interco.
Nous surveillons l'évolution de la situation.
Date: 2014-06-11 10:19:44 UTC
Pour une raison inconnue, nos passerelles de conversion entre les réseaux ip et telecom ne parviennent pas à acheminer toutes les demandes d'appels.
Actuellement, la nouvelle interco est en train d'être montée, elle devrait être finalisée avant 14h00.
Date: 2014-06-11 09:26:49 UTC
La carte est en cours d'acheminement.
Dès réception elle sera mise en place dans les plus bref délais.
Date: 2014-06-11 08:39:00 UTC
La tâche travaux actuelle est due à un soucis avec une carte de sortie. L'effet de bord constaté est que la carte de conversions est saturée.
Elle n'arrive pas à utiliser ses ressources de conversion, de ce fait, certains appels extérieurs au réseau téléphonique OVH n'aboutissent pas.
À la suite du problème d'hier, une nouvelle carte a été redémarrée ce matin. Nous travaillons activement à la résolution de ce problème.
Nous attendions jusqu'à aujourd'hui le retour de SFR pour la mise en place de la nouvelle interco (la mise en place a commencé en janvier).
Suite au problème actuel, l'incident est passé en priorité chez eux, le but est de délester les cartes de sortie.
Nous devrions avoir des nouvelles d'eux entre la fin de matinée et le début d'après midi.
Date: 2014-06-11 08:13:33 UTC
La carte de conversion a un soucis. Nous la remplacons des que possible.
Date: 2014-06-11 07:56:28 UTC
La carte est a nouveau stabilisé.
Date: 2014-06-11 07:35:30 UTC
Nous redémarrons la carte completement.
La relance des applications n'a pas suffit a fixer le problème.
Date: 2014-06-11 07:26:09 UTC
Une de nos passerelles de conversion entre le réseau IP et le réseau Telecom
a un rencontré une surcharge. Nous investiguons.
Date: 2014-06-10 14:55:12 UTC
Un de nos fournisseurs a réinitialisé des circuits de nos interconnexions d'une manière inhabituelle.
Cela a provoqué un disfonctionnement dans une de nos cartes.
Le problème n'est pas systématique, nous investiguons pour contenir le problème pour redémarrer la carte.
Date: 2014-06-10 14:43:18 UTC
Nous observons une congestion mettant en erreur certains appels (entrants et sortants).
Nous investiguons la cause avec le constructeur.
Les appels établis ne sont pas impactés.
Date: 2014-06-05 14:06:42 UTC
L'activité est normale.
Nous avons détecté un nombre d'appel en erreur limité mais supérieur à l'habitude pour le nombre d'appel en cours sur cette équipement à l'aide du monitoring actif.
L'équipement a été isolé par sécurité, les autres équipements ont pris le relai. Il n'y a plus de détection d'erreur particulière.
Les traces sont en cours d'analyse pour déterminer s'il s'agit d'un problème isolé concernant des appels particuliers, ce qui semble être le cas.
L'équipement en question a été redémarré.
Nous surveillons l'activité.
Update(s):
Date: 2014-06-14 16:12:45 UTC
La suite du task est sur
http://travaux.ovh.net/?do=details&id=10957
Date: 2014-06-14 10:29:28 UTC
Le plan de réallocation est défini.
Nous démarrons la réorganisation des circuits un par un pour isoler les inputs/outputs.
Les circuits sont bloqués avant migration, il n'y a pas d'impact sur les appels en cours.
Date: 2014-06-13 16:59:44 UTC
l'état actuel:
- l'infra passe par le VAC qui nettoie quelques
packets pas catholiques
- ce week-end on va basculer tous les circuits un par
un pour les réallouer pour un équipement. On a
3 input/output avec FT et 3 input/output avec
sfr. On va les isoler l'un des autres
- cirpack continue de regarder dans les dumps
quel packet pose le probleme
- on regarde avec un autre équipemetier pourqu'il
nous fixe un bug sur son boitier. Il doit livrer
les patchs dans quelques heures. Si c'est le cas
on va tester le basculement d'une interco dessus et
voir si c'est stable. Si c'est stable, on va le
pousser pour déterrer 2 autres boitiers demain
ou dimanche puis on basculera les 3 sfr sur 3 boitiers
Date: 2014-06-13 13:56:45 UTC
Le flux de voix passe correctement à travers le vac.
Date: 2014-06-13 13:52:38 UTC
Nous passons c5b derrière le vac.
Date: 2014-06-13 13:46:11 UTC
Nous allons aspirer l'ip d'un relai de voix via le vac afin de surveiller le traffic.
Date: 2014-06-12 16:42:31 UTC
Nous avons retiré le dernier patch des infrastructures class 5 qui avait été testé depuis plusieurs mois sur c5c et mise en place ce week-end sur c5a et c5b.
Celui-ci résoud des problèmes de boucle d'appels mais il semble qu'il ne libère pas bien les ressources et provoque des surcharges.
Depuis le retrait vers 16h30 nous n'avons pas détecté de congestion et donc de pertes d'appels. Il faut valider cette hypothèse dans la journée de demain.
En parallèle nous mettons ce soir en place une nouvelle infrastructure class 4 pour les interconnections, dans le but de réduire la charge et diviser l'impact
d'un problème éventuel. Tout les détails de l’intervention seront suivi dans une nouvelle tâche.
Date: 2014-06-12 13:31:30 UTC
Nous avons de nouveaux des congestions sur les cartes d’interconnexions.
Nous allons mettre en place un autre class4 cette nuit et séparer les interconnections entrantes et sortantes.
Date: 2014-06-12 12:36:02 UTC
La situation semble se stabiliser. Les logs et les tickets d'appels
sont correct et ne remontent pas les soucis de ce matin et d'hier.
Les cartes communiquent correctement avec le controleur.
Nous poursuivons nos observations sur l'infrastructure.
Date: 2014-06-12 12:05:44 UTC
La nouvelle carte est installé.
Nous la remettons en service.
Date: 2014-06-12 11:54:45 UTC
Nous démarrons le remplacement de la carte.
Date: 2014-06-12 10:56:36 UTC
Une carte a crashé et ne remonte pas.
Les 2 nouvelles cartes commandées ce matin vont arriver d'ici quelques minutes.
Nous passerons donc de 2 cartes (hier matin) à 8 pour gérer les appels entrants et sortants de notre réseaux téléphoniques.
Date: 2014-06-12 10:18:41 UTC
Tous les circuits remontent, les premiers sont revenus en moins de 2 minutes.
Date: 2014-06-12 10:10:19 UTC
Avant d'effectuer le basculement, par précaution, nous avons rebooter l'équipement de secours.
Une fois que ce sera fait, nous allons vérifier son bon comportement et enfin lancer la bascule.
Date: 2014-06-12 10:05:37 UTC
Nous allons commencer la bascule sur l'équipement de secours.
La manipulation devrait prendre 3 minutes.
Date: 2014-06-12 09:41:36 UTC
Nous vérifions aussi la totalité des branchements de l'infrastructure Voip dans le datacentre.
Date: 2014-06-12 09:31:34 UTC
La carte en cause a été bloqué, mais les autres cartes saturent comme hier.
Des ressources sont utilisées alors qu'elles ne correspondent à aucun appel en cours.
Plusieurs pistes sont en cours d'étude par la cellule Cirpack/OVH.
Les actions actuellement en cours :
- cartes en cours de transit pour remplacer celle qui reboot aléatoirement
- basculement des infrastructures sur les équipements redondants prévu vers midi dans le creux d'appel : le but est d'exclure un défaut possible sur ces équipements principaux
- analyse du traffic IP
Date: 2014-06-12 08:56:46 UTC
Une des nouvelles cartes installées cette nuit montrent des instabilités.
Avec Cirpack nous sommes en train de bloquer la carte et préparer son remplacement au plus vite, délai estimé de 3h max.
Date: 2014-06-12 00:10:01 UTC
la migration de tous les circuits est terminée
les ressources de chaque carte sera utilisé uniformément.
Date: 2014-06-11 23:24:36 UTC
la moitié des circuits sortants a été déplacé.
nous terminons la deuxieme moitié.
Date: 2014-06-11 22:46:03 UTC
les circuits sur les appels entrants sont équilibrés sur toutes les cartes.
nous avancons sur les circuits d'appels sortants.
Date: 2014-06-11 21:51:50 UTC
le processus de migration est très long.
il faut refaire l'acheminement complet de l'E1 et vérifier circuit apres circuit.
nous sommes à 20% de la migration.
Date: 2014-06-11 20:49:21 UTC
Les cartes sont initialisés et configurés.
Elles sont prêtes à recevoir les E1.
Date: 2014-06-11 19:54:40 UTC
les fibres sont tirés dans le datacentres.
les nouvelles cartes sont allumés. nous démarrons la configuration et le déplacement des liens.
Date: 2014-06-11 19:47:50 UTC
nous démarrons les opérations de migration
Date: 2014-06-11 14:12:52 UTC
Le remplacement de la carte n'a pas corrigé le problème.
Nous recherchons activement avec le constructeur la source du problème : une surconsommation des ressources qui ne corresponde pas aux nombres d'appels simultanés en cours.
En parallèle nous préparons de 2 nouvelles cartes pour baisser le niveau d'utilisation cette carte. Ces cartes sont déjà dans le datacenter en cours de raccordement.
L'installation se fera durant la soirée.
Date: 2014-06-11 12:31:00 UTC
Nous avons recu les nouvelles cartes.
La carte qui posait le plus de probleme ce matin vient encore de poser probleme.
Nous la remplacons.
Date: 2014-06-11 12:06:43 UTC
Les indicateurs posaient par nous et par notre fournisseur sur la nouvelle interco ne montre pas de defaut sur les nouveaux liens.
Nous continuons notre surveillance sur le bon acheminement des appels.
Date: 2014-06-11 10:27:21 UTC
Les tests de circuits sont terminées.
Nous avons ouvert le traffic vers la nouvelle interco.
Nous surveillons l'évolution de la situation.
Date: 2014-06-11 10:19:44 UTC
Pour une raison inconnue, nos passerelles de conversion entre les réseaux ip et telecom ne parviennent pas à acheminer toutes les demandes d'appels.
Actuellement, la nouvelle interco est en train d'être montée, elle devrait être finalisée avant 14h00.
Date: 2014-06-11 09:26:49 UTC
La carte est en cours d'acheminement.
Dès réception elle sera mise en place dans les plus bref délais.
Date: 2014-06-11 08:39:00 UTC
La tâche travaux actuelle est due à un soucis avec une carte de sortie. L'effet de bord constaté est que la carte de conversions est saturée.
Elle n'arrive pas à utiliser ses ressources de conversion, de ce fait, certains appels extérieurs au réseau téléphonique OVH n'aboutissent pas.
À la suite du problème d'hier, une nouvelle carte a été redémarrée ce matin. Nous travaillons activement à la résolution de ce problème.
Nous attendions jusqu'à aujourd'hui le retour de SFR pour la mise en place de la nouvelle interco (la mise en place a commencé en janvier).
Suite au problème actuel, l'incident est passé en priorité chez eux, le but est de délester les cartes de sortie.
Nous devrions avoir des nouvelles d'eux entre la fin de matinée et le début d'après midi.
Date: 2014-06-11 08:13:33 UTC
La carte de conversion a un soucis. Nous la remplacons des que possible.
Date: 2014-06-11 07:56:28 UTC
La carte est a nouveau stabilisé.
Date: 2014-06-11 07:35:30 UTC
Nous redémarrons la carte completement.
La relance des applications n'a pas suffit a fixer le problème.
Date: 2014-06-11 07:26:09 UTC
Une de nos passerelles de conversion entre le réseau IP et le réseau Telecom
a un rencontré une surcharge. Nous investiguons.
Date: 2014-06-10 14:55:12 UTC
Un de nos fournisseurs a réinitialisé des circuits de nos interconnexions d'une manière inhabituelle.
Cela a provoqué un disfonctionnement dans une de nos cartes.
Le problème n'est pas systématique, nous investiguons pour contenir le problème pour redémarrer la carte.
Date: 2014-06-10 14:43:18 UTC
Nous observons une congestion mettant en erreur certains appels (entrants et sortants).
Nous investiguons la cause avec le constructeur.
Les appels établis ne sont pas impactés.
Date: 2014-06-05 14:06:42 UTC
L'activité est normale.
Nous avons détecté un nombre d'appel en erreur limité mais supérieur à l'habitude pour le nombre d'appel en cours sur cette équipement à l'aide du monitoring actif.
L'équipement a été isolé par sécurité, les autres équipements ont pris le relai. Il n'y a plus de détection d'erreur particulière.
Les traces sont en cours d'analyse pour déterminer s'il s'agit d'un problème isolé concernant des appels particuliers, ce qui semble être le cas.
This incident affected: VoIP || Core Network.