Photo-2016-06-20-10-20-06_8646

Un nouveau bug “CBT” d’ESXi sur la dernière build :(

Bon Lundi à tous … enfin, façon de parler :( . En effet, en consultant ma timeline Twitter ce matin, je suis tombé sur un tweet de Didier Wenger faisant mention d’un nouveau bug “CBT like” (voir ce billet et sa résolution sur le précédent, qui a fait couler beaucoup d’encre).

En effet, la dernière build “Express Patch 6” d’ESXi 6.0, build 3825889, semble être de nouveau affectée par un bug relatif à la gestion du CBT (j’ai envie d’hurler, là, ça se sent ou pas ?). Seules les machines de type Windows 2008 ou supérieures semblent touchées. Comme indiqué dans le billet du blog Running System (excellent blog au passage), globalement, vous avez deux symptômes potentiels qui vous confirmeront que vous êtes effectivement touchés par ce bug : un message d’erreur récurrent dans le vmware.log des VMs (sympa de se palucher des milliers de VM à la recherche du problème) et/ou plus sûrement une augmentation importante du volume de vos sauvegardes incrémentales de VMs (qui s’apparentent plus à de la totale déguisée).

La meilleure parade pour tous ceux qui ont déjà des ESXi en build 3825889 est de revenir très très vite dans la build “Update 2”, à savoir la 3620759. Et comme c’est visiblement ENCORE lié au CBT, si vous voulez être sûr de vos backups, il faut réinitialiser le log CBT de toutes vos VMs et relancer des totales, une fois les ESXi à la bonne version. Chouette, je me demandais ce qu’on allait faire ces prochains jours, tellement on avait pas de boulot … Ca mériterait un “Rognotudju”, FRANCHEMENT.

En général je suis assez magnanime voire compréhensif avec VMware, mais là, c’est complètement inadmissible qu’un type de bug pareil portant sur une fonction aussi essentielle du fonctionnement des VMs ressorte encore.

IMG_5657

Technique : SmartLock, la solution WORM d’ISILON

English sum-up :
A technical deepdive into the SmartLock WORM function of ISILON.

Vous savez sans doute qu’ISILON est une offre bigdata très riche : de nombreuses configurations différentes, des licences permettant de débloquer des fonctions spécifiques, des noeuds orientés capacitif ou performance, etc. … A l’occasion de l’acquisition récentes de nos deux clusters, s’est donc inévitablement posé la question des licences nécessaires à nos usages actuels et futurs. Nous avons opté pour InsightIQ (reporting et capacity planning), SyncIQ (réplication entre clusters), SnapshotIQ (snapshots locaux), SmartQuotas (gestion de quotas) et SmartLock (mode WORM).

Je vous propose de faire un focus particulier sur SmartLock car elle se distingue des autres part le fait qu’elle n’est accessible que via de la ligne de commande, pour le moment du moins. Cet outil permet d’appliquer des règles de “verrouillage” sur une hiérarchie de fichier donnée et se destine logiquement à des volumes de type “archive”.

Lire la suite …

unnamed

maj : XtremIO et snapshots, questions autour de l’intégration en production

stratMise à jour : après contact auprès de la team XtremIO, les fonction de refresh et revert sur les snapshots ne sont effectivement pas encore supportées, mais sont dans la roadmap XtremIO 4.0. A suivre !

Article original : Si vous me suivez depuis quelques semaines, vous savez sans doute que nous venons d’acquérir deux X-brick XtremIO que nous souhaitons intégrer à notre production en utilisant notre VPlex, afin disposer de toutes les fonctions de Disaster Recovery que nécessite notre institution. Chaque X-brick sera donc située dans une salle informatique différente, la réplication temps réelle étant assurée par VPlex Metro (en production depuis plus de 2 ans, désormais).

Intrinsèquement, toute cette architecture est parfaitement saine et performante, à même d’assurer notre production dite TIER1 dans les meilleures conditions. Pour autant, la couche VPlex introduit toujours une complexité supplémentaire, voir même quelques difficultés pour utiliser certaines fonctions bien pratique, mais n’étant pas VPlex “aware” pour le moment ou tout simplement pas supportées (je pense en particulier à la fonction “UNMAP”, voir ce billet).

En travaillant sur les fonctionnalités de snapshot d’XtremIO, j’ai donc imaginé les nombreux scénarios de production qui pourraient énormément bénéficier de l’Xtrem agilité de la baie en la matière. Aujourd’hui, nous n’utilisons que très ponctuellement les systèmes de snapshot de nos baies de stockage, principalement pour des raisons historiques. Il me paraissait logique de profiter d’un changement majeur d’infrastructure pour remettre cette fonction dans l’esprit de tous mes collègues ingénieurs et susciter, si ce n’est son usage plus systématique, du moins cette curiosité nécessaire à l’amélioration continuelle de nos outils et services !

Or, je suis confronté à un problème : malgré toutes mes recherches (documentation d’admin, blogs divers et variés), je n’ai pas vu de fonction intégrée permettant de faire un “refresh” ou un “revert” d’un snapshot en cours. L’objectif étant, bien entendu, de conserver tout le provisionning du snapshot jusqu’aux serveur l’utilisant (zoning éventuel, connexion “scsi”, identité logique etc. …), sans être obligé de casser toute la chaîne. C’est d’autant plus important lorsque le snapshot en question passe par un VPlex. A ce titre, d’ailleurs, la version 5.2 a ajouté une fonction parfaitement adaptée aux “refresh de snap”, c’est la possibilité, pour un virtual volume donné (ou même tout un consistency group) d’invalider le cache cohérent correspondant. En effet, en cas de revert ou refresh d’un snap back-end, il faut absolument indiquer au VPlex de repartir de zéro en terme de cache, sans quoi, vous obtenez à coup sûr une dé-cohérence de votre cache par rapport aux données rafraîchies présentées par le snap.

Même sans aller jusqu’à une intégration VPlex d’un volume de type snapshot (on peut se poser la question de l’utilité réelle d’une telle configuration, d’ailleurs), même via une connexion directe, il semble que, dès qu’on souhaite récupérer un snapshot “à jour” par rapport à la LUN source, nous soyons obligés de supprimer complètement le volume du host, supprimer l’ancien snapshot, recréer un nouveau snapshot copie du LUN de prod à l’instant T, le re-présenter au serveur et, enfin seulement, le reconnecter via une redécouverte du volume.

Pour le moment, je n’ai donc pas de solution et c’est assez frustrant. Si vous avez des pistes, je suis preneur, bien entendu !

A ce sujet : un billet détaillant avec précision le fonctionnement des snapshots sur XtremIO.