La vitesse de stockage convient-elle pour etcd ? Demandons à fio

Une brève histoire sur fio et etcd

Performance du cluster etcd dépend beaucoup de la performance de son stockage. etcd exporte certaines métriques dans Prometheus, afin de fournir les informations nécessaires sur les performances du stockage. Par exemple, la métrique wal_fsync_duration_seconds. La documentation d'etcd stipule: pour que le stockage soit considéré comme suffisamment rapide, le 99e percentile de cette métrique doit être inférieur à 10 ms. Si vous envisagez de lancer un cluster etcd sur des machines Linux et que vous souhaitez évaluer si votre stockage est suffisamment rapide (par exemple, SSD), vous pouvez utiliser fio — un outil populaire pour tester les opérations d'entrée/sortie. Exécutez la commande suivante, où test-data est le répertoire sous le point de montage du stockage :

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

Il suffit de consulter les résultats et de vérifier que le 99e percentile de la durée de fdatasync est inférieur à 10 ms. Si c'est le cas, vous avez un stockage suffisamment rapide. Voici un exemple de résultats :

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  percentiles de sync (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]

Notes

• Nous avons ajusté les valeurs des paramètres —size et —bs pour notre scénario spécifique. Pour obtenir un résultat utile de fio, spécifiez vos valeurs. D'où les obtenir ? Lisez, comment nous avons appris à configurer fio.
• Pendant le test, toute la charge d'entrée/sortie provient de fio. Dans un scénario réel, il est probable que d'autres demandes d'écriture, en plus de celles liées à wal_fsync_duration_seconds, arrivent dans le stockage. Une charge additionnelle augmentera la valeur de wal_fsync_duration_seconds. Donc, si le 99e percentile frôle 10 ms, votre stockage ne suffira pas.
• Prenez la version fio pas inférieure à 3.5 (les versions précédentes ne montrent pas les percentiles de durée de fdatasync).
• Seul un extrait des résultats de fio est montré ci-dessus.

Une longue histoire sur fio et etcd

Qu'est-ce que le WAL dans etcd

En général, les bases de données utilisent journal de préécriture; etcd l'utilise aussi. Ici, nous n'allons pas discuter en détail du journal d'écriture anticipée (write-ahead log, WAL). Nous devons simplement savoir que chaque membre du cluster etcd le garde dans un stockage permanent. etcd enregistre chaque opération avec des paires clé-valeur (par exemple, une mise à jour) dans le WAL avant de les appliquer au stockage. Si, entre les instantanés, l'un des membres du stockage s'arrête de manière inattendue et redémarre, il peut récupérer localement les transactions depuis le dernier instantané en se basant sur le contenu du WAL.

Lorsque le client ajoute une clé au stockage de paires clé-valeur ou met à jour la valeur d'une clé existante, etcd enregistre cette opération dans le WAL, qui est un fichier ordinaire dans le stockage permanent. Avant de continuer le traitement, etcd DOIT être complètement certain que l'enregistrement dans le WAL a réellement eu lieu. Sous Linux, un seul appel système ne suffit pas pour cela. write, car l'enregistrement dans le stockage physique peut en fait être retardé. Par exemple, Linux peut conserver pendant un certain temps l'enregistrement WAL dans le cache en mémoire du noyau (comme le cache des pages). Pour que les données soient effectivement enregistrées dans le stockage permanent, un appel système fdatasync est nécessaire après l'enregistrement, et etcd l'utilise effectivement (comme on peut le voir dans le résultat de l'exécution strace, où 8 est le descripteur de fichier WAL) :

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 
21:23:09.895041 fdatasync(8)            = 0

Malheureusement, l'enregistrement dans le stockage permanent ne se fait pas instantanément. Si l'appel fdatasync est lent, les performances du système etcd en pâtissent. La documentation sur etcd indique, qu'un stockage est considéré comme suffisamment rapide si, au 99e percentile des appels fdatasync lors de l'enregistrement dans le fichier WAL, ceux-ci prennent moins de 10 ms. Il existe d'autres métriques utiles pour le stockage, mais dans cet article, nous parlons uniquement de cette métrique.

Évaluation du stockage avec fio

Si vous devez évaluer si votre stockage est adapté à etcd, utilisez fio — un outil de test de charge d'entrée-sortie très populaire. Il faut garder à l'esprit que les opérations disque peuvent varier considérablement : synchrones et asynchrones, de nombreuses classes d'appels système, etc. En conséquence, utiliser fio peut être assez complexe. Il dispose de nombreux paramètres, et différentes combinaisons de leurs valeurs donnent des charges de travail d'entrée-sortie totalement différentes. Pour obtenir des chiffres adéquats pour etcd, vous devez vous assurer que la charge d'écriture testée par fio est aussi proche que possible de la charge réelle d'écriture d'etcd lors de l'écriture des fichiers WAL.

Par conséquent, fio doit, au minimum, générer une charge sous la forme d'une série d'opérations d'écriture séquentielles dans un fichier, chaque écriture consiste en un appel système write, suivi de l'appel système fdatasync. Pour les opérations d'écriture séquentielles, fio nécessite le paramètre —rw=write. Pour que fio utilise l'appel système write lors de l'écriture, et non pwrite, il convient de spécifier le paramètre —ioengine=sync. Enfin, pour que fdatasync soit appelé après chaque écriture, il faut ajouter le paramètre —fdatasync=1. Les deux autres paramètres de cet exemple (—size et —bs) dépendent du scénario spécifique. Dans la section suivante, nous expliquerons comment les configurer.

Pourquoi fio et comment nous avons appris à le configurer

Dans ce post, nous décrivons un cas réel. Nous avions un cluster Kubernetes v1.13, que nous surveillions avec Prometheus. etcd v3.2.24 était hébergé sur SSD. Les métriques d'etcd montraient des latences beaucoup trop élevées pour fdatasync, même lorsque le cluster ne faisait rien. Les métriques étaient bizarres, et nous ne savions pas vraiment ce qu'elles signifiaient. Le cluster était composé de machines virtuelles, et il fallait comprendre où était le problème : dans les SSD physiques ou dans la couche de virtualisation. De plus, nous apportions souvent des modifications à la configuration matérielle et logicielle, et nous avions besoin d'un moyen d'évaluer leurs résultats. Nous aurions pu exécuter etcd dans chaque configuration et observer les métriques de Prometheus, mais cela était trop fastidieux. Nous cherchions un moyen suffisamment simple d'évaluer une configuration spécifique. Nous voulions vérifier si nous comprenions correctement les métriques Prometheus d'etcd.

Mais pour cela, il fallait résoudre deux problèmes. Tout d'abord, à quoi ressemble la charge d'E/S que etcd génère lors de l'écriture dans le WAL ? Quels appels système sont utilisés ? Quelle est la taille des enregistrements ? En second lieu, si nous répondons à ces questions, comment reproduire une charge de travail similaire avec fio ? N'oubliez pas que fio est un outil très flexible avec de nombreux paramètres. Nous avons résolu les deux problèmes avec une seule approche — en utilisant des commandes. lsof et strace. lsof affiche tous les descripteurs de fichiers utilisés par le processus et les fichiers qui y sont associés. Avec strace, on peut examiner un processus déjà en cours ou en démarrer un et l'étudier. strace affiche tous les appels système du processus étudié (et de ses processus fils). Ce dernier point est très important, car etcd utilise justement une approche similaire.

Tout d'abord, nous avons utilisé strace pour étudier le serveur etcd pour Kubernetes, lorsque le cluster n'était pas sous charge. Nous avons vu que presque tous les enregistrements WAL étaient d'une taille similaire : 2200 à 2400 octets. C'est pourquoi dans la commande au début du post, nous avons spécifié le paramètre —bs=2300 (bs signifie la taille en octets pour chaque enregistrement fio). Notez que la taille des enregistrements etcd dépend de la version d'etcd, de la distribution, des valeurs des paramètres, etc., et influence la durée de fdatasync. Si vous avez un scénario similaire, examinez vos processus etcd à l'aide de strace pour connaître les chiffres exacts.

Ensuite, pour bien visualiser les actions dans le système de fichiers etcd, nous l'avons exécuté avec strace et avec les paramètres -ffttT. Nous avons donc essayé d'étudier les processus fils et d'enregistrer les sorties de chacun d'eux dans un fichier séparé, tout en obtenant des rapports détaillés sur le début et la durée de chaque appel système. Nous avons utilisé lsof pour confirmer notre analyse des sorties de strace et voir quel descripteur de fichier était utilisé à quelles fins. Ainsi, avec strace, nous avons obtenu les résultats montrés ci-dessus. Les statistiques de temps de synchronisation ont confirmé que le taux wal_fsync_duration_seconds d'etcd correspond aux appels de fdatasync avec des descripteurs de fichiers WAL.

Nous avons étudié la documentation de fio et sélectionné les paramètres pour notre scénario afin que fio génère une charge similaire à celle d'etcd. Nous avons également vérifié les appels système et leur durée en exécutant fio depuis strace, de manière similaire à etcd.

Nous avons soigneusement sélectionné la signification du paramètre —size, qui représente toute la charge d'entrée-sortie de fio. Dans notre cas, cela correspond au nombre total d'octets écrits dans le stockage. Cela s'est avéré directement proportionnel au nombre d'appels système write (et fdatasync). Pour une valeur donnée de bs, le nombre d'appels fdatasync = size/bs. Étant donné que nous nous intéressions au percentile, nous devions disposer d'un nombre suffisant d'échantillons pour la fiabilité, et nous avons estimé qu'un 10^4 serait suffisant (ce qui équivaut à 22 mébibytes). Si —size est inférieur, des anomalies peuvent apparaître (par exemple, plusieurs appels fdatasync prennent plus de temps que d'habitude et impactent le 99ème percentile).

Essayez par vous-même

Nous avons démontré comment utiliser fio et vérifier si le stockage a une vitesse suffisante pour une haute performance d'etcd. Vous pouvez maintenant essayer cela par vous-même, en utilisant, par exemple, des machines virtuelles avec un stockage SSD dans IBM Cloud.

Source : habr.com