{"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, di recente mi \u00e8 capitato di affrontare un'interessante sfida nel configurare uno storage per il backup di un gran numero di dispositivi a blocchi.<\/p>\n

<\/p>\n

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

<\/p>\n

Sfortunatamente, le configurazioni standard RAID5<\/strong>, RAID6<\/strong> in questo caso non sono adatte poich\u00e9 il processo di ripristino su dischi cos\u00ec grandi come i nostri sarebbe incredibilmente lungo e probabilmente non si concluderebbe mai.<\/p>\n

<\/p>\n

Esaminiamo quali alternative ci sono:<\/p>\n

<\/p>\n

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

<\/p>\n

DRAID<\/a><\/noindex><\/strong> \u00e8 una funzionalit\u00e0 di ZFS attualmente 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, il che consente di gestire meglio i guasti dei dischi e di riprendersi pi\u00f9 rapidamente dopo un'interruzione. <\/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 processore Intel Xeon CPU E5-2650L 0 @ 1.80GHz<\/strong>, nove schede di memoria RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9)<\/strong>, scaffale disco Supermicro SuperChassis 847E26-RJBOD1<\/strong>, collegato tramite Dual LSI SAS2X36 Expander<\/strong> e 45 dischi Seagate ST6000NM0115-1YZ110<\/strong> per 6TB<\/strong> ognuno.<\/p>\n

<\/p>\n

Prima di prendere qualsiasi decisione, \u00e8 fondamentale testare tutto adeguatamente.<\/p>\n

<\/p>\n

Per questo, mi sono preparato e ho condotto test su diverse configurazioni. Ho utilizzato minio, che fungeva da backend S3, eseguendolo in diverse modalit\u00e0 con un numero variabile di target.<\/p>\n

<\/p>\n

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

<\/p>\n

Per vostra informazione: quando eseguite minio con un solo target, minio opera in modalit\u00e0 S3-gateway, presentando il vostro file system locale come storage S3. Se eseguite minio specificando pi\u00f9 target, si attiva automaticamente la modalit\u00e0 di Erasure Coding, che distribuisce i dati tra i vostri target fornendo tolleranza ai guasti.<\/p>\n

Per impostazione predefinita, minio suddivide i target in gruppi di 16 dischi, con 2 parit\u00e0 per ciascun gruppo. Ci\u00f2 significa che possono guastarsi contemporaneamente due dischi senza perdere dati.<\/p><\/blockquote>\n

Per testare le prestazioni, ho utilizzato 16 dischi da 6TB ciascuno e ho scritto su di essi piccoli oggetti di dimensione 1MB. Questo descriveva con massima precisione il nostro carico futuro, poich\u00e9 tutti gli strumenti di backup moderni 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'utile s3bench, eseguita su un server remoto che inviava a minio decine di migliaia di oggetti in cento flussi. Successivamente, ha tentato di richiederli indietro allo stesso modo.<\/p>\n

<\/p>\n

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

<\/p>\n

\"Storage<\/p>\n

<\/p>\n

Come possiamo vedere, minio in modalit\u00e0 erasure coding nativa funziona significativamente peggio in scrittura rispetto a minio avviato sopra RAID6 software, RAIDZ2 e DRAID2 nella stessa configurazione.<\/p>\n

<\/p>\n

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

<\/p>\n

Nella prima serie di test, Mdadm ha mostrato un superiore rispetto a ZFS, ma pi\u00f9 avanti gmelikov<\/a><\/noindex> ha suggerito<\/a><\/noindex>, che \u00e8 possibile 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 significativamente.<\/p>\n
<\/p>\n
Si pu\u00f2 anche notare che DRAID non offre un vantaggio significativo in termini di prestazioni rispetto a RAIDZ, ma teoricamente dovrebbe essere molto pi\u00f9 sicuro.<\/p>\n
<\/p>\n
Nei due test finali ho anche cercato di trasferire i metadati (special) e ZIL (log) su uno specchio da SSD. Tuttavia, il trasferimento dei metadati non ha fornito un miglioramento significativo nella velocit\u00e0 di scrittura, e quando ho trasferito ZIL, i miei SSDSC2KI128G8<\/a><\/noindex> hanno raggiunto il limite con un utilizzo del 100%, 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 li avevo.<\/p>\n
<\/p>\n
Alla fine ho deciso di mantenere DRAID e, nonostante il suo stato beta, \u00e8 la soluzione pi\u00f9 veloce ed efficace per il nostro caso.<\/p>\n
<\/p>\n
Ho creato un semplice DRAID2 in configurazione con tre gruppi e due spare 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, abb smakando lo storage, ora parliamo di cosa useremo per il backup. Qui voglio subito parlare di tre soluzioni che ho potuto provare, ovvero:<\/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 i diff tra gli snapshot e di formarne un backup incrementale. Supporta un'ampia variet\u00e0 di backend di storage, tra cui sia locale che S3. Richiede un database separato per la memorizzazione della tabella hash di deduplicazione. Tra i lati negativi: \u00e8 scritto in Python e ha un'interfaccia a riga di comando un po' poco reattiva.<\/p>\n
<\/p>\n
Borg Backup<\/a><\/noindex><\/strong> \u2014 fork Attic<\/a><\/noindex>, un mezzo ben noto e collaudato per il backup, in grado di salvare i dati e di deduplicarli in modo efficiente. 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 suoi svantaggi: durante la creazione di un backup, il repository viene completamente bloccato, quindi \u00e8 consigliabile creare un repository separato per ogni macchina virtuale, ma in realt\u00e0 non \u00e8 un problema, dato che vengono creati molto facilmente.<\/p>\n
<\/p>\n
Restic<\/a><\/noindex><\/strong> \u2014 un progetto in rapida crescita, scritto in Go, sufficientemente veloce e supporta un gran numero di backend per lo storage, tra cui sia lo storage locale che scp, S3 e molto altro. \u00c8 importante notare che esiste un rest-server<\/a><\/noindex> specificamente creato per restic, che consente di esportare lo storage per un utilizzo remoto nel modo pi\u00f9 rapido possibile. Tra tutte le opzioni, questa mi \u00e8 piaciuta di pi\u00f9. Supporta il backup da stdin. Ha pochi svantaggi evidenti, ma ci sono alcune peculiarit\u00e0:<\/p>\n
<\/p>\n