ONTAP Select vSAN et configurations de baies externes
Les déploiements NAS virtuels (vNAS) prennent en charge les clusters ONTAP Select sur SAN virtuel (vSAN), certains produits HCI et les types de baies externes de banques de données. L'infrastructure sous-jacente de ces configurations assure la résilience des banques de données.
L’exigence minimale est que l’hyperviseur que vous utilisez (VMware ESXi ou KVM sur un hôte Linux pris en charge) prenne en charge la configuration sous-jacente. Si l'hyperviseur est ESXi, il doit être répertorié dans les HCL VMware respectifs.
Architecture vNAS
La nomenclature vNAS est utilisée pour toutes les configurations qui n'utilisent pas de DAS. Pour les clusters ONTAP Select multi-nœuds, cela inclut les architectures pour lesquelles les deux nœuds ONTAP Select d'une même paire haute disponibilité partagent un seul datastore (y compris les datastores vSAN). Les nœuds peuvent également être installés sur des datastores distincts issus de la même baie externe partagée. Cela permet d'obtenir des efficacités de stockage côté baie afin de réduire l'encombrement global de l'ensemble de la paire haute disponibilité ONTAP Select. L'architecture des solutions ONTAP Select vNAS est très similaire à celle d'ONTAP Select sur DAS avec un contrôleur RAID local. C'est-à-dire que chaque nœud ONTAP Select continue d'avoir une copie des données de son partenaire de haute disponibilité. Les politiques d'efficacité du stockage ONTAP sont appliquées au niveau du nœud. Par conséquent, les efficacités de stockage côté baie sont préférables car elles peuvent potentiellement être appliquées aux ensembles de données des deux nœuds ONTAP Select.
Il est également possible que chaque nœud ONTAP Select d'une paire HA utilise une baie externe distincte. Ce choix est commun avec ONTAP Select MetroCluster SDS et un stockage externe.
Lors de l'utilisation de baies externes distinctes pour chaque nœud ONTAP Select, il est très important que les deux baies présentent des caractéristiques de performances similaires à la machine virtuelle d'ONTAP Select.
Architectures vNAS par rapport à DAS local avec contrôleurs RAID matériels
L'architecture vNAS est logiquement la plus similaire à l'architecture d'un serveur avec DAS et un contrôleur RAID. Dans les deux cas, ONTAP Select utilise un espace de datastore. L'espace du datastore est divisé en VMDK et ces VMDK constituent les agrégats de données ONTAP traditionnels. ONTAP Deploy garantit que les VMDK sont correctement dimensionnés et attribués au plex approprié (dans le cas de paires haute disponibilité) lors des opérations de création et d'ajout de stockage en cluster.
Il existe deux différences majeures entre vNAS et DAS avec un contrôleur RAID. La différence la plus immédiate est que vNAS ne nécessite pas de contrôleur RAID. VNAS assure que la baie externe sous-jacente fournit la persistance et la résilience des données qu'un DAS avec une configuration de contrôleur RAID fournit. La deuxième différence, plus subtile, est quant aux performances de la NVRAM.
NVRAM vNAS
La NVRAM ONTAP Select est un VMDK. Cela signifie ONTAP Select émule un espace adressable en octets ( NVRAM traditionnelle) sur un périphérique adressable en bloc (VMDK). Cependant, les performances de la NVRAM sont essentielles aux performances globales du nœud ONTAP Select .
Pour les configurations DAS avec un contrôleur RAID matériel, le cache du contrôleur RAID matériel agit comme cache NVRAM , car toutes les écritures dans le VMDK NVRAM sont d'abord hébergées dans le cache du contrôleur RAID.
Pour les architectures VNAS, ONTAP Deploy configure automatiquement les nœuds ONTAP Select avec un argument de démarrage appelé consignation de données à instance unique (SIDL). Lorsqu'il s'agit d'un argument de démarrage, ONTAP Select ignore la mémoire NVRAM et écrit les données directement dans l'agrégat de données. La mémoire NVRAM n'est utilisée que pour enregistrer l'adresse des blocs modifiés par l'opération D'ÉCRITURE. Cette fonctionnalité permet d'éviter une double écriture : une écriture sur la mémoire NVRAM et une seconde écriture lorsque la mémoire NVRAM est déchargée. Cette fonctionnalité n'est activée que sur vNAS, car les écritures locales sur le cache du contrôleur RAID présentent une latence supplémentaire négligeable.
La fonction SIDL n'est pas compatible avec toutes les fonctionnalités d'efficacité du stockage ONTAP Select. La fonction SIDL peut être désactivée au niveau de l’agrégat à l’aide de la commande suivante :
storage aggregate modify -aggregate aggr-name -single-instance-data-logging off
|
|
Les performances d'écriture sont affectées si la fonction SIDL est désactivée. Il est possible de réactiver la fonction SIDL après que toutes les stratégies d'efficacité du stockage sur tous les volumes de cet agrégat ont été désactivées : |
volume efficiency stop -all true -vserver * -volume * (all volumes in the affected aggregate)
Colocaliser les nœuds ONTAP Select lors de l'utilisation de vNAS sur ESXi
ONTAP Select inclut la prise en charge des clusters ONTAP Select multi-nœuds sur stockage partagé. ONTAP Deploy permet la configuration de plusieurs nœuds ONTAP Select sur le même hôte ESXi, à condition que ces nœuds ne fassent pas partie du même cluster.
|
|
Cette configuration est uniquement valable pour les environnements VNAS (banques de données partagées). Plusieurs instances ONTAP Select par hôte ne sont pas prises en charge lors de l'utilisation d'un stockage DAS, car ces instances se disputent le même contrôleur RAID matériel. |
ONTAP Deploy garantit que le déploiement initial du cluster VNAS multi-nœuds n’entraîne pas le placement de plusieurs instances ONTAP Select issues du même cluster sur le même hôte. La figure suivante illustre un exemple de déploiement correct de deux clusters à quatre nœuds qui se recoupent sur deux hôtes.
Déploiement initial de clusters VNAS multi-nœuds

Une fois le déploiement terminé, les nœuds ONTAP Select peuvent être migrés entre des hôtes. Cela pourrait entraîner des configurations non optimales et non prises en charge pour lesquelles deux nœuds ONTAP Select ou plus du même cluster partagent le même hôte sous-jacent. NetApp recommande la création manuelle de règles d'anti-affinité des VM afin que VMware maintienne automatiquement la séparation physique entre les nœuds du même cluster, et pas seulement les nœuds de la même paire haute disponibilité.
|
|
Les règles anti-affinité exigent que DRS soit activé sur le cluster ESXi. |
Consultez l'exemple suivant sur la manière de créer une règle d'anti-affinité pour les machines virtuelles ONTAP Select. Si le cluster ONTAP Select contient plusieurs paires haute disponibilité, tous les nœuds du cluster doivent être inclus dans cette règle.


Deux ou plusieurs nœuds ONTAP Select du même cluster ONTAP Select peuvent potentiellement se trouver sur le même hôte ESXi pour l'une des raisons suivantes :
-
DRS n'est pas présent en raison des limites de licence VMware vSphere ou si DRS est activé.
-
La règle anti-affinité DRS est contournée car l'opération VMware HA ou la migration VM initiée par l'administrateur est prioritaire.
|
|
ONTAP Deploy ne surveille pas de manière proactive les emplacements des machines virtuelles ONTAP Select. Cependant, une opération d'actualisation du cluster reflète cette configuration non prise en charge dans les journaux ONTAP Deploy : |