vault est lent comme pas permis en haute dispo

hello, c'est quoi le backend de stockage de ton raft ? et les IOPS réels de tes disques SSD ? "censés être rapides" ça veut souvent dire pas mesuré. regarde la queue depth et les latences sur tes devices block. pour 500 req/s vault a besoin de iops sérieuses.

on est sur du ext4 sur un volume EBS io2 sur AWS. on a configuré 10k IOPS provisionnés. cloudwatch me donne des avg iops à 400-500 en pic. mais la latence disque monte parfois à 50ms sur des périodes courtes.

50ms de latence pour du raft c'est beaucoup. raft est très sensible à la latence i/o et network. t'as vérifié les métriques réseau entre tes noeuds vault ? y a du jitter ? est-ce que t'es sûr que tes vms ont assez de bande passante réseau ?

check le tuning kernel de tes VMs. limites de fichiers ouverts (ulimit -n) ? network buffer sizes ? des fois les defaults sont trop bas pour des applications qui gèrent autant de connexions ou de fichiers. pour vault c'est clé.

ulimit c'est par défaut sur 1024. ça peut être ça ouais. pour la bande passante c'est des c5.large ou medium j'ai un doute, j'ai pas les specs là mais c'est pas des gros modèles. on a d'autres trucs sur ces vms genre quelques agents. mais pas des trucs qui devraient saturer le réseau.

c5.large c'est pas fou pour du réseau non plus. c'est surtout le storage iops sur ebs qui m'inquiète pour 500 req/s. t'as tenté d'augmenter les iops provisionnés ? ou de passer sur un type d'instance avec du nvme local si tu peux te le permettre niveau architecture ?

regarde aussi le nombre de sessions ouvertes par vault et les time_wait. si tu as trop de connexions en time_wait ça peut saturer les ports éphémères et ça peut créer de la latence réseau même si le réseau est pas saturé en bande passante. tcp_tw_reuse peut aider mais attention aux effets de bord.

un truc con mais tu as bien activé le cache en mémoire pour vault ? vault cache-size dans la config. et vérifie que tu n'as pas de clients qui spamment la même clé ou un chemin très "chaud" sans token caching côté client. la plupart des SDK vault ont des options de cache.

ok alors après investigation y'avait un mix de trucs. les IOPS de l'EBS étaient pas suffisants pour les bursts réels malgré ce que cloudwatch montrait en moyenne. j'ai monté à 20k IOPS et ça va mieux. et le ulimit -n était effectivement à 1024, je l'ai mis à 65536. depuis ça respire beaucoup plus.

nickel c'est souvent un mix de petits réglages. les IOPS sur EBS sont un piège parfois la moyenne est trompeuse. et le ulimit c'est un classique. bien joué !