Partager via

FAQ sur la résilience des applications pour Azure NetApp Files

  • Article

Cet article répond aux questions fréquemment posées sur la résilience des applications Azure NetApp Files.

Que recommandez-vous pour gérer les interruptions potentielles de l’application dues à des événements de maintenance de service de stockage ?

Azure NetApp Files peut faire l’objet d’une maintenance planifiée occasionnelle (par exemple, mises à jour de la plateforme, mises à niveau de services ou de logiciels). Du point de vue du protocole de fichier (NFS/SMB), les opérations de maintenance ne sont pas perturbatrices, tant que l’application peut gérer les pauses d’E/S qui peuvent se produire brièvement au cours de ces événements. Les pauses d’e/s sont généralement courtes, allant de quelques secondes à 30 secondes. Le protocole NFS est particulièrement robuste, et les opérations sur les fichiers client-serveur se poursuivent normalement. Certaines applications peuvent nécessiter un réglage pour gérer les pauses d’E/S allant jusqu’à 30-45 secondes. Par conséquent, veillez à prendre connaissance des paramètres de résilience de l’application pour gérer les événements de maintenance de service de stockage. Pour les applications avec interaction humaine tirant parti du protocole SMB, les paramètres standard du protocole sont généralement suffisants.

Important

Pour garantir une architecture résiliente, il est essentiel de comprendre que le cloud fonctionne sous un modèle de responsabilité partagée. Ce modèle englobe la plateforme cloud Azure, ses services d’infrastructure, la couche du système d’exploitation et les fournisseurs d’applications. Chacun de ces composants joue un rôle essentiel dans la gestion correcte des interruptions d’application potentielles qui peuvent survenir pendant les événements de maintenance du service de stockage.

Dois-je prendre des précautions particulières pour les applications basées sur le protocole SMB ?

Oui, certaines applications basées sur le protocole SMB nécessitent le basculement transparent SMB. Le basculement transparent SMB permet d’effectuer des opérations de maintenance sur le service Azure NetApp Files sans interrompre la connectivité aux applications du serveur qui stockent et accèdent aux données sur les volumes SMB. Pour prendre en charge le basculement transparent SMB pour des applications spécifiques, Azure NetApp Files prend désormais en charge l’option de partages SMB à disponibilité continue. L’utilisation de la disponibilité continue SMB est prise en charge uniquement pour les charges de travail sur :

Attention

Les applications personnalisées ne sont pas prises en charge avec la disponibilité continue SMB et ne peuvent pas être utilisées avec les volumes avec disponibilité continue SMB.

J’exécute IBM MQ sur Azure NetApp Files. Quelles précautions puis-je prendre pour éviter les interruptions dues à des événements de maintenance de service de stockage malgré l’utilisation du protocole NFS ?

Si vous exécutez l’application IBM MQ dans une configuration de fichiers partagés, où les données et les journaux IBM MQ sont stockés sur un volume Azure NetApp Files, les considérations suivantes sont recommandées pour améliorer la résilience pendant les événements de maintenance du service de stockage :

Remarque

Le nombre de messages que chaque paire multi-instance MQ doit traiter dépend fortement de votre environnement spécifique. Vous devez décider du nombre de paires multi-instances MQ nécessaires ou des règles de scale-up ou de scale-down.

L’architecture scale-out se compose de plusieurs paires multi-instances IBM MQ déployées derrière un équilibreur de charge Azure. Les applications configurées pour communiquer avec IBM MQ seraient ensuite configurées pour communiquer avec les instances d’IBM MQ via Azure Load Balancer. Pour une assistance relative à IBM MQ sur des volumes NFS partagés, vous devez vous adresser au support d’IBM.

J’exécute Apache ActiveMQ avec LevelDB ou KahaDB sur Azure NetApp Files. Quelles précautions puis-je prendre pour éviter les interruptions dues à des événements de maintenance de service de stockage malgré l’utilisation du protocole NFS ?

Si vous utilisez Apache ActiveMQ, nous vous recommandons de déployer la haute disponibilité d’ActiveMQ avec des casiers de stockage enfichables.

Les modèles de haute disponibilité ActiveMQ garantissent qu’une instance de répartiteur est toujours en ligne et en mesure de traiter le trafic des messages. Les deux modèles de haute disponibilité ActiveMQ les plus courants impliquent le partage d’un système de fichiers sur un réseau. L’objectif est de fournir LevelDB ou KahaDB aux instances actives et passives du répartiteur. Ces modèles de haute disponibilité nécessitent qu’un verrou au niveau du système d’exploitation soit obtenu et maintenu sur un fichier dans les répertoires LevelDB ou KahaDB, appelé « lock ». Ce modèle de haute disponibilité ActiveMQ présente quelques problèmes. Ils peuvent aboutir à une situation « sans maître », où le réplica ne sait pas qu’il peut verrouiller le fichier. Ils peuvent également aboutir à une configuration « maître-maître » qui entraîne l’altération de l’index ou du journal, et finalement la perte de messages. La plupart de ces problèmes proviennent de facteurs hors du contrôle d’ActiveMQ. Par exemple, un client NFS mal optimisé peut causer l’obsolescence des données de verrouillage sous la charge, ce qui entraîne un temps d’arrêt « sans maître » pendant le basculement.

Étant donné que la plupart des problèmes liés à cette solution de haute disponibilité proviennent du verrouillage inexact de fichiers au niveau du système d’exploitation, la communauté ActiveMQ a introduit le concept d’un casier de stockage enfichable dans la version 5.7 du répartiteur. Cette approche permet à un utilisateur de tirer parti d’un autre moyen de verrou partagé, à l’aide d’un verrou de base de données JDBC au niveau de la ligne par opposition à un verrou de système de fichiers au niveau du système d’exploitation. Pour obtenir de l’aide ou des conseils sur les architectures et les déploiements de la haute disponibilité ActiveMQ, contactez OpenLogic by Perforce.

J’exécute Apache ActiveMQ avec LevelDB ou KahaDB sur Azure NetApp Files. Quelles précautions puis-je prendre pour éviter les interruptions dues à des événements de maintenance de service de stockage malgré l’utilisation du protocole SMB ?

La recommandation générale du secteur est de ne pas exécuter votre stockage partagé KahaDB sur CIFS [Common Internet File System]/SMB. Si vous avez des difficultés à maintenir un état de verrouillage précis, consultez le casier de stockage enfichable de JDBC, qui peut fournir un mécanisme de verrouillage plus fiable. Pour obtenir de l’aide ou des conseils sur les architectures et les déploiements de la haute disponibilité ActiveMQ, contactez OpenLogic by Perforce.

J’exécute Boomi sur Azure NetApp Files. Quelles précautions puis-je prendre pour éviter les interruptions dues à des événements de maintenance de service de stockage ?

Si vous exécutez Boomi, il est recommandé de suivre les meilleures pratiques Boomi pour la haute disponibilité des temps d’exécution et la récupération d’urgence.

Boomi recommande que Boomi Molecule soit utilisé afin d’implémenter la haute disponibilité pour Boomi Atom. La configuration système requise pour Boomi Molecule indique que les partages de fichiers NFS avec verrouillage NFS activé (prise en charge NLM) ou SMB peuvent être utilisés. Dans le contexte d’Azure NetApp Files, les volumes NFSv4.1 prennent en charge NLM.

Boomi recommande que le partage de fichiers SMB soit utilisé avec des machines virtuelles Windows ; pour NFS, Boomi recommande des machines virtuelles Linux.

Remarque

Les partages de disponibilité continue Azure NetApp Files ne sont pas pris en charge avec Boomi.

Étapes suivantes