🥇Comment vérifier les disques avec fio pour des performances suffisantes pour etcd

Noter. trad.: Cet article est le résultat d'une mini-recherche menée par des ingénieurs d'IBM Cloud à la recherche d'une solution à un problème réel lié au fonctionnement de la base de données etcd. Une tâche similaire était pertinente pour nous, cependant, le cheminement des réflexions et des actions des auteurs peut être intéressant dans un contexte plus large.

Bref résumé de l'intégralité de l'article : fio et etcd

Les performances d'un cluster etcd dépendent fortement de la vitesse du stockage sous-jacent. etcd exporte diverses métriques Prometheus pour surveiller les performances. L'un d'eux est wal_fsync_duration_seconds. Dans la documentation d'etcd ditce stockage peut être considéré comme suffisamment rapide si le 99e centile de cette métrique ne dépasse pas 10 ms…

Si vous envisagez de configurer un cluster etcd sur des machines Linux et que vous souhaitez vérifier si les disques (tels que les SSD) sont suffisamment rapides, nous vous recommandons d'utiliser le testeur d'E/S populaire appelé fio. Il suffit de lancer la commande suivante (répertoire test-data doit être situé dans la partition montée du lecteur testé) :

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Il ne reste plus qu'à regarder la sortie et à vérifier si le 99e centile correspond fdatasync en 10 ms. Si tel est le cas, votre lecteur fonctionne assez rapidement. Voici un exemple de sortie :

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Quelques notes:

Dans l'exemple ci-dessus, nous avons ajusté les paramètres --size и --bs pour un cas précis. Pour obtenir un résultat significatif de fio, spécifiez des valeurs adaptées à votre cas d'utilisation. Comment les choisir sera discuté ci-dessous.
Pendant les tests uniquement fio charge le sous-système de disque. Dans la vraie vie, il est probable que d'autres processus écrivent sur le disque (en plus de ceux liés à wal_fsync_duration_seconds). Cette charge supplémentaire peut augmenter wal_fsync_duration_seconds. En d'autres termes, si le 99e centile des tests avec fio, seulement un peu moins de 10 ms, il y a de fortes chances que les performances de stockage ne soient pas suffisantes.
Pour le test, vous aurez besoin de la version fio au moins 3.5, car les anciennes versions ne regroupent pas les résultats fdatasync sous forme de centiles.
La conclusion ci-dessus n'est qu'un petit extrait de la conclusion générale fio.

En savoir plus sur fio et etcd

Quelques mots sur les WAL etcd

Généralement, les bases de données utilisent journalisation proactive (journalisation en écriture anticipée, WAL). etcd est également affecté. Une discussion sur les WAL dépasse le cadre de cet article, mais pour nos besoins, ce que vous devez savoir, c'est que chaque membre du cluster etcd stocke les WAL dans un stockage persistant. etcd écrit certaines opérations de stockage clé-valeur (telles que les mises à jour) dans WAL avant de les exécuter. Si un nœud plante et redémarre entre les instantanés, etcd peut récupérer les transactions depuis l'instantané précédent en se basant sur le contenu du WAL.

Ainsi, chaque fois qu'un client ajoute une clé au magasin KV ou met à jour la valeur d'une clé existante, etcd ajoute la description de l'opération au WAL, qui est un fichier normal dans le magasin persistant. etcd DOIT être sûr à 100% que l'entrée WAL a bien été sauvegardée avant de continuer. Pour y parvenir sous Linux, il ne suffit pas d'utiliser l'appel système write, car l'opération d'écriture elle-même sur le support physique peut être retardée. Par exemple, Linux peut conserver une entrée WAL dans un cache du noyau en mémoire (par exemple, dans le cache de la page) pendant un certain temps. Pour s'assurer que les données sont écrites sur le support, un appel système doit être appelé après l'écriture fdatasync - c'est exactement ce que fait etcd (comme vous pouvez le voir dans la sortie suivante strace; Ici 8 - Descripteur de fichier WAL) :

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Malheureusement, écrire sur un stockage persistant prend un certain temps. L'exécution prolongée d'appels fdatasync peut affecter les performances d'etcd. Dans la documentation du référentiel est indiqué, que pour des performances suffisantes, il est nécessaire que le 99e centile de la durée de tous les appels fdatasync lors de l'écriture dans un fichier WAL était inférieure à 10 ms. Il existe d'autres métriques liées au stockage, mais cet article se concentrera sur celle-là.

Valoriser le stockage avec fio

Vous pouvez évaluer si un certain stockage convient à une utilisation avec etcd à l'aide de l'utilitaire fio — un testeur d'E/S populaire. Gardez à l'esprit que les E/S de disque peuvent se produire de différentes manières : synchronisation/asynchrone, de nombreuses classes d'appel système différentes, etc. Le revers de la médaille est que fio extrêmement difficile à utiliser. L'utilitaire a de nombreux paramètres et différentes combinaisons de leurs valeurs conduisent à des résultats complètement différents. Afin d'obtenir une estimation raisonnable pour etcd, vous devez vous assurer que la charge d'écriture générée par fio est aussi proche que possible de la charge d'écriture du fichier WAL d'etcd :

Cela signifie que le produit généré fio la charge doit être au moins une série d'écritures consécutives dans le fichier, où chaque écriture consiste en un appel système writesuivie par fdatasync.
Pour activer l'écriture séquentielle, vous devez spécifier le drapeau --rw=write.
Que fio écrit à l'aide d'appels write (plutôt que d'autres appels système - par exemple, pwrite), utilisez le drapeau --ioengine=sync.
Enfin, le drapeau --fdatasync=1 assure que chaque write devrait fdatasync.
Les deux autres paramètres de notre exemple sont : --size и --bs - peut varier en fonction du cas d'utilisation spécifique. La section suivante décrira leur configuration.

Pourquoi nous avons choisi fio et comment nous avons appris à le configurer

Cette note provient d'un cas réel que nous avons rencontré. Nous avions un cluster sur Kubernetes v1.13 avec une surveillance sur Prometheus. Les SSD ont été utilisés comme stockage pour etcd v3.2.24. Les métriques Etcd ont montré des latences trop élevées fdatasync, même lorsque le cluster était inactif. Pour nous, ces mesures semblaient très douteuses et nous ne savions pas exactement ce qu'elles représentaient. De plus, le cluster était composé de machines virtuelles, il n'était donc pas possible de dire si le retard était dû à la virtualisation ou si le SSD était à blâmer.

De plus, nous avons envisagé divers changements dans la configuration matérielle et logicielle, nous avions donc besoin d'un moyen de les évaluer. Bien sûr, il serait possible d'exécuter etcd dans chaque configuration et d'examiner les métriques Prometheus correspondantes, mais cela nécessiterait des efforts considérables. Ce dont nous avions besoin était un moyen simple d'évaluer une configuration spécifique. Nous voulions tester notre compréhension des métriques Prometheus provenant d'etcd.

Cela nécessitait de résoudre deux problèmes :

Tout d'abord, à quoi ressemble la charge d'E/S générée par etcd lors de l'écriture dans des fichiers WAL ? Quels appels système sont utilisés ? Quelle est la taille des blocs d'enregistrement ?
Deuxièmement, disons que nous avons des réponses aux questions ci-dessus. Comment reproduire la charge correspondante avec fio? Après tout fio — utilitaire extrêmement flexible avec une abondance de paramètres (c'est facile à vérifier, par exemple, ici - environ. trad.).

Nous avons résolu les deux problèmes avec la même approche basée sur les commandes lsof и strace:

Avec lsof vous pouvez afficher tous les descripteurs de fichiers utilisés par le processus, ainsi que les fichiers auxquels ils se réfèrent.
Avec strace vous pouvez analyser un processus déjà en cours d'exécution ou exécuter un processus et le surveiller. La commande affiche tous les appels système effectués par ce processus et, si nécessaire, ses descendants. Ce dernier est important pour les processus qui fork, et etcd est l'un de ces processus.

La première chose que nous avons faite a été d'utiliser strace pour examiner le serveur etcd dans le cluster Kubernetes alors qu'il était inactif.

Il a donc été constaté que les blocs d'enregistrement WAL sont regroupés de manière très dense, la taille de la majorité étant comprise entre 2200 et 2400 octets. C'est pourquoi la commande au début de cet article utilise le drapeau --bs=2300 (bs est la taille en octets de chaque bloc d'écriture dans fio).

Veuillez noter que la taille des blocs d'écriture etcd peut varier en fonction de la version, du déploiement, des valeurs des paramètres, etc. - cela affecte la durée fdatasync. Si vous avez un cas d'utilisation similaire, analysez avec strace vos processus etcd pour obtenir des valeurs à jour.

Ensuite, afin d'avoir une idée claire et complète du fonctionnement d'etcd avec le système de fichiers, nous l'avons commencé par le bas strace avec des drapeaux -ffttT. Cela a permis de capturer les processus enfants et d'écrire la sortie de chacun dans un fichier séparé. De plus, des informations détaillées sur l'heure de début et la durée de chaque appel système ont été obtenues.

Nous avons également utilisé la commande lsofpour confirmer votre compréhension de la sortie strace en termes de descripteur de fichier utilisé à quelle fin. j'ai eu la conclusion strace, semblable à celui ci-dessus. Des manipulations statistiques avec des temps de synchronisation ont confirmé que la métrique wal_fsync_duration_seconds d'etcd correspond aux appels fdatasync avec des descripteurs de fichiers WAL.

Générer avec fio une charge de travail similaire à celle d'etcd, la documentation de l'utilitaire a été étudiée et les paramètres adaptés à notre tâche ont été sélectionnés. Nous avons vérifié que les bons appels système sont en cours et confirmé leur durée en exécutant fio de strace (comme cela a été fait dans le cas d'etcd).

Une attention particulière a été portée à la détermination de la valeur du paramètre --size. Il représente la charge d'E/S totale générée par l'utilitaire fio. Dans notre cas, il s'agit du nombre total d'octets écrits sur le média. Il est directement proportionnel au nombre d'appels write (et fdatasync). Pour un spécifique bs nombre d'appels fdatasync égal size / bs.

Puisque nous nous intéressons au centile, nous voulions que le nombre d'échantillons soit suffisamment grand pour être statistiquement significatif. Et a décidé que 10^4 (ce qui correspond à une taille de 22 Mo) suffira. Valeurs de paramètre plus petites --size émettait un bruit plus prononcé (par exemple, des appels fdatasync, qui prennent beaucoup plus de temps que d'habitude et affectent le 99e centile).

C'est à vous

L'article montre comment utiliser fio on peut juger si le média destiné à être utilisé avec etcd est assez rapide. Maintenant, ça ne depent que de toi! Vous pouvez explorer des machines virtuelles avec un stockage basé sur SSD dans le service IBM Cloud.

PS du traducteur

Avec des cas d'utilisation prêts à l'emploi fio Pour d'autres tâches, voir documentation ou directement à référentiels de projet (il y en a beaucoup plus que ceux mentionnés dans la documentation).

PPS du traducteur

A lire aussi sur notre blog :

Source: habr.com

Comment vérifier les disques avec fio pour des performances suffisantes pour etcd