Cela faisait longtemps que je ne vous avais pas parlé de notre production XtremIO, qui est rentrée en phase de MCO depuis plus d’un an et demi maintenant (déjà ?!). Les machines sont actuellement dans une version relativement récente de leur firmware : 4.0.4-41 (voir le live de leur dernière mise à jour ici et la review associée, ici). Certes, le 4.0.2-80 est le plus récent en date, mais il n’apporte pas grand chose pour nous aujourd’hui, même si les différences entre les deux versions sont nombreuses (notamment l’ajout de Xbricks à un cluster a chaud, donc sans coupure de production). Tiens, d’ailleurs, pour ceux qui le souhaitent, voici le lien vers le PDF décrivant les releases notes du firmware en question, pour mémoire.
Nous avons réalisé deux chantiers récemment sur ces machines. Je vous propose un petit résumé de ceux-ci ainsi que les conclusions que nous pouvons en tirer pour la suite.
La première est uniquement “logistique”, mais a nécessité pas mal de préparation malgré tout. Elle consistait en un déménagement physique de chacune des baies au sein de nos datacenters. Chaque baie devait être déplacée de quelques mêtres pour laisser la place à des extensions destinées à notre TIER2 sous VNX. Evidemment, couper des machines sur lequel tourne grosso modo l’ensemble de nos applications ultra critiques n’est pas sans poser quelques sueurs froides à nos responsables. Il a donc fallu bien communiquer sur la méthode et surtout rappeler que l’ensemble des volumes XtremIO sont exploités à travers notre VPlex Metro et distribués en temps réel sur nos deux salles. Après une phase de mise en place, nous avons procédé, l’une après l’autre, à l’arrêt à froid des machines, leur déplacement physique et leur redémarrage. S’en est suivi, à chaque fois, une reconstruction différentielle des mirroirs via VPlex (de quelques dizaines de minutes suite à environ 1h30 d’arrêt). Globalement, et comme prévu – on est hyper forts :) – tout s’est bien passé sans aucun impact utilisateur. La conclusion de tout cela est double : d’une part VPlex re-re-re-re-confirme son comportement stable, fiable et prévisible sur ce genre d’opérations planifiée et consolide encore un peu plus son magistral ROI au sein de notre institution et d’autre part, les baies XtremIO sont très faciles à éteindre et redémarrer, comme toute autre baie de stockage classique, malgré leurs spécificités (stockage des metadatas en RAM, notamment).
Le second chantier a consisté à faire du ménage, au sens XtremIO du terme, au sein de nos volumes de production pour redonner des couleurs à notre taux d’occupation, qui baissaient régulièrement depuis plus de 6 mois. Pour se faire, nous avons utilisé toutes les méthodes déjà évoquées pour redonner des “block zéro” aux baies et se faisant, récupérer l’espace disque inutilement consommé. Et le moins que l’on puisse dire, c’est que cela a payé, puisque nous sommes parti d’un taux de remplissage de plus 69% à environ 58%, soit un gain de 10% (1,5 To de gagné tout de même, sur les 15 To utiles disponibles), preuve en est que la connaissance du fonctionnement d’une baie peut faire gagner beaucoup au quotidien. Sans une analyse complète d’XtremIO et notamment vis à vis de son traitement des blocks zéro (voir ce billet), je n’aurais jamais pris la peine de réaliser ce chantier.
Comme toujours, à votre disposition si vous souhaitez des retours spécifiques sur certains aspects de notre production, notamment vis à vis d’XtremIO et VPlex ;)
Bonjour,
Nous avons un nouveau METRO cluster VPLEX entre deux datacenters.
Nos LUN sont répliquées sur les deux datacenters.
Existe t il un moyen simple de “décrocher” une LUN d’un datacenter pour vérifier que toutes les données vont bien sur l’autres LUN et vice versa pour tester la hautedispo de ce nouveau VPLEX.
cordialement.
Bonjour !
Quelle type de baie back-end sert cette LUN, XtremIO, VNX ? Toutes vos LUNs sont répliquées ou seulement certaines ?
Vplex ne signant pas les disques il est tout à fait possible de présenter les luns directement des baies backend du vplex à un host, voir un snap/clone de ses luns (pour ne prendre aucun risque)
Je pense que la question était plutôt, peut-on facilement “mettre en pause” une synchro sur un distributed device sur un Vplex pour vérifier que l’autre LUN en mirroir continue à assurer le service.
Aujourd’hui en 5.4 et 5.5, non, pas de moyen en ligne de commande ou par une autre méthode. Par contre, on le fait régulièrement pour tester notre PSI stockage : on coupe carément le zoning d’une baie vers ses directeurs, mais dans ce cas de figure, c’est toute la baie qu’on “teste”, pas juste une LUN parmi d’autres.
J’avais pensé à déprésenter une LUN temporairement depuis le back-end, mais pas eu le temps d’essayer pour voir comment réagit le VPlex lors de la re-présentation … à mon sens, pas sûr que ça marche dans tous les cas suivant le back-end, d’où ma question préalable ;)