L’offre de stockage Azure basée sur les classiques disques managés à base de HDD, SSD standard et SSD premium s’est enrichie depuis un an maintenant d’un service qui vient bousculer notre façon de concevoir nos architectures : Azure Netapp Files (ANF).

ANF est un service PAAS édité et proposé par Microsoft (et non pas par Netapp), qui ne nécessite donc l’acquisition d’aucune licence particulière. Nous allons voir dans cet article ce qui se cache derrière ce service et comment il fait évoluer nos habitudes. Je vous proposerai également un bref aperçu des coûts de la solution, en la comparant au compte de stockage Azure. L’exploitation de ces volumes ainsi que les performances seront traitées dans des posts à part.

 

La mutualisation

Jusqu’à présent, le stockage sur Azure était déployé suivant la quantité utile nécessaire d’une part, et les débits (Iops / MBps) attendus d’autre part. Ainsi, pour disposer par exemple d’un volume de 300GB proposant un débit de 250MBps en SSD Premium, nous étions contraints de provisionner un disque P40 de 2TB, comme le montre l’extrait suivant :

Le gaspillage de l’espace utilisé est évident (1,7TB dans cet exemple tout de même). Par ailleurs, ce débit de 250MBps n’est généralement ciblé que pour absorber des pics de consommation, il y a peu de chance pour que ce niveau soit atteint 100% du temps. Il s’agit généralement d’un niveau observé sur de courtes périodes de temps plus qu’un niveau moyen continu ! Autrement dit, nous provisionnons 1,7TB de trop simplement pour absorber des pics de consommation.

Azure Netapp Files promet de résoudre ce dilemme en proposant de partager l’espace de stockage provisionné (et donc le débit) entre différentes VM : plus de surconsommation : l’espace disque et le débit sont mutualisés i.e. partagés entre différents workflows. Dans notre exemple, les 1,7TB ne sont plus perdus, mais accessibles par d’autres VM.

Voyons cela de plus près…

 

Azure Netapp Files : Compte de Stockage, Capacity Pool et Volume

Description succincte de l’offre de service

Le déploiement d’ANF passe par la création d’un Compte de Stockage ANF au sein d’une souscription Azure, directement depuis la Market Place Azure :

Ce compte de stockage pourra ensuite contenir jusqu’à 10 Capacity Pool, chacun pouvant contenir jusqu’à 500 volumes. Chaque Compte de Stockage est rattaché à une seule région Azure, mais il est possible de créer plusieurs Comptes de Stockage dans différentes régions au sein de la même souscription.

Chaque Capacity Pool se verra associer un quota (taille en TB) qui induira les débits Iops et MBps disponibles pour les volumes sous-jacents, ainsi qu’un tier permettant de définir le niveau de performance maximum à atteindre, avec le coût associé comme illustré dans le tableau ci-dessous :

offre Netapp	taille minimal (TB)	Iops (per TB)	Mbps (per TB)	Coût mensuel (per TB)
Standard	4	1000	16	155 €
Premium	4	4000	64	310 €
Ultra	4	8000	128	414 €

A noter que la taille minimale d’un Capacity Pool est de 4TB, permettant ainsi des performances minimums allant de 4000Iops / 64MBps pour le standard à 32000 Iops/512 MBps pour l’ultra. Il est ensuite possible d’augmenter les capacités par tranche de 1TB, augmentant d’autant les débits suivant le tiers choisi.

Le fonctionnement global

Le Capacity Pool agit comme une réservation de taille et de débit, qui sera ensuite partagée/éclatée entre différents volumes, qui pourront être montés sur différentes VM. Ainsi, si l’on monte un Capacity Pool de 4TB en Premium, nous disposons d’une réserve de 4TB et d’un débit de 16000 Iops / 256 MBps à ventiler / partager entre différentes VM par le biais des volumes qui seront créés dans ce pool. Ainsi, si l’une de ces VM occupe tout le débit (i.e. le volume associé à la VM génère le débit max du pool), il n’y aura plus de débit disponible pour les VM voisines : c’est le principe des vases communiquants : ce que l’un prend, l’autre le perd. On parle alors de Qualité de service (QoS) automatique.

Et c’est l’intérêt de la solution par rapport aux comptes de stockage Azure dont la capacité & débit ne peuvent pas être partagés. Nous sommes avec Netapp Files dans une relation 1-n : le Capacity Pool peut être mutualisé entre différentes VM, permettant une optimisation financière certaine par rapport au modèle habituel. Qui plus est, il est possible de procéder à une qualité de service manuelle au sein d’un pool, afin de répartir manuellement, suivant les besoins, la bande passante du pool entre les différents volumes. Voyons cela de plus près !

Fonctionnement par défaut : qualité de service automatique

Comme pour la gestion des comptes de stockage managée Azure, ANF adopte un mode par défaut de qualité de service automatique. Cela signifie qu’il faut augmenter la taille du pool pour acquérir du débit supplémentaire, puis jongler avec les allocations de volumes pour s’assurer que le workflow ciblé bénéficie bien de ce surplus de débit, tout en étant capable d’allouer l’espace disque supplémentaire à d’autres VM sans qu’elles viennent perturber le traitement ciblé i.e. ces VM ne devront pas générer de débit IO en même temps.

Avec ce mode de fonctionnement, même si la mutualisation est un véritable atout, on reste sur un mode où il faut augmenter l’espace alloué pour leur faire bénéficier de plus de débit.

Mais là où ANF va plus loin, c’est qu’il permet de passer en mode manuel et donc nous laisse choisir sur quel volume affecter le débit.

Quota et débit des volumes avec Qualité de Service manuelle

Dans ce mode (en préversion depuis sept. 2020), il est possible de définir manuellement le débit du volume contenu dans un pool que l’on souhaite.

Prenons l’exemple d’un serveur SQL qui nécessite plusieurs volumes, chacun avec des caractéristiques et des besoins en performance différents :

• Data disk : 600MBps
• TLog disk : 200MBps
• Binaire : 32Mbps
• Backup : 128Mbps
• Tempdb : 512MBps

Soit 1472 MBps au total. En provisionnant un pool en ultra de 12TB, on obtient un débit max de 1536 MBps qui couvre le besoin et que l’on peut répartir manuellement entre les différents volumes qui seront créés dans ce pool.

L’équivalent en SSD premium aurait nécessité plus de 25TB :

• Un P70 pour le Data disk : 16TB
• Un P30 pour le TLog disk : 1TB
• Un P6 pour les Binaires : 64GB
• Un P15 pour les Sauvegardes : 256GB
• Un P60 pour la Tempdb : 8TB

Les accès

Les comptes de stockage ANF sont déployés dans un subnet dédié (délegate subnet), sans connectivité aucune avec les autres services Azure, ni internet. Chaque vnet ne peut contenir qu’un seul subnet délégué à ANF. Les accès depuis les vnet (peering) de la même région sont possibles, le global peering quant à lui n’est pas supporté : les accès depuis une région distante sont donc impossibles.

A noter que les fonctionnalités suivantes ne sont pas prises en charges :

• le routage de transit via le peering de réseau virtuel.
• NSG appliqué au subnet délégué
• UDR appliqué au subnet délégué
• Stratégies Azure
• Load-balancer
• …

Les accès aux volumes depuis les VM se font via les protocoles SMB & NFS. Il est possible depuis juillet 2020 de créer des volumes double protocoles, permettant ainsi l’accès simultané à un volume de VM Windows et Linux.

Il est intéressant de noter que ANF prend en charge RSS (receive-side-scaling). Lorsque l’option RSS est activée, tout le traitement des données de réception pour une connexion TCP particulière est partagé entre plusieurs vCPU. SMB multichannel est activé par défaut depuis Windows 2012. Quand SMB Multichannel est activé, un client SMB3 établit plusieurs connexions TCP au serveur SMB ANF sur une seule carte réseau qui prend en charge RSS.

Ainsi, les performances sont accrues grâce au support du SMB multichannel couplé aux cartes réseaux RSS. En revanche, ANF ne prend pas en charge SMB Direct (RDMA). Il sera donc recommandé de choisir des template de VM Azure prenant en charge RSS, inutile en revanche de déployer les templates de la serie H prenant en charge RDMA.

Astuce : pour savoir si RSS est activé sur une VM, il suffit d’exécuter la commande suivante : netsh interface tcp show global

 

Conclusion

ANF a son rôle à jouer dans des architectures mutualisées et promet de belles économies dans ce contexte. Nous verrons deux point capitaux lors de prochain posts : les performances et la comparaison des coûts face aux offres de stockage Azure classiques.