Ce que signifie le passage au quota inconditionnel de volume pour votre service Azure NetApp Files
Depuis le début du service, Azure NetApp Files utilise un mécanisme d’approvisionnement et de croissance automatique des pools de capacité. Les volumes Azure NetApp Files sont approvisionnés dynamiquement sur un pool de capacité sous-jacent, approvisionné par le client, d’un niveau et d’une taille sélectionnés. Les tailles de volume (quotas) sont utilisées pour fournir le niveau de performance et la capacité, et les quotas peuvent être ajustés à la volée à tout moment. Ce comportement signifie que, actuellement, le quota de volume est un levier du niveau de performance utilisé pour contrôler la bande passante sur le volume. Actuellement, les pools de capacité sous-jacents augmentent automatiquement lorsque la capacité est pleine.
Important
Le comportement d’Azure NetApp Files en matière de provisionnement de volumes et de pools de capacité va changer pour devenir un mécanisme manuel et contrôlable. À partir du 30 avril 2021 (mise à jour), les tailles de volume (quota) géreront le niveau de performance de la bande passante ainsi que la capacité approvisionnée, et les pools de capacité sous-jacents n’augmenteront plus automatiquement.
Raisons du passage au quota inconditionnel de volume
De nombreux clients ont indiqué que le comportement initial posait trois grands inconvénients :
- Les clients de machines virtuelles voient la capacité approvisionnée dynamiquement (100 Tio) d’un volume donné lorsqu’ils utilisent l’espace du système d’exploitation ou des outils de surveillance de la capacité, ce qui donne une visibilité inexacte de la capacité côté client ou application.
- Les propriétaires d’applications n’ont aucun contrôle sur l’espace de pools de capacité approvisionné (et le coût associé) en raison du comportement de croissance automatique des pools de capacité. Cette situation est fastidieuse dans les environnements où les « pertes de contrôle de processus » peuvent rapidement remplir et augmenter la capacité approvisionnée et le coût.
- Les clients veulent voir et maintenir une corrélation directe entre la taille du volume (quota) et le niveau de performance. Avec le comportement actuel de surabonnement (implicite) d’un volume (en matière de capacité) et de croissance automatique des pools, les clients n’ont pas de corrélation directe tant que le quota de volume n’a pas été défini ou réinitialisé activement.
De nombreux clients ont demandé un contrôle direct sur la capacité approvisionnée. Ils souhaitent contrôler et équilibrer la capacité et l’utilisation du stockage. Ils souhaitent également contrôler les coûts et disposer d’une visibilité, côté application et côté client, de la capacité disponible, utilisée et approvisionnée et du niveau de performance de leurs volumes d’application.
Présentation du passage au quota inconditionnel de volume
Lorsque vous passez au quota inconditionnel de volume, les volumes Azure NetApp Files ne sont plus approvisionnés dynamiquement à 100 Tio (maximum). Les volumes seront approvisionnés à la taille réelle configurée (quota). En outre, les pools de capacité sous-jacents n’augmentent plus automatiquement une fois la consommation à pleine capacité atteinte. Ce changement reflète le comportement des disques managés Azure, qui sont également approvisionnés tels quels, sans augmentation automatique de la capacité.
Prenons l’exemple d’un volume Azure NetApp Files configuré à une taille de 1 Tio (quota) sur un pool de capacité de niveau de service Ultra de 4 Tio. Une application écrit continuellement des données sur le volume.
Le comportement initial :
- Bande passante attendue : 128 Mio/s
- Capacité totale utilisable (et visible par le client) : 100 Tio
Vous ne pouvez pas écrire plus de données sur le volume au-delà de cette taille. - Pool de capacité : augmente automatiquement par incréments de 1 Tio lorsqu’il est plein.
- Passage au quota de volume : modifie uniquement le niveau de performance (bande passante) du volume. Cela ne modifie pas la capacité visible ou utilisable par le client.
Le comportement modifié :
- Bande passante attendue : 128 Mio/s
- Capacité totale utilisable (et visible par le client) : 1 Tio. Vous ne serez pas en mesure d’écrire plus de données sur le volume au-delà de cette taille.
- Pool de capacité : la taille reste fixée à 4 Tio et n’augmente pas automatiquement.
- Passage au quota de volume : modifie le niveau de performance (bande passante) et la capacité visible ou utilisable par le client du volume.
Vous devez surveiller de manière proactive l’utilisation des volumes Azure NetApp Files et des pools de capacité. Pour une consommation proche de la pleine capacité, vous devez modifier intentionnellement l’utilisation des volumes et des pools. Azure NetApp Files continuera à permettre des opérations de redimensionnement à la volée des volumes et des pools de capacité.
Mise en œuvre du passage au quota inconditionnel de volume
Cette section fournit une aide sur la manière de rendre opérationnel le passage au quota inconditionnel de volume pour une transition en douceur. Elle donne également des indications sur la manière de gérer les volumes et les pools de capacité actuellement approvisionnés, le monitoring continu et les options d’alerte et de gestion de la capacité.
Volumes et pools de capacité actuellement approvisionnés
En raison du passage au quota inconditionnel de volume, vous devez modifier votre modèle de fonctionnement. Les volumes et les pools de capacité approvisionnés nécessitent une gestion continue de la capacité. Comme le changement de comportement se fera instantanément, l’équipe d’Azure NetApp Files recommande une série de mesures correctives ponctuelles pour les volumes et les pools de capacité existants, précédemment approvisionnés, comme décrit dans cette section.
Recommandations de mesures correctives ou préventives ponctuelles
Le passage au quota inconditionnel de volume entraîne des modifications de la capacité approvisionnée et disponible pour les volumes et pools précédemment approvisionnés. Par conséquent, certains problèmes d’allocation de capacité peuvent se produire. Pour éviter aux clients des situations de dépassement de capacité à court terme, l’équipe d’Azure NetApp Files recommande les mesures correctives/préventives ponctuelles suivantes :
Tailles de volume approvisionnées :
Redimensionnez chaque volume approvisionné pour disposer d’une mémoire tampon appropriée en fonction du taux de changement et des alertes ou redimensionnez le délai d’exécution (par exemple, 20 % en fonction des considérations de charge de travail typiques), avec un maximum de 100 Tio (ce qui correspond à la limite de taille des volumes habituelle). Cette nouvelle taille de volume, y compris la capacité de la mémoire tampon, doit reposer sur les facteurs suivants :- Capacité de volume approvisionnée, dans le cas où la capacité utilisée est inférieure au quota de volume approvisionné.
- Capacité de volume utilisée, dans le cas où la capacité utilisée est supérieure au quota de volume approvisionné.
Il n’y a pas de frais supplémentaires pour l’augmentation de la capacité au niveau du volume si le pool de capacité sous-jacent n’a pas besoin d’être augmenté. À la suite de ce changement, vous pourriez observer une augmentation de la limite de bande passante pour le volume (dans le cas où le type de pool de capacité Qualité de service automatique est utilisé).
Tailles des pools de capacité approvisionnées :
Une fois les tailles de volume ajustées, si la somme des tailles de volumes devient supérieure à la taille du pool de capacité d’hébergement, le pool de capacité doit être augmenté à une taille égale ou supérieure à la somme des volumes, avec un maximum de 500 Tio. Pour plus d’informations sur les limites, consultez Limites des ressources pour Azure NetApp Files. La capacité supplémentaire du pool de capacité est soumise aux frais ACR habituels.
Si vous avez besoin d’aide pour configurer la surveillance ou les alertes comme décrit dans les sections ci-dessous, collaborez avec vos spécialistes Azure NetApp Files pour valider votre environnement.
Gestion continue des capacités
Après avoir appliqué les mesures correctives ponctuelles, vous devez mettre en place des processus permanents pour surveiller et gérer les capacités. Les sections suivantes présentent des suggestions et des alternatives concernant le suivi et la gestion des capacités.
Surveiller l’utilisation des capacités
Vous pouvez surveiller l’utilisation des capacités à différents niveaux.
Surveillance au niveau de la machine virtuelle
Le niveau le plus élevé de surveillance (le plus proche de l’application) se fait à partir de la machine virtuelle de l’application. Vous observerez un changement de comportement dans les rapports de capacité depuis le système d’exploitation client de la machine virtuelle.
Dans les deux scénarios suivants, prenons l’exemple d’un volume Azure NetApp Files configuré à une taille de 1 Tio (quota) sur un pool de capacité de niveau de service Ultra de 4 Tio.
Windows
Les clients Windows peuvent vérifier la capacité utilisée et disponible d’un volume à l’aide des propriétés du lecteur mappé. Vous pouvez utiliser l’option Explorateur ->Lecteur ->Propriétés.
Les exemples suivants illustrent les rapports relatifs à la capacité de volume dans Windows avant le changement de comportement :
Vous pouvez également utiliser la commande dir dans l’invite de commandes, comme indiqué ci-dessous :
Les exemples suivants illustrent les rapports relatifs à la capacité de volume dans Windows après le changement de comportement :
L’exemple suivant montre la sortie de la commande dir :
Linux
Les clients Linux peuvent vérifier la capacité utilisée et disponible d’un volume à l’aide de la commande df. L’option -h indiquera la taille, l’espace utilisé et l’espace disponible dans un format lisible, à l’aide de les tailles d’unités M, G et T.
L’exemple suivant illustre les rapports relatifs à la capacité de volume dans Linux avant le changement de comportement :
L’exemple suivant illustre les rapports relatifs à la capacité de volume dans Linux après le changement de comportement :
Configurer des alertes à l’aide d’ANFCapacityManager
Vous pouvez utiliser l’outil ANFCapacityManager de Logic Apps, pris en charge par la communauté, pour surveiller la capacité d’Azure NetApp Files et recevoir des alertes personnalisées. L’outil ANFCapacityManager est disponible sur la page de GitHub relative à ANFCapacityManager.
ANFCapacityManager est une application logique Azure qui gère les règles d’alerte basées sur la capacité. Elle augmente automatiquement la taille des volumes pour éviter que vos volumes Azure NetApp Files ne manquent d’espace. Elle est facile à déployer et offre les capacités Alert Management suivantes :
- Lorsqu’un pool de capacité ou un volume Azure NetApp Files est créé, ANFCapacityManager crée une règle d’alerte métrique en fonction du seuil spécifié du pourcentage de consommation.
- Lorsqu’un pool de capacité ou un volume Azure NetApp Files est redimensionné, ANFCapacityManager modifie la règle d’alerte métrique en fonction du seuil spécifié du pourcentage de capacité consommée. Si la règle d’alerte n’existe pas, elle est créée.
- Lorsqu’un pool de capacité ou un volume Azure NetApp Files est supprimé, la règle d’alerte de métrique correspondante est supprimée.
Vous pouvez configurer les principaux paramètres d’alerte suivants :
- Seuil de pleine capacité en pourcentage du pool de capacité : Ce paramètre détermine le seuil de consommation qui déclenche une alerte pour les pools de capacité. Une valeur de 90 déclenche une alerte lorsque le pool de capacité atteint une consommation de 90 %.
- Seuil de pleine capacité en pourcentage du volume : Ce paramètre détermine le seuil de consommation qui déclenche une alerte pour les volumes. Une valeur de 80 déclenche une alerte lorsque le volume atteint une consommation de 80 %.
- Groupe d’actions existant pour les notifications de capacité : Ce paramètre est le groupe d’actions qui sera déclenché pour les alertes basées sur la capacité. Vous devez créer ce paramètre au préalable. Le groupe d’actions peut envoyer des e-mails, des SMS ou d’autres formats de notification.
L’illustration suivante montre la configuration des alertes :
Une fois ANFCapacityManager installé, vous pouvez vous attendre au comportement suivant : lorsqu’un pool de capacité ou un volume Azure NetApp Files est créé, modifié ou supprimé, l’application logique crée, modifie ou supprime automatiquement une règle d’alerte de métrique basée sur la capacité et portant le nom ANF_Pool_poolname ou ANF_Volume_poolname_volname.
Gérer la capacité
En plus de la surveillance et des alertes, vous devez également intégrer une pratique de gestion de la capacité des applications pour gérer la consommation de capacité (accrue) d’Azure NetApp Files. Quand un pool de capacité ou un volume Azure NetApp Files se remplit, une capacité supplémentaire peut être fournie à la volée sans interruption des applications. Cette section décrit les différentes méthodes manuelles et automatisées permettant d’augmenter l’espace des volumes et des pools de capacité en fonction des besoins.
Manuel
Vous pouvez utiliser le portail ou l’interface CLI pour augmenter manuellement la taille des pools de capacité ou des volumes.
Portail
Vous pouvez changer la taille d’un volume selon les besoins. La consommation de capacité d’un volume est comptée par rapport à la capacité configurée de son pool.
Dans votre compte NetApp, sélectionnez Volumes.
Cliquez avec le bouton droit sur le nom du volume que vous souhaitez redimensionner ou sélectionnez l’icône
…à la fin de la ligne correspondant au volume pour afficher le menu contextuel.Utilisez les options du menu contextuel pour redimensionner ou pour supprimer le volume.
Dans certains cas, le pool de capacité d’hébergement ne dispose pas d’une capacité suffisante pour redimensionner les volumes. Toutefois, vous pouvez modifier la taille du pool de capacité par incréments ou décréments de 1 Tio. La taille du pool de capacité ne peut pas être inférieure à 4 Tio. Le redimensionnement du pool de capacités change la capacité Azure NetApp Files achetée.
Dans le panneau Gérer le compte NetApp, sélectionnez le pool de capacité que vous souhaitez redimensionner.
Cliquez avec le bouton droit sur le nom du pool de capacité ou sélectionnez sur l’icône
…à la fin de la ligne correspondant au pool de capacité pour afficher le menu contextuel.Utilisez les options du menu contextuel pour redimensionner ou pour supprimer le pool de capacités.
CLI ou PowerShell
Vous pouvez utiliser les outils CLI d’Azure NetApp Files, y compris Azure CLI et Azure PowerShell, pour modifier manuellement la taille des volumes ou des pools de capacité. Les deux commandes suivantes peuvent être utilisées pour gérer les ressources de pool et de volume Azure NetApp Files :
Pour gérer les ressources Azure NetApp Files à l’aide d’Azure CLI, vous pouvez ouvrir le portail Azure et sélectionner le lien Azure Cloud Shell en haut de la barre de menu :
Cette action ouvre Azure Cloud Shell :
Les exemples suivants utilisent les commandes permettant d’afficher et de mettre à jour la taille d’un volume :
Les exemples suivants utilisent les commandes permettant d’afficher et de mettre à jour la taille d’un pool de capacité :
Automatisé
Vous pouvez créer un processus automatisé pour gérer le changement de comportement.
API REST
L’API REST pour le service Azure NetApp Files définit des opérations HTTP sur des ressources telles que le compte NetApp, le pool de capacité, les volumes et les captures instantanées. La spécification de l’API REST pour Azure NetApp Files est publiée via la page Gestionnaire des ressources Azure NetApp Files de GitHub. Vous trouverez un exemple de code à utiliser avec les API REST dans GitHub.
Voir Développer pour Azure NetApp Files avec l’API REST.
API REST avec PowerShell
L’API REST pour le service Azure NetApp Files définit des opérations HTTP sur des ressources telles que le compte NetApp, le pool de capacité, les volumes et les captures instantanées. La spécification de l’API REST pour Azure NetApp Files est publiée via GitHub.
Voir Développer pour Azure NetApp Files avec l’API REST à l’aide de PowerShell.
Gestion des capacités à l’aide d’ANFCapacityManager
ANFCapacityManager est une application logique Azure qui gère les règles d’alerte basées sur la capacité. Elle augmente automatiquement la taille des volumes pour éviter que vos volumes Azure NetApp Files ne manquent d’espace. Outre l’envoi d’alertes, elle peut permettre l’augmentation automatique de la taille des volumes et des pools de capacité pour éviter que vos volumes Azure NetApp Files ne manquent d’espace :
- Facultativement, lorsqu’un volume Azure NetApp Files atteint le seuil spécifié du pourcentage de consommation, le quota de volume (taille) sera augmenté du pourcentage spécifié entre 10 et 100.
- Si l’augmentation de la taille du volume dépasse la capacité du pool de capacité contenant, la taille du pool de capacité est également augmentée pour s’adapter à la nouvelle taille du volume.
Vous pouvez configurer le paramètre clé de gestion des capacités suivant :
Augmentation en pourcentage de la croissance automatique : Pourcentage de la taille de volume existante pour augmenter automatiquement un volume si celui-ci atteint le seuil de pleine capacité en pourcentage spécifié. La valeur 0 (zéro) désactive la fonctionnalité de croissance automatique. Une valeur comprise entre 10 et 100 est recommandée.
Forum aux questions
Cette section répond à quelques questions sur le passage au quota inconditionnel de volume.
L’espace de capture instantanée est-il pris en compte dans la capacité utilisable ou approvisionnée d’un volume ?
Oui, la capacité de capture instantanée consommée est comptabilisée dans l’espace approvisionné du volume. Si le volume est plein, deux options de correction peuvent être envisagées :
- Redimensionnez le volume comme décrit dans cet article.
- Supprimez les captures instantanées plus anciennes pour libérer de l’espace dans le volume d’hébergement.
Ce changement signifie-t-il que le comportement de croissance automatique du volume disparaîtra d’Azure NetApp Files ?
Une idée fausse, mais courante, est que la taille des volumes Azure NetApp Files augmente automatiquement lorsqu’ils arrivent à saturation. Les volumes étaient approvisionnés de manière dynamique avec une taille de 100 Tio, indépendamment du quota réel défini, tandis que la taille du pool de capacité sous-jacent augmentait automatiquement par incréments de 1 Tio. Ce changement portera sur la taille du volume (visible et utilisable) par rapport au quota défini, et la taille des pools de capacité n’augmenta plus automatiquement. Ce changement permet d’obtenir les rapports précis recherchés quant à l’espace et à la capacité côté client. Il permet d’éviter une consommation de capacité « incontrôlée ».
Ce changement a-t-il un effet sur les volumes répliqués avec la réplication interrégion (préversion) ?
Le quota inconditionnel de volume n’est pas appliqué sur les volumes de destination de la réplication.
Ce changement a-t-il un effet sur les métriques actuellement disponibles dans Azure Monitor ?
Les métriques du portail et les statistiques d’Azure Monitor refléteront avec précision le nouveau modèle d’allocation et d’utilisation.
Ce changement a-t-il un effet sur les limites de ressources pour Azure NetApp Files ?
Il n’y a pas de changement dans les limites de ressources pour Azure NetApp Files au-delà des changements de quotas décrits dans cet article.
Existe-t-il un exemple de workflow ANFCapacityManager ?
Oui. Consultez la page Exemple de workflow de croissance automatique de volume de GitHub.
ANFCapacityManager est-elle prise en charge par Microsoft ?
L’application logique ANFCapacityManager est fournie telle quelle et n’est prise en charge ni par NetApp ni par Microsoft. Vous êtes encouragé à la modifier en fonction de votre environnement ou de vos besoins spécifiques. Vous devez tester la fonctionnalité avant de la déployer dans un environnement vital pour l’entreprise ou dans un environnement de production.
Comment signaler un bogue ou envoyer une demande de fonctionnalité pour ANFCapacityManger ?
Vous pouvez envoyer des bogues et des demandes de fonctionnalité en sélectionnant Nouveau problème dans la page ANFCapacityManager de GitHub.