¶ Importance
Comprendre les options de stockage disponibles vous aide à configurer votre stockage en fonction de vos besoins en termes de coût, performance et facilité de gestion.
Vous pouvez utiliser un stockage partagé pour la reprise après sinistre, la haute disponibilité, et pour déplacer des machines virtuelles entre les hôtes.
¶ Leçons du module
- Concepts de stockage
- Stockage Fibre Channel
- Stockage iSCSI
- VMFS Datastores
- NFS Datastores
¶ Leçon 1 : Concepts de stockage
¶ Objectifs d’apprentissage
- Reconnaître les technologies de stockage vSphere
- Identifier les types de datastores
- Reconnaître les conventions de nommage des périphériques de stockage
¶ À propos des datastores
Un datastore est une unité de stockage logique qui peut utiliser l’espace d’un ou de plusieurs périphériques de stockage physiques.
Les datastores sont utilisés pour stocker des données telles que :
- des machines virtuelles (VM),
- des modèles de VM,
- des images ISO.
vSphere prend en charge les types de datastores suivants :
- VMFS
- NFS
- vSAN
- vSphere Virtual Volumes
Un datastore est un terme générique désignant un conteneur qui stocke des fichiers et des objets. Les datastores sont des conteneurs logiques, analogues à des systèmes de fichiers, qui masquent les spécificités du périphérique de stockage sous-jacent et fournissent un modèle uniforme pour stocker les fichiers des machines virtuelles.
Une VM est stockée sous forme d’un ensemble de fichiers dans son propre répertoire, ou comme un groupe d’objets dans un datastore.
Vous pouvez afficher tous les datastores disponibles pour vos hôtes et analyser leurs propriétés.
¶ Méthodes d’accès aux datastores
Les datastores vSphere stockent et accèdent aux données sous forme de blocs ou de fichiers :
Stockage basé sur des blocs :
- Stocke les données sous forme de blocs (une séquence d’octets)
- Utilisé sur le stockage local
- Utilisé dans les Storage Area Networks (SANs) et accessible via iSCSI ou Fibre Channel
- Utilisé par les datastores VMFS, vSAN et vSphere Virtual Volumes
Stockage basé sur des fichiers :
- Stocke les données de manière hiérarchique dans des fichiers et des dossiers
- Utilisé sur le network-attached storage (NAS)
- Utilisé par les datastores NFS et vSphere Virtual Volumes
¶ Contenu des datastores
Selon le type de datastore, le contenu peut être stocké sous forme de fichiers ou d’objets.
Datastores basés sur des fichiers :
- Une VM est composée d’un ensemble de fichiers.
- Chaque VM possède son propre répertoire.
- Les datastores VMFS et NFS contiennent des fichiers.
Datastores basés sur des objets :
- Une VM est composée d’un ensemble de conteneurs de données appelés objets.
- Les datastores vSAN et vSphere Virtual Volumes contiennent des objets.
Dans les datastores basés sur des fichiers, un répertoire contient les fichiers de la machine virtuelle (VM), tels que le fichier de configuration, un ou plusieurs fichiers de disque virtuel, les fichiers d’échange (swap), et ainsi de suite.
Dans un datastore basé sur des objets, chaque VM est constituée de plusieurs conteneurs de données appelés objets, par exemple un objet de configuration de VM, un ou plusieurs objets de disque virtuel, un objet d’espace d’échange (swap space) et ainsi de suite.
Un objet est un conteneur de données. Chaque objet présent sur le datastore inclut les données, certaines métadonnées, et un identifiant unique (unique ID).
¶ Résumé sur les Datastores
En résumé, les datastores vSphere peuvent être classés en fonction de leur méthode d’accès et de leur contenu.
| Type de datastore | Méthode d’accès | Contenu du datastore |
|---|---|---|
| VMFS | Block access | Files |
| NFS | File access | Files |
| vSAN | Block access | Objects |
| vSphere Virtual Volumes | Block or file access | Objects |
¶ Vue d’ensemble du Storage
Les hôtes ESXi doivent être configurés avec un accès partagé aux datastores.
Selon le type de storage que vous utilisez, les datastores peuvent être formatés avec VMFS ou NFS.
Dans l’environnement vSphere, les hôtes ESXi prennent en charge plusieurs technologies de storage :
- Direct-attached storage : Disques ou baies de stockage internes ou externes attachés à l’hôte via une connexion directe plutôt qu’une connexion réseau.
- Fibre Channel (FC) : Un protocole de transport haut débit utilisé pour les SANs. Fibre Channel encapsule les commandes SCSI, qui sont transmises entre les nœuds Fibre Channel. En général, un nœud Fibre Channel est un serveur, un système de stockage ou un lecteur de bande. Un Fibre Channel switch interconnecte plusieurs nœuds, formant le fabric dans un réseau Fibre Channel.
- FCoE : Le trafic Fibre Channel est encapsulé dans des trames Fibre Channel over Ethernet (FCoE). Ces trames FCoE sont convergées avec d’autres types de trafic sur le réseau Ethernet.
- iSCSI : Un protocole de transport SCSI, offrant un accès aux périphériques de stockage et au câblage via des réseaux TCP/IP standards. iSCSI mappe le stockage orienté blocs SCSI sur TCP/IP. Les initiateurs, comme un iSCSI host bus adapter (HBA) dans un hôte ESXi, envoient des commandes SCSI aux targets, situés dans des systèmes de stockage iSCSI.
- NAS : Stockage partagé sur des réseaux TCP/IP standards au niveau du système de fichiers. Le stockage NAS est utilisé pour héberger des datastores NFS. Le protocole NFS ne prend pas en charge les commandes SCSI.
- iSCSI, network-attached storage (NAS) et FCoE peuvent fonctionner sur des réseaux haut débit, offrant ainsi des niveaux de performance de storage accrus et garantissant une bande passante suffisante. Avec une bande passante suffisante, plusieurs types de trafic de protocoles à haut débit peuvent coexister sur le même réseau.
Pour plus d’informations sur la prise en charge des physical NICs et le nombre maximal de ports pris en charge, consultez VMware Configuration Maximums à l’adresse : https://configmax.vmware.com
¶ Conventions de nommage des périphériques de stockage
Les périphériques de storage sont identifiés de plusieurs façons :
- Runtime name : utilise la convention vmhbaN:C:T:L. Ce nom n’est pas persistant après un redémarrage.
- Target : identifie l’adresse et le port de la cible.
- LUN : un identifiant unique attribué individuellement ou à des ensembles de périphériques de storage.
Cette diapositive montre des exemples de noms de périphériques iSCSI logiciels.
Sur les hôtes ESXi, les périphériques de stockage SCSI utilisent divers identifiants. Chaque identifiant a un but spécifique.
Par exemple le VMkernel nécessite un identifiant, généré par le périphérique de storage, qui est garanti comme étant unique pour chaque LUN. Si le périphérique de storage ne peut pas fournir un identifiant unique, le VMkernel doit générer un identifiant unique pour représenter chaque LUN ou disque.
Les identifiants suivants de périphériques de stockage SCSI sont disponibles :
- Runtime name : Nom du premier chemin vers le périphérique. Le runtime name est un nom convivial créé par l’hôte après chaque redémarrage. Ce n’est pas un identifiant fiable pour le périphérique disque, car il n’est pas persistant. Le runtime name peut changer si vous ajoutez des HBA à l’hôte ESXi. Cependant, vous pouvez utiliser ce nom lorsque vous utilisez les utilitaires en ligne de commande pour interagir avec le stockage reconnu par un hôte ESXi.
- Target : Un nom universellement unique permettant d’identifier le nœud. Par exemple, iSCSI utilise l’IQN et l’EUI. L’IQN utilise le format :
iqn.yyyy-mm.naming-authority:unique name. - LUN : Un numéro d’unité logique, adressé par le protocole SCSI ou par les protocoles SAN qui encapsulent SCSI, tels que iSCSI ou Fibre Channel.
Les noms de périphériques de stockage apparaissent dans différents panneaux du vSphere Client.
¶ Vue d’ensemble des protocoles de stockage
Chaque datastore utilise un protocole avec différents niveaux de prise en charge des fonctionnalités.
| Type de Datastore | Protocole de stockage | Prise en charge Boot from SAN | Prise en charge vSphere vMotion | Prise en charge vSphere HA | Prise en charge vSphere DRS |
|---|---|---|---|---|---|
| VMFS | Fibre Channel | Yes | Yes | Yes | Yes |
| VMFS | FCoE | Yes | Yes | Yes | Yes |
| VMFS | iSCSI | Yes | Yes | Yes | Yes |
| VMFS | iSER/NVMe-oF (RDMA) | No | Yes | Yes | Yes |
| VMFS | DAS (SAS, SATA, NVMe) | N/A | Yes* | No | No |
| NFS | NFS | No | Yes | Yes | Yes |
| vSphere Virtual Volumes | FC/Ethernet (iSCSI, NFS) | No | Yes | Yes | Yes |
| vSAN Datastore | vSAN | No | Yes | Yes | Yes |
Le Direct-attached storage (DAS) prend en charge vSphere vMotion lorsqu’il est combiné avec vSphere Storage vMotion.
Le Direct-attached storage, par opposition au SAN storage, est l’endroit où de nombreux administrateurs installent ESXi. Le Direct-attached storage est également idéal pour les petits environnements en raison des économies liées à l’achat et à la gestion d’un SAN.
L’inconvénient est que vous perdez de nombreuses fonctionnalités qui rendent la virtualisation intéressante, par exemple, l’équilibrage de la charge de travail sur un hôte ESXi spécifique.
Le Direct-attached storage peut également être utilisé pour stocker des données non critiques, telles que :
- Des images CD/DVD ISO
- Des VMs mises hors service
- Des VM templates
En comparaison, les storage LUNs doivent être regroupés et partagés afin que tous les hôtes ESXi puissent y accéder. Le Shared storage fournit les fonctionnalités vSphere suivantes :
- vSphere vMotion
- vSphere HA
- vSphere DRS
L’utilisation du Shared SAN storage offre également des fonctionnalités avancées dans vSphere :
- Des dépôts centraux pour les fichiers et templates de VM
- La mise en cluster des VMs entre les hôtes ESXi
- L’allocation de grandes capacités de stockage (en téraoctets) à vos hôtes ESXi
ESXi prend en charge différentes méthodes de démarrage à partir du SAN afin d’éviter la gestion d’un stockage Direct-attached storage supplémentaire ou dans le cas de configurations matérielles sans disque, telles que les systèmes blade.
Si vous configurez votre hôte pour démarrer à partir d’un SAN, l’image de démarrage de votre hôte est stockée sur une ou plusieurs LUNs dans le système de stockage SAN. Au démarrage, l’hôte utilise la LUN du SAN plutôt que son disque en Direct-attached storage.
Pour les hôtes ESXi, vous pouvez démarrer à partir de software iSCSI, d’un independent hardware SCSI adapter pris en charge, ou d’un dependent hardware iSCSI adapter pris en charge. L’adaptateur réseau doit uniquement prendre en charge le format iSCSI Boot Firmware Table (iBFT), qui est une méthode de communication des paramètres du périphérique de démarrage iSCSI vers un système d’exploitation.
¶ À propos de vSphere Virtual Machine File System
Les hôtes ESXi prennent en charge vSphere Virtual Machine File System (VMFS), notamment VMFS5 et VMFS6 :
-
Fonctionnalités prises en charge par VMFS5 et VMFS6 :
- Accès simultané au stockage partagé
- Expansion dynamique
- Verrouillage sur disque
-
Fonctionnalités prises en charge uniquement par VMFS6 :
- Prise en charge des périphériques de stockage 4K natifs
- Libération automatique d’espace (automatic space reclamation)
- Jusqu’à 128 hôtes par datastore
VMFS est un système de fichiers en cluster dans lequel plusieurs hôtes ESXi peuvent lire et écrire simultanément sur le même périphérique de stockage. Ce système de fichiers en cluster fournit des services uniques, basés sur la virtualisation :
- Migration de machines virtuelles en cours d’exécution d’un hôte ESXi à un autre sans interruption.
- Redémarrage automatique d’une VM défaillante sur un hôte ESXi distinct.
- Mise en cluster de VMs à travers différents serveurs physiques.
Grâce à VMFS, les équipes informatiques peuvent simplifier le provisionnement des VMs en stockant efficacement l’ensemble de l’état d’une VM dans un emplacement central. Plusieurs hôtes ESXi peuvent accéder simultanément au stockage VM partagé.
La taille d’un datastore VMFS peut être augmentée dynamiquement, même lorsque les VMs hébergées sur ce datastore sont allumées et en cours d’exécution. Un datastore VMFS stocke efficacement à la fois de gros fichiers et de petits fichiers appartenant à une VM. Un datastore VMFS peut héberger des disques virtuels dont la taille maximale est de 62 To. Il utilise un adressage en sous-blocs pour optimiser l’utilisation du stockage pour les petits fichiers.
VMFS fournit un verrouillage distribué au niveau bloc pour garantir qu’une même VM ne soit pas démarrée en parallèle par plusieurs serveurs. Si un hôte ESXi tombe en panne, le verrou sur disque associé à chaque VM est libéré, ce qui permet aux VMs d’être redémarrées sur d’autres hôtes ESXi.
Sur le schéma associé, chaque hôte ESXi exécute deux VMs. Les lignes reliant les VMs aux disques virtuels (VMDK) représentent de manière logique l’association et l’allocation à un datastore VMFS plus large. Le datastore VMFS inclut un ou plusieurs LUNs. Les VMs perçoivent le volume de stockage assigné uniquement comme une cible SCSI dans leur système d’exploitation invité. En réalité, le contenu des VMs n’est constitué que de fichiers stockés sur le volume VMFS.
VMFS peut être déployé sur trois types de périphériques de stockage basés sur SCSI :
- Stockage Direct-attached (DAS)
- Stockage Fibre Channel
- Stockage iSCSI
Un disque virtuel stocké sur un datastore VMFS apparaît toujours à la VM comme un périphérique SCSI monté. Ce disque virtuel masque la couche de stockage physique au système d’exploitation de la VM.
Pour le système d’exploitation de la VM, VMFS préserve les sémantiques du système de fichiers interne. Ainsi, l’OS invité voit un système de fichiers natif et non VMFS. Ces sémantiques garantissent le bon fonctionnement et l’intégrité des données pour les applications exécutées sur les VMs.
¶ À propos de NFS
Network File System (NFS) est un protocole de partage de fichiers qu’utilisent les hôtes ESXi pour communiquer avec un périphérique de stockage en réseau (NAS).
NFS prend en charge NFS v3 et NFS v4.1 sur TCP/IP.
Le NAS est un périphérique de stockage spécialisé qui se connecte à un réseau et peut fournir des services d’accès aux fichiers aux hôtes ESXi.
Les datastores NFS sont traités comme des datastores VMFS car ils peuvent contenir des fichiers de VM, des modèles et des images ISO. De plus, comme un datastore VMFS, un volume NFS permet la migration vSphere vMotion des VM dont les fichiers résident sur un datastore NFS.
Le client NFS intégré à ESXi utilise les versions 3 et 4.1 du protocole NFS pour communiquer avec les serveurs NAS ou NFS.
Le verrouillage NFS 3 sur ESXi n’utilise pas le protocole NLM (Network Lock Manager), qui est un protocole standard servant à gérer le verrouillage des fichiers montés via NFS. VMware fournit à la place son propre protocole de verrouillage. Les verrous NFS 3 sont implémentés en créant des fichiers de verrouillage sur le serveur NFS.
NFS 4.1 utilise quant à lui un verrouillage côté serveur.
Comme les clients NFS 3 et NFS 4.1 n’utilisent pas le même protocole de verrouillage, tu ne peux pas utiliser différentes versions NFS pour monter le même datastore sur plusieurs hôtes. L’accès aux mêmes disques virtuels à partir de deux clients incompatibles peut entraîner un comportement incorrect et provoquer une corruption des données.
¶ À propos de vSAN
vSAN est une solution de stockage définie par logiciel et convergée au niveau de l’hyperviseur pour les environnements virtuels, qui n’utilise pas de stockage externe traditionnel.
En regroupant les disques SSD (solid-state drives) et les disques durs (HDDs) attachés aux hôtes, vSAN crée un datastore agrégé accessible à tous les hôtes ESXi du cluster vSAN.
Lorsque vSAN est activé sur un cluster, un datastore vSAN unique est créé. Ce datastore utilise les composants de stockage de chaque hôte du cluster.
vSAN peut être configuré en mode hybride ou en mode tout-flash :
-
Architecture hybride :
vSAN regroupe les disques HDD et SSD attachés aux serveurs pour créer un datastore distribué partagé. Ce datastore abstrait le matériel de stockage afin de fournir un tiers de stockage défini par logiciel pour les machines virtuelles (VMs).- Les disques flash sont utilisés comme cache de lecture/buffer d’écriture pour accélérer les performances.
- Les disques magnétiques (HDDs) assurent la capacité et le stockage persistant des données.
-
Architecture tout-flash :
vSAN peut aussi être déployé uniquement avec des périphériques flash.-
Les SSDs sont utilisés à la fois comme cache d’écriture et pour fournir la capacité, la persistance des données et des temps de réponse rapides et constants.
-
Cette architecture repose sur une hiérarchisation des SSDs pour réduire les coûts :
- Un tiers cache constitué de SSDs haut de gamme, conçus pour des écritures intensives.
- Un tiers capacité basé sur des SSDs plus économiques, optimisés pour des lectures intensives.
-
¶ À propos de vSphere Virtual Volumes (vVols)
vSphere Virtual Volumes apporte plusieurs fonctionnalités clés :
- Représentation native des VMDKs sur SAN/NAS. Plus besoin de gérer des LUNs ou des volumes traditionnels.
- Compatibilité avec les systèmes SAN/NAS existants. Fonctionne avec l’infrastructure de stockage déjà en place.
- Nouveau chemin de contrôle pour les opérations de données. Gestion au niveau de la VM et du VMDK plutôt qu’au niveau du LUN.
- Snapshots, réplication et autres opérations au niveau VM. Les fonctionnalités avancées de stockage (snapshots, réplications, clones, etc.) sont appliquées directement au niveau des VMs sur le stockage externe.
- Automatisation via des politiques de stockage. Permet de contrôler automatiquement les niveaux de service par VM grâce aux VM Storage Policies.
- Accès standardisé au stockage. Utilise le vSphere API for Storage Awareness (VASA) via un protocol endpoint.
- Conteneurs de stockage. Représentent des espaces de stockage logiques qui peuvent couvrir l’intégralité d’une baie de stockage.
vSphere Virtual Volumes virtualise les périphériques SAN et NAS en abstrayant les ressources matérielles physiques pour les transformer en pools logiques de capacité.
vSphere Virtual Volumes offre les avantages suivants :
- Réduction des coûts de stockage
- Diminution de la charge administrative liée à la gestion du stockage
- Meilleure évolutivité (scalabilité plus large et flexible)
- Amélioration des performances face aux besoins d’accès aux données et d’analytique
¶ À propos du Raw Device Mapping (RDM)
Bien que le Raw Device Mapping (RDM) ne soit pas un datastore, il permet à une machine virtuelle (VM) d’accéder directement à un LUN physique.
Un fichier de mappage (suffixe -rdm.vmdk) est créé pour pointer la VM vers le LUN physique.
Ce fichier de mappage doit obligatoirement être stocké sur un datastore VMFS.
Le Raw Device Mapping (RDM) est un fichier stocké dans un volume VMFS qui agit comme proxy pour un périphérique physique brut.
Au lieu de stocker les données d’une machine virtuelle (VM) dans un fichier de disque virtuel (VMDK) situé sur un datastore, tu peux stocker directement les données du système d’exploitation invité sur un LUN brut. Cette méthode est utile si tu exécutes des applications dans tes VMs qui doivent connaître les caractéristiques physiques réelles du périphérique de stockage. En mappant un LUN brut, tu peux utiliser les commandes SCSI existantes pour gérer le stockage du disque.
Le RDM est utilisé lorsqu’une VM doit interagir directement avec un disque réel du SAN.
Ceci est particulièrement le cas pour effectuer des snapshots au niveau de la baie de disques, ou gérer une grande quantité de données que tu ne veux pas déplacer dans un disque virtuel lors d’une conversion physique-vers-virtuel (P2V).
Le RDM peut être utilisé en deux modes :
- Mode de compatibilité virtuelle : le RDM se comporte comme s’il s’agissait d’un disque virtuel. Dans ce cas, tu peux utiliser des fonctionnalités comme les snapshots, le clonage, etc.
- Mode de compatibilité physique : donne un accès direct au périphérique sans virtualisation intermédiaire, idéal pour des besoins spécifiques de performances ou de compatibilité matérielle.
Le fichier pointeur RDM utilise l’extension -rdm.vmdk.
Le mode de compatibilité physique permet au système d’exploitation invité d’accéder directement au matériel.
- Ce mode est utile lorsque tu utilises des applications compatibles SAN (SAN-aware) dans la machine virtuelle.
- Dans ce cas, la VM peut interagir directement avec les caractéristiques physiques du périphérique de stockage sans abstraction intermédiaire.
Le fichier pointeur RDM utilise alors l’extension -rdmp.vmdk.
¶ Considérations sur le stockage physique
Avant de mettre en œuvre ton environnement vSphere, discute des besoins en stockage avec ton équipe d’administration du stockage. Prends en compte les facteurs suivants :
- Tailles des LUNs
- Bande passante d’E/S (I/O) requise par tes applications
- Nombre de requêtes d’E/S par seconde qu’une LUN peut supporter
- Paramètres du cache disque
- Zoning et masking
- Paramètres de multipathing pour tes baies de stockage (active-active ou active-passive)
- Propriétés d’exportation pour les datastores NFS
Pour plus d’informations afin de vous aider à planifier vos besoins en stockage, consultez les documentations suivantes : vSphere Storage et vSphere Storage – VMware Core
¶ Revue des objectifs d’apprentissage
- Reconnaître les technologies de stockage vSphere
- Identifier les types de datastores
- Reconnaître les conventions de nommage des périphériques de stockage
¶ Leçon 2 : Stockage Fibre Channel
¶ Objectifs d’apprentissage
• Décrire les utilisations de Fibre Channel avec ESXi
• Décrire les composants et l’adressage de Fibre Channel
• Expliquer le fonctionnement du multipathing avec Fibre Channel
¶ À propos de Fibre Channel
Fibre Channel est un protocole utilisé pour accéder aux périphériques de stockage à travers un réseau.
Un SAN Fibre Channel est un réseau spécialisé à haute vitesse qui connecte vos hôtes à des périphériques de stockage haute performance.
Le réseau utilise le protocole Fibre Channel pour transporter le trafic SCSI des machines virtuelles vers les périphériques du SAN Fibre Channel.
ESXi prend en charge :
- Fibre Channel 32 Gbps
- Fibre Channel over Ethernet (FCoE)
Pour se connecter au SAN Fibre Channel, votre hôte doit être équipé d’adaptateurs de bus hôte Fibre Channel (HBAs).
À moins que vous n’utilisiez un stockage Fibre Channel en connexion directe, vous avez besoin de commutateurs Fibre Channel pour acheminer le trafic de stockage.
Si votre hôte contient des adaptateurs FCoE, vous pouvez vous connecter à vos périphériques Fibre Channel partagés en utilisant un réseau Ethernet.
Dans cette configuration, un hôte se connecte à un SAN fabric, qui se compose de commutateurs Fibre Channel et de baies de stockage, en utilisant un adaptateur Fibre Channel.
Les LUNs d’une baie de stockage deviennent disponibles pour l’hôte. Vous pouvez accéder aux LUNs et créer des datastores pour vos besoins en stockage. Ces datastores utilisent le format VMFS.
En alternative, vous pouvez accéder à une baie de stockage qui prend en charge les vSphere Virtual Volumes et créer des datastores vSphere Virtual Volumes sur les conteneurs de stockage de la baie.
¶ Composants d’un SAN Fibre Channel
Un SAN Fibre Channel se compose d’un ou de plusieurs serveurs connectés à une baie de stockage à l’aide d’un ou de plusieurs commutateurs Fibre Channel.
Chaque serveur d’un SAN Fibre Channel peut héberger de nombreuses applications nécessitant un stockage dédié pour leur traitement.
Les composants suivants sont impliqués :
- Commutateurs SAN Fibre Channel : les commutateurs SAN connectent les différents éléments du SAN. Ils peuvent relier les hôtes aux baies de stockage. Grâce aux commutateurs SAN, vous pouvez mettre en place une redondance des chemins pour pallier toute défaillance entre un serveur hôte et un commutateur, ou entre une baie de stockage et un commutateur.
- Fabric : la SAN fabric correspond à la partie réseau du SAN. Lorsqu’un ou plusieurs commutateurs SAN sont interconnectés, une fabric est créée. Le protocole Fibre Channel (FC) est utilisé pour communiquer sur l’ensemble du réseau. Un SAN peut être composé de plusieurs fabrics interconnectées. Même un SAN simple se compose souvent de deux fabrics pour la redondance.
- Connexions (HBA et processeurs de stockage) : les serveurs hôtes et les systèmes de stockage sont reliés à la fabric SAN via des ports de la fabric :
— Un hôte se connecte à un port de la fabric via un HBA (Host Bus Adapter).
— Les périphériques de stockage se connectent aux ports de la fabric via leurs processeurs de stockage.
¶ Addressage Fibre Channel et Access Control
Un port connecte un périphérique au SAN. Chaque node dans le SAN inclut chaque host, storage device, et composant de fabric (router ou switch). Chaque node dans le SAN possède un ou plusieurs ports qui le connectent au SAN. Les ports peuvent être identifiés par leur Worldwide Port Name (WWPN). Le WWPN est un identifiant unique global pour un port qui permet à certaines applications d’accéder à ce port. Les Fibre Channel switches découvrent le WWPN d’un périphérique ou d’un host et attribuent une port address à ce périphérique.
Vous pouvez utiliser le zoning et le LUN masking pour séparer l’activité du SAN et restreindre l’accès aux storage devices.
Vous pouvez protéger l’accès au stockage dans votre environnement vSphere en utilisant le zoning et le LUN masking avec vos ressources SAN. Par exemple, vous pouvez gérer indépendamment les zones définies pour les tests dans le SAN afin qu’elles n’interfèrent pas avec l’activité dans les zones de production. De même, vous pouvez configurer différentes zones pour différents départements.
Lorsque vous configurez des zones, prenez en compte les host groups qui sont configurés sur le périphérique SAN.
Les fonctionnalités de zoning et de masking pour chaque SAN switch et disk array, ainsi que les outils de gestion du LUN masking, dépendent du fournisseur.
Consultez la documentation de votre fournisseur SAN et vSphere Storage à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Multipathing avec Fibre Channel
Le multipathing correspond au fait de disposer de plus d’un chemin entre un host et un LUN. Le multipathing fournit les fonctions suivantes :
- Accès continu aux SAN LUNs en cas de défaillance matérielle
- Load balancing
Un Fibre Channel path décrit une route :
- Depuis un HBA port spécifique dans le host
- À travers les switches dans la fabric
- Vers un storage port spécifique sur le storage array
Par défaut, les ESXi hosts utilisent seulement un chemin entre un host et un LUN donné à la fois. Si le chemin actuellement utilisé par l’ESXi host échoue, le serveur sélectionne un autre chemin disponible.
Le processus de détection d’un chemin défaillant et de basculement vers un autre est appelé path failover. Un chemin échoue si l’un des composants le long du chemin (HBA, câble, switch port, ou storage processor) tombe en panne.
Distinction entre les active-active disk arrays et les active-passive disk arrays peut être utile :
-
Un active-active disk array permet l’accès aux LUNs simultanément via les storage processors disponibles, sans dégradation significative des performances. Tous les paths sont actifs en permanence (sauf en cas d’échec d’un path).
-
Dans un active-passive disk array, un storage processor assure activement le service d’un LUN donné. L’autre storage processor agit comme une sauvegarde pour ce LUN et peut assurer activement le service d’autres LUN I/O.
Les I/O peuvent uniquement être envoyées à un active processor. Si le primary storage processor échoue, l’un des secondary storage processors devient actif, soit automatiquement, soit par intervention administrative.
¶ Revue des objectifs d’apprentissage
- Décrire les utilisations de Fibre Channel avec ESXi
- Décrire les composants et l’adressage de Fibre Channel
- Expliquer le fonctionnement du multipathing avec Fibre Channel
¶ Leçon 3 : iSCSI Storage
¶ Objectifs d’apprentissage
- Décrire les composants et l’adressage de iSCSI
- Configurer les iSCSI initiators
¶ Composants iSCSI
Un iSCSI SAN se compose d’un iSCSI storage system, qui contient des LUNs et des storage processors. La communication entre le host et le storage array s’effectue via un réseau Ethernet.
Un iSCSI SAN se compose d’un iSCSI storage system, qui contient un ou plusieurs LUNs et un ou plusieurs storage processors. La communication entre le host et le storage array s’effectue via un réseau TCP/IP.
L’ESXi host est configuré avec un iSCSI initiator. Un initiator peut être basé sur du matériel, où l’initiator est un iSCSI HBA. Ou bien l’initiator peut être basé sur un logiciel, connu sous le nom de iSCSI software initiator.
Un initiator transmet des commandes SCSI sur le réseau IP. Un target reçoit les commandes SCSI du réseau IP. Votre réseau iSCSI peut inclure plusieurs initiators et targets. L’iSCSI est orienté SAN pour les raisons suivantes :
- L’initiator trouve un ou plusieurs targets.
- Un target présente des LUNs à l’initiator.
- L’initiator envoie des commandes SCSI à un target.
Un initiator réside dans l’ESXi host. Les targets résident dans les storage arrays pris en charge par l’ESXi host.
Pour restreindre l’accès aux targets depuis les hosts, les iSCSI arrays peuvent utiliser divers mécanismes, notamment l’adresse IP, les subnets, et les exigences d’authentification.
¶ Adressage iSCSI
L’entité principale adressable et détectable est un iSCSI node. Un iSCSI node peut être un initiator ou un target. Un iSCSI node nécessite un name afin que le stockage puisse être géré indépendamment de l’adresse.
Le iSCSI name peut utiliser l’un des formats suivants : le iSCSI qualified name (IQN) ou l’extended unique identifier (EUI).
L’IQN peut comporter jusqu’à 255 caractères. Plusieurs conventions de nommage sont utilisées :
- Préfixe iqn
- Code de date spécifiant l’année et le mois au cours desquels l’organisation a enregistré le domaine ou le sous-domaine utilisé comme chaîne d’autorité de nommage
- Chaîne d’autorité de nommage organisationnelle, qui se compose d’un nom de domaine ou de sous-domaine valide, inversé
- (Optionnel) Deux-points ( : ) suivi d’une chaîne choisie par l’organisation attribuante, qui doit rendre chaque iSCSI name unique
Les conventions de nommage EUI sont les suivantes :
- Le préfixe est eui.
- Un nom de 16 caractères suit le préfixe.
Le nom inclut 24 bits pour un nom de société attribué par l’IEEE et 40 bits pour un identifiant unique, tel qu’un numéro de série.
¶ Adaptateurs iSCSI
Vous devez configurer des iSCSI adapters logiciels ou matériels avant qu’un ESXi host puisse fonctionner avec un iSCSI storage. Pour accéder aux iSCSI targets, votre host utilise des iSCSI initiators.
Les iSCSI initiators transportent les requêtes et réponses SCSI, encapsulées dans le protocole iSCSI, entre le host et la iSCSI target. Votre host prend en charge deux types d’initiators : software iSCSI et hardware iSCSI.
Un software iSCSI initiator est du code VMware intégré dans le VMkernel. En utilisant cet initiator, votre host peut se connecter au iSCSI storage device via des standard network adapters. Le software iSCSI initiator gère le traitement iSCSI tout en communiquant avec le network adapter. Avec le software iSCSI initiator, vous pouvez utiliser la technologie iSCSI sans acheter de matériel spécialisé.
Un hardware iSCSI initiator est un adaptateur spécialisé tiers capable d’accéder au iSCSI storage via TCP/IP. Les hardware iSCSI initiators sont divisés en deux catégories : dependent hardware iSCSI et independent hardware iSCSI.
Un dependent hardware iSCSI initiator, également connu sous le nom de iSCSI host bus adapter, est un standard network adapter qui inclut la fonction iSCSI offload. Pour utiliser ce type d’adaptateur, vous devez configurer le réseau pour le trafic iSCSI et lier l’adaptateur à un VMkernel iSCSI port approprié.
Un independent hardware iSCSI adapter gère tout le traitement et la gestion iSCSI et réseau pour votre ESXi host. Dans ce cas, un VMkernel iSCSI port n’est pas requis.
Pour des informations de configuration, consultez vSphere Storage à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Configuration réseau ESXi pour le Software iSCSI
Un VMkernel port doit être créé avant d’activer le software iSCSI initiator.
Pour optimiser la configuration réseau de votre vSphere, vous devez séparer les réseaux iSCSI des réseaux NAS et NFS :
- La séparation physique est préférable
- Si la séparation physique n’est pas possible, utilisez des VLANs
La configuration réseau pour le software iSCSI implique la création d’un VMkernel port sur un virtual switch afin de gérer votre trafic iSCSI.
Selon le nombre de physical adapters que vous souhaitez utiliser pour le trafic iSCSI, la configuration réseau peut varier :
- Si vous avez un physical network adapter, vous avez besoin d’un VMkernel port sur un virtual switch.
- Si vous avez deux ou plusieurs physical network adapters pour l’iSCSI, vous pouvez utiliser ces adaptateurs pour le host-based multipathing.
Les VMkernel ports sont également utilisés pour gérer la connexion au dependent hardware iSCSI.
Pour les performances et la sécurité, isolez votre réseau iSCSI des autres réseaux. Séparez physiquement les réseaux. Si la séparation physique des réseaux est impossible, séparez-les logiquement sur un seul virtual switch en configurant un VLAN distinct pour chaque réseau.
¶ Activation du Software iSCSI Adapter
Pour ajouter le software iSCSI adapter :
- Sélectionnez le host et cliquez sur l’onglet Configure.
- Sélectionnez Storage Adapters et cliquez sur ADD SOFTWARE ADAPTER > Add iSCSI adapter.
Le software iSCSI adapter (vmhba65) apparaît dans la liste.
Vous devez activer votre software iSCSI adapter afin que votre host puisse l’utiliser pour accéder au iSCSI storage.
Vous ne pouvez activer qu’un seul software iSCSI adapter.
Si vous démarrez depuis iSCSI en utilisant le software iSCSI adapter, l’adaptateur est actif et la configuration réseau est créée lors du premier démarrage. Si vous désactivez l’adaptateur, il est réactivé à chaque fois que vous démarrez le host.
¶ Découverte des iSCSI Targets
L’iSCSI adapter découvre les ressources de stockage sur le réseau et détermine quelles ressources sont disponibles pour l’accès.
Un ESXi host prend en charge les méthodes de découverte suivantes :
- Static
- Dynamic ou SendTargets
La réponse SendTargets renvoie l’IQN et toutes les adresses IP disponibles.
L’host ne voit pas les iSCSI LUNs tant qu’il ne peut pas communiquer avec le storage array. Pour cela, vous fournissez à l’host l’adresse IP des storage processors de l’array.
L’ESXi host prend en charge les méthodes de découverte de iSCSI targets suivantes :
- Static discovery : l’initiator n’a pas besoin d’effectuer de découverte. L’initiator connaît à l’avance toutes les targets qu’il contactera. Il utilise leurs adresses IP et noms de domaine pour communiquer avec elles.
- Dynamic discovery ou SendTargets discovery : chaque fois que l’initiator contacte un iSCSI server spécifié, il envoie une requête SendTargets au serveur. Le serveur répond en fournissant une liste de targets disponibles à l’initiator.
Les noms et adresses IP de ces targets apparaissent comme des static targets dans le vSphere Client. Vous pouvez supprimer une static target qui a été ajoutée par dynamic discovery. Si vous supprimez la target, celle-ci peut réapparaître dans la liste lors de la prochaine opération de rescan. La target peut également réapparaître si le HBA est réinitialisé ou si le host est redémarré.
¶ Sécurité iSCSI : CHAP
Les iSCSI initiators utilisent CHAP à des fins d’authentification.
Par défaut, CHAP n’est pas configuré.
ESXi prend en charge deux types d’authentification CHAP :
- Unidirectional
- Bidirectional
ESXi prend également en charge l’authentification CHAP par target.
Vous pouvez implémenter CHAP pour fournir une authentification entre les iSCSI initiators et les targets.
ESXi prend en charge les méthodes d’authentification CHAP suivantes :
- Unidirectional ou one-way CHAP : la target authentifie l’initiator, mais l’initiator n’authentifie pas la target. Vous devez spécifier le CHAP secret afin que vos initiators puissent accéder à la target.
- Bidirectional ou mutual CHAP : avec un niveau de sécurité supplémentaire, l’initiator peut authentifier la target. Vous devez spécifier des secrets différents pour la target et l’initiator.
CHAP utilise un algorithme de three-way handshake pour vérifier l’identité de votre host et, le cas échéant, de la iSCSI target lorsque le host et la target établissent une connexion. La vérification est basée sur une valeur privée prédéfinie, ou CHAP secret, que l’initiator et la target partagent. ESXi implémente CHAP tel que défini dans la RFC 1994.
ESXi prend en charge l’authentification CHAP au niveau de l’adapter. Toutes les targets reçoivent le même CHAP secret de l’iSCSI initiator. Pour les software iSCSI initiators et les dependent hardware iSCSI initiators, ESXi prend également en charge l’authentification CHAP par target.
Avant de configurer CHAP, vérifiez si CHAP est activé sur le iSCSI storage system et quelle méthode d’authentification CHAP le système prend en charge. Si CHAP est activé, vous devez aussi l’activer pour vos initiators, en vérifiant que les informations d’identification CHAP correspondent à celles configurées sur le iSCSI storage.
L’utilisation de CHAP dans votre implémentation iSCSI SAN est recommandée, mais consultez votre fournisseur de stockage afin de garantir que les meilleures pratiques sont respectées.
Vous pouvez protéger vos données de manières supplémentaires. Par exemple, vous pouvez protéger votre iSCSI SAN en lui dédiant un standard switch. Vous pouvez également configurer le iSCSI SAN sur son propre VLAN pour améliorer les performances et la sécurité. Certains dispositifs réseau en ligne peuvent être implémentés pour fournir du chiffrement et renforcer la protection des données.
¶ Multipathing avec le Software iSCSI
Le software iSCSI utilise plusieurs NICs :
- Chaque NIC est connecté à un VMkernel port distinct.
- Chaque VMkernel port est lié à l’iSCSI initiator.
Lors de la configuration de votre ESXi host pour le multipathing et le failover, vous pouvez utiliser plusieurs hardware iSCSI adapters ou plusieurs NICs. Le choix dépend du type d’iSCSI initiators présents sur votre host.
Avec le software iSCSI, vous pouvez utiliser plusieurs NICs qui fournissent un failover pour les connexions iSCSI entre votre host et les iSCSI storage systems.
Une fois le iSCSI multipathing configuré, chaque port de l’ESXi host possède sa propre adresse IP, mais les ports partagent le même iSCSI initiator IQN. Lorsque le iSCSI multipathing est configuré, la VMkernel routing table n’est pas consultée pour identifier le outbound NIC à utiliser. À la place, le iSCSI multipathing est géré à l’aide des vSphere multipathing modules. En raison de la latence qui peut en découler, le routage du trafic iSCSI n’est pas recommandé.
¶ Multipathing avec le Dependent Hardware iSCSI
Le dependent hardware iSCSI utilise plusieurs NICs et iSCSI HBAs :
- Chaque NIC est connecté à un VMkernel port distinct.
- Chaque VMkernel port est lié à l’iSCSI initiator.
Un dependent hardware iSCSI adapter est un adaptateur tiers qui dépend de la configuration vSphere networking et iSCSI.
Lorsqu’un dependent hardware iSCSI adapter est installé sur un ESXi host, il présente ses deux composants — un standard network adapter (vmnic) et un iSCSI engine — sur le même port. L’iSCSI engine apparaît dans la liste des storage adapters comme un iSCSI adapter (vmhba).
L’iSCSI adapter est activé par défaut. Pour le rendre fonctionnel, vous devez le connecter, via un VMkernel adapter (vmk), à un physical network adapter (vmnic) qui lui est associé. Vous pouvez ensuite configurer l’iSCSI adapter.
¶ Multipathing avec l’Independent Hardware iSCSI
L’independent hardware iSCSI utilise deux ou plusieurs hardware iSCSI adapters.
Avec l’independent hardware iSCSI, l’host dispose généralement de deux ou plusieurs hardware iSCSI adapters, à partir desquels le storage system peut être atteint en utilisant un ou plusieurs switches.
En alternative, la configuration peut inclure un seul adapter et deux storage processors, de sorte que l’adapter puisse utiliser un chemin différent pour atteindre le storage system.
¶ Liaison des VMkernel Ports avec l’iSCSI Initiator
Avec le port binding, chaque VMkernel port connecté à une NIC distincte devient un chemin différent que la iSCSI storage stack peut utiliser.
Avec le software iSCSI et le dependent hardware iSCSI, les multipathing plug-ins n’ont pas d’accès direct aux physical NICs de votre host. Pour cette raison, vous devez d’abord connecter chaque physical NIC à un VMkernel port distinct. Ensuite, vous utilisez une technique de port binding pour associer tous les VMkernel ports à l’iSCSI initiator.
Pour le dependent hardware iSCSI, vous devez installer correctement la physical network card, qui doit apparaître dans l’onglet Configure du host, dans la vue Virtual Switches.
¶ Lab 9 : Accès au stockage iSCSI
Configurer l’accès à un iSCSI datastore :
- Afficher une configuration iSCSI existante sur un ESXi host
- Ajouter un VMkernel port pour le IP Storage
- Ajouter un deuxième VMkernel port pour le IP Storage
- Ajouter le iSCSI Software Adapter à un ESXi host
- Découvrir les LUNs sur le iSCSI Target Server
Retrouvez le lien du Lab en cliquant ici : Lab 9 : Accès au stockage iSCSI
¶ Revue des objectifs d’apprentissage
- Décrire les composants et l’adressage iSCSI
- Configurer les iSCSI initiators
¶ Leçon 4 : VMFS Datastores
¶ Objectifs d’apprentissage
- Créer un VMFS datastore
- Augmenter la taille d’un VMFS datastore
- Supprimer un VMFS datastore
¶ À propos des VMFS Datastores
VMFS est un système de fichiers en cluster haute performance qui sert de référentiel pour des fichiers tels que les fichiers de VM, les VM templates et les images ISO.
Un VMFS datastore est optimisé pour le stockage et l’accès à de gros fichiers, tels que les virtual disks et les images mémoire de VMs suspendues.
Un VMFS datastore peut avoir une taille de volume maximale de 64 To.
¶ Création d’un VMFS Datastore
Vous pouvez créer des VMFS datastores sur n’importe quel périphérique de stockage basé sur SCSI découvert par l’host, y compris le Fibre Channel, l’iSCSI, et les périphériques de stockage locaux.
¶ Parcours du contenu d’un Datastore
Vous utilisez le datastore file browser pour gérer le contenu de vos datastores.
Le Datastores pane répertorie tous les datastores actuellement configurés pour tous les ESXi hosts gérés.
L’exemple montre le contenu du VMFS datastore nommé ICM-Datastore. Le contenu du datastore est constitué de dossiers qui contiennent les fichiers des virtual machines ou des templates.
¶ Augmentation de la taille des VMFS Datastores
Augmentez la taille d’un VMFS datastore pour lui donner plus d’espace ou éventuellement améliorer les performances.
En général, avant de modifier votre allocation de stockage :
- Effectuez un rescan pour vous assurer que tous les hosts voient l’état le plus récent du stockage.
- Notez l’identifiant unique du volume que vous souhaitez étendre.
Pour augmenter dynamiquement la taille d’un VMFS datastore, utilisez l’une des méthodes suivantes :
- Ajouter une extent (LUN).
- Étendre le datastore dans son extent.
Un exemple d’identifiant unique d’un volume est le NAA ID. Vous avez besoin de cette information pour identifier le VMFS datastore dont la taille doit être augmentée.
Vous pouvez augmenter dynamiquement la capacité d’un VMFS datastore si le datastore ne dispose pas d’assez d’espace disque. Vous découvrez que l’espace disque est insuffisant lorsque vous créez une VM ou que vous essayez d’ajouter plus d’espace disque à une VM.
Utilisez l’une des méthodes suivantes :
- Ajouter une extent au VMFS datastore : une extent est une partition sur un LUN. Vous pouvez ajouter une extent à n’importe quel VMFS datastore. Le datastore peut s’étendre sur plusieurs extents, jusqu’à 32.
- Étendre le VMFS datastore : vous augmentez la taille du VMFS datastore en étendant d’abord son extent sous-jacent.
¶ Mode de maintenance du Datastore
Avant de retirer un datastore du service, placez le datastore en maintenance mode.
Avant de placer un datastore en maintenance mode, vous devez d’abord déplacer toutes les VMs (sous tension et hors tension) ainsi que les templates vers un autre datastore.
Le datastore entre en maintenance mode une fois que toutes les VMs et les templates ont été déplacés hors du datastore.
En sélectionnant la case Let me migrate storage for all virtual machines and continue entering maintenance mode after migration, l’assistant Migrate wizard démarre, vous offrant la possibilité de migrer les VMs vers un autre datastore.
Si des VM templates existent sur le datastore, vous pouvez convertir les templates en VMs, migrer les VMs vers un autre datastore, puis reconvertir les VMs en VM templates.
Le maintenance mode du datastore est une fonction de la fonctionnalité vSphere Storage DRS, mais vous pouvez utiliser le maintenance mode sans activer vSphere Storage DRS.
Si vSphere Storage DRS est configuré et en mode totalement automatisé, les migrations de VMs se font automatiquement.
Pour plus d’informations sur vSphere Storage DRS, consultez vSphere Resource Management à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Suppression ou démontage d’un datastore VMFS
Un datastore unmounted reste intact, mais n’est pas visible depuis les hosts que vous spécifiez.
Il continue d’apparaître sur les autres hosts, où il reste mounted.
Un datastore deleted est détruit et disparaît de tous les hosts qui y ont accès.
Le datastore deleted supprime définitivement tous les fichiers présents sur le datastore.
Le unmounting d’un datastore VMFS conserve les fichiers présents sur le datastore mais rend le datastore inaccessible à l’ESXi host.
Ne réalisez aucune opération de configuration susceptible de générer des entrées/sorties (I/O) vers le datastore pendant que le unmounting est en cours.
Vous pouvez supprimer (delete) n’importe quel type de datastore VMFS, y compris les copies que vous avez mounted sans réinscription (re-signing). Bien que vous puissiez supprimer le datastore sans le unmounting, il est recommandé de d’abord effectuer le unmounting.
La suppression (deleting) d’un datastore VMFS détruit les pointeurs vers les fichiers présents sur le datastore, ce qui fait disparaître ces fichiers de tous les hosts ayant accès au datastore.
Avant de supprimer (delete) ou de démonter (unmount) un datastore VMFS, mettez hors tension (power off) toutes les VMs dont les disques résident sur ce datastore.
Si vous ne mettez pas les VMs hors tension et que vous tentez de continuer, un message d’erreur vous indique que la ressource est occupée (resource is busy).
Avant de unmount un datastore VMFS, utilisez le vSphere Client pour vérifier les conditions suivantes :
- Aucune virtual machine ne réside sur le datastore.
- Le datastore ne fait pas partie d’un datastore cluster.
- Le datastore n’est pas géré par vSphere Storage DRS.
- vSphere Storage I/O Control est désactivé.
- Le datastore n’est pas utilisé pour le vSphere HA heartbeat.
Pour conserver vos données, sauvegardez le contenu de votre datastore VMFS avant de supprimer (delete) le datastore.
¶ Algorithmes de multipathing
Les arrays fournissent des processeurs de stockage en mode active-active et active-passive. Les algorithmes de multipathing interagissent avec ces storage arrays :
- vSphere offre une sélection de chemin native (path selection), ainsi que des mécanismes de répartition de charge (load-balancing) et de basculement (failover).
- Les fournisseurs tiers (third-party vendors) peuvent créer des logiciels pour les ESXi hosts afin d’interagir correctement avec les storage arrays.
L’architecture de stockage enfichable (Pluggable Storage Architecture) est une couche du VMkernel chargée de gérer plusieurs chemins de stockage (storage paths) et d’assurer la répartition de charge (load balancing).
Un ESXi host peut être connecté à des storage arrays configurés avec des processeurs de stockage en mode active-active ou active-passive.
VMware propose des mécanismes natifs de load balancing et de failover.
Les stratégies de sélection de chemin (path selection policies) de VMware incluent les exemples suivants :
- Round Robin
- Most Recently Used (MRU)
- Fixed
Les fournisseurs tiers (third-party vendors) peuvent concevoir leurs propres techniques de load balancing et de failover pour certains types de storage arrays, afin d’ajouter la prise en charge de nouveaux arrays.
Les fournisseurs tiers n’ont pas besoin de fournir à VMware d’informations internes ni de propriété intellectuelle concernant l’array.
¶ Configuration de la répartition de charge du stockage
Les politiques de sélection de chemin (path selection policies) offrent :
-
Scalabilité :
— Round Robin -
Disponibilité :
— Most Recently Used (MRU)
— Fixed
Il est possible d’avoir plusieurs chemins (paths) entre un ESXi host et un datastore.
Pour le multipathing avec Fibre Channel ou iSCSI, les politiques de sélection de chemin (path selection policies) suivantes sont prises en charge :
-
Fixed : l’host utilise toujours le chemin préféré (preferred path) vers le disque lorsque ce chemin est disponible. Si l’host ne peut pas accéder au disque par le chemin préféré, il essaie les chemins alternatifs. Cette politique est la politique par défaut pour les périphériques de stockage active-active.
-
Most Recently Used (MRU) : l’host sélectionne le premier chemin fonctionnel détecté au démarrage du système. Lorsque ce chemin devient indisponible, l’host choisit un chemin alternatif. L’host ne revient pas au chemin d’origine lorsque celui-ci redevient disponible. La politique Most Recently Used n’utilise pas le paramètre de chemin préféré (preferred path setting). Cette politique est la politique par défaut pour les périphériques de stockage active-passive et elle est obligatoire pour ces périphériques.
-
Round Robin : en plus du basculement de chemin (path failover), cette politique prend en charge la répartition de charge (load balancing) entre les chemins. Par défaut, le mécanisme de latence (latency mechanism) est activé sur l’host. Ce mécanisme prend en compte la bande passante I/O et la latence de chemin pour sélectionner un chemin optimal pour les I/O. Lors de l’utilisation du mécanisme de latence, la politique Round Robin peut sélectionner dynamiquement le chemin optimal et obtenir de meilleurs résultats de répartition de charge. Avant d’utiliser cette politique, vérifiez auprès des fournisseurs de stockage si une configuration Round Robin est prise en charge sur leur stockage.
¶ Lab 10 : Gestion des datastores VMFS
Créez des datastores VMFS, augmentez la taille de ces datastores et partagez des datastores entre des ESXi hosts :
- Créer des datastores VMFS pour les ESXi hosts
- Étendre un datastore VMFS pour utiliser l’espace inutilisé d’un LUN
- Supprimer un datastore VMFS
- Agrandir un datastore VMFS en ajoutant un LUN
Retrouvez le lien du Lab en cliquant ici : Lab 10 : Gestion des datastores VMFS
¶ Revue des objectifs d’apprentissage
- Créer un datastore VMFS
- Augmenter la taille d’un datastore VMFS
- Supprimer un datastore VMFS
¶ Leçon 5 : Datastores NFS
¶ Objectifs d’apprentissage
- Identifier les composants NFS
- Reconnaître les différences entre NFS 3 et NFS 4.1
- Configurer et gérer des datastores NFS
¶ Composants NFS
Un système de fichiers NFS se trouve sur un périphérique NAS appelé NFS server.
Le NFS server contient un ou plusieurs répertoires qui sont partagés avec l’ESXi host via un réseau TCP/IP.
Un ESXi host accède au NFS server par l’intermédiaire d’un port VMkernel défini sur un virtual switch.
¶ NFS 3 et NFS 4.1
Un datastore NFS peut être créé soit en NFS 3, soit en NFS 4.1.
| NFS 3 | NFS 4.1 |
|---|---|
| ESXi managed multipathing | Native multipathing et session trunking |
| Authentification AUTH_SYS (root) | Authentification Kerberos optionnelle |
| VMware proprietary client-side file locking | Server-side file locking |
| Client-side error tracking | Server-side error tracking |
Des problèmes de compatibilité entre les deux versions de NFS empêchent l’accès à un même datastore en utilisant simultanément les deux protocoles depuis des hosts différents.
Si un datastore est configuré en NFS 4.1, tous les hosts qui y accèdent doivent monter le partage en NFS 4.1.
Une corruption de données peut se produire si des hosts accèdent à un datastore avec la mauvaise version de NFS.
¶ Compatibilité des versions NFS avec d’autres technologies vSphere
vSphere prend en charge NFS 4.1 afin de surmonter de nombreuses limitations liées à l’utilisation de NFS 3. Les partages NFS 3 et NFS 4.1 peuvent être utilisés, mais il est important de prendre en compte certaines contraintes lors de la conception d’un environnement vSphere dans lequel les deux versions sont déployées.
| Technologie vSphere | NFS 3 | NFS 4.1 |
|---|---|---|
| vSphere vMotion et vSphere Storage vMotion | Yes | Yes |
| vSphere HA et vSphere Fault Tolerance | Yes | Yes |
| vSphere DRS et vSphere DPM | Yes | Yes |
| Stateless ESXi et Host Profiles | Yes | Yes |
| vSphere Storage DRS et Storage I/O Control | Yes | No |
| Site Recovery Manager | Yes | Partial* |
| vSphere Virtual Volumes et vSphere Replication | Yes | Yes |
| vRealize Operations Manager | Yes | Yes |
| Host Profiles | Yes | Yes |
- Site Recovery Manager ne prend pas en charge les datastores NFS 4.1 pour la réplication basée sur les arrays ni pour la réplication des vSphere Virtual Volumes. Vous pouvez utiliser Site Recovery Manager avec des datastores NFS 4.1 pour la vSphere Replication.
Améliorations offertes par NFS 4.1 :
- Native multipathing et session trunking : NFS 4.1 fournit le multipathing pour les serveurs qui prennent en charge le session trunking. Lorsque le trunking est disponible, vous pouvez utiliser plusieurs adresses IP pour accéder à un seul volume NFS. Le Client ID trunking n’est pas pris en charge.
- Kerberos authentication : NFS 4.1 introduit l’authentification Kerberos, en plus de la méthode traditionnelle AUTH_SYS utilisée par NFS 3.
- Amélioration du file locking intégré.
- Récupération d’erreurs améliorée grâce au suivi côté serveur (server-side tracking) des fichiers ouverts et des délégations.
- De nombreuses améliorations d’efficacité générale, notamment les session leases et une réduction de la surcharge du protocole (protocol overhead).
Nouvelles fonctionnalités offertes par le client NFS 4.1 :
- Stateful locks avec réservation de partage, utilisant une sémantique de verrouillage obligatoire (mandatory locking semantic).
- Intégration du protocole, le protocole auxiliaire (side-band protocol) n’est plus nécessaire pour le verrouillage et le montage.
- Trunking (véritable NFS multipathing) : plusieurs chemins (sessions) vers l’NAS array peuvent être créés et la charge est répartie entre ces sessions.
- Récupération d’erreurs améliorée pour atténuer les défaillances serveur et les pertes de connectivité.
¶ Configuration des datastores NFS
Pour configurer un datastore NFS :
-
Créer un port VMkernel :
- Pour de meilleures performances et une sécurité renforcée, séparez votre réseau NFS du réseau iSCSI.
-
Créer le datastore NFS en fournissant les informations suivantes :
- Version NFS : 3 ou 4.1
- Nom du datastore
- Noms ou adresses IP du NFS server
- Dossier sur le NFS server, par exemple : /templates ou /nfs_share
- Indiquer si le système de fichiers NFS doit être monté en lecture seule (read only)
- Hosts qui montent le datastore
- Paramètres d’authentification
Pour chaque ESXi host qui accède à un datastore NFS via le réseau, un port VMkernel doit être configuré sur un virtual switch. Le nom de ce port peut être choisi librement.
Pour des raisons de performance et de sécurité, isolez vos réseaux NFS des autres réseaux, tels que votre réseau iSCSI et vos réseaux de virtual machines.
¶ Configuration de l’authentification des hôtes ESXi et des identifiants Kerberos NFS
Comme exigence de l’authentification Kerberos, vous devez ajouter chaque ESXi host au domaine Active Directory. Ensuite, vous configurez les identifiants Kerberos pour NFS.
Vous devez effectuer plusieurs étapes de configuration pour préparer chaque ESXi host à utiliser l’authentification Kerberos.
L’authentification Kerberos exige que tous les nœuds impliqués (le serveur Active Directory, les NFS servers et les ESXi hosts) soient synchronisés afin qu’il n’existe que très peu ou pas de dérive temporelle. L’authentification Kerberos échoue si une dérive significative existe entre les nœuds.
Pour préparer votre ESXi host à utiliser l’authentification Kerberos, configurez les paramètres du client NTP afin de référencer un serveur NTP commun (ou le domain controller, le cas échéant).
Lors de la planification de l’utilisation de NFS Kerberos, prenez en compte les points suivants :
- NFS 3 et NFS 4.1 utilisent des identifiants d’authentification différents, ce qui entraîne des UID et GID incompatibles sur les fichiers.
- L’utilisation d’utilisateurs Active Directory différents sur plusieurs hosts accédant au même partage NFS peut provoquer l’échec d’une migration vSphere vMotion.
- La configuration NFS Kerberos peut être automatisée à l’aide des host profiles pour réduire les conflits de configuration.
- L’heure doit être synchronisée entre tous les composants participants.
Pour plus de détails sur la configuration des ESXi hosts pour l’authentification Kerberos, consultez vSphere Storage à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Configuration du datastore NFS pour utiliser Kerberos
Lors de la création de chaque datastore NFS 4.1, vous activez l’authentification Kerberos en sélectionnant l’un des modes de sécurité suivants :
- Kerberos5 authentication
- Kerberos5i authentication and data integrity
Après avoir effectué les étapes de configuration initiales, vous pouvez configurer le datastore pour utiliser l’authentification Kerberos.
La capture d’écran montre un choix entre une authentification Kerberos simple (krb5) ou une authentification avec intégrité des données (krb5i).
Le mode krb5i garantit que les attaques de type man-in-the-middle qui modifient les données peuvent être détectées.
Avec krb5, ces attaques ne peuvent pas être détectées.
Pour plus d’informations sur la configuration des ESXi hosts pour l’authentification Kerberos, consultez vSphere Storage à l’adresse : https://docs.vmware.com/en/VMware-vSphere/index.html.
¶ Démontage d’un datastore NFS
Le démontage d’un datastore NFS rend les fichiers sur le datastore inaccessibles aux ESXi hosts sélectionnés.
Avant de démonter un datastore NFS, vous devez éteindre toutes les VMs dont les disques résident sur le datastore.
¶ Multipathing et stockage NFS
Pour une architecture NAS hautement disponible, configurez le NFS multipathing afin d’éviter les points uniques de défaillance.
Exemple de configuration multipathing :
- Configurez un port VMkernel.
- Attachez des NICs au même switch physique pour configurer le NIC teaming.
- Configurez le serveur NFS avec plusieurs adresses IP (le même sous-réseau est acceptable).
- Pour mieux utiliser plusieurs liaisons, configurez les NIC teams avec la stratégie d’équilibrage de charge IP hash.
Des exemples de point unique de défaillance (SPOF) dans l’architecture NAS incluent la carte NIC dans un ESXi host, ainsi que le câble entre la carte NIC et le switch.
Pour éviter les points uniques de défaillance et créer une architecture NAS hautement disponible, configurez l’ESXi host avec des cartes NIC redondantes et des switches physiques redondants.
La meilleure approche consiste à installer plusieurs NICs sur un ESXi host et à les configurer en NIC teams. Les NIC teams doivent être configurées sur des switches externes distincts, chaque paire de NIC étant configurée comme une équipe sur le switch externe respectif.
De plus, vous pouvez appliquer un algorithme d’équilibrage de charge basé sur le type de protocole d’agrégation de liens pris en charge sur le switch externe, tel que 802.3ad ou EtherChannel.
Un niveau encore plus élevé de performance et de haute disponibilité peut être atteint avec des switches capables de cross-stack EtherChannel. Avec certains switches réseau, vous pouvez regrouper des ports à travers deux ou plusieurs switches physiques distincts, gérés comme un switch logique unique.
Le NIC teaming à travers des virtual switches fournit une résilience supplémentaire et une certaine optimisation des performances. Le fait d’avoir plus de chemins disponibles vers l’ESXi host peut améliorer les performances en activant un partage de charge distribué.
Un seul chemin actif est disponible pour la connexion entre l’ESXi host et une seule cible de stockage (LUN ou point de montage). Bien que des connexions alternatives puissent être disponibles pour le failover, la bande passante pour un seul datastore et le stockage sous-jacent est limitée à ce qu’une seule connexion peut fournir.
Pour utiliser plus de bande passante disponible, un ESXi host nécessite plusieurs connexions entre l’ESXi host et les cibles de stockage. Vous pourriez avoir besoin de configurer plusieurs datastores, chacun utilisant des connexions séparées entre l’ESXi host et le stockage.
Le tableau montre la configuration recommandée pour le NFS multipathing.
| Les switches externes prennent en charge le cross-stack EtherChannel | Les switches externes ne prennent pas en charge le cross-stack EtherChannel |
|---|---|
| Configurez un port VMkernel. | Configurez deux ports VMkernel ou plus sur différents virtual switches dans différents sous-réseaux. |
| Configurez le NIC teaming en utilisant des adaptateurs connectés à des switches physiques distincts. | Configurez le NIC teaming avec des adaptateurs connectés au même switch physique. |
| Configurez le serveur NFS avec plusieurs adresses IP. Les adresses IP peuvent être sur le même sous-réseau. | Configurez le serveur NFS avec plusieurs adresses IP. Les adresses IP peuvent être sur le même sous-réseau. |
| Pour utiliser plusieurs liaisons, configurez les NIC teams avec la stratégie d’équilibrage de charge IP hash. | Pour utiliser plusieurs liaisons, laissez la table de routage VMkernel décider quel lien utiliser pour envoyer les paquets (nécessite plusieurs datastores). |
¶ Configuration du multipathing pour NFS 4.1
NFS 4.1 prend en charge le multipathing natif et le session trunking.
Pour configurer le multipathing, saisissez plusieurs adresses IP du serveur lors de la configuration du datastore.
NFS 4.1 fournit le multipathing pour les serveurs qui prennent en charge le session trunking.
Lorsque le trunking est disponible, vous pouvez utiliser plusieurs adresses IP pour accéder à un volume NFS unique.
Le Client ID trunking n’est pas pris en charge.
¶ Lab 11 : Accès au stockage NFS
Créez un datastore NFS et enregistrez ses informations de stockage :
- Configurer l’accès à un datastore NFS
- Afficher les informations de stockage NFS
Retrouvez le lien du Lab en cliquant ici : Lab 11 : Accès au stockage NFS
¶ Revue des objectifs d’apprentissage
- Identifier les composants NFS
- Reconnaître les différences entre NFS 3 et NFS 4.1
- Configurer et gérer des datastores NFS
¶ Points clés
- Les ESXi hosts prennent en charge différentes technologies de stockage : Direct-attached storage, Fibre Channel, FCoE, iSCSI et NAS.
- Les datastores VMFS et NFS contiennent les fichiers des VMs.
- vSAN et vSphere Virtual Volumes contiennent les objets VM.
- Avec le port binding, chaque port VMkernel connecté à une NIC distincte devient un chemin différent que le stockage iSCSI peut utiliser.
- Le stockage partagé est essentiel aux fonctionnalités de vSphere telles que vSphere vMotion, vSphere HA et vSphere DRS.
Chapitre précédent : 5 - Configuration du réseau vSphere - Chapitre suivant : 7 - Déploiement de machines virtuelles (VMs)