Archive for June, 2011

Support H+4 ou J+1 pour votre serveur ?

Wednesday, June 15th, 2011

Nous devons souvent conseiller nos clients sur le choix du support H+4 ou J+1 pour leur serveur. En théorie un support H+4 permet d’obtenir un matériel de remplacement en moins de 4h 24h/24, alors qu’un support J+1 permet de déclarer l’incident uniquement en heures ouvrées (du lundi au vendredi de 9h à 18h) et de l’obtenir 1 jour ouvré après.

Pour aider à cette décision, je vous propose de profiter d’un incident traité la nuit dernière par notre équipe de sysadmins. Il s’agit d’un soucis classique avec un disque défectueux sur un serveur DELL PowerEdge en support H+4. Voici l’historique précis de l’incident :

Mardi 14 juin 23h45 : le controleur RAID du serveur nous remonte une alerte : un disque OFFLINE.

Mardi 14 juin 23h50 : notre sysadmin d’astreinte intervient sur le serveur pour vérifier l’alerte. Une fois confirmée, il reste à collecter les différentes informations nécessaires à l’appel au support (numéros du serveur, logs à transmettre au technicien, etc.)

Mercredi 15 juin 00h05 : appel au support DELL. Vu que l’on est en heures non ouvrées, on passe donc par le support 24/24. À bien noter que le support 24/24 est exclusivement en anglais (si vous comptez faire intervenir une personne ne parlant pas la langue de Shakespeare, c’est raté). La conversation avec le technicien DELL peut être longue car selon son humeur il va demander de lui envoyer par mail le résultat de certaines commandes, chercher lui-même dans sa base de connaissances, etc. Le délai est clairement variable à cette étape. De notre côté, l’appel a duré 52 minutes !

Mercredi 15 juin 01h00 : départ en urgence pour le datacenter, le technicien DELL exigeant une vérification visuelle du disque et de ses numéros de série.

Mercredi 15 juin 01h20 : arrivée au datacenter, il faut maintenant passer tous les accès, sortir le disque concerné et envoyer un email de confirmation au technicien DELL.

Mercredi 15 juin 01h30 : l’email “final” est envoyé à DELL.

Mercredi 15 juin 02h00 : sans confirmation par mail ou téléphone, une relance par mail est faite.

Mercredi 15 juin 02h20 : le technicien DELL rappelle pour confirmer qu’il vient de prendre en compte l’email. Tout lui parait OK, il lance donc la procédure de remplacement du disque défectueux.

Mercredi 15 juin 03h00 : on reçoit un email de DELL nous donnant une estimation d’arrivée du disque pour 05h00… on ignore cependant si c’est GMT+1 (comme pour notre interlocuteur chez DELL) ou bien GMT+2

Mercredi 15 juin 05h01 : on reçoit bien le disque par “Taxi Colis”. Je vous fais grâce de la suite des opérations, pas très intéressantes pour illustrer le sujet.

En conclusion, environ 5h entre le début de l’incident et la réception du matériel, soit un peu plus de 4h entre l’appel au support DELL et la réception du disque. Dans un cas général, les constructeurs respectent donc pratiquement leur engagement H+4… mais il ne faut pas négliger le temps nécessaire à analyser le problème avec le support (de quelques minutes à plusieurs heures selon l’incident matériel) et le plus important : s’assurer d’avoir une bonne infogérance 24/24 ! Sachant qu’un support H+4 coûte quelques centaines d’euros supplémentaires à l’achat, qu’il est possible en complément (ou à la place !) d’avoir une partie du matériel en spare… ou même un 2e serveur (ou plus) qui pourra prendre le relai à chaud ou en secours… vous avez presque tous les éléments en main : à vous de choisir !

Bilan de l’IPv6day Evolix

Monday, June 13th, 2011

Evolix infogère des centaines de serveurs chez différents hébergeurs français. À l’occasion de l’IPv6day (mercredi 8 juin 2011), nous avons pu vérifier le déploiement d’IPv6 chez chacun d’eux. Pour certains, c’était déjà en place (parfois depuis des années), pour d’autres c’est beaucoup plus “problèmatique”. Petit bilan sans concession :

– JAGUAR NETWORK : OK pour l’IPv6
– LOST OASIS/IELO : OK pour l’IPv6
– DEDIBOX/ONLINE : OK pour l’IPv6
– OVH : OK pour l’IPv6
– GANDI HOSTING : OK pour l’IPv6
– IKOULA : #FAIL pour l’IPv6 ; malgré une communication autour d’IPv6 (?!), réponse reçue : “Nous vous invitons à contacter le service commerciale à sales@ikoula.com.”
– AMAZON EC2 : #FAIL pour l’IPv6 ; IPv6 est déclaré comme “non supporté”…
– NEXTO : #FAIL pour l’IPv6, réponse reçue : “Aucun planning n’est actuellement prévue pour la migration IPv6.”
– ILIAD ENTREPRISES : #FAIL pour l’IPv6, réponse reçue : “pour le moment ca n’est pas possible, on espère pouvoir le fournir prochainement mais je ne peux pas donner d’échéance précise pour l’instant.”

Côté fournisseur d’accès français, ça sera plus rapide, seul Nerim offre un accès natif depuis presque 10 ans. Free s’y est mis plus récemment en proposant un accès 6to4rd : c’est moins bien qu’un accès natif notamment car cela signifie qu’IPv6 n’est pas déployé sur le cœur de réseau, mais Free a permis une mise en œuvre très facile : il suffit de cocher une option sur une interface web pour activer l’IPv6.

Pour l’IPv6day, Evolix a donc proposé à tous ses clients d’activer leurs services en IPv6 pour ce jour là, notamment de les aider à ajouter temporairement un enregistrement DNS AAAA sur les noms de domaines les plus utilisés. Le taux de réponse a été très faible, et nous remercions notamment les sites web http://www.itsartmag.com/ et http://www.chambresapart.fr/ d’avoir joué le jeu.

Sur la partie technique, l’activation de nos propres services et ceux de certains clients ont montré que tout est quasiment prêt. Le soucis majeur n’est plus vraiment de se préoccuper si cela marche ou pas, mais d’avoir une qualité de service au moins équivalente à l’IPv4. De façon plus terre à terre, l’enjeu n’est plus d’arriver à faire un ping6 ipv6.google.com ou de voir la tortue danser sur www.kame.net MAIS d’avoir des temps de réponse corrects. Concrètement, à cause de l’utilisation de nombreux tunnels IPv6, mais aussi d’infrastructures IPv6 expérimentales et moins robustes chez les opérateurs et fournisseurs d’accès, on a souvent constaté des temps de réponses dégradés en IPv6 pour l’utilisateur final. Par exemple, depuis un accès donné, un site web qui répondait en 50ms en IPv4 peut se retrouver à répondre en 200ms en IPv6…

Pour conclure, l’IPv6day a permis de valider le bon fonctionnement d’IPv6 en parallèle d’IPv4 ; il faut surtout rester vigilant sur la qualité des services accessibles en IPv6, notamment en terme de temps de réponse (tout n’étant pas parfait sur ce point, je conseille d’ailleurs de désactiver pour l’instant les doubles enregistrements DNS A et AAAA sur vos noms de domaine). Par contre, l’obstacle principal à IPv6 reste la partie communication, et l’on voit que des évènements comme l’IPv6day ne suffisent pas : pour forcer tout le monde à s’intéresser à IPv6, il faudrait que des moteurs de recherche comme Google pénalisent les sites web n’étant pas accessibles en IPv6. Prochaine étape ?