La taille du fichier est moins importante que le nombre d'écritures émises entre OPEN le et les CLOSE appels pour un fichier. Les petits fichiers ont par nature moins d' WRITE appels, ce qui les rend moins idéaux pour les réécritures. Les fichiers volumineux peuvent avoir plus d'écritures entre OPEN les appels et CLOSE , mais cela n'est pas garanti.

Reportez-vous "Instructions de réécriture de code FlexCache"à la page pour connaître les recommandations les plus récentes concernant la taille maximale du fichier.

Lors de l'écriture à partir d'un client, d'autres appels NAS modifiés sont impliqués, autres que des appels d'écriture. Notamment :

SETATTR et SET_INFO les appels qui définissent mtime, atime, ctime, owner, , group ou size sont traités au niveau du cache. Le reste de ces appels doit être traité à l'origine et déclencher une réécriture de toutes les données corrompues accumulées au niveau du cache activé pour l'écriture différée du fichier en cours d'exécution. Les E/S vers le fichier seront suspendues jusqu'à ce que l'écriture différée soit terminée.

En sachant que ces appels doivent traverser le WAN, vous pouvez identifier les charges de travail adaptées à la réécriture. En général, plus le nombre d'écritures pouvant être effectuées entre OPEN les CLOSE appels et sans que l'un des autres appels répertoriés ci-dessus ne soit émis est élevé, plus le gain de performances est élevé.

Dans le passé, les workloads de lecture après écriture ont des performances médiocres chez FlexCache. Ceci est dû au mode de fonctionnement de la réécriture avant 9.15.1. L' WRITE appel au fichier doit être validé à l'origine et l'appel suivant READ devra renvoyer les données dans le cache. Les deux opérations sont donc pénalisés par le WAN. Par conséquent, les charges de travail de lecture après écriture sont déconseillées pour FlexCache en mode d'écriture immédiate. Avec l'introduction de la fonctionnalité de réécriture dans la version 9.15.1, les données sont désormais validées au niveau du cache et peuvent être immédiatement lues à partir du cache, éliminant ainsi les pénalités liées au WAN. Si votre charge de travail inclut la lecture après écriture sur les volumes FlexCache, vous devez configurer le cache pour qu'il fonctionne en mode écriture différée.

Lorsqu'un fichier accumule des données corrompues dans un cache, le cache réécrit les données de manière asynchrone vers l'origine. Cela se traduit naturellement par des moments où le client ferme le fichier avec des données corrompues en attendant toujours d'être retransférées vers l'origine. Si un autre fichier ouvert ou en écriture vient d'être enregistré pour le fichier qui vient d'être fermé et qui contient toujours des données corrompues, l'écriture sera suspendue jusqu'à ce que toutes les données corrompues aient été vidées à l'origine.

Lorsque FlexCache fonctionne en mode de réécriture, les clients NAS bénéficient d'avantages à mesure que la latence augmente. Il est toutefois important de noter que la surcharge liée à l'écriture différée est supérieure aux avantages obtenus dans les environnements à faible latence. Dans certains tests NetApp, les bénéfices de la réécriture ont commencé autour d'une latence minimale entre le cache et l'origine de 8 ms. Cette latence varie en fonction des charges de travail. Assurez-vous donc de tester pour connaître le point de retour de votre charge de travail.

Le graphique suivant montre le point de retour pour l'écriture différée dans les tests de laboratoire NetApp. L' x axe est la taille du fichier et l' y axe est le temps écoulé. Le test a utilisé NFSv3, à monter avec une et de 256 Ko, et une rsize wsize latence WAN de 64 ms. Ce test a été réalisé en utilisant une petite instance ONTAP Select pour le cache et l'origine, ainsi qu'une seule opération d'écriture par thread. Vos résultats peuvent varier.