Newsgroup: it.comp.os.linux.sys
Titolo: Stress-test storage

Supponiamo di dover implementare uno storage (non importa la tipologia)
Se volessi stressarlo a fondo, ad esempio: rimuovere dischi, spegnere uno o più
server, staccare cavi di rete, bloccare qualcosa via firewall, bla bla bla, 
mentre lui sta trasferendo grossi quantitativi di dati, che software usereste?
 
Sulla carta, basterebbe far partire la copia di /dev/zero all'infinito fino a
riempire tutti i dischi e poi ripartire da capo, ma questo non mi garantirebbe che,
in caso di problemi, i dati salvati siano consistenti.
 
A livello teorico, basterebbe avere un $tot di file sia di piccole che grosse 
dimensioni, con il loro hash precalcolato da qualche parte, iniziare a copiare 
tutto, cercare di spaccare il possibile in piena copia e verificare, alla fine, 
i vari hash. Se sono giusti, lo storage ha retto.
 
Altra alternativa: usare rsync: copiare $tantaRoba, spaccare il possibile durante 
la copia e, una volta finite le demolizioni, rieseguire rsync. Se tutto è OK, 
non deve sincronizzare nulla, perchè tutto presente nella destinazione.
 
Il problema però è: come riempio 50TB ? Esiste un software che faccia questo in 
automatico generando dati random e verificandone l'hash di volta in volta ?

 automatico generando dati random e verificandone l'hash di volta in volta ?
 
Se ti piace rsync copiando 5000 volte una directory di 10GB in un ciclo for.
 
Non riesco comunque a comprendere l'utilità della cosa... lo storage 
deve garantire che quel che gli arriva sia scritto, ma se stacchi cavi e 
la roba non gli arriva non è colpa dello storage se non la trovi scritta.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 la roba non gli arriva non è colpa dello storage se non la trovi scritta.
 
Non è uno storage classico ma scale-out, con ridondanza su più nodi
(Gluster, Moose, Lizard, Ceph, ........)
 
Ho necessità di capire come si comporta uccidendo vari pezzi (server metadata,
server storage, togliendo dischi brutalmente, mettendo dischi con settori +
danneggiati, "dd if=/dev/zero of=/path_disco" a caso, togliere cavi di rete,
togliere uno dei due switch, riavviare un nodo, .....) tutto questo mentre c'è
attività di I/O
 
Se tutto va bene, anche spaccando qua e la randomicamente, lui deve sopravvivere
e non creare inconsistenze.

 e non creare inconsistenze.
 
Non funziona proprio cosi`.
Una certa configurazione e` fatta per affrontare
certi problemi.
 
Non esiste "randomicamente", si deve prima decidere
quali problemi sono rilevanti e poi testare per quelli.
 
Solo in seguito, una volta stabilito che lo scenario
richiesto sia soddisfatto, si puo` pensare a danni
pseudo-casuali.
Come scritto sopra`, nel caso di "dd", questo dovrebbe
simulare qualcosa, non ha senso farlo a caso.
Anche perche`, facendo solo a caso, si potrebbe, sempre
casualmente, saltare proprio il test che serve.
 
Quindi, prima le specifiche, poi il test per le specifiche,
poi test casuali.
Questi ultimi servono per verificare che non vi siano
scenari imprevisti.
 
bye,
 
-- 
 
piergiorgio

 quali problemi sono rilevanti e poi testare per quelli.
 
Ovviamente. Ma i test che andrò ad eseguire sono pensati per
simulare determinati guasti. Il mio "randomico" è riferito non
alla tipologia dei test (che è ben definita), ma alla loro
successione. In pratica una mattina vado li e stacco un cavo
di rete. Poi magari il pomeriggio spengo uno switch, etc etc.
 

 di rete. Poi magari il pomeriggio spengo uno switch, etc etc.
 
Questo e` piu` ragionevole, dato che si tratta
di incidenti possibili.
 
bye,
 
-- 
 
piergiorgio

 realistico.
 
IMHO, si.
Comunque la questione non è "quali spaccature devo eseguire" bensì
"quale tool posso usare" per scrivere, verificare, modificare, rileggere (e via da capo) X terabyte di dati, in continuazione.
 
Hai presente quello che fa memtest86 ? Parte e va avanti all'infinito lavorando
sulla ram (scrive, legge, sposta, verifica, ...). Io devo fare la stessa cosa
sullo storage.

 sullo storage.
 
Ho capito, ma i test che vuoi fare richiedono
dei tool che dipendono dal test stesso.
Se il test e` inutile, non serve neanche cercare
tale tool. E` tempo sprecato.
D'altro canto fare 2 settimane di test che non
rappresentano un caso realistico e` ancora piu`
inutile.
Risulta in una perdita di tempo e in un sistema
non sicuro.
 
Quindi, per concludere, se chiedi un tool, si
potrebbe dire che "dd" non e` utile allo scopo.
D'altro canto, "dd" con l'opzione "seek" e
"notrunc" puo` cambiare byte di file a piacere.
Magari e` piu` realistico, anche se dubito.
 
bye,
 
-- 
 
piergiorgio

Il 23/09/2017 14:37, 
gandalf.co...@gmail.com
 ha scritto:
 > Supponiamo di dover implementare uno storage (non importa la tipologia)
 
[ CUT ]
 
 > Il problema però è: come riempio 50TB ? Esiste un software che faccia 
questo in
 > automatico generando dati random e verificandone l'hash di volta in 
volta ?
 >
io riutilizzerei la ruota già inventata da qualcuno altro.
 
https://www.coker.com.au/bonnie++/
 
https://www.jamescoyle.net/how-to/913-simple-bonnie-example
 
 
--
Massimiliano Adamo
 

 potrebbe dire che "dd" non e` utile allo scopo.
 
Non è utile, infatti cerco altro. "dd" era un test
brutale e rapido per fare "danni".
 
Ma so benissimo che non va bene allo scopo (se non per mettere
dentro dati, non per spaccare)...
 
Tant'è che inizialmente pensavo ad rsync ma è troppo intelligente, non
vorrei che avesse una sua "correzione di errore" e quindi possa mascherare
eventuali problemi temporanei allo storage.
 
Ho bisogno di un tool che al minimo errore dica: Hey, si è rotto.

 
https://www.jamescoyle.net/how-to/913-simple-bonnie-example
 
 
Lo ammetto, non sono capace ad usarlo (e men che meno interpretare
i dati di risposta)
 
Non penso che lui faccia scritture, verifiche e cancellazioni.
Mi sembra più un benchmark (del tipo: scrivo quanta più roba possibile
e guardo quando vado veloce)


probabile che tu abbia ragione. L'ho usato una sola volta 4 anni fa e 
ricordo a fatica.

 Ho bisogno di un tool che al minimo errore dica: Hey, si è rotto.
 
Da quello che so, "rsync", con l'opzione "-c" (o "-C",
non ricordo), controlla il checksum dei due file e
decide, se diverso, di fare la copia.
 
Per cui, ed io lo ho usato in questo modo, si puo` fare
una copia, poi fare il test, poi rifare la copia.
Se "rsync" copia di nuovo dei file, vuol dire che non
erano uguali (usando "-c" o "-C").
Il problema, al massimo, e` verificare che "rsync"
faccia la copia.
 
Un'altra possibilita` e` copiare dei file di cui si
e` pre-calcolato il md5.
Fare il test e ri-verificare il md5.
 
Tra l'altro questo puo` essere fatto in un loop,
cioe` in maniera continua (fatto anche questo).
 
bye,
 
-- 
 
piergiorgio

 eventuali problemi temporanei allo storage.
 
Rsync non è intelligente, si basa sul concetto semplice che il file sorgente
e il file di destinazione sono uguali, sostituendo quest'ultimo se il controllo
fallisce. Per intenderci, se stai copiando ricorsivamente una directory, ed
un file che rsync ha già copiato si  è corrotto, quel file rimarrà corrotto
finché non verrà riscritto da un altro giro di rsync
 
Enrico

 finché non verrà riscritto da un altro giro di rsync
 
Intendevo dire che magari *durante* il trasferimento di un *singolo* file,
rsync possa riprovare l'invio correggendo eventuali problemi temporanei.
 
Un banale "cp", se interrompi in qualsiasi modo la trasmissione, muore.
Magari rsync no, più volte mi è capitato di notare un rallentamento di alcuni 
secondi, sullo stesso file, per poi riprendere.
Questo non deve capitare, perchè se c'è un rallentamento, significa che lo storage
non è adeguato

 cioe` in maniera continua (fatto anche questo).
 
Ed è ciò che voglio evitare. Vorrei evitare di farmi uno script
da zero, che sicuramente può tralasciare qualche casistica e
che non sarà in grado di gestire la concorrenza.
 
Se ci fosse un tool che facesse tutto da solo, meglio.
 
Per intenderci, c'è anche "ab" per testare apache. Decidi quanto tempo,
quanti processi in parallelo, e via andare. In caso di errori, a fine
procedura, lui te li mostra.

Supponiamo di dover implementare uno storage (non importa la tipologia)
 
Eh, importa.
 
Perché quello che serve a te è circa l'equivalente di un "ping" per lo
storage, che ti dica se un certo blocco è stato persistito e in quanto
tempo (poi, tu decidi che sia un errore, sia un tempo eccessivono sono
entrambi fallimenti).
 
Però devi sapere che cosa pingare, altrimenti in un volume consistente
in 10 dischi separati potresti seguitare a scassare il disco Tizio nel
mentre che pinghi (testi) il disco Sempronio, e avere risultati ottimi
per puro sedere.
 
Quindi no, ti serve un qualcosa del tipo "stòrami 'sto file nella zona
logica X" (che corrisponderà ai dischi AAA e BBB, se corrisponde ad un
disco solo hai digià perso), e mentre lui pinga X tu scassi AAA oppure
BBB (se scassi entrambi niente funziona, tante grazie). Oppure, scassi
la comunicazione fra AAA e BBB. Oppure boh: anche quello dipende dalla
tipologia.
 
Un software come lo vuoi tu non può essere generalista, a meno che sia
l'OS a decidere sempre dove mandare i file e decida sempre di mandarli
sullo X in quel momento più sicuro, nel qual caso non ti serve neanche
il software (C.V.D.), basta tu scassi una cosa a caso mentre fai cp.
 
Leonardo
 
-- 
 
Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

 per puro sedere.
 
Il test lo faccio con 1 solo disco, non con 10, altrimenti diventerebbe troppo
complesso. Ho bisogno di verificare come è gestito il fault-tollerance, ed
1 disco è più che adeguato.
 
Potrei usare benissimo "cp" come suggerisci tu, ma per forza di cose poi devo
verificarne l'hash finale, quindi:
 
a) genero un file da 2TB
b) calcolo l'hash
c) inizio la copia
d) spacco tutto
e) quando "cp" termina (se termina, è già parzialmente un successo) ricalcolo l'hash
f) se hash2 == hash1, epic win
 
Questo va bene, ma se ci fosse uno script che oltre a copiare 1 file riuscisse
a stressare lo storage facendo molte più operazioni contemporaneamente, sarebbe
meglio. E' questo il mio problema.
 
"cp" mi obbliga per forza a fare un test alla volta e deve essere monitorato.
Io vorrei poterlo far andare 1 settimana di fila, stressando lo storage ed allo
stesso tempo simulando vari danni.

meglio. E' questo il mio problema.
 
Ma anche no, scusa. La pipeline, quella è. Non è che un trasferimento di
file stressa una rete più di 100 trasferimenti simultanei. Salvo qualche
configurazione particolarmente esoterica. Per il disco è simile. Sarà il
kernel che locka il dispositivo, una volta sola, poi l'IOSS accoderà "N"
processi che vogliono scrivere. Di nuovo, qui avere processi separati ti
consente di stimare quanto è lo starving su ciascun processo (se c'è). A
fare tutto con un solo script questa visibilità non ce l'hai (o ce l'hai
molto meno).


 molto meno).
 
Ok, allora non ho spiegato bene sin dall'inizio cosa voglio fare.
Io *NON* voglio testare il disco. Devo testare un SDS (Gluster, Lizard, Ceph,
quel che ti pare).
 
Scrivere su un SDS non equivale a scrivere su un disco, stai comunicando con
un software (spesso con FUSE di mezzo), non direttamente con il kernel/FS,
che distribuisce i dati, li 'spacchetta' in oggetti più piccoli e li salva
qua è la, per poi ricomporli in fase di lettura.
 
Qui è il software che, eventualmente, accoda le richieste.
Io lo devo stressare, per vedere se tiene botta o se collassa prima o se
magari con un I/O massiccio inizia a dare i numeri.
 
Ho necessità di vedere cosa succede se, durante un massiccio I/O che possa
simulare decine e decine (centinaia?) di VM belle cariche (che non so come simulare), lui
è in grado di gestire il tutto senza corrompere dati. In aggiunta a questo,
sempre durante lo stesso massiccio I/O, devo poter iniziare a rimuovere
componenti A CALDO per verificare se il SDS è in grado di fare fileover senza
soluzione di continuità e, ancor più importante, senza corrompere dati.
 
Se durante un crash le VM si freezano per qualche secondo, potrebbe starmi bene
(no, non è vero, ma è sopportabile), ma se dopo il crash mi trovo con l'immagine
qcow corrotta, questo sarebbe intollerabile.
 
Per un SDS gestire un singolo client che sta copiando un singolo file è quasi
sicuramente diverso rispetto a gestirne, con la dovuta concorrenza, decine se non
centinaia che scrivono (e magari che operano in simultanea sullo stesso file).
 
Deve gestire la concorrenza, il locking, etc etc e mentre fa tutto questo, deve
gestire il failover e la replica una volta che ho ripristinato il guasto.
 
No, non devo controllare un disco, devo stressare un SDS, l'avevo scritto all'inizio.
 
Un singolo "dd" non stressa niente, mi dice solo se i file vengono salvati
correttamente.

soluzione di continuità e, ancor più importante, senza corrompere dati.
 
Okay. Allora quello che ti serve è "semplicemente" un programma che apra un
file e generi un indirizzo casuale, all'interno del file stesso, a multipli
di 64 Kb (per farla semplice).
 
Poi, in quei 64 Kb legge o scrive un blocco pseudocasuale (per esempio, una
longword random, seguita da 65532 byte generati da un PRNG inizializzato da
quella longword). In questo modo, controllare se il blocco è valido è molto
semplice, e la probabilità che due processi scrivano lo stesso blocco molto
bassa.
 
(Problema: che strategia usa per lockare il file? Devi poterla scegliere!).
 
Per ogni I/O il programma cronometra quanto ci mette e mantiene i valori di
minima, massima, somma delle attese e somma dei quadrati delle attese <g>.
 
Lanci X programmi in parallelo su un file di 50 TB, e alla fine (o, magari,
quando ricevono SIGUSR1) i vari programmini sparano le statistiche dentro a
/var/storping.$PID .


 /var/storping.$PID .
 
Benissimo.
Esiste un tool? Vorrei evitare di reinventare la ruota ?

On Tue, 26 Sep 2017 10:57:20 -0700 (PDT), 
gandalf.co...@gmail.com
 
wrote:

Che io sappia no, ma non dovrebbe essere difficile costruirselo in, tipo,
Python.
