En route pour… le BGP / Changement de datacenter

PetitNuage en visite chez NeoTelecoms

Bonjour à toutes et à tous. Une importante opération de maintenance est programmée fin juin, dans la nuit du 28 au 29 et aura un impact sur la disponibilité des services.

De plus les adresses IP de Web4all vont toutes être modifiées au cours de cette nuit. Nous vous invitons donc à lire les explications qui suivent.

Si vous ne souhaitez pas tout lire, rendez-vous sur la partie la plus importante : Avant le déménagement ainsi que la suite : Le déménagement… Au sujet de la coupure : impact

 

 

 

Historique du projet Housing et BGP de 2013 à aujourd’hui

Le 07 avril 2013, Web4all lançait son projet En-route-pour-le-housing et faisait appel à la générosité de ses adhérents, clients, visiteurs pour acquérir une trésorerie permettant d’effectuer la migration avec ses mois de locations en doubles. En quelques jours seulement, l’objectif des 7777 € était atteint et même dépassé ! http://blog.web4all.fr/en-route-pour-le-housing-objectif-atteint/ Encore un grand merci à vous toutes et tous !

Quelques semaines après, le 9 juin 2013, nous réalisions notre premier ping et pouvions avancer sur la migration http://blog.web4all.fr/en-route-pour-le-housing-ca-ping/

L’été fut chaotique en raison de problème de BIOS sur les serveurs de virtualisation. Le problème fut corrigé début août après prêt de 4 semaines de dures journées et nuits de recherches.

Le 25 février 2014 à 11H28 nous recevions ce fabuleux mail de la part du RIPE :

We are pleased to welcome Association WEB4ALL as a Local Internet Registry (LIR) and member of the RIPE NCC.

Web4all obtenait alors le statut de LIR : https://apps.db.ripe.net/search/query.html?searchtext=ORG-AW16-RIPE#resultsAnchor

Le 26 février à 13H16 nous recevions une allocation d’adresses IPv6 :

We have allocated the following prefix of IPv6 address space to your registry fr.web4all: 2a01:9de0::/32

Toujours le 26 février, 13H19, allocation d’adresses IPv4… issu du dernier /8 disponible auprès du RIPE NCC :

We have allocated the following prefix of IPv4 address space to your registry fr.web4all (you will receive the assignment approval shortly): 185.49.20.0/22

Et pour finir, le 27 février à 12H32…… Web4all se voyait attribuer son AS !

The RIPE NCC has today assigned the following Autonomous System Number AS199712 to Association WEB4ALL

Nous allons y revenir dans la suite de cet article mais vous pouvez aussi trouver pas mal d’informations sur un de nos articles précédents : http://blog.web4all.fr/zimbra-attaques-projets-2014-et-salon-solution-linux/#bgp

Avril 2014, nous ajoutions deux serveurs de virtualisation portant à 6 le nombre d’hyperviseur (soit 1.5 To de RAM).

Mai 2014 : Web4all souscrit à une offre Anti-DDOS Arbor Networks, nous vous en parlions là : http://blog.web4all.fr/zimbra-attaques-projets-2014-et-salon-solution-linux/#ddos

Fin juin 2014 : mise en place des nouveaux firewalls, des routeurs BGP, déménagement dans la nouvelle baie, changement des adresses IP

Et nous devrions au cours de l’été 2014 recevoir trois serveurs de virtualisation ainsi qu’une unité de stockage (SAN).

Pourquoi un déménagement / migration

En 2013 Web4all a fait le choix d’une baie d’hébergement avec 46U disponible et 3kVA de capacité électrique. Nous avions alors cela :

  • 2 firewalls
  • 2 switchs 48 ports
  • 2 switchs 24 ports pour l’iSCSI
  • 4 serveurs de virtualisation
  • 1 serveur de backup
  • 1 baie de stockage (DAS)
  • 2 serveurs reliés au DAS pour publier les fichiers des hébergements
  • 1 SAN

Bref, ca donnait ça :

baie_sans_legende2013

 

Avec cela, on avait un peu de marge…

Le soucis, c’est que comme nous venons de le dire, nous avons depuis ajouté deux serveurs de virtualisation et même une baie Equallogic que Web4all s’est faite offrir en début d’année (d’occasion). Bien souvent la limitation dans une baie de serveurs est atteinte non pas la capacité à déposer des équipements… mais plutôt pas la capacité d’alimentation électrique.

Bref, ca donnait ça :

baie_sans_legende2013vs2014

 

A l’heure actuelle, nous dépassons quasiment en permanence cette capacité électrique de 3kVA. Bien que cela ne soit pas gênant en temps normal (nous pouvons monter à 3kVA sur chaque bandeau et nous en avons deux) cela serait une terrible erreur. En cas de perte d’une des arrivées électrique nous perdrions toute redondance car la seule arrivée qui serait encore active serait en limite.

Il s’agit là d’un problème dont nous avions pleinement conscience et nous n’avons pas attendu le mois de mai pour prévoir une issue de secours… Dès le mois de février nous étions en discussion avec notre commerciale de Neo Telecoms pour envisager de changer de baie (notre baie ne permettant pas de monter au-delà des 3kVA).

Après avoir étudié les différents avantages et inconvénients dans les différents datacenter où Neo Telecoms est présent et les différentes capacités électriques disponibles, nous avons optés pour le dernier datacenter Neo Telecoms, inauguré en septembre 2013 en plein cœur de Paris ! Une petite présentation ? 

Nous serons sur une baie de type haute-densité avec une capacité de 5kVA et la possibilité de monter à 7kVA si cela est nécessaire sans déménager à nouveau.

Et donc au final… voilà à quoi va ressembler la baie une fois déménagée et le matériel en cours de commande :

baie_sans_legende2013vs2014vs2014v2

 

Le but de cette opération est donc triple :

  • Mettre en place notre matériel dans une nouvelle baie afin de pouvoir accueillir encore plus de matériel ;
  • Avoir un seul interlocuteur pour le datacenter et réseau. Actuellement nous ne travaillons qu’avec Neo Telecoms mais le datacenter appartient à Equinix. Là nous n’aurons que Neo Telecoms comme interlocuteur ;
  • Mettre en place notre nouveau matériel réseau qui va nous permettre de diffuser notre AS et nos IP.

AS, IP… Késako ?

Le but de cet article n’est pas de détailler les points techniques, si vous souhaitez des informations vous trouverez cela sur mon précédent article : http://blog.web4all.fr/zimbra-attaques-projets-2014-et-salon-solution-linux/#bgp

On pourrait dire que désormais Web4all sera une (toute) petite partie d’Internet. Nous serons identifié en tant que Web4all et non plus Neo Telecoms (et avant 2013 nous sortions en OVH).

Avec la pénurie d’adresses IPv4 les adresses IP coutent chères et sont limités. Chez Neo Telecoms nous n’en avons que 64. Chez OVH 254 mais à plus d’un euros par IP et par mois… cela fait vite un sacré budget.

En devenant LIR, avec notre AS et nos IP nous allons disposer de 1024 adresses IP sans coût direct. Il y a en revanche des coûts indirect : l’infrastructure BGP notamment mais nous ne faisons pas tout cela que pour les IP.

Avant le déménagement

Vous n’avez rien à faire. La préparation est effectuée par Web4all. Manquant de connaissance dans le domaine du routage BGP, Web4all a fait appel à une société dont c’est le métier : un opérateur. Il s’agit de la société INEONET qui nous avait déjà aidé dans le projet en 2013 : http://www.ineonet.com

Un ingénieur d’INEONET travaille déjà avec nous depuis plusieurs semaines (mois, même…) pour préparer tout cela. Il a déjà configuré la partie routage dans leurs ateliers ainsi que les nouveaux firewalls puisque nous remplaçons nos pare-feu par des modèles plus puissants.

Cet ingénieur va monter sur Paris la semaine prochaine afin de mettre en place le matériel avec nous et valider le bon fonctionnement. Si tout est bon, alors nous pourrons passer à l’étape suivante.

Le déménagement… Au sujet de la coupure : impact

Autant ne pas perdre de temps et dire les choses rapidement : il y aura une coupure de service de 02H30 à 05H30 dans la nuit du samedi 28 juin au dimanche 29 juin.

Dans la nouvelle baie, nous aurons déjà les équipements réseaux en place (routeurs et firewalls).

  • Il nous faudra alors démonter de l’ancienne baie tous les serveurs, les baies de stockages, les swicths. Cela prendra environ 45 minutes ;
  • Ensuite nous allons charger le matériel dans nos véhicules et devoir faire la route de Saint-Denis à Paris 2. N’ayant pas d’avertisseur lumineux ou sonore, nous comptons environ 20 minutes de trajet ;
  • Nous déchargerons le matériel et le mettrons en place dans la nouvelle baie. Il faut compter 1H00 ;
  • Nous relançons le tout et effectuons des tests… comptez 30 minutes.

Nous arrivons donc à 2H35 soit 3H00 en laissant une petite marge. Mais il est fort probable si tout se passe correctement que nous parvenions à effectuer les opérations en moins de temps.

Web4all n’est pas en mesure d’avoir une infrastructure doublée pour effectuer une migration sans coupure. Bien que cela ait été étudié, le coût était de plus de 20000 € de matériel à acheter.

Durant ce temps là…

  • Les sites ne seront plus accessibles ;
  • Le webmail et les mails en POP / IMAP ne seront plus accessibles ;
  • Les mails seront TOUJOURS réceptionnés par un serveur dédié à cela chez ONLINE. Aucune perte de mail à prévoir. Il s’agit du fonctionnement habituel des MTA, donc c’est déjà en place ;
  • Les zones DNS seront toujours publiés chez ONLINE et OVH. Aucun impact donc ;
  • quelques personnes avec des polos Web4all courront dans Equinix PA2 et Paris… si vous êtes dehors cette nuit là ne prenez pas peur…

Et après le déménagement / la coupure ?

Web4all devra modifier les zones DNS afin de faire pointer sur les bonnes adresses IP.

  • Si vos zones DNS sont gérées par Web4all (ce qui est le choix par défaut pour vos domaines) alors vous n’aurez rien à faire ;
  • Si vos zones DNS ne sont pas gérées par Web4all alors vous serez contacté sous peu pour gérer cette modification ;
  • Si vous ne savez pas, alors dites-vous que si vous ne recevez pas de mails de notre part d’ici la migration c’est que vous n’avez rien à gérer.

Sachez que Web4all fera en sorte que les flux de l’ancien datacenter soient redirigés sur le nouveau durant quelques jours, la modification des IP dans les zones DNS ne sera donc pas urgente pour les clients gérants leurs zones. Nous vous contacterons dans les jours qui viennent.

Voilà je pense avoir fais le tour. Nous contacterons les clients qui ont des modifications à effectuer d’ici la migration. Pour les autres vous n’avez rien à gérer, Web4all s’en charge.

Une fois tout cela terminé, Web4all travaillera avec ses adresses IP qui ne seront donc plus liés à un fournisseur ni à un emplacement géographique. Nous ne devrions plus avoir de problématique de modification d’adresse IP dans le futur !

En vous remerciant de votre compréhension.

Note : le patch Zimbra devrait sortir dans les jours qui viennent selon l’éditeur Zimbra.

Quoi de neuf chez Web4all ?

Logo Web4all

Certains se demandent parfois ce qu’il se passe chez Web4all. Je ne parle pas forcément de ce qu’il se passe tous les jours, le tout venant, mais des évolutions ou modifications qui sont effectuées. Certaines modifications sont visibles, d’autres moins, voir, pas du tout. Aussi je vais prendre un peu de temps pour vous retracer les modifications effectuées ces deux derniers mois. Pourquoi ces deux derniers mois ? Car ils ont été très intense en terme de charge de travail et donc de rythme pour l’équipe ! Je vous parlerais aussi de ce qui est en cours de mise en place, ce qui est prêt à arriver. Je ne vous dévoilerais pas tout, j’en garderais un peu pour les semaines à venir. Parce que je ne vais pas tout annoncer d’un coup mais aussi car bien trop souvent des projets prennent du retard et les annoncer sans avoir la certitude qu’ils seront menés à terme, dans les temps est relativement frustrant, pour vous comme pour nous.

Bien que certains titres puissent contenir des termes techniques, je vais essayer d’être le plus compréhensible possible afin que tout le monde puisse prendre un minimum de plaisir à lire cet article. Si jamais une partie venait à être un peu trop complexe, je ne doute pas que vous passerez rapidement à la suivante. N’hésitez pas à nous laisser un commentaire, cela fait toujours plaisir et n’oubliez pas que vos critiques nous permettent d’avancer 🙂

Sommaire :

Comme vous pouvez le voir, cela fait quelques thèmes à aborder mais je resterais assez bref, ne vous en faites pas 🙂

Vous retrouverez les temps passés (approximatifs) sur chaque projet.

Les incidents de début novembre : causes, conséquences et mesures prises


Comme vous l’avez constaté, nous avons connu un début de mois de novembre assez douloureux. Alors que j’avais personnellement posé des jours de congés pour me consacrer à la finalisation d’un projet (sur la plate forme Web), j’ai passé mes journées à remettre en route l’architecture à plusieurs reprises. Nous avons eu plusieurs soucis qui se sont enchaînés et -ce n’est pas pour nous dédouaner- qui n’étaient pas forcément de notre fait.

OVH : notre fournisseur principal

Pour héberger les sites internet, les mails et tout ce qui va avec, nous louons des serveurs chez deux prestataires différents : OVH et Online. La majorité de l’infrastructure est basée chez OVH, à Roubaix. La partie étant chez Online à Paris sert principalement de redondance sur certains services et de sauvegarde. Nous avons fait le choix de ces prestataires pour différentes raisons. Ce sont des prestataires Français, basés en France, cela compte beaucoup à nos yeux.

Début novembre, premier samedi, OVH, notre prestataire principal donc, à réalisé une intervention sur son réseau, cette dernière s’est mal passée et a provoqué une coupure de service de notre côté. Il faut bien comprendre qu’une fois le réseau remonté, tout ne repart pas tout seul et pas tout de suite. Il y a pas mal d’interventions et de contrôles à faire de notre côté et cela prends du temps 🙁 Le lundi suivant, rebelote, mais consolation (si si ça rassure même si cela peut paraître surprenant)  nous étions loin d’êtres les seuls, énormément de sites hébergés chez OVH ont été impactés. Cela aura à nouveau provoqué une coupure d’une bonne trentaines de minutes.

La même semaine, le jeudi, OVH a effectué une opération de maintenance sur des noeuds de stockage que nous utilisons (nous utilisons du stockage particulier pour notre environnement de virtualisation des serveurs). Cette maintenance aurait dû être transparente en basculant sur un noeud secondaire… cela n’a pas du tout été le cas. La coupure à duré plus d’une heure, nous avons ensuite passé des dizaines d’heures à tout contrôler et à réparer certains disques de données qui ont été endommagés.

Comme si cela ne suffisait pas, pour vous comme pour nous, l’opération inverse à été effectuée le samedi. Oui, la même que le jeudi mais dans le sens inverse. Je ne vais pas vous faire un dessin, les conséquences ont été les mêmes que le jeudi… et même pire. En effet certains serveurs n’ont pas du tout appréciés la blague -notamment un des serveurs de stockage Zimbra pour les mails- et nous ont obligés à effectuer des opérations de maintenance qui ont duré plusieurs heures.

Voilà, nous avons fait le tour et ce fût bien suffisant ! Alors de notre côté nous ne sommes pas resté les bras croisés une fois tout redevenu fonctionnel hein 😉 Comme je vous le disais plus haut, le but de ces explications n’est pas de nous dédouaner. Nous avons pleinement conscience que de votre point de vue, vous avez un prestataire, en l’occurrence Web4all qui a ses prestataires et que ce qui compte pour vous c’est que le service soit pleinement fonctionnel. Nous ne pouvons pas nous réfugier en permanence derrière les loupés (et parfois ils sont humains) de nos fournisseurs. Donc nous avons pris des mesures pour améliorer la disponibilité de nos services.

Les mesures prises

Parce qu’un dessin vaut mieux qu’un long discours, voilà en quoi consiste les améliorations (ce ne sont que des schémas d’exemples, il ne sont pas à l’image exacte de l’architecture) :

Web4all Full HG

 

Sur cette image nous avons :

  • tout en bas, dans le rectangle gris : la couche stockage où sont stockées les données des serveurs virtuels
  • au milieu les serveurs physiques permettant la virtualisation. C’est ce que l’on appel des hyperviseurs
  • au dessus, les pool de ressources, une notion virtuelle qu’il n’est pas utile de détailler dans notre explication
  • tout en haut, les machines virtuelles « VM » qui peuvent se déplacer d’un hôte physique (hyperviseur) à un autre.
Comme le montre ce schéma, le gros avantage est de faire abstraction de la couche matérielle. Tous les chemins sont redondés et donc en cas de soucis sur un serveur physique, les ressources publiées (VM) seront publiées par un autre serveur physique car il a lui aussi accès au stockage et au même réseau.
Le problème dans notre cas, c’est que nous avons perdu la couche stockage, complètement, pour tout les serveurs physiques. Nous avons donc revu notre schéma. Nous avons conservé le fonctionnement que je viens de vous présenter pour certains services nécessitant de la haute disponibilité mais nous les avons doublés de manière logicielle.
Ainsi nous avons par exemple :
  • un répartiteur de charge (load balancer) A stocké sur le stockage 1
  • un répartiteur de charge (load balancer) B stocké sur le stockage 2

Si le stockage 1 tombe, alors le 2 sera présent pour assurer le fonctionnement du service et vice versa. Mais concernant les serveurs Web, nous sommes allés plus loin :

 

Web4all Mix HG EGSur cette image nous avons donc toujours la partie de gauche pour les services devant être hautement disponible mais nous avons ajoutés à droite des serveurs totalement autonomes. Ces serveurs présentent l’avantage de bénéficier de disques SSD. Ainsi les temps de lectures et d’écritures pour les logs d’Apache (les fichiers journaux dans lesquels sont enregistrés toutes les visites sur vos sites) sont considérablement diminués. Alors vous devez vous demander ce qu’il se passe si le serveur qui est tout à droite vient à être défaillant ? Ce n’est pas grave car sur la partie de gauche, notre fameux répartiteur de charge (load balancer) n’enverra plus de visiteurs sur ces serveurs. Il va donc gérer la répartition en fonction de la charge mais également de la disponibilité des serveurs.

Comme vous pouvez le voir nous avons amélioré la partie Web, il nous reste encore du travail afin de minimiser le plus possible les risques d’incidents, nous y travaillons… c’est perpétuel… 😉

A titre d’information, le temps passé sur ce projet est d’environ 100 heures.

Importantes modifications sur la couche réseau : pourquoi et comment ?


Jusqu’à il y a peu, nous avions un fonctionnement qui -il faut le reconnaître- était loin d’être optimal pour la gestion du réseau et des adresses IP. Chaque serveur avait une adresse IP publique et une ou plusieurs adresses IP pour publier les services. Des adresses, elles aussi publiques. Cela n’était pas très gênant car les adresses IP chez OVH étaient soient fournies avec les serveurs, soit à acheter en une fois et puis on ne payait plus rien tant que l’on conservait ces adresses (Il fallait compter 250 € pour 254 adresses IP – un /24).

Chez Web4all nous avions ce fonctionnement car il était hérité des début de l’association. A l’époque où nous n’avions que des serveurs physiques et pas de réseau privé.

Et puis en 2009 nous avons commencé à mettre en place la virtualisation, le réseau privé… mais sans forcément tout reprendre à zéro.

Il y a un peu moins de deux mois, notre prestataire OVH a décidé, en raison de la pénurie d’adresses IPv4 que désormais il faudrait payer 1 € par adresse IP et par mois ! Rien de plus normal me direz vous ! Après tout chez Online, nous fonctionnions déjà ainsi. Mais voilà, ce qui nous a un peu irrité c’est que OVH avait pleinement conscience de la situation quant à la disponibilité des adresses IPv4 ces dernières années et a indirectement incité les clients à utiliser ces IP à faible prix. Changer les règles du jeu d’un mois sur l’autre, sans délais, cela n’est pas très correct… Bref, c’est ainsi, on fait avec, pas le choix de toutes façons…

Alors du coup on a tout revu… on a tout repris à zéro. On a pris une feuille de papier, un stylo et on a fait comme si on démarrait une nouvelle infrastructure. Sans se poser de questions sur les modifications à effectuer car sinon, on avance pas. Nous avons donc définit un réseau entièrement privé. Nous l’avons découpé afin de pouvoir s’y repérer un peu. Nous en avons profité pour mettre en place des serveurs DNS à utilisation interne, en faisait notamment appel au Split-DNS.

Le Split quoi ? Petite explication rapide 😉 Quand vous tapez www.web4all.fr dans votre navigateur, ce dernier effectue ce qu’on appel une requête DNS afin de savoir sur quel serveur se trouve le site internet de Web4all. Un peu comme vous utilisez un annuaire. Et là le serveur DNS répond à votre ordinateur en lui donnant l’adresse du serveur de Web4all.

Alors le Split DNS, ca sert à quoi ? Cela permet d’obtenir une réponse DNS différente en fonction de l’origine de la demande. Ainsi un serveur Web4all obtiendra en réponse de type privé là où un serveur externe à Web4all obtiendra une réponse publique.

Un petit exemple concret : dans le cadre de votre hébergement Web4all, vous disposez de bases de données MySQL. Vous pouvez vous connecter de chez vous sur le serveur MySQL et vous passez par le Firewall de Web4all. Par contre lorsque la connexion provient d’un serveur Web, afin de minimiser le chemin parcouru au niveau réseau, nous irons directement du serveur Web au serveur MySQL en restant dans un réseau 100% privé. Cela, car le serveur DNS, va indiquer aux serveurs Web que le serveur MySQL se trouve sur le réseau privé.

Web4all Split-DNS

 

Revenons en à notre réseau… Nous avons donc dû tout basculer sur notre nouvel adressage réseau. Les modifications sont énormes côté Web4all puisque nous sommes passés de plus de 250 adresses IP utilisées (mal utilisées !) à moins de 40 !

Nous avons mis en place deux serveurs qui font office de pare-feu (Firewall) et de passerelles pour l’ensemble de nos serveurs. Il s’agit d’un serveur Maître et un serveur Esclave. En cas de défaillance du Master, le Slave prend immédiatement la relève, en moins d’une seconde. Pour se faire nous utilisons une technique basée sur l’ARP qui permet au Slave de traiter tous les paquets réseau même si il n’en a pas besoin. Si le Master tombe il est donc déjà opérationnel et n’a plus qu’à envoyer le tout aux serveurs de l’architecture.

Voilà au final nous ne conservons que 254 adresses IP ! Et tout cela ne s’est quasiment pas vu, nous sommes parvenu à effectuer toutes les modifications en toute transparence. Il y aura eu une seule coupure qui était inévitable pour basculer le coeur (stockage) au cours de la nuit mais qui a été de courte durée.

254 ??? et oui. Avant nous avions un bloc de 8, un bloc de 32 et deux de 254. Nous avons donc réduit à un de 254 mais nous ne pouvons pas descendre plus bas. En effet, beaucoup de prestataires, lorsqu’ils décident de bannir une adresse IP qui émet du SPAM, bannissent les 254 adresse de la plage, le /24 ! Aussi si nous souhaitons continuer à offrir une qualité de service quant à la délivérabilité des emails, nous sommes dans l’obligation de conserver ces 254 adresses 🙁

A titre d’information, le temps passé sur ce projet est d’environ 200 heures.

Nouveau serveur MySQL pour vos bases de données


Le samedi 24 novembre nous avons changé le serveur MySQL qui héberge vos bases de données. Changement de serveur physique mais également de version logicielle !

Web4all MySQL 5.5

La version de MySQL est désormais la 5.5.28, soit la dernière version stable de chez MySQL ! Les utilisateurs peuvent donc désormais disposer des triggers, ce qui n’était pas possible dans les versions précédentes en environnement mutualisé. Les différences de performances sont énormes si l’en en croît les dires de Oracle (éditeur de MySQL). Dans les faits, il est vrai que le serveur est bien moins chargé qu’auparavant. Mais cela s’explique également pour d’autres raisons. En effet comme dit précédemment, nous avons également procédé au remplacement du serveur qui héberge le service MySQL. Nous sommes désormais sur la gamme 2013 de serveur OVH. Ce nouveau serveur bénéficie comme l’ancien de disques SSD nous permettant de maximiser les performances mais ce serveur nous apporte surtout une grosse quantité de RAM puisque nous bénéficions désormais de 64 Go de mémoire vive. Le processeur aussi a pris un petit coup de jeune, puisqu’il s’agit d’un Intel Xeon à 12 coeurs.

Web4all EG 64G SSD

Il faut savoir que la migration en version 5.5 n’est pas aisée. En effet, si MySQL gère très bien l’upgrade de version, cela devient très long lorsque le serveur a beaucoup de bases de données à gérer. Sur ce serveur, Web4all gère un peu plus de 4000 bases de données. La procédure d’upgrade aurait été bien trop longue et l’indisponibilité qui avec… Nous avons donc du scripter afin d’exporter les bases de données en fonction de ce qui était enregistré dans notre manager (nous ne souhaitions pas nous baser sur la base « mysql » du serveur) puis procéder à un import sur le nouveau serveur puis remettre les droits qu’il faut sur chaque base et redéfinir les mots de passe des utilisateurs… Un beau chantier qui s’est parfaitement bien déroulé 🙂

Pour information voici quelques chiffres relatifs au serveur MySQL :

  • Trafic réseau depuis le démarrage : 6,5 Tio
  • Ce serveur MySQL fonctionne depuis 8 jours, 17 heures, 23 minutes et 46 secondes. Il a démarré le Sam 01 Décembre 2012 à 13:32.
  • Trafic par heure
    • Reçu 1,8 Gio
    • Envoyé 30,1 Gio
    • Total 32 Gio
  • Questions depuis le démarrage : 614 011 598 
    • ø par heure: 2 932 297
    • ø par minute: 48 872
    • ø par seconde: 815

Cela commence à faire 🙂 Nous en avons donc profité pour apporter pas mal de modifications à la configuration afin d’optimiser le plus possible. Nous continuons à surveiller et affiner nos réglages.

J’y reviendrais par la suite mais nous avons également revue notre politique de sauvegardes ce qui nous permet de décharger un peu le serveur 🙂

A titre d’information, le temps passé sur ce projet est d’environ 100 heures.

Nouveau système de sauvegarde MySQL, mails et fichiers : finalisation des tests


Depuis fin 2011 (oui oui, un an !) nous développons  un nouveau système de sauvegardes. Ce système concerne trois domaines :

  • les bases de données MySQL
  • les fichiers des sites internet
  • les emails de la plate forme Zimbra
Bien que ce qui est actuellement en place n’est pas forcément la version finale, elle en est très proche… Je vais donc vous en annoncer une partie, voilà à quoi devrait ressembler l’offre de sauvegarde sous peu de temps (attention il s’agit de données en cours d’étude, aucune garantie que ces données soient conservées) :
  • Bases de données :
    • une sauvegarde par jour
    • Durée de rétention : 30 jours
  • Fichiers :
    • un cliché (snapshot) toutes les heures. Durée de conservation : 3 jours
    • un cliché (snapshot) tous les jours. Durée de conservation : 21 jours
    • un cliché (snapshot) toutes les semaines. Durée de conservation : 6 semaines
    • un cliché (snapshot) tous les mois. Durée de conservation : 3 mois
  • Email Zimbra :
    • une sauvegarde complète chaque dimanche
    • une sauvegarde différentielle chaque jour
    • Durée de rétention : 30 jours
A savoir :
  • Toutes les données sont à Roubaix.
  • Toutes les sauvegardes seront donc à Paris. Deux sites géographiques différents. Deux prestataires différents.
  • Le système fonctionne actuellement en parallèle du système en production.
La grande nouveauté, toute récente, c’est sur la partie MySQL. Nous avons mis en place un répliqua du serveur à Paris, ainsi nous effectuons les sauvegardes depuis le répliqua ce qui permet de minimiser l’impact sur le serveur de production.
A titre d’information, le temps passé sur ce projet est d’environ 1500 heures.

Zimbra 8 Open Source Edition : mise en place généralisée pour tous les clients


Comme vous avez pu le constater le week-end dernier, la plate forme de messagerie a été mise à jour. En effet nous avons mis en place la nouvelle version de VMware Zimbra : 8 Nous vous avions déjà présenté la version 8 lors de la sortie de la version bêta ( http://blog.web4all.fr/tag/zimbra/ ).

Quelques difficultés lors de la mise en place, notamment sur le protocole POP. Cela a été corrigé dans la journée de lundi, nous vous prions de nous excuser pour la gêne occasionnée.

Le plus compliqué aura été sur un des serveurs de stockage qui ne s’est pas correctement mis à jour. Il m’aura fallu y passer plus de 30 heures pour corriger le problème. Zimbra fonctionne avec 100 bases de données par serveur, 96 de ces bases n’avaient pas correctement été mises à jour. Il aura fallu corriger manuellement cela. Vous pouvez retrouver l’historique de cette intervention sur les forums de l’association Web4all.

A titre d’information, le temps passé sur ce projet est d’environ 100 heures.

 

Zimbra Network Edition : fin de la période de tests et abandon du projet


Il y a un peu plus d’un an, nous avions mis en place une infrastructure Zimbra Network Edition. Cette version apporte quelques suppléments par rapport à la version Open Source Edition utilisée chez Web4all :

  • sauvegardes natives sur 30 jours
  • synchronisation avec téléphones mobiles
  • connecteur pour Microsoft Outlook
  • prévisualisation des pièces jointes avec conversion HTML

Seulement, le coût des licences nous aurait obligé à vendre ces boites mails pour environ 4 à 5 € par mois et par compte mail. Les clients avec qui nous en avons parlé ont trouvé le coût trop élevé au regards des apports de cette version. Ainsi il nous a été demandé si nous pouvions mettre en place une offre Exchange… c’est à l’étude ! 🙂

Quant au projet Zimbra Network Edition, il est donc abandonné. En revanche nous réfléchissons actuellement à vous apporter quelques nouveautés sur la version Open Source 🙂 Je n’en dirais pas plus 😉

A titre d’information, le temps passé sur ce projet est d’environ 1000 heures.

 

 Modifications du nommage : DNS, FTP, MySQL


En septembre 2011 nous avons déployé la nouvelle architecture de messagerie. Zimbra Open Source en version multi-serveurs. Nous avions alors dû modifier le nommage des serveurs. Nous avons alors mis en place des noms tels que mx1.web4all.fr ; mx2.web4all.fr…

Aujourd’hui nous utilisons pour certains noms .web4all.fr et pour d’autres .w4a.fr (les DNS, le FTP, le MySQL)…

Beaucoup de clients nous ont indiqués préférer les noms en .web4all.fr car plus parlant pour eux. Côté support nous avons aussi moins de soucis lorsque les noms utilisés sont en .web4all.fr

Aussi, nous avons décidé que nous allions tout passer en .web4all.fr afin d’être le plus cohérent possible :

  • ns1.w4a.fr – sdns1.w4a.fr – sdns2.w4a.fr
  • ftp1.w4a.fr
  • sql1.w4a.fr
Vont donc devenir :
  • ns1.web4all.fr – ns2.web4all.fr – ns3.web4all.fr
  • ftp1.web4all.fr
  • mysql1.web4all.fr

Comment cela va-t-il se passer en pratique ?

Pour la partie DNS

Rassurez vous : vous n’aurez rien à changer !
Les noms en .w4a.fr continueront d’exister.
Les sites existants et dont les domaines sont chez Web4all seront basculés en .web4all.fr par soucis de cohérence mais cela sera totalement transparent.
Les sites dont les domaines ne sont pas chez Web4all pourront donc continuer d’utiliser les noms en .w4a.fr
Les futurs sites seront mis par défaut sur les nouveaux noms.
A savoir : vous pouvez dès à présent utiliser ces nouveaux noms pour vos domaines !

Pour la partie FTP

Le nom en .w4a.fr continuera d’exister. Là aussi vous n’aurez rien à changer. Il y aura cependant un message d’erreur pour le certificat SSL qui ne correspondra pas au nom du domaine utilisé mais cela n’empêchera pas le fonctionnement de vos applications FTP.
A savoir : vous pouvez dès à présent utiliser ce nouveau nom pour votre FTP !

Pour la partie MySQL

Là aussi… le nom en .w4a.fr continuera d’exister ! Et là aussi… vous n’aurez rien à changer. Vous pouvez modifier le nom si vous souhaitez uniformiser les données que vous utilisez mais cela est vraiment, sans importance 🙂
A savoir : vous pouvez dès à présent utiliser ce nouveau nom pour vos connexions MySQL !

Nouvelles offres d’hébergements… et nouveaux tarifs

Depuis 2010 nous n’avons pas modifié les tarifs des hébergements. Et pourtant nos dépenses ont considérablement augmentées ! Ce n’est pas compliqué, elles ont triplées. Et je ne parle même pas des 250 € mensuel que nous allons devoir désormais payer pour les adresses IP dont je vous parlais plus haut.
Aussi, nous n’avons pas le choix. Il ne s’agit pas de vouloir mettre en place des nouveautés pour une minorité des clients mais bien de l’ensemble de la plate forme et nous ne pouvons pas faire plus économique sans altérer la qualité de service.
L’autre problème que nous avons, c’est que beaucoup de prestataires proposent des hébergements avec des espaces disques (FTP) énormes mais où les autres critères sont très médiocres… Malheureusement, la majorité des clients regardent en premier la quantité d’espace disque et du coup, passent leur chemin quand ils voient les offres de Web4all 🙁
Aussi nous avons pris la décision -qui nous déplaît au plus profond de nous même- d’augmenter considérablement l’espace disque des offres.
Sans trop vous donner de détail car la grille n’est pas finalisée à 100 %, les nouvelles offres devraient :
  • être plus simple à comprendre : 6 offres + 6 offres HS actuellement –> passage sur 4 offres
  • contenir plus d’espace disque : environ 10 fois plus en moyenne
  • proposer des boites mails plus importantes : 5 Go –> 10 Go
Les augmentations seront annoncées d’ici quelques jours et nous permettrons à tous les clients ayant des abonnements en cours, de les renouveler pour une année supplémentaire aux anciens tarifs pendant une durée de un mois comme définit dans les conditions générales d’utilisations.

Le mot de la fin

Si vous êtes arrivé jusqu’ici, je ne peux que vous remercier pour votre attention ! Sachez que cette semaine, me concernant, je suis en congés et donc vais pouvoir finaliser certains projets en cours. Une semaine pleinement consacrée à Web4all. La semaine se terminera en beauté puisque l’équipe de Web4all va se réunir sur Paris pendant deux jours. Nous vous posterons quelques photos sur les réseaux sociaux 🙂

Bonne semaine à toutes et à tous 🙂

Aurélien PONCINI,

Président de Web4all.