Jlarvers le 10 septembre 2026 à 13:04

2026-09-10T13:04:27Z

Jlarvers : Page créée avec « Bilan technique du service AD64 1. Architecture générale Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques... »

2026-09-10T13:03:20Z

Page créée avec « Bilan technique du service AD64 1. Architecture générale Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques... »

Nouvelle page

Bilan technique du service AD64
1. Architecture générale
Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques distinctes :
- Saturne3 / VM 507 « AD64 » : hébergement de la plateforme applicative Pleade 4.5 ;
- eole3 : stockage des données AD64, mise à disposition NFS pour la VM, accès SFTP, réception des synchronisations provenant du serveur du client et snapshots ZFS ;
- beotos3 / PBS4 : sauvegarde des données et des systèmes.
Les données volumineuses ne sont donc pas stockées dans la VM applicative : celle-ci dispose d'un disque système dédié et accède aux données AD64 hébergées sur eole3 par NFS.
2. Plateforme applicative – VM 507 AD64
La plateforme est hébergée sur la VM 507 – AD64, sur l'hyperviseur Proxmox Saturne3.
Ressources de la VM
Ressource Configuration
CPU 8 vCPU – 2 sockets × 4 cœurs
Mémoire 64 Gio maximum
Ballooning minimum 16 Gio
Disque système 100 Go
Contrôleur VirtIO SCSI
Stockage Proxmox local-zfs
Réseau applicatif 10.0.0.41/24
Réseau données 192.168.123.41/24

Le disque virtuel de 100 Go est hébergé sur un pool ZFS constitué de 4 SSD NVMe Samsung d'environ 960 Go, organisés en RAIDZ1. Le pool est actuellement ONLINE et ne présente aucune erreur ZFS connue.
Le système de fichiers de la VM occupe environ 36 Go sur 99 Go, soit environ 37 %.
Environnement logiciel
Composant Version
Application Pleade 4.5
Système Ubuntu 26.04 LTS – Resolute Raccoon
Noyau Linux 7.0.0-30-generic
Apache HTTP Server 2.4.66
Java OpenJDK 17.0.20 – 64 bits
Apache Tomcat 9.0.98
MariaDB 11.8.6

Trois instances Tomcat Pleade 4.5 sont installées :
Instance Fonction
internet site Internet
preprod préproduction
slecture salle de lecture

Les trois utilisent Tomcat 9.0.98 et OpenJDK 17.0.20.
Lors du contrôle, les trois JVM fonctionnaient normalement et la VM ne présentait aucune pression significative sur la mémoire ou le CPU.
Accès aux données
Les données sont montées depuis eole3 en NFSv4.2 :
192.168.123.202:/var/data/ad64-data/data
→
/var/data/ad64-data/data
La liaison utilise le réseau interne 192.168.123.0/24.
Observation système
Un épisode de soft lockup Linux a été enregistré le 6 septembre 2026, affectant simultanément plusieurs vCPU, notamment des threads Java/GC et kcompactd.
Aucune nouvelle occurrence n'a été observée lors des contrôles ultérieurs et la charge actuelle de la VM est faible. Cet événement est donc à surveiller, sans signe actuel de dysfonctionnement du service.
3. Stockage des données – eole3
eole3 assure le stockage principal des données AD64.
Le dataset ZFS est :
data/clients/ad64-data
monté sous :
/var/data/ad64-data
Capacité
Capacité État
Volume total ~35 To
Utilisé ~28 To
Disponible ~7,5 To
Occupation ~79 %

Le volume reste donc opérationnel avec une réserve d'environ 7,5 To, mais son évolution doit être surveillée compte tenu de son taux d'occupation.
La partie utilisée par Pleade est située sous :
/var/data/ad64-data/data
et est accessible à la VM 507 par NFS.
4. Synchronisation des données du client vers eole3
Les données provenant du serveur des AD64 sont synchronisées quotidiennement vers eole3.
La connexion ne pouvant être initiée depuis AJLSM vers le serveur du client, le transfert fonctionne obligatoirement en PUSH depuis le serveur AD64 :
Serveur AD64
│
│ SSH + rsync
▼
eole3
51.178.110.230
Le transfert est programmé quotidiennement à :
17 h 02
Il utilise une clé SSH dédiée et rsync.
Le périmètre actuel comprend notamment les images, fichiers attachés, EAD, CDC, CSV, FLV, fichiers, documents Excel, lecteurs, NC, PDF et réservations, pour les environnements concernés.
Le transfert ne comporte volontairement pas de --delete : la synchronisation entrante ne supprime donc pas automatiquement sur eole3 les données absentes de la source.
État : opérationnel.
5. Accès SFTP aux données
eole3 héberge également le service SFTPGo utilisé pour l'accès sécurisé aux données :
sftpgo.ajlsm.com:2022
Le service est activé et fonctionnel.
Le compte ad64 est actif et dispose de deux espaces virtuels principaux :
/pleade
/projets
correspondant aux espaces physiques :
/var/data/ad64-data/data/pleade
/var/data/ad64-data/data/projets
Les droits sont définis finement selon les sous-répertoires. Les espaces de production permettent notamment les opérations nécessaires de dépôt, téléchargement, remplacement, création de répertoires, renommage et suppression.
Aucun quota SFTPGo spécifique n'est imposé au compte AD64.
Point de vigilance
Le contrôle a montré que SFTPGo écoute également sur le port 8080 sur toutes les interfaces et que des requêtes externes atteignent ce service.
Cela ne constitue pas en soi la constatation d'une compromission, mais l'exposition du port 8080 devra être revue afin de vérifier qu'elle correspond bien à la politique d'accès souhaitée.
6. Snapshots ZFS
Les données AD64 font l'objet de snapshots ZFS automatiques gérés par Sanoid 2.2.0.
AD64 utilise le profil :
template_tres_gros_volume
avec la politique suivante :
hourly = 2
daily = 1
monthly = 0
autosnap = yes
autoprune = yes
Sont donc conservés :
- les 2 derniers snapshots horaires ;
- le dernier snapshot quotidien.
Les snapshots sont créés et purgés automatiquement.
Ils permettent notamment de revenir rapidement sur un état antérieur du volume en cas de suppression ou modification accidentelle récente.
Une évolution possible, non mise en œuvre actuellement, consisterait à effectuer la sauvegarde vers beotos3 depuis un snapshot ZFS figé plutôt que depuis les données actives. Cela garantirait une image temporellement cohérente lors des périodes de publication intensive.
7. Sauvegarde des données AD64 sur beotos3
Les données hébergées sur eole3 sont sauvegardées vers beotos3.
Contrairement à la synchronisation provenant du client, cette opération est initiée depuis le serveur de sauvegarde :
eole3
192.168.123.202
│
│ rsync PULL
▼
beotos3
/var/data/ad64-data
La sauvegarde est programmée :
chaque vendredi à 18 h 59.
Elle utilise rsync via SSH avec une limitation de priorité CPU/IO afin de ne pas perturber les autres services.
Le mode réel de sauvegarde est désormais :
DRY_RUN=0
QUARANTINE_ENABLED=1
QUARANTINE_RETENTION_DAYS=7
Les suppressions nécessaires au maintien du miroir sont donc appliquées, mais les éléments concernés sont conservés temporairement dans une quarantaine pendant 7 jours avant leur purge.
Les volumes importants de suppressions et créations observés lors du contrôle sont cohérents avec le fonctionnement de Pleade : les opérations de publication suppriment puis régénèrent de grands ensembles de fichiers.
État : sauvegarde réelle réactivée ; prochaine exécution à contrôler après le premier cycle.
8. Sauvegardes de la VM 507
La VM AD64 est incluse dans trois dispositifs de sauvegarde Proxmox distincts.
Sauvegarde PBS4
Exécution quotidienne :
21 h 00
Destination :
PBS4
Rétention :
- 7 quotidiennes ;
- 3 dernières sauvegardes ;
- 3 hebdomadaires ;
- 2 mensuelles.
Mode snapshot Proxmox.
Sauvegarde locale
Exécution quotidienne :
23 h 00
Destination :
local
Compression ZSTD, mode snapshot.
Rétention :
1 sauvegarde quotidienne.
Sauvegarde vers beotos3
Exécution :
02 h 00
Destination :
beotos3-import-saturne3
Compression ZSTD, mode snapshot.
Rétention :
- 3 hebdomadaires ;
- 1 mensuelle.
Bien que cette sauvegarde soit annotée « Hebdomadaire » dans Proxmox, son calendrier est 02:00 sans restriction de jour : le job est donc lancé quotidiennement, la politique de rétention étant, elle, hebdomadaire et mensuelle.
Les trois jobs sont activés et la VM 507 figure explicitement dans leur périmètre. Une notification par courrier électronique est configurée en cas d'échec.
9. Sauvegarde de la configuration d'eole3
Indépendamment des données AD64, eole3 fait lui-même l'objet d'une sauvegarde quotidienne de sa configuration vers PBS4.
Elle est exécutée chaque jour à :
02 h 30
Elle comprend notamment :
/etc
/usr/local
/root
/var/lib/sftpgo
/var/log
Cette sauvegarde permet de restaurer la configuration du serveur et du service SFTPGo ; elle ne remplace pas la sauvegarde des 28 To de données AD64.
Une sauvegarde spécifique de la configuration SFTPGo est également exécutée quotidiennement à 02 h 15.
10. État général du service
Composant État Observation
VM 507 AD64 🟢 Opérationnel Ressources largement suffisantes actuellement
Pleade 4.5 – Internet 🟢 Opérationnel Tomcat 9 / Java 17
Pleade 4.5 – Préproduction 🟢 Opérationnel Tomcat 9 / Java 17
Pleade 4.5 – Salle de lecture 🟢 Opérationnel Tomcat 9 / Java 17
Stockage eole3 🟢 Opérationnel 28 To / 35 To, occupation à surveiller
NFS eole3 → VM 507 🟢 Opérationnel NFSv4.2
Rsync client → eole3 🟢 Opérationnel PUSH quotidien 17:02
SFTPGo 🟢 Opérationnel ACL et montages validés
Snapshots ZFS 🟢 Opérationnel Sanoid automatique
Backups VM → PBS4 🟢 Configuré Quotidien 21:00
Backup VM local 🟢 Configuré Quotidien 23:00
Backup VM → beotos3 🟢 Configuré Job quotidien 02:00
Backup config eole3 → PBS4 🟢 Opérationnel Quotidien 02:30
Backup données eole3 → beotos3 🟠 À contrôler Réactivé en mode réel, prochain cycle à valider

Points de vigilance
Le service est globalement opérationnel et dispose de plusieurs niveaux complémentaires de protection : snapshots ZFS, sauvegarde des données sur un serveur distinct, sauvegardes multiples de la VM et sauvegarde PBS des configurations.
Trois points méritent néanmoins un suivi :
1. Stockage AD64 à 79 % : les ~7,5 To encore disponibles offrent une marge significative, mais l'évolution doit être suivie compte tenu du volume des publications.
2. Sauvegarde eole3 → beotos3 : le mode réel vient d'être réactivé après une période de simulation ; il convient de contrôler le prochain cycle complet et sa quarantaine.
3. SFTPGo / port 8080 : vérifier si son exposition externe est nécessaire et conforme à la politique de sécurité.
L'épisode isolé de soft lockup observé sur la VM le 6 septembre doit également rester sous surveillance, mais aucun symptôme de saturation ou de récidive n'est actuellement constaté.

Bilan technique AD64 - 2026 - Historique des versions

Jlarvers le 10 septembre 2026 à 13:04

Jlarvers : Page créée avec « Bilan technique du service AD64 1. Architecture générale Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques... »

Jlarvers : Page créée avec « Bilan technique du service AD64 1. Architecture générale Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques... »