Mieux appréhender la gestion du cache de vos VNX

On oublie trop souvent qu’une production reposant sur du stockage VNX classique doit être gérée. Les fonctionnalités de nos baies ont certes beaucoup évolué depuis quelques années, tendant globalement vers une certaine forme d’auto-gestion assumée : Fast Cache, Auto-Tiering, Thin provisionning etc. … . Sauf que dans la pratique, toutes automatiques qu’elles soient, il arrive un moment ou l’Homme doit aider la machine (pour le moment en tout cas …) pour que tout se passe bien ou que les difficultés soient surmontées.

A ce sujet, le cache primaire de lecture/écriture des VNX a toujours été une denrée rare et donc cruciale sur ce type de baie. Il faut absolument le préserver et l’entretenir régulièrement ; il faut prendre soin en somme, d’autant plus que sa bonne santé détermine souvent le comportement générale de votre baie. En effet, c’est quasiment le seul composant à être commun à l’ensemble des accès clients et de facto un passage obligé et donc goulot d’étranglement potentiel en cas de contention.

Si vous avez l’habitude de ces environnements, vous connaissez surement les différents paramètres qui prévalent au dimensionnement et au tuning du cache VNX. En substance, vous pouvez jouer sur 3 paramètres : la taille des blocks cachés, le low watermark et le high watermark. La taille des blocks est finalement assez rarement modifiée car pour des baies généralistes, on choisit souvent une taille médiane ni trop petite ni trop grande (cela peut être utile de réduire un peu pour avoir plus de granularité dans le cache si vous ne faite que du transactionnel avec des petites I/O par exemple). Par contre, les watermark low et high sont souvent établis en fonction d’une activité donnée sur la baie. Ces deux indicateurs établissent une règle de “purge du cache” en cas d’afflut d’I/O en écriture. Le HWM indique qu’à partir de XX % de remplissage du cache en écriture, la baie doit “flusher” les blocks actuellement en cache… jusqu’à atteindre le LWM. On a coutume de dire qu’un cache parfait devrait toujours être à 100%… mais pas plus. En effet, si le cache est full, toutes les nouvelles I/O sont mises en attente par les SP et la latence augmente mécaniquement pour tous les clients de la baie.

En substance, tout est affaire de dosage. Si vous rencontrez souvent des périodes de forte activité d’écriture ou les I/O idoines s’accumulent dans votre cache, il vaut mieux réduire le HWM pour que la baie ait le temps de flusher les blocks en attente avant que de nouveaux blocks puissent prendre leur place. A contrario si vous avez des I/O en écriture très aléatoires, il vaut mieux profiter au maximum du cache et pousser le HWM. En général, EMC recommande un LWM de 60% et un HWM de 80%.

De notre coté, nous avions respecté jusqu’à présent les best practices d’EMC qui convenaient bien à notre production. Oui, mais c’était sans compter sur notre nouveau système de sauvegarde tout neuf et ultra performant basé sur Avamar et Datadomain (voir ici). Etant donné que ce système nous autorisait une réduction très importante de nos fenêtres de sauvegarde, nous avons aussi concentré sur une période beaucoup plus courte les pré-traitements et en particulier ceux qui réalisaient des dumps de nos bases de production (via du RMAN Oracle ou du dump SQL). Résultat, des écritures séquentielles beaucoup plus nombreuses avec en parallèle des phases de lectures pour le backup lui-même… la pire des situations pour un cache primaire en somme.

Cela n’a pas trainé : des soucis de performance réguliers sur le TIER2, notamment en début de matinée alors que l’activité journalière reprend et que les sauvegardes n’étaient pas encore terminées. Il nous a fallut quelques jours pour mettre en place tout un tas de mesures d’équilibrage et de modération afin de lisser l’activité et la rendre supportable par nos baies. De plus, nous avons aussi modifié les deux paramètres LWM et HWM pour les faire passer à 40/60 afin d’éviter les périodes de saturation rencontrées auparavant. Les graphiques suivants sont particulièrement éloquents :

Une journée d’activité avant la mise à jour des LWM et HWM (60/80) :

Une journée d’activité après la mise à jour des LWM et HWM (40/60) :

Cette modification nous a permis de maintenir une latence moyenne correcte au alentours de 20/30 ms dans le pire des cas quand nous pouvions atteindre des sommets à plus de 100/150 ms précédemment. Malgré tout, je pense qu’il sera nécessaire de rajouter un peu de disques “performance” sur nos pools capacitifs et faire jouer l’auto-tiering pour que les flushs soient plus rapidement réalisés sur les LUN les plus sollicitées. En effet, pour qu’un flush reste efficace et libère la place du cache primaire, il faut aussi que les disques suivent un minimum, sinon, cela risque de n’être qu’un coup d’épée dans l’eau et la saturation perdurera.

Pour ouvrir le sujet en guise de conclusion, voici une liste de billets et de références externes qui peuvent vous aider à faire bien comprendre les metrics VNX et faire le point sur votre propre production :
– Un billet incontournable de “The SAN Guy” à visiter ici.
– Mon billet sur VNX Monitoring and reporting.
– Utilisez Mitrend pour faire un bilan de santé de votre baie.

Evidemment, si vous n’avez pas le temps ou les compétences pour réaliser vous-même cet audit, n’oubliez pas que la plupart des intégrateurs stockage en France sont tout à fait capables de réaliser cela pour vous (APX, Telindus, Computa, Bull etc. …).