Aller au contenu

NFS

NFS est un protocole développé par Sun Microsystems qui permet à un ordinateur d’accéder à des fichiers via un réseau.

Utilisation de PostgreSQL sur NFS

La documentation officielle de PostgreSQL contient un avertissement à propos du stockage des fichiers de l’instance (fichiers de données et fichiers WAL) dans un montage réseau, qui concerne particulièrement NFS : https://www.postgresql.org/docs/current/static/creating-cluster.html#CREATING-CLUSTER-NFS.

Il est néanmoins difficile de trouver des sources d’information récentes concernant d’éventuels problèmes de fiabilité entre PostgreSQL et NFS. Notamment l’avertissement de la documentation officielle pointe vers le lien suivant : https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html.

Cet article, comme l’indique l’auteur lui-même en en-tête, a été écrit en 2000, et n’a pas été mis à jour pour tenir compte des évolutions du NFS ces dernières décennies. Il reste vrai que PostgreSQL n’a pas été conçu pour accomplir des actions particulières en fonction du type de montage, et considérera dans tous les cas que les données sont écrites vers un stockage fiable. Il est particulièrement important de s’assurer que toute demande d’écriture synchrone est bien correctement traitée ainsi. Il convient donc de s’assurer que la cohérence des données de PostgreSQL est garantie, y compris en cas d’indisponibilité ponctuelle du NFS, voire en cas d’extinction soudaine, complète et totale de la salle serveur. Pour cela, il convient au minimum de réaliser des tests intensifs, et surtout de configurer le montage de façon à minimiser les risques.

Voici quelques liens qui permettent de se faire une idée des expériences et des opinions que la communauté a partagées des dernières années concernant le NFS :

La conférence pointée par le dernier lien donne de nombreuses informations très intéressantes sur un cas d’usage assez populaire :

  • virtualisation VMWare ;
  • stockage NetApp (avec un modèle FAS8080 Full-Flash) ;
  • montage NFS.

Les conclusions de cette conférence sont que le NFS peut être utilisé, dans ses versions v3 ou si possible v4, mais que la configuration nécessaire pour garantir la cohérence et la durabilité des données a un impact important en termes de performances. Et surtout, certains modes de montage d’un volume NFS doivent à tout pris être désactivés, car ils peuvent provoquer des corruptions de données (soft, async, etc.).

Danger

Certaines implémentations de NFS côté serveur permettent à l’administrateur de choisir de ne pas respecter le protocole NFS sur les opérations synchrones (c’est le cas de Linux avec l’option de partage async). Il est primordial de s’assurer que ce n’est pas le cas sur les baies NAS, car une telle configuration peut entraîner une corruption des données en cas de panne sur la baie.

Un autre sujet touchant à la fiabilité du NFS est la problématique de la haute disponibilité, par le biais d’un shared storage. Quelques ressources :

Le document suivant traitant des bonnes pratiques des bases de données Oracle avec un stockage NetApp aborde l’aspect de la configuration d’un volume NFS :

  • Oracle Databases on ONTAP ;
  • → p.35-36 “12 General NFS Configuration” ;
  • → p.47-48 “18.1 Linux NFS” “Slot Tables”.

On peut extraire quelques recommandations de ce rapport qui pourraient s’appliquer à PostgreSQL, mais tout n’est évidemment pas à prendre à la lettre. Il faut également indiquer que, contrairement aux meilleures pratiques orientées Oracle, la communauté PostgreSQL dans sa documentation officielle préconise de désactiver le cache NFS au montage pour les fichiers de données. Il est important de prendre en compte que, contrairement à PostgreSQL, Oracle a longuement optimisé les accès à des montages NFS, et a même développé son propre client NFS (Direct NFS) qui offre des améliorations de performances et comble un certain nombre de manques du client NFS classique (multipathing, fault tolerance, etc.). Par contraste, PostgreSQL n’adapte pas son comportement en fonction du type de stockage utilisé, il est donc important de procéder aux optimisations avec prudence, et de privilégier la stabilité et la persistance des données. Il est indiqué dans le document qu’Oracle ne supporte pas le NFS v4, sans toutefois que le document ne précise pour quelle raison, il est donc impossible de déterminer si cela peut s’appliquer à PostgreSQL ou non. Le document préconise également de préférer un montage NFS direct sur la VM plutôt que de passer par un Datastore, lorsque la virtualisation est utilisée.

En conclusion, il semble possible d’utiliser NFS sans faire courir de risques à l’intégrité des données à condition de le configurer correctement, mais le coût en performances sera très certainement rédhibitoire, et ce n’est pas recommandé.

Configuration de NFS

Voici quelques préconisations de configuration, afin de réduire le risque de perte ou corruption de données, et de minimiser les problèmes de performances.

Warning

Pour rappel, l’usage du NFS pour stocker des fichiers d’une instance PostgreSQL (fichiers de données ET fichiers WAL) n’est pas recommandé, même avec cette configuration.

Réseau

Utilisation des JumboFrame (modification du MTU) : attention toutefois au réseau routé, il faut que la valeur soit identique de bout en bout afin de ne pas fragmenter les paquets.

Utilisation d’un réseau dédié pour garantir la bande passante à l’accès aux données et sécuriser les transferts.

Export NFS (côté serveur)

  • sync : le volume ne doit surtout pas être exporté en mode async, qui indique à NFS d’ignorer les demandes de sync.

Montage NFS (côté client)

Options pour la sécurité des données:

  • hard : réessayer les opérations sur le serveur NFS indéfiniment. Son opposée est l’option soft, elle est connue pour causer des problèmes de corruption de données ;
  • sync : ne jamais mettre les modifications de données en cache, mais les transmettre directement au serveur (option non réellement nécessaire sur le client selon la documentation v12 mais obligatoire sur le serveur NFS ) ;
  • proto=tcp : il est impératif d’utiliser le protocole TCP, par opposition au protocole UDP, car celui n’est pas sensible aux possibles corruptions silencieuses de données dues à la fragmentation des paquets UDP sur les réseaux de grande capacité ;
  • noac : indique au client NFS de ne pas mettre les modifications d’attributs et méta-données des fichiers en cache, mais plutôt de transmettre directement ces modifications au serveur. La mise en cache des modifications d’attribut pourrait causer des pertes de données en cas d’arrêt brutal du serveur, par exemple dans le cas du recyclage d’un fichier WAL (renommage du fichier → modification d’attribut) ;
  • vers=3 : utiliser la version 3 au minimum du protocole NFS (meilleure gestion du cache entre les clients et serveurs NFS), suivant les fonctionnalités de la baie les versions 4 et 4.1 du protocole permettent d’obtenir une meilleure stabilité ;
  • nosuid : ne pas autoriser l’exécution de binaire Set-UID. Cela permet d’éviter d’introduire ou propager des binaires Set-UID par l’intermédiaire du serveur NFS ;
  • nodev : ne pas considérer les fichiers de type « block device » ou « character device » comme tels. Cela permet également de limiter l’introduction ou la propagation de fichiers de ce type par le serveur NFS ;
  • nointr : bloquer les signaux (voir la commande kill) lors des appels système utilisant le montage NFS. Interrompre les opérations sur le système de fichiers en cas de problèmes de communication peut provoquer des corruptions de données ;
  • namlen=255 : spécifier la longueur maximum des noms de fichiers permet de s’assurer que la taille maximum soit utilisée. Sans utilisation de cette option, cette longueur est négociée entre le client et le serveur, sans garantie que cela soit la valeur maximum. Cette valeur est identique à celles des systèmes de fichiers généralement utilisés avec PostgreSQL.

Options orientées performances :

  • noatime : ne pas mettre à jour les date et heure du dernier accès à un fichier. Sans l’utilisation de cette option de montage, chaque opération sur un fichier génère des entrées/sorties supplémentaires pour mettre cette information à jour alors que l’information est inutile à PostgreSQL. L’utilisation de ce paramètre est conseillée pour tout type de système de fichiers dédié à PostgreSQL ;
  • rsize=1048576,wsize=1048576 : passer la quantité maximale de données lues ou écrites par requête au serveur NFS au maximum permet de gagner en performances en minimisant le nombre de requêtes. Il est indispensable d’utiliser le protocole TCP pour de grandes valeurs de rsize et wsize : la fragmentation de paquets sur le réseau risque de provoquer des corruptions de données avec UDP.

Linux

Options orientées performances :

  • positionner les paramètres kernel sunrpc.tcp_max_slot_table_entries et sunrpc.tcp_slot_table_entries à la valeur 128.

PostgreSQL

Options orientées sécurité :

  • créer l’instance avec l’option checksum activée, afin de détecter les éventuelles corruptions silencieuses ;
  • pour toute installation, s’assurer que les options fsync et full_page_writes sont bien activées.

Options orientées performances :

  • l’option noac peut impacter fortement les performances, y compris en écriture. Normalement, seule l’instance PostgreSQL accède et modifie les fichiers de données. Aucun cas de corruption n’a été trouvé si cette option n’est pas utilisée ;
  • comme sur un disque classique, pour gagner en performances , il peut être envisagé de passer synchronous_commit à off si et seulement si perdre des transactions en cas d’arrêt brutal (moins d’une seconde) est acceptable.