From 776f087f707c51e3027d0acd9c15a75ff1104b37 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Mon, 10 Aug 2026 22:38:42 -0400 Subject: [PATCH] clonage : attendre la fin reelle de la tache, pas seulement l'avoir demandee MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- CHANGELOG.md | 58 ++++++++++++++++++++++++++ playbooks/proxmox/cloner_vm_debian.yml | 47 +++++++++++++++++++++ 2 files changed, 105 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2b31f96..7d1f9bb 100644 --- a/CHANGELOG.md +++ b/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** : diff --git a/playbooks/proxmox/cloner_vm_debian.yml b/playbooks/proxmox/cloner_vm_debian.yml index 4edcb86..94c757f 100644 --- a/playbooks/proxmox/cloner_vm_debian.yml +++ b/playbooks/proxmox/cloner_vm_debian.yml @@ -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: >-