Newsgroup: it.comp.os.linux.sys
Titolo: Bacula e LTO-5...

 
Uso da qualche annetto Bacula, e passato che devi imparare a ragionare come
vuole lui, non mi ci trovo malissimo.
 
Finora l'ho usato come sistema di backup ''accessorio'', su file. Ora sto
inziando a sperimentarlo su nastro (singolo, non changer).
 
 
Faccio un backup di test:
 
 08-giu 10:05 sanvito-dir JobId 21: No prior Full backup Job record found.
 08-giu 10:05 sanvito-dir JobId 21: No prior or suitable Full backup found in catalog. Doing FULL backup.
 08-giu 10:06 sanvito-dir JobId 21: Start Backup JobId 21, Job=Lupus.2016-06-08_10.05.59_04
 08-giu 10:06 sanvito-dir JobId 21: Using Device "LTOStorage"
 08-giu 10:06 lupus-fd JobId 21: shell command: run ClientRunBeforeJob "/etc/bacula/scripts/debian-client-before"
 08-giu 10:08 ashpool-sd JobId 21: Wrote label to prelabeled Volume "Ashpool002" on device "LTOStorage" (/dev/nst0)
 08-giu 15:17 ashpool-sd JobId 21: Job write elapsed time = 05:09:25, Transfer rate = 15.93 M Bytes/second
 08-giu 15:19 sanvito-dir JobId 21: Bacula sanvito-dir 5.2.6 (21Feb12):
 
E sedici giga di trasnfer rate mi sembrano pochini; vado a cercare ni rete
un po' di info e scopro che dovrei riuscire anche a saturare la ethernet
gigabit con un LTO-5 (50-60GBit/s), e finisco su :
 
 
http://www.bacula.org/5.2.x-manuals/en/problems/problems/Testing_Your_Tape_Drive.html#SECTION00422000000000000000
 
 
http://www.bacula.org/5.2.x-manuals/en/problems/problems/Testing_Your_Tape_Drive.html#SECTION00480000000000000000
 
 
al che aggiungo alla definizione dello storage/Device:
 
  Maximum File Size = 10GB
  Maximum Network Buffer Size = 65536
  Maximum Spool Size = 100G
  Maximum Job Spool Size = 25G
 
riprovo e...
 
 10-giu 23:00 sanvito-dir JobId 31: Start Backup JobId 31, Job=Lupus.2016-06-10_23.00.00_38
 10-giu 23:00 sanvito-dir JobId 31: Using Device "LTOStorage"
 10-giu 23:00 lupus-fd JobId 31: shell command: run ClientRunBeforeJob "/etc/bacula/scripts/debian-client-before"
 10-giu 23:03 ashpool-sd JobId 31: Wrote label to prelabeled Volume "Ashpool003" on device "LTOStorage" (/dev/nst0)
 11-giu 04:35 ashpool-sd JobId 31: Job write elapsed time = 05:32:32, Transfer rate = 14.84 M Bytes/second
 11-giu 04:38 sanvito-dir JobId 31: Bacula sanvito-dir 5.2.6 (21Feb12):
 
 
Dove sbaglio? Grazie.
 
-- 
  Quante persone che non contano, e invece contano
  e si stanno contando gia`
  Stanno solo aspettando un segno, Capata`z		(F. De Gregori)


Dico 'na cavolata.
ricordo di aver letto da qualche parte (mi pare un greenbook di Computer 
associates ma non ne sono sicuro) che per tirare al massimo gli LTO non 
devi mai andare in "buffer underrun" (uso un paragone in voga con i 
masterizzatori SCSI di quando avevo più capelli).
In altre parole, per avere un buon data transfer la sorgente deve 
trasmettere uno stream continuo, perchè in caso contrario l'LTO si deve 
fermare, riavvolgere un pezzo di nastro e poi ripartire.
Non a caso i sistemi "grossi" (ho la "fortuna" di giocherellare con 
TSM....) fanno molto spesso  Disk to disk to Tape, immagino anche per 
questo motivo (non ho memoria che nei redbook del tsm sia citato questo 
aspetto, ma non me ne meraviglierei)
Comunque 60 Gbps mi sembrano tantini, diciamo che a naso mi aspetterei
intorno ai 5 GB/sec (sono un po' indietro con l'hw)
 
Saluti
 
-- 
Luca
http://www.civinini.net
 
 
"Unix is simple. It just takes a genius to understand its simplicity." - 
Dennis Ritchie

 intorno ai 5 GB/sec (sono un po' indietro con l'hw)
 
Ahem, beh, ho sbagliato ovviamente unità di misura, scusate... intendevo
50/60 Mbyte/s... invece di 15...
 
-- 
  chi si convertiva nel novanta
  ne era dispensato nel novantuno			(F. De Andre`)


OK, siamo in due ad aver sbagliato unità di misura, intendevo 5 
GB/minuto.... Diciamo circa 100 MB/s vuoto per pieno..
In ogni caso, con 100 MB/sec si "satura" bene una rete a 1 Gbps e forse 
si sbatte anche il naso sui limiti dell'interfaccia del tape..
 
Comunque, se putacaso il tuo "file daemon" di bacula (mi pare di 
ricordare si chiamasse così la componente che aveva i dati da 
backuppare.. ma son passati anni) smette per un attimo di mandare lo 
stream al tuo storage daemon, l'LTO rischia di fermarsi e ripartire...
 
Io proverei la soluzione "ad orecchio": di solito si riesce a sentire 
(almeno sui drive singoli, sulle librerie non ce l'ho fatta) quando il 
nastro si ferma e viene riavvolto. Ovviamente se la tua sala server non 
è troppo rumorosa :-)
 
E speriamo stavolta di non aver scritto sfondoni con le unità di misura!


 50/60 Mbyte/s... invece di 15...
 
OK, ho scoperto 'btape' e che ha una bella funzionalità di test; il manuale
dice di scrivere una quantità di dati > RAM, quindi:
 
 root@3jane:~# free
              total       used       free     shared    buffers     cached
 Mem:      12258376   12132436     125940      60532     159324    3697380
 -/+ buffers/cache:    8275732    3982644
 Swap:     23811068          0   23811068
 root@3jane:~# btape /dev/nst0
 Tape block granularity is 1024 bytes.
 btape: butil.c:290 Using device: "/dev/nst0" for writing.
 speed file_size=5 nb_file=3
 btape: btape.c:477 open device "LTOStorage" (/dev/nst0): OK
 *btape: btape.c:1057 Test with zero data, should give the maximum throughput.
 [...]
 btape: btape.c:385 Total Volume bytes=16.10 GB. Total Write rate = 162.6 MB/s
 
 btape: btape.c:1069 Test with random data, should give the minimum throughput.
 btape: btape.c:906 Begin writing 3 files of 5.368 GB with raw blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=16.10 GB. Total Write rate = 55.15 MB/s
 
 btape: btape.c:1083 Test with zero data and bacula block structure.
 btape: btape.c:961 Begin writing 3 files of 5.368 GB with blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=16.10 GB. Total Write rate = 133.1 MB/s
 
 btape: btape.c:1095 Test with random data, should give the minimum throughput.
 btape: btape.c:961 Begin writing 3 files of 5.368 GB with blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=16.10 GB. Total Write rate = 55.15 MB/s
 
 *
 
3jane ha un 'vecchio' LTO-3 SAS HP (Ultrium), con controller Smart HBA H240.
 
 
Invece ashpool, il server nuovo con l'LTO-5:
 
 root@ashpool:~# free
              total       used       free     shared    buffers     cached
 Mem:      65712968    6063868   59649100     113104     225020     557372
 -/+ buffers/cache:    5281476   60431492
 Swap:     66843644          0   66843644
 root@ashpool:~# btape /dev/nst0
 Tape block granularity is 1024 bytes.
 btape: butil.c:290 Using device: "/dev/nst0" for writing.
 btape: btape.c:477 open device "LTOStorage" (/dev/nst0): OK
 *speed file_size=5 nb_file=14
 btape: btape.c:1057 Test with zero data, should give the maximum throughput.
 btape: btape.c:906 Begin writing 14 files of 5.368 GB with raw blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=75.16 GB. Total Write rate = 152.7 MB/s
 
 btape: btape.c:1069 Test with random data, should give the minimum throughput.
 btape: btape.c:906 Begin writing 14 files of 5.368 GB with raw blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=75.16 GB. Total Write rate = 117.6 MB/s
 
 btape: btape.c:1083 Test with zero data and bacula block structure.
 btape: btape.c:961 Begin writing 14 files of 5.368 GB with blocks of 64512 bytes.
 btape: btape.c:385 Total Volume bytes=75.16 GB. Total Write rate = 121.4 MB/s
 
 btape: btape.c:1095 Test with random data, should give the minimum throughput.
 btape: btape.c:961 Begin writing 14 files of 5.368 GB with blocks of 64512 bytes.
 [...]
 btape: btape.c:385 Total Volume bytes=75.16 GB. Total Write rate = 110.5 MB/s
 
 *
 
Questo è un LTO-5, sempre HP Ultium, con controller Smart Array P212.
 
 
Insomma, btape sembra non segnalare problemi prestazionali, 120 MB/s è più di
quanto possa mai aspettarmi, visto che dietro c'è una rete gigabit so già
che più di 50/60 MB/s non farò.
 
Sicuramente non i miseri 15 MB/s che fa ora, però... boh...
 
 
Ora provo con blocco da 128K, vediamo se cambia qualcosa. ;)
 
-- 
  Coltivate Linux, tanto Window$© si pianta da solo
				(Antonio, MajaGLUG: 
http://www.teppisti.it
)

 Ora provo con blocco da 128K, vediamo se cambia qualcosa. ;)
 
Con blocco da 256K raggiungo i 200Mbyte/s e passa, ovviamente per contenuto
altamente comprimibile. ;-)
 
Alla fine ho abilitato il despooling, e credo sia quella la discriminante:
 
 14-giu 23:00 sanvito-dir JobId 55: Start Backup JobId 55, Job=Lupus.2016-06-14_23.00.00_08
 14-giu 23:00 sanvito-dir JobId 55: Using Device "LTOStorage"
 14-giu 23:00 lupus-fd JobId 55: shell command: run ClientRunBeforeJob "/etc/bacula/scripts/debian-client-before"
 14-giu 23:03 ashpool-sd JobId 55: Volume "Ashpool003" previously written, moving to end of data.
 14-giu 23:05 ashpool-sd JobId 55: Ready to append to end of Volume "Ashpool003" at file=33.
 14-giu 23:05 ashpool-sd JobId 55: Spooling data ...
 14-giu 23:06 ashpool-sd JobId 55: Job write elapsed time = 00:01:13, Transfer rate = 25.08 M Bytes/second
 14-giu 23:06 ashpool-sd JobId 55: Committing spooled data to Volume "Ashpool003". Despooling 1,832,018,881 bytes ...
 14-giu 23:06 ashpool-sd JobId 55: Despooling elapsed time = 00:00:09, Transfer rate = 203.5 M Bytes/second
 14-giu 23:07 ashpool-sd JobId 55: Sending spooled attrs to the Director. Despooling 3,274,703 bytes ...
 14-giu 23:12 sanvito-dir JobId 55: Bacula sanvito-dir 5.2.6 (21Feb12):
 
Ancora quel '25.08 M Bytes/second' con rete gigabit non mi piace del tutto,
ma è pur sempre un incrementale, aspetto il prossimo full...
 
-- 
  Se non trovi nessuno vuol dire che siamo scappati alle sei-shell (bash,
  tcsh,csh...)							(Possi)

 ma è pur sempre un incrementale, aspetto il prossimo full...
 
Si, direi che ci siamo:
 
 17-giu 23:00 sanvito-dir JobId 77: Start Backup JobId 77, Job=Lupus.2016-06-17_23.00.00_26
 17-giu 23:00 sanvito-dir JobId 77: Using Device "LTOStorage"
 17-giu 23:00 lupus-fd JobId 77: shell command: run ClientRunBeforeJob "/etc/bacula/scripts/debian-client-before"
 17-giu 23:03 ashpool-sd JobId 77: Volume "Ashpool004" previously written, moving to end of data.
 17-giu 23:03 ashpool-sd JobId 77: Ready to append to end of Volume "Ashpool004" at file=1.
 17-giu 23:03 ashpool-sd JobId 77: Spooling data ...
 18-giu 00:22 ashpool-sd JobId 77: User specified spool size reached.
 18-giu 00:22 ashpool-sd JobId 77: Writing spooled data to Volume. Despooling 268,435,683,477 bytes ...
 18-giu 01:15 ashpool-sd JobId 77: Despooling elapsed time = 00:53:00, Transfer rate = 84.41 M Bytes/second
 18-giu 01:15 ashpool-sd JobId 77: Spooling data again ...
 18-giu 01:25 ashpool-sd JobId 77: Job write elapsed time = 02:21:46, Transfer rate = 35.45 M Bytes/second
 18-giu 01:25 ashpool-sd JobId 77: Committing spooled data to Volume "Ashpool004". Despooling 33,240,638,790 bytes ...
 18-giu 01:29 ashpool-sd JobId 77: Despooling elapsed time = 00:04:13, Transfer rate = 131.3 M Bytes/second
 18-giu 01:31 ashpool-sd JobId 77: Sending spooled attrs to the Director. Despooling 148,556,948 bytes ...
 
Ora mi sa che devo spostare l'LTO-5 sul nodo che ha più spazio disco, perchè
altrimenti, come si nota, va in despooling in due colpi.
Ma 84MB/s direi che è un valore più che buono.
 
Ancora non mi torna una cosa. la linea successiva:
 
 18-giu 04:23 sanvito-dir JobId 77: Bacula sanvito-dir 5.2.6 (21Feb12):
 
indica che ci ha messo quasi 4 ore a fare il despooling degli attributi al
director?
Ok, è vero che su una cartella ho abilitato le ACL, ma mi paiono comunque
una enormità per delle insert in una tabella...
 
 
Uffa, ora mi tocca ottimizzare anche il DB (MySQL) ...
 
-- 
  Non può sentirsi degno di essere italiano chi non vota SI al referendum
				(Silvio Berlusconi, 21 giugno 2006)

 Uffa, ora mi tocca ottimizzare anche il DB (MySQL) ...
 
Non è stato difficile:
 
 22-giu 23:00 sanvito-dir JobId 106: No prior Full backup Job record found.
 22-giu 23:00 sanvito-dir JobId 106: No prior or suitable Full backup found in catalog. Doing FULL backup.
 22-giu 23:00 sanvito-dir JobId 106: Start Backup JobId 106, Job=Lupus.2016-06-22_23.00.00_06
 22-giu 23:00 sanvito-dir JobId 106: Using Device "LTOStorage"
 22-giu 23:00 lupus-fd JobId 106: shell command: run ClientRunBeforeJob "/etc/bacula/scripts/debian-client-before"
 22-giu 23:04 ashpool-sd JobId 106: Volume "Ashpool004" previously written, moving to end of data.
 22-giu 23:04 ashpool-sd JobId 106: Ready to append to end of Volume "Ashpool004" at file=37.
 22-giu 23:04 ashpool-sd JobId 106: Spooling data ...
 22-giu 23:39 ashpool-sd JobId 106: Job write elapsed time = 00:35:01, Transfer rate = 36.65 M Bytes/second
 22-giu 23:39 ashpool-sd JobId 106: Committing spooled data to Volume "Ashpool004". Despooling 77,057,440,160 bytes ...
 22-giu 23:55 ashpool-sd JobId 106: Despooling elapsed time = 00:15:59, Transfer rate = 80.35 M Bytes/second
 22-giu 23:56 ashpool-sd JobId 106: Sending spooled attrs to the Director. Despooling 134,088,985 bytes ...
 23-giu 00:17 sanvito-dir JobId 106: Bacula sanvito-dir 5.2.6 (21Feb12):
 
ho sommariamente seguito, per la cronaca:
 
 
http://bacula.us/tuning/
 
 
-- 
  Chissà perché quando si sbaglia numero il telefono non è mai occupato.
							(Beppe Grillo)