vDisk – Méthodes de transport 3/3
NBD et NBDSSL Transport
Si aucun autre moyen de transport est disponible, les applications de stockage en réseau peuvent utiliser les transports « LAN » pour accéder aux données, soit le NBD (dispositif de bloc de réseau) ou le NBDSSL (version cryptée de NBD). NBD est un module du noyau Linux qui traite le stockage sur un hôte distant comme un périphérique bloc. NBDSSL est similaire, mais utilise le protocole SSL pour crypter toutes les données transmises sur la connexion TCP. La méthode de transport NBD est construite dans la librairie de vDisk, de sorte qu’il soit toujours disponible, mais il fait aussi office de solution tierce lorsque les autres modes de transport ne sont pas disponibles. Ce qui arrive régulièrement avec les applications de sauvegarde.
Dans ce mode, l’hyperviseur lit les données en mémoire et les envoie à travers le réseau vers le serveur de sauvegarde. Avec les transports LAN, les gros disques virtuels peuvent prendre beaucoup de temps à être transmis. Ce mode de transport ajoute du trafic vers le réseau local, contrairement au mode de transport de type SAN ou HotAdd, mais le transport NBD offre les avantages suivants :
- L’hôte ESXi peut utiliser un périphérique de stockage, y compris le stockage local ou distant (NAS).
- Le proxy de sauvegarde peut être une machine virtuelle, de manière à ce que les clients puissent utiliser les pools de ressources vSphere afin de minimiser l’impact sur les performances de sauvegarde. Par exemple, le proxy de sauvegarde peut être dans un pool de ressources de plus faible priorité que les hôtes ESXi de production.
- Si les machines virtuelles et le proxy de sauvegarde sont sur un réseau privé, les clients peuvent choisir le transfert de données non cryptées. NBD est plus rapide et consomme moins de ressources que NBDSSL. Cependant VMware recommande le cryptage des informations sensibles, même sur un réseau privé.
Lorsque VDDK ouvre un disque « non-snapshot » pour le transfert NBD (lecture seule ou lecture / écriture), il sélectionne l’hôte ESXi où le disque de la machine virtuelle se situe à ce moment-là.
Toutefois, lorsque VDDK ouvre un disque « snapshot » pour le transfert NBD, VDDK passe par vCenter Server pour atteindre le datastore, qui consulte la liste des hôtes ESXi ayant accès au datastore; vCenter prend le premier hôte avec un accès en lecture / écriture. La liste des hôtes est désordonnée, de sorte que l’hyperviseur choisi pour le transfert NBD de du snapshot ne soit pas nécessairement l’hôte ESXi où la machine virtuelle ou le snapshot réside.
NBD Performance
Lors de la lecture des données du disque en utilisant le transport NBD, VDDK effectue des appels synchrones. Autrement dit, VDDK demande un bloc de données et attend une réponse. Le bloc est lu à partir du disque et copié dans un tampon dans un coin du serveur, puis envoyé sur le réseau. Pendant ce temps, aucune donnée n’est copiée sur le réseau, ajoutant ainsi du temps d’attente. Dans une certaine mesure, vous pouvez passer outre cette limitation en utilisant de multiples flux de lecture simultanés à partir d’un seul disque ou de plusieurs disques.
Limites des sessions NFC
NBD emploie le protocole de copie de fichiers réseau (NFC). Les sessions de connexion NFC montre des limites sur le nombre de connexions pour les différents types d’hyperviseur. Ce sont des limites au niveau de l’hôte, et non pas du process. De plus vCenter Server impose une limite de 52 connexions. VixDiskLib_Open() utilise une connexion pour chaque disque virtuel auquel il accède sur chaque hôte ESXi. Le clone avec VixDiskLib_Clone() nécessite également une connexion. Il est impossible de partager une connexion sur les disques physiques. Ces limites de session NFC ne sont pas applicables au mode de transport SAN ou HotAdd.
Limites de connexion des sessions NFC
Certificats et sécurité SSL
La version VDDK 5.1 et les versions ultérieures ont été renforcées au niveau de la sécurité, avec des machines virtuelles définies pour vérifier les certificats SSL.
Sous Windows VDDK 5.1 et 5.5 requière les clés de registre VerifySSLCertificates et InstallPath sous HKEY_LOCAL_MACHINE\SOFTWARE pour vérifier les certificats SSL. Sur Linux, VDDK 5.1 et 5.5 nécessite l’ajout d’une ligne linuxSSL.verifyCertificates = 1, dans le fichier de configuration VixDiskLib_InitEx.
Dans VDDK 6.0 la vérification du certificat SSL et SSL thumbprint est obligatoires et ne peut pas être désactivé. Le registre Windows et le paramètre SSL Linux ne sont plus contrôlés, de sorte qu’il n’y ai aucun impact.
Plus clairement VDDK 6.0 utilise maintenant des certificats X.509 avec une cryptographie TLS, remplaçant SSLv3.
Les fonctions suivantes renforcent la vérification des certificats SSL :
initex,
PrepareForAccess,
EndAccess,
GetNfcTicket, et l’interface GetRpcConnection qui est utilisé par tous les transports avancés. La vérification de SSL peut utiliser thumbprints pour vérifier si deux certificats sont les identiques. Le thumbprint vSphere est un hachage cryptographique d’un certificat obtenu à partir d’une source de confiance telles que vCenter Server, et passé dans la structure SSLVerifyParam de NFC.
