clonage : attendre la fin reelle de la tache, pas seulement l'avoir demandee
Mon optimisation d'hier soir a mis le cluster a genoux, et la faute est entiere. En remplacant proxmox_kvm par un appel d'API direct, j'ai perdu ce que le module faisait pour moi : attendre la fin de la tache (timeout: 600). `POST .../clone` rend un UPID et la main immediatement ; Proxmox copie le disque en tache de fond. En sequentiel ca ne se voyait pas — l'attente de SSH absorbait le delai. En PARALLELE, `make creer-vm` rendait la main pendant la copie : la limite de concurrence ne retenait plus que des PROCESSUS VIDES et les clones s'empilaient. Mesure : limite a 4, QUATORZE copies integrales simultanees. Le symptome trompait — CPU de l'hyperviseur a 2 %, RAM a 13/62, et tout ramait. Ce n'etait pas la machine, c'etait TrueNAS. Les 14 hotes ont echoue, et flotte-creer a refuse de continuer : la garde ajoutee le matin meme a fait son travail. Le clonage relit desormais l'UPID et interroge l'etat de la tache jusqu'a `stopped`, avec un message clair si la sortie n'est pas OK. La limite de concurrence retrouve un sens : quatre clones REELS, pas quatre coquilles. NOTE, PAS ENCORE CORRIGE : `raser` a le meme defaut dans l'autre sens. Il a rapporte « 6/6 VM detruites » alors que les six etaient la — l'API accepte le DELETE, rend un UPID, et la tache echoue ensuite sur « VM is locked (clone) ». raser ne lit que la reponse immediate, jamais le resultat. MESURE DES OPTIMISATIONS, reconstruction complete avec gabarit sur CephNVMe (proposition de l'exploitant) et concurrence a 3 : 54 min 02 s contre 1 h 12 min 48 s — 26 % de moins, zero echec, 2838 taches. Le cache d'artefacts est le plus rentable : Nextcloud 10m55s -> 4m14s, Forgejo 3m42s -> 1m33s, verifie par les `skipping` du journal. J'avais annonce un gain « limite a la part telechargement » — cette part etait bien plus grosse que je ne le croyais. forks=20 : les couches larges 3m09s -> 1m37s. Gabarit NVMe + 3 clones : 1m35s -> 1m17s par VM, le plus modeste, car les disques ECRIVENT toujours sur TrueNAS. Verifie : 3 clones actifs jamais plus, 7 devis CONFORME, ansible-lint production, prouver.py 35 OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
840b21bfb6
commit
776f087f70
2 changed files with 105 additions and 0 deletions
58
CHANGELOG.md
58
CHANGELOG.md
|
|
@ -1,5 +1,63 @@
|
|||
# CHANGELOG — Set-OPS
|
||||
|
||||
## 2026-08-10 — Le clonage ne s'attendait plus lui-même, et ça a saturé le stockage
|
||||
|
||||
**Mon optimisation de la veille au soir a mis le cluster à genoux, et la faute est entière.**
|
||||
|
||||
En remplaçant `proxmox_kvm` par un appel d'API direct (pour corriger la résolution par nom),
|
||||
j'ai perdu quelque chose que le module faisait pour moi : **attendre la fin de la tâche**
|
||||
(`timeout: 600`). `POST .../clone` rend un UPID et la main immédiatement ; Proxmox copie le
|
||||
disque en tâche de fond.
|
||||
|
||||
En séquentiel ça ne se voyait pas — l'attente de SSH qui suit absorbait le délai. **En
|
||||
parallèle, c'est tout autre chose** : `make creer-vm` rendait la main pendant la copie, la
|
||||
limite de concurrence ne retenait plus que des **processus vides**, et les clones
|
||||
s'empilaient. Mesuré : limite à 4, **quatorze copies intégrales du gabarit simultanées**.
|
||||
|
||||
Le symptôme trompait : **CPU de l'hyperviseur à 2 %**, RAM à 13/62 Gio — et tout ramait. Ce
|
||||
n'était pas la machine, c'était TrueNAS (LVM sur iSCSI). Les 14 hôtes ont échoué, et
|
||||
`flotte-creer` a refusé de continuer — la garde ajoutée le matin même a fait son travail.
|
||||
|
||||
**Le clonage attend désormais la fin réelle** : il relit l'UPID rendu par l'API et interroge
|
||||
l'état de la tâche jusqu'à `stopped`, avec un message clair si la sortie n'est pas `OK`. La
|
||||
limite de concurrence retrouve alors un sens — quatre clones *réels*, pas quatre coquilles.
|
||||
|
||||
### Au passage : `raser` annonçait des destructions qui échouaient
|
||||
|
||||
En nettoyant, `make raser` a rapporté « 6/6 VM détruites » alors que les six étaient toujours
|
||||
là. L'API accepte le `DELETE`, rend un UPID… et la tâche échoue ensuite sur
|
||||
`VM is locked (clone)`. **`raser` ne lit que la réponse immédiate, jamais le résultat.**
|
||||
C'est exactement le même défaut, dans l'autre sens — noté ici, pas encore corrigé.
|
||||
|
||||
### Ce que les optimisations ont réellement donné
|
||||
|
||||
Reconstruction complète de Chezlepro, gabarit déplacé sur `CephNVMe` (proposition de
|
||||
l'exploitant), concurrence à 3 : **`54 min 02 s` contre `1 h 12 min 48 s` — 26 % de moins,
|
||||
zéro échec, 2 838 tâches.**
|
||||
|
||||
| Phase | Avant | Après |
|
||||
|---|---|---|
|
||||
| création des 14 VM | 22m08s | **17m57s** |
|
||||
| amorçage PKI + DNS | 6m01s | 6m07s |
|
||||
| six couches | 44m39s | **29m58s** |
|
||||
|
||||
**Le cache d'artefacts est le plus rentable, et de loin** : Nextcloud `10m55s → 4m14s`,
|
||||
Forgejo `3m42s → 1m33s`. Vérifié — `skipping` sur chaque téléchargement, les fichiers du
|
||||
cache portent toujours leur horodatage d'origine. J'avais annoncé un gain « limité à la part
|
||||
téléchargement » : cette part était bien plus grosse que je ne le croyais, et la
|
||||
décompression bz2 n'était pas le mur que je décrivais.
|
||||
|
||||
**`forks = 20`** : socle + durcissement + AC + enrôlement PKI des 14 hôtes, `3m09s → 1m37s`.
|
||||
|
||||
**Gabarit sur NVMe + 3 clones** : `1m35s → 1m17s` par VM. Le gain le plus modeste — les
|
||||
disques **écrivent toujours sur TrueNAS**, donc seule la moitié du chemin a été traitée.
|
||||
|
||||
**L'amorçage n'a pas bougé**, et c'est cohérent : deux hôtes l'un après l'autre, aucun levier
|
||||
ne s'y applique.
|
||||
|
||||
Sept devis **CONFORME** après coup, dont le MTU : les quatorze invités naissent à 1450 sans
|
||||
le moindre geste.
|
||||
|
||||
## 2026-08-10 — Le contrôleur télécharge et pousse ; la cible ne tire plus d'Internet
|
||||
|
||||
**Inventaire mesuré** de ce qu'une reconstruction de tenant télécharge — environ **1,5 Gio** :
|
||||
|
|
|
|||
|
|
@ -226,6 +226,53 @@
|
|||
no_log: true
|
||||
when: not proxmox_clone_deja_la
|
||||
|
||||
# ATTENDRE QUE LE CLONE SOIT REELLEMENT FINI, pas seulement demande.
|
||||
#
|
||||
# `POST .../clone` rend un UPID et la main IMMEDIATEMENT : Proxmox copie le disque en
|
||||
# tache de fond. `proxmox_kvm`, qu'on a remplace, attendait la fin (`timeout: 600`) — la
|
||||
# reecriture par API avait perdu cette attente sans que ca se voie, parce qu'en
|
||||
# sequentiel l'attente de SSH qui suit l'absorbait.
|
||||
#
|
||||
# En PARALLELE, c'est tout autre chose : `make creer-vm` rend la main pendant que le
|
||||
# disque se copie, la limite de concurrence ne retient plus que des processus vides, et
|
||||
# les clones s'empilent. Mesure du 2026-08-10 : limite a 4, DOUZE copies integrales du
|
||||
# gabarit simultanees sur le meme stockage. Le CPU de l'hyperviseur a 2 %, et pourtant
|
||||
# tout ramait — ce n'etait pas la machine, c'etait TrueNAS.
|
||||
- name: Attendre la fin reelle du clonage
|
||||
vars:
|
||||
proxmox_api_racine: "https://{{ proxmox_api_host_effectif }}:{{ proxmox_api_port_effectif | default(8006, true) }}"
|
||||
ansible.builtin.uri:
|
||||
url: >-
|
||||
{{ proxmox_api_racine }}/api2/json/nodes/{{ proxmox_clone_noeud
|
||||
}}/tasks/{{ proxmox_clone_lance.json.data | urlencode }}/status
|
||||
method: GET
|
||||
headers:
|
||||
Authorization: >-
|
||||
PVEAPIToken={{ proxmox_api_user_effectif }}!{{ proxmox_api_token_id_effectif }}={{ proxmox_api_token_secret_effectif }}
|
||||
validate_certs: "{{ proxmox_validate_certs | default(false) | bool }}"
|
||||
status_code: [200]
|
||||
register: proxmox_clone_tache
|
||||
until: (proxmox_clone_tache.json.data.status | default('running')) == 'stopped'
|
||||
retries: "{{ ((proxmox_clone_timeout | default(600) | int) / 10) | round | int }}"
|
||||
delay: 10
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
no_log: true
|
||||
when:
|
||||
- not proxmox_clone_deja_la
|
||||
- proxmox_clone_lance.json.data is defined
|
||||
|
||||
- name: Dire si le clonage ne s'est pas termine correctement
|
||||
ansible.builtin.fail:
|
||||
msg: >-
|
||||
Le clonage de {{ proxmox_clone_nom }} (VMID {{ proxmox_clone_vmid }}) ne s'est pas
|
||||
termine correctement : etat « {{ proxmox_clone_tache.json.data.status | default('?')
|
||||
}} », sortie « {{ proxmox_clone_tache.json.data.exitstatus | default('?') }} ».
|
||||
Regarder la tache sur {{ proxmox_clone_noeud }}.
|
||||
when:
|
||||
- not proxmox_clone_deja_la
|
||||
- proxmox_clone_tache.json.data.exitstatus | default('OK') != 'OK'
|
||||
|
||||
- name: Dire pourquoi le clonage a echoue, s'il a echoue
|
||||
ansible.builtin.fail:
|
||||
msg: >-
|
||||
|
|
|
|||
Loading…
Reference in a new issue