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: >-