{"id":83100,"date":"2020-05-28T13:42:10","date_gmt":"2020-05-28T11:42:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami"},"modified":"2020-05-28T13:42:10","modified_gmt":"2020-05-28T11:42:10","slug":"bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","title":{"rendered":"Storage di backup per migliaia di macchine virtuali con strumenti gratuiti","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Storage<\/p>\n

<\/p>\n

Ciao, recentemente mi \u00e8 capitato di affrontare una questione interessante: configurare uno storage per il backup di un gran numero di dispositivi di archiviazione.<\/p>\n

<\/p>\n

Ogni settimana eseguiamo il backup di tutte le macchine virtuali nel nostro cloud, quindi \u00e8 importante saper gestire migliaia di backup e farlo nel modo pi\u00f9 veloce ed efficiente possibile.<\/p>\n

<\/p>\n

Sfortunatamente, le configurazioni standard RAID5<\/strong>, RAID6<\/strong> in questo caso non sono appropriate poich\u00e9 il processo di ripristino su dischi cos\u00ec grandi come i nostri sar\u00e0 dolorosamente lungo e probabilmente non sar\u00e0 mai completato.<\/p>\n

<\/p>\n

Esaminiamo le alternative:<\/p>\n

<\/p>\n

Erasure Coding<\/a><\/noindex><\/strong> \u2014 Analogo a RAID5, RAID6, ma con un livello di parit\u00e0 configurabile. In questo caso, il backup viene eseguito non per blocchi ma per singolo oggetto. Il modo pi\u00f9 semplice per provare l'erasure coding \u00e8 distribuire minio<\/a><\/noindex>.<\/p>\n

<\/p>\n

DRAID<\/a><\/noindex><\/strong> \u2014 \u00e8 una funzionalit\u00e0 di ZFS ancora non rilasciata. A differenza di RAIDZ, DRAID ha un blocco di parit\u00e0 distribuito e durante il ripristino utilizza immediatamente tutti i dischi dell'array, consentendo una migliore resilienza ai guasti e un ripristino pi\u00f9 veloce dopo un errore. <\/p>\n

<\/a><\/noindex><\/p>\n

\"Storage<\/p>\n

<\/p>\n

\"Storage<\/p>\n

Abbiamo a disposizione un server Fujitsu Primergy RX300 S7<\/strong> con un processore Intel Xeon CPU E5-2650L 0 @ 1.80GHz<\/strong>, nove moduli di memoria RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9)<\/strong>, un sistema di archiviazione Supermicro SuperChassis 847E26-RJBOD1<\/strong>, connesso tramite Dual LSI SAS2X36 Expander<\/strong> e 45 dischi Seagate ST6000NM0115-1YZ110<\/strong> da 6TB<\/strong> ciascuno.<\/p>\n

<\/p>\n

Prima di prendere qualsiasi decisione, dobbiamo prima testare accuratamente tutto.<\/p>\n

<\/p>\n

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\u00e0 con quantit\u00e0 diverse di target.<\/p>\n

<\/p>\n

Ho principalmente testato il caso di minio in erasure coding rispetto a software raid con lo stesso numero di dischi e dischi di parit\u00e0, ovvero: RAID6, RAIDZ2 e DRAID2.<\/p>\n

<\/p>\n

Per riferimento: quando avvii minio con un solo target, minio funziona in modalit\u00e0 S3 gateway, fornendo il tuo file system locale come storage S3. Se invece avvii minio specificando pi\u00f9 target, si attiver\u00e0 automaticamente la modalit\u00e0 Erasure Coding, che andr\u00e0 a distribuire i dati tra i tuoi target fornendo resilienza ai guasti.<\/p>\n

Per impostazione predefinita, minio suddivide i target in gruppi di 16 dischi, con 2 pareti per ogni gruppo. Cio\u00e8, possono guastarsi due dischi contemporaneamente senza perdita di dati.<\/p><\/blockquote>\n

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\u00e9 tutti gli strumenti moderni per il backup suddividono i dati in blocchi di alcuni megabyte e li scrivono in questo modo.<\/p>\n

<\/p>\n

Per eseguire il benchmark, \u00e8 stata utilizzata l'utilit\u00e0 s3bench, lanciata su un server remoto e che inviava a minio decine di migliaia di tali oggetti in cento thread. Dopodich\u00e9, ha tentato di richiederli indietro nello stesso modo.<\/p>\n

<\/p>\n

I risultati del benchmark sono riportati nella seguente tabella:<\/p>\n

<\/p>\n

\"Storage<\/p>\n

<\/p>\n

Come possiamo vedere, il minio in modalit\u00e0 di erasure coding proprietaria funzionava significativamente peggio in scrittura rispetto al minio avviato su RAID6 software, RAIDZ2 e DRAID2 nella stessa configurazione.<\/p>\n

<\/p>\n

Separatamente, mi \u00e8 stato chiesto<\/a><\/noindex> di testare minio su ext4 rispetto a XFS. Sorprendentemente, ma per il mio tipo di carico, XFS si \u00e8 rivelato significativamente pi\u00f9 lento di ext4.<\/p>\n

<\/p>\n

Nella prima serie di test, Mdadm ha mostrato superiorit\u00e0 su ZFS, ma successivamente gmelikov<\/a><\/noindex> ha suggerito<\/a><\/noindex>, che si pu\u00f2 migliorare le prestazioni di ZFS impostando le seguenti opzioni:<\/p>\n

<\/p>\n

xattr=sa atime=off recordsize=1M<\/code><\/pre>\n
<\/p>\n
e dopo questo, i test con ZFS sono migliorati notevolmente.<\/p>\n
<\/p>\n
Si pu\u00f2 anche notare che DRAID non offre un vantaggio particolare in termini di prestazioni rispetto a RAIDZ, ma in teoria dovrebbe essere molto pi\u00f9 sicuro.<\/p>\n
<\/p>\n
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\u00e0 di scrittura, e durante lo spostamento di ZIL, i miei SSDSC2KI128G8<\/a><\/noindex> hanno raggiunto il limite con il 100% di utilizzo, quindi considero questo test fallito. Non escludo che se avessi avuto SSD pi\u00f9 veloci, questo potrebbe migliorare notevolmente i miei risultati, ma, purtroppo, non ne avevo.<\/p>\n
<\/p>\n
Alla fine, ho deciso di fermarmi all'uso di DRAID e nonostante il suo stato beta, \u00e8 la soluzione pi\u00f9 veloce ed efficace per la nostra situazione.<\/p>\n
<\/p>\n
Ho creato un semplice DRAID2 in configurazione con tre gruppi e due ricambi distribuiti:<\/p>\n
<\/p>\n
# zpool status data\n  pool: data\n state: ONLINE\n  scan: none requested\nconfig:\n\n    NAME                 STATE     READ WRITE CKSUM\n    data                 ONLINE       0     0     0\n      draid2:3g:2s-0     ONLINE       0     0     0\n        sdy              ONLINE       0     0     0\n        sdam             ONLINE       0     0     0\n        sdf              ONLINE       0     0     0\n        sdau             ONLINE       0     0     0\n        sdab             ONLINE       0     0     0\n        sdo              ONLINE       0     0     0\n        sdw              ONLINE       0     0     0\n        sdak             ONLINE       0     0     0\n        sdd              ONLINE       0     0     0\n        sdas             ONLINE       0     0     0\n        sdm              ONLINE       0     0     0\n        sdu              ONLINE       0     0     0\n        sdai             ONLINE       0     0     0\n        sdaq             ONLINE       0     0     0\n        sdk              ONLINE       0     0     0\n        sds              ONLINE       0     0     0\n        sdag             ONLINE       0     0     0\n        sdi              ONLINE       0     0     0\n        sdq              ONLINE       0     0     0\n        sdae             ONLINE       0     0     0\n        sdz              ONLINE       0     0     0\n        sdan             ONLINE       0     0     0\n        sdg              ONLINE       0     0     0\n        sdac             ONLINE       0     0     0\n        sdx              ONLINE       0     0     0\n        sdal             ONLINE       0     0     0\n        sde              ONLINE       0     0     0\n        sdat             ONLINE       0     0     0\n        sdaa             ONLINE       0     0     0\n        sdn              ONLINE       0     0     0\n        sdv              ONLINE       0     0     0\n        sdaj             ONLINE       0     0     0\n        sdc              ONLINE       0     0     0\n        sdar             ONLINE       0     0     0\n        sdl              ONLINE       0     0     0\n        sdt              ONLINE       0     0     0\n        sdah             ONLINE       0     0     0\n        sdap             ONLINE       0     0     0\n        sdj              ONLINE       0     0     0\n        sdr              ONLINE       0     0     0\n        sdaf             ONLINE       0     0     0\n        sdao             ONLINE       0     0     0\n        sdh              ONLINE       0     0     0\n        sdp              ONLINE       0     0     0\n        sdad             ONLINE       0     0     0\n    spares\n      s0-draid2:3g:2s-0  AVAIL   \n      s1-draid2:3g:2s-0  AVAIL   \n\nerrors: No known data errors<\/code><\/pre>\n
Bene, 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:<\/p>\n
<\/p>\n
Benji Backup<\/a><\/noindex><\/strong> \u2014 fork Backy2<\/a><\/noindex>, soluzione specializzata per il backup di dispositivi a blocchi, ha una stretta integrazione con Ceph. \u00c8 in grado di recuperare le differenze tra i snapshot e di formare un backup incrementale. Supporta un'ampia variet\u00e0 di backend di archiviazione, inclusi sia locale che S3. Richiede un database separato per memorizzare la tabella hash di deduplicazione. Tra i contro: scritto in Python, ha un'interfaccia a riga di comando leggermente poco reattiva.<\/p>\n
<\/p>\n
Borg Backup<\/a><\/noindex><\/strong> \u2014 fork Attic<\/a><\/noindex>, un vecchio e collaudato strumento per il backup, \u00e8 in grado di eseguire il backup dei dati e li deduplica bene. Pu\u00f2 memorizzare i backup sia localmente che su un server remoto tramite scp. \u00c8 in grado di eseguire il backup di dispositivi a blocchi se avviato con il flag --special<\/code>, tra i lati negativi: durante la creazione del backup, il repository \u00e8 completamente bloccato, quindi per ogni macchina virtuale \u00e8 consigliabile creare un repository separato, in linea di principio non \u00e8 un problema, dato che vengono creati molto facilmente.<\/p>\n
<\/p>\n
Restic<\/a><\/noindex><\/strong> \u2014 un progetto in attivo sviluppo, scritto in go, piuttosto veloce e supporta un'ampia variet\u00e0 di backend per l'archiviazione, tra cui sia lo storage locale, sia scp, S3 e molto altro. Vale la pena notare che c'\u00e8 un rest-server<\/a><\/noindex> appositamente creato per restic, che consente di esportare pi\u00f9 rapidamente lo storage per un utilizzo remoto. Tra tutti quelli sopra menzionati, mi \u00e8 piaciuto di pi\u00f9. Pu\u00f2 eseguire il backup da stdin. Ha pochi difetti evidenti, ma ci sono alcune peculiarit\u00e0:<\/p>\n
<\/p>\n