Testare il Cold Storage con Rclone: un piano di test pratico
Prima che un servizio legga i propri file dal cloud tramite un mount Rclone, occorre verificare più del semplice accesso alle directory. Questo piano di test copre Cold Read, Warm Read, operazioni di scrittura, comportamento della cache, integrità dei file e guasti.
Un mount Rclone si configura rapidamente. Il remote appare come una directory, ls mostra i file e il primo test funzionale è superato. Tuttavia, questo dice ancora poco sull’uso in produzione.
Non appena un servizio accede al mount, sorgono ulteriori domande: quanto dura il primo accesso a un file? Quali accessi vengono serviti dalla cache locale? Cosa accade a un file non ancora caricato se Rclone si arresta? Un container in esecuzione vede nuovamente il mount ricreato? E come reagisce il servizio se il cloud è temporaneamente irraggiungibile?
Questo articolo fornisce un piano di test generale. Può essere utilizzato per un archivio di documenti, un media server, una gestione di foto o qualsiasi altro servizio che recuperi file usati raramente tramite Rclone da un Cold Storage.
Le opzioni principali di rclone
Per orientarsi, ecco le opzioni Rclone presenti in questo piano di test, tradotte liberamente dalla documentazione:
Gli elenchi completi sono disponibili nella documentazione di Rclone, in particolare in rclone mount e nella panoramica dei flag globali.
Definire innanzitutto ciò che si vuole ottenere
Cold Storage non significa automaticamente la stessa cosa per ogni applicazione. Un media server legge generalmente file grandi in modo sequenziale. Una gestione di foto carica molti piccoli dati di anteprima e salta a posizioni diverse. Un archivio di documenti apre file relativamente piccoli, ma spesso una sola volta.
Prima del test, annotate le caratteristiche più importanti del vostro archivio reale:
- dimensione tipica dei file e file più grande presente
- numero di file per directory
- lettura completa o accessi casuali a singole aree
- rapporto tra accessi in lettura e scrittura
- numero di utenti o processi simultanei
- modifiche effettuate direttamente nel remote al di fuori del mount
- tempo di attesa accettabile per un Cold Read
- spazio massimo disponibile per la cache locale
Solo da questi elementi derivano criteri di successo sensati. Aprire un singolo file in 1,2 secondi può essere perfettamente accettabile per un archivio e inutilizzabile per un’applicazione interattiva.
Generare un set di dati di test riproducibile
Rclone include già uno strumento adatto. rclone test makefiles genera ogni volta lo stesso albero di file con un seed fisso:
rclone test makefiles ./testdata \
--seed 42 \
--files 250 \
--files-per-directory 25 \
--min-file-size 16K \
--max-file-size 32MAdattate numero e dimensioni al vostro insieme di dati reale. Non testate solo file di dimensione media. Alcuni file molto piccoli mostrano quanto siano costosi gli accessi ai metadati; alcuni file grandi rendono visibili throughput, read-ahead e comportamento della cache.
Aggiungete inoltre nomi di file che potrebbero causare problemi nella pratica:
mkdir -p "testdata/Sonderfälle/Unterordner"
printf 'Leerzeichen\n' > "testdata/Sonderfälle/Datei mit Leerzeichen.txt"
printf 'Umlaute\n' > "testdata/Sonderfälle/Grösse und Änderung.txt"
printf 'Grossschreibung\n' > "testdata/Sonderfälle/Test.txt"
printf 'Kleinschreibung\n' > "testdata/Sonderfälle/test.txt"L’ultimo test è particolarmente importante se il file system locale e il backend cloud trattano in modo diverso maiuscole e minuscole.
Se il vostro servizio accetta solo determinati formati, file binari arbitrari non sono sufficienti. In tal caso, generate anche file sintetici esattamente in questi formati. Con Paperless-ngx si trattava di PDF con un vero livello di testo, affinché il test non misurasse per errore le prestazioni OCR invece del percorso di archiviazione. Per una gestione di foto, l’insieme deve includere diverse dimensioni e formati di immagine; per un media server, file brevi con codec diversi.
Una misurazione di riferimento senza mount
Prima che entrino in gioco FUSE e la cache VFS, dovreste misurare direttamente il backend. Copiate l’insieme di dati nel remote di test con Rclone e salvate un log dettagliato:
rclone copy ./testdata remote:cold-storage-test \
--progress \
--stats 5s \
--log-file rclone-copy.log \
--log-level INFOVerificate poi che origine e destinazione corrispondano:
rclone check ./testdata remote:cold-storage-test \
--one-way \
--download--download è decisivo in questo caso, perché alcuni backend non forniscono hash adeguati. Il confronto richiede più tempo, ma offre una base utile per il successivo test di integrità.
Annotate tempo di upload, velocità di trasferimento, numero di retry ed errori API. Se già l’accesso diretto è instabile, il mount non può risolvere il problema.
Separare il mount di test dalla cache di produzione
Per le misurazioni, utilizzate un punto di mount e una directory di cache dedicati:
rclone mount remote:cold-storage-test /mnt/rclone-test \
--vfs-cache-mode full \
--cache-dir /var/cache/rclone-test \
--vfs-cache-max-size 10G \
--vfs-cache-poll-interval 1m \
--allow-other \
--log-file /var/log/rclone-test.log \
--log-level INFOI valori sono un esempio e non una raccomandazione generale. Ciò che conta è la separazione: una cache di test vuota rende riproducibili i Cold Read senza dover eliminare file da una cache di produzione in uso.
--vfs-cache-mode full è generalmente la modalità di test più istruttiva per le applicazioni. Rclone memorizza localmente nella cache gli accessi in lettura e scrittura e può rappresentare meglio accessi ai file che non sarebbero possibili con un puro object storage. La compatibilità aggiuntiva richiede spazio locale.
Verificare sempre dal punto di vista del servizio reale
Un mount può funzionare per il vostro utente ma risultare comunque inutilizzabile per il servizio. Cause frequenti sono un ID utente diverso, l’assenza di --allow-other, limiti dei container o una propagazione del mount errata.
Eseguite quindi almeno un accesso in lettura completo con la stessa identità con cui verrà eseguita in seguito l’applicazione:
sudo -u <service-user> sha256sum /mnt/rclone-test/pfad/zur/dateiSe il servizio viene eseguito in Docker, il test deve essere effettuato nel container:
docker exec --user <uid>:<gid> <app-container> \
sha256sum /pfad/im/container/dateiAncora meglio è un test dell’applicazione reale. Aprite il file tramite l’interfaccia web o l’API del servizio. Solo così noterete se l’applicazione, ad esempio, avvia più letture parallele, salta alla fine del file o richiede metadati aggiuntivi.
Misurare separatamente Cold Read e Warm Read
Con --vfs-cache-mode full esistono tre livelli tra l’applicazione e il cloud:
| Livello | Cosa contiene |
|---|---|
| Remote | il file completo nel servizio cloud |
| Cache VFS | aree memorizzate localmente di file già letti |
| Linux Page Cache | dati utilizzati di recente nella RAM |
Per un Cold Read, scegliete un file il cui contenuto non sia mai stato letto tramite il mount di test. Nel Warm Read effettuato immediatamente dopo, il file si trova nella cache VFS e di norma anche nella RAM.
measure_read() {
file="$1"
label="$2"
start=$(date +%s%3N)
cat "$file" > /dev/null
end=$(date +%s%3N)
printf '%s: %s ms\n' "$label" "$((end - start))"
}
measure_read "/mnt/rclone-test/grosse-datei.bin" "Cold Read"
measure_read "/mnt/rclone-test/grosse-datei.bin" "Warm Read"Non misurate un solo file. Utilizzate almeno dieci file di dimensioni diverse mai letti in precedenza e annotate mediana, valore più lento e dimensione del file. Un singolo valore migliore non è una base per decidere.
Un Warm Read non è un puro test del disco, perché il kernel può mantenere in RAM parti del file. Per la maggior parte degli scenari Cold Storage non è un problema. Ciò che conta è ciò che un utente sperimenta alla prima apertura e alle aperture successive. Se volete valutare separatamente RAM e disco locale, dovete controllare e svuotare in modo dimostrabile anche la page cache.
Non testare solo letture complete
cat legge un file dall’inizio alla fine. Molte applicazioni si comportano diversamente:
- Un lettore video legge dapprima header e indice, salta in seguito a un’altra posizione e poi continua a caricare in modo sequenziale.
- Una gestione di immagini legge i metadati e genera poi un’anteprima.
- Un programma di archiviazione può leggere prima la fine del file.
- Più worker possono accedere contemporaneamente a file diversi.
Testate questi flussi con l’applicazione effettiva. Osservate parallelamente il log di Rclone e la cache. Per i file grandi, è interessante vedere quanto Rclone memorizzi davvero localmente e se --vfs-read-ahead si adatti al modello di accesso.
Inoltre, un mount Rclone non è una posizione di archiviazione sensata per database o altri file che richiedono locking affidabile e modifiche frequenti all’interno dello stesso file. Il layer VFS compensa le differenze tra file system e object storage, ma non trasforma il backend in un file system locale.
Collaudare separatamente il percorso di scrittura
Se il servizio legge soltanto, montate il remote in sola lettura quando possibile. Se deve scrivere, testate separatamente creazione, sovrascrittura, rinomina ed eliminazione.
Un file scritto non compare necessariamente subito nel remote. Con la cache VFS attiva, l’upload inizia solo dopo che il file è stato chiuso e --vfs-write-back è trascorso. Verificate quindi entrambi gli stati:
- L’applicazione ha chiuso il file correttamente.
- Il file è poi leggibile nel remote tramite un accesso diretto con Rclone.
printf 'writeback-test\n' > /mnt/rclone-test/writeback-test.txt
# Dopo la scadenza di --vfs-write-back:
rclone cat remote:cold-storage-test/writeback-test.txtRipetete il test con un file grande e terminate Rclone mentre l’upload è ancora in corso. Riavviate poi usando la stessa directory di cache e controllate se l’upload riprende. Proprio questa finestra temporale determina quanti dati siano a rischio in caso di guasto del server.
Testate anche rinomina ed eliminazione. Molti backend cloud rappresentano queste operazioni in modo diverso da un file system locale. Non è rilevante solo che il comando termini con successo, ma anche quando la modifica diventa visibile tramite un accesso diretto al remote e per altri client.
Testare le modifiche al di fuori del mount
I file possono essere modificati tramite l’interfaccia web del provider, un secondo processo Rclone o un altro server. Il mount non vede sempre subito tali modifiche, poiché le informazioni delle directory sono memorizzate nella cache.
Create quindi un file direttamente nel remote con una seconda chiamata Rclone:
printf 'external-change\n' > external-change.txt
rclone copyto external-change.txt \
remote:cold-storage-test/external-change.txtMisurate quando il file appare nel mount. Ripetete il test per modifica ed eliminazione. Il risultato dipende dal backend, dal suo supporto per il polling, nonché da --poll-interval e --dir-cache-time. Se l’applicazione deve vedere subito le modifiche attuali, questo comportamento deve rientrare esplicitamente nei criteri di accettazione.
Con l’interfaccia Remote Control attivata, potete svuotare in modo mirato la cache delle directory:
rclone rc vfs/forgetQuesto è utile per un test manuale, ma non sostituisce una strategia operativa adeguata.
Mettere la cache sotto pressione
Una cache quasi vuota è il caso più semplice. In un secondo ciclo di test, impostate intenzionalmente --vfs-cache-max-size su un valore basso e leggete più dati di quanti ve ne possano entrare.
du -sh /var/cache/rclone-test/vfs
du -sh --apparent-size /var/cache/rclone-test/vfs
find /var/cache/rclone-test/vfs -type f | wc -lLe due dimensioni possono differire notevolmente. In modalità Full, Rclone usa sparse file: un file mostra la sua intera dimensione logica, anche se solo le aree lette occupano spazio locale.
Inoltre, il limite della cache è soft. Rclone lo controlla con la frequenza di --vfs-cache-poll-interval, e i file aperti non possono essere rimossi. La cache può quindi superare temporaneamente il limite. Tuttavia, dopo la chiusura dei file e il successivo ciclo di pulizia dovrebbe tornare a ridursi.
Registrate il valore di picco, il valore dopo la pulizia e il tempo necessario. In questo modo è possibile dimensionare in modo ragionevole lo spazio locale necessario.
Simulare due guasti diversi
Un cloud irraggiungibile e un processo Rclone arrestato sono due errori differenti:
| Guasto | Cosa viene verificato |
|---|---|
| Backend o rete irraggiungibili, Rclone continua a funzionare | Comportamento con retry, timeout e file già memorizzati nella cache |
| Processo Rclone terminato | Comportamento del mount FUSE e ripristino del punto di mount |
Simulate entrambi solo nell’ambiente di test. Per il secondo caso, potete terminare forzatamente un container Rclone:
docker kill --signal KILL <rclone-container>Durante il guasto, verificate l’applicazione e non solo il punto di mount:
- Quali funzioni rimangono disponibili?
- Quanto attende un accesso prima che compaia un errore?
- I file già interamente memorizzati nella cache sono ancora accessibili?
- L’applicazione interrompe le nuove operazioni di scrittura?
- Compare un messaggio di errore comprensibile oppure solo un processo bloccato?
- Il monitoraggio si attiva?
Un servizio di scrittura non deve scrivere inosservato nella directory locale sottostante quando il mount è assente. Dopo il ritorno del mount, questi file verrebbero nascosti. Una semplice protezione prima di ogni job di scrittura è:
mountpoint -q /mnt/rclone-test || exit 1Dopo il riavvio di Rclone, controllate il mount sull’host e da ogni container che lo utilizza. Un mount ricreato raggiunge un container già in esecuzione solo con la corretta propagazione del mount. Per Docker, sul lato che lo utilizza è generalmente necessario rslave. I dettagli sono disponibili nell’articolo Gestire in modo affidabile i mount Rclone in Docker.
Un esempio concreto con Paperless-ngx
Per il mio test con Paperless ho generato 40 PDF per un totale di 13,9 MB. Un documento mai aperto prima ha richiesto circa 1,8 secondi; un accesso ripetuto immediatamente ha richiesto da 19 a 24 millisecondi. Una cache VFS limitata a 4 MB è salita temporaneamente a 12,7 MiB ed è stata ripulita al ciclo successivo.
Mentre il remote non era raggiungibile, l’elenco dei documenti, la ricerca full-text e le anteprime hanno continuato a funzionare, perché questi dati erano locali. Solo l’originale non poteva essere aperto. Dopo il ripristino del mount, il container Paperless in esecuzione ha potuto nuovamente accedere ai file senza dover essere riavviato.
Questi numeri non sono un benchmark per Rclone o Proton Drive. È interessante il comportamento: l’Hot Storage è rimasto disponibile localmente, i Cold Read erano più lenti ma prevedibili e il servizio si è ripreso dopo il guasto.
Cosa includere nel protocollo di test
Un risultato tracciabile anche in seguito contiene almeno:
- versione di Rclone e backend utilizzato
- sistema operativo, variante FUSE e file system della directory di cache
- comando di mount completo senza credenziali
- numero, distribuzione delle dimensioni e struttura dei file di test
- valori di Cold Read e Warm Read per più file
- durata della scrittura fino alla visibilità nel remote
- valore di picco della cache e durata della pulizia
- risultato di
rclone check --download - comportamento in caso di guasto del backend e processo Rclone terminato
- tempo di ripristino dal punto di vista dell’applicazione
- retry, timeout, limitazioni e errori di autenticazione nel log
Definite in anticipo un valore limite per ogni punto. Così il test termina con una decisione e non solo con una raccolta di numeri interessanti.
Quando la configurazione è pronta
Un mount Cold Storage è pronto all’uso se potete rispondere sì a queste domande:
- I Cold Read sono abbastanza rapidi per il servizio previsto?
- La cache accelera gli accessi ripetuti come previsto?
- Il fabbisogno di spazio locale resta controllabile anche sotto carico?
- Tutti i file corrispondono dopo un download completo?
- Tutte le operazioni sui file necessarie funzionano con il backend scelto?
- L’applicazione si comporta in modo controllato in caso di guasto del cloud?
- Le operazioni di scrittura vengono interrotte in sicurezza quando il mount è assente?
- Un mount ricreato raggiunge tutti i consumer in esecuzione?
- Il monitoraggio segnala il guasto prima che lo segnali un utente?
Se manca una risposta, sapete almeno esattamente su cosa dovete continuare a lavorare. È molto più utile di un mount che al primo ls sembrava valido e mostra i suoi limiti solo durante l’esercizio.
Commenti
I commenti vengono caricati da GitHub / Giscus.