Aller au contenu

Routine hebdomadaire de l'admin Proxmox (15 min)

Day 2 · ExploiterNiveau 1 · DécouvrirChecklistRédigé · à valider en lab

Chaque lundi matin, en 15 minutes, vous vérifiez que le cluster, le stockage, les sauvegardes et la copie MSP sont sains, et vous détectez ce qui deviendra un incident dans un mois. Tout est en lecture seule : aucune commande de cette page ne modifie la configuration.

Comment l'utiliser

  • Imprimez la page ou copiez-la dans votre outil de suivi, cochez chaque point et notez la date.
  • Un point rouge ne se corrige pas ici : suivez le runbook indiqué, ou ouvrez un ticket.
  • Les commandes se lancent en SSH sur un nœud (ex. pve01), ou côté PBS quand c'est précisé.
  • Les notifications natives et la supervision ne remplacent pas cette routine : elles ne voient que ce qu'on leur a demandé de surveiller.

1. État du cluster (2 min)

  • GUI : Datacenter → Summary : tous les nœuds en vert, aucun point d'interrogation gris ni croix rouge.
  • Quorum présent et tous les votes attendus :

    pvecm status | grep -E 'Quorate|Expected votes|Total votes'
    # Quorate: Yes ; Expected votes = Total votes
    
  • Cluster à 2 nœuds : la ligne Qdevice apparaît dans pvecm status (votes du QDevice comptés).

  • HA : ha-manager status sans ressource en error ou fence, aucun nœud resté en mode maintenance après une intervention.
  • Toutes les versions identiques : pveversion sur chaque nœud, ou Datacenter → Summary.

Anomalie : RB-09 · Nœud grisé, hors ligne, perte de quorum.

2. Stockage Ceph ou ZFS (3 min)

  • ceph -s : HEALTH_OK, 100 % active+clean, aucun drapeau noout oublié.
  • ceph osd df tree : aucun OSD au-delà de 75 % (%USE), écart VAR inférieur à 1,2.
  • ceph crash ls-new : vide, ou crashs expliqués puis archivés.
  • Lecture détaillée : RB-01 · Ceph : lire l'état du cluster. Remplissage : RB-04.
  • zpool status -x sur chaque nœud : all pools are healthy.
  • zpool list : colonne CAP sous 80 % pour rpool et tank.
  • Date du dernier scrub (ligne scan: de zpool status tank) de moins de 5 semaines.
  • Réplication : pvesr status, tous les jobs en OK avec un Last Sync récent (RB-11).
  • Anomalie : RB-07 · ZFS : pool DEGRADED.
  • pvesm status : tous les stockages en active.
  • multipath -ll : tous les chemins en active ready running.
  • Alertes de la baie consultées sur sa console d'administration.
  • Disques : nœud → Disks, colonne S.M.A.R.T. à PASSED pour tous les disques.

3. Sauvegardes et vérification (3 min)

  • Datacenter → Backup : chaque job a tourné cette semaine. Nœud → Task History, filtre Backup Job : aucune tâche en Error sur 7 jours.

    pvenode task list --typefilter vzdump --errors 1 --limit 20
    
  • Aucune VM de production hors de tout job de sauvegarde (GUI : Datacenter → Backup, vue des invités non sauvegardés dans la barre d'outils) :

    pvesh get /cluster/backup-info/not-backed-up   # liste vide attendue
    
  • PBS → Datastore → Summary : occupation sous 80 %, estimation de remplissage cohérente.

  • PBS → Datastore → Prune & GC : dernière garbage collection en OK.
  • PBS → Datastore → Verify Jobs : dernier verify en OK, aucun snapshot marqué en échec dans Content.

    # côté PBS
    proxmox-backup-manager verify-job list
    proxmox-backup-manager task list --limit 20
    

Anomalie : RB-14 · Job de sauvegarde en échec. Ordre des tâches : rétention, prune, GC, verify.

4. Copie hors site vers le MSP (1 min)

  • PBS local → Datastore → Sync Jobs : Last Sync de moins de 24 h, statut OK.
  • Les 7 derniers logs du job sans erreur ; même nombre de groupes de sauvegarde des deux côtés (à demander au MSP en cas de doute).

Anomalie : RB-15 · Sync vers le MSP.

5. Mises à jour disponibles (2 min)

  • Nœud → Updates : liste des paquets en attente notée (noyau, pve-manager, qemu-server, ceph, zfsutils-linux).
  • Nœud → Updates → Repositories : aucun avertissement (dépôt enterprise actif en production, pas de pvetest).
  • Mises à jour de sécurité ou correctifs importants : planifier un passage avec RB-08 · Mises à jour en rolling ; contrats N2/N3 : vérifier avec le MSP.

    apt list --upgradable 2>/dev/null | wc -l   # la liste est rafraîchie chaque jour par pveupdate
    

6. Espace et ressources (2 min)

  • Datacenter → Summary : CPU et RAM du cluster. La RAM utilisée doit permettre de vider le nœud le plus chargé sur les autres (N+1, voir le plan de capacité).
  • Système de chaque nœud : df -h / sous 80 % ; /var/log et /var/lib/vz sans croissance anormale.
  • Snapshots de VM de plus de 7 jours : VM → Snapshots. Un snapshot oublié consomme de l'espace et ralentit certaines opérations.

    for id in $(qm list | awk 'NR>1{print $1}'); do qm listsnapshot $id | grep -v current | sed "s/^/$id /"; done
    

7. Certificats (1 min)

  • Nœud → System → Certificates : date d'expiration de pveproxy-ssl.pem (ou pve-ssl.pem) à plus de 30 jours.

    pvenode cert info | grep -E 'filename|notafter'
    
  • Certificats ACME : le renouvellement est automatique ; un certificat à moins de 30 jours de l'expiration signale un échec de renouvellement. Voir Durcir un hôte PVE et PBS.

  • Certificat du PBS renouvelé : l'empreinte doit être mise à jour dans Datacenter → Storage → pbs-local (sinon échec de sauvegarde, voir RB-14).

8. Journaux de tâches et erreurs système (1 min)

  • Bas de l'écran GUI → Cluster log et Tasks : aucune tâche rouge inexpliquée cette semaine.

    pvenode task list --errors 1 --limit 30
    journalctl -p err --since "7 days ago" | tail -50
    
  • Méthode de lecture : Lire les logs.

9. Clôture

  • Notifications : Datacenter → Notifications → Test sur la cible principale, réception confirmée (Notifications natives).
  • Anomalies notées avec leur suite (runbook appliqué, ticket ouvert et son numéro).
  • Une fois par mois, compléter par le test de restauration mensuel.

Pièges vus en support

  • Routine faite uniquement sur le nœud où l'on est connecté : zpool status, df et les tâches sont locaux à chaque nœud.
  • « Pas de mail, donc tout va bien » : un relais SMTP cassé rend toutes les alertes muettes.
  • Drapeau Ceph noout resté actif depuis la dernière maintenance : Ceph ne reconstruit plus rien en cas de panne.
  • Verify jamais planifié : on découvre les chunks corrompus le jour de la restauration.

Quand ouvrir un ticket iTop

Point rouge que le runbook ne résout pas, ou anomalie présente deux semaines de suite : P3. Joignez les sorties des commandes concernées.

Ouvrir un ticket iTop