Alors que je faisais un petit tour sur ma timeline Tweeter, je suis tombé sur un retweet d’un gentleman du nom de Mikael (qui travaille chez Atlantis aujourd’hui, transfuge d’EMC que j’ai eu l’occasion de côtoyer à plusieurs reprises) citant la très récente étude de la DCIG, une des nombreuses sociétés d’analyse du marché de l’IT, portant sur le segment des All-Flash-Arrays, dont les conclusions sont pour le moins surprenantes en première lecture : XtremIO est relégué au onzième rang, en fond de tableau, loin derrière les solutions de HP et Netapp, notamment. Quoi comment pardon, qu’est-ce ?! Evidemment, avec les chiffres de vente insolents d’XtremIO aujourd’hui sur ce marché en pleine explosion, il n’en fallait pas plus pour que cela déclenche une avalanche de querelles de clochers et d’arguments plus ou moins objectifs. Mais, après tout, il convient d’analyser vraiment les critères qui ont présidés à cette étude avant de balancer le bébé avec l’eau du bain. Le billet d’annonce de la DCIG au sujet du rapport apporte malgré tout quelques orientations intéressantes quant aux reproches qui ont pu peser lourd dans le classement final d’XtremIO. Je vous propose de faire le tour des objectifs et fondements de l’étude,

Je viens d’être averti par EMC (Merci à Benoit pour le forward !) d’un ETA, un EMC Technical Advisory, portant sur un risque critique de corruption de données sur les nouveaux firmware XtremIO 4.0. Ce risque vous concerne si vous provisionnez directement des LUNs vers des serveurs PHYSIQUES exécutant Windows 2012. A priori, pour le moment, les Windows 2012 R2 ne sont pas touchés (mais dans le doute, faite comme si …). Cette alerte est liée à la fameuse commande SCSI « UNMAP » qui permet à un host d’indiquer à XtremIO les blocks qu’il peut considérer comme libérable (plus utilisés par le serveur). Dans le détail, le problème est lié à une mauvaise interprétation par XtremIO (ou un envoi « buggué » par Windows, EMC ne détaille pas vraiment) de requêtes spécifiques produites par l’outil « Drive Optimizer » de Windows. La conséquence est une corruption potentielle des données sur les LUNs XtremIO présentées au serveur… pas cool 🙁 Dans la pratique, EMC recommande de procéder urgemment à une mise à jour mineure des XtremIO en 4.0.1-41 pour corriger le problème définitivement. Dans l’interval, la solution de contournement consiste à désactiver l’outil Drive Optimizer. Pour plus d’info, vous pouvez vous rendre directement sur la fiche

Update du 05/10/2015 : J’ai trouvé la cause de la disparition des tags, en fait ces outils d’organisation ne sont tout simplement pas stockés dans les contrôleurs mais uniquement dans les XMS. Donc si vous en avez des centaines, attention, rapprochez-vous d’EMC, il y a sûrement un moyen de les récupérer. Bon, je suis d’humeur facétieuse aujourd’hui, donc le ton sera sans doute plus léger ce soir 😉 Checklist de mise en production : on est entre grandes personnes ? check. Vous avez confiance en vous (et en moi ? juste un peu… ) ? check. L’aventure ne vous fait pas peur ? check. Bien ! Avant toute chose, je vous rappelle que les manipulations que je vais vous présenter peuvent tout à fait être réalisées via un SR au Remote Change Managment d’EMC. Ceci étant, cela ne va pas nous empêcher, ne serait-ce que par curiosité, de tenter la manipulation seuls 😉 Je vais donc vous présenter les divers étapes, que j’ai réalisé chez nous, qui permettent depuis XtremIO 4.0 de ne plus utiliser qu’une seule console de gestion XMS pour l’ensemble des clusters que vous possédez. Malgré mes avertissements, le risque est somme toute quasi nul sur votre

Vous avez pu suivre récemment notre upgrade de XIOS 3.0 vers la nouvelle version 4.0. Après des préparatifs plus longs que prévu (nécessiter de redéployer de nouvelles XMS aux capacités plus importantes), cette phase critique d’upgrade majeure s’est très bien déroulée. En moins d’une heure, les deux controleurs et le logiciel de la XMS étaient mis à jour en 4.0.1, dernière release en date. C’est l’occasion désormais de faire le – nouveau – tour du propriétaire, car les changements et évolutions sont nombreux, autant du coté de la cosmétique et de l’ergonomie que sur le plan fonctionnel.

Après l’annonce de « The Beast », XtremIO 4.0, par EMC à l’occasion de l’EMC World en Mai dernier, il nous tardait de profiter de toutes les avancées apportées par ce nouveau code sur nos baies de production (plus d’infos ici). Après validation, nous procédons en ce moment même à l’upgrade de notre premier cluster XtremIO. Je vous propose de vous un petit live de cette opération ! Nous partons donc d’XtremIO 3.0.3-11 aujourd’hui. Première information, il nous a été demandé de pré-déployer une nouvelle appliance XMS (version A.1.0) en prévision de cette mise à jour. En effet, les XMS historiques ne sont pas suffisamment bien taillées pour prendre en charge XIOS 4.0.1 et on peut le comprendre car désormais, une XMS est capable de gérer plusieurs clusters alors que ce n’était pas le cas auparavant. Nous avons donc procédé à l’import de l’OVA, puis nous avons dû procéder avec le support EMC à un changement d’appliance virtuelle de nos deux baies. Cela se fait via une procédure de recovery. En substance : vous arrêtez (power-off) physiquement votre ancienne XMS, vous lancez la nouvelle, vous la re-configurez pour qu’elle reprenne l’identité (IP, nom, FQDN) de l’ancienne, puis vous effectuez une procédure de