L’interface de Prism Central renvoie des 403 environ une fois sur deux, alors que l’API v4 répond et authentifie sans broncher. Ce n’était vraisemblablement pas l’authentification : un seul service occupait 21 des 25 vCPU d’une des trois PCVM.
Le contexte
Prism Central scale-out à trois PCVM, microservices activés. Depuis PC.2022.9, cette infrastructure (MSP) est active par défaut : une partie des services tourne en pods dans un cluster Kubernetes de trois nœuds en scale-out, et MSP fournit aussi la gestion des identités. Symptôme : des 403 intermittents sur /dm dans l’UI.
Le premier indice : l’API répond
Au même moment, l’API v4 répond, authentification par compte d’annuaire comprise. Un annuaire ou un mapping de rôles cassé la ferait échouer aussi. L’asymétrie oriente vers une ressource qui manque.
Ce qui était sain :
/homeentre 54 et 63 % sur les trois PCVM ;- tous les pods en
Running(kubectl get pods -A) ; - conteneur
domain_manageren état healthy ; - horloges alignées entre PCVM ;
- les erreurs
aplos.cfg: No such file or directorydedomain_manager.outbouclaient depuis des semaines : du bruit.
Comparer les PCVM entre elles
La mesure décisive : le load average de chaque PCVM.
# sur chaque PCVM, en SSH avec le compte nutanix
top # load average 1/5/15 min et charge par processus
less /home/nutanix/data/logs/sysstats/top.INFO # historique de top (chemin documenté sur une CVM)Une PCVM affichait 43,5 / 43,4 / 41,3 pour 25 vCPU, les deux autres entre 2,5 et 3,8. Charge stable (1 min ≈ 15 min), donc pas un pic. Dans top, stats_gw_server (un parent et un enfant) prenait environ 590 % et 1500 % de CPU, soit environ 21 vCPU en continu. Cette PCVM portait aussi le leader Prism et la VIP.
C’est la démarche qu’un employé Nutanix décrit sur le forum communautaire pour une CVM chargée : top, sysstats/top.INFO, et « les autres CVM font-elles pareil ? ».
La chaîne causale
Le conteneur domain_manager est limité à cpu_quota 200000 pour cpu_period 100000. En sémantique Docker, le quota est le nombre de microsecondes de CPU autorisées par période : 2 CPU au maximum. La chaîne retenue, non validée par un log : sur un nœud saturé, il ne suit plus, ses appels vers iam-proxy.ntnx-base:8445 expirent, et /dm répond 403.
L’intermittence venait du DNS : le FQDN du PC tournait en round-robin sur quatre entrées, les trois PCVM et la VIP. Deux sur quatre menaient au nœud saturé, d’où environ une requête sur deux en échec.
La piste de correctif
La Nutanix Bible donne le redémarrage d’un service local (procédure documentée pour une CVM) : genesis stop <service> puis cluster start, qui relance tous les services arrêtés.
# sur la PCVM saturée uniquement
genesis status # repérer le nom genesis du service
genesis stop <service> # noté stats_gateway dans notre diagnostic
cluster startCe qu’il faut retenir
- UI en 403 et API v4 qui s’authentifie : cherchez la ressource qui manque avant l’annuaire.
- Comparez le load average des PCVM entre elles, c’est ce qui isole le nœud fautif.
- La colonne
%CPUdepsest une moyenne sur la vie du processus ; liseztopousysstats/top.INFO. - Un round-robin DNS sur les PCVM transforme la panne d’un nœud en symptôme intermittent.
- L’incident n’a été vu qu’au ressenti : supervisez le load des PCVM.
In English
Intermittent 403 errors in the UI while the v4 API behaves normally. On a scale-out Prism Central, one service was using 21 of the 25 vCPUs of a single PCVM, and ps hid it. Diagnosis by measurement with top and a load average comparison between PCVMs, DNS round-robin explaining the intermittence, and a fix still to be confirmed.
Sources & vérification
Testé sur : Prism Central scale-out 3 PCVM, microservices et IAM v2 activés (2026)
- The Nutanix Bible, Book of AOS Administration nutanixbible.com
- The Nutanix Bible, Prism Microservices Infrastructure nutanixbible.com
- High CPU on a CVM, isolating and troubleshooting (next.nutanix.com) next.nutanix.com
- ps(1), man7.org man7.org
- top(1), man7.org man7.org
- Docker, Resource constraints docs.docker.com
- Expérience directe de l’auteur, en production (versions ci-dessus)