Partager sur Facebook
Partager sur Twitter
Partager sur LinkedIn
Référencer cette pageType de tâche: Maintenance
Catégorie: 240plan
Etat: Finie
Malgré les upgrades hardware nous détectons toujours des ralentissements sur ce serveur.
Pendant les nuits de mardi/mercredi et mercredi/jeudi nous allons déplacer certains comptes sur un autre filer pour répartir la charge.
Une coupure de quelques secondes par site déplacé est à prévoir.
Les sites hébergés sur /homez.342 sont impactés.
Commentaires:
Date: Wed, 25 Aug 2010 09:55:31 +0200
Les migrations sont toujours en cours.
Les temps de réponse du serveur s'améliorent.
En milieu/fin de semaine prochaine on devrait avoir des temps de réponse optimums.
Date: Wed, 01 Sep 2010 10:16:52 +0200
Les migrations sont terminées.
Type de tâche: Incident
Catégorie: tous les start
Etat: Finie
Le serveur a redémarré, nous intervenons.
Commentaires:
Date: Thu, 26 Aug 2010 11:53:52 +0200
Le service est UP.
Nous avons un doute sur la carte mère, le serveur sera remplacé par un spare dans la nuit de samedi à dimanche.
Date: Mon, 30 Aug 2010 12:40:14 +0200
L'intervention a été reportée au matin du 31/08
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
L'ancien accès ftp du cluster007 (anciennement xxlplan) est actuellement indisponible. Une intervention est en cours.
Le nouvel accès reste fonctionnel en utilisant ftp.cluster007.ovh.net comme nom de serveur FTP
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
Le serveur mysql5-19.bdb est actuellement indisponible. Une intervention est en cours.
Commentaires:
Date: Sat, 28 Aug 2010 09:04:56 +0200
Le serveur n'arrive pas à fonctionner avec les deux CPUs, il doit s'agir d'un problème matériel au niveau de la carte mère. Nous remplaçons le serveur par un spare.
Type de tâche: Incident
Catégorie: 1000gp
Etat: Finie
Le serveur a freezé, il ne redémarre pas.
Nous remplaçons le CPU et préparons un serveur de spare en parallèle.
Commentaires:
Date: Thu, 26 Aug 2010 16:32:43 +0200
Nous basculons sur le serveur de spare.
Date: Thu, 26 Aug 2010 16:45:30 +0200
Le spare est opérationnel , retour à la normale.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Finie
Nous mettons à jour le noyau.
Commentaires:
Date: Tue, 08 Jun 2010 15:44:01 +0200
cluster012 et cluster014 faits. cluster010 en cours.
Type de tâche: Incident
Catégorie: logs
Etat: Finie
La machine gérant les logs des domaines commençant par la lettre U était freezée. Nous l'avons redémarrée. Tout est rentré dans l'ordre.
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: Finie
Nous remplaçons le serveur mysql5-1.start par une nouvelle machine. Une coupure de 5 minutes est à prévoir.
Commentaires:
Date: Tue, 24 Aug 2010 01:36:46 +0200
Nous coupons le serveur pour finaliser le basculement
Type de tâche: Maintenance
Catégorie: 90plan
Etat: Finie
Nous allons intervenir sur le serveur pour une opération de maintenance.
Les sites hébergés sur /homez.44 seront impactés pendant 3 à 5 minutes.
Type de tâche: Incident
Catégorie: tous les start
Etat: Finie
Le serveur ne répond plus, nous intervenons.
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
Le filer /homez.116 est actuellement indisponible.
Une intervention est en cours
Commentaires:
Date: Tue, 17 Aug 2010 14:06:57 +0200
Le service est à nouveau disponible.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Finie
Nous allons mettre a jour la version de phpmyadmin présente sur https://phpmyadmin.ovh.net, pour passer à la version 3.3.5
Malheureusement, cette nouvelle version n'est plus compatible avec les servers MySQL4.
Une interface compatible restera cependant disponible a l'adresse suivante : https://phpmyadmin.ovh.net/old/, pour les clients utilisant encore les serveurs MySQL4
Le basculement se fera de manière transparente, des déconnexions seront cependant a prévoir au moment du basculement.
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: En cours
Nous effectuerons une maintenance de l'infra mutualisée au niveau réseau ce 06/08 à 01:00 CEST (durée prévue: 1h environ). La plate-forme d'hébergement mutualisé sera indisponible pendant quelques minutes pendant la durée de la maintenance (environ 4 à 5min).
Commentaires:
Date: Fri, 06 Aug 2010 01:05:05 +0200
Nous commencons les travaux. Les switchs p19-61/62 et p19-65/66 vont être successivement redémarrés pour être mis à jour.
Date: Fri, 06 Aug 2010 01:47:21 +0200
Suite à un bug cisco qui bloque l'upgrade (message d'erreur incohérent par rapport à la place dispo sur la bootflash), nous avons du redémaré p19-65 (sur la même version). Suite à ce reboot, 7 ports de l'un des fex se sont mis en erreur. Un spare de fex 2248 est prêt à démarrer sur ce couple de chassis. Nous devons donc terminer l'upgrade de la paire pour le mettre en ligne (le 2248 n'est supporté que dans la nouvelle version de nx-os).
msg d'erreur:
Version Compatibility check failed. Return code 0x40930062 (free space in the filesystem is below threshold).
Date: Fri, 06 Aug 2010 01:48:25 +0200
reload sur même version du p19-66 en raison d'une même bug en cours. Nous allons ensuite pouvoir commencer l'upgrade proprement dit.
Date: Fri, 06 Aug 2010 01:51:13 +0200
p19-65 en cours d'upgrade
Date: Fri, 06 Aug 2010 02:08:03 +0200
correction, p19-66 a été upgradé. Nous reloadons les fex sur ce chassis.
Date: Fri, 06 Aug 2010 02:25:52 +0200
p19-65 maintenant en cours d'upgrade
Date: Fri, 06 Aug 2010 03:16:50 +0200
Le couple p19-65/66 est maintenant à jour mais les fexs sont passés off-line après le reboot de p19-65 dans la nouvelle version et réactivation des ports-channels. A ce moment, pour une raison inconnue, la config des ports des fexs s'est réinitialisé côté p19-65 ce qui provoque un mismatch entre la conf des 2 chassis. Même en recoupant les uplinks des fexs côté p19-65, les ports ne remontent pas sur p19-66. Nous avons donc redescendu la conf de tous les ports fex sur p19-65 et les ports sont remontés.
Nous devons revoir le protocole de migration pour p19-61/62 qui comportent 6 fexs. Nous reportons donc les upgrades sur ces switchs à une date ultérieure.
Nous rencontrons également des difficultés à monter le nouveau fex 2248.
Date: Fri, 06 Aug 2010 03:24:05 +0200
nous avons résolu les pbs d'uplinks sur le 2248 mais le fex ne monte pas:
p19-66-n5# 2010 Aug 6 03:21:54 p19-66-n5 %$ VDC-1 %$ %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP 175 returned error 0x40290000 (err
or) in if_bind sequence
Date: Fri, 06 Aug 2010 03:38:30 +0200
Nous avons essayé avec un 2ème fex 2248, idem. Par contre, après revérification, les problèmes sur ces ports étaient antérieurs et les machines déjà déplacées sur d'autres ports du même fex. Ceci va nous laisser le temps de résoudre le problème sur les fex 2248.
Date: Fri, 06 Aug 2010 03:39:32 +0200
Fin de la maintenance pour ce soir. Nous programmerons asap une nouvelle intervention de nuit pour p19-61/62.
Type de tâche: Incident
Catégorie: tous les start
Etat: Finie
Le filer ne ping plus. Nous regardons le probleme.
Type de tâche: Incident
Catégorie: 240plan
Etat: Finie
Plusieurs disques se sont mis en défaut simultanément, nous intervenons sur le serveur.
Commentaires:
Date: Thu, 29 Jul 2010 17:18:36 +0200
Le serveur est UP.
Les disques sont clean, c'est visiblement le contrôleur de disques qui a eu un problème.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: En cours
Nous mettons à jour php5 :
php 5.2.14
php 5.3.3
Commentaires:
Date: Wed, 28 Jul 2010 13:14:24 +0200
Fait sur cluster014
Type de tâche: Amélioration
Catégorie: 240plan
Etat: Finie
Dans le but d'améliorer les performances et notamment les temps de réponse du serveur, nous allons upgrader le serveur en RAM et ajouter 2 disques SSD au niveau du cache du filesystem.
La maintenance débutera vers 00h30 et durera une quinzaine de minutes.
Les sites hébergés sur /homez.342 seront impactés le temps de l'upgrade.
Commentaires:
Date: Tue, 27 Jul 2010 01:17:55 +0200
La maintenance s'est déroulée sans complications.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Plannifiée
Nous allons ajouter de la mémoire dans les serveurs suivants. A chaque fois, une petite indisponibilité est à prévoir. Nous opérerons le soir à partir de 23h.
mysql5-16.perso
mysql5-1.60gp
mysql5-2.60gp
mysql5-3.60gp
mysql5-4.60gp
mysql5-6.60gp
mysql5-7.60gp
mysql5-8.60gp
mysql5-1.90
mysql5-2.90
mysql5-4.90
mysql5-5.90
mysql5-6.90
mysql5-7.90
mysql5-8.90
mysql5-9.90
mysql5-10.90
mysql5-12.90
mysql5-13.90
mysql5-15.90
mysql5-16.90
mysql5-17.90
mysql5-18.90
mysql5-19.90
mysql5-21.90
mysql5-22.90
mysql5-23.90
mysql5-24.90
mysql5-25.90
mysql5-26.90
mysql5-34.90
mysql5-1.240
mysql5-2.240
mysql5-3.240
mysql5-4.240
mysql5-5.240
mysql5-6.240
mysql5-8.240
mysql5-11.240
mysql5-1.720
mysql5-2.720
mysql5-3.720
mysql5-4.720
mysql5-5.720
mysql5-10.720
mysql5-1.media
mysql5-2.media
mysql5-3.media
mysql5-4.media
mysql5-5.media
mysql5-1.xxl
mysql5-2.xxl
mysql5-3.xxl
mysql5-4.xxl
mysql5-5.xxl
mysql5-6.xxl
mysql5-7.xxl
mysql5-1.start
mysql5-3.start
mysql5-4.start
mysql5-5.start
mysql5-6.start
mysql5-1.1000gp
mysql5-2.1000gp
mysql5-1.300gp
sql1.modules
Commentaires:
Date: Fri, 23 Jul 2010 12:24:33 +0200
Exceptionnellement, nous allons opérer sur mysql5-1.xxl dans 10/15 minutes.
Date: Fri, 23 Jul 2010 13:12:14 +0200
La carte mère n'accepte pas la mémoire. nous somme revenus à la configuration d'origine.
Type de tâche: Incident
Catégorie: 90plan
Etat: Finie
Le serveur a planté quand nous avons voulu changer un disque défectueux.
Commentaires:
Date: Fri, 23 Jul 2010 11:36:02 +0200
Le serveur est à nouveau disponible. Le raid n'a pas survécu à la manipulation. Nous allons transférer les données sur un nouveau serveur. Le serveur sera à nouveau indisponible quelques minutes.
Date: Fri, 23 Jul 2010 14:55:00 +0200
Nous passons sur le nouveau serveur. 15 minutes d'indisponibilité à prévoir.
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: Finie
Nous allons remplacer le serveur mysql5-6.720 par une nouvelle machine pendant la nuit. Une coupure de moins d'environ 5 minutes est à prévoir.
Commentaires:
Date: Fri, 23 Jul 2010 00:31:13 +0200
Nous coupons le serveur pour procéder au basculement
Type de tâche: Maintenance
Catégorie: 240plan
Etat: Plannifiée
Le serveur ne répond plus, nous intervenons.
Les sites hébergés sur /homez.52 sont impactés.
Commentaires:
Date: Fri, 16 Jul 2010 16:04:12 +0200
Un problème au niveau de la carte réseau est à l'origine de la panne.
Retour à la normale pour les sites hébergés sur /homez.52
Nous planifions le remplacement de la carte réseau.
Type de tâche: Incident
Catégorie: tous les start
Etat: Finie
Le serveur présente un défaut matériel, nous allons le basculer sur un spare.
Une coupure de quelques minutes pourra être observée.
Commentaires:
Date: Wed, 14 Jul 2010 19:06:52 +0200
L'intervention est plus longue que prévue.
Date: Wed, 14 Jul 2010 19:51:47 +0200
La service est à nouveau opérationnel.
3 disques sont en cours de resynchronisation sur le serveur.
Type de tâche: Maintenance
Catégorie: tous les start
Etat: Finie
Le serveur mysql5-11.start présente des problèmes matériels. Nous allons procéder à son remplacement. Une coupure de 5 minutes environ est à prévoir.
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
Le serveur ne répond plus.
Nous intervenons.
Commentaires:
Date: Tue, 13 Jul 2010 01:13:10 +0200
Le problème est résolu. Un équipement réseau était en cause.
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
Le serveur mysql5-36.90 présente des problèmes de RAM. Une intervention est en cours.
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
L'option FollowSymLinks d'Apache pose de probleme de securité.
Nous avons patché Apache afin de garder l'option sans mettre
en panne tous les sites qui utilisaient mais juste changer
son comportement. Maintenant FollowSymLinks se comporte comme
SymLinksIfOwnerMatch.
Il n'y a donc pas de consequence sur le comportement de sites.
Type de tâche: Incident
Catégorie: tous les plans
Etat: Finie
Nous avons un soucis sur 240plan et 720plan.
Commentaires:
Date: Wed, 07 Jul 2010 21:33:46 +0200
attaque est bloquée.
Type de tâche: Incident
Catégorie: 240plan
Etat: Finie
Le filer ne répond pas correctement, nous intervenons.
Commentaires:
Date: Fri, 02 Jul 2010 15:31:02 +0200
Jul 2 14:44:27 filerz57 ^Mpanic[cpu2]/thread=fffffe800036bc60:
Date: Fri, 02 Jul 2010 15:31:59 +0200
Nous remplaçons le cpu.
Date: Fri, 02 Jul 2010 15:59:40 +0200
Le CPU est remplacé, le service est UP.
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: En cours
Depuis 3 mois nous preparons la mise en place de la
nouvelle infrastructure reseau sur P19 pour l'hébergement
mutualisé. L'objectif est de passer sur le reseau 10G
et eviter tous les problemes de congestion et de qualité
dû à la croissance. L'infra actuel a 6 ans. Il est temps
de mettre en place une nouvelle pour ... 6 ans ?
Commentaires:
Date: Fri, 21 May 2010 16:46:19 +0200
Nous allons basculer quelques switchs sur quelques nouveaux bouts du nouveau reseau.
Date: Tue, 25 May 2010 19:26:13 +0200
Le migration continue tranquilement switch par switch. En tout on doit basculer un reseau de presque 10000 serveurs sur cette nouvelle infra. Les interventions vont prendre plusieurs semaines.
Date: Wed, 26 May 2010 13:31:49 +0200
On bouge physiquement l'un des 2 N5 pour le recabler dans une
autre baie.
1 packet perdu ... Le cluster de N5 en vPC (virtual port channel)
fonctionne correctement en MTU 1500.
Date: Thu, 10 Jun 2010 05:45:22 +0200
Nous allons basculer le vlan principal de l'hébergement
mutualisé de 6K vers N5. Le but est de mettre la
nouvelle infra au coeur du switching du reseau mutu.
Il y a une petite coupure de quelques dizaines de
secondes à prevoir.
Date: Thu, 10 Jun 2010 06:09:27 +0200
c'est fait.
on peut continuer le basculement d'environ 10000
serveurs de l'hébergement mutualisé vers ce
nouveau reseau du mutu.
voici le schema.
http://weathermap.ovh.net/p19-mutu
Type de tâche: Incident
Catégorie: logs
Etat: Finie
Bonjour,
nous avons un soucis pour regénérer les clés de licence urchin6 sur les serveurs gérants les domaines commençant par 0, 1, 2 ,3 ,4, 5, 6 ,7 ,8 ,9 ou la lettre s.
Les statistiques ne peuvent être calculés pour le moment.
Le serveur de validation des licences chez google est en cause.
Nous attendons plus d'informations.
Commentaires:
Date: Mon, 05 Jul 2010 16:41:06 +0200
Nous avons pu regénérer les clés de license. Les calculs journaliers vont reprendre demain matin. Nous rattraperons le retard sous peu.
Type de tâche: Incident
Catégorie: 240plan
Etat: Finie
Une erreur humaine lors d'un changement de disque a planté le serveur.
Nous intervenons.
Les sites hébergés sur /homez.342 sont impactés.
Commentaires:
Date: Fri, 02 Jul 2010 12:37:05 +0200
Retour à la normale d'ici quelques minutes.
Type de tâche: Incident
Catégorie: 240plan
Etat: Finie
Un disque défaillant bloque les opérations de lecture/ecriture.
Nous intervenons.
Les sites hebergés sur /homez.307 sont impactés.
Type de tâche: Maintenance
Catégorie: mediaplan
Etat: Finie
Nous changeons la mémoire sur le serveur.
Type de tâche: Incident
Catégorie: 90plan
Etat: Finie
Le filer ne répond plus, nous intervenons.
Type de tâche: Incident
Catégorie: 240plan
Etat: Finie
Le serveur a freezé.
Redémarrage du service en cours.
Type de tâche: Incident
Catégorie: 90plan
Etat: Finie
Nous avons un problème de surcharge sur le serveur.
Nous intervenons.
Type de tâche: Incident
Catégorie: tous les start
Etat: Finie
Nous avons un probleme avec le filer. Il n'arrive pas a booter.
Nous le remettons en route.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Finie
Ruby a été mis à jour en version 1.8.7p174
Rails a été mis à jour en version 2.3.8
Type de tâche: Maintenance
Catégorie: 1000gp
Etat: Finie
Nous allons intervenir sur le filer homez.106 durant la nuit. Quelques minutes d'indisponibilité sont à prévoir.
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Finie
Nous allons remplacer le serveur mysql5-1.perso par une nouvelle machine.
Commentaires:
Date: Mon, 14 Jun 2010 13:51:20 +0200
Le changement sera effectué cette nuit (nuit du 14 au 15 juin 2010)
Date: Tue, 15 Jun 2010 02:31:24 +0200
Nous coupons le serveur pour procéder au basculement
Type de tâche: Incident
Catégorie: tous les datacenters
Etat: Finie
Depuis 7h de ce matin, nous avons un probleme bizarre
entre les Nexus 5000 et les Catalyst 6500
Commentaires:
Date: Sat, 12 Jun 2010 09:15:32 +0200
Nous avons de probleme de packet input sur les 6000.
Rien sur les Nexus 5000.
Nous avons redemarré le p19-53-n5 puis p19-54-n5.
ils sont en cluster donc chacun a pris le relay
de l'autre. Toujours le probleme.
Le probleme est sur tous les ports de tous les 6K
qui sont connectés vers les N5.
p19-57-6k#sh inter counters errors module 6
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Te6/1 0 0 0 0 0 0
Te6/2 0 0 0 0 0 0
Te6/3 0 0 0 0 0 0
Te6/4 0 0 0 74 0 0
Sur les N5 on utilise du virtual port channel sur 2 équipements.
C'est comme si les Nexus balancaient tellement de trafic que
le 6K n'arrivait pas à prendre ...
...
hmm ... on va augmenter les tailles de queue en input sur
les 6K
wrr-queue bandwidth 255 255 255 255 255 255 255
wrr-queue queue-limit 100 100 100 100 100 100 100
wrr-queue threshold 1 100 100 100 100 100 100 100 100
wrr-queue threshold 2 100 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 3 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
wrr-queue cos-map 1 4 0 1
wrr-queue cos-map 3 1 6
wrr-queue cos-map 7 8 7
rcv-queue bandwidth 255 255 255 255 255 255 255 255
rcv-queue queue-limit 100 100 100 100 100 100 100 100
rcv-queue threshold 1 100 100 100 100 100 100 100 100
rcv-queue random-detect min-threshold 1 100 100 100 100 100 100 100 100
rcv-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
rcv-queue cos-map 1 1 2 3
rcv-queue cos-map 1 8 0 1
rcv-queue cos-map 2 8 4 6
rcv-queue cos-map 7 8 7
rcv-queue cos-map 8 8 5
Date: Sat, 12 Jun 2010 09:20:17 +0200
on essaie de voir si avec le flowcontrol c'est mieux
Date: Sat, 12 Jun 2010 09:28:03 +0200
sur n5 on peut mettre flowcontrol sur le port channel et pas sur les port physiques et sur 6k on peut mettre flowcontrol sur les ports physique et pas sur le port channel. j'adore.
Date: Sat, 12 Jun 2010 09:29:35 +0200
Les erreurs augmente toujours, mais il n'y a plus de probleme de
detection de MAC entre les cartes de repartition de charge et les
serveurs.
p19-57-6k#sh inter counters errors module 6
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Te6/1 0 0 0 0 0 0
Te6/2 0 0 0 0 0 0
Te6/3 0 0 0 0 0 0
Te6/4 0 0 0 146 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Te6/1 0 0 0 0 0 0 0
Te6/2 0 0 0 0 0 0 0
Te6/3 0 0 0 0 0 0 15
Te6/4 0 0 0 0 0 0 0
Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err
Te6/1 0 0 0 0 0
Te6/2 0 0 0 0 0
Te6/3 0 0 0 0 0
Te6/4 0 0 0 0 0
on va ajouter un 2ème port 10G dans les port channels
entre les 6k et les N5. si on faire repartir le trafic
sur 2 ports 10G au lieu d'1, ça devrait mieux marcher.
Date: Sat, 12 Jun 2010 11:11:22 +0200
Avec 4x10G /6500, ça va mieux mais dés qu'un port 10G se
prend plus de 300'000 packets/seconds à partir d'un N5,
il a des erreurs sur input quand même.
On va remonter les bugs chez Cisco.
Date: Sat, 12 Jun 2010 11:13:21 +0200
p19-57-6k#sh inter t6/4 | i 30 sec
30 second input rate 1276919000 bits/sec, 316372 packets/sec
30 second output rate 1149697000 bits/sec, 204839 packets/sec
p19-57-6k#sh inter t7/1 | i 30 sec
30 second input rate 364833000 bits/sec, 68728 packets/sec
30 second output rate 1142250000 bits/sec, 205848 packets/sec
p19-57-6k#sh inter t7/3 | i 30 sec
30 second input rate 1404992000 bits/sec, 344054 packets/sec
30 second output rate 1042913000 bits/sec, 199855 packets/sec
p19-57-6k#sh inter t7/4 | i 30 sec
30 second input rate 342808000 bits/sec, 65034 packets/sec
30 second output rate 1081846000 bits/sec, 194390 packets/sec
p19-57-6k#sh inter cou err mod 6
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Te6/4 0 0 0 271 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Te6/4 0 0 0 0 0 0 0
Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err
Te6/4 0 0 0 0 0
p19-57-6k#sh inter cou err mod 7
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Te7/1 0 0 0 0 0 0
Te7/3 0 0 0 142 0 0
Te7/4 0 0 0 0 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Te7/1 0 0 0 0 0 0 0
Te7/3 0 0 0 0 0 0 0
Te7/4 0 0 0 0 0 0 0
Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err
Te7/1 0 0 0 0 0
Te7/3 0 0 0 0 0
Te7/4 0 0 0 0 0
Type de tâche: Incident
Catégorie: xxlplan
Etat: Finie
Nous avons un probleme de nfs sur le filer.
Tous les sites heberges sur ce filer ne sont pas accessibles.
Type de tâche: Maintenance
Catégorie: 240plan
Etat: Finie
Un des 2 CPU du serveur est défectueux, nous allons le remplacer.
Une coupure de 5 minutes est à prévoir.
Les sites hébergés sur /homez.183 sont impactés.
Commentaires:
Date: Mon, 07 Jun 2010 23:15:56 +0200
Le remplacement a été effectué. Nous suivons l'activité du serveur.
Type de tâche: Maintenance
Catégorie: sqlprive
Etat: Finie
Dans la nuit du mardi 01/06 au mercredi, nous allons basculer certains liens.
Une coupure de 10 secondes pourra être observée.
Les serveurs impactés :
server1
server2
server3
server5
server6
server7
server8
server9
server10
server11
server12
server15
server22
server31
server32
server33
Commentaires:
Date: Wed, 02 Jun 2010 00:29:33 +0200
Nous démarrons les interventions.
Type de tâche: Incident
Catégorie: 60gp
Etat: Finie
Le serveur est indisponible.
Nous procédons à son remplacement.
Commentaires:
Date: Mon, 31 May 2010 13:05:57 +0200
Nous avons changé le disque de la machine.
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: Finie
Le serveur mysql5-10.bdb présente des problèmes de stabilité depuis quelques jours.
Nous allons donc procéder à son remplacement.
Commentaires:
Date: Mon, 31 May 2010 01:06:02 +0200
Nous coupons le serveur pour procéder au basculement
Type de tâche: Amélioration
Catégorie: tous les plans
Etat: Finie
Nous allons faire plusieurs mises à jours de sécurités sur les serveurs webs. Il n'y a pas de coupure à prévoir.
Certaines mises à jour pouraient avoir un impact sur le fonctionnement de certains sites effectuant des opérations non standard.
En cas de problème, n'hésitez pas à nous contacter.
Commentaires:
Date: Tue, 15 Dec 2009 16:03:13 +0100
La première étape de la mise à jour est terminée sur cluster012
Date: Tue, 15 Dec 2009 17:08:43 +0100
Une bug dans la mise à jour a entrainé un problème temporaire sur la création des sessions PHP. Le problème est corrigé.
Date: Thu, 31 Dec 2009 09:28:03 +0100
La première étape de la mise à jour est terminée sur l'ensemble des serveurs
Type de tâche: Maintenance
Catégorie: tous les plans
Etat: Finie
Ceci ne concerne que les domaines commençant par la lettre P.
Les statistiques v3/v6 n'ont pas été calculées ces derniers jours.
Nous corrigeons le problème.
Type de tâche: Incident
Catégorie: 90plan
Etat: Finie
Le serveur est surchargé pour une raison inconnue.
Nous intervenons.
Commentaires:
Date: Thu, 27 May 2010 18:00:49 +0200
Nous redémarrons le serveur.
Date: Thu, 27 May 2010 18:04:29 +0200
Le serveur est redémarré. Retour à la normale dans quelques minutes.
Type de tâche: Maintenance
Catégorie: 20gp
Etat: En cours
Nous allons ajouter un nouveau routeur p19-55-6k
qui va router ovh.com
Le but est de basculer l'infrastructure actuelle
vers le nouveau reseau 10G.
http://travaux.ovh.com/?do=details&id=4208
Type de tâche: Incident
Catégorie: 20gp
Etat: Finie
Le serveur à redémarré à cause d'une erreur sur un des CPU.
Nous allons remplacer le CPU dans le courant de la matinée.
Commentaires:
Date: Wed, 26 May 2010 11:23:39 +0200
Nous remplaçons le CPU , une indisponibilité de 5 à 10 minutes sur les sites hébergés sur /homez.105 est à prévoir.
Type de tâche: Maintenance
Catégorie: 240plan
Etat: Finie
Nous détectons des instabilités matérielles sur le serveur.
Nous allons le remplacer par un spare dans la nuit du lundi 24/05 au mardi.
Commentaires:
Date: Mon, 24 May 2010 23:59:02 +0200
Nous démarrons l'intervention.
Date: Tue, 25 May 2010 00:38:22 +0200
Déplacement effectué sans problème.
