Nous venons de faire une maintenance ce dimanche matin afin de gêner le moins possible. Nous avions programmé la fermeture des Backs Office entre 10 h à 12 h 00 mais cela à pris un peu plus de temps. Ils sont de nouveau accessibles depuis 14 h 00. Durant la maintenance les sites étaient accessibles.
Je vous fais un compte rendu, c'est technique mais pour ceux qui veulent comprendre, je rentre dans les détails.
En quoi consistait cette maintenance :
1) Test de reboot
Cette maintenance consistait à effectuer des tests de reboot sur le serveur de base de données principal, le "Master". Cette machine est un HP 16 Core avec 64 Go de RAM ECC. Elle possède 8 disques SSD Intel de 120 Go et un disque de Boot interne. Nous avons retiré par prévention le disque de boot interne vendredi dernier, car nous craignons qu'il soit un point faible de la machine. On devient Parano ... avec l'architecture de serveur. Résultat 3 reboots réussis, la machine se comporte bien :-)
2) Restauration des Machines Virtuelles sur RAID iSCSI
Depuis mi-octobre nous testions une nouvelle manière de répartir les machines virtuelles. Au lieu de mettre la moitié des Machines Virtuelles sur le serveur de fichier n°1 et l'autre moitié sur le serveur de fichier n°2, ce qui est à l'origine de l'indisponibilité durant 4 heures dans la nuit de samedi 29. Nous avions monté une machine virtuelle en Raid 1 en iSCSI. Ainsi en cas de panne d'un des gros serveurs de fichiers, elle continue à fonctionner avec un seul disque sur le second serveur. C'est validé, ça marche. L'incident du 29 nous l'a prouvé sur les machines concernées. En revanche nous avons profité de cette maintenance pour procéder à la réparation du Raid. Résultat, même si ça évite la panne à chaud, ça ne fait que la reporter.... mauvaise piste :-/
Intervention lundi dans Data Center :
1) Serveur de fichier n°1
Jeudi dernier, nous avons réussi à resynchroniser les disques de notre serveur de fichier n°1. Il était tombé en panne samedi 29. Lundi, Jérôme retirera les derniers disques WD Green qui restent dans la machine et qui sont à l'origine de la panne. Maintenant la machine semble à nouveau bien tourner mais nous n'avons plus totalement confiance. Cette intervention devrait être sans incidence la machine n'étant plus en production.
On a contacté SUN / Oracle afin de changer la carte mère et toutes les cartes contrôleurs de ce serveur de fichiers. Si ce n'est pas possible, on mettra la machine au rencard.
Ce genre de machine coute quand même 30 000 euros pièce.... même si je pense que notre erreur a été d'utiliser des disques basse consommation d'énergie. Il n'est pas normal que lorsqu'un disque sur 48 lâche, l'ensemble de la machine plante, normalement le RAID c'est fait pour cela .....
2) Back up et réseau
Le serveur de video était doublé par un autre serveur dans un second data center. Normalement il nous aurait suffit de changer les points de montage et les vidéos seraient reparties. Mais nous avons rencontré un problème sur le réseaux OVH entre Roubaix et Paris qui nous a limité la bande passante à 100 M/s au lieu 1 Gb/s. Du coup les vidéos étaient servies lentement. Nous n'avons pas eu de réponse du support OVH pendant le weekend de la Toussaint. En fin de compte j'ai contacté le patron d'OVH qui a reconnu le problème et m'a expliqué comment contourner cette limite de 100 Mb/s.
Comme vous l'a expliqué Samir dans les commentaires, nous allons mettre en place un troisième niveau de back up sur le Cloud Amazon. En cas de perte du serveur de fichier Vidéo, le relais sera pris automatiquement sans coupure, puisque le player est devenu intelligent. Cela sera pleinement fonctionnel dans les toutes prochaines semaines.
Pour finir ...
5 Personnes travaillent à plein temps sur l'architecture WMaker avec 2 points quotidiens de reporting. A la fin du mois on publiera un schéma décrivant les modifications apportées à l'architecture. Conscients de la gêne que cela vous a procuré, nous avons élaboré les compensations que nous allons vous proposer dès demain.
Rédigé par Sébastien Simoni le Mardi 1 Novembre 2011
Je vais vous expliquer les choses techniquement et de la manière le plus exhaustive possible. En tout cas, de la façon dont j'aimerais qu'on me les explique en tant que client.
Nous rencontrons plusieurs problèmes qui, cumulés, nous compliquent la tâche.
Up-load vidéo :
Nous avons trouvé une solution pour rétablir l'up-load vidéo. Cela nécessite la modification de l'application ; ça prendra la journée. Une fois la modification effectuée, les vidéos pourront être lues depuis plusieurs serveurs. Actuellement, les vidéos sont lues depuis le serveur de back-up chez OVH. Cela nous permettra de réparer les volumes de disques défectueux du serveur de fichiers n°1. Nous disposons sur place d'une quarantaine de disques neufs dans leurs emballages (Seagate ES 2To). Adieu les disques Green de WesternDigital qui sont la cause de tous nos problèmes...
Opération data center / technicien OVH :
Cette nuit, nous avons demandé au technicien d'OVH d'intervenir sur notre architecture afin de rétablir l’up-load sur les vidéos. L'opération consistait à retirer un ensemble de plusieurs pools de disques afin de permettre à la machine de redémarrer. Etant donné qu'il s'agit de très grosses machines (48 disques), les checks de disque empêchaient le redémarrage.
Nous disposons de deux gros serveurs de ce type, un dans chaque baie, identifié par des étiquettes en façade et sur le panneau arrière. L'opérateur d'OVH n'a pas retiré les disques dans le bon serveur, mais dans le serveur de fichiers n°2. :-(
Cela a eu pour conséquence de nous couper de notre deuxième serveur de fichiers central. Nous nous en sommes rendus compte quasiment immédiatement, nous avons pu contacter le technicien au téléphone qui a reconnecté les disques. Cela a provoqué une coupure du service de 15 minutes vers 0h40 cette nuit. Il y a eu ensuite beaucoup de travail pour l'équipe car nous avons dû remonter des machines virtuelles et surtout traiter un gros problème SQL…
Resynchronisation base de donnée :
Un défaut sur un serveur de données a entrainé une perte de désynchronisation sur l'ensemble des serveurs SQL. En temps normal, 6 de serveurs de base de données sont en réplication mutuelle, avec les mêmes données partout. Cette nuit, l'application était en ligne, mais les données n'étaient plus cohérentes d'une base à l'autre. Nous avons à l’heure actuelle, relancé 3 serveurs de base de données, on continu... Cette situation est assez exceptionnelle, cela nous est arrivé une fois en 2006 pendant la nuit de Noël. Pour se prémunir de ce genre de risque, une photo de la base est faite tous les jours à 6h00 du matin ; nous stockons ces images de la base chaque jour avec 1 mois d'historique.
Nous avons pu garder les sites actifs. Seuls les back-offices ont été mis en maintenance de 4h00 à 6h30 du matin. Heureusement, nous n'avons pas eu besoin d'utiliser ce back-up. L'un des serveurs de bases de données avait été mis en stand-by hier à 19h00. Nous sommes repartis de cette base pour remonter des serveurs de base de données cohérents. En revanche, les modifications (Article, Photo ...) entre 19h00 et 3h00 du matin n’ont pas été sauvegardé . Tout le reste est en ligne.
Pour finir :
Nous avons bien conscience que cela fait beaucoup d'incidents en trois jours. Nous faisons le maximum pour revenir à une situation stable. Nous avons organisé un roulement des équipes pour résoudre au plus vite les problèmes. Une fois cet épisode terminé, nous allons modifier plusieurs aspects de notre organisation. Le seul point positif, c'est que nous avons réussi à limiter l'interruption de service à 15 minutes, cette nuit. Nous pensons raisonnablement rouvrir l'up-load des vidéos d'ici mercredi matin. Une fois que nous serons venus à bout de tout cela, je vous proposerai une compensation commerciale. Mais là on se concentre totalement sur les problèmes techniques. Je ferai un point en début d’après midi.
Maj 15h30 01/11 :
- Site : Temps de génération moyen des pages sous les >500 ms, c'est un peu plus lent que d'habitude mais la valeur s'approche de la normale.
- WebTV : le lancement des videos est toujours lent, système Uplaod progress bien samir donnera des détails en commentaire de la note.
Merci pour vos soutiens nombreux, On lache rien !!!!
Maj 00h00 01/11 :
- Site : temps de génération moyen des pages 280 ms.
- WebTV : Lancement des videos est normal, Upload des videos actif si vous avez votre propre domaine !!!
Maj 15h30 01/11 :
- Site : Temps de génération moyen des pages sous les >500 ms, c'est un peu plus lent que d'habitude mais la valeur s'approche de la normale.
- WebTV : le lancement des videos est toujours lent, système Uplaod progress bien samir donnera des détails en commentaire de la note.
Merci pour vos soutiens nombreux, On lache rien !!!!
Maj 00h00 01/11 :
- Site : temps de génération moyen des pages 280 ms.
- WebTV : Lancement des videos est normal, Upload des videos actif si vous avez votre propre domaine !!!
Nous avons subi une longue interruption de service. La panne a débuté à 19h45, les sites ont été remontés vers minuit. Nous sommes intervenus dès 19h50, mais la panne était assez grave.
Nous avons perdu notre serveur de fichier central. Ce genre de machine est très fiable mais en cas de problème, elle est très compliquée à relancer : le reboot peut prendre plusieurs heures.
Nous ne sommes pas arrivés à relancer le serveur de fichier. Aussi, nous avons dû utiliser le serveur de fichier situé dans un autre data center en secours. Cette machine en BackUp nous sert à remonter l'architecture de WMaker en cas de grave problème.
Nous avons perdu notre serveur de fichier central. Ce genre de machine est très fiable mais en cas de problème, elle est très compliquée à relancer : le reboot peut prendre plusieurs heures.
Nous ne sommes pas arrivés à relancer le serveur de fichier. Aussi, nous avons dû utiliser le serveur de fichier situé dans un autre data center en secours. Cette machine en BackUp nous sert à remonter l'architecture de WMaker en cas de grave problème.
Depuis début octobre, nous mettons en place une toute nouvelle architecture, les travaux seront finalisés fin novembre. Cela aurait réduit considérablement la probabilité de ce genre de panne et le temps d'indisponibilité...
Nous sommes désolé pour cette interruption de service, pour l'instant on se concentre sur la remise en route des +900 services de l'architecture et notamment les services de mail.
(Maj 1) 30/10 à 4 h 00 : Le service Mail est ok.
(Maj 2) 30/10 à 6 h 00 : Certains sites n'étaient pas accessibles par leur nom de domaine DNS : problème fixé. 30/10 à 6 h 00.
(Maj 3) 30/10 à 12 h 20 : Nous avons réglé depuis ce matin plusieurs disfonctionnements.
Cette nuit :
(Maj 1) 30/10 à 4 h 00 : Le service Mail est ok.
(Maj 2) 30/10 à 6 h 00 : Certains sites n'étaient pas accessibles par leur nom de domaine DNS : problème fixé. 30/10 à 6 h 00.
(Maj 3) 30/10 à 12 h 20 : Nous avons réglé depuis ce matin plusieurs disfonctionnements.
Cette nuit :
Le principal problème que nous rencontrons actuellement c'est les VIDEO.
Nous sommes intervenu dans la nuit dans le DataCenter de DC1 afin de redémarrer physiquement le serveur de fichier Video cela n'a pas fonctionné. Nous avons basculé sur un serveur de secours situé dans un autre DataCenter à Roubaix.
Actuellement :
Actuellement :
Il y a encore pas mal de problème sur les Videos notamment :
Upload Video / Photo -> service indisponible
Encodage Video -> service indisponible
Lecture des video -> lenteur épisodique
On a planifier une autre intervention sur le DataCenter de DC1 dans l'après midi, en attendant on essaie de trouver des solutions softs.
(Maj 4) 30/10 à 14 H 00
Uplaod des Photos est Ok
(Maj 5) 30/10 à 16 H 00
Quasiment tous le service à la normale nous avons redémarrer le Serveur fichier principal.
Nous allons essayer de mettre en service.
(Maj 6) 30/10 à 17 h 40
La tentative a avorté, ce qui à causé une interruption de back 30 min, revient à notre état initial mais toujours impossible d'envoyer des vidéos.
(Maj 7) 30/10 à 21 h 00
Nous avons remonté un maximum de services.
Mais on ne peut toujours pas uploader de vidéo.
Demain matin une équipe prend la relève et réglera le problème de ce serveur de fichier avec l'aide OVH.
(Maj 8) 31/10 à 10 h 00
Nous avons profité de la nuit pour déplacer nos backups sur le nouveau serveur de fichier.
Ce serveur devait entrer en service la semaine prochaine.
Nous allons l'utiliser pour relancer les services.
Nous pensons avoir stabilisé d'ici le début d'après midi.
(Maj 9) 31/10 à 17 h 00
Nous avons mis au point une technique sur le papier. Elle devrait nous permettre de reprendre la main sur le serveur de fichier central. On vient de commencer si cela réussis vous pourrez uploader à nouveau des videos,
en fin de soirée ou demain matin.
(Maj 4) 30/10 à 14 H 00
Uplaod des Photos est Ok
(Maj 5) 30/10 à 16 H 00
Quasiment tous le service à la normale nous avons redémarrer le Serveur fichier principal.
Nous allons essayer de mettre en service.
(Maj 6) 30/10 à 17 h 40
La tentative a avorté, ce qui à causé une interruption de back 30 min, revient à notre état initial mais toujours impossible d'envoyer des vidéos.
(Maj 7) 30/10 à 21 h 00
Nous avons remonté un maximum de services.
Mais on ne peut toujours pas uploader de vidéo.
Demain matin une équipe prend la relève et réglera le problème de ce serveur de fichier avec l'aide OVH.
(Maj 8) 31/10 à 10 h 00
Nous avons profité de la nuit pour déplacer nos backups sur le nouveau serveur de fichier.
Ce serveur devait entrer en service la semaine prochaine.
Nous allons l'utiliser pour relancer les services.
Nous pensons avoir stabilisé d'ici le début d'après midi.
(Maj 9) 31/10 à 17 h 00
Nous avons mis au point une technique sur le papier. Elle devrait nous permettre de reprendre la main sur le serveur de fichier central. On vient de commencer si cela réussis vous pourrez uploader à nouveau des videos,
en fin de soirée ou demain matin.
Nous avons été assez déçus par le changement de moteur de base de donnée.
La nouvelle base est bien plus robuste, mais nous attendions de meilleures performances.
En fait les gains ont été assez minimes, de l'ordre de 20 %.
Aussi pendant l'été nous avons cherché à optimiser dans les moindres détails le code du CMS.
Mais les améliorations n'ont influé que faiblement sur les résultats en production. Jusqu'à ce qu'on se rende compte que notre architecture de test au CampusPlex se comportait parfois de manière très différente par rapport à la prod.
La nouvelle base est bien plus robuste, mais nous attendions de meilleures performances.
En fait les gains ont été assez minimes, de l'ordre de 20 %.
Aussi pendant l'été nous avons cherché à optimiser dans les moindres détails le code du CMS.
Mais les améliorations n'ont influé que faiblement sur les résultats en production. Jusqu'à ce qu'on se rende compte que notre architecture de test au CampusPlex se comportait parfois de manière très différente par rapport à la prod.
Depuis lundi dernier, pour les utilisateurs de www.wmaker.tv nous avons mis en ligne une nouvelle fonctionnalité: la publication différée ... et je n'en parle que maintemant sur le blog ? Pourquoi ? A cause d'une chose dont on vous parle peu souvent, les aides en ligne.
Lors de l'élaboration de la Web TV, nous avions cherché à optimiser au maximum le formulaire de publication des vidéos. L'enjeu était de charger l'interface au minimum dans la partie supérieure du formulaire. Au moment de l'ajout du statut publication différée, on s'est retrouvé en manque de place. il n'y avait plus trop d'endroit disponible pour afficher les champs de sélection de la date et de l'heure de publication. Nous avons alors retravaillé la page en s'inspirant de la page article du CMS en V5. Nous avons libéré de la place en haut du formulaire en déplaçant la saisie des tags en bas de page.
Lors de l'élaboration de la Web TV, nous avions cherché à optimiser au maximum le formulaire de publication des vidéos. L'enjeu était de charger l'interface au minimum dans la partie supérieure du formulaire. Au moment de l'ajout du statut publication différée, on s'est retrouvé en manque de place. il n'y avait plus trop d'endroit disponible pour afficher les champs de sélection de la date et de l'heure de publication. Nous avons alors retravaillé la page en s'inspirant de la page article du CMS en V5. Nous avons libéré de la place en haut du formulaire en déplaçant la saisie des tags en bas de page.
Votre CMS préféré utilise Open Graph.
Si vous ne connaissez pas l'Open Graph Protocol, retenez qu'il s'agit d'une collection de balises inventées par Facebook pour décrire vos pages. Ces balises permettent d'ajouter du "sens" à vos contenus. Cela rend leur partage dans les réseaux sociaux plus efficace. Ces balises participent également à l'amélioration de votre référencement.
Si vous ne connaissez pas l'Open Graph Protocol, retenez qu'il s'agit d'une collection de balises inventées par Facebook pour décrire vos pages. Ces balises permettent d'ajouter du "sens" à vos contenus. Cela rend leur partage dans les réseaux sociaux plus efficace. Ces balises participent également à l'amélioration de votre référencement.
La page article et le module Mes notes permettent d'afficher un nouveau bouton de partage.
Après le bouton Google +1 en juillet, c'est au tour de LinkedIn de figurer dans la liste des réseaux sociaux disponibles. En cliquant sur ce bouton, vos lecteurs republieront vos articles dans leur fil d'activité LinkedIn.
Après le bouton Google +1 en juillet, c'est au tour de LinkedIn de figurer dans la liste des réseaux sociaux disponibles. En cliquant sur ce bouton, vos lecteurs republieront vos articles dans leur fil d'activité LinkedIn.
La page auteur, c'est la page qui liste tous les articles que vous avez écrits sur votre site. Par exemple, voici un lien vers ma page auteur sur le Blog de WMaker :
http://blog.wmaker.net/author/Jerome-Granados/
Cette page est structurée de la façon suivante :
- Nom de l'auteur
- Photo associée à son Account ID suivi d'une description personnalisable
- Liens vers les différents profils de l'auteur dans les réseaux sociaux
- Liste des articles rédigés par l'auteur sur le site
Cette page est désactivée par défaut, pour l'activer, éditez l'onglet "Infos relatives au site" depuis votre fiche profil dans le back office.
http://blog.wmaker.net/author/Jerome-Granados/
Cette page est structurée de la façon suivante :
- Nom de l'auteur
- Photo associée à son Account ID suivi d'une description personnalisable
- Liens vers les différents profils de l'auteur dans les réseaux sociaux
- Liste des articles rédigés par l'auteur sur le site
Cette page est désactivée par défaut, pour l'activer, éditez l'onglet "Infos relatives au site" depuis votre fiche profil dans le back office.
Nous avons changé ce matin tôt le système de base de donnée utilisé par WMaker depuis 2001. C'est une modification très lourde que nous préparons depuis 1 mois et demi. La conversion de la base de donnée a pris 8 heures.
Le service n'a connu aucune interruption pendant ce changement pour vos visiteurs. Nous avons seulement du couper l'accès au back office pour ne pas désynchroniser l'ancienne base avec la nouvelle.
Comme annoncé précédemment, nous allons changer de moteur de base de données dans la nuit. Nous profitons des grandes vacances pour faire cette manipulation sur laquelle nous travaillons depuis des mois.
Pendant cette bascule qui va durer une bonne partie de la nuit, nous allons fermer les backoffice de tous les sites. Les sites restants bien évidement actifs pendant la durée de la bascule.
Nous avons mis en place 2 équipes pour se répartir le travail afin d'être le plus réactif possible. En effet, nous prévoyons de nombreux ajustements demain toute la journée. La 1erè équipe va travailler cette nuit, la seconde arrive à 6 heures du matin pour prendre le relai.
Début des opérations 20h00 (GMT+2), vous pourrez nous suivre sur Twitter,
Pendant cette bascule qui va durer une bonne partie de la nuit, nous allons fermer les backoffice de tous les sites. Les sites restants bien évidement actifs pendant la durée de la bascule.
Nous avons mis en place 2 équipes pour se répartir le travail afin d'être le plus réactif possible. En effet, nous prévoyons de nombreux ajustements demain toute la journée. La 1erè équipe va travailler cette nuit, la seconde arrive à 6 heures du matin pour prendre le relai.
Début des opérations 20h00 (GMT+2), vous pourrez nous suivre sur Twitter,
Derniers commentaires
-
PIETRI le 09/07/2023
Déménagement dans un nouveau datacenter
-
Mohamed Rial le 09/07/2023
Déménagement dans un nouveau datacenter
-
PIETRI le 07/07/2023
Déménagement dans un nouveau datacenter
-
CONQ Frantz le 07/07/2023
Déménagement dans un nouveau datacenter
-
Jerome le 27/06/2023
Déménagement dans un nouveau datacenter
Tags
ajax
android
apps
architecture
article
authentification
blogs
CampusPlex
conférence
css
datacenter
design
diaporama
e-commerce
facebook
flash
forum
galerie
google
hébergement
iPad
iPhone
japan
maquette
mobile
module
newsletter
nom de domaine
openid
optimisation
petites annonces
podcast
presse
profiling
publicité
recherche
référencement
restriction
rss
sem
seo
serveur
sns
social
statistiques
support
tags
telechargement
twitter
une
upload
V4
V5
video
web 2.0
web semantique
webservice
webtv
WMaker
xml
