Sunucu Durumu

Un de nos serveurs subit des interruptions suite à un problème sur un module de sécurité.
Nous intervenons

Le serveur a été redémarré et nous surveillons les logs pour identifier la cause exacte de la charge

La cause du dérangement a été identifiée.
La base de données en relation avec ModSecurity de Comodo ne cessait de grandir suite à une erreur logiciel et empêchait les requêtes web de fonctionner correctement.

Le serveur va être redémarré pour appliquer les dernières mises à jour du kernel.

Edit 07.01.2018 @ 23:00
La maintenance est terminée. La charge du serveur est élevée suite au redémarrage et va baisser à un niveau normal dans les 30 minutes.

Le serveur va être redémarré pour appliquer les dernières mises à jour du kernel.

Edit 07.01.2018 @ 22:45
La maintenance est terminée. La charge du serveur est élevée suite au redémarrage et va baisser à un niveau normal dans les 30 minutes.

Le problème de charge était dû à un problème lors de la sauvegarde de la base de données MySQL.
Le processus en question a été suspendu et la charge du serveur est revenue à un niveau normal.

Un redémarrage du serveur va être réalisé afin d'appliquer des mises à jour critique.

Comme le serveur n'a pas été redémarré depuis plus d'une année il est possible qu'une opération d'analyse de disque soit réalisée ce qui va allonger le temps de coupure.

Litespeed va être désactivé sur le serveur et Apache va être réactivé.

La version de cPanel va également être actualisée et le système de sauvegarde modifié en utilisant les dernières options de cPanel.

Il est possible qu'un modification du fichiers .htaccess soit nécessaire.

Le serveur doit être redémarré afin d'appliquer les dernières mises à jour de sécurité.
Les services vont être interrompu durant le redémarrage.

Litespeed va être désactivé sur le serveur et Apache va être réactivé.

La version de cPanel va également être actualisée et le système de sauvegarde modifié en utilisant les dernières options de cPanel.

Il est possible qu'un modification du fichiers .htaccess soit nécessaire.

Le processus de sauvegarde du serveur à subit une défaillance qui a engendré une charge élevée sur le serveur. 
L'incident est en cours de traitement et la sauvegarde va être interrompue.

Edit 12.06.2017
La sauvegarde doit être reconstruite et ce traitement est long et consomme des ressources serveurs.
Le processus est stoppé quand la charge est trop haute et le processus est relancé la nuit suivante.

La version PHP par défaut du serveur va être mise à jour de PHP5.6 vers PHP7.1.

Il est toujours possible de revenir à la version précédente via cPanel > Gestionnaire Multi-PHP

Il est aussi possible de choisir la version PHP et les modules via cPanel > Select PHP Version
https://www.eurowh.com/knowledgebase/14/Modification-de-la-version-de-PHP-et-des-modules-actives.html

Une hausse significative du trafic sur le serveur a été mesurée.
Des analyses sont en cours afin de déceler la source du problème.

Des ralentissements sont attendus lors des opérations de maintenance et d'analyse.

Mise à jour Apache et EasyApache

Une mise à jour du Backend EuroWH et de l'espace clients sera effectuée le 18 octobre entre 5h et 7h.
Des coupures sur l'espace clients sont à prévoires.

Aucun impact sur les sites n'est attendu.

Bonjour 

une opération de maintenance planifiée sur le serveur peut engendrer une charge élevée à plusieurs reprise durant quelques minutes dans la plage horaire mentionnée.

Le backup a été lancé une seconde fois mais en utilisant une carte réseau séparée et un réseau entièrement privé.
L'impact sur les performances du serveur devrait être moindre que durant la journée de lundi.

Un backup complet est effectué sur un nouveau serveur externe et le processus va être plus long que d'habitude.
Il est possible que la charge augmente ponctuellement lors du transfert des données.

La connexion SSL sur l'espace client EuroWH a temporairement été suspendue.

L'espace client est accessible pour l'instant via http://www.eurowh.com/clientarea.php

La connexion via SSL https://www.eurowh.com/clientarea.php ne fonctionne actuellement pas à 100%

Le problème était situé chez Cloudflare ou sur le routage entre le serveur et Cloudflare.
Plus aucun problème n'est constaté, le SSL est réactivé de base.

Une coupure du trafic réseau a eu lieu durant une vingtaine de minute entre 11h20 et 11h40 aujourd'hui.

Le trafic est actuellement rétabli et la cause de l'erreur n'est pas encore connue.
La coupure réseau a affecté l'intégralité du Datacenter hébergeant nos infrastructures situées chez Online à Paris.

L'incident a bien été confirmé sur le réseau. Le problème est apparu suite à une mise à jour des routeurs Cisco.
https://status.online.net/index.php?do=details&task_id=346

l'adresse IP principale du serveur est bloquée temporairement chez Free.fr. Le problème vient de mail envoyé sur une adresse e-mail qui n'existe pas chez free.fr

Le serveur a cessé de répondre au Ping et un redémarrage est en cours.

Une erreur logiciel a provoqué un redémarrage du serveur après un Uptime supérieur à une année.
L'erreur est en analyse.

Des problèmes d'accessibilité ont étés signalés ce matin par nos outils de monitoring.

La cause du problème est en analyse pour l'instant.
Il pourrait s'agir d'attaque sur l'ensemble du réseau et ayant indirectement touché notre infrastructure ou un effet de bord d'une installation réalisée ce matin sur le serveur et ayant provoqué un dysfonctionnement de Litespeed.

Pour l'instant il semblerait que le problème soit lié à la maintenance et tout fonctionne bien après avoir réinstallé Litespeed.

Des attaques DDoS ont étés effectuées contre le serveur.
Les attaques ont étés mitigées par notre protection anti-DDoS. 
Pour mitiger les attaques le trafic est brièvement interrompu puis il est rétablis quand les adresses attaquantes ont étés identifiées.
Il y a eu plusieurs vagues d'attaques successives. Le trafic a été interrompu entre 3 et 5 fois durant les attaques.

Les attaques sont bloquées pour l'instant et une surveillance étroite est maintenue sur le trafic entrant.
Voici un aperçu du trafic généré durant l'attaque (en paquets par secondes et en Mo par seconde).

Les serveurs de Free.fr ont bloqués certaines adresses IP suite à un trop grand nombre de message envoyé.
La durée de bloquage est de 24h.

Nos équipes sont en discussions avec Free pour lever ce bloquage.
Les messages envoyés sont des notifications de nouveaux commentaires d'un blog wordpress et donc tout à fait légitime.
Il semblerait que Free impose une limite relativement basse sur les e-mails entrants par heure sur un compte.

Suite à une opération de mise à jour des modules PHP, le module MYSQLi a été retiré du profil de base tout en restant accessible dans les modules complémentaires. L'activation est possible depuis la page cPanel > Select PHP Version. Edit 10.11 à 03h00 : Le module MYSQLi a été remis dans les modules du profil de base.

Des travaux sur l'espace client sont planifiés.

L'accès aux hébergements via cPanel sera garanti en tout temps mais l'accès à l'espace client sera impossible par moment.
Pour le support il faudra passer par les e-mails durant la maintenance.

Une longue interruption est à prévoir le samedi 1 novembre dans la soirée. Des perturbations seront possibles également le dimanche et jusqu'au lundi matin.

Suite à un défaut sur le serveur de sauvegarde une nouvelle sauvegarde complète doit être effectuée.

Le processus de sauvegarde est transparent et tourne en tâche de fond sur le serveur.

Il n'est malheureusement plus possible de restorer d'ancienne sauvegarde.

Un problème avec Litespeed a été détecté.
Durant la phase d'analyse le serveur fonctionne à nouveau sur Apache.

Le retour à Litespeed sera effectué dès que l'erreur aura été corrigée.

Litespeed a été redémarré depuis quelques minutes. 
Le service est sous surveillance.

EDIT 22.08.2014 @ 10h50:
Visiblement la version 4.2.14 de Litespeed pose quelques soucis.
Un retour à la version 4.2.12 a été effectué.

EDIT 22.08.2014 @ 17h30:
La version 4.2.12 de Litespeed fonctionne sans probème de 10h50. Aucune interruption n'a été remarquée.
Litespeed reste donc momentanément en 4.2.12.

Un problème afféctant le routage du trafic Internet de manière général provoque des alarmes non avérées.

Depuis 22h00 environs de nombreuses alarmes (Pingdom) mentionnes des sites Down alors que l'infrastructure fonctionne parfaitement bien.

Il semblerait que le trafic US et certains points de peering européen posent quelques soucis.

La cause du dérangement serait une coupure d'un câble transatlantique de Telias. 
Le trafic est rerouté sur un autre peering

Un redémarrage des hosts VPS est planifié afin d'appliquer un nouveau kernel. 
Une coupure de 15 minutes par host est à prevoir.

Les serveurs ont étés mis à jour (BIOS et Kernel) et l'infrastructure est à nouveau fonctionnel à 100%

Une coupure réseau de quelques minutes c'est produite ce matin.

Les services sont rétablis et la coupure a duré environs 4 minutes.

Selon les spécialistes du Datacenter une erreur logiciel dans un des éléments de routage est la cause de la coupure. 
Des mesures ont étés prises pour éviter une nouvelle coupure de cette élément.

Une mise à jour des versions de PHP 5.4 et 5.5 va être effectuée.

PHP5.4 va passer en 5.4.25
PHP5.5 va passer à la version 5.5.9

Édit 13.02 @ 22h05 : Mises à jour effectuées avec succès. 

Une attaque DDoS est en cours sur l'IP principale du serveur.

Le serveur fonctionne correctement sur les IP additionnels mais l'IP principale est en cours de mitigation par le Datacenter et est temporairement isolée du réseau externe.

Nos équipes font le maximum pour contrer les attaques et remettre l'IP sur le réseau.

Sur les 3 attaques détectées une est mitigée correctement et les deux dernières sont sur le point d'être mitigée aussi.

Le pique de trafic de l'attaque DDoS était de 7.5Gbit /s

Edit 09.02 @ 11h00: L'attaque est contrée et les sites sur l'IP principale sont à nouveau accessible
Edit 09.02 @ 11h10: Deux nouvelles attaques en cours de mitigation
Edit 09.02 @ 19h25 : Cible des attaques identifiées

Tous les serveurs de l'infrastructure doivent être redémarrés afin d'appliquer un patch de mise à jour HP lié à la console.

L'infrastructure virtualisée va être redémarrée ce soir à 22h20 (coupure 5 minutes par serveur).

Le serveur mutu vz01 sera redémarré mardi matin à 5h30 (coupure 5 minutes).

26.01 @ 22h15: Infrastructure virtualisée redémarée comme prévu. Coupure de 4 minutes sur chaque serveur.
27.01 @ 05H00: Le redémarrage de wh01 est déplacé à mardi matin 5h30
28.01 @ 05h30: Lancement du redémarrage du serveur
28.01 @ 05h45: Le serveur est à nouveau en service. La charge est élevée suite au redémarrage et devrait redescendre dans les 15 prochaines minutes
28.01 @ 05h50: La charge est à nouveau faible et l'intégralité des services sont à disposition. La maintenance est terminée

Une migration de l'infrastructure actuelle est nécessaire afin de garantir un niveau de service convenable.

L'infrastructure va être migrée dans un nouveau Datacenter et les comptes vont être migrés.

Veuillez vous assurer que vos noms de domaines utilisent bien les DNS EuroWH (ns1.eurowh.com ; ns2.eurowh.com) afin que cette migration n'influence pas sur vos sites.
Les sites vont être migrés de md-1.eurowh.com vers wh01.eurowh.com (62.210.152.79).

04.01.2014 @ 23h00: La migration débute. Les comptes sont migrés les uns après les autres.

Une migration de l'infrastructure actuelle est nécessaire afin de garantir un niveau de service convenable.

L'infrastructure va être migrée dans un nouveau Datacenter et les comptes vont être migrés.
La migration va être lancée le 31.12.2013 à 22h30

Veuillez vous assurer que vos noms de domaines utilisent bien les DNS EuroWH (ns1.eurowh.com ; ns2.eurowh.com) afin que cette migration n'influence pas sur vos sites.
Les sites vont être migrés de md-1.eurowh.com vers wh01.eurowh.com (62.210.152.79).

31.12.2013 @ 23h00: La migration est lancée. Les comptes sont migrés les uns après les autres.
01.01.2014 @ 21h00: La migration est terminée. Tous les comptes ont étés migrés avec succès

Le certificat SSL du serveur à été renouvelé il y a plusieurs jours mais certaines configuration e-mail garde l'ancien certificat en mémoire et indique qu'il est expiré. 

Nos équipes analysent le problème en collaboration avec les ingénieurs de cPanel

Dans certains cas il a suffit de supprimer le certificat local pour que le client mail mette à jour le certificat.

Edit 17.12 @ 17h00: Le certificat a été réinstallé et les services relancés. Il ne devrait plus y avoir de problème. 

Une brève interruption du serveur est nécessaire afin d'appliquer un nouveau noyau Linux.

Le serveur va être redémarré afin de fonctionner sur le nouveau kernel

La coupure estimée est de l'ordre de quelques minutes

Suite aux problèmes rencontrés sur MD-1 la mise à jour du Kernel de ce serveur est suspendue

06.12.2013 23h00 : Les problèmes sur MD-1 étaient le résultat d'une manipulation malheureuse dans le BIOS et était indépendantes de la mise à jour.  Une nouvelle mise à jour de MD-2 est planifiée
09.12.2013 07h15 : Shutdown en cours 
09.12.2013 07h20 : Le redémarrage a été effectué avec succès. 

Une brève interruption du serveur est nécessaire afin d'appliquer un nouveau noyau Linux.

Le serveur va être redémarré afin de fonctionner sur le nouveau kernel

La coupure estimée est de l'ordre de quelques minutes

Suite à la mise à jour le kernel ne se charge pas proprement.
Le serveur fonctionne provisoirement sans les fonctions liées à CloudLinux (versions PHP à choix et limitations CPU par utilisateur).

EDIT 30.11.2013: cette nuit une intervention va être effectuée sur MySQL. Il est possible que MySQL arrête de fonctiionner le temps de la maintenance
Maintenance prévue cette nuit entre 23h00 et 5h00

Tout les problèmes sont corrigés. 

Suite au problème de la mise à jour du Kernel une maintenance doit être effectuée physiquement au Datacenter.

Nous avons été avisé que cette maintenance va être effectuée.
Une indisponibilité du serveur est à prévoir et la durée est inconnue (mais ne devrait pas être longue).

EDIT 17h10: La maintenance va être lancée dans quelques minutes

Le problème a été identifié et corrigé. Le serveur est à nouveau pleinement fonctionnel

Une erreur chez OVH a bloqué le serveur.

Le support OVH est avisé depuis hier et plusieurs ticket ont étés ouverts pour éviter ce problème malheureusement OVH n'en a pas tenu compte.

Le ticket est ouvert avec une priorité haute chez OVH

Le délai de résolution n'est pas encore connu

Un problème de routage avec certaines IP est constaté.
Un ticket est ouvert au niveau réseau
Bloc IP concernés:
  - 178.32.14.96 /29
  - 176.31.2.204 /30

Le problmème a été identifié et corrigé
Les services sont à nouveaux disponibles

Une opération de maintenance est planifiée pour dimanche en fin de journée.

La maintenance va servir à installer Varnish sur le serveur afin d'améliorer les performances. 

Si les tests sont concluants, Varnish sera installé sur tous les serveurs. 

Depuis dimanche 18.08 à 23:30 Varnish est actif avec Apache et NGINX est désactivé. Les performances sont en cours d'évaluations.

Varnish est désactivé et le cache NGINX est en place.

Une maintenance hardware va être réalisée sur le serveur.

Ceci pourrait provoquer une interruption du service

Des travaux sont prévus sur l'Espace client. 

L'accès à cPanel sera possible en connexion direct sur le port 2083

Par exemple : https://votredomaine.fr:2083 

La coupure sur l'espace client devrait durer 1-2h maximum.

Merci d'avance de votre compréhension. 

Une mise à jour du Kernel va être effectuée sur tous les serveurs afin de corriger une faille de sécurité majeur concernant tous les noyaux Linux.

Les hébergements mutualisés seront hors service le temps du redémarrage du serveur.

Update 16.05 @ 07h00: Tous les serveurs ont les kernels à jour.

Le service www a été perturbé de 18h20 à 18h40 environs suite à une erreur sur NGINX.

NGINX a été désactivé et Apache a prit la relève en attendant que nos équipes trouvent l'erreur.

NGINX a été réinstallé. Tout fonctionne correctement.

Un redémarrage de l'infrastructure est planifiée pour mettre à jour le Kernel des serveurs

Opération terminée. L'infrastructure a été redémarrée et tous les serveurs sont opérationnels.

Une maintenance est en cours sur le serveur.

La charge est anormalement élevée même sans service actif.
Nos équipes en recherches la cause

Edit 16.04.2013 @ 08h00 : une mise à jour forcée de cPanel est en cours 

Information: Un second serveur sera prêt à prendre la relève dans la journée si les performances continues de chuter

Edit 16.04.2013 @ 23h30: La charge du serveur est toujours élevée. Tout porte à croire qu'un disque RAID est défectueux mais les statistiques du RAID sont bonnes.

Un second serveur (md-2.eurowh.com) est à disposition. Si vous voulez migrer votre hébergement sur ce nouveau serveur merci de contacter le support.

Edit 17.04.2013 @ 23h30: La charge est toujours élevée

Edit 18.04.2013 @ 21:00: OVH a effectué des tests hardware et tout est OK.

Edit 19.04.2013 @ 12:00: Des tests ont étés effectués ce matin avec un Kernel modifié pour limiter les I/O en écriture sur un des disques. Le kernel modifié n'a pas booté donc les tests sont repoussés à ce soir afin d'éviter des coupures en pleine journée. Un passage en PHP 5.4 sera également effectué. Ce changement a 2 buts. Améliorer la stabilité et forcer les clients à mettre les sites à jour pour ne pas être hacké avec les attaques en cours. 

Edit: 20.04.2013 @ 08:00: La maintenance programmée hier soir a visiblement porté ses fruits. La charge du serveur est restée faible malgré les sauvegardes et le trafic. Le serveur reste sous surveillance. Les sites devraient à nouveau fonctionner de manière optimales. 

Edit 26.04.2013 @ 23:00: Une grosse opération de sauvegarde va être lancée car la tâche de sauvegarde était interrompue depuis quelques jours.

Edit 11.05.2013 @ 23:00: Après avec procédé à de nombreuses analyses le problème de charge à été détecté. Il s'agissait d'un Forum PHPBB installé par un client qui était spammé et utiliser pour de la publicité intenpestive. Ceci générait une sorte de DDoS sur le serveur. L'hébergement est suspendu et la charge du serveur est passée de 15 à 1.8 en l'espace de 2 minutes.

Serveur Down

Un incident a été déclaré chez OVH pour suspicion de défaut Hardware et le serveur est tombé environs 30 minutes après. 

Le serveur Ping mais a été redémarré. Je suspecte les équipes d'OVH d'être en maintenance dessus mais je n'ai aucune info pour l'instant de leurs part.

Selon l'historique le NetBoot du serveur a été modifié par un technicien donc intervention hardware en cours. Pas de communication d'OVH pour l'instant.

EDIT 20h44 : Je vois le serveur en train de relancer les services, le netboot a été modifié et le serveur relancé. Il devrait être de retour dans quelques minutes. J'attend le feedback OVH si un défaut hardware a été trouvé et corrigé.

OVH a confirmé avoir effectué des tests Hardware et tout est OK. 
L'incident est clos et le statut est maintenu dans le ticket Maintenance

Une intervention vient d'être plainifiée afin de remplacer un module de prise en main à distance du serveur.

Le serveur sera mis hors service quelques minutes le temps de l'intervention

La maitenance est terminée et tout est fonctionnel.

Divers modifications ont étés appliquées sur le serveur pour divers raisons.

Le serveur utilise maintenant LiteSpeed à la place d'Apache.

Afin de passer à LiteSpeed il a été nécessaire d'apporter les modifications suivantes :

• Désactivation de PHP Selector
• Désactivation de CageFS

Le couple Apache - NGINX a été remplacé par Litespeed qui devrait être plus rapide et moins gourmand en mémoire. 

Litespeed est entièrement compatible avec les scriots Apache.

La fonction PHP Selector vient d'être desactivée pour des raisons de maintenance

Divers clients subissent des attaquent ce qui pourrait augmenter la charge du serveur de manière ponctuelle.

Un redémarrage du serveur est planifié afin de mettre le noyau Linux à jour sur le serveur. 

Le redémarrage ne devrait pas durer plus de 10 minutes.

La coupure sera annoncée quelques minutes avant via notre compte Twitter @EuroWH

Edit 5:30 : le serveur a été redémarré avec succès à 5:05.  Coupure effective de 7 minutes

NGINX vient d'être désactivé pour une opération de maintenance.

Aucun impact sur les sites à prévoir

Le service MySQL a été relancé manuellement pour une opération de maintenance. 

La coupure du service ne prend généralement que quelques secondes mais ce soir il aura fallu 10 minutes au service pour s'arrêter. 

Cette opération était voulue et pas liée à un défaut.

je suis navré de l'impact sur les sites en production et a l'avenir les coupure de service se feront en tard dans la nuit.

Il semblerait que les FAI français rencontre des problèmes pour résoudre les noms de domaines.

Un test sur les DNS des principaux FAI retourne une erreur
nslookup domain.tld

Alors que le même test sur des serveurs DNS publique fonctionne correctement

DNS Google:
nslookup domain.tld 8.8.8.8

Maintenance sur l'infrastructure Cloudflare.

Une panne des services Cloudflare (DNS et Proxy) a bloqué l'accès aux sites utilisants leurs technologies. 

La migration de VCP-2 vers la nouvelle infrastructure vient d'être planifiée.

La migration aura lieu dans la nuit du 19 au 20 février 2013.

Les comptes seront migrés sur MD-1 (md-1.eurowh.com : 37.59.32.3)

Une charge anormale est constatée sur l'infrastructure.

Une intervention est en cours

Notre infrastructure a subit une attaque de type DoS. 

La migration de VCP-1 vers la nouvelle infrastructure vient d'être planifiée.

La migration aura lieu dans la nuit du 13 au 14 février 2013.

Les comptes seront migrés sur MD-1 (md-1.eurowh.com : 37.59.32.3)

Une opération de contrôle des partitions est prévues lundi matin entre 5h30 et 7h30

Le serveur sera redémarré et un contrôle des disques sera forcé.

Une coupure de courte durée est à prévoir.

Une maintenance est en cours sur VCP-1 suite à une erreur lors du processus de backup.

Une mise à jour de PHP va être effectuée sur les serveurs

Redémarrage rapide de tous les serveurs pour le passage sur un nouveau kernel.

Interruption de max 5 minutes par serveur

Maintenance terminée.

Une des sondes de VCP-1 a forcé un redémarrage.

Une maintenance urgente a été effectuée sur le serveur pour un problème d'intégrité sur un disque.

Le serveur effectue un contrôle des disques puis sera à nouveau à disposition.

Le serveur devrait être disponible aux alentours de 21h30

Edit: L'erreur d'intégrité semble plus importante et d'autre test sont en cours

Edit 22h10: Les opérations sont toujours en cours

Edit 00h20: Un problème lié au Datastore est venu se greffer au problème d'origine. Le serveur doit donc être déplacé sur un nouveau Datastore. L'opération dure depuis plusieurs heures alors qu'elle n'aurait du prendre que quelques minutes. Tant que les données ne sont pas copiées je dois attendre.
Le opération vont continuer dès que le transfert sera terminé.

Edit 04h00: Lancement du FSCHK sur les disques. FSCHK ok en mode manuel

Edit 05h15: FSCK Ok en mode manuel, relance en mode automatique

Edit 05h45: Le serveur est en fonctionnement et les sites sont de retour

Depuis quelques jours (et plus particulièrement depuis ce matin) une instabilité est présente sur un des serveurs et provoque une surcharge ponctuelle inexpliquée.

Après quelques analyses il semblerait que le problème soit lié à une extension PHP qui ne supporte pas le fonctionnement d'Apache en Worker.

Un passage de Apache vers le fonctionnement Prefork est en cours

10:20 : Le passage en Prefork est terminé

Une attaque est en cours et sature le réseau.
Nous intervenons

L'attaque est sous contrôle

Un changement sur l'infrastructure de VCP-2 est en cours.

Le changement consiste à remplacer LiteSpeed! par Apache et NGINX en reverse proxy.
Ce changement va ramener une cohérence entre les divers serveurs étant donné que VCP-2 était le seul à utiliser LiteSpeed!.
Ce changement est transparent pour les utilisateurs hormis la modification de variable PHP via .htaccess qui n'est plus soutenue.

Pour toutes questions notre support est à votre disposition.

Afin de finaliser l'installation de divers patch de sécurité un redémarrage de certain serveurs est planifié comme suit :

VCP-1 : 06h50
VCP-2 : 06h55

La coupure ne va pas excéder 2 à 3 minutes par serveur.

EDIT: La maintenance c'est déroulée comme prévue et les serveurs sont en fonctionnements

Une attaque est en cours sur un des serveurs et amène à une perturbation sur le trafic.

Nos équipes ont coupés l'attaques et redémarré le serveur pour mettre un terme à l'attaque.

Le serveur est en redémarrage et une analyse des disques est en cours suite au redémarrage (procédure automatique de Linux).
La durée estimée est de 30 minutes

Des travaux d'optimisation du serveur sont prévus pour le 31 juillet entre 6h30 et 7h30.

Des travaux sont prévus sur l'espace client dès ce Week-end.

Une maintenance préventive est en cours.

Durée estimée 30 - 45 minutes

Une maintenance est en cours suite à un défaut.

Durée estimée 30 minutes

Le serveur VCP-1 va être coupé durant 30 à 45 minutes pour permettre l'ajout de RAM et divers optimisation.

Le serveur va également être redémarré sur un noyau CloudLinux plutôt que sur son noyau CentOS d'origine.

Edit 22h50 : Le serveur est en cours de redémarrage... il sera redémarré encore une fois

Edit 23:05 : Le serveur est redémarré et un check disk est en cours (durée environs 30 minutes)

Edit 23:40 : Le serveur est à disposition.

Une maintenance est en cours par 2 ingénieurs système à la recherche du problème de stabilité.

Un coupure temporaire n'est pas exclue

Le serveur VCP-1 subit de fréquent crash alors que les autres serveurs de l'infrastructure sont stables et ne présentent pas de problème.

Après avoir isolé 2 attaques massives et appliquer 2 Patch un Rollback de CloudLinux vers CentOS vient d'être effectué afin de tester la machine sans les fonctions de limitations.

Les analyses sont toujours en cours avec les développeurs de CloudLinux afin d'isoler le problème et les causes des crash.

Suite à des attaques à répétition nous appliquons un patch de sécurité renforcée sur le serveur.

Aucune attaque n'a pour l'instant abouti mais la fréquence et la teneur de ces attaques nous forces à appliquer le patch immédiatement.

21:55: L'installation est toujours en cours et devrait être bientôt terminée.

23:15: Le serveur est disponible et le patch installé

Bonjour,

un problème majeur au niveau des 2 disques RAID de Stitch empêche ce dernier de redémarrer correctement.

Une analyse des disques sur le serveur une fois redémarré en mode secours (disque non monté) ne montre aucune erreur et les tests sont concluents.

Une fois le serveur remis mode normal le démarrage ne s'effectue pas.

19.05 12:00 Le serveur est enfin reparti mais la connexion à CPanel - webmail - PHPMyAdmin ne s'effectue pas correctement.

19.05 13:00 Les connexions CPanel et Webmail sont rétablies.

Une migration des comptes hébergés sur Stitch va être effectuée vers la nouvelle architecture EuroWH qui devait être présentée que Lundi.

Le nouveau serveur est vcp-1.eurowh.com avec l'adreses IP 37.59.243.195.

La migration sera effectuée cette nuit

21.05 10:00 Un certain nombre de compte ont étés retirés du nouveau serveur et sont transférés à nouveau par l'équipe en charge de la migration des comptes. La raison est une erreur lors de la restoration de ces comptes.

Les comptes sont à nouveau migrés et sont réactivés les uns après les autres.

Le serveur de nom principal est basculé sur une nouvelle adresse IP dans une infrastructure haute disponibilité.

La nouvelle adresse IP du server est 37.59.243.193

Un problème de connectivité vient de se produire sur le serveur Stitch.eurowh.com

Visiblement plusieurs serveurs situé dans la même baie sont tombés simultanément.

Le problème est probablement au niveau connectivité.

Edit 12:20 :
Un redémarrage hardware à tout de même été tenté mais le serveur reste Down.
Le statut du ticket sera mis à jour dès que le technicien sera intervenu

Edit 12:30 :
Le server est à nouveau opérationnel.
Le défaut est en analyse.

Edit 12:36
Le serveur est retombé

Edit 13:00
Le serveur est à nouveau entièrement opérationnel.

Web Services Scheduled Downtime

Une mise à jour importante de CPanel a été effectuée ce matin.

Suite à cette mise à jour des problèmes récurents ont étés constatés sur le serveur mail lié à Stitch (webmail, pop, imap).

Principalement des lenteurs et des erreurs aléatoire au niveau webmail surviennent.

Visiblement la mise à jour à été effectuée à 95% et il y a une partie des fichiers qui n'auraient pas été mis à jour.

Un ticket est ouvert chez CPanel (2505631) afin de valider l'erreur et de trouver un correctif.

EDIT 17:00

Les performances devraient être meilleure. Un processus de backup était en cours et ralentissait de manière importante les performances du disque dur

Bonjour,

le système de redémarrage Hardware du serveur doit être remplacé.

Pour ce faire le serveur sera mis hors service le jeudi 5 avril à 6h.

Les techniciens seront sur place et superviseront les travaux et garantiront le redémarrage du serveur dans les meilleures délais.

Update 07h00:

Le système n'a toujours pas été mis hors service par les techniciens.

La fenêtre de maintenance est prolongée d'une heure.

Une intervention est en cours sur Stitch suite à une saturation du serveur sans raison.

Edit 01.04.2012 @ 01:00 :

Le serveur était bloqué sur une commande manuel concernant un test du HDD suite au Reboot.

Le technicien sur site à validé la commande et le serveur à pu terminer son démarrage.

Nous avons des problèmes de connectivités sur un des serveurs.

Une intervention est en cours.

Edit 15:15: Le serveur est à nouveau en fonctionnement

Edit 18:15: Le problème de stabilité du serveur est un bug au niveau consommation mémoire.

Un patch vient d'être installé et devrait rétablire la stabilité des services.

Edit 29.03 06:00 : Le serveur est stable depuis 12 jours.

Un problème de routage a causé des perturbations majeurs sur le réseau général d'OVH ce matin entre 04h45 et 06h15 environs.

Un ticket détaillant le dérangement est disponible chez OVH (http://travaux.ovh.net/?do=details&id=6533).

Le tout serait lié à un bug Hard/Soft sur les routeurs Cisco.

Le dérangement  a provoqué des indisponibilités des serveurs par alternance.

Edit 29.03 06:00 :

OVH a patché les routeurs cette nuit afin de corriger le bug.

La première partie de la migration des comptes clients est planifiée pour le jeudi 15 mars entre 5h00 et 7h00

Les clients concernés ont étés avisés par mail.

Une attaque est en cours contre Riri.

Le serveur est à nouveau fonctionnel mais encore chargé.

Une analyse est en cours.

EDIT 16:05

La situation est sous contrôle et la charge est de retour à un niveau normal.

Un des serveurs subit une attaque de type DDoS ce qui bloque ou ralentit l'affichage des sites.

Nous intervenons en ce moment afin de rétablire les services.

Une maintenance est prévue sur le réseau du Datacenter US.

Une coupure partielle de l'infrastructure US n'est pas exclue.

Please be advised that our Network Engineers will be performing an emergency maintenance with one of
our Austin border routers.

This preventative software upgrade is to ensure no future loss of redundancy on this host.

Date: January 26, 2012
Start Time: (06:01:00 AM)GMT
End Time: (10:00:00 AM)GMT

Si vous avez activé CloudFlare pour accélérer votre site ou simplement pour vous protéger des attaques il est possible que votre site ne réponde plus en ce moment.

En effet, CloudFlare a indiqué être la cible d'une attaque par Deni de service (DDoS) et les ingénieurs sont entrains d'isoler l'attaque et de remonter l'infrastructure.

Si vous désirez modifier vos enregistrements DNS pour permettre à votre site de remonter plus rapidement il vous suffira de suivre le tutoriel situé dans la rubrique Trucs et Astuces.

Un scan profond va être effectué sur l'ensemble des sites clients suites à un nombre élevé de site corrompu suite entre autre au problème lié à Timthumb.

La sauvegarde n'aura pas lieu ce soir afin d'accélérer le scan.

Le scan est programmé à 1h30 cette nuit et devrait durer plusieurs heures.

Le serveur est en cours de redémarrage pour l'application d'un patch.

Une seconde demande de redémarrage à été faite. Le serveur à redémarré à 15:40.

Les services sont Down mais le serveur Ping.

Les services sont en fonctionnements et le serveur est reparti normalement. La charge va grimper et ralentir le serveur dans les 15 prochaines minutes le temps aux sites de retrouver une charge normale (bcp de connection simultanées au redémarrage).

Le système de monitoring à signalé un problème sur le serveur de nom ns2.eurowh.com

Un reboot hardware du serveur à échoué et une intervention est en cours physiquement sur le serveur.

Le serveur de nom secondaire est basé sur un Cloud OVH et la panne est peut être liée à l'incident 6194

http://travaux.ovh.net/?do=details&id=6194

Le relais est assuré par NS1 qui est propulsé par un serveur standard.

Edit 23:30 : Le technicien à redémarré manuellement le serveur et tout est ok. Les services sont à nouveau assuré par les 2 serveurs de noms

Le serveur MySQL de RIRI doit être arrêté quelques minutes afin que les données soient déplacées sur une autre partition.

Les sites utilisant des bases de données seront indisponibles durant toute la durée de la maintenance.

Edit 31.12.2011: changement de date d'intervention

Le niveau de priorité de cette maintenance n'est plus critique.

L'operation est donc planifiée à un moment ou le trafic est moins important.

La fonction Suhosin va être désactivée sur les hébergements.

Cette désactivation oblige une nouvelle compilation de Apache et PHP.

Les sites clients ne seront pas impactés par cette modification et seul une micro coupure de l'ordre de 10 secondes aura lieu lors de l'activation des nouveaux modules.

EDIT: La mise compilation est terminée avec succès et tout est fonctionnel. Comme prévu il n'y a eu aucune coupure

Je viens d'être avisé qu'une attaque est en cours contre le Datacenter US et certains serveurs sont impactés.

Le problème est une saturation de la bande passante entrante ce qui perturbe l'accessibilité des sites.

Les spécialistes font le nécessaire pour contrer l'attaque et libérer la bande passante.

Ticket initial:

Our System Administration Team has discovered that there is an ongoing attack on one of our hosting server.
IMPACT:172.74 Mbps
TYPE: Incoming Bandwidth Profile

The destination is
cp-18.webhostbox.net(208.91.198.132)
and
208.91.198.132/32
208.91.199.192/26
208.91.199.224/30
208.91.199.204/31
208.91.198.48/28
208.91.199.200/30
208.91.199.0/25

Source of attack is from Vietnam.

Une opération de maintenance à provoqué une indisponibilité du serveur de l'ordre de 40 minutes.

Le Datacenter US subit actuellement une attaque et plusieurs serveurs sont injoignables.

Les spécialistes sont entrain de contrer l'attaque.

Etat du ticket :

Our Austin Datacenter is currently facing an attack.
Our Server Administration team is coordinating the same with our Datacenter technicians at present. You may face intermittent outages with sites hosted on the respective servers.

Affected servers are as follows :
cPanel Single domain hosting servers :
cp-18.webhostbox.net
cp-19.webhostbox.net
cp-20.webhostbox.net
cp-21.webhostbox.net
cp-22.webhostbox.net

cPanel Multi-Domain Hosting Servers :
md-1.webhostbox.net
md-2.webhostbox.net
md-3.webhostbox.net
md-4.webhostbox.net
md-5.webhostbox.net
md-6.webhostbox.net
md-7.webhostbox.net
md-8.webhostbox.net

All the hosting services will be affected.

Des travaux de maintenances sont planifiés pour les nuits du samedi au dimance et dimanche au lundi.

L'espace client peut-être par moment interrompu.

Les hébergements (sites) ne seront pas affectés par cette maintenance.

Le Datacenter situé au USA (Austin) a subit une attaque importante et de nombreux serveurs ont étés surchargés ce qui a perturbé les sites hébergés sur ces serveurs.

Le NOC m'a informé que tout est rentré dans l'ordre en fin d'après midi.

Le serveur est soumis à des attaques ce qui charge le serveur.

Nos équipes sont actuellement entrain de fixer le problème.

Suivi

18:20 : Un redémarrage du serveur est en cours

18:35 : Les service sont en cours de redémarrages

18:45 : Les services ont redémarrés

Le service de base de données est tombé à plusieurs reprise.

Après un certain nombre de manipulation le service est enfin en fonction.

Le service MySQL est en fonction stable depuis 7h30 environs.

Nous sommes entrain d'examiner les logs afin de trouver la provenance du problème et comment éviter que celui-ci ne se reproduise.

EDIT: 11.10

Visiblement un plugin de 1H Software servant à la limitation de la charge avait un impact négatif sur les services du serveurs. Plus de coupure depuis la désactivation du plugin

Une opération de maintenance sur un script de monitoring à fait tomber le serveur MySQL.

Ce dernier à eu beaucoup de mal à redémarer par ma faute (trop impatient j'ai systématiquement arrêté le redémarrage après 30 secondes pour chercher le problème alors qu'il lui fallait environs 3 minutes pour faire tombre MySQL proprement et le redémarrer).

Navré pour la coupure.

Afin de corriger une faille de sécurité de PHP 5.3 le serveur à été mis à jour avec la version de PHP 5.3.8

La charge du serveur étant trop élevée la mise à jour à été mise en attente. Afin que la tâche de mise à jour se termine correctement Apache et MySQL ont étés stoppés quelques minutes.

Tous les services ont redémarrés et la version de PHP est à jour.

Les serveurs vont être adaptés afin de supporter GIT.

L'intervention est programmée pour le vendredi 15 juillet 2011 entre 5h et 7h.

Cette intervention était prévue de longue date mais avait été repoussée suite aux problèmes de serveurs.

D'autre part, le port 9418 va être ouvert dans le Firewall pour l'utilisatin de GIT.

EDIT 15.07@06:45 :GIT est installé et le port 9418 ouvert dans le Firewall

Le serveur a subit une pointe de charge ce qui à rendu l'affichage des sites difficiles.

Le service MySQL a été redémarré afin de faire descendre la charge.

L'affichage des sites est à nouveau normale et la charge est stable.

Une maintenance est prévue sur riri et un redémarrage du serveur sera nécessaire.

La maintenance c'est déroulée comme prévu.

Un dérangement sur un des routeurs principaux d'OVH a entrainé une coupure de connectivité de quelques minutes sur l'ensemble des serveurs.

Pour plus d'information veuillez-vous reporter ici : http://travaux.ovh.com/?do=details&id=4700

Les serveurs viennent de subire une mini coupure réseau en raison d'une défaillance dans le Datacenter.

=> Information détaillée

Le serveur de nom secondaire vient de subir un défaut et doit être réinstallé.

Aucun impact sur les sites hébergés.