1.3. Pratiques recommandées pour etcd
Comme etcd écrit des données sur le disque et y conserve des propositions, ses performances dépendent de celles du disque. Bien que etcd ne soit pas particulièrement gourmand en E/S, il a besoin d'un périphérique de bloc à faible latence pour des performances et une stabilité optimales. Comme le protocole de consensus d'etcd dépend du stockage persistant des métadonnées dans un journal (WAL), etcd est sensible à la latence de l'écriture sur disque. Les disques lents et l'activité du disque par d'autres processus peuvent causer de longues latences de synchronisation.
Ces latences peuvent amener etcd à manquer des battements de cœur, à ne pas livrer de nouvelles propositions sur le disque à temps et, en fin de compte, à subir des dépassements de délai de requête et des pertes de leader temporaires. Des latences d'écriture élevées entraînent également une lenteur de l'API OpenShift, ce qui affecte les performances du cluster. Pour ces raisons, évitez de colocaliser d'autres charges de travail sur les nœuds du plan de contrôle.
En termes de latence, exécutez etcd au-dessus d'un périphérique bloc qui peut écrire au moins 50 IOPS de 8000 octets de long séquentiellement. C'est-à-dire avec une latence de 10 ms, en gardant à l'esprit que etcd utilise fdatasync pour synchroniser chaque écriture dans le WAL. Pour les clusters très chargés, 500 IOPS séquentiels de 8000 octets (2 ms) sont recommandés. Pour mesurer ces chiffres, vous pouvez utiliser un outil d'analyse comparative, tel que fio.
Pour obtenir de telles performances, exécutez etcd sur des machines soutenues par des disques SSD ou NVMe avec une faible latence et un débit élevé. Considérons les disques d'état solide (SSD) à cellule à niveau unique (SLC), qui fournissent 1 bit par cellule de mémoire, sont durables et fiables, et sont idéaux pour les charges de travail à forte intensité d'écriture.
Les caractéristiques suivantes du disque dur permettent d'optimiser les performances du système etcd :
- Faible latence pour permettre une lecture rapide.
- Écritures à large bande passante pour des compactions et des défragmentations plus rapides.
- Lecture à large bande passante pour une reprise plus rapide en cas de défaillance.
- Les disques d'état solide sont une sélection minimale, mais les disques NVMe sont préférables.
- Matériel de qualité serveur provenant de différents fabricants pour une plus grande fiabilité.
- Technologie RAID 0 pour des performances accrues.
- Disques etcd dédiés. Ne placez pas de fichiers journaux ou d'autres charges de travail lourdes sur les disques etcd.
Évitez les configurations NAS ou SAN et les disques en rotation. Effectuez toujours des analyses comparatives à l'aide d'utilitaires tels que fio. Surveillez en permanence les performances de la grappe au fur et à mesure qu'elles augmentent.
Évitez d'utiliser le protocole NFS (Network File System) ou d'autres systèmes de fichiers basés sur le réseau.
Certaines mesures clés à surveiller sur un cluster OpenShift Container Platform déployé sont p99 of etcd disk write ahead log duration et le nombre de changements de leader etcd. Utilisez Prometheus pour suivre ces métriques.
La taille des bases de données des membres etcd peut varier dans un cluster au cours des opérations normales. Cette différence n'affecte pas les mises à niveau du cluster, même si la taille du leader est différente de celle des autres membres.
Pour valider le matériel pour etcd avant ou après la création du cluster OpenShift Container Platform, vous pouvez utiliser fio.
Conditions préalables
- Les moteurs d'exécution de conteneurs tels que Podman ou Docker sont installés sur la machine que vous testez.
-
Les données sont écrites sur le chemin
/var/lib/etcd.
Procédure
Exécutez fio et analysez les résultats :
Si vous utilisez Podman, exécutez cette commande :
$ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/openshift-scale/etcd-perf
Si vous utilisez Docker, exécutez cette commande :
$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/openshift-scale/etcd-perf
La sortie indique si le disque est assez rapide pour héberger etcd en comparant le 99ème percentile de la métrique fsync capturée lors de l'exécution pour voir si elle est inférieure à 10 ms. Voici quelques-unes des métriques etcd les plus importantes qui peuvent être affectées par les performances d'E/S :
-
etcd_disk_wal_fsync_duration_seconds_bucketla métrique indique la durée de la synchronisation WAL de etcd -
etcd_disk_backend_commit_duration_seconds_bucketla métrique indique la durée de latence du commit du backend etcd -
etcd_server_leader_changes_seen_totalrapports métriques le leader change
Comme etcd réplique les requêtes entre tous les membres, ses performances dépendent fortement de la latence des entrées/sorties du réseau. Des latences réseau élevées entraînent des battements de cœur etcd plus longs que le délai d'élection, ce qui se traduit par des élections de leaders qui perturbent le cluster. Une mesure clé à surveiller sur un cluster OpenShift Container Platform déployé est le 99e percentile de la latence des pairs du réseau etcd sur chaque membre du cluster etcd. Utilisez Prometheus pour suivre cette métrique.
La métrique histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m])) indique le temps d'aller-retour pour que etcd finisse de répliquer les requêtes des clients entre les membres. Assurez-vous qu'il est inférieur à 50 ms.
