La migration d'une instance SQL Server locale vers une machine virtuelle (VM) Azure est une méthode courante de migration vers Azure. Les professionnels de l'informatique sont habitués à déterminer la taille des machines virtuelles en termes de vCPU, de mémoire et de capacité de stockage. Microsoft propose plusieurs types et tailles de machines virtuelles pour les besoins d'une organisation. Vous verrez les types référencés comme Family dans le portail Azure lors du dimensionnement d'une machine virtuelle.
Types et tailles de machines virtuelles
Microsoft a contribué à simplifier les choses en créant plusieurs types de machines virtuelles. Les types visent à définir les machines par objectif. Les différents types sont :
- Usage général :rapport CPU/mémoire équilibré, bases de données petites à moyennes
- Optimisation du calcul :ratio CPU/mémoire élevé, serveurs Web et serveurs d'applications à trafic moyen
- Mémoire optimisée – Rapport mémoire/processeur élevé, serveurs de bases de données relationnelles, caches moyens à grands et analyses en mémoire
- Stockage optimisé – Débit de disque et E/S élevés
- GPU – Rendu graphique lourd et montage vidéo
- Calcul haute performance – Machines virtuelles CPU les plus rapides et les plus puissantes
Dans chaque type/famille, il existe de nombreuses tailles parmi lesquelles choisir. Les tailles vous offrent des options pour le nombre de vCPU, de RAM et de disques de données. Le nombre de disques de données déterminera le maximum d'IOPS (IOPS signifie opérations d'entrée/sortie par seconde.) et la taille globale déterminera la quantité de stockage temporaire disponible. Certaines tailles prennent également en charge le stockage premium, ce qui devrait être une exigence pour un SQL Server de production.
Options d'image de machine virtuelle
Lors de la sélection d'une image pour SQL Server, plusieurs options s'offrent à vous. Vous pouvez choisir de sélectionner uniquement le système d'exploitation, tel que Linux ou Windows, ou vous pouvez choisir de sélectionner une image avec le système d'exploitation et SQL Server déjà installés. Actuellement, je préfère choisir l'image avec uniquement le système d'exploitation afin de pouvoir installer SQL Server et le configurer comme je le souhaite. Lorsque vous choisissez l'image de la galerie avec SQL Server préinstallé, tous les composants inclus dans l'ISO pour cette version sont installés, et je n'ai pas toujours besoin d'installer Integration Services ou Analysis Services.
Considérations relatives au dimensionnement des VM
La sélection d'une machine virtuelle Azure peut sembler simple, avec le choix d'une taille basée sur le nombre de vCPU, la mémoire et suffisamment de stockage pour contenir vos bases de données, mais je vois des clients ayant des problèmes de performances liés au stockage. La tendance courante est de choisir une machine virtuelle basée exclusivement sur le vCPU, la mémoire et la capacité de stockage sans comparer les exigences actuelles en matière d'E/S et de débit. Lorsque vous créez une machine virtuelle Azure dans le portail Azure, vous pouvez filtrer les options en fonction des éléments suivants :
- Taille
- Génération
- Famille
- RAM/mémoire
- Prise en charge du stockage Premium
- Nombre de vCPU
- Disque de système d'exploitation éphémère
Une fois que vous avez sélectionné vos options de filtrage, le cas échéant, vous verrez une liste des serveurs disponibles. Dans la liste, il affiche la taille de la machine virtuelle, l'offre, la famille, le vCPU, la RAM, le nombre de disques de données pris en charge, les IOPS max, le stockage temporaire (D :), si le disque premium est pris en charge et le coût estimé. J'ai filtré les éléments suivants sur le disque premium pris en charge et la taille commençant par la lettre E pour une mémoire optimisée.
Ce qui n'est pas affiché, cependant, c'est le débit autorisé par machine virtuelle. Le débit mesure le taux de transfert de données vers et depuis le support de stockage en mégaoctets par seconde.
Le débit peut être calculé à l'aide de la formule suivante
Mo/s =IOPS * Ko par IO / 1 024
En utilisant cette formule, KB par IO serait la taille de votre bloc. Si vous formatez vos données et vos lecteurs de journaux à 64 000, la formule pour les machines virtuelles E2s_v3, E4-2s_v3 et E8-2s_v3 avec 3 200, 6 400 et 12 800 IOPS serait :
Mo/s =3 200 * 64/1 024 ou 200 Mo/s
Mo/s =6 400 * 64/1 024 ou 400 Mo/s
Mo/s =12 800 * 64/1 024 ou 800 Mo/s
Les calculs de débit basés sur les IOPS de chaque machine virtuelle avec une taille de bloc de 64k ne sont pas trop mauvais. Ces chiffres ne tiennent pas compte des pénalités d'écriture pour RAID. J'ai testé chacune de ces machines virtuelles à l'aide de CrystalDiskMark. Les chiffres que j'ai obtenus pour le débit étaient loin de ce que les calculs estimaient.
Test de référence
J'ai provisionné trois machines virtuelles de la même famille, mais de tailles différentes, et chacune avec 2 vCPU. Les spécifications des machines virtuelles étaient :
- E2s_v3 – 2 vCPU – 16 Go de RAM – 3 200 IOPS – Prend en charge jusqu'à 4 disques de données
- E4-2s_v3 – 2 vCPU – 32 Go de RAM – 6 400 IOPS – Prend en charge jusqu'à 8 disques de données
- E8-2s_v3 – 2 vCPU – 64 Go de RAM – 12 800 IOPS – Prend en charge jusqu'à 16 disques de données
- Disque de données P60 – SSD Premium – 16 000 IOPS
Sur chaque machine virtuelle, j'ai provisionné un disque premium P60 d'une capacité de 8 To. Ce disque annonçait 16 000 IOPS qui, avec une taille de bloc de 64 000 octets, pouvait prendre en charge un débit de 1 000 Mo/s, mais la documentation Azure indique que le disque fournit un débit de 500 Mo/s.
CrystalDiskMark est un outil de référence de lecteur de disque open source pour Windows, basé sur l'outil Diskspd de Microsoft. L'outil mesure les performances séquentielles et aléatoires des lectures et des écritures.
En haut de l'outil se trouvent des menus déroulants. Le nombre 5 est le nombre d'itérations du test qui seront exécutées. Vient ensuite 1 Go, c'est la taille du fichier de test. Pour un test de production réel, cela devrait être suffisamment grand pour éviter de heurter le cache. La version 7.0 prend en charge un fichier jusqu'à 64 Gio. Le dernier est le lecteur sur lequel vous souhaitez effectuer le test.
Une fois que vous avez fait votre sélection, vous pouvez cliquer sur Tout pour commencer la série de tests. Le test effectuera une boucle sur diverses opérations de lecture/écriture séquentielles et aléatoires. Soyez prudent si vous envisagez de comparer de vrais serveurs de production. Ce test met une charge sur votre disque et peut avoir un impact considérable sur une charge de travail de production. Après les heures ou pendant une fenêtre de maintenance serait préférable.
J'ai choisi d'exécuter 5 itérations du test avec un fichier de 32 Gio sur le disque P60 qui était le lecteur E :.
La machine virtuelle E2s_v3 a atteint un maximum de moins de 50 Mo/s, ce qui est bien inférieur aux 200 Mo que nous avons calculés.
La machine virtuelle E4-2s_v3 a atteint un maximum de moins de 100 Mbps au lieu de 400 Mbps.
La machine virtuelle E8-2s_v3 a atteint un maximum de moins de 200 Mbps au lieu des 800 Mbps estimés.
Pourquoi réduire le débit ?
D'après mes calculs précédents, 3 200 IOPS à une taille de bloc de 64 000 devraient produire un débit de 200 Mo, mais je n'ai pas vu de chiffres proches de cela jusqu'à ce que j'aie un disque de 16 000 IOPS sur une machine virtuelle prenant en charge jusqu'à 12 800 IOPS. Le raisonnement est que chaque taille de machine virtuelle a une limite de débit. Si vous consultez la documentation de la famille de machines virtuelles à mémoire optimisée, vous constaterez que le débit maximal du disque non mis en cache de l'E2 est de 3 200 IOPS/48 Mo/s, le débit maximal du disque non mis en cache de l'E4 est de 6 400 IOPS/96 Mo/s et le débit maximal du disque non mis en cache de l'E8. le débit est de 12 800 IOPS / 192 Mbps. Ces chiffres coïncident avec les résultats que j'ai obtenus avec CrystalDiskMark.
Même si vous pouvez allouer de très grands disques qui ont beaucoup d'IOPS et qui prennent en charge des débits élevés, la taille de la machine virtuelle pourrait très bien limiter votre débit.
L'analyse comparative de vos besoins actuels en matière de débit doit être une grande priorité avant de migrer toute charge de travail SQL Server vers Azure.
Conclusion
Je comprends que l'IOPS est une unité de mesure fournie par les fabricants de disques et les fournisseurs de stockage, et c'est correct. Cependant, lorsqu'il s'agit de tester le stockage, nous avons tendance à nous concentrer davantage sur les chiffres de débit. Ce n'est qu'un problème mathématique, mais à moins que vous ne soyez dans le domaine de l'analyse comparative du stockage et que vous effectuiez les calculs des IOPS au débit en fonction de la taille des blocs, cela peut prêter à confusion.
Ce qui me dérange, c'est le fait que la restriction de débit n'est pas claire lorsque vous sélectionnez une taille de machine virtuelle. L'unité de mesure des E/S de stockage est IOPS. À 3 200 IOPS avec une taille de bloc de 64 000, je pouvais être à environ 200 Mbps, mais ma machine virtuelle était limitée à 48 Mbps. De nombreux professionnels de l'informatique ont découvert qu'ils avaient des problèmes de performances de disque et ont fait évoluer leur stockage vers un disque plus grand et plus rapide (plus d'IOPS) en espérant de meilleures performances, pour constater que cela ne résolvait pas leur problème. Le problème est que la taille de la machine virtuelle limitait leur débit. La mise à l'échelle vers une machine virtuelle de taille supérieure résoudrait le problème, mais cela a un coût. Dans mon exemple, l'E4 coûtait deux fois plus cher que l'E2, mais il doublait la mémoire et le débit, tout en conservant le même vCPU. L'E8 coûtait le double de l'E4 et doublait le débit et la mémoire, tout en conservant le même vCPU. Le maintien du même nombre de vCPU signifie que je n'aurais pas d'augmentation du coût de la licence SQL Server principale.
En fin de compte, vous devez comparer vos exigences de débit actuelles et vous assurer que vous dimensionnez la machine virtuelle Azure ou toute machine virtuelle de manière appropriée pour vos besoins. Ne vous concentrez pas uniquement sur une référence de votre stockage local, analysez ce dont votre charge de travail a besoin et dimensionnez-la en conséquence.
