Architettura della soluzione di backup utilizzando Veeam e Ceph

L'architettura del backup delle macchine virtuali su VMWare e Hyper-V è simile. Veeam utilizza i data mover per trasferire i dati dagli host di origine ai repository di backup. I data mover vengono eseguiti sul server proxy e sul server di repository. Per utilizzare Ceph come storage di backend di un repository di backup, è possibile montare RBD o CephFS su un server fisico o una macchina virtuale Linux come server di repository.

Se i server proxy e di repository sono macchine virtuali all'interno del cluster dell'ipervisore, è possibile ottenere il vantaggio del trasporto dati ad alta velocità senza rete tra il disco della macchina virtuale, il server proxy e il server di repository. La migliore configurazione di un grande cluster di hypervisor è quella di distribuire una VM server proxy e una VM server repository su ogni host VMWare. In caso contrario, è possibile distribuire una macchina virtuale di backup proxy su ogni host VMWare e un host di repository esterno per rimuovere il carico di lavoro dalla tua produzione VMWare.

Ci sono tre modi per utilizzare l'appliance Ceph Ambedded come repository per Veeam Backup and Replication.CephFS e dispositivi a blocchi RBD possono essere utilizzati come repository di backup in loco.L'archiviazione degli oggetti S3 può essere utilizzata come livello di capacità per una posizione remota.

Per le istruzioni su come impostare il dispositivo a blocchi Ceph RBD e il sistema di file CephFS come repository di backup di Veeam per il backup di macchine virtuali e file, potete trovare i dettagli nel white paper alla fine di questa pagina.

Ambiente di Test

Cluster Ceph

• Tre Mars 400 con 3x monitor, 20 OSD, e 1x MDS (server di metadati)
• Ogni demone Ceph funziona su un microserver Arm A72 dual-core
• Sistema Operativo: CentOS 7
• Software Ceph: Nautilus 14.2.9 Arm64
• Rete: 4x 10Gb di rete per Mars 400 

Veeam Backup & Replication 10, Versione: 10.0.1.4854

Server di Backup Veeam

• CPU: Intel Xeon E5-2630 2.3GHz DUAL
• DRAM: 64GB
• Rete: 2x 10Gb sfp+ bonding
• Disco: 1TB per il sistema, 256GB SATA3 SSD per il volume
• Windows Server 2019

 Server Proxy Veeam

• collocato con il Server di Backup Veeam

 Server del Repository

• Macchina Virtuale

◇ CPU: 4 core 2.3GHz

◇  DRAM: 8GB

◇  Rete: ponte

◇  Disco: disco virtuale da 50GB

◇  OS: CentOS 7.8.2003

• Server Baremetal

◇  CPU: Intel Xeon X5650 2.67GHz DUAL

◇  DRAM: 48GB

◇  Rete: bonding a 2 porte 10Gb sfp+

◇  Disco: 1TB per il sistema

◇  OS: CentOS 7.6.1810

Host Hyper-V

◇  CPU: Intel Xeon E5-2630 2.3GHz DUAL

◇  DRAM: 64GB

◇  Rete: bonding sfp+ a 2 porte da 10 Gb

◇  Disco: 1TB per il sistema

◇  Windows Server 2019

Host VMWare

◇  CPU: Intel Xeon E5-2630 2.3GHz DUAL

◇  DRAM: 64GB

◇  Rete: bonding sfp+ a 2 porte da 10 Gb

◇  Disco: 1TB per il sistema

◇  ESXi 6.5

Rete: switch 10GbE

Benchmark su diverse configurazioni

Per valutare le prestazioni di backup di diversi repository di backup, abbiamo effettuato test con diversi repository di backup e tre sorgenti di backup.

Le sorgenti di backup utilizzate per i test sono un volume basato su SSD SATA su un server, una VM Windows di Hyper-V e una VM CentOS 7 e una VM Windows di VMWare.

(1) Backup di un volume su un'unità SSD

Tabella 1. Backup di un volume da un server con un SSD SATA.

Tabella 2.

Nota: i tassi medi di scrittura dei dati sono calcolati dividendo i dati trasferiti per la durata. Questi tassi rappresentano i carichi di lavoro del cluster Ceph in questi lavori di backup.

(2) Esegui il backup di una VM Windows 10 su Hyper-V su HDD

In questo benchmark, facciamo il backup di un'istanza Hyper-V che è memorizzata su un hard disk SATA. I tassi di elaborazione di questi lavori raggiungono il limite superiore della larghezza di banda dell'HDD. Possiamo anche trovare il collo di bottiglia sulla fonte perché i loro carichi sono occupati durante il 99% della durata del lavoro. Cluster Ceph, il target, il carico di lavoro dai lavori di backup di Veeam è leggero. Il cluster Ceph è occupato solo dal 6% all'1% del tempo di lavoro.

Rispetto al benchmark precedente, il tasso di elaborazione del backup della VM è molto più basso rispetto al backup SSD.Questo è principalmente perché i dati della VM sono memorizzati su un hard disk.

Tabella 3.

Tabella 4. Esegui il backup di un'immagine di macchina virtuale su un HDD SATA3

Nota: i tassi medi di scrittura dei dati sono calcolati dividendo i dati trasferiti per la durata. Questi tassi rappresentano i carichi di lavoro del cluster Ceph in questi lavori di backup.

(3)Backup delle macchine virtuali su ESXi su HDD

Questo test effettua il backup di una macchina virtuale CentOS 7 e Windows 10 in esecuzione su un disco rigido di un host VMWare ESXi 6.5 su un repository supportato da un Ceph RBD con protezione a codice di cancellazione 4+2.

Tabella 5.

Tabella 6.

Nota: i tassi medi di scrittura dei dati sono calcolati dividendo i dati trasferiti per la durata. Questi tassi rappresentano i carichi di lavoro del cluster Ceph in questi lavori di backup.

Conclusioni

Secondo i risultati del test, Ceph RBD e CephFS hanno prestazioni simili. Questo corrisponde alla nostra esperienza riguardo al benchmark delle prestazioni di RBD e CephFS. Confrontando le caratteristiche di CephFS e RBD, hanno i loro vantaggi e svantaggi. Se hai bisogno di distribuire più server di repository, devi creare un'immagine RBD per ogni server di repository di backup poiché puoi montare solo Ceph RBD su un host. Rispetto a CephFS, l'utilizzo di RBD è più semplice in quanto non richiede i server di metadati. Dobbiamo assegnare la dimensione della capacità RBD quando viene creata, quindi devi ridimensionare la sua capacità quando hai bisogno di più spazio.

Se si utilizza CephFS come repository, è necessario distribuire almeno un server di metadati (MDS) nel cluster Ceph. Abbiamo anche bisogno di un server di metadati di standby per l'alta disponibilità. Rispetto a Ceph RBD, non è necessario assegnare un limite di quota al file system. Quindi, è possibile trattare CephFS come un pool di archiviazione illimitato.

In questa dimostrazione di caso d'uso, i nostri test effettuano il backup di un solo VM in ogni job di backup. Secondo i rapporti di test sopra citati, sappiamo che il tasso medio di scrittura dei dati è correlato al tasso di elaborazione e all'efficienza di deduplicazione e compressione dei dati. Un disco di origine più veloce riduce la durata del job di backup e porta a un tasso di elaborazione più rapido. A seconda dell'infrastruttura degli utenti, è possibile eseguire diversi job simultanei per eseguire il backup di oggetti diversi contemporaneamente. Lo storage Ceph si comporta molto bene nel supportare job simultanei multipli.

Un cluster Ceph OSD HDD 20x alimentato da 3x Ambedded Mars 400 può offrire una velocità di scrittura aggregata fino a 700MB/s al pool di codifica 4+2. Implementando più lavori di backup correnti si ottiene il vantaggio di ridurre la durata complessiva del backup. Le prestazioni massime di un cluster Ceph sono quasi proporzionali linearmente al numero totale di unità disco nel cluster.

In questo caso d'uso, non abbiamo testato l'utilizzo di S3 object storage come repository di backup. S3 object storage può essere utilizzato come livello di capacità nel repository di backup Scale-Out di Veeam e come repository di archiviazione di destinazione per il backup NAS. È possibile configurare facilmente un gateway RADOS e creare utenti di object storage utilizzando il Ambedded UVS manager, l'interfaccia web di gestione di ceph.