¶ Introduction
Dans cette partie de la documentation nous allons détailler le fonctionnement de NFS 3 et NFS 4.1.
Nous verrons également les différences entre ces deux versions et comment elles sont implémentées.
¶ NFS 3
Afin de bien comprendre les différences entre NFS 3 et NFS 4.1, commençons par NFS 3.
Le premier point important à comprendre et à prendre en compte lorsque l'on utilise NFS 3 est le fait que le trafic réseau qui passe entre l'hôte ESXi et le périphérique de stockage est entièrement en clair, il n'est pas du tout chiffré.
Lorsque nos machines virtuelles vont créer des commandes SCSi, ces commandes seront envoyées depuis l'ESXi vers le périphérique de stockage en passant par le réseau physique.
Avec NFS 3 ces commandes seront non chiffrées ce qui implique que nous voudrions utiliser cette version de NFS uniquement sur un réseau physique de confiance.
NFS 3 utilise également une seule connexion par I/O (entrées/sorties) et une seule adresse IP peut être utilisée pour le serveur NFS.
Cela peut rendre l'équilibrage de charge assez difficile lorsqu'il est effectué via une règle de loadbalancing de type IP Hash (fonctionnement disponibles ICI).
En effet si tout le trafic réseau est à destination d'une seule adresse IP et que j'utilise du loadbalancing de type IP Hash alors tout le trafic passera par un seul port physique relié à mon switch virtuel.
Donc dans ce sénario même si je possède plusieurs VMNICs (ports physiques), si j'utilise du loadbalancing de type IP Hash un seul de ces ports physiques sera réellement utilisé pour acheminer le trafic vers le périphérique de stockage.
Une autre chose importantes dont nous devons parler concerne l'accès de nos ESXi sur le périphérique de stockage.
Lorsque l'on utilise NFS 3, il est obligatoire que nos hôtes ESXi aient un accès en root sur le serveur NFS.
Donc si l'on souhaite créer un Datastore depuis un ESXi en utilisant NFS 3, l'hôte ESXi doit disposer d'un accès root pour le faire. Sans ce niveau d'accès ce ne sera pas possible.
Cela signifie que nous allons devoir configurer l'option "no_root_squash" sur notre serveur NFS.
Par défaut, les partages NFS remplacent l'utilisateur root par l'utilisateur nfsnobody qui est un compte utilisateur non privilégié. Cela change donc le propriétaire de tous les fichiers créés par root en nfsnobody, empêchant le téléchargement de programmes potentiellement malvaillants.
Lorsque no_root_squash est utilisé, les utilisateurs root distants peuvent modifier n'importe quel fichier sur le système de fichiers NFS, ce qui peut avoir de graves conséquences en matière de sécurité.
¶ NFS 4.1
Maintenant que nous avons vu les grandes lignes de NFS 3, voyons ensemble le fonctionnement de NFS 4.1.
Pour commencer la sécurité à été améliorée.
Précédemment nous avons vu que le trafic réseau entre l'hôte ESXi et le serveur NFS était entièrement en clair. A présent avec NFS 4.1 ce n'est plus le cas.
Les en-têtes (headers) sont signées et chiffrées lorsque le trafic traverse le réseau physique, ce qui nous offre un niveau de sécurité supplémentaire par rapport à NFS 3.
L'autre grande fonctionnalité qui est apparue avec NFS 4.1 est le fait que nous pouvons faire du "multipathing" en utilisant plusieurs adresses IP pour le serveur NFS.
Nous avons donc la possibilité d'utiliser plusieurs adresses IP pour accéder à une seule banque de données.
Qu'est-ce que cela implique ?
Lorsque notre machine virtuelle va envoyer du trafic vers le périphérique de stockage, il y aura ainsi deux adresses IP ou plus qui pourront être utilisées pour joindre notre banque de données.
De ce fait pour le loadbalancing de type IP Hash cela représente bien deux destinations distinctes possibles et le trafic à destination de l'une de ces IP passera alors par un port physique tandis que le trafic à destination de l'autre IP passera par un port physique différent.
Il s'agit donc d'une amélioration majeure en ce qui concerne l'équilibrage de charge (loadbalancing) sur les différents VMNICs (ports physiques) de notre ESXi.
Précédemment nous avons parlé de la nécessité de nos ESXi d'avoir un accès root sur le serveur NFS.
Avec NFS 4.1 cette nécessité n'existe plus, les ESXi n'ont plus besoin de se connecter en root sur le serveur NFS et nous n'avons plus besoin d'activer l'option "no_root_squash".
Si l'on parle à présent d'un point de vue strictement sécurité, NFS 4.1 apporte les éléments suivants :
- Le support de Kerberos est inclus dans NFS 4.1
- Il n'est plus nécessaire d'avoir un accès root sur le serveur NFS
- Le chiffrement est pris en charge sur les Headers (en-têtes) entre les hôtes ESXi et le serveur NFS
- Les informations d'identification utilisées pour Kerberos doivent correspondre sur tous les hôtes ESXi utilisant la même banque de données.
- Compatible avec Active Directory et KDC (Key Distribution Center) pour configurer l'authentification Kerberos
Chapitre précédent : 2- VMFS et NFS Datastores dans vSphere 7 - Chapitre suivant : 4- Création d'un Datastore NFS : Démonstration