9 commentaires
hello t'as vérifié la santé de ton cluster Consul ? genre
consul operator raft list-peersen plus des problèmes réseau entre Vault et Consul regarde aussi les problèmes disque sur les serveurs Consul ? ça pourrait être juste un bottleneck sur les disques ou le réseau
ouais le quorum est bon pas de souci de ce côté. par contre les logs consul montrent des leaders switch de temps en temps mais c'est pas systématique. je vais regarder les métriques i/o des disques des serveurs consul
c'est quel type de stockage pour Consul ? EBS gp2/gp3 ou des iops provisionnés ? un gp2 sous-provisionné ça explose vite avec le trafic de Vault et les write ahead logs de consul
et la version de vault et consul ? y'a eu des fixs perf/stabilité sur les dernières versions avec consul
c'est du gp2 par défaut sur des instances t3.medium. ptete que les iops burst sont pas suffisants surtout quand y a un pic de demandes pour des secrets. et on est sur vault 1.12 et consul 1.13
T3.medium avec gp2 c'est pas ouf pour un backend HA de Vault en prod. passe en gp3 avec des iops garantis ou au moins en m5.large avec plus de network perf et de iops de base ça va changer la donne. et regarde la latence réseau entre vault et consul si c'est pas sur le même subnet ou la même AZ
oui la latence entre vault et consul est primordiale pour la stabilité et la perf. si t'as des ms de ping c'est mort pour des petits commits ultra fréquents
ok je vais tester de migrer vers du gp3 et des instances plus solides et je vais checker la latence. je vous tiens au jus thx pour les pistes
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team ! vault en HA avec consul backend qui part en vrille après un reboot de certains nœuds consul. mes workers Vault galèrent à débloquer le service. je vois des erreurs I/O sur consul parfois genre
c'est aléatoire mais super relou en prod