Posts Tagged ‘dell’

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 !

Driver bnx2 du noyau Lenny et carte Broadcom NetXtreme II

Friday, May 8th, 2009

Le driver bnx2 du noyau Linux 2.6.26 de Debian Lenny (et du 2.6.24 d’half-and-etch) nécessite un firmware pour fonctionner avec les cartes réseau Broadcom NetXtreme II (présentes par exemple sur les serveurs DELL PowerEdge 1950/2950), au contraire du noyau Linux 2.6.18 de Debian Etch. Lors de la mise-à-jour vers l’un de ces noyaux, il faut donc installer le paquet firmware-bnx2 (section non-free) et s’assurer de mettre à jour les images initramfs (update-initramfs -u -k all).

Pseudo-cartes RAID DELL/Adaptec

Saturday, February 23rd, 2008

Mon histoire avec les cartes Adaptec (Dell OEM) 39320 Ultra320 SCSI adapter commence il y a trois ans quand j’ai eu à installer plusieurs exemplaires de machines DELL PowerEdge SC420 incluant cette carte. Cette carte est sensée permettre du RAID hardware mais c’est loin d’être le cas. Les premiers drivers pour cette carte ont été inclus dans le noyau Linux 2.6.11 (l’installation de Sarge nécessitait donc une technique annexe : debian-installer avec un noyau custom ou debootstrap à partir d’un autre disque) mais ils ignorent tout simplement la configuration RAID effectuée au niveau du BIOS de la carte. Celle-ci gère pourtant le RAID0 et RAID1 mais au démarrage de Linux, les disques sont vus par le noyau comme des disques indépendants… Bref, pas de RAID hardware possible (des blobs pour Suse/RedHat existent mais je préfère éviter cette solution).

Récemment, j’ai du ajouter un nouveau disque sur ce controleur. J’ai donc branché ce 2e disque sur la machine concernée et tenté de démarrer la machine : le controleur ne trouvait pas de périphérique de démarrage valide. En regardant de plus près, il cherchait un volume RAID0, forcément inexistant. Or, je souhaitais simplement avoir deux malheureux disques, sans RAID. Mais même en retirant le disque ajouté, il cherchait toujours un volume RAID0 : le second disque devait contenir un reste de RAID0 et le controleur l’a considéré maître et et a écrasé la configuration du premier disque. Youpi : bien que le RAID de ce controlleur ne fonctionne pas sous Linux… me voilà coincé à cause du RAID. Premier réflexe : désactiver les fonctionnalités RAID de la carte, et la documentation d’Adaptec m’indique que c’est simple, il suffit de l’indiquer dans le BIOS de la carte. Sauf que j’ai une carte DELL/Adaptec, c’est-à-dire que DELL a placé un firmware modifié pour faire croire à une carte DELL et, au passage, a eu la chouette idée de supprimer la possibilité de désactiver le RAID. Arrivé ici, on pourrait penser qu’il suffit de mettre un firmware Adaptec mais c’est justement indiqué que l’on ne doit le faire qu’avec les cartes 100% Adaptec et non issues d’un autre fournisseur. Et de toute façon, cela risquerait de me faire perdre la garantie DELL, ultime recours en cas de soucis :-)

Je vais donc devoir me débrouiller avec ce firmware. Ma première mission est de ré-initialiser le RAID du premier disque car, avec controleur on ne peut pas effacer la configuration RAID, il faut… ré-initialiser complètement le disque (ce qui l’efface au passage). À noter que cette ré-initialisation peut être délicate, j’ai déjà explosé un disque SCSI en annulant cette opération ! À noter aussi que cela prend plusieurs heures et si l’on ajoute les temps de backup (dd powered), ça fait beaucoup de temps pour effacer quelques octets dans le firmware du disque dur… Ces opérations de réparation prennent donc des heures et des heures et un message de confirmation aurait ainsi été bienvenu avant que le controleur écrase ses fameux paramètres RAID stockés sur un disque.

En conclusion, lorsque l’on manipule les disques de volumes RAID, outre la possibilité de perdre les données, il faut bien avoir en tête le temps considérable que peuvent prendre certaines opérations, d’autant plus quand il s’agit de controleurs de qualité médiocre (qui impliquent souvent des fonctionnalités réduites).