Voir la version complète : Rps Down ?
Un collègue me signale le down d'un service teamspeak.
Suspect, tout tournais bien.
Des infos de vos cotés ? Je commence à regarder
Serveur 1 >> Ok
Serveur 2 >> Ok
Serveur 3 >> Mysql fonctionne mais lighttpd & teamspeak down. Impossible de me connecter en ssh. (r10877.ovh.net) (Et le pire, c'est que sa ping)
Reboot hardware lancer...
Sa ne reping pas encore
Ticket d'incident créer.
Wait & see...
Afrolatino.net
08/05/2008, 04h26
Depuis 2h du mat plus http ni ssh ni webmin
reboot vers 5h a partir du manager OVh
et maintenant le serveur rps ne replonds plus ping hs
et je viens de recevoir ceci par mail
Bonjour,
Notre système de monitoring vient de détecter un défaut sur votre serveur r11375.ovh.net. Le défaut a été constaté à la date 2008-05-08 05:00:31
Notre équipe de techniciens sur site (opérationnelle 24h/24, 7j/7), a été informée de ce défaut et va intervenir sur votre machine.
Sachez que d'autres interventions peuvent être en cours actuellement et qu'il faut compter en moyenne 30 minutes par intervention et par machine.
Par conséquent, nous ne pouvons pas vous donner plus de précisions quant à l'heure de début de l'intervention.
Vous pouvez avoir un aperçu global des machines actuellement en defaut et en intervention sur tout le réseau à cette adresse:
http://travaux.ovh.net/vms/
Votre serveur se trouve dans la baie 07D03
Vous recevrez un email dés qu'un technicien prendra en charge votre serveur. En attendant, vous avez la possibilité de le rebooter à partir de votre manager.
Logs:
----------------------
PING r11375.ovh.net (87.98.145.134) from 213.186.33.13 : 56(84) bytes of data.
From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable
--- 87.98.145.134 ping statistics ---
10 packets transmitted, 0 packets received, +6 errors, 100% packet loss
Support technique, OVH
Afrolatino.net
08/05/2008, 04h51
apparemment il y a eu un incident
http://travaux.ovh.net/?do=details&id=2169
Détails La communication entre le SAN et les serveurs iSCSI a coupé.
Nous avons rebooté le SAN + les serveurs iSCSI.
Date: jeudi, 08 mai 2008, 05:41
Raison de clôture: Done
Commentaires supplémentaires de clôture: fixé
j'ai refait un reboot mais toujours pas de ping malgre le message suivant
Bonjour,
Vous avez fait la demande d'un reboot hardware à distance sur votre serveur r11375.ovh.net. Nous venons d'exécuter votre demande et votre serveur répond à nouveau au ping.
Vous pouvez vous connecter à votre serveur.
Pour votre information:
- date de votre demande de reboot: 2008-05-08 05:48:09
- date d'éxécution du reboot hard: 2008-05-08 05:48:21
- date de détection de ping : 2008-05-08 05:49:20
Cordialement
Service Client, OVH
Cela est un message "BATEAU" :(:(:(
Afrolatino.net
08/05/2008, 06h01
c'est reparti :)
Interruption de 01:56:21 à 06:17:18 :(
Mais au final 128 Messages soit 2,95 messages par jour pour des soucis
http://forum.ovh.com/member.php?u=19540
j'en ai marre je quitte le RPS
( le Réseau Peer Soucis )
:mad: :rolleyes: :p :D :)
PS: je félicite la liberté d'expression sur ce forum
Je pense qu'il faudrais regarder le problème autrement.
Le soucis étais sur l'accès disque mais la base de donnée fonctionnais encore (mysql).
Savez vous si il y à un moyen de charger un programme en mémoire vive et non sur le dd ?
Un peut comme ce que devais faire mysql ?
Afrolatino.net
08/05/2008, 18h57
Encore HS le
Réal Partage Soucis
http://travaux.ovh.net/?do=details&id=2169
FS#2169 — iscsi5/6
Concerne le projet— RPS
Type de tâche Incident
Catégorie Backend / Core
Etat En cours
Pourcentage effectué 100%
Détails La communication entre le SAN et les serveurs iSCSI a coupé.
Nous avons rebooté le SAN + les serveurs iSCSI.
* Commentaires (2)
Commentaire de OVH - jeudi, 08 mai 2008, 19:42
Des erreurs de communication subsistent. Nous venons de rebooter le SAN.
Commentaire de OVH - jeudi, 08 mai 2008, 19:51
Nous intervenons physiquement sur le SAN pour vérifier son bon fonctionnement.
Afrolatino.net
08/05/2008, 18h57
...:mad::mad::mad::mad:
Bonjour,
Notre système de monitoring vient de détecter un défaut sur votre serveur r11375.ovh.net. Le défaut a été constaté à la date 2008-05-08 19:59:32
Notre équipe de techniciens sur site (opérationnelle 24h/24, 7j/7), a été informée de ce défaut et va intervenir sur votre machine.
Sachez que d'autres interventions peuvent être en cours actuellement et qu'il faut compter en moyenne 30 minutes par intervention et par machine.
Par conséquent, nous ne pouvons pas vous donner plus de précisions quant à l'heure de début de l'intervention.
Vous pouvez avoir un aperçu global des machines actuellement en defaut et en intervention sur tout le réseau à cette adresse:
http://travaux.ovh.net/vms/
Votre serveur se trouve dans la baie 07D03
Vous recevrez un email dés qu'un technicien prendra en charge votre serveur. En attendant, vous avez la possibilité de le rebooter à partir de votre manager.
Logs:
----------------------
PING r11375.ovh.net (87.98.145.134) from 213.186.33.13 : 56(84) bytes of data.
From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable From 213.186.33.13: Destination Host Unreachable
--- 87.98.145.134 ping statistics ---
10 packets transmitted, 0 packets received, +6 errors, 100% packet loss
---------------------
--
Support technique, OVH
Afrolatino.net
08/05/2008, 19h04
Votre serveur se trouve dans la baie 07D03
il doit y avoir des baies maudites
ou alors effectivement nous sommes victime une fois de plus de la mondialisation
les CeleronS sont recyclés made in inde c'est ceux qui ont ete desoude par chalumeaux par un pauvre indien respirant de meme des PCB et autres
Au fait il viennent d'ou ces CeleronS d'occas :confused::confused::confused:
j'ai fait des reboots en hard
ça ne ping toujours pas
Baie : 08H01
ca commence a faire long (30 min)
Bonjour,
Mon RSP est également down (baie 08H02 : surement le même problème).
Bonjour, le mien aussi8H01 depuis un bon bout de temps déjà!(au moins depuis 19h45)
Profinternet
08/05/2008, 21h45
Aïe! Car y en a 14 down sur 08H01 (http://travaux.ovh.net/vms/index_rbx.html#08H01) :confused:
seedaumas
08/05/2008, 21h58
Et bien je vous souhaite bien du courage c'est vrai que c'est pas très sérieux tout ca!! :mad::mad:
Par contre moi j'ai de la chance presque pas de merde sur la baie 08H03!
les techos sont tous en vacances ????
seedaumas
08/05/2008, 22h11
Oui c'est sur que des ponts comme ce week end ca doit bouriner sur les RPS c'est le qu'il vont s'apercevoir qu'ils avaient pas prévu assez large niveau iscsi et san....
Bonjour,
Etant relativement nouveau sur OVH je me demande si ce genre d'incident est fréquent?
Je trouve qu'une coupure de près de 4 heures du service pour ma part n'est pas admissible, a moins que la cause soit exceptionnelle...
Combien de temps allons nous continuer à payer pour voir notre serveur indisponible?
Merci OVH...
seedaumas
08/05/2008, 22h13
Toujours meme discourt ovh pas de soucis sur les dedies normaux mais de gros problème sur les RPs ..... cause à mon avis sous dimensionnement des infras san et iscsi.
Du nouveau apparement, et pas de bonnes nouvelles : http://travaux.ovh.net/?do=details&id=2169
ca veut dire qu'en fait demain matin on se retrouve avec nos serveurs configurés et contenant les mêmes data que dimanche matin?
petitcurieux
08/05/2008, 22h19
Mon RPS est également down depuis quelques heures et ce, malgré plusieurs reboots (baie 07D01). C'est la seconde fois en deux mois que j'ai des problèmes, je vais certainement opter pour un Kimsufi en attendant que ce soit vraiment au point... Bonne chance aux techniciens d'OVH ;)
plusieurs dizaines d'heure...:(:eek:
Afrolatino.net
09/05/2008, 01h26
:( :confused: :eek: :mad: :o
FS#2169 — iscsi5/6
Concerne le projet— RPS
Type de tâche Incident
Catégorie Backend / Core
Etat En cours
Pourcentage effectué 100%
Détails La communication entre le SAN et les serveurs iSCSI a coupé.
Nous avons rebooté le SAN + les serveurs iSCSI.
* Commentaires (8)
Commentaire de OVH - jeudi, 08 mai 2008, 19:42
Des erreurs de communication subsistent. Nous venons de rebooter le SAN.
Commentaire de OVH - jeudi, 08 mai 2008, 19:51
Nous intervenons physiquement sur le SAN pour vérifier son bon fonctionnement.
Commentaire de OVH - jeudi, 08 mai 2008, 20:34
Nous avons changé le shelf qui semble poser problème.
Commentaire de OVH - jeudi, 08 mai 2008, 21:18
Le changement du shelf n'a pas résolu le problème.
Nous remettons en place le iscsi sur 196 (iscsi5).
Pour le iscsi de 197 (iscsi6), nous inspectons le shelf ainsi que les disques correspondants.
Commentaire de OVH - jeudi, 08 mai 2008, 23:09
Nous avons un grave probleme sur le filesysteme 197. Le systeme est
monté sur un RAID-10 de 12 disques (basés sur 4 raid-1 de 3 disques
chacun). Il se trouve que le filesysteme a enregistré les erreurs
sur 2 raid-1 (soit 6 disques !).
root@filerz3:~# zpool status -x
pool: filer197
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see: http://www.sun.com/msg/ZFS-8000-CS
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
filer197 FAULTED 0 0 4 corrupted data
mirror ONLINE 0 0 0
c1t20d0 ONLINE 0 0 0
c1t21d0 ONLINE 0 0 0
c1t22d0 ONLINE 0 0 0
mirror ONLINE 0 0 2
c1t23d0 ONLINE 0 0 4
c1t24d0 ONLINE 0 0 4
c1t25d0 ONLINE 0 0 4
mirror ONLINE 0 0 2
c1t26d0 ONLINE 0 0 4
c1t27d0 ONLINE 0 0 4
c1t28d0 ONLINE 0 0 4
mirror ONLINE 0 0 0
c1t29d0 ONLINE 0 0 0
c1t30d0 ONLINE 0 0 0
c1t31d0 ONLINE 0 0 0
Nous avons sortis les disques sur un autre filer pour travailer
sur ces disques afin de voir si on peut recuperer les données
ou c'est foutu et on doit travailer à partir du backup (daté
de ce dimanche).
Commentaire de OVH - jeudi, 08 mai 2008, 23:13
Après differents essais sur differentes configurations entre
differents disques, le filesystem ne veut pas demarrer. Les
données sont là, les disques n'ont pas d'erreurs, mais l'ensemble
de veut pas monter.
Nous allons travailer à partir de backup du dimanche. Par contre
ceci prendra plusieurs heures pour recopier les données binaires
sous forme de disque. Nous utilisons pour ça les commandes de
ZFS (zsend/zreceive).
Commentaire de OVH - jeudi, 08 mai 2008, 23:25
Bonjour,
Nous avons un grave probleme sur l'ensemble des RPS qui sont
installés sur la 197. Il y a 167 RPS touchés par ce probleme.
Le plus ancien RPS touché a été installé il y a 18 jours. Le
plus recent il y a 10 jours.
Le detail:
http://travaux.ovh.com/?do=details&id=2169
Nous avons effectué des maintenances cette nuit, ce matin et
cette apres midi sur le SAN qui gere les RPS 196 et 197.
Fin de l'apres midi, le SAN s'est mis en défaut et nous avons
dû intervenir sur place. Apparament un probleme hardware est
à l'origine du probleme. Nous avons changé les shelfs et nous
avons redemarré le SAN. Le filesystem 196 n'a aucun probleme.
Tout est à nouveau en fonctionnement. Par contre sur la 197,
nous avons un grave probleme: malgré un RAID-1 sur 3 disques
plusieurs disques ont des données corrompu et le filesystem
ne veut pas monter.
root@filerz3:~# zpool status -x
pool: filer197
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see: http://www.sun.com/msg/ZFS-8000-CS
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
filer197 FAULTED 0 0 4 corrupted data
mirror ONLINE 0 0 0
c1t20d0 ONLINE 0 0 0
c1t21d0 ONLINE 0 0 0
c1t22d0 ONLINE 0 0 0
mirror ONLINE 0 0 2
c1t23d0 ONLINE 0 0 4
c1t24d0 ONLINE 0 0 4
c1t25d0 ONLINE 0 0 4
mirror ONLINE 0 0 2
c1t26d0 ONLINE 0 0 4
c1t27d0 ONLINE 0 0 4
c1t28d0 ONLINE 0 0 4
mirror ONLINE 0 0 0
c1t29d0 ONLINE 0 0 0
c1t30d0 ONLINE 0 0 0
c1t31d0 ONLINE 0 0 0
Le checksum sur le 2ème et 3ème RAID-1 n'est pas bon mais
surtout le checksum n'est pas bon sur les 3 disques de 2
RAID-1 !
Nous allons travailer à partir de backup réalisé ce dimanche
mais ceci risque de prendre plusieurs heures voir plusieurs
dizaines d'heures pour reprendre le backup et en faire un
filesystem (actuellement le backup est sous forme d'un fichier
et donc binaires. nous allons le recuperer avec les commandes
ZFS zreceive/zsend).
Amicalement
Octave
Commentaire de OVH - vendredi, 09 mai 2008, 00:32
La construction de filesystem à partir de backup est très lente.
Ceci va prendre probablement toute la nuit voir plus.
Pour eviter la panne de RPS pour des clients qui ont leurs propres
backups, nous allons reinstaller tous les RPS 187 sur la nouvelle
plateforme l'iSCSI v2. Ceci permettra aux clients de remettre
rapidement les RPS en marche.
Lorsqu'on aura fini avec la recuperation du backup, nous allons
permettre aux clients de recuperer les données à travers l'iSCSI.
La version 2 de l'iSCSI n'aura plus ce probleme là vu que chaque
client a son propre filesystem sur le SAN (au lieu d'un grand
filesystem mutualisé parmis 230 clients).
La nuit sera longe ...
Afrolatino.net
09/05/2008, 01h26
Bref vivement qu'on puisse récupérer nos donnés et remettre en service
celadevient URGENT
J' avais pris un Kimsufi depuis 1 mois mais j'ai eu la faiblesse de reporter la migration de mon web
je m'en mords les doigts cela commence a coute cher
(Perte de Referencement , Plainte de mes adherents, ...)
merci quand meme a l'equipe OVH qui bosse dessus ;)
Bonjour,
Etant relativement nouveau sur OVH je me demande si ce genre d'incident est fréquent?
Je trouve qu'une coupure de près de 4 heures du service pour ma part n'est pas admissible, a moins que la cause soit exceptionnelle...
Combien de temps allons nous continuer à payer pour voir notre serveur indisponible?
Merci OVH...
Jamais eu aucun soucis sur dédié...
On va dire que les rps en production avec le disque dur réseau, c'est pas encore sa ;)
Insatisfait. Quand ça marchait, ça marchait plutôt pas mal. Ceci dit trop de problèmes : indisponibilités, plantages, reboot divers ; ce matin j'apprends que les RPS sont réinstallés, donc perte de données uploadées, raz de la configuration, etc. Bref, à éviter pour le moment. Faudra les utiliser lorsque la phase de beta test sera terminée (suis je bête elle est déjà terminée ... on croirait pas en fait). Je ne vais pas renouveler l'offre. Non bien sûr ça n'est pas de l'incompétence, non c'est pas la faute aux techniciens, oui il font du bon travail, mais non RPS n'est pas au point. Ça plante.
Si j'avais perdu tout ce que j'ai fait hier apres-midi je ferais la gueule :( Heureusement je suis sur le 196 mais je vais lancer un backup de ce pas :D Un ptit reboot tous les matins ca devient routinier, va falloir que je fasse un script :p
Plus de nouvelles concernant les backups depuis 5h du mat, ca se termine?
merci
vBulletin® v.3.8.4, Copyright ©2000-2012, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org