Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Instructions de réécriture de code ONTAP FlexCache

Contributeurs elliott-ecton netapp-dbagwell elliottecton
PDF

L'écriture différée FlexCache implique de nombreuses interactions complexes entre l'origine et les caches. Pour des performances optimales, assurez-vous que votre environnement respecte ces consignes. Ces directives sont basées sur la dernière version majeure ONTAP (ONTAP 9.17.1.) disponible au moment de la création du contenu.

Il est recommandé de tester votre charge de travail de production dans un environnement de non-production. Cela est encore plus important si vous implémentez la réécriture FlexCache en dehors de ces instructions.

Les directives suivantes sont testées en interne par NetApp. Il est fortement recommandé que vous restiez à l'intérieur d'eux. Si ce n'est pas le cas, un comportement inattendu pourrait se produire.

  • Des améliorations significatives pour la fonction d'écriture différée de FlexCache ont été introduites dans ONTAP 9.17.1P1. Il est fortement conseillé d'exécuter la version recommandée actuelle après la version 9.17.1P1 sur les clusters d'origine et de cache. Si vous ne parvenez pas à exécuter la version 9.17.1, la dernière version P, la 9.16.1, est la version suivante recommandée. ONTAP 9.15.1 ne contient pas tous les correctifs et améliorations nécessaires pour la réécriture FlexCache et n'est pas recommandé pour les charges de travail de production.

  • Les caches d'écriture différée FlexCache à plusieurs constituants sont pris en charge avec ONTAP 9.19.1 GA, 9.18.1P2, 9.17.1P3, 9.16.1P10 et les versions P ultérieures de chaque famille de versions respective. Pour les versions antérieures d'ONTAP, vous devez utiliser un seul constituant pour l'ensemble du volume FlexCache. Les FlexCaches à plusieurs constituants sur les versions antérieures peuvent entraîner des évictions indésirables de données du cache.

  • Des tests ont été effectués pour des fichiers de moins de 100 Go et des temps d'aller-retour WAN entre le cache et l'origine ne dépassant pas 200 ms. Toute charge de travail dépassant ces limites pourrait entraîner des performances inattendues.

  • L'écriture dans les autres flux de données SMB entraîne la suppression du fichier principal du cache. Toutes les données corrompues du fichier principal doivent être vidées à l'origine avant que d'autres opérations puissent avoir lieu sur ce fichier. Le flux de données alternatif est également transmis à l'origine.

  • Le fait de renommer un fichier entraîne la suppression du fichier du cache. Toutes les données corrompues du fichier doivent être vidées à l'origine avant que d'autres opérations puissent avoir lieu sur ce fichier.

  • Pour le moment, les seuls attributs qui peuvent être modifiés ou définis sur un fichier du volume FlexCache avec écriture différée sont les suivants :

    • Horodatages

    • Bits de mode

    • Listes de contrôle d'accès NT

    • Propriétaire

    • Groupe

    • Taille

      Tous les autres attributs modifiés ou définis sont transférés vers l'origine, ce qui peut entraîner l'éviction du fichier du cache. Si vous avez besoin de modifier ou de définir d'autres attributs dans le cache, demandez à votre équipe de gestion de compte d'ouvrir un PVR.

  • Les snapshots pris à l'origine entraînent le rappel de toutes les données corrompues en attente de chaque cache activé pour l'écriture différée associé à ce volume d'origine. Ceci peut nécessiter plusieurs tentatives de l'opération si une activité de réécriture importante est en cours, car les suppressions de ces fichiers sales peuvent prendre un certain temps.

  • Les verrous opportunistes SMB (Oplocks) pour les écritures ne sont pas pris en charge sur les volumes FlexCache avec écriture différée activée.

  • Les caches en écriture différée basculent automatiquement en mode write-around lorsque l'espace libre du volume d'origine tombe à 20 % ou moins. Cela permet d'éviter un manque d'espace à l'origine, ce qui laisserait des données modifiées orphelines dans un cache avec écriture différée. Si le volume d'origine est surprovisionné, sa taille logique provisionnée est supérieure à l'espace libre dans l'agrégat. Le seuil de 20 % est évalué par rapport à l'espace disponible du volume d'origine et à la capacité physique disponible de l'agrégat. percent-used et capacity peuvent toujours afficher 0 % lorsque l'espace disponible est déjà inférieur à ce seuil.

    L'exemple suivant illustre un volume source surprovisionné. Presque aucune donnée n'est écrite, mais l'agrégat ne peut pas prendre en charge la taille logique totale :

    ORIGIN::> vol show -volume origin_volume -fields percent-used,available,size
vserver             volume           size    available percent-used
------------------- ---------------- ------- --------- ------------
origin_svm          origin_volume    19.70TB 1.33TB    0%

    Notez que percent-used est de 0 %, mais l'espace disponible est de 1,33 To sur 19,70 To, soit 1,33 / 19,70, ou environ 7 % disponibles. Ce chiffre est déjà inférieur au seuil de 20 %, de sorte que les caches en écriture différée pour cette origine passent en mode write-around.

    ORIGIN::> df -h origin_volume
Filesystem               total       used      avail   capacity  Mounted on       Vserver
/vol/origin_volume/      18TB        515MB     1363GB         0%    ---           origin_svm

2 entries were displayed.

    Notez que capacity est également à 0 %, et que seulement 515 Mo sont utilisés. L’espace disponible est de 1 363 Go sur 18 To, soit environ 7 % du système de fichiers. Les colonnes de pourcentage indiquent la faible quantité de données stockées. Elles n’indiquent pas quelle part de la taille du volume l’agrégat peut réellement fournir.

  • Une bande passante faible et/ou des réseaux interclusters sujets à des pertes de paquets peuvent avoir un impact négatif significatif sur les performances d'écriture différée de FlexCache®. Bien qu'il n'y ait pas d'exigence de bande passante spécifique, car cela dépend fortement de votre charge de travail, il est fortement recommandé de vous assurer du bon état de fonctionnement de la liaison intercluster entre le ou les caches et l'origine. Si votre réseau est sujet aux pertes de paquets et que vous utilisez ONTAP 9.19.1 ou une version ultérieure, envisagez d'utiliser "TCP RACK" pour améliorer les performances.