Une petite histoire sur fio et etcd
Performances du cluster dépend en grande partie des performances de son stockage. etcd exporte certaines métriques vers pour fournir les informations de performances de stockage souhaitées. Par exemple, la métrique wal_fsync_duration_seconds. : Pour que le stockage soit considéré comme suffisamment rapide, le 99e centile de cette métrique doit être inférieur à 10 ms. Si vous envisagez d'exécuter un cluster etcd sur des machines Linux et que vous souhaitez évaluer si votre stockage est suffisamment rapide (par exemple, SSD), vous pouvez utiliser est un outil populaire pour tester les opérations d'E/S. Exécutez la commande suivante, où test-data est le répertoire sous le point de montage de stockage :
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestIl vous suffit de regarder les résultats et de vérifier que le 99e centile de la durée moins de 10 ms. Si c'est le cas, vous disposez d'un stockage raisonnablement rapide. Voici un exemple des résultats :
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]notes
- Nous avons personnalisé les options --size et --bs pour notre scénario particulier. Pour obtenir un résultat utile de fio, fournissez vos propres valeurs. Où les obtenir ? Lire .
- Pendant les tests, toute la charge d'E/S provient de fio. Dans un scénario réel, il y aura probablement d'autres demandes d'écriture entrant dans le stockage en plus de celles liées à wal_fsync_duration_seconds. La charge supplémentaire augmentera la valeur de wal_fsync_duration_seconds. Donc, si le 99e centile est proche de 10 ms, votre stockage manque de vitesse.
- Prenez la version au moins 3.5 (les précédents n'affichent pas les centiles de durée de fdatasync).
- Ci-dessus est juste un extrait des résultats de fio.
Longue histoire sur fio et etcd
Qu'est-ce que WAL dans etcd
Généralement, les bases de données utilisent ; etcd l'utilise aussi. Nous ne discuterons pas en détail du journal d'écriture anticipée (WAL) ici. Il nous suffit de savoir que chaque membre du cluster etcd le maintient dans un stockage persistant. etcd écrit chaque opération clé-valeur (telle qu'une mise à jour) dans WAL avant de l'appliquer au magasin. Si l'un des membres du stockage tombe en panne et redémarre entre les instantanés, il peut restaurer localement les transactions depuis le dernier instantané par le contenu WAL.
Lorsqu'un client ajoute une clé au magasin clé-valeur ou met à jour la valeur d'une clé existante, etcd enregistre l'opération dans WAL, qui est un fichier normal dans un stockage persistant. etcd DOIT être complètement sûr que l'entrée WAL s'est réellement produite avant de poursuivre le traitement. Sous Linux, un appel système ne suffit pas pour cela. , car l'écriture réelle sur le stockage physique peut être retardée. Par exemple, Linux peut stocker une entrée WAL dans un cache de la mémoire du noyau (comme un cache de pages) pendant un certain temps. Et pour que les données soient écrites avec précision dans le stockage persistant, l'appel système fdatasync est nécessaire après l'écriture, et etcd l'utilise simplement (comme vous pouvez le voir dans le résultat du travail , où 8 est le descripteur de fichier WAL) :
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Malheureusement, l'écriture dans le stockage persistant ne se produit pas instantanément. Si l'appel fdatasync est lent, les performances du système etcd en souffriront. que le stockage est considéré comme suffisamment rapide si, dans le 99e centile, les appels fdatasync prennent moins de 10 ms pour écrire dans le fichier WAL. Il existe d'autres métriques utiles pour le stockage, mais dans cet article, nous ne parlons que de cette métrique.
Estimation du stockage avec fio
Si vous avez besoin d'évaluer si votre stockage est adapté à etcd, utilisez fio, un outil de test de charge d'E/S très populaire. Il convient de rappeler que les opérations sur disque peuvent être très différentes : synchrone et asynchrone, plusieurs classes d'appels système, etc. Par conséquent, fio est assez difficile à utiliser. Il comporte de nombreux paramètres et différentes combinaisons de leurs valeurs produisent des charges de travail d'E/S très différentes. Pour obtenir des chiffres adéquats pour etcd, vous devez vous assurer que la charge d'écriture de test de fio est aussi proche que possible de la charge réelle d'etcd lors de l'écriture de fichiers WAL.
Par conséquent, fio doit, au minimum, créer une charge d'une série d'écritures séquentielles dans le fichier, chaque écriture consistera en un appel système suivi de l'appel système fdatasync. Les écritures séquentielles sur fio nécessitent l'option --rw=write. Pour que fio utilise l'appel système write lors de l'écriture, plutôt que , vous devez spécifier le paramètre --ioengine=sync. Enfin, pour appeler fdatasync après chaque écriture, vous devez ajouter le paramètre --fdatasync=1. Les deux autres options de cet exemple (--size et -bs) sont spécifiques au script. Dans la section suivante, nous vous montrerons comment les configurer.
Pourquoi fio et comment nous avons appris à le mettre en place
Dans cet article, nous décrivons un cas réel. Nous avons un cluster v1.13 que nous avons surveillé avec Prometheus. etcd v3.2.24 était hébergé sur un SSD. Les métriques Etcd ont montré des latences fdatasync trop élevées, même lorsque le cluster ne faisait rien. Les mesures étaient bizarres et nous ne savions pas vraiment ce qu'elles signifiaient. Le cluster était composé de machines virtuelles, il fallait comprendre quel é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 pourrions exécuter etcd dans chaque configuration et examiner les métriques Prometheus, mais c'est trop compliqué. Nous recherchions un moyen assez simple d'évaluer une configuration spécifique. Nous voulions vérifier si nous comprenons correctement les métriques Prometheus d'etcd.
Mais pour cela, deux problèmes devaient être résolus. Tout d'abord, à quoi ressemble la charge d'E/S créée par etcd lors de l'écriture dans WAL ? Quels appels système sont utilisés ? Quelle est la taille des enregistrements ? Deuxièmement, si nous répondons à ces questions, comment reproduisons-nous une charge de travail similaire avec fio ? N'oubliez pas que fio est un outil très flexible avec de nombreuses options. Nous avons résolu les deux problèmes en une seule approche - en utilisant les commandes и . lsof répertorie tous les descripteurs de fichiers utilisés par le processus et leurs fichiers associés. Et avec strace, vous pouvez examiner un processus déjà en cours d'exécution ou démarrer un processus et l'examiner. strace imprime tous les appels système du processus en cours d'examen (et de ses processus enfants). Ce dernier est très important, car etcd adopte simplement une approche similaire.
Nous avons d'abord utilisé strace pour explorer le serveur etcd pour Kubernetes lorsqu'il n'y avait pas de charge sur le cluster. Nous avons vu que presque tous les enregistrements WAL avaient à peu près la même taille : 2200–2400 octets. Par conséquent, dans la commande au début de l'article, nous avons spécifié le paramètre -bs=2300 (bs signifie la taille en octets pour chaque entrée fio). Notez que la taille de l'entrée etcd dépend de la version d'etcd, de la distribution, des valeurs des paramètres, etc., et affecte la durée de fdatasync. Si vous avez un scénario similaire, examinez vos processus etcd avec strace pour connaître les chiffres exacts.
Ensuite, pour avoir une bonne idée de ce que fait le système de fichiers etcd, nous l'avons démarré avec strace et les options -ffttT. Nous avons donc essayé d'examiner les processus enfants et d'enregistrer la sortie de chacun d'eux dans un fichier séparé, et également d'obtenir 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 de la sortie strace et voir quel descripteur de fichier était utilisé dans quel but. Ainsi, avec l'aide de strace, les résultats présentés ci-dessus ont été obtenus. Les statistiques de temps de synchronisation ont confirmé que wal_fsync_duration_seconds d'etcd est cohérent avec les appels fdatasync avec les descripteurs de fichiers WAL.
Nous avons parcouru la documentation de fio et avons choisi des options pour notre script afin que fio génère une charge similaire à etcd. Nous avons également vérifié les appels système et leur durée en exécutant fio depuis strace, similaire à etcd.
Nous avons soigneusement choisi la valeur du paramètre --size pour représenter la totalité de la charge d'E/S de fio. Dans notre cas, il s'agit du nombre total d'octets écrits dans le stockage. Il s'est avéré être directement proportionnel au nombre d'appels système d'écriture (et de fdatasync). Pour une certaine valeur de bs, le nombre d'appels fdatasync = taille/bs. Puisque nous étions intéressés par le centile, nous devions avoir suffisamment d'échantillons pour être sûrs, et nous avons calculé que 10 ^ 4 nous suffirait (c'est-à-dire 22 mébioctets). Si --size est plus petit, des valeurs aberrantes peuvent se produire (par exemple, plusieurs appels fdatasync prennent plus de temps que d'habitude et affectent le 99e centile).
Essayez vous-même
Nous vous avons montré comment utiliser fio et voir si le stockage est assez rapide pour qu'etcd fonctionne bien. Vous pouvez maintenant l'essayer par vous-même en utilisant, par exemple, des machines virtuelles avec un stockage SSD dans .
Source: habr.com