Ciao, recentemente mi è capitato di affrontare una questione interessante: configurare uno storage per il backup di un gran numero di dispositivi di archiviazione.
Ogni settimana eseguiamo il backup di tutte le macchine virtuali nel nostro cloud, quindi è importante saper gestire migliaia di backup e farlo nel modo più veloce ed efficiente possibile.
Sfortunatamente, le configurazioni standard RAID5, RAID6 in questo caso non sono appropriate poiché il processo di ripristino su dischi così grandi come i nostri sarà dolorosamente lungo e probabilmente non sarà mai completato.
Esaminiamo le alternative:
— Analogo a RAID5, RAID6, ma con un livello di parità configurabile. In questo caso, il backup viene eseguito non per blocchi ma per singolo oggetto. Il modo più semplice per provare l'erasure coding è distribuire .
— è una funzionalità di ZFS ancora non rilasciata. A differenza di RAIDZ, DRAID ha un blocco di parità distribuito e durante il ripristino utilizza immediatamente tutti i dischi dell'array, consentendo una migliore resilienza ai guasti e un ripristino più veloce dopo un errore.
Abbiamo a disposizione un server Fujitsu Primergy RX300 S7 con un processore Intel Xeon CPU E5-2650L 0 @ 1.80GHz, nove moduli di memoria RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9), un sistema di archiviazione Supermicro SuperChassis 847E26-RJBOD1, connesso tramite Dual LSI SAS2X36 Expander e 45 dischi Seagate ST6000NM0115-1YZ110 da 6TB ciascuno.
Prima di prendere qualsiasi decisione, dobbiamo prima testare accuratamente tutto.
A tale scopo, mi sono preparato e ho condotto test su varie configurazioni. Per questo ho utilizzato minio, che ha funzionato come backend S3, eseguendolo in diverse modalità con quantità diverse di target.
Ho principalmente testato il caso di minio in erasure coding rispetto a software raid con lo stesso numero di dischi e dischi di parità, ovvero: RAID6, RAIDZ2 e DRAID2.
Per riferimento: quando avvii minio con un solo target, minio funziona in modalità S3 gateway, fornendo il tuo file system locale come storage S3. Se invece avvii minio specificando più target, si attiverà automaticamente la modalità Erasure Coding, che andrà a distribuire i dati tra i tuoi target fornendo resilienza ai guasti.
Per impostazione predefinita, minio suddivide i target in gruppi di 16 dischi, con 2 pareti per ogni gruppo. Cioè, possono guastarsi due dischi contemporaneamente senza perdita di dati.
Per testare le prestazioni, ho utilizzato 16 dischi da 6TB ciascuno e ho scritto su di essi piccoli oggetti delle dimensioni di 1MB, questo descriveva con precisione il nostro carico futuro, poiché tutti gli strumenti moderni per il backup suddividono i dati in blocchi di alcuni megabyte e li scrivono in questo modo.
Per eseguire il benchmark, è stata utilizzata l'utilità s3bench, lanciata su un server remoto e che inviava a minio decine di migliaia di tali oggetti in cento thread. Dopodiché, ha tentato di richiederli indietro nello stesso modo.
I risultati del benchmark sono riportati nella seguente tabella:
Come possiamo vedere, il minio in modalità di erasure coding proprietaria funzionava significativamente peggio in scrittura rispetto al minio avviato su RAID6 software, RAIDZ2 e DRAID2 nella stessa configurazione.
Separatamente, mi di testare minio su ext4 rispetto a XFS. Sorprendentemente, ma per il mio tipo di carico, XFS si è rivelato significativamente più lento di ext4.
Nella prima serie di test, Mdadm ha mostrato superiorità su ZFS, ma successivamente , che si può migliorare le prestazioni di ZFS impostando le seguenti opzioni:
xattr=sa atime=off recordsize=1Me dopo questo, i test con ZFS sono migliorati notevolmente.
Si può anche notare che DRAID non offre un vantaggio particolare in termini di prestazioni rispetto a RAIDZ, ma in teoria dovrebbe essere molto più sicuro.
Negli ultimi due test, ho anche tentato di spostare i metadati (special) e ZIL (log) su uno specchio da SSD. Ma spostare i metadati non ha dato un particolare guadagno in velocità di scrittura, e durante lo spostamento di ZIL, i miei hanno raggiunto il limite con il 100% di utilizzo, quindi considero questo test fallito. Non escludo che se avessi avuto SSD più veloci, questo potrebbe migliorare notevolmente i miei risultati, ma, purtroppo, non ne avevo.
Alla fine, ho deciso di fermarmi all'uso di DRAID e nonostante il suo stato beta, è la soluzione più veloce ed efficace per la nostra situazione.
Ho creato un semplice DRAID2 in configurazione con tre gruppi e due ricambi distribuiti:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsBene, abbiamo sistemato lo storage, ora parliamo di cosa useremo per il backup. Qui voglio subito parlare di tre soluzioni che sono riuscito a provare, che sono:
— fork , soluzione specializzata per il backup di dispositivi a blocchi, ha una stretta integrazione con Ceph. Può prelevare le differenze tra gli snapshot e formare da esse un backup incrementale. Supporta un'ampia gamma di backend di archiviazione, tra cui sia locale che S3. Richiede un database separato per memorizzare la tabella hash di deduplicazione. Tra i lati negativi: scritto in python, ha un'interfaccia CLI leggermente poco reattiva.
— fork , un vecchio e collaudato strumento per il backup, è in grado di eseguire il backup dei dati e li deduplica bene. Può memorizzare i backup sia localmente che su un server remoto tramite scp. È in grado di eseguire il backup di dispositivi a blocchi se avviato con il flag --special, tra i lati negativi: durante la creazione del backup, il repository è completamente bloccato, quindi per ogni macchina virtuale è consigliabile creare un repository separato, in linea di principio non è un problema, dato che vengono creati molto facilmente.
— un progetto in attivo sviluppo, scritto in go, piuttosto veloce e supporta un'ampia varietà di backend per l'archiviazione, tra cui sia lo storage locale, sia scp, S3 e molto altro. Vale la pena notare che c'è un appositamente creato per restic, che consente di esportare più rapidamente lo storage per un utilizzo remoto. Tra tutti quelli sopra menzionati, mi è piaciuto di più. Può eseguire il backup da stdin. Ha pochi difetti evidenti, ma ci sono alcune peculiarità:
In primo luogo, ho provato a usarlo in modalità repository condiviso per tutte le macchine virtuali (come Benji) e ha funzionato piuttosto bene, ma le operazioni di ripristino richiedevano un tempo piuttosto lungo, poiché ogni volta prima del ripristino, restic cerca di leggere i metadati di tutti i backup. Questo problema è stato facilmente risolto, come con borg, creando un repository separato per ogni macchina virtuale. Questo approccio si è rivelato molto efficace anche per la gestione dei backup. I repository separati possono avere una password separata per l'accesso ai dati, e inoltre non dobbiamo temere che il repository globale possa rompersi in qualche modo. Creare nuovi repository è altrettanto semplice come in borg backup.
In ogni caso, la deduplicazione viene effettuata solo rispetto alla versione precedente del backup, il backup precedente è determinato dal path del backup specificato, quindi se stai eseguendo il backup di oggetti diversi da stdin in un repository comune, non dimenticare di specificare l'opzione
--stdin-filename, oppure specificare esplicitamente ogni volta l'opzione--parent.
In secondo luogo, il ripristino in stdout richiede significativamente più tempo rispetto al ripristino su un file system a causa della sua parallelizzazione. In futuro, è previsto un supporto più stretto per i backup degli oggetti a blocchi.
In terzo luogo, attualmente si consiglia di utilizzare , poiché la versione 0.9.6 presenta un bug con il ripristino lento di grandi file.
Per testare l'efficacia del backup e la velocità di scrittura/ripristino da un backup, ho creato un repository separato e ho provato a eseguire il backup di un'immagine di macchina virtuale di piccole dimensioni (21 GB). Sono stati effettuati due backup senza modificare l'originale, utilizzando ciascuna delle soluzioni elencate, per verificare quanto più velocemente/più lentamente vengano copiati i dati deduplicati.
Come possiamo notare, Borg Backup ha il miglior coefficiente di efficienza per il backup iniziale, ma perde in velocità sia di scrittura che di ripristino.
Restic si è dimostrato più veloce di Benji Backup, ma ripristina più lentamente in stdout e purtroppo, non sa ancora scrivere direttamente su un dispositivo a blocchi.
Pesando tutti i pro e i contro, ho deciso di fermarmi su restic con rest-server come la soluzione più comoda e promettente per il backup.
In questo screencast puoi vedere come una connessione da 10 gigabit viene completamente utilizzata durante diverse operazioni di backup avviate contemporaneamente. Vale la pena notare che l'utilizzo dei dischi non supera il 30%.
Sono rimasto più che soddisfatto della soluzione ottenuta!
Fonte: habr.com
