Déployez des applications en cluster sur Azure Elastic SAN

Les volumes Azure Elastic SAN peuvent être attachés simultanément à plusieurs clients de calcul, ce qui vous permet de déployer ou de migrer des applications de cluster vers Azure. Vous devez utiliser un gestionnaire de cluster pour partager un volume Elastic SAN, comme le cluster de basculement Windows Server (WSFC, Windows Server Failover Cluster) ou Pacemaker. Le gestionnaire de cluster gère les communications de nœud de cluster et le verrouillage d’écriture. Elastic SAN n’offre pas nativement de système de fichiers entièrement managé accessible via SMB ou NFS.

Lorsqu’ils sont utilisés en tant que volume partagé, les volumes Elastic SAN peuvent être partagés entre différentes zones ou régions de disponibilité. Le partage d’un volume dans un SAN de stockage redondant local entre différentes zones réduit vos performances en raison d’une latence accrue entre le volume et les clients.

Limites

• Les scripts de connexion Elastic SAN peuvent être utilisés pour attacher des volumes partagés à des machines virtuelles dans des Groupes de machines virtuelles identiques ou des machines virtuelles dans des Groupes à haute disponibilité. L’alignement du domaine d’erreur n’est pas pris en charge.
• Un volume partagé prend en charge un maximum de 128 sessions.
  • Un client individuel peut créer plusieurs sessions sur un volume individuel pour améliorer les performances. Par exemple, si vous créez 32 sessions sur chacun de vos clients, seuls quatre clients peuvent se connecter à un volume unique.

Pour connaître les autres limitations d’Elastic SAN, consultez Prise en charge des fonctionnalités de Stockage Azure.

Fonctionnement

Les volumes partagés Elastic SAN utilisent des réservations persistantes SCSI-3 pour permettre aux initiateurs (clients) de contrôler l’accès à un volume SAN élastique partagé. Ce protocole permet à un initiateur de réserver l’accès à un volume Elastic SAN, de limiter l’accès en écriture (ou en lecture) par d’autres initiateurs et de conserver la réservation sur un volume au-delà de la durée de vie d’une session par défaut.

La réservation persistante SCSI-3 joue un rôle essentiel dans le maintien de la cohérence et de l’intégrité des données au sein de volumes partagés des scénarios de cluster. Les nœuds de calcul d’un cluster peuvent lire ou écrire dans leurs volumes Elastic SAN attachés en fonction de la réservation choisie par leurs applications de cluster.

Flux de réservation persistante

Le schéma suivant illustre un exemple d’application de base de données en cluster à deux nœuds qui utilise les réservations persistantes SCSI-3 pour activer le basculement d’un nœud vers l’autre.

Voici comment se déroule l’opération :

1. L’application en cluster s’exécutant sur Azure VM1 et Azure VM2 inscrit son intention de lire ou d’écrire sur le volume Elastic SAN.
2. L’instance d’application sur VM1 prend ensuite une réservation exclusive pour écrire sur le volume.
3. Cette réservation est imposée sur votre volume et la base de données peut désormais écrire exclusivement sur le volume. Toute écriture provenant de l’instance d’application sur VM2 échoue.
4. Si l’instance d’application sur VM1 cesse de fonctionner, l’instance sur VM2 peut lancer un basculement de base de données et prendre le contrôle du volume.
5. La réservation est désormais imposée sur le volume et n’acceptera pas d’écritures de VM1. Elle accepte uniquement les écritures de VM2.
6. L’application en cluster peut mener à bien le basculement de base de données et traiter les demandes de VM2.

Le schéma suivant illustre une autre charge de travail en cluster courante dans laquelle plusieurs nœuds lisent les données d’un volume Elastic SAN pour l’exécution de processus parallèles, comme l’entraînement de modèles Machine Learning.

Voici comment se déroule l’opération :

1. L’application en cluster s’exécutant sur toutes les machines virtuelles inscrit son intention de lire ou d’écrire sur le volume Elastic SAN.
2. L’instance d’application sur VM1 prend une réservation exclusive pour écrire sur le volume tout en permettant aux autres machines virtuelles de lire sur le volume.
3. Cette réservation est imposée sur le volume.
4. Tous les nœuds du cluster peuvent désormais lire sur le volume. Un seul nœud écrit en retour les résultats sur le volume pour le compte de tous les nœuds du cluster.

Commandes PR SCSI prises en charge

Les commandes suivantes sont prises en charge avec les volumes Elastic SAN :

Pour interagir avec le volume, commencez par l’action de réservation persistante appropriée :

• PR_REGISTER_KEY
• PR_REGISTER_AND_IGNORE
• PR_GET_CONFIGURATION
• PR_RESERVE
• PR_PREEMPT_RESERVATION
• PR_CLEAR_RESERVATION
• PR_RELEASE_RESERVATION

Lorsque vous utilisez PR_RESERVE, PR_PREEMPT_RESERVATION ou PR_RELEASE_RESERVATION, fournissez l’un des types de réservations persistantes suivants :

• PR_NONE
• PR_WRITE_EXCLUSIVE
• PR_EXCLUSIVE_ACCESS
• PR_WRITE_EXCLUSIVE_REGISTRANTS_ONLY
• PR_EXCLUSIVE_ACCESS_REGISTRANTS_ONLY
• PR_WRITE_EXCLUSIVE_ALL_REGISTRANTS
• PR_EXCLUSIVE_ACCESS_ALL_REGISTRANTS

Le type de réservation persistante détermine l’accès au volume à partir de chaque nœud dans le cluster.

Type de réservation persistante	Titulaire de la réservation	Enregistré	Autres
AUCUNE RÉSERVATION	N/A	Lecture-écriture	Lecture-écriture
ÉCRITURE EXCLUSIVE	Lecture-écriture	Lecture seule	Lecture seule
ACCÈS EXCLUSIF	Lecture-écriture	Aucun accès	Aucun accès
ÉCRITURE EXCLUSIVE : REGISTRANTS UNIQUEMENT	Lecture-écriture	Lecture-écriture	Lecture seule
ACCÈS EXCLUSIF : REGISTRANTS UNIQUEMENT	Lecture-écriture	Lecture-écriture	Aucun accès
ÉCRITURE EXCLUSIVE : TOUS LES REGISTRANTS	Lecture-écriture	Lecture-écriture	Lecture seule
ACCÈS EXCLUSIF : TOUS LES REGISTRANTS	Lecture-écriture	Lecture-écriture	Aucun accès

Vous devez également fournir une clé de réservation persistante lorsque vous utilisez :

• PR_RESERVE
• PR_REGISTER_AND_IGNORE
• PR_REGISTER_KEY
• PR_PREEMPT_RESERVATION
• PR_CLEAR_RESERVATION
• PR_RELEASE-RESERVATION.