Optimiser les performances des disques persistants et des disques SSD locaux

Les disques persistants constituent l'option de stockage la plus courante en raison de leur prix, de leurs performances et de leur durabilité. Vous pouvez également choisir des disques SSD locaux, qui offrent des performances encore plus élevées et une latence moindre. Néanmoins, ils ne sont pas redondants et ne sont disponibles que pendant la durée de vie d'une instance spécifique. Lorsque vous configurez une option de stockage pour les applications qui s'exécutent sur vos instances, procédez comme suit :

  • Déterminez de combien d'espace vous avez besoin.
  • Déterminez le niveau de performances requis par vos applications.
  • Configurez vos instances pour optimiser les performances de stockage.

Les sections suivantes décrivent les options de stockage de blocs disponibles que vous pouvez associer à vos instances Compute Engine. Pour obtenir la liste complète des options de stockage sur Google Cloud Platform, consultez la page Produits Cloud Storage.

Comparer les performances des options de stockage de blocs

Définissez clairement vos besoins en matière d'espace disponible et de performances pour vous aider à déterminer le type et la taille de disque appropriés pour vos instances. Les exigences de performances pour une application donnée sont généralement séparées en deux modèles d'E/S distincts :

  • Opérations de lecture et d'écriture de petite taille
  • Opérations de lecture et d'écriture de taille importante

Pour les opérations de petite taille, le facteur limitant est le nombre aléatoire d'opérations d'entrées/sorties par seconde (IOPS).

Pour les opérations de lecture et d'écriture de grande taille, le facteur limitant est le débit.

Les valeurs d'IOPS par Go et de débit représentent le total des performances globales pour les données sur un seul disque, qu'elles soient associées à une seule instance ou partagées entre plusieurs instances. Si des opérations de lecture sont exécutées par plusieurs instances sur le même disque, le débit global et la capacité IOPS du disque sont partagés entre les instances. À des fins de planification, nous vous recommandons d'utiliser les valeurs de débit et d'IOPS par Go suivantes :

Disques
persistants
standards zonaux
Disques
persistants
standards régionaux
Disques
persistants
SSD zonaux
Disques
persistants
SSD régionaux
SSD local (SCSI) SSD local (NVMe)
Nombre maximal d'IOPS soutenues
IOPS par Go en lecture 0,75 0,75 30 30 266,7 453,3
IOPS par Go en écriture 1,5 1,5 30 30 186,7 240
IOPS par instance en lecture 3 000* 3 000* 15 000-60 000* 15 000-60 000* 400 000 680 000
IOPS par instance en écriture 15 000* 15 000* 15 000-30 000* 15 000-30 000* 280 000 360 000
Débit soutenu maximal (Mo/s)
Débit par Go en lecture 0,12 0,12 0,48 0,48 1,04 1,77
Débit par Go en écriture 0,12 0,12 0,48 0,48 0,73 0,94
Débit par instance en lecture 240* 240* 240-1 200* 240-1 200* 1 560 2 650
Débit par instance en écriture 76-240** 38-200** 76-400* 38-200* 1 090 1 400

* Les IOPS et performances de débit des disques persistants dépendent du nombre de processeurs virtuels de l'instance et de la taille des blocs d'E/S. Consultez les limites de performances des disques persistants SSD pour en savoir plus sur ce type de disques. Consultez également les limites de performances des disques persistants standards pour plus de détails à ce sujet.

** Les disques SSD et les disques persistants standards peuvent atteindre des performances de débit supérieures sur les instances comportant un plus grand nombre de processeurs virtuels. Consultez la section Plafonds de sortie réseau sur le débit d'écriture pour plus de détails.

Comparer un disque persistant à un disque dur physique

Lorsque vous spécifiez la taille de vos disques persistants, tenez compte des performances de ceux-ci par rapport aux disques durs physiques traditionnels. Les tableaux suivants comparent les disques persistants standards et les disques persistants SSD aux performances typiques que vous pouvez attendre d'un disque SATA à 7 200 tr/min, qui atteint généralement 75 IOPS ou 120 Mo/s.

Type d'E/S Modèle d'E/S Taille requise pour correspondre à un disque SATA à 7 200 tr/min
Disque persistant standard Disque persistant SSD
Lectures aléatoires de petite taille 75 lectures aléatoires de petite taille 100 Go 3 Go
Écritures aléatoires de petite taille 75 écritures aléatoires de petite taille 50 Go 3 Go
Lectures de grande taille en streaming 120 Mo/s de lectures en streaming 1 000 Go 250 Go
Écritures de grande taille en streaming 120 Mo/s d'écritures en streaming 1 000 Go 250 Go

Taille, prix et performances

Vous avez plusieurs éléments à prendre en compte lorsque vous sélectionnez un type et une taille de volume pour votre application, mais le coût lié à l'utilisation de votre volume de stockage n'en est pas un. Les disques persistants ne génèrent aucun coût par E/S. Il n'est donc pas nécessaire d'estimer les E/S mensuelles pour calculer votre budget disque. Néanmoins, vous pouvez analyser le coût mensuel des charges de travail axées IOPS à des fins de comparaison.

Les exemples de calcul des coûts suivants sont basés sur les tarifs américains des disques persistants. Dans ces exemples, vous devez considérer les coûts relatifs des disques persistants standards par rapport aux disques persistants SSD. Les disques persistants standards coûtent 0,040 $ par Go et les disques persistants SSD 0,170 $ par Go. L'augmentation de la taille d'un volume entraîne également l'augmentation automatique des plafonds de performances, sans frais supplémentaires.

Pour déterminer le coût par IOPS d'un disque persistant, divisez le prix par Go par mois par le nombre d'IOPS par Go. Le tableau suivant calcule le prix par IOPS en lecture aléatoire par Go. Vous pouvez également appliquer les mêmes calculs pour déterminer le prix par IOPS en écriture.

Type de disque Prix (par Go/mois) IOPS par Go en lecture Prix par IOPS par Go
Disque persistant standard 0,040 $ 0,75 0,040 $ / 0,75 = 0,0533 $
Disque persistant SSD 0,170 $ 30 0,170 $ / 30 = 0,2267 $

Les disques persistants SSD atteignent leur limite de 60 000 IOPS en lecture aléatoire à 2 000 Go, et leur limite de 30 000 IOPS en écriture aléatoire à 1 000 Go. En revanche, les disques persistants standards atteignent leur limite de 3 000 IOPS en lecture aléatoire à 4 To et leur limite de 15 000 IOPS en écriture aléatoire à 10 To.

Les disques persistants SSD sont conçus pour des latences de l'ordre de la milliseconde. Notons que les latences observées sont toujours spécifiques à l'application.

Disque persistant standard

Les performances des disques persistants évoluent de manière linéaire jusqu'aux limites de performances de la machine virtuelle (VM). La présence de quatre processeurs virtuels ou plus ne limite pas les performances des disques persistants standards.

En revanche, si votre instance dispose de moins de quatre processeurs virtuels, sa capacité en écriture sera limitée, car les limites de sortie réseau sont proportionnelles au nombre de processeurs virtuels. La limite de capacité d'écriture dépend également de la taille des E/S : des E/S à 16 Ko consomment plus de bande passante que des E/S à 8 Ko pour le même niveau d'IOPS.

Les performances en matière d'IOPS et de débit des disques persistants standards augmentent de manière linéaire avec la taille du disque en question, jusqu'à atteindre les limites par instance suivantes :

  • Débit de lecture : jusqu'à 240 Mo/s avec un disque de 2 To
  • Débit d'écriture : jusqu'à 240 Mo/s avec un disque de 2 To
  • IOPS en lecture : jusqu'à 3 000 IOPS avec un disque de 4 To
  • IOPS en écriture : jusqu'à 15 000 IOPS avec un disque de 10 To

Pour améliorer les performances des disques persistants de vos instances existantes, redimensionnez vos disques persistants pour augmenter leur nombre d'IOPS et leur débit.

Taille du volume (Go) IOPS aléatoires soutenues Débit soutenu (Mo/s)
Lecture
(<=16 Ko par E/S)
Écriture
(<=8 Ko par E/S)
Écriture
(16 Ko par E/S)
Lecture Écriture
10 * * * * *
32 24 48 48 3 3
64 48 96 96 7 7
128 96 192 192 15 15
256 192 384 384 30 30
512 384 768 768 61 61
1 000 750 1 500 1 500 120 120
1 500 1 125 2 250 2 250 180 180
2 048 1 536 3 072 3 072 240 240
4 000 3 000 6 000 6 000 240 240
5 000 3 000 7 500 7 500 240 240
8 192 3 000 12 288 7 500 240 240
10 000 3 000 15 000 7 500 240 240
16 384 3 000 15 000 7 500 240 240
32 768 3 000 15 000 7 500 240 240
65 536 3 000 15 000 7 500 240 240

* Nous vous conseillons de n'utiliser cette taille que pour les volumes de démarrage. L'utilisation intensive d'E/S offre des performances plus élevées pour les volumes de démarrage que le scaling linéaire décrit ici.

Disque persistant SSD

Les performances en termes d'IOPS des disques persistants SSD dépendent du nombre de processeurs virtuels dans l'instance, en plus de la taille du disque.

Les machines virtuelles comportant moins de cœurs ont des limites d'IOPS en écriture et de débit inférieures en raison des limitations du débit en écriture à la sortie réseau. Pour en savoir plus, consultez la section Plafonds de sortie réseau sur le débit d'écriture.

Les performances des disques persistants SSD évoluent de manière linéaire jusqu'à atteindre les limites du volume ou les limites de chaque instance Compute Engine. La cohérence de la bande passante en lecture SSD et/ou d'IOPS proche des limites maximales dépend en grande partie de l'utilisation de l'entrée réseau. Une certaine variabilité est à prévoir, en particulier pour les E/S de 16 Ko proches des limites maximales d'IOPS.

Nombre de processeurs virtuels par instance IOPS aléatoires soutenues Débit soutenu (Mo/s)
Lecture
(<=16 Ko par E/S)
Écriture
(<=8 Ko par E/S)
Écriture
(16 Ko par E/S)
Lecture* Écriture
1 processeur virtuel 15 000 9 000 4 500 240 72
2 à 3 processeurs virtuels 15 000 15 000 4 500/processeur virtuel 240 72/processeur virtuel
4 à 7 processeurs virtuels 15 000 15 000 15 000 240 240
8 à 15 processeurs virtuels 15 000 15 000 15 000 800 400
16 à 31 processeurs virtuels 25 000 25 000 25 000 1 200 400
32 à 63 processeurs virtuels 60 000 30 000 25 000 1 200 400
64 processeurs virtuels et plus** 60 000 30 000 25 000 1 200 400

* Débit maximal en se basant sur des tailles de bloc d'E/S de 256 Ko ou plus.

** Les performances maximales peuvent ne pas être atteintes lorsque le taux d'utilisation du processeur est à son maximum.

Pour améliorer les performances des disques persistants SSD de vos instances existantes, modifiez le type de machine de l'instance pour augmenter les limites par VM, et redimensionnez vos disques persistants pour augmenter leur nombre d'IOPS et leur débit.

Taille du volume (Go) IOPS aléatoires soutenues Débit soutenu (Mo/s)
Lecture
(<=16 Ko par E/S)
Écriture
(<=8 Ko par E/S)
Écriture
(16 Ko par E/S)
Lecture Écriture
10 300 300 300 4,8 4,8
32 960 960 960 15 15
64 1 920 1 920 1 920 30 30
128 3 840 3 840 3 840 61 61
256 7 680 7 680 7 680 122 122
500 15 000 15 000 15 000 240 240
834 25 000 25 000 25 000 400 400
1 000 30 000 30 000 25 000 480 400
1 334 40 000 30 000 25 000 640 400
1 667 50 000 30 000 25 000 800 400
2 048 60 000 30 000 25 000 983 400
4 096 60 000 30 000 25 000 1 200 400
8 192 60 000 30 000 25 000 1 200 400
16 384 60 000 30 000 25 000 1 200 400
32 768 60 000 30 000 25 000 1 200 400
65 536 60 000 30 000 25 000 1 200 400

Limites de disques C2

Les types de machines optimisés pour le calcul sont soumis à des limites de disque persistant spécifiques par processeur virtuel différentes des autres types de machines. Les tableaux suivants présentent ces limites.

Notez que les performances par volume restent identiques à celles décrites dans les sections Performances des disques standards et Performances des disques SSD.

Disque persistant standard
Nombre de processeurs virtuels par instance IOPS aléatoires soutenues Débit soutenu (Mo/s)
Lecture
(<=16 Ko par E/S)
Écriture
(<=8 Ko par E/S)
Écriture
(16 Ko par E/S)
Lecture* Écriture
4 processeurs virtuels 3 000 4 000 4 000 240 240
8 processeurs virtuels 3 000 4 000 4 000 240 240
16 processeurs virtuels 3 000 4 000 4 000 240 240
30 processeurs virtuels 3 000 8 000 8 000 240 240
60 processeurs virtuels 3 000 15 000 15 000 240 240
Disque persistant SSD
Nombre de processeurs virtuels par instance IOPS aléatoires soutenues Débit soutenu (Mo/s)
Lecture
(<=16 Ko par E/S)
Écriture
(<=8 Ko par E/S)
Écriture
(16 Ko par E/S)
Lecture* Écriture
4 processeurs virtuels 4 000 4 000 4 000 240 240
8 processeurs virtuels 4 000 4 000 4 000 240 240
16 processeurs virtuels 8 000 4 000 4 000 320 240
30 processeurs virtuels 15 000 8 000 8 000 600 240
60 processeurs virtuels 30 000 15 000 15 000 1 200 400

Lectures et écritures simultanées

Pour les disques persistants standards, les opérations simultanées de lecture et d'écriture partagent les mêmes ressources. Si votre instance dédie plus de débit ou d'IOPS aux opérations de lecture, elle est limitée en termes d'opérations d'écriture. À l'inverse, les instances qui utilisent plus de débit en écriture pourront effectuer moins d'opérations de lecture.

Les disques persistants SSD sont capables d'atteindre leur débit maximal à la fois pour les lectures et les écritures, ce qui n'est pas le cas pour les IOPS. Pour atteindre un débit maximal lors d'opérations simultanées de lecture et d'écriture, optimisez la taille des E/S afin d'atteindre les limites de débit sans créer de goulot d'étranglement IOPS.

Limites IOPS de l'instance pour les opérations simultanées de lecture et d'écriture :

Les nombres d'IOPS répertoriés dans le tableau suivant sont basés sur une taille d'E/S de 8 Ko. D'autres tailles d'E/S, telles que 16 Ko, peuvent générer des nombres d'IOPS différents, mais conserveront la même distribution en lecture/écriture.

Disque persistant standard Disque persistant SSD (8 processeurs virtuels) Disque persistant SSD (32 processeurs virtuels et plus)
Lecture Écriture Lecture Écriture Lecture Écriture
3 000 IOPS 0 IOPS 15 000 IOPS 0 IOPS 60 000 IOPS 0 IOPS
2 250 IOPS 3 750 IOPS 11 250 IOPS 3 750 IOPS 45 000 IOPS 7 500 IOPS
1 500 IOPS 7 500 IOPS 7 500 IOPS 7 500 IOPS 30 000 IOPS 15 000 IOPS
750 IOPS 11 250 IOPS 3 750 IOPS 11 250 IOPS 15 000 IOPS 22 500 IOPS
0 IOPS 15 000 IOPS 0 IOPS 15 000 IOPS 0 IOPS 30 000 IOPS

Limites de débit de l'instance pour les opérations simultanées de lecture et d'écriture :

Disque persistant standard Disque persistant SSD (8 processeurs virtuels) Disque persistant SSD (16 processeurs virtuels et plus)
Lecture Écriture Lecture Écriture Lecture Écriture
240 Mo/s 0 Mo/s 800 Mo/s* 400 Mo/s* 1 200 Mo/s* 400 Mo/s*
180 Mo/s 60 Mo/s
120 Mo/s 120 Mo/s
60 Mo/s 180 Mo/s
0 Mo/s 240 Mo/s

* Pour les disques persistants SSD, le débit de lecture maximal et le débit d'écriture maximal sont indépendants l'un de l'autre. Ces limites sont donc constantes. Vous constaterez peut-être une augmentation du débit d'écriture sur les disques persistants SSD par instance par rapport aux limites publiées ici, en raison d'améliorations continues du service.

Plafonds de sortie réseau sur le débit d'écriture

Chaque opération d'écriture sur le disque persistant se cumule et rapproche votre instance de machine virtuelle (VM) de son plafond de sortie réseau.

Pour calculer le trafic maximal en écriture qu'une instance de VM peut générer sur un disque persistant, soustrayez les autres trafics de sortie réseau d'une instance de son plafond réseau de 2 Gbit/s par processeur virtuel. Le débit restant représente le débit disponible pour le trafic d'écriture sur disque persistant.

Les disques persistants Compute Engine sont dotés d'une fonction de redondance intégrée. Pour obtenir cette redondance, les instances écrivent trois fois en parallèle les données sur le disque persistant. En outre, chaque demande d'écriture est associée à une certaine quantité de tâches annexes, qui consomment de la bande passante de sortie.

Chaque instance comporte une limite d'écriture sur le disque persistant basée sur le plafond de sortie réseau de la VM. Dans une situation où le disque persistant est en concurrence pour la sortie réseau avec le trafic IP, 60 % du plafond de trafic de sortie réseau est alloué au trafic du disque persistant, ce qui laisse 40 % pour le trafic IP. Le tableau suivant indique la bande passante en écriture attendue sur le disque persistant avec et sans trafic IP supplémentaire :

Disque persistant standard Disque persistant SSD
Nombre de processeurs virtuels Limite d'écriture (Mo/s) Limite d'allocation en écriture (Mo/s) Taille requise pour atteindre la limite (Go) Limite d'écriture (Mo/s) Limite d'allocation en écriture (Mo/s) Taille requise pour atteindre la limite (Go)
1 72 43 600 72 43 150
2 144 86 1 200 144 86 300
4 240 173 2 000 240 173 500
8+ 240 240 2 000 400 346 834

Pour comprendre comment les valeurs de ce tableau ont été calculées, prenons l'exemple d'un processeur virtuel et d'un disque persistant standard. Dans cet exemple, nous estimons que le multiplicateur de bande passante pour chaque demande d'écriture est de 3,3 x, ce qui signifie que les données sont écrites 3 fois avec un volume total de tâches annexes de 10 %. Pour calculer le plafond de sortie, divisons le plafond de sortie réseau (soit 2 Gbit/s, ce qui équivaut à 238 Mo/s) par 3,3 :

Bande passante d'écriture maximale pour un processeur virtuel = 238/3,3 = ~72 Mo/s sur votre disque persistant standard

En vous basant sur les valeurs de débit d'écriture (en Go) sur disque persistant standard, fournies dans le tableau de performances vu précédemment, vous pouvez également obtenir la capacité de disque requise pour atteindre ces performances :

Capacité de disque requise pour obtenir une bande passante d'écriture maximale pour un processeur virtuel = 72/0,12 = ~600 Go

Comme pour les disques persistants zonaux, le trafic en écriture à partir de disques persistants régionaux contribue au plafond de sortie réseau cumulé d'une instance de VM. Pour calculer la sortie réseau disponible pour les disques persistants régionaux, utilisez un facteur de 6,6.

Bande passante d'écriture maximale pour un processeur virtuel = 238/6,6 = ~36 Mo/s sur votre disque persistant standard répliqué

Optimiser les performances des disques persistants et des disques SSD locaux

Vous pouvez optimiser vos disques persistants et disques SSD locaux pour gérer vos données plus efficacement.

Optimiser les disques persistants

Les disques persistants vous offrent les performances décrites dans le tableau de comparaison des différents types de disques si la VM utilise suffisamment de ressources pour atteindre les plafonds de performances. Une fois que vous avez dimensionné les volumes de vos disques persistants en fonction des performances attendues, votre application et votre système d'exploitation peuvent nécessiter des ajustements.

Les sections suivantes décrivent quelques éléments clés qui peuvent être ajustés pour offrir de meilleures performances, et expliquent comment appliquer certains d'entre eux à des types de charges de travail spécifiques.

Désactiver l'initialisation différée et activer les commandes DISCARD

Les disques persistants sont compatibles avec les commandes DISCARD ou TRIM, qui permettent aux systèmes d'exploitation d'informer les disques lorsque les blocs ne sont plus utilisés. Cette compatibilité avec DISCARD permet au système d'exploitation de marquer des blocs de disque comme n'étant plus nécessaires, sans encourir le coût de leur mise à zéro.

Sur la plupart des systèmes d'exploitation Linux, vous activez DISCARD dès lors que vous installez un disque persistant sur votre instance. De même, les instances Windows 2012 R2 activent DISCARD par défaut lorsque vous installez un disque persistant. Windows 2008 R2, en revanche, n'est pas compatible avec DISCARD.

L'activation de DISCARD peut améliorer les performances d'exécution générales et peut également accélérer les performances de votre disque lors de sa première installation. Formater le volume entier d'un disque peut prendre du temps. Ainsi, il est courant de faire appel aux fameuses commandes "Lazy". L'inconvénient de cette pratique, c'est qu'on la paye souvent la première fois que le volume est installé. En désactivant l'initialisation différée et en activant les commandes DISCARD, vous pouvez augmenter la rapidité de vos formatages et installations.

  • Désactivez l'initialisation différée et activez DISCARD lors du formatage en transmettant les paramètres suivants à mkfs.ext4 :

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    Le paramètre lazy_journal_init=0 ne fonctionne pas sur les instances avec des images CentOS 6 ou RHEL 6. Pour ces instances, formatez les disques persistants sans ce paramètre.

    -E lazy_itable_init=0,discard
    
  • Activez les commandes DISCARD lors de l'installation, et transmettez l'indicateur suivant à la commande d'installation :

    -o discard
    

Les disques persistants présentent un fonctionnement optimal lorsque l'option discard est activée. Cependant, vous pouvez exécuter périodiquement fstrim en plus de l'option discard, ou en lieu et place de celle-ci. Si vous n'utilisez pas l'option discard, exécutez fstrim avant de créer un instantané de votre disque. L'ajustement du système de fichiers vous permet de créer des instantanés plus petits, ce qui réduit leur coût de stockage.

Profondeur de la file d'attente d'E/S

De nombreuses applications disposent de paramètres qui jouent sur la profondeur de la file d'attente d'E/S. La définition d'une profondeur plus importante augmente les IOPS, mais risque également d'accroître la latence. À l'inverse, une profondeur moindre réduit la latence par E/S, mais cela s'effectue parfois au détriment des IOPS.

Cache Readahead

Pour améliorer les performances d'E/S, les systèmes d'exploitation utilisent des techniques telles que readahead, qui consiste à lire une plus grande partie du fichier que nécessaire, en se basant sur l'idée que les lectures ultérieures sont susceptibles d'avoir besoin de ces données. Un cache readahead supérieur augmente le débit, mais au détriment de la mémoire et des IOPS. Un cache readahead plus faible augmente les IOPS, mais au détriment du débit.

Sur les systèmes Linux, vous pouvez obtenir et définir la valeur readahead avec la commande blockdev :

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

La valeur de readahead est égale à : <desired_readahead_bytes> / 512 octets.

Imaginons que vous désirez définir un readahead de 8 Mo. 8 Mo correspondent à 8 388 608 octets (8 * 1 024 * 1 024).

8388608 bytes / 512 bytes = 16384

Définissez la commande blockdev sur 16384 :

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

Processeurs disponibles

La lecture et l'écriture sur disque persistant consomment des cycles de processeur de votre VM. Pour atteindre des niveaux fiables et élevés d'IOPS, il est nécessaire de disposer de processeurs disponibles pour traiter les E/S.

Charges de travail axées IOPS

Les bases de données, qu'elles soient de type SQL ou NoSQL, présentent des modèles d'accès aux données aléatoires. Google recommande les valeurs suivantes pour les charges de travail axées IOPS :

  • Définissez les valeurs de profondeur de file d'attente d'E/S sur 1 pour 400 à 800 IOPS, sans dépasser 64 sur les volumes importants.

  • Prévoyez un processeur disponible tous les 2 000 IOPS en lecture aléatoire et un processeur disponible tous les 2 500 IOPS en écriture aléatoire.

Abaissez le cache readahead aux valeurs généralement suggérées dans les bonnes pratiques pour MongoDB, Apache Cassandra et les autres applications de base de données.

Charges de travail orientées débit

Les opérations de streaming, telles qu'une tâche Hadoop, bénéficient de lectures séquentielles rapides. De ce fait, des tailles d'E/S plus importantes peuvent augmenter les performances de diffusion. Pour les charges de travail orientées débit, des valeurs d'E/S de 256 Ko ou plus sont recommandées.

Optimiser les performances des disques persistants SSD

Le tableau des performances par type de disque décrit les performances maximales attendues et réalisables pour les disques persistants SSD. Pour optimiser vos applications et instances de VM afin d'atteindre ces vitesses, conformez-vous aux bonnes pratiques suivantes :

  • Assurez-vous que votre application génère suffisamment d'E/S

    Si votre application génère moins d'IOPS que la limite décrite dans le tableau ci-dessus, vous n'atteindrez pas ce niveau d'IOPS. Par exemple, sur un disque de 500 Go, la limite attendue s'élève à 15 000 IOPS. Toutefois, si vous en générez moins ou si vous émettez des opérations d'E/S supérieures à 8 Ko, vous n'atteindrez pas 15 000 IOPS.

  • Veillez à fournir des E/S avec suffisamment de parallélisme

    Utilisez une profondeur de file d'attente suffisamment élevée pour tirer parti du parallélisme du système d'exploitation. Si vous émettez 1­  ­000 IOPS de manière synchrone et avec une profondeur de file d'attente de 1, vous obtiendrez beaucoup moins d'IOPS que la limite décrite dans le tableau. Votre application doit présenter au minimum une profondeur de file d'attente de 1 pour 400 à 800 IOPS.

  • Assurez-vous d'avoir suffisamment de processeurs disponibles sur l'instance émettant les E/S

    Si votre instance de VM manque de ressources de processeur, votre application ne pourra pas gérer les taux d'IOPS décrits ci-dessus. Nous vous recommandons d'avoir un processeur disponible pour 2 000 à 2 500 IOPS de trafic attendu.

  • Assurez-vous que votre application est optimisée pour offrir une localité temporelle des données raisonnable sur les disques de grande capacité

    Si votre application accède à des données réparties sur différentes parties d'un disque sur une courte période (à raison de plusieurs centaines de Go par processeur virtuel), vous n'atteindrez pas les valeurs IOPS optimales. Pour des performances maximales, optimisez la localité temporelle des données et des facteurs de pondération tels que la fragmentation du disque et le caractère aléatoire des parties du disque consultées.

  • Assurez-vous que le programmeur d'E/S du système d'exploitation est configuré pour répondre à vos besoins spécifiques

    Sur les systèmes Linux, vous pouvez paramétrer le programmeur d'E/S sur noop pour obtenir le plus grand nombre d'IOPS sur les périphériques exploitant un disque SSD.

Effectuer l'analyse comparative des performances d'un disque persistant SSD

Les commandes ci-dessous prennent l'exemple d'un disque persistant SSD de 2 500 Go. Si la taille de votre disque est différente, modifiez la valeur de l'argument --filesize. Cette taille de disque est nécessaire pour atteindre les limites de débit de 32 processeurs virtuels par VM.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Remplissez le disque avec des données non nulles. Les lectures à partir de blocs vides ont un profil de latence différent des lectures de blocs contenant des données. Nous vous recommandons donc de remplir le disque avant de lancer des analyses comparatives de latence de lecture.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Testez la bande passante en écriture à l'aide d'écritures séquentielles comportant plusieurs flux parallèles (plus de 8). Prévoyez une taille d'E/S de 1 Mo et une profondeur d'E/S égale ou supérieure à 64.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=write --numjobs=8 --offset_increment=100G
    
  3. Testez les IOPS en écriture. Pour atteindre le nombre maximal d'IOPS des disques persistants, vous devez conserver une file d'attente d'E/S de grande profondeur. Par exemple, si la latence d'écriture est de 1 milliseconde, la VM peut atteindre au maximum 1 000 IOPS pour chaque E/S en cours de transfert. Pour atteindre 15 000 IOPS, la VM doit maintenir au moins 15 E/S. Si votre disque et votre VM peuvent atteindre 30 000 IOPS, le nombre d'E/S en cours de transfert doit être d'au moins 30 E/S. Si la taille des E/S est supérieure à 4 Ko, il est possible que la VM atteigne la limite de bande passante avant d'atteindre la limite d'IOPS.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Testez la latence en écriture. Lors du test de la latence par E/S, la VM ne doit pas atteindre la limite de bande passante ou d'IOPS, sinon la latence observée ne reflétera pas la latence réelle des E/S du disque persistant. Par exemple, si la limite d'IOPS est atteinte avec une profondeur d'E/S de 30 et que la commande fio présente le double de cette valeur, alors le total d'IOPS reste le même et la latence d'E/S rapportée double.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Testez la bande passante en lecture à l'aide de lectures séquentielles comportant plusieurs flux parallèles (plus de 8). Prévoyez une taille d'E/S de 1 Mo et une profondeur d'E/S égale ou supérieure à 64.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=read --numjobs=8 --offset_increment=100G
    
  6. Testez les IOPS en lecture. Pour atteindre le nombre maximal d'IOPS des disques persistants, vous devez conserver une file d'attente d'E/S de grande profondeur. Si la taille des E/S est supérieure à 4 Ko, il est possible que la VM atteigne la limite de bande passante avant d'atteindre la limite d'IOPS.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randread
    
  7. Testez la latence en lecture. Il est important de remplir le disque avec des données afin d'obtenir une mesure de latence réaliste. Il est important que la VM n'atteigne pas les limites d'IOPS ou de débit lors de ce test : une fois que le disque persistant atteint sa limite de saturation, il repousse toute E/S, ce qui se traduit par une augmentation artificielle de la latence des E/S.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Testez la bande passante en lecture séquentielle.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=read
    
  9. Testez la bande passante en écriture séquentielle.

    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=write
    

Optimiser les disques SSD locaux

Le tableau des performances par type de disque décrit les performances maximales réalisables pour les disques SSD locaux. Pour optimiser vos applications et instances de VM afin d'atteindre ces vitesses, conformez-vous aux bonnes pratiques suivantes :

Utilisez les optimisations pour les disques SSD locaux de l'environnement invité

Par défaut, la plupart des images Linux fournies par Compute Engine exécutent automatiquement un script d'optimisation qui configure l'instance pour des performances maximales des disques SSD locaux. Ce script active certains paramètres des fichiers de file d'attente sysfs, qui améliorent les performances globales de votre machine et masquent les requêtes d'interruption (IRQ) sur des processeurs virtuels spécifiques. Ce script optimise uniquement les performances des périphériques SSD locaux Compute Engine.

Ubuntu, SLES et d'autres images plus anciennes peuvent ne pas fournir cette optimisation des performances. Si vous utilisez l'une de ces images ou une image antérieure à v20141218, vous pouvez installer l'environnement invité pour activer ces optimisations.

Sélectionnez la meilleure image pour les interfaces NVMe ou SCSI

Les disques SSD locaux fonctionnent avec l'interface NVMe ou SCSI. La meilleure option dépend du système d'exploitation que vous utilisez. Choisissez une interface pour vos périphériques SSD locaux qui donnera des résultats optimaux avec votre image de disque de démarrage. Si vos instances se connectent à des disques SSD locaux à l'aide d'interfaces SCSI, vous pouvez activer le mode SCSI à files d'attente multiples sur le système d'exploitation invité, afin d'obtenir des performances optimales sur l'interface SCSI.

Activez le mode SCSI à files d'attente multiples sur des instances dotées d'images personnalisées et de disques SSD locaux

Certaines images publiques sont compatibles avec le mode SCSI à files d'attente multiples. Si vous avez besoin de cette capacité pour des images personnalisées que vous importez dans votre projet, vous devez l'activer vous-même. Vos images Linux importées ne peuvent utiliser le mode SCSI à files d'attente multiples que si elles incluent la version de noyau 3.19 ou ultérieure.

Pour activer le mode SCSI à files d'attente multiples sur une image personnalisée, importez l'image en activant la fonctionnalité de système d'exploitation invité VIRTIO_SCSI_MULTIQUEUE et ajoutez une entrée à votre configuration GRUB :

CentOS

Pour CentOS7 uniquement.

  1. Importez votre image personnalisée à l'aide de l'API, et incluez un élément guestOsFeatures avec une valeur type de VIRTIO_SCSI_MULTIQUEUE.

  2. Créez une instance à l'aide de votre image personnalisée et associez un ou plusieurs disques SSD locaux.

  3. Connectez-vous à votre instance via SSH.

  4. Vérifiez la valeur du fichier /sys/module/scsi_mod/parameters/use_blk_mq

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Si la valeur de ce fichier est Y, le mode SCSI à files d'attente multiples est déjà activé sur votre image importée. Si la valeur du fichier est N, incluez scsi_mod.use_blk_mq=Y dans l'entrée GRUB_CMDLINE_LINUX de votre fichier de configuration GRUB et redémarrez le système.

    1. Ouvrez le fichier de configuration GRUB /etc/default/grub dans un éditeur de texte.

      $ sudo vi /etc/default/grub
      
    2. Ajoutez scsi_mod.use_blk_mq=Y à l'entrée GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX=" vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16 scsi_mod.use_blk_mq=Y"
      
    3. Enregistrez le fichier de configuration.

    4. Exécutez la commande grub2-mkconfig pour régénérer le fichier GRUB et terminer la configuration.

      $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
      
    5. Redémarrez l'instance.

      $ sudo reboot
      

Ubuntu

  1. Importez votre image personnalisée à l'aide de l'API, et incluez un élément guestOsFeatures avec une valeur type de VIRTIO_SCSI_MULTIQUEUE.

  2. Créez une instance à l'aide de votre image personnalisée et associez un ou plusieurs disques SSD locaux via l'interface SCSI.

  3. Connectez-vous à votre instance via SSH.

  4. Vérifiez la valeur du fichier /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Si la valeur de ce fichier est Y, le mode SCSI à files d'attente multiples est déjà activé sur votre image importée. Si la valeur du fichier est N, incluez scsi_mod.use_blk_mq=Y dans l'entrée GRUB_CMDLINE_LINUX de votre fichier de configuration GRUB et redémarrez le système.

    1. Ouvrez le fichier de configuration GRUB sudo nano /etc/default/grub dans un éditeur de texte.

      $ sudo nano /etc/default/grub
      
    2. Ajoutez scsi_mod.use_blk_mq=Y à l'entrée GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=Y"
      
    3. Enregistrez le fichier de configuration.

    4. Exécutez la commande update-grub pour régénérer le fichier GRUB et terminer la configuration.

      $ sudo update-grub
      
    5. Redémarrez l'instance.

      $ sudo reboot
      

Désactivez le vidage du cache en écriture

Les systèmes de fichiers, les bases de données et d'autres applications utilisent le vidage du cache pour garantir un stockage durable des données à différents points de contrôle. Pour la plupart des périphériques de stockage, ce paramètre par défaut est très pertinent. Cependant, les vidages de cache en écriture sont assez lents sur les disques SSD locaux. Vous pouvez augmenter les performances d'écriture pour certaines applications en désactivant les commandes de vidage automatique dans ces applications, ou en désactivant les options de vidage au niveau du système de fichiers.

Les disques SSD locaux vident toujours les écritures mises en cache en moins de deux secondes, quelles que soient les commandes de vidage que vous définissez pour vos systèmes de fichiers et vos applications. Vous ne perdrez ainsi pas plus de deux secondes d'écritures mises en cache en cas de défaillance matérielle temporaire. Cependant, des pannes matérielles sévères peuvent toujours entraîner la perte de toutes les données stockées sur l'appareil, qu'elles aient été vidées ou non. Vous devez donc toujours sauvegarder les données critiques sur des disques persistants ou des buckets Cloud Storage.

Pour désactiver le vidage du cache en écriture sur les systèmes de fichiers ext4, incluez la commande nobarrier dans vos options d'installation ou dans vos entrées /etc/fstab. Exemple :

$ sudo mount -o discard,defaults,nobarrier /dev/[LOCAL_SSD_ID] /mnt/disks/[MNT_DIR]

[LOCAL_SSD_ID] correspond à l'ID d'appareil du disque SSD local que vous souhaitez installer, et [MNT_DIR] au répertoire d'installation.

Effectuer l'analyse comparative des performances d'un disque SSD local

Les niveaux de performances d'un disque SSD local décrits dans la section Performances ont été obtenus à l'aide de paramètres spécifiques sur l'instance SSD locale. Si votre instance a des difficultés à atteindre ces limites de performances alors que vous l'avez déjà configurée conformément aux paramètres de disque SSD local recommandés, vous pouvez comparer vos limites de performances aux limites publiées en répliquant les paramètres utilisés par l'équipe Compute Engine.

  1. Créez une instance SSD locale dotée de quatre ou huit processeurs virtuels pour chaque appareil, en fonction de votre charge de travail. Par exemple, si vous souhaitez associer quatre périphériques SSD locaux à une instance, utilisez un type de machine doté de 16 ou 32 processeurs virtuels.

    La commande suivante crée une VM avec huit processeurs virtuels et un seul disque SSD local :

    gcloud compute instances create ssd-test-instance \
    --machine-type "n1-standard-8" \
    --local-ssd interface="SCSI"
    
  2. Exécutez le script suivant sur votre VM. Il réplique les paramètres utilisés pour atteindre les niveaux de performances des disques SSD locaux décrits dans la section Performances. Notez que le paramètre --bs définit la taille du bloc, ce qui affecte les résultats pour les différents types d'opérations de lecture et d'écriture.

    # install dependencies
    sudo apt-get update -y
    sudo apt-get install -y build-essential git libtool gettext autoconf \
    libgconf2-dev libncurses5-dev python-dev fio bison autopoint
    
    # blkdiscard
    git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
    cd util-linux/
    ./autogen.sh
    ./configure --disable-libblkid
    make
    sudo mv blkdiscard /usr/bin/
    sudo blkdiscard /dev/disk/by-id/google-local-ssd-0
    
    # full write pass - measures write bandwidth with 1M blocksize
    sudo fio --name=writefile --size=100G --filesize=100G \
    --filename=/dev/disk/by-id/google-local-ssd-0 --bs=1M --nrfiles=1 \
    --direct=1 --sync=0 --randrepeat=0 --rw=write --refill_buffers --end_fsync=1 \
    --iodepth=200 --ioengine=libaio
    
    # rand read - measures max read IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randread --blocksize=4k --group_reporting
    
    # rand write - measures max write IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randwrite --blocksize=4k --group_reporting
    

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine