Dell PowerStore: Metro Volume72 min read

Temps de lecture : 44 minutes

 

Vue d’ensemble

La prévention de la perte de données ou de transactions nécessite une méthode fiable de protection continue des données et de haute disponibilité. Pour éviter les catastrophes et les pannes planifiées, les applications et les services doivent être mis à disposition sur un site alternatif. Diverses méthodes de mobilité des données, notamment la réplication asynchrone, peuvent permettre de fournir des répliques hors site. Dell PowerStore propose des solutions natives et non natives pour protéger les données et aider les entreprises à atteindre leurs objectifs commerciaux en matière de disponibilité et de protection des données. Les solutions de réplication natives PowerStore peuvent répliquer les données vers d’autres systèmes, qu’ils se trouvent sur le même site ou sur un site distant. La réplication synchrone avec Metro Volume se différencie des autres méthodes en garantissant la cohérence transactionnelle entre les clusters PowerStore en fonctionnement normal. Ce livre blanc se concentre sur PowerStore Metro Volume et fournit une couverture approfondie de ses caractéristiques.

 

Introduction

Planification de la continuité des activités

Les données sont l’un des actifs les plus précieux d’une organisation. Les utilisateurs (et parfois leurs clients) accèdent constamment aux données, directement et indirectement, en utilisant diverses applications. Les données sont donc un élément crucial des opérations quotidiennes. Les pannes peuvent survenir à tout moment et se limiter à un seul système ou à un centre de données ou un site entier. Qu’il s’agisse d’interruptions planifiées, comme une maintenance régulière, ou d’événements imprévus, comme une panne de courant, il est primordial de s’assurer que les données critiques sont toujours disponibles. Un plan de continuité des activités pour les données critiques peut prévenir ces pannes coûteuses. Pour se protéger contre différents scénarios de panne, une entreprise doit planifier et mettre en œuvre une stratégie de protection des données qui inclut une solution de réplication des données.

Pour se protéger contre une panne du système de stockage, vous pouvez utiliser la réplication asynchrone pour créer une copie des données sur un système distant. La réplication est une fonctionnalité logicielle qui synchronise les données sur un système distant au sein du même site ou d’un autre emplacement. La réplication des données permet d’assurer la redondance des données et de se prémunir contre les défaillances du système de stockage sur le site de production principal. Le fait de disposer d’un site distant de reprise après sinistre (DR) permet de se prémunir contre les pannes de système et de site. Il fournit également un emplacement distant qui peut reprendre la production et minimiser les temps d’arrêt dus à un sinistre. La plateforme PowerStore offre de nombreuses solutions de protection des données qui peuvent répondre aux besoins de DR dans divers environnements.

La réplication asynchrone est principalement utilisée pour répliquer des données sur de longues distances, mais vous pouvez également l’utiliser pour répliquer vers des systèmes situés au même endroit. La réplication asynchrone pour PowerStore est conçue pour avoir un impact minimal sur la latence des E/S de l’hôte. Les écritures de l’hôte sont reconnues une fois qu’elles sont sauvegardées sur la ressource de stockage locale, et aucune autre écriture n’est nécessaire pour le suivi des changements. Comme les opérations d’écriture ne sont pas immédiatement répliquées sur une ressource de destination, toutes les écritures sont suivies sur la source. Ces données sont répliquées lors de la synchronisation suivante. Avec les politiques de protection, la réplication asynchrone utilise le concept d’objectif de point de récupération (RPO). Le RPO est la quantité acceptable de données, qui est mesurée en unités de temps, qui peut être perdue en raison d’une panne. Ce delta de temps affecte également la quantité de données qui doit être répliquée lors de la prochaine synchronisation. Il reflète également le montant de la perte potentielle de données dans un scénario de catastrophe.

Un Metro Volume en bloc fournit une réplication synchrone, répartie sur deux clusters PowerStore individuels pour une configuration VMware vSphere Metro Storage Cluster. Un Metro Volume permet d’éviter les sinistres et constitue une solution d’équilibrage de charge lorsque les clusters PowerStore participants se trouvent dans le même bâtiment ou à une distance métropolitaine. Les entrées/sorties actives/actives simultanées des hôtes sont possibles des deux côtés et sont répliquées sur le système distant. Les hôtes peuvent se connecter aux deux clusters PowerStore simultanément avec des chemins actifs pour plus de redondance (configuration uniforme des hôtes). L’architecture étendue permet la mobilité des charges de travail et l’équilibrage automatique de la charge entre les sites, ainsi qu’une récupération rapide pour une utilisation optimale du centre de données et l’évitement des temps d’arrêt.

Vous pouvez configurer toutes les fonctions de réplication natives de PowerStore en utilisant PowerStore Manager, PowerStore CLI ou REST API. PowerStore peut également s’intégrer à Dell metro node, VPLEX et RecoverPoint for Virtual Machines. Alors que Metro Node et VPLEX fournissent une fonction de volume métropolitain sur différentes baies de stockage, RecoverPoint for Virtual Machines prend en charge la réplication de VM pour PowerStore. Vous pouvez la configurer à l’aide de l’interface utilisateur Unisphere Manager for RecoverPoint.

 

Aperçu de Power

PowerStore atteint de nouveaux niveaux de simplicité et d’agilité opérationnelles. Il utilise une architecture microservices basée sur des conteneurs, des technologies de stockage avancées et un apprentissage automatique intégré pour libérer la puissance de vos données. PowerStore est une plateforme polyvalente avec une conception centrée sur les performances qui offre une échelle multidimensionnelle, une réduction des données en permanence et une prise en charge des supports de nouvelle génération.

PowerStore apporte la simplicité du cloud public à l’infrastructure sur site, en rationalisant les opérations avec un moteur d’apprentissage automatique intégré et une automatisation transparente. Il offre également des analyses prédictives pour surveiller, analyser et dépanner facilement l’environnement. PowerStore est hautement adaptable, offrant la flexibilité d’héberger des charges de travail spécialisées directement sur l’appliance et de moderniser l’infrastructure sans interruption. Il offre également une protection des investissements grâce à des solutions de paiement flexibles et à des mises à niveau des données sur place.

La plateforme PowerStore est disponible en deux modèles de produits : les modèles PowerStore T et les modèles PowerStore X. Les modèles PowerStore T sont des baies de stockage unifié à nu qui peuvent gérer des ressources de blocs, de fichiers et de volumes virtuels VMware vSphere (vVols) ainsi que de nombreux services de données et d’efficacité. Les appliances PowerStore X permettent d’exécuter des applications directement sur l’appliance grâce à la fonction AppsON. Une couche native VMware ESXi exécute les applications intégrées à côté du système d’exploitation PowerStore, le tout sous forme de machines virtuelles. Cette fonction s’ajoute à la fonctionnalité de stockage traditionnelle des appliances PowerStore X et permet de servir du stockage externe par blocs et vVol aux serveurs avec FC et iSCSI.

Terminologie

Le tableau suivant fournit des définitions pour certains des termes utilisés dans ce document.

 

  • Terminologie

Term

Definition

Appliance

Solution contenant une armoire de base et des armoires d’extension attachées. La taille d’un appareil peut correspondre uniquement à l’armoire de base ou à l’armoire de base plus les armoires d’extension.

Asynchronous Logical Unit Access (ALUA)

PowerStore utilise une ALUA implicite qui permet à PowerStore de fournir un chemin optimisé actif recommandé vers une ressource de stockage pour les hôtes.

Asynchronous replication

Méthode de réplication qui permet de répliquer des données sur de longues distances et de maintenir une réplique sur un site de destination. Les mises à jour de l’image de destination peuvent être émises manuellement, ou automatiquement en fonction d’un RPO personnalisable.

Bandwidth

Quantité de données, représentée en MB/s, qui peut être transférée dans une période donnée.

Common base

Paire d’instantanés pris sur une ressource de stockage source et destination de réplication qui ont la même image ponctuelle.

Destination storage resource

Ressource de stockage qui est utilisée pour la reprise après sinistre dans une session de réplication. Ce terme est également connu sous le nom d’image cible.

Fibre Channel (FC) protocol

Protocole utilisé pour exécuter des commandes IP et SCSI sur un réseau Fibre Channel.

File system

Ressource de stockage à laquelle on peut accéder via des protocoles de partage de fichiers tels que SMB ou NFS.

Internal snapshot (replication snapshot)

Le système crée des instantanés unifiés et fait partie d’une session de réplication asynchrone. Ces instantanés ne sont visibles que dans l’interface CLI de PowerStore ou l’API REST de PowerStore, et la modification manuelle n’est pas possible. Chaque session de réplication asynchrone utilise jusqu’à deux instantanés internes qui sont pris sur les ressources de stockage source et destination. Chaque session utilise également un instantané en lecture/écriture sur le système de stockage de destination. Les derniers instantanés internes réussis en lecture seule (RO) pour les ressources de stockage source et destination sont utilisés comme base commune.

iSCSI

Fournit un mécanisme d’accès au stockage de données par blocs sur des connexions réseau.

Metro Volume

Volume de blocs PowerStore répliqué de manière synchrone.

Network-attached storage (NAS) server

Serveur de stockage de niveau fichier utilisé pour héberger des systèmes de fichiers. Un serveur NAS est nécessaire pour créer des systèmes de fichiers qui utilisent des partages SMB ou NFS.

Network File System (NFS)

Un protocole d’accès qui permet l’accès aux données à partir d’hôtes Linux ou UNIX sur un réseau.

PowerStore base enclosure

Boîtier contenant les deux nœuds (nœud A et nœud B) et 25 emplacements pour lecteurs NVMe

PowerStore CLI

Outil qui peut être installé sur un système d’exploitation pour gérer un système PowerStore.

PowerStore cluster

Un groupe d’un ou plusieurs appareils. Il est possible de mettre en grappe jusqu’à quatre appliances PowerStore en ajoutant des appliances selon les besoins.

PowerStore Command Line Interface (PSTCLI)

Outil qui peut être installé sur un système d’exploitation pour gérer un système PowerStore. Il permet à un utilisateur d’effectuer des tâches sur le système de stockage en tapant des commandes au lieu d’utiliser l’interface utilisateur graphique.

PowerStore expansion enclosure

Armoire qui peut être attachée à une armoire de base pour fournir un stockage supplémentaire.

PowerStore Manager

Interface de gestion basée sur le web pour créer des ressources de stockage et configurer et planifier la protection des données stockées sur PowerStore. PowerStore Manager peut être utilisé pour toute la gestion de la réplication native de PowerStore.

PowerStore node

Contrôleur de stockage qui fournit les ressources de traitement pour effectuer les opérations de stockage et gérer les E/S entre le stockage et les hôtes. Chaque appliance PowerStore contient deux nœuds.

PowerStore Representational State Transfer (REST) API

Ensemble de ressources (objets), d’opérations et d’attributs qui fournissent un contrôle de gestion interactif, scénarisé et programmatique du cluster PowerStore.

PowerStore T model

Système de stockage basé sur des conteneurs et fonctionnant sur du matériel spécialement conçu. Ce système de stockage prend en charge les charges de travail unifiées (blocs et fichiers), ou les charges de travail optimisées pour les blocs.

PowerStore X model

Système de stockage basé sur des conteneurs qui fonctionne à l’intérieur d’une machine virtuelle déployée sur un hyperviseur VMware. En plus d’offrir des charges de travail optimisées pour les blocs, PowerStore permet également aux utilisateurs de déployer des applications directement sur la baie.

RecoverPoint for Virtual Machines

Protège les machines virtuelles (VM) dans un environnement VMware avec une granularité au niveau des VM et fournit une réplication locale ou distante pour toute récupération ponctuelle. Cette fonction est intégrée à VMware vCenter et dispose de capacités d’orchestration et d’automatisation intégrées.

Recovery point objective (RPO)

Quantité acceptable de données, mesurée en unités de temps, qui peut être perdue en raison d’une panne. Par exemple, si une ressource de stockage a un RPO d’une heure, les données écrites sur la ressource de stockage au cours de la dernière heure peuvent être perdues lorsque la session de réplication est basculée sur la ressource de stockage de destination.

Recovery time objective (RTO)

Durée pendant laquelle un processus métier doit être restauré après un sinistre. Par exemple, un RTO d’une heure exige de restaurer l’accès aux données dans l’heure qui suit un sinistre.

Remote systems

Relation qui est configurée entre deux systèmes PowerStore pour établir une session de réplication.

Replication session

Relation qui est configurée entre deux ressources de stockage du même type sur des systèmes différents, et qui synchronise automatiquement les données d’une ressource à l’autre.

Snapshot

Également appelé instantané unifié, un instantané est une vue ponctuelle d’une ressource de stockage. Lorsqu’un instantané est pris, il crée une copie exacte de la ressource de stockage source et partage tous les blocs de données avec elle. Lorsque les données changent sur la source, de nouveaux blocs sont alloués et écrits. La technologie d’instantané unifié peut être utilisée pour prendre un instantané d’une ressource de stockage de blocs ou de fichiers.

Storage resource

Objet de niveau supérieur qu’un utilisateur peut approvisionner et qui est associé à une quantité spécifique de stockage. Toutes les activités d’accès à l’hôte et de protection des données sont effectuées à ce niveau. Dans ce document, les ressources de stockage font référence aux ressources qui prennent en charge la réplication, telles que les volumes, les groupes de volumes et les clones légers.

Synchronous replication

Méthode de réplication dans laquelle l’hôte initie une écriture dans le système du site local. Les données doivent être stockées avec succès dans les systèmes local et de destination avant qu’un accusé de réception ne soit envoyé à l’hôte. Garantit un RPO sans perte de données tant que la source et la destination sont synchronisées.

Thin clone

Copie en lecture-écriture d’une ressource de stockage en blocs légers (volume, groupe de volumes ou datastore VMFS de VMware vSphere) qui partage des blocs avec la ressource parente.

Unisphere Manager for RecoverPoint

Web-based interface for managing RecoverPoint replication. It serves as a single pane of glass for replicating storage resources of multiple storage systems that are configured to use RecoverPoint. Consistency groups are created, replicated, and recovered through this interface.

User snapshot

Instantané que l’utilisateur crée manuellement ou qu’une politique de protection crée avec une règle d’instantané associée. Ce type de snapshot est différent d’un snapshot interne, que le système avec réplication asynchrone prend automatiquement.

Virtual Volumes (vVols)

Cadre de stockage VMware qui permet aux données des machines virtuelles d’être stockées sur des volumes virtuels individuels. Cette capacité permet d’appliquer des services de données au niveau de la granularité de la VM tout en utilisant la gestion basée sur les politiques de stockage (SPBM).

Volume

Ressource de stockage par bloc qu’un utilisateur fournit. Il représente une unité logique SCSI.

Volume group

Instance de stockage qui contient un ou plusieurs volumes dans un système de stockage. Les groupes de volumes peuvent être configurés avec une cohérence d’ordre d’écriture et aident à organiser le stockage alloué à des hôtes particuliers.

vStorage API for Array Integration (VAAI)

API VMware qui permet de décharger les tâches liées au stockage sur le système de stockage.

vSphere API for Storage Awareness (VASA)

API VMware qui fournit des informations supplémentaires sur les capacités de stockage dans vSphere.

vSphere Metro Storage Cluster (vMSC)

Solution basée sur VMware qui combine la réplication avec la mise en grappe basée sur la matrice.

 

 

Metro Volume

 

Introduction

Un Metro Volume fournit une réplication synchrone de volumes de stockage de blocs étendus sur deux clusters PowerStore en distance métro pour les datastores VMFS. Cette section décrit la prise en charge des Metro Volume de blocs natifs PowerStore dans une architecture vSphere Metro Storage Cluster (vMSC). Un vMSC fournit des centres de données entièrement actifs et équilibrés en termes de charge de travail avec des ressources dans un cluster vSphere étendu. L’infrastructure du cluster étendu peut se trouver dans le même centre de données, ou même au-delà des frontières du site, sur deux sites différents, à distance métropolitaine. La configuration Metro Volume permet d’éviter les catastrophes et les temps d’arrêt grâce à la haute disponibilité (HA) et à la tolérance aux pannes (FT) de vSphere. Cependant, elle ne doit pas être la solution principale pour la reprise après sinistre car elle ne permet pas d’attribuer des politiques de redémarrage des VM, contrairement à SRM. Lorsqu’elle est activée, cette fonction permet à un opérateur de configurer des Metro Volumes entièrement actifs sur deux clusters PowerStore Model T exécutant PowerStoreOS 3.0 ou une version ultérieure. L’architecture stretch permet la mobilité de la charge de travail et l’équilibrage automatique de la charge entre les sites. Lorsqu’un Metro Volume est entièrement synchronisé, il permet à l’hôte d’accéder simultanément en lecture et en écriture au même Metro Volume sur les deux clusters PowerStore participants. Un mécanisme de polarisation intégré protège contre une situation de cerveau divisé pendant un scénario de panne. Une fois la panne corrigée, PowerStore lance un processus d’auto-réparation pour remettre le Metro Volume dans un état actif-actif.

La version PowerStoreOS 3.0 supporte la configuration de Metro Volume avec des volumes standards uniquement. La fonctionnalité Metro Volume utilise la configuration commune du système distant pour la gestion de la réplication et le trafic de données de réplication via une connexion Ethernet (LAN). Les sections suivantes montrent la configuration dans PowerStore Manager, bien que l’utilisation de la CLI et de l’API REST de PowerStore soit également supportée. Les sous-sections suivantes traitent de ces sujets :

– Caractéristiques

– Exigences de licence pour Metro Volume

– Fonctionnement de la fonctionnalité Metro Volume

– Configurations prises en charge pour Metro Volume

– PowerStore Manager : Configuration et gestion de Metro Volume

 

Fonctionnalités

 

Architecture Metro Volume symétrique active-active : Les entrées/sorties en lecture et en écriture peuvent se faire directement sur l’un ou l’autre des clusters PowerStore hébergeant le Metro Volume. La réplication synchrone bidirectionnelle garantit la synchronisation des volumes sur les deux clusters en fonctionnement normal.

Gestion non perturbatrice du cycle de vie : Vous pouvez approvisionner et mettre hors service les Metro Volumes sans interruption. Les autres tâches de configuration, telles que la modification d’un rôle privilégié, n’interfèrent pas avec les entrées/sorties des applications.

Prise en charge des instantanés (snapshot) : Les snapshots d’utilisateurs créés par une politique de protection sur les Metro Volumes sont disponibles sur chaque cluster PowerStore hébergeant un Metro Volume. Vous pouvez utiliser les snapshots pour diverses raisons, comme la création de clones légers ou l’exécution d’opérations de rafraîchissement et de restauration de volumes. Pendant l’état actif-actif d’un Metro Volume, les snapshots sont pris simultanément sur les deux clusters PowerStore et donnent des snapshots presque identiques. Pour les snapshots pris lorsque Metro Volume n’est pas dans l’état actif-actif, les snapshots sont répliqués sur le système homologue après que l’auto-réparation rétablisse le Metro Volume.

Connectivité de l’hôte : Metro Volume supporte la connectivité frontale VMware ESXi FC ou iSCSI avec une présentation de stockage uniforme ou non uniforme.

Intégration VMware : Metro Volume est conçu pour fonctionner en tandem avec vSphere High Availability (HA) et Fault Tolerance (FT). De plus, il est conforme aux états ALUA et s’intègre au multipathing de stockage vSphere.

Prise en compte du coût du chemin d’une topologie uniforme : Lors de l’utilisation d’une présentation de stockage uniforme, Metro Volume prend en charge les états ALUA granulaires pour les chemins équidistants et non équidistants.

Cas d’utilisation proactifs : Metro Volume prend en charge les cas d’utilisation proactifs tels que la maintenance planifiée, la prévention des sinistres, l’équilibrage des charges et la migration.

Pause : Vous pouvez mettre en pause la protection de Metro Volume pour des opérations de maintenance et la reprendre ultérieurement.

Auto-réparation : Metro Volume est synchronisé et rétabli dans un état actif-actif automatiquement.

 

 

Licences

La réplication Metro Volume est incluse dans la licence de base sans coût supplémentaire pour les clusters PowerStore supportés.

 

Théorie du fonctionnement

Vous pouvez utiliser chaque volume standard sur un cluster PowerStore pour créer un Metro Volume qui s’étend à un système PowerStore distant. L’option de configuration de Metro Volume est disponible dans PowerStore Manager > Volume overview, ou dans le sous-onglet Protection > Metro Volume > Volumes details, et elle nécessite une configuration du système distant. Lorsque vous sélectionnez le système distant et que la création de Metro Volume démarre, PowerStore configure une session de réplication Metro et lance la synchronisation initiale du volume sur le système distant. Lorsque le système distant est un cluster PowerStore multi-devices, PowerStore peut placer le volume automatiquement sur le meilleur appareil applicable sur le cluster PowerStore distant. Alternativement, PowerStore Manager vous permet de sélectionner une appliance spécifique dans la configuration de Metro Volume. Pendant la synchronisation initiale, même si le volume n’est pas utilisable sur un PowerStore distant pour les entrées/sorties des hôtes, le nouveau Metro Volume pourrait être déjà mappé aux hôtes. Pour la synchronisation initiale, PowerStore utilise le même processus de réplication asynchrone basé sur des snapshots, comme décrit dans le document PowerStore: Replication Technologies. Alors que le Metro Volume n’est pas complètement synchronisé entre les clusters PowerStore, des cycles de réplication asynchrones sont continuellement en cours. Pour les synchronisations finales, la réplication passe d’une réplication incrémentale à une synchronisation différentielle.

Lorsque les Metro Volumes sont complètement synchronisés, PowerStore passe à l’état actif-actif et active les E/S de l’hôte sur le cluster PowerStore distant. La durée de la synchronisation initiale dépend de la quantité de données sur la source et de l’activité d’écriture de l’hôte sur le volume. Pendant le fonctionnement normal, PowerStore génère des snapshots internes qui sont cohérents sur les deux clusters PowerStore. Les snapshots internes sont utilisés comme base commune lorsqu’un volume Metro doit être resynchronisé, par exemple, après une pause ou une fracture. Si une nouvelle synchronisation est nécessaire, PowerStore utilise la dernière base commune pour une réplication asynchrone jusqu’à ce que Metro Volume soit synchronisé sur les deux clusters PowerStore et passe dans l’état actif-actif. Lorsque l’état indique Operating Normally (actif-actif), les hôtes peuvent effectuer des E/S simultanées sur les deux clusters PowerStore. PowerStore contrôle le chemin actif avec un accès implicite aux unités logiques asynchrones (ALUA). Chaque Metro Volume sur une appliance a des chemins ALUA actifs-optimisés vers le volume sur un nœud. Il dispose également de chemins actifs ALUA non optimisés vers le même volume sur les autres nœuds. Cependant, un hôte peut utiliser plusieurs chemins vers les deux nœuds pour les E/S. L’affinité de nœud du volume individuel est le facteur déterminant pour sélectionner le chemin actif-optimisé pour une appliance.

Polarisation

L’une des situations les plus critiques pour un Metro Volume est un scénario de « split-brain » lorsque les deux volumes d’un Metro Volume sont actifs simultanément. Cette situation peut conduire à avoir des données différentes sur les deux volumes et peut nécessiter une intervention manuelle. Pour éviter une situation de « split brain », PowerStore utilise la polarisation pour le traitement des pannes. Pour chaque Metro Volume, un volume est assigné avec un rôle préféré tandis que le côté pair est configuré avec un rôle non préféré. Le côté préféré initial d’un Metro Volume est le côté où la configuration de la session de réplication du Metro Volume a été effectuée. La figure suivante montre un exemple du côté distribué et préféré des Metro Volumes.

Rôles de volume de métro distribué

 

            Vous pouvez changer le rôle préféré en rôle non préféré, et inversement, dans PowerStore Manager. Cette action ne perturbe pas les hôtes lorsqu’un Metro Volume est dans le statut Operating Normally. Pendant que la session Metro Volume fonctionne avec le statut actif-actif, le cluster PowerStore doit s’assurer que les E/S peuvent être répliquées vers l’appliance PowerStore pair. Les deux clusters vérifient constamment le cluster homologue et ne servent les E/S sur les hôtes du côté non préféré que lorsque le côté préféré est disponible. La polarisation se produit lorsqu’un côté ne répond pas et entraîne un état « failure » pour les volumes Metro affectés. Lorsque la polarisation est invoquée et que le côté préféré détermine que le côté non préféré n’est pas disponible, le trafic de réplication est arrêté et les E/S des hôtes du côté préféré continuent. Du côté non préféré, les hôtes ne reçoivent pas d’accusé de réception pour leurs écritures, les E/S s’arrêtent et les chemins deviennent indisponibles ALUA. Dans cette situation où les chemins sont indisponibles, le serveur ESXi affiche un événement APD (All Path Down) pour les volumes de stockage de données concernés. En fonction de la connectivité de l’hôte, les VM affectées continuent ou VMware HA doit redémarrer les VM sur les hôtes avec des chemins vers le volume préféré.

Polarization pendant un scenario de failure

Après le rétablissement de la connexion, PowerStore initie l’auto-réparation du Metro Volume avec les données du volume le plus courant. Sans intervention manuelle, le volume préféré est considéré comme le plus actuel, et l’auto-réparation initie la synchronisation du côté préféré vers le côté non préféré. L’auto-réparation utilise la dernière base commune et ne nécessite pas une synchronisation complète.

Pendant la polarisation, seuls les hôtes ayant des chemins vers le côté préféré peuvent accéder au volume. Lorsqu’un volume Metro n’est pas dans un état prévu pour l’accès des hôtes, vous pouvez utiliser les opérations de promotion et de rétrogradation pour remplacer le rôle préféré ou non préféré d’un volume Metro. L’opération de promotion active l’E/S hôte sur le côté non préféré d’un Metro Volume, et l’opération de rétrogradation désactive l’E/S hôte sur le côté préféré. Après une opération de promotion, PowerStore détermine que les données du côté promu sont plus actuelles que celles du côté préféré, et commence l’auto-réparation du volume promu au volume rétrogradé. Une intervention manuelle non désirée lors de l’opération de promotion peut conduire à une situation de split-brain. Cela pourrait entraîner une perte de données car les données de production du côté préféré pourraient être écrasées par les données du côté promu pendant l’auto-réparation. PowerStore aide à atténuer le risque potentiel de perte de données en effectuant un snapshot avant d’exécuter les actions de promotion et de rétrogradation, et lorsque l’auto-réparation commence.

 

Connectivité de l’hôte

Dans une configuration Metro Volume, PowerStore supporte l’accès uniforme et non-uniforme des hôtes. Pendant l’enregistrement de l’hôte, l’opérateur peut choisir la connectivité de l’hôte qui définit également les états ALUA pour les chemins individuels.

Dans une configuration de connectivité hôte non-uniforme (montrée ci-dessous), chaque hôte a des chemins vers une seule appliance PowerStore. Par exemple, les hôtes du Site-A ne sont connectés qu’au cluster PowerStore du Site-A, et les hôtes du Site-B ne sont connectés qu’au cluster PowerStore du Site-B. Puisque le Metro Volume est réparti sur les deux clusters PowerStore, le Metro Volume mappé est le même pour tous les hôtes du cluster.

Connectivité hôte non uniforme

Connectivité hôte non uniforme

 

Dans une configuration avec une connectivité hôte uniforme (montrée ci-dessous), chaque hôte a des chemins actifs vers les deux clusters PowerStore. Par exemple, tous les hôtes dans le Site-A et le Site-B sont mappés à PowerStore dans le Site-A et le Site-B. Cette configuration offre une résilience supplémentaire. En cas de défaillance d’une baie ou de perte de lien, les VM peuvent continuer à fonctionner sur n’importe quel hôte en utilisant les chemins d’accès à la baie non affectée avec le volume préféré.

 

Connectivité uniforme des hôtes

Connectivité uniforme des hôtes

 

Configuration de l’hôte

PowerStore Manager vous permet de sélectionner le type de connectivité de l’hôte lors de l’enregistrement d’un nouvel hôte. Les schémas suivants montrent la configuration possible des hôtes.

Connectivité locale : Cette configuration permet à l’hôte et à l’application d’accéder aux volumes standard et au Metro Volume exclusivement dans ce système de stockage. Utilisez cette configuration pour les volumes standard, et pour les Metro Volumes sur la PowerStore dans une configuration hôte non uniforme. L’exemple suivant montre que l’hôte H1 est connecté au cluster PowerStore PS1 dans une configuration hôte non uniforme.

Connectivité locale

L’hôte est co-localisé avec le système local : Utilisez cette option avec les Metro Volumes qui ont des chemins non équidistants dans une présentation de stockage uniforme lorsque l’hôte et le PowerStore sont locaux l’un par rapport à l’autre. En d’autres termes, l’hôte et le PowerStore se trouvent dans le même centre de données ou sont connectés de manière optimale. Utilisez cette option pour les hôtes locaux dont la latence est inférieure à celle des hôtes distants. Dans cette configuration, les hôtes tentent toujours d’envoyer des E/S vers le volume métropolitain sur ce système, sauf en cas de défaillance, et il en résulte un chemin actif-optimisé pour les hôtes. Comme indiqué ci-dessous, vous pouvez utiliser cette configuration pour une connexion hôte uniforme sur le cluster PowerStore PS1 pour l’hôte H1 qui se trouve au même endroit.

 

Hôte co-localisé avec un système en local

 

L’hôte est co-localisé avec le système distant : Utilisez cette option avec les Metro Volumes qui ont des chemins non équidistants dans une présentation de stockage uniforme lorsque l’hôte et le PowerStore ne sont pas locaux l’un par rapport à l’autre. En d’autres termes, l’hôte et le PowerStore sont dans des centres de données différents avec une latence significative entre les deux. Utilisez cette option pour les hôtes qui sont éloignés du cluster PowerStore avec une latence plus élevée que les hôtes locaux. L’hôte n’envoie des E/S au volume Metro sur ce système qu’en cas de défaillance, ce qui entraîne des chemins actifs non optimisés pour les hôtes. Comme indiqué ci-dessous, vous pouvez utiliser cette configuration pour une connexion hôte uniforme sur le cluster PowerStore PS1 pour l’hôte H2 qui se trouve dans un emplacement distant avec une latence plus élevée.

L’hôte est co-localisé avec le système distant

L’hôte est co-localisé avec les deux systèmes : Utilisez cette option avec les Metro Volumes qui ont des chemins équidistants dans une présentation de stockage uniforme lorsque l’hôte et les deux clusters PowerStore sont locaux l’un par rapport à l’autre. En d’autres termes, l’hôte et les deux clusters PowerStore se trouvent dans le même centre de données ou sont connectés de manière optimale. L’hôte utilise sa propre configuration multipath pour déterminer le meilleur chemin pour les E/S. Cette option est utile pour les configurations où tous les hôtes ont la même latence vers le cluster PowerStore. Si vous utilisez cette option pour les deux clusters PowerStore, il en résulte des chemins optimisés actifs vers les deux extrémités d’un Metro Volume. Vous pouvez utiliser cette option lorsque les hôtes H1 et H2 et les clusters PowerStore PS1 et PS2 sont situés au même endroit avec la même latence.

L’hôte est co-localisé avec les deux systèmes

Avec différentes options de connectivité métropolitaine pour les hôtes dans une configuration uniforme, les chemins sont présentés aux hôtes avec les états ALUA suivants. PowerStore utilise ALUA implicite pour fournir des informations sur les chemins optimisés pour les hôtes connectés. Pour l’équilibrage de charge, PowerStore sélectionne un nœud de l’appliance comme nœud optimisé pour un volume avec une affinité de nœud. Les informations d’affinité de nœuds assignées pour chaque volume sont disponibles dans la vue d’ensemble du volume après avoir ajouté la colonne Node Affinity. L’interface CLI de PowerStore et l’API REST de PowerStore vous permettent de modifier manuellement le paramètre d’affinité de nœuds.


Note: Il est recommandé d’utiliser des numéros de LUN cohérents pour les mappages de volumes standard ainsi que pour les mappages de volumes Metro sur les hôtes vSphere.


La configuration du tableau suivant suppose que le volume a sélectionné le nœud A pour l’affinité de nœud de volume.

  • ALUA path states for uniform metro connectivity

Metro connectivity

PowerStore cluster site-A

PowerStore cluster site-B

Host site-A

Host site-B

Node A

Node B

Node A

Node B

Co-located with both systems

Co-located with both systems

Active-optimized

Active-non-optimized

Active-optimized

Active-non-optimized

Co-located with local system

Co-located with remote system

 

Active-optimized

 

Active-non-optimized

Active-non-optimized

Active-non-optimized

During failure scenario, or standard volumes1

Unavailable

Unavailable

Active-optimized

Active-non-optimized

Co-located with local system

Co-located with remote system

During node failure PowerStore site-A or node A

Unavailable

Active-non-optimized2

Active-non-optimized

Active-non-optimized

Co-located with local system

Co-located with remote system

  1. Lorsque les volumes Metro Volumes et les volumes standard sont partagés sur le même système avec le paramètre hôte Co-Located avec le système distant, les chemins ALUA de l’hôte vers les volumes standard fonctionnent comme une connectivité locale.
  2. Pour atténuer les problèmes de latence, nous avons recommandé d’activer le round robin basé sur la latence du NMP, ce qui est abordé dans la section suivante.

 

ESXi path selection policies (PSP)

vSphere est livré avec trois politiques de sélection de chemin MPIO (PSP) : Most Recently Used (MRU), Round Robin (RR) et Fixed. MRU est la politique par défaut pour la plupart des périphériques de stockage actifs-passifs et n’est pas utilisée avec PowerStore.

Lorsque la fonction de connectivité hôte est configurée correctement, la meilleure politique de sélection de chemin à choisir avec Metro Volume est Round Robin. Round Robin est le PSP le plus facile à configurer et fournit à la fois des performances d’E/S optimales et un équilibre du tissu de stockage dans une présentation de stockage uniforme ou non. Il offre également une capacité de basculement automatique vers des chemins non optimaux et une capacité de retour automatique vers des chemins optimaux récupérés.

Pour l’hôte ESXi, l’état du chemin de travail est disponible dans Configure > Storage Device.

La figure suivante montre comment vCenter affiche les chemins pour une configuration d’hôte uniforme avec les paramètres de Co-Localisé avec le Local (cible se terminant par …fnm102135) et Co-localisé avec le distant (cible se terminant par …fnm102139). Le nombre total de chemins affichés dans l’interface utilisateur de vSphere est déterminé en multipliant le nombre d’initiateurs d’hôtes par le nombre de groupes de ports cibles sur PowerStore.

vCenter > Storage Devices > Paths view

VMware NMP choisit le chemin de travail et indique l’état dans vCenter. Le chemin de travail sélectionné par le NMP n’est pas toujours le chemin Active-Optimized. Les états de chemin possibles dans vCenter sont décrits dans le tableau ci-dessous.

  • Path states in vCenter

State in vCenter

Description

Active (I/O)

Indicates the working path for a volume. It might be the
Active-Optimized path, or another active path selected by NMP

Active

Indicates an active path for a volume.

Dead

Path is not available for host I/O to the volume.

 

 

 

L’esxcli fournit plus de détails sur les chemins utilisés pour un périphérique. Pour un périphérique particulier mappé à un hôte ESXi, vous pouvez utiliser la commande suivante pour afficher les détails du chemin. L’identifiant du périphérique (naa.68ccf…) est disponible soit dans l’aperçu du volume de PowerStore Manager, dans vSphere, ou en utilisant esxcli. La figure suivante montre deux commandes permettant d’accéder à ces informations. Alors que la liste des périphériques donne un aperçu complet des chemins d’accès au périphérique, la liste des chemins d’accès optionnels montre les détails de tous les chemins d’accès à un volume et inclut le nom d’exécution tel qu’il est utilisé dans vCenter UI.

esxcli mapping TPG_id to Runtime Name

Note: TPG state identifie l’état ALUA actif-optimal et actif-non-optimal pour chaque groupe de ports cibles. PowerStore a un groupe de ports cibles par nœud. Working Paths identifie chaque chemin actif-optimal utilisé tel que dérivé des groupes de ports cibles. Working Paths correspond à Active (I/O) dans l’interface utilisateur de vSphere Client.

 

Le tableau suivant montre les différents états TPG_states possibles qui représentent également les informations de chemin ALUA fournies par PowerStore..

  • Esxcli path states

TPG_state
in esxcli

ALUA path state

Description

AO

Active-optimized

Indique le chemin optimisé pour les
E/S de l’hôte vers le volume et peut être contrôlé avec le paramètre Volume Node-Affinity dans PowerStore CLI ou REST API.

ANO

Active-non-optimized

Le chemin est disponible, mais n’est pas optimisé pour les E/S de l’hôte vers le volume.

UNAVAIL

Unavailable

Le chemin n’est pas disponible pour les E/S de l’hôte vers le volume.

 

S’il y a une défaillance d’un seul nœud, PowerStore ne commute pas le chemin actif-optimisé vers le nœud restant. Avec le NMP par défaut basé sur iops, le NMP round-robin sélectionne tous les chemins actifs-non-optimisés restants comme chemin de travail (voir ci-dessous).

vCenter path states during a node failure

 

Ce scénario peut avoir un impact sur les performances car il est probable que NMP choisisse le cluster PowerStore distant avec une latence plus élevée pour les entrées/sorties. Pour atténuer ce problème, vous pouvez modifier la configuration du dispositif pour que NMP fasse du round-robin avec le mécanisme de latence. Les commandes dans la figure ci-dessous montrent un exemple des commandes pour vérifier (deviceconfig get) et changer (deviceconfig set) le mécanisme NMP round-robin à round-robin basé sur la latence.


Note: The below command is applied per-host and per-device.


 

Changer le round-robin NMP en mécanisme de latence

Vous pouvez utiliser une règle de réclamation pour mettre en œuvre la politique de latence pour les périphériques PowerStore. Vous devez ajouter cette règle de réclamation à chaque hôte ESXi. Après avoir appliqué la règle de réclamation, chaque périphérique nouvellement découvert se voit appliquer les règles de réclamation (les périphériques déjà découverts avant l’application de la règle de réclamation ne le seront pas).

Note: The following commands are for vSphere 7 ESXi hosts. ESXi 6.7 hosts should also include the disable_action_OnRetryErrors option. See the PowerStore Host Configuration Guide for more information.

esxcli storage nmp satp rule add -c tpgs_on -e "PowerStore" -M PowerStore -P VMW_PSP_RR -O "policy=latency" -s VMW_SATP_ALUA -t vendor -V DellEMC

Vous pouvez également ajouter la règle de réclamation aux hôtes ESXi en utilisant la PowerCLI.

# Add or remove a claim rule on each vSphere host

$esxlist | ForEach-Object {

$esxcli = Get-EsxCli -VMHost $_ -V2

 

# Fill the hash table (optional params are not required)

$sRule = @{

   satp = 'VMW_SATP_ALUA' #esxcli: -s

   psp = 'VMW_PSP_RR' #esxcli: -P

   pspoption = 'iops=1' #esxcli: -O

   claimoption = 'tpgs_on' #esxcli: -c

   #option = 'disable_action_OnRetryErrors' #esxcli: -o

   vendor = 'DellEMC' #esxcli: -V

   model = 'PowerStore' #esxcli: -M

   description = 'PowerStore' #esxcli: -e

}

 

# Call the esxcli command to add/remove the rule

Write-Host $selection "rule on" $_

$esxcli.storage.nmp.satp.rule.$selection.Invoke($sRule)

La politique MPIO fixe peut être souhaitable lorsqu’un chemin préféré sur la matrice de stockage doit être utilisé. Comme le montre la figure ci-dessous, vous devez définir la stratégie MPIO sur l’hôte vSphere sur Fixed (fixe) avec le chemin préféré menant à vmhba3:C0:T1:L3. L’utilisation de la stratégie MPIO fixe nécessite généralement plus d’efforts administratifs pour mettre en œuvre, maintenir et documenter les éléments suivants.

Politique de sélection du chemin fixe

Si la connectivité de l’hôte est modifiée à une nouvelle valeur, provoquant l’envoi d’E/S sur un chemin actif/non-optimal, PowerStore est conçu pour signaler les changements d’état du chemin ALUA à l’hôte vSphere en utilisant le processus suivant :

  1. La connectivité de l’hôte est modifiée à une nouvelle valeur entraînant l’envoi d’E/S sur un chemin actif/non optimal.
  2. Les hôtes vSphere envoient des E/S de type Round Robin vers un chemin actif/non-optimal.
  3. PowerStore fait échouer l’E/S avec une condition de contrôle d’attention de l’unité.
  4. L’hôte vSphere demande des groupes de ports cibles de rapport. 5.
  5. PowerStore répond avec de nouveaux changements d’état ALUA. 6.
  6. vSphere commence les E/S Round Robin sur les nouveaux chemins optimaux.

Note: You can view the Unit Attention Check Condition in /var/log/vmkernel.log in the following example. For more information, see the VMware KB article, Interpreting SCSI sense codes in VMware ESXi and ESX (289902).


2022-04-28T01:53:52.332Z cpu11:2097789)NMP: nmp_ThrottleLogForDevice:3867: Cmd 0x89 (0x45b8c3883988, 2097177) to dev "naa.68ccf0980080631b71144f5e582abe31" on path "vmhba3:C0:T0:L2" Failed:

2022-04-28T01:53:52.332Z cpu11:2097789)NMP: nmp_ThrottleLogForDevice:3875: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x6. Act:FAILOVER. cmdId.initiator=0x430541297ec0 CmdSN 0x1b191

Lors de tests précédents, nous avons découvert que vSphere ne commençait pas à utiliser les nouveaux chemins optimaux de manière cohérente ou fiable immédiatement après un changement d’état ALUA. Au lieu de cela, jusqu’à cinq minutes s’écoulaient avant que vSphere ne reconnaisse le changement d’état du chemin ALUA. Cela signifie que vSphere peut continuer à appliquer la stratégie Round Robin sur des chemins non optimaux pendant cinq minutes.

Si vous observez cette situation et que vous craignez que ce comportement ne se produise dans vos environnements, il existe deux solutions de contournement :

  • Après un changement d’état ALUA connu, effectuez un rescan du stockage vSphere.
  • Réduisez le paramètre avancé Disk.PathEvalTime de l’hôte vSphere de la valeur par défaut de 300 secondes à un intervalle acceptable de rescan automatique du stockage. Si vous choisissez cette approche, vous devez effectuer cette action sur chaque hôte vSphere où la connectivité de l’hôte a été modifiée.
Exemple : Réduction du paramètre Disk.PathEvalTime à 30 secondes sur un hôte vSphere

États de réplication

Cette section décrit les différents états principaux d’un Metro Volume. Certains des états suivants affichent plus d’informations entre parenthèses dans l’IU.  

Operating Normally

Dans cet état, PowerStore Metro Volume est entièrement synchronisé et actif-actif. Les deux côtés du Metro Volume servent les E/S de l’hôte, et un hôte ne reçoit un accusé de réception de la matrice que lorsque les E/S sont engagées des deux côtés du Metro Volume. Les sous-états possibles sont Actif-Actif, et Synchronisation asynchrone lorsque la reprotection commence à partir d’un volume promu.

Switching to Metro Sync

PowerStore orchestre les opérations de copie et de miroir. Cet état n’autorise que les E/S de l’hôte vers le côté préféré ou promu d’un volume Metro. Les états secondaires possibles sont Synchronisation asynchrone, et Committing to Active-Active.

Fractured

Les systèmes PowerStore homologues n’ont pas pu synchroniser les E/S. Cet état peut être causé par une défaillance de la matrice ou de la liaison nécessaire à la réplication. Cet état n’autorise que les E/S de l’hôte vers le côté préféré ou promu d’un volume Metro.

Paused

Dans cet état, le volume Metro est mis en pause. Cet état est déclenché par l’opération Pause dans PowerStore Manager. Cet état ne permet que les E/S de l’hôte vers le côté préféré ou promu d’un Metro Volume.

Resuming

Il s’agit d’un état transitoire après avoir repris un Metro Volume en pause et déclenché l’état Switching to Active-Active. Cet état ne permet que les E/S de l’hôte vers le côté préféré ou promu d’un Metro Volume.

Reprotecting

Cet état indique que PowerStore a initié la récupération auto-réparatrice de Metro Volume pour que la réplication Metro Sync revienne à l’état actif-actif. Cet état ne permet que les E/S de l’hôte vers le côté préféré ou promu d’un Metro Volume.

Modify role in progress

La réplication est dans cet état lorsqu’elle échange les rôles des volumes préférés et non préférés de la session de synchronisation du métro.

Deleting

Cet état se produit après la déconfiguration d’un Metro Volume après un état End Metro Volume dans PowerStore Manager.

Mesures de réplication

Pour chaque session de réplication Metro Volume, PowerStore Manager fournit des mesures de performance. Un graphique montre la bande passante du trafic de réplication pour le volume sélectionné (en haut de la figure suivante). Un second graphique montre les données restantes à synchroniser lors de l’exécution de la synchronisation initiale ou de l’auto-réparation (en bas de la figure suivante). Pendant l’état actif-actif, le graphique des données restantes montre seulement une ligne plate.

 

Metro session performance metrics

Opérations Metro Volume

Cette section décrit les opérations dans PowerStore Manager pour un Metro Volume. Vous pouvez exécuter une opération pour un Metro Volume dans différents écrans. En dehors des actions pour Configurer et Terminer Metro Volume, qui sont également disponibles dans l’écran de vue d’ensemble des volumes, les opérations sont disponibles dans la vue des détails du volume. Cette vue est disponible dans Volumes > [Nom du volume] > Détails du volume > Protection > Metro Volume. Les opérations sont également disponibles dans l’aperçu de la session Metro (Protection > Metro). Lorsqu’une opération ayant un impact sur les E/S de l’hôte est censée être exécutée, une boîte de dialogue apparaît et présente une description détaillée de l’état effectif de Metro Volume après l’exécution de l’opération.

Opérations Metro Volume

Vous pouvez commencer une nouvelle configuration de Metro Volume dans Volumes Overview ou dans la vue détaillée du volume dans le sous-onglet pour Protection > Metro Volume. L’assistant nécessite uniquement que le système distant définisse le cluster PowerStore homologue. (Voir plus de détails sur le système distant et le protocole de réplication dans le document PowerStore: Replication Technologies.) Lorsque le pair est un cluster multi-appliance, il y a un champ supplémentaire pour spécifier l’appliance. Sans sélectionner d’appliance, PowerStore équilibre les Metro Volumes entre les appliances disponibles. Quand aucune migration ou réplication n’est configurée pour le volume, la configuration de Metro Volume est possible dans n’importe quel état d’un volume standard. Une session de réplication Metro est créée juste après et initie la synchronisation initiale pour le volume.

Définir le rôle local comme préféré ou modifier le rôle préféré

Ces opérations permettent de changer le rôle préféré d’un Metro Volume et peuvent être effectuées une fois qu’un Metro Volume a atteint l’état Operating normally (Active-Active). Le changement de rôle pourrait être nécessaire pour définir le même rôle pour les volumes relatifs à la même application sur un seul cluster PowerStore. S’il y a un scénario de panne, tous les volumes de la même application pourraient être affectés par la polarisation. Un autre cas d’utilisation serait de changer le rôle avant une maintenance planifiée dans l’un des sites Metro Volume ou de mettre en pause une application Metro Volume.

Pause

Pour modifier certaines propriétés de Metro Volume, vous devez mettre en pause un Metro Volume. La mise en pause d’un Metro Volume peut également être utilisée lors d’une maintenance planifiée. Sachez que la mise en pause d’un Metro Volume désactive les E/S de l’hôte sur le côté non préféré d’un Metro Volume. Pour une configuration d’hôte non uniforme, nous avons recommandé de s’assurer que les hôtes avec des VM en cours d’exécution utilisent le volume préféré pour éviter un redémarrage non désiré des VM.

La synchronisation des données Metro Volume entre PowerStore-A et PowerStore-B sera mise en pause. Sur le système préféré, l’accès à la production continuera pour les applications. La politique de protection restera active. Sur le système non préféré, l’accès à la production restera désactivé pour les hôtes et les applications. La politique de protection restera en pause.

Resume

Cette opération permet de reprendre un Metro Volume en pause et de le faire passer dans un état actif-actif. Les écritures et les instantanés de l’hôte créés sur le volume préféré pendant que le volume métropolitain était en pause, seront synchronisés avec le système homologue.

Promote

Une action de promotion permet l’accès à l’hôte et à la production sur un volume Metro non préféré et n’est disponible que dans les états Paused et Fractured. Une action de promotion peut entraîner une corruption des données si le système distant est en ligne et sert des entrées/sorties. Si seule la connexion entre le système PowerStore actuel et le système PowerStore distant est interrompue, vérifiez que le système distant n’est plus en ligne.

Après l’action de promotion, l’accès à la production sera activé pour les hôtes et les applications sur le système actuel. La politique de protection est activée et la création de snapshots reprend.

Demote

Une action de rétrogradation désactive l’accès à l’hôte et à la production sur un Metro Volume préféré en état de pause. Pour éviter la corruption des données, l’action de rétrogradation est limitée lorsqu’il y a une connectivité réseau entre les deux systèmes PowerStore et que le Metro Volume distant a également un accès de production. Une fois l’opération de rétrogradation terminée, le volume métropolitain non préféré peut être promu.

Après l’action de rétrogradation, l’accès à la production sera désactivé pour les hôtes et les applications. La politique de protection sera désactivée, et la création programmée de snapshots sera arrêtée.

End metro

Cette opération met fin à une session de réplication de Metro Volume pour le volume. L’assistant pour mettre fin à cette session propose deux options :

  • Terminer Metro et conserver le volume sur les deux systèmes.
    • Sur current, les propriétés du volume et l’accès à l’hôte resteront inchangés.
    • Sur remote, cette option démappe le Metro Volume, supprime la session de réplication Metro et attribue un WWN SCSI différent au volume.
  • Terminez Metro et supprimez le volume et tous les snapshots associés sur le système distant.
    • Sur le current, les propriétés du volume et l’accès à l’hôte restent inchangés.
    • Sur remote, cette option démappe le volume Metro, déconfigure la session de réplication Metro et supprime le volume.

 

 

Operation overview

  • Metro sync session operations overview
 

Status

Reconfig allowed

Modify role

Promote

Demote

Pause

Resume

End Metro

On preferred

Operating Normally

 

Yes

   

Yes

 

Yes

Paused

Yes

   

Yes

 

Yes

Yes

Fractured

Yes

   

Yes

Yes

 

Yes

Synchronizing

       

Yes

 

Yes

On non-preferred

Operating Normally

 

Yes

   

Yes

 

Yes

Paused

Yes

 

Yes

   

Yes

Yes

Fractured

Yes

 

Yes

 

Yes

 

Yes

Synchronizing

       

Yes

 

Yes

 

Créer et gérer un Metro Volume

Cette section montre comment créer une configuration Metro Volume dans PowerStore Manager. Pour créer et gérer un Metro Volume dans l’API REST de PowerStore ou dans la CLI de PowerStore, consultez les guides de l’API et de la CLI à l’adresse suivante PowerStore Product Documentation & Videos.

Les exemples utilisent les éléments suivants :

– Deux clusters PowerStore PowerStore-A, et PowerStore-B avec une configuration de système distant pour la réplication.

– Une seule appliance vCenter vcsa.lab

– Hôtes ESXi esx-a, et esx-b connectés au PowerStore local uniquement pour les besoins suivants

accès hôte non uniforme, mappé à Metro Volume Sales

– Hôtes ESXi esx-c, et esx-d connectés au PowerStore local et distant pour un accès uniforme aux hôtes.

un accès hôte uniforme, mappé à Metro Volume Engineering.

– Les volumes Heartbeat sont mappés à partir de chaque PowerStore vers tous les serveurs ESXi pour satisfaire à vSphere HA.

– Un volume standard Technical Marketing Engineering est mappé sur les hôtes esx-c et esx-d et préparé pour la configuration de Metro Volume en tant que datastore VMFS dans vSphere vCenter.

Figure 16. Paramètres de connectivité de l’hôte

 

Figure 17. PowerStore-A > Aperçu de l’hôte Metro

La Figure 16 montre les options de connectivité d’hôte dans PowerStore Manager, et la Figure 17 représente la configuration d’hôte avec différents paramètres de connectivité d’hôte pour PowerStore-A. Pour une connectivité hôte uniforme, l’hôte esx-c est local à PowerStore-A. La connectivité hôte pour esx-c, et esx-d est permutée sur PowerStore-B.

  • Host connectivity setting
  • PowerStore-A > Metro host overview

Créer une réplication de Metro Volume

Dans l’interface utilisateur de PowerStore Manager, vous pouvez créer un Metro Volume dans la page Storage > Volumes overview après avoir sélectionné le volume approprié dans le menu déroulant Protect. Vous pouvez également le créer dans la vue détaillée du volume sous le sous-onglet Protection > Metro Volume avec un lien pour configurer le Metro Volume.

Configurer Metro Volume dans l’aperçu des volumes

L’assistant demande le système distant. Si aucun système distant n’est configuré, un lien mène à l’assistant de nouveaux systèmes distants.

Assistant de configuration de Metro Volume, système distant à une seule appliance

Lorsque le système distant est un cluster multi-appareils, un menu déroulant supplémentaire vous permet de sélectionner l’appareil. Avec l’option Auto, PowerStore Manager sélectionne la meilleure appliance applicable sur le cluster PowerStore distant pour le volume.

Figure 20. Assistant de configuration de Metro Volume, système distant multi-appareils

Une fois qu’un volume Metro est configuré, l’icône dans l’aperçu du volume change pour indiquer qu’il s’agit d’un volume Metro. De même, le volume Metro apparaît dans l’écran de synthèse Metro Protection > Metro. Selon l’état actuel, les opérations pour le volume sélectionné sont activées.

Figure 22. Volume de métro en statut actif-actif

Pour afficher plus de détails sur la session de réplication de Metro Volume, cliquez sur l’état de Metro pour un Metro Volume individuel (voir ci-dessous).

 

Pause and Resume

Une opération de pause de Metro Volume met en pause le trafic de réplication vers le pair, et cette opération est possible dans presque toutes les situations. Une boîte de dialogue détaille l’état après que le Metro Volume soit en état de pause. Lorsque le Metro Volume est en état de pause, le volume non préféré apparaît hors ligne pour les hôtes mappés et aucun trafic de réplication n’est autorisé..

Figure 23. Pause Metro Volume

 

 

Lorsque le Metro Volume est en état de pause, les détails de la session Metro Volume montrent l’état et permettent les opérations de rétrogradation et de reprise.

Figure 24. Metro Volume in Paused state

Après avoir effectué l’opération Resume, le Metro Volume démarre la synchronisation du Metro Volume et permet l’accès de l’hôte après avoir basculé en mode actif-actif.

Modifier le rôle

Figure 25. Metro Volume detail view

 

Après une nouvelle configuration de Metro Volume, le côté préféré du volume est le même que celui du volume d’origine. Dans cet exemple, le côté préféré est PowerStore-A. La page de détails du Metro Volume met en évidence le système actuel où la session du navigateur est connectée et indique le côté préféré du Metro Volume. L’opération Modifier le rôle préféré n’est possible que dans l’état actif-actif.

Figure 25. Vue détaillée de Metro Volume

Après avoir sélectionné Modifier le rôle préféré, une boîte de dialogue affiche la nouvelle configuration cible une fois la modification terminée. La modification du rôle préféré n’a aucune influence sur le paramètre ALUA du chemin d’accès à l’hôte.

Figure 26. Modifier le paramètre du rôle préféré

 

Metro Volume in vSphere vCenter

Lorsque la session de synchronisation de Metro Volume est mise en place, le volume est disponible sur le PowerStore homologue pour être mappé sur les hôtes. Après le mappage et le rescanning du stockage dans vCenter, les chemins apparaissent dans les hôtes sous la vue Storage Devices. Le chemin affiché dépend de la configuration de connectivité des hôtes choisie. La figure suivante montre un Metro Volume dans une connectivité uniforme après la synchronisation initiale lorsque le volume a atteint l’état actif-actif. Dans cet exemple, PowerStore-A est configuré comme colocalisé à l’hôte ESXi, et PowerStore-B est la matrice distante. Actif (I/O) indique le chemin de travail actif.

Figure 27. Uniform Metro Volume in vCenter

Si vous mettez en pause la session de synchronisation Metro ou si un scénario d’échec affecte la réplication, le chemin d’accès au côté non préféré du Metro Volume affichera le statut de mort. Après une opération précédente de modification du rôle préféré, le Metro Volume serait hors ligne sur PowerStore-A et montrerait les chemins morts tandis que le chemin optimisé actif passerait sur PowerStore-B/Node-B avec une affinité de nœud de volume. Le statut Actif (I/O) dans vCenter montre le chemin de travail modifié qui est le nouveau chemin actif optimisé ALUA présenté par PowerStore-B.

Figure 28. Uniform Metro Volume dans vCenter après une pause ou pendant un scénario de panne

Dans tous les cas, une fois que Metro Volume reprend à partir d’un état de pause ou qu’un scénario de panne est résolu, PowerStore lance le processus d’auto-réparation de Metro Volume. Une fois que le Metro Volume est repassé en mode actif-actif, les hôtes ESXi peuvent rétablir les chemins.

Promote or demote after a failure situation

Dans une configuration d’hôte non uniforme lors de l’utilisation du volume non préféré, les hôtes affectés perdent tous les chemins actifs vers le Metro Volume. Dans ce cas, vSphere HA ou vSphere FT doit basculer la production vers un hôte disposant de chemins d’accès au côté préféré du Metro Volume. Les informations de chemin d’accès d’un volume connecté uniforme sont identiques pour tous les hôtes ESXi. Dans l’exemple, l’hôte esx-a a un Metro Volume non uniforme configuré et ne montre que le chemin vers le cluster PowerStore local PowerStore-A.

Figure 29. Volume Metro non uniforme dans vCenter

 

Par exemple, lors d’une panne de courant sur le site avec le volume préféré, les hôtes avec une connectivité au volume non préféré perdront tous les chemins vers le volume. Pour permettre la production sur la baie survivante, il est possible de promouvoir le volume non préféré pour permettre l’accès des hôtes afin de reprendre les opérations. La figure suivante montre le volume non préféré sur PowerStore-B après une panne.

Figure 30. État fracturé sur le site non préféré

Avec l’opération de promotion, il est possible d’activer manuellement les E/S de l’hôte de production pour ce volume, même s’il n’est pas préféré. Afin d’éviter une éventuelle situation de « split-brain » lorsque les deux côtés sont en ligne pour les hôtes, une action de promotion n’est possible que lorsque la baie homologue est hors ligne, ou que le volume est rétrogradé du côté préféré. Une boîte de dialogue montre la situation après l’exécution de la promotion (voir ci-dessous).).

Figure 31. Promouvoir le volume de Metro

Lorsque l’opération de promotion se termine, les chemins d’accès au volume non privilégié sur les hôtes ESXi passent à actif pour les E/S de production. Une fois le problème à l’origine de la rupture résolu, PowerStore lance le processus d’auto-réparation et synchronise les E/S du côté promu vers le pair.

Une opération de rétrogradation permet de désactiver les E/S de l’hôte de production sur le volume préféré. Cette action peut être nécessaire lorsqu’une promotion est prévue, mais que le PowerStore avec le volume préféré est toujours disponible. Après avoir cliqué sur l’opération de rétrogradation, la boîte de dialogue montre le volume Metro une fois l’opération terminée (voir ci-dessous).

Figure 32. Demote Metro Volume

Scénarios de défaillance

Cette section couvre les scénarios de défaillance possibles avec une connectivité hôte non uniforme et uniforme. En raison du mécanisme de polarisation, un Metro Volume n’est actif-actif sur les deux clusters PowerStore que lorsque les clusters PowerStore sont opérationnels, et que les liens pour le trafic de gestion de la réplication et le trafic de données de réplication sont établis. En cas de défaillance d’un lien nécessaire à la réplication, le côté non préféré perd la communication avec le côté préféré du Metro Volume et passe en mode hors ligne pour les hôtes, tandis que les volumes préférés peuvent toujours être servis par le même cluster PowerStore. Lors d’une défaillance de la matrice, seuls les volumes préférés restent accessibles sans une promotion manuelle des volumes non préférés sur la matrice survivante. Les sous-sections suivantes montrent le scénario d’échec dans une configuration d’hôte non-uniforme et uniforme.

Failure scenario in a non-uniform configuration

Dans ce scénario, les VMs sur l’hôte 2 accèdent à deux Metro Volumes différents sur PowerStore-B. La VM1 est sur le Metro Volume 1 avec le rôle non privilégié, et la VM 2 est sur le Metro Volume 2 avec le rôle privilégié (voir ci-dessous).

Figure 33. Actif-actif non uniforme

Dans la figure suivante, en raison d’une défaillance de liaison, l’hôte 2 perd l’accès au Metro Volume 1 avec un événement APD (all path down), et la VM 1 est interrompue. VM 2 continue de fonctionner sur le volume préféré Metro Volume 2 mappé à l’hôte 2. L’hôte 1 a accès au volume préféré Metro Volume 1, vSphere HA reconnaît que le volume est toujours disponible, et il redémarre VM 1 sur l’hôte 1. Une autre option pour protéger VM 1 est VMware Fault Tolerance (FT) où VM 1 pourrait fonctionner sans interruption sur l’hôte 1 (PowerStore-A).

 

 

Figure 34. Non-uniforme pendant une défaillance de la liaison

Avec la même configuration, lorsque PowerStore-B est en panne pendant une situation de défaillance (panne de réseau), Metro Volume 2 n’est pas accessible jusqu’à ce qu’une opération de promotion manuelle soit effectuée sur PowerStore-A. Après l’action de promotion de Metro Volume 2 sur l’hôte 1, le volume et les chemins actifs sont activés, et VM 2 peut démarrer sur l’hôte 1.

 

Failure scenario in a uniform configuration

L’exemple de configuration uniforme est identique à l’exemple précédent avec des chemins supplémentaires entre les hôtes et le cluster PowerStore distant. Les chemins actifs redondants vers les clusters PowerStore locaux et distants donnent un niveau supplémentaire de haute disponibilité. Selon la configuration de l’hôte telle que décrite dans la section Configuration de l’hôte, les chemins vers le volume desservi par le PowerStore distant peuvent être ALUA actif-non optimisé uniquement, ou également actif-optimisé avec des chemins actifs-non optimisés dépendant du paramètre d’affinité du nœud de volume. Dans l’exemple ci-dessous, VM 1 et VM 2 fonctionnent sur l’hôte 2 en utilisant différents Metro Volumes. Alors que la VM 1 utilise le Metro Volume 1 dans le rôle non privilégié qui est mis hors ligne en cas de panne, la VM 2 utilise le Metro Volume 2 dans le rôle privilégié.

Figure 35. Uniform active-active

 

Dans un scénario de panne, lorsque le lien entre PowerStore-A et PowerStore-B est affecté, l’hôte 2 perdrait le volume de la VM 1. Comme des chemins actifs sont encore disponibles vers le même volume sur PowerStore-A, la VM 1 reste en ligne sans interruption. VMware Native Multipathing (NMP) gère le basculement vers un chemin actif disponible.

Figure 36. Uniform during a link failure

Lors d’une panne de réseau de PowerStore-B, VM 2 perdrait également le chemin actif vers Metro Volume 2, mais elle ne peut pas continuer sur PowerStore-A parce que Metro Volume 2 est dans le rôle non-préféré. VM 2 ne peut démarrer avec Metro Volume 2 sur PowerStore A qu’après qu’une action manuelle de promotion de Metro Volume ait été effectuée sur PowerStore-A.

 

Failure scenario table

Le tableau suivant présente les scénarios de défaillance de la conception et des composants testés avec Metro Volume activé avec vSphere HA.

  • Failure scenarios with uniform and non-uniform storage presentation

Event scenario

Metro Volume behavior

vSphere HA behavior

Uniform: Outage of non-preferred Metro Volume

Preferred Metro Volume remains available

None. VMs have uniform paths to surviving preferred Metro Volume.

Non-uniform: Outage of non-preferred Metro Volume

Preferred Metro Volume remains available

vSphere HA restarts impacted VMs on preferred Metro Volume.

Uniform: Outage of synchronous replication link

Preferred Metro Volume remains available

None. VMs have uniform paths to surviving preferred Metro Volume.

Non-uniform: Outage of synchronous replication link

Preferred Metro Volume remains available

vSphere HA restarts impacted VMs on preferred Metro Volume.

Uniform: Outage of preferred Metro Volume

Non-preferred Metro Volume becomes unavailable. Manually promote non-preferred Metro Volume.

vSphere HA attempts to restart impacted VMs if a Metro Volume becomes available in time.

Non-uniform: Outage of preferred Metro Volume

Non-preferred Metro Volume becomes unavailable. Manually promote non-preferred Metro Volume.

vSphere HA attempts to restart impacted VMs if a Metro Volume becomes available in time.

 

 

vSphere DRS, HA, and Metro Volume

VMware Distributed Resource Scheduler (DRS) est une configuration centrée sur le cluster qui utilise VMware vSphere vMotion pour déplacer automatiquement les ressources de calcul des machines virtuelles vers d’autres hôtes d’un cluster vSphere. Cette action est effectuée sans tenir compte des sites locaux, métropolitains ou étendus. De même, vSphere n’est pas conscient de la virtualisation du stockage qui se produit dans Metro Volume. Lorsque Metro Volume est configuré avec vSphere, envisagez de placer les machines virtuelles de niveau 1 ou critiques pour l’entreprise sur le Metro Volume préféré en cas d’interruption imprévue du lien de réplication synchrone.

Si DRS est activé sur un cluster vSphere, DRS peut déplacer automatiquement les machines virtuelles. Cette situation pourrait être un problème dans une conception de présentation de stockage non uniforme. Les groupes d’hôtes DRS et les groupes de machines virtuelles peuvent être utilisés pour appliquer des règles permettant de délimiter la mobilité des machines virtuelles.

  • Groupes VM : Les machines virtuelles peuvent être placées dans des groupes VM. Les groupes de machines virtuelles peuvent être assignés à des hôtes dans un groupe d’hôtes où les machines virtuelles doivent s’exécuter.
  • Groupes d’hôtes : les hôtes qui partagent un volume Metro préféré ou non préféré commun peuvent être placés dans des groupes d’hôtes. Une fois les groupes d’hôtes configurés, ils peuvent représenter la localité pour le Metro Volume préféré ou non préféré.

Vous pouvez affecter des groupes de machines virtuelles à des groupes d’hôtes à l’aide du client vSphere. Cette pratique garantit que les machines virtuelles suivent des règles de placement prévisibles sur les hôtes vSphere soutenus par les Metro Volumes. Vous pouvez également concevoir l’infrastructure avec des clusters DRS distincts existant sur les deux sites, en conservant la migration automatique des machines virtuelles sur le site respectif où réside le Metro Volume préféré ou non préféré.

vSphere Availability (HA) est également une configuration centrée sur le cluster. En cas de défaillance d’un hôte ou d’une unité de stockage, HA tente de redémarrer les machines virtuelles sur un candidat hôte du même cluster qui a encore accès au Metro Volume. Dans une présentation de stockage non uniforme, si une panne a un impact sur la disponibilité des Metro Volume non préférés, vous pouvez configurer vSphere HA pour redémarrer les machines virtuelles impactées sur le Metro Volume préféré.

 

Figure 37. Défaillance du rôle non préférentiel dans une présentation de stockage non uniforme

Le réglage avancé vSphere suivant doit être configuré pour les configurations de clusters étirés non uniformes. Ce réglage permet à HA de mettre hors tension et de migrer les machines virtuelles vers le Metro Volume préféré si le Metro Volume non préféré devient indisponible.

Configurez les éléments suivants :

  • vSphere 6.0+ : Disk.AutoremoveOnPDL = 1 (paramètre avancé par défaut recommandé par VMware sur chaque hôte)
  • Outre la prise en charge du redémarrage HA pour les événements PDL (Permanent Device Loss), le redémarrage HA peut également réagir aux événements APD (All-Paths-Down). Nous recommandons de configurer la protection des composants VM pour les événements PDL et APD. Pour les événements PDL, sélectionnez Power off and restart VMs. Pour les événements APD, VMware recommande de sélectionner Power off and restart VMs (conservative). Pour les paramètres APD avancés, consultez le document VMware vSphere Metro Storage Cluster Recommended Practices.
Figure 38. Configuring vSphere HA for PDL and APD conditions

Le paramètre avancé Disk.AutoremoveOnPDL n’est pas configurable dans VMCP et doit rester à sa valeur par défaut de 1 pour chaque hôte vSphere 6 du cluster. Pour plus d’informations sur la fonctionnalité Disk.AutoremoveOnPDL, consultez l’article 2059622 de la KB de VMware, PDL AutoRemove feature vSphere 6.x/7.x.

Si une panne non planifiée a un impact sur la disponibilité du Metro Volume préféré, ce dernier devient indisponible. Les machines virtuelles fonctionnant sur ce Metro Volume n’auront plus accès au stockage.

VMware vSphere surveille les codes de détection SCSI envoyés par une baie pour déterminer si un périphérique est dans un état PDL. Ces codes de détection SCSI sont décrits dans l’article 2004684 de la KB de VMware., Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 6.x and 7.x. PowerStore supporte les codes de sens SCSI suivants (voir le tableau ci-dessous) qui seront envoyés aux hôtes vSphere lorsqu’une condition PDL est remplie.

  • SCSI sense codes

SCSI sense code

Description

0x02/0x04/0x0c

ALUA UNAVAILABLE

 

 

vSphere vMotion and Metro Volume

Pour les clusters ou centres de données étendus, tenez compte des exigences en matière de latence vMotion et Metro vMotion entre les hôtes. vMotion exige une latence aller-retour de 5 ms ou moins entre les hôtes sur le réseau vMotion. vSphere Metro Storage Cluster augmente la latence aller-retour autorisée de 5 ms à 10 ms sur le réseau vMotion entre les sites avec une licence Enterprise Plus.

Lorsque la connectivité des hôtes est correctement configurée et que la politique de sélection des chemins d’accès est appropriée, la migration des machines virtuelles entre les clusters PowerStore dans une configuration Metro Volume devrait fonctionner comme prévu. Cependant, il y a quelques points à garder à l’esprit :

  • Un réseau de couche 2 étiré est nécessaire entre les sites dans une architecture de cluster étiré. Les machines virtuelles qui sont migrées d’un site à l’autre doivent se trouver sur le même réseau de couche 2 une fois la migration vMotion terminée.
  • Pour une plus grande disponibilité, les machines virtuelles doivent être exécutées sur un hôte vSphere qui est local au Metro Volume préféré. Cette pratique s’explique par le fait que les pannes de Metro Volume sont traitées par polarisation. En cas de panne du lien de réplication synchrone, le volume préféré reste disponible pour les hôtes tandis que le volume non préféré devient indisponible pour les hôtes.

 

Supported configurations

Les exigences de connectivité de Metro Volume peuvent varier en fonction de l’utilisation prévue et réelle. Par exemple, les exigences liées à l’utilisation de Metro Volume pour migrer une charge de travail de machines virtuelles éteintes seront sensiblement différentes de celles liées à la migration de machines virtuelles allumées et très actives. VMware Fault Tolerance (FT) est également un gros consommateur de bande passante et doit être pris en compte.

Un volume PowerStore Metro natif peut être configuré sur tous les modèles PowerStore T exécutant PowerStoreOS 3.0 ou plus dans une configuration vSphere Metro Storage Cluster (vMSC). Un vMSC peut fournir une architecture de cluster étiré vSphere. Pour la configuration de l’hôte, PowerStore prend en charge l’accès hôte non uniforme qui utilise uniquement le chemin local, et l’accès hôte uniforme qui fournit une connectivité croisée supplémentaire au cluster PowerStore distant.

Nous recommandons d’utiliser des VLAN ou des tissus dédiés pour isoler le trafic de stockage basé sur IP des autres types de trafic LAN général, en particulier lorsqu’il s’agit de centres de données étendus. Bien que cette recommandation ne soit pas une exigence pour Metro Volume, il s’agit d’une meilleure pratique générale pour le stockage basé sur IP.

Outre les exigences existantes pour la réplication PowerStore, les restrictions suivantes s’appliquent à Metro Volume :

  • Cluster PowerStore modèle T uniquement
  • VMware ESXi dans une configuration vSphere Metro Storage Cluster
  • Jusqu’à 64 datastores VMFS Metro Volume sur volume de bloc par cluster
  • Volumes VMFS FC/SCSI ou iSCSI
  • Réplication PowerStore basée sur TCP Lien Ethernet avec une bande passante d’au moins 622 Mbps
  • Distance maximale entre les sites : 100 km (60 miles)

Exigences en matière de latence

  • 5 millisecondes maximum pour vSphere High Availability (vSphere HA)
  • 1 milliseconde maximum pour la tolérance aux pannes de vSphere (vSphere FT)

Note: Le protocole de réplication PowerStore basé sur TCP utilise des ports TCP dans la gamme 13333-13337 selon la configuration de latence du réseau du système distant. Assurez-vous que les règles de pare-feu entre les clusters PowerStore avec Metro Volumes permettent à ces ports de laisser passer le trafic.

Note: Les réservations persistantes SCSI-3 et les Raw Device Mappings (RDM) de vSphere ne sont pas prises en charge.

 

System limits

Pour connaître les limites les plus récentes du système, consultez la Matrice de support simple sur Dell.com/powerstoredocs.

Metro Volume use cases

 

Introduction

Cette section fournit d’autres exemples de la façon dont vous pouvez utiliser Metro Volume dans divers environnements.

 

Zero-downtime SAN maintenance and data migration

Avec Metro Volume, vous pouvez effectuer des activités de maintenance sans entraîner de temps d’arrêt sur un cluster PowerStore. Ces tâches comprennent la mise hors ligne d’un cluster pour déplacer son emplacement, effectuer des mises à jour de firmware de boîtier ou de disque affectant le service, et migrer les volumes vers un nouveau cluster.

Les conditions requises pour cette opération sont les suivantes

– MPIO installé et configuré de manière appropriée sur les ordinateurs hôtes.

– Hôte ou hôtes correctement zonés aux deux clusters PowerStore

– Connectivité des hôtes configurée sur les deux clusters

– Lien de réplication synchrone entre les clusters

Résumé : Avant une panne planifiée, Metro Volume peut migrer sans interruption des volumes d’un cluster PowerStore à un autre, permettant ainsi un fonctionnement continu pour toutes les charges de travail, même après la mise hors tension complète d’un cluster.

 

 

Fonctionnement : Dans un processus à la demande, piloté par l’opérateur, Metro Volume peut déplacer de manière transparente des volumes d’un cluster PowerStore à un autre. Les charges de travail fonctionnent en continu. Cette capacité permet plusieurs options pour améliorer le fonctionnement du système :

  • Redéfinir Metro Volumes sur le site distant comme rôle privilégié.
  • Arrêter le site local
  • Inverser le processus après la fin de l’arrêt planifié
Figure 39. Maintien de la disponibilité des applications et des services pendant la maintenance planifiée

 

Figure 40. Les applications restent disponibles en permanence sur PS2 pendant que PS1 subit une maintenance.

.

 

Migration du stockage pour la migration des machines virtuelles

Lorsque les machines virtuelles VMware sont migrées d’un centre de données à un autre, vous pouvez utiliser Metro Volume pour migrer les fichiers de disque des machines virtuelles en vrac de manière transparente.

Cette action implique les éléments suivants :

  1. Activez Metro Volume sur le cluster source.
  2. Migrez les machines virtuelles à l’aide de vMotion.
  3. Terminer Metro Volume.
Figure 41. Le stockage suit l’application (virtualisation du serveur)

Les conditions requises pour cette opération sont les suivantes :

  • Hôte ou hôtes correctement zonés sur les deux clusters PowerStore.
  • Connectivité de l’hôte configurée correctement sur les deux baies
  • Réseau étendu de niveau 2 entre les sites source et de destination.
  • 5 ms ou moins de latence sur le lien de réplication synchrone entre les sites.

 

Éviter les catastrophes

En prévision d’une panne (par exemple, l’approche d’un ouragan dans une région côtière), vous pouvez utiliser Metro Volume pour migrer les charges de travail et les données vers des systèmes de récupération. Metro Volume utilisé de cette manière peut empêcher la perte de données et l’arrêt des applications.

Fonctionnement : Metro Volume peut déplacer de manière transparente des volumes d’un cluster PowerStore à un autre. Les applications fonctionnent en continu. Cela permet plusieurs options pour améliorer le fonctionnement du système :

  1. Activer Metro Volume sur le cluster source.
  2. Migrer les machines virtuelles à l’aide de vMotion.
  3. Terminez Metro Volume.
  4. Redémarrez ou récupérez les applications sur le site distant si nécessaire.
  5. Utilisez ce même processus pour déplacer les applications de manière transparente vers leurs emplacements d’origine en utilisant Metro Volume.
Figure 42. Éviter les catastrophes

 

 

Distribution de la charge à la demande

Dans ce cas d’utilisation, Metro Volume distribue de manière transparente la charge de travail, équilibre l’utilisation du stockage ou le trafic E/S entre deux clusters PowerStore.

Fonctionnement : Dans un processus à la demande, piloté par l’opérateur, Metro Volume peut déplacer de manière transparente des volumes d’un cluster PowerStore à un autre. Les applications fonctionnent en continu. Cette capacité permet plusieurs options pour améliorer le fonctionnement du système :

  • Distribution de la charge de travail E/S
  • Distribution du stockage
  • Distribution de la charge de trafic frontal
  • Réaffectation de la charge de travail en fonction des capacités des systèmes hétérogènes
Figure 43. Distribution de la charge à la demande

 

Figure 44. Répartition de la charge à la demande entre plusieurs clusters

 

Conclusion

 

Résumé

Dell PowerStore Metro Volume offre une mobilité transparente des données pour divers cas d’utilisation proactive. Metro Volume est facile à déployer et à gérer. Cependant, vous devez effectuer une planification minutieuse pour vous assurer que les charges de travail critiques nécessitant une haute disponibilité sont polarisées vers le Metro Volume préféré. De plus, prenez les mesures nécessaires pour vous assurer que le Metro Volume préféré reste hautement disponible pour les hôtes de stockage avec une présentation de stockage uniforme et une disponibilité vSphere configurée et activée lorsque cela est possible. N’utilisez pas Metro Volume comme solution principale pour la reprise après sinistre.

References

 

Dell Technologies documentation

The following Dell Technologies documentation provides other information related to this document. Access to these documents depends on your login credentials. If you do not have access to a document, contact your Dell Technologies representative.

 

VMware documentation

See the following links for related VMware resources:

 

No votes yet.
Please wait...
72 min read" />72


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.