Les joies des baies iSCSI au boulot…

Encore une fois, ce post n’est intéressant que pour une personne : moi. Encore une fois, c’est technique et il va me permettre de garder quelque part certains éléments.

Dans le cadre de mon boulot, j’ai eu l’occasion de concevoir et de mettre en place une petite infrastructure VMware composée de deux serveurs ESX, d’un serveur vCenter et d’une baie de stockage iSCSI. C’est sur la baie iSCSI que va porter l’essentiel de cet «article».
Premièrement, pourquoi une baie iSCSI ?
 D’abord, pour des question de coût. Trois technologies se présentaient à moi dans mon étude : Fibre Channel, SAS ou iSCSI. Chez le client, aucune infrastructure n’existait pouvant supporter l’ajout de cette baie. Il fallait donc monter quelque chose à partir de rien. Pour la technologie FC, les coûts en infrastructure sont énormes. – C’est de la fibre optique. – Pour bien faire, cela implique de tirer des fibres optiques, de mettre en place des switchs spécifiques – avec de la configuration lourde – et ajouter des cartes HBA dans les serveurs. Coût : XXXk€. Avec le budget que j’avais à disposition, il est évident que cette solution n’était pas viable. Pour la technologie SAS, il fallait aussi des cartes supplémentaires sur les serveurs. Des cartes chères. La baie SAS était aussi un peu plus chère que la baie iSCSI. Pour la baie iSCSI, la moins chère, tout ce qui était nécessaire, c’était des cartes réseau supplémentaires. – Moins chères que les cartes SAS – Car le iSCSI, c’est du SCSI sur de l’ethernet. Et les infrastructures réseau, c’est la base même de l’informatique d’entreprise aujourd’hui. Aucun investissement particulier n’était nécessaire ici.
Vous allez me dire : oui, mais les performances du iSCSI, comparées à de la fibre ou du SAS, c’est la nuit et le jour. iSCSI : 1 Gbps; SAS : 3 Gbps; FC : 4 Gbps. Dans le cas de mon client, 1 Gbps était suffisant. – Peu de machines virtuelles, peu de prod, peu de réelle charge I/O – De plus, j’ai plus que 1 Gbps en iSCSI puisque avec le modèle de baie choisie, je bénéficie de quatre connexions Gigabit sur ma baie. Avec de la répartition de charge, on obtient facilement bien plus de 1 Gbps. Je n’ai pas fait de mesure exacte, mais bon…
Finalement, il fallait aussi prendre en compte la possibilité d’extension éventuelle de l’infrastructure. Depuis que je fais de la virtualisation, j’ai vu les erreurs à ne pas commettre. La première d’entre elles est de ne pas prévoir une architecture qui va évoluer. La virtualisation, une fois qu’elle a pénétré dans une entreprise, elle ne fait que s’étendre. Si mon client ne voulait que deux serveurs ESX pour commencer, il fallait prévoir de pouvoir en augmenter le nombre. Or, si pour les technologies FC et iSCSI, l’ajout de serveurs supplémentaires n’est pas un problème pour attaquer la même baie, il est largement plus problématique pour les baies SAS. En effet, dans le cadre des baies SAS, les serveurs sont en attachement direct avec la baie. Dans les cas FC et iSCSI, les serveurs sont reliés à des switchs, et ces switchs sont reliés à la baie. Pour le SAS, la baie est reliée directement aux serveurs et ne peut servir que deux serveurs au maximum. Donc exit le SAS.

Donc, pour mon architecture, mon choix s’est porté sur une baie HP, iSCSI, MSA2312i G2. Une baie avec deux contrôleurs – redondance, sécurité, tout ça – quatre ports réseau pour le iSCSI, deux ports pour le management, avec la possibilité de mettre 12 disques SAS ou SATA, et une possibilité de rajouter des modules supplémentaires – quatre maximum – pouvant gérer chacun soit 12, soit 24 disques supplémentaires. – En l’occurrence, on a pris un module supplémentaire pour 12 disques. –
L’installation physique de la baie s’est fait sans problème – Ahahahahahhahahahaha… Pardon… C’est nerveux… Quand le client ne vous file pas les bonnes infras pour installer votre matos… –, la configuration effectuée normalement. Puis, voulant faire bien, et parce que c’était la dernière fois possible avant la mise en prod et la possibilité de la faire en heures normales et sans impact, j’ai voulu mettre à jour le firmware de la baie. Opération on ne peut plus normale.
Première étape : récupération du dernier firmware à jour sur le site du constructeur. Autant dire, la galère… Le site de HP est franchement l’un des plus bordéliques qui puissent exister. Même quand vous possédez les références exactes de votre matériel.
Deuxième étape : lancer la mise à jour. Fort heureusement, les baies de nos jours possèdent des interfaces web. Vous vous connectez, vous allez sur la bonne page, vous sélectionnez le fichier contenant le firmware et vous appuyez sur : «vas-y fait ton boulot».
Et là… COIN ! «Mauvaise extension de fichier». Marmotte, tout ça, vous vérifiez le fichier, la source, vous réessayez : COIN ! Marmotte moins polie, vous vérifiez la doc pour cette opération, vous ne constatez aucune erreur, votre fichier est correct, vous réessayez. – Oui, dans l’informatique, si vous ne touchez à rien, des fois, au bout de la xème tentative, ça marche. – COIN ! toujours et encore. Et là… L’éclair de génie. Votre fichier est dans un répertoire dont le nom contient un espace. Ouais… Le vieux truc qui n’a plus d’impact normalement… Vous résolvez le problème et l’opération se lance. Et dure… Et dure… Vous regardez d’un oeil morne les écrans et les étapes qui défilent. Et l’opération aboutie enfin. Comme vous avez deux contrôleurs sur cette baie, cette opération doit être effectuée sur les deux. Ce qui se fait automatiquement.
Et là… Le drame… La mise à jour boucle. Une fois terminée, elle repart à zéro. Avec des écrans qui vous empêche d’accéder à l’interface web, pour consulter les logs… Au bout de la troisième boucle, vous faites ce qu’il ne faut pas faire. Vous allez éteindre électriquement la baie. – Ne faites jamais ça chez vous les enfants. Ni même au boulot. Seuls les professionnels suicidaires, déprimés, ayant envie d’être virés ou cons sont habilités à le faire. – Elle redémarre correctement, vous accédez à l’interface web, vous commencez à consulter les logs et à voir que c’est la mise à jour sur le contrôleur 2 qui merde et… La mise à jour se relance d’elle-même, et c’est reparti pour une boucle. Et là… Vous n’êtes plus de bonne humeur… Vous vous passez les nerfs sur le collègue bourré en train de chanter le générique français de l’Agence Tout Risque.
Et vous commencez à googler le problème à l’aide des différents messages que vous voyez passer et repasser en boucle. Et vous comprenez que le problème est connu – Vous maudissez le constructeur sur 150 générations – et vous obtenez les commandes nécessaires à la désactivation de la mise à jour automatique d’un contrôleur par l’autre contrôleur.
La manipulation est simple. Vous vous connectez à la baie en ligne de commande, ce qui nécessite un câble au format propriétaire, qui relie un port COM – Essayez de trouver de nos jours un portable qui a encore un port COM… – à un port propriétaire.
Et vous désactivez la fonction avec la commande suivante :
set job-parameters partner-firmware-upgrade disable
Vous pouvez vérifier que la commande a bien été prise en compte à l’aide de :
show job-parameters
Une fois cette fonction désactivée, vous êtes bons pour attendre la fin d’un cycle de mise à jour avant de redémarrer électriquement la baie. – Ou avant si vous êtes complètement timbrés. –
Et à recommencer l’upgrade, contrôleur par contrôleur. Et bien noter dans votre documentation d’exploitation que vous allez filer au client toutes les petites merdes qu’ils peuvent avoir, les solutions éventuelles, et que si ils font cette opération, il vaut mieux la prévoir hors heures ouvrées et prévoir une interruption de service.

Et si vous êtes architecte virtualisation, prévoir que pour la prochaine fois, vous ne prendrez pas du HP. A la rigueur, de l’EMC ou du NetApp. – Ouais, parce que là, c’est la version courte des problèmes que j’ai eu pour faire cette bon dieu de mise à jour de firmware… –

Tout ça pour juste me faire une petite note pour ne pas oublier les deux commandes, notées sur un post-it.

4 réflexions sur « Les joies des baies iSCSI au boulot… »

  1. J’ai compris “architecture”, “solutions” et “c’est le drame”. Entre les trois, pas grand-chose 😀
    Juste un conseil: ne lâche pas l’informatique pour la photo ^^

  2. Au fond, Ketch, tu es un poète… je lis tes posts durant des réunions techniques sur la prise en compte des normes ISO ou STEp dans le cadre de la conception d’un outil de type SLM (un PLM pour la simulation mais avec une couche comportementale) et je me rends compte qu’on est des pionniers de l’aventure numérique. Ca a quelque chose de rassurant.

  3. On utilisait du filer netapp pour stocker nos teras de données chez CI et c’était bien. Maintenant j’ai changé de boucherie et on utilise ces foutues baies de stockage (je sais pas quel modèle ni quoi) mais ça rame comme jamais et on n’a jamais le droit de demander quelques teras pour nos bases. SNIF.
    C’était mieux avant. :p
    @+,
    NicK.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.