Considérations sur la résilience des applications

Cette page fournit des informations sur la résilience des applications Google Cloud NetApp Volumes.

Remarques sur la résilience des applications

Bien que NetApp Volumes soit disponibilité élevée, les événements de maintenance planifiés tels que les mises à jour de plate-forme, les mises à niveau de service, les mises à niveau logicielles ou les défaillances de composants non planifiées dans le service peuvent entraîner de brèves pauses dans les opérations d'entrée/sortie (E/S).

Mises en veille des E/S

Le logiciel client Network File System (NFS), Server Message Block (SMB) et iSCSI à l'intérieur de votre système d'exploitation gère les brèves pauses d'E/S. Le client attend et relance les opérations d'E/S sans signaler le problème à l'application. Ces courtes pauses sont considérées comme non perturbatrices, car même si les utilisateurs de l'application peuvent constater des temps de réponse plus longs, l'application ne signale pas d'erreurs d'E/S.

Pour les pauses d'E/S plus longues, le comportement dépend du client NFS, SMB ou iSCSI de votre système d'exploitation, ainsi que des éventuels délais d'attente configurés dans l'application. Les sections suivantes abordent les détails spécifiques au protocole pour les pauses d'E/S.

Mises en pause des E/S NFS

Tous les appels à un partage NFS indisponible et monté en dur sont bloqués dans le client NFS et attendent indéfiniment que le serveur NFS réponde à nouveau. Pendant que votre client NFS attend, des messages s'affichent dans les journaux de votre client pour indiquer que le serveur NFS ne répond pas.

Du point de vue de l'application, les opérations d'E/S telles que la lecture ou l'écriture sont bloquées et restent en suspens jusqu'à ce que le partage NFS soit renvoyé avec succès. Lors des pauses d'E/S, aucune opération d'E/S n'est jamais perdue et NetApp Volumes assure la cohérence des données, sauf si vous arrêtez de force les opérations d'E/S en cours côté client.

Utiliser des applications logicielles de cluster pour automatiser les basculements

Si vous utilisez des applications logicielles de cluster telles que Pacemaker sur les VM clientes pour automatiser le basculement de votre application, configurez vos délais d'attente pour les partages NFS afin de résister aux événements de maintenance NetApp Volumes. Ces basculements interrompent les opérations d'E/S en cours sur le client et peuvent entraîner la perte de transactions. Nous vous recommandons les délais d'attente suivants :

Type de protocole Délai d'inactivité recommandé Remarques
Partages NFSv3 60 secondes (pour les niveaux de service Standard, Premium et Extreme)
120 secondes (pour le niveau de service Flex)
Nous vous recommandons d'utiliser une méthode de clôture qui utilise l'option de montage nolock au lieu de s'appuyer sur les verrous NFS.
NFSv4.1 105 secondes (pour les niveaux de service Standard, Premium et Extreme)
165 secondes (pour le niveau de service Flex)
Le protocole NFSv4.1 ajoute automatiquement un verrouillage fiable sur NFSv3 (RFC NFSv4.x, section 9.6.2), que vous pouvez utiliser comme mécanisme de clôture. La récupération de l'état de verrouillage ajoute 45 secondes.

Suspension des E/S de partage SMB

Contrairement à NFS, les sessions SMB utilisent une connexion qui peut expirer. Dans la plupart des cas, NetApp Volumes ne dépasse pas les délais d'expiration.

Délai avant expiration de la session

Le délai d'expiration de la session est défini au niveau du client. Le délai avant expiration par défaut pour les clients Windows est de 60 secondes. Vous pouvez exécuter la commande Get-SmbClientConfiguration/Set-SmbClientConfiguration à l'aide du paramètre SessionTimeout pour lire ou modifier le délai avant expiration de la session.

Si un délai d'inactivité de session se produit, la session SMB est interrompue et une erreur d'E/S est signalée à l'application effectuant l'E/S. L'Explorateur de fichiers ou les applications Microsoft 365 se reconnectent généralement dès que l'utilisateur accède à nouveau au partage SMB. En cas d'erreurs d'E/S, certaines applications tentent de se reconnecter et de réessayer l'opération d'E/S ayant échoué, tandis que d'autres ne le font pas. Consultez la documentation du fournisseur de votre application pour savoir comment elle gère les délais d'attente SMB et peut fonctionner de manière résiliente sur les partages SMB.

Les partages disponibles en continu (CA) sont une fonctionnalité SMB3.x qui améliore la résilience au basculement pour les applications de type base de données. NetApp Volumes est compatible avec les partages en disponibilité continue pour Microsoft SQL Server et FSLogix.

La récupération en cas d'échec s'améliore à chaque nouvelle version de SMB. NetApp Volumes est compatible avec SMB 2.1, 3.0 et 3.1.1. Si possible, utilisez la dernière version SMB compatible. Windows 10/Server 2016 et versions ultérieures sont compatibles avec la dernière version SMB 3.1.1.

Précautions basées sur les applications pour les PME

Certaines applications basées sur SMB nécessitent le basculement transparent SMB. Le basculement transparent SMB permet d'effectuer des opérations de maintenance sur les volumes SMB dans NetApp Volumes sans interrompre la connectivité aux applications serveur qui stockent les données ou y accèdent. NetApp Volumes est compatible avec l'option de partage de disponibilité continue (CA) SMB pour s'assurer que certaines applications sont compatibles avec le basculement transparent SMB. L'utilisation de partages SMB disponibles en continu n'est compatible qu'avec les charges de travail suivantes :

  • Conteneurs de profils utilisateur FSLogix

  • Microsoft SQL Server (et non Linux SQL Server)

Les partages SMB disponibles en continu ne sont pas compatibles avec les applications personnalisées.

Mises en veille des E/S iSCSI

Dans les environnements Linux et Windows, les clients iSCSI (initiateurs) gèrent les pauses d'E/S en réessayant les commandes jusqu'à ce que la cible (NetApp Volumes) devienne disponible. Lors de brefs événements de maintenance, l'initiateur iSCSI tente de se reconnecter et de reprendre les opérations d'E/S en attente, ce qui contribue à maintenir la résilience des applications.

Délais avant expiration iSCSI

La configuration appropriée des délais d'attente iSCSI est essentielle pour maintenir la résilience des applications lors d'événements de maintenance ou d'interruptions de service inattendues.

Pour les systèmes Linux, NetApp Volumes utilise les paramètres par défaut de l'initiateur iSCSI. Ces paramètres incluent des configurations spécifiques à NetApp dans le mappeur de périphériques Linux multipath par défaut, qui gère automatiquement les exigences de délai d'attente lors des événements de maintenance des NetApp Volumes.

Toutefois, pour les systèmes Windows, modifiez les paramètres Windows MPIO à l'aide de la commande suivante pour gérer les événements de maintenance NetApp Volumes.

 Set-MPIOSetting -NewPathVerificationState Enabled `
 -NewPDORemovePeriod 130 `
 -NewRetryCount 6 `
 -CustomPathRecovery Enabled `
 -NewPathRecoveryInterval 30 `

Pendant les pauses d'E/S, l'initiateur iSCSI réessaie les commandes et maintient les E/S en attente pendant toute la durée du délai d'expiration. Si le délai avant expiration est dépassé, le système d'exploitation peut signaler des erreurs d'E/S à l'application, ce qui peut entraîner la perte de transactions ou nécessiter une récupération au niveau de l'application.

Remarques concernant les applications et les clusters

Si vous utilisez des logiciels ou des applications de clustering qui automatisent le basculement, configurez vos délais d'attente iSCSI pour tenir compte des événements de maintenance NetApp Volumes. Un basculement prématuré peut interrompre les opérations d'E/S en cours et entraîner une perte de données ou de transactions. Consultez toujours la documentation de votre application et de votre système d'exploitation pour connaître les bonnes pratiques concernant les paramètres de délai avant expiration iSCSI.

Des événements de maintenance planifiés, comme les mises à niveau de plate-forme et de logiciel de service, peuvent se produire de temps en temps. Les événements de maintenance sont considérés comme non perturbateurs du point de vue du protocole de fichier (NFS ou SMB) tant que l'application peut gérer les pauses d'E/S qui peuvent se produire lors de ces événements.

Pour les niveaux de service Standard, Premium et Extreme, les pauses d'E/S sont généralement courtes et durent de quelques secondes à 30 secondes.

Pour le niveau de service Flex, les pauses d'E/S peuvent durer jusqu'à 70 secondes.

Étapes suivantes

Découvrez les considérations de sécurité concernant Google Cloud NetApp Volumes.