Il repository con protezione avanzata è la soluzione nativa di Veeam per fornire l’immutabilità affidabile per i backup di Veeam Backup & Replication su un server Linux. Supportando i server Linux generici, Veeam garantisce che i clienti abbiano sempre la possibilità di scegliere il proprio hardware senza vendor lock-in. Veeam consente inoltre ai clienti di utilizzare la propria distribuzione Linux di fiducia (Ubuntu, Red Hat, SUSE) invece di essere costretti a utilizzare un “Veeam Linux personalizzato”.
I repository con protezione avanzata consentono di garantire l’immutabilità dei backup Veeam rispettando la regola 3-2-1 e combinando i repository con protezione avanzata con altre opzioni immutabili come il blocco degli oggetti su object storage o i nastri WORM. Questo blog post spiega come selezionare e preparare l’ambiente per un server fisico che verrà successivamente utilizzato come repository con protezione avanzata. I prossimi blog post tratteranno argomenti quali la preparazione e la pianificazione, la protezione di un sistema Linux e l’integrazione in Veeam Backup & Replication
E chi è impaziente può utilizzare dei server (ad alta densità) con dischi interni. Questo approccio è scalabile in modo lineare, perché con ogni nuovo nodo di repository con protezione avanzata, ci sono migliori prestazioni di CPU, RAM, RAID, rete, spazio su disco e I/O. Un rack pieno di server ad alta densità offre circa 8 PB di capacità nativa. Grazie alla riduzione dei dati nativa Veeam e al risparmio di spazio XFS (clonazione dei blocchi), è possibile ottenere dati logici fino a 100 PB in un rack con velocità di backup fino a 420 TiB/h.
Se avete un ambiente piccolo, non preoccupatevi. Inizia con due unità rack, 12 dischi dati e due dischi per il sistema operativo.
La rete
Il networking è un fattore chiave per garantire che un repository con protezione avanzata possa contribuire al raggiungimento dei Recovery Point Objective (RPO, quantità massima di dati che possono essere persi) e dei Recovery Time Objective (RTO, quanto tempo impiegherebbe un ripristino). In un mondo di backup “incrementali per sempre”, la rete viene talvolta dimenticata, a causa dei bassi requisiti di larghezza di banda dell’approccio “incrementale per sempre”. Si raccomanda di progettare uno scenario di “ripristino completo”. Utilizza il tuo strumento di calcolo preferito per stimare l’ampiezza di banda abbinandola ai tuoi requisiti di ripristino.
Alcuni esempi di quanto tempo è necessario per copiare dati da 10 TB su diverse velocità di rete:
1 Gbit/s 22 h 45 min
10 Gbit/s 2 h 15 min
20 Gbit/s 1 h 8 min
40 Gbit/s 34 min
100 Gbit/s meno di 14 min
1100 Gbit/s è realisticamente la velocità massima che i clienti oggi possono implementare in un server repository. HPE ha dimostrato nel 2021 con il suo server Apollo 4510 che tali velocità sono raggiungibili con un singolo server.
Ma non riguarda solo la larghezza di banda. È anche una questione di ridondanza. Se è presente un solo cavo di rete verso l’infrastruttura dello switch, ciò significa un singolo punto di guasto. Si consiglia di disporre di una connessione di rete ridondante per il repository con protezione avanzata. A seconda delle capacità di rete di cui disponi, potrebbe trattarsi di collegamenti attivi/attivi con bilanciamento del carico (ad esempio LACP/802.3ad) o di un semplice scenario attivo/passivo.
Sebbene Linux possa essere facilmente configurato con i tag VLAN, il principio KISS richiede l’utilizzo di switchport senza tag. Ciò significa che si configurano direttamente gli indirizzi IP senza alcuna VLAN in Linux. La configurazione ridondante più piccola sarebbe da 2 connessioni a 10 Gbit/s a due switch/uno stack di switch (a seconda del nostro ambiente di rete).
Per ricevere gli aggiornamenti della protezione di Linux, è necessario disporre dell’accesso ai server di aggiornamento della protezione della distribuzione Linux.
Per semplicità, consentiamo l’accesso a Internet HTTP in uscita sul firewall per ottenere gli aggiornamenti di sicurezza. Consentiamo solo connessioni ai server di aggiornamento della distribuzione Linux scelta, e non a Internet. L’alternativa sarebbe quella di impostare un mirror della tua distribuzione Linux preferita per ottenere aggiornamenti e software da lì.
Trovare il fornitore e il modello di server giusti
Dal punto di vista di Veeam, la raccomandazione è di utilizzare un server con dischi interni come repository con protezione avanzata. I dischi interni sono consigliati perché eliminano il rischio che un utente malintenzionato possa accedere al sistema di storage ed eliminare tutto ciò che si trova sul lato storage. I fornitori di server talvolta adottano modelli di “server di backup Veeam”. Questi modelli di server sono ottimizzati per i requisiti delle prestazioni di backup e attenersi alle raccomandazioni del fornitore è una buona idea.
Se hai una distribuzione Linux preferita, è bene scegliere un modello certificato per quella distribuzione Linux. Le configurazioni pre-testate consentono di risparmiare molto tempo quando si lavora con Linux. I grandi marchi di solito dispongono di server, che sono compatibili con le principali distribuzioni Linux come Ubuntu, Red Hat (RHEL) e SUSE (SLES).
Come ho detto prima, Cisco ha predisposto dei “Cisco Validated Design” per Veeam per le serie S3260 e C240. Tecnicamente, tutti i fornitori di server vanno bene dal punto di vista di Veeam, purché siano soddisfatti questi requisiti essenziali:
Controller RAID con cache write-back alimentata a batteria (o tecnologia simile)
Si consiglia vivamente di utilizzare controller RAID con analisi predittiva dei guasti
Con molti dischi (50+), più controller RAID di solito hanno senso, a causa dei limiti di velocità del controller RAID (spesso limitati a circa 2 GByte/s)
Dischi separati per sistema operativo e dati
SSD fortemente consigliati per il sistema operativo
Alimentazione ridondante
Rete ridondante con velocità di collegamento richiesta (vedi sopra)
La velocità della CPU è relativamente irrilevante, perché Veeam utilizza la compressione LZ4 molto veloce per impostazione predefinita. Funziona bene accettare qualsiasi cosa offra il fornitore del server. Molti core della CPU consentono di eseguire molte attività in parallelo. 4 GB di RAM per core della CPU è la best practice consigliata. Se decidi per 2X 16 core della CPU, la soluzione perfetta sarebbe una RAM da 128 GB. Anche se questo tipo di dimensionamento potrebbe sembrare “eccessivamente semplificato”, funziona bene da anni nei nostri ambienti di test e in ambienti di produzione reali.
Configurazione di base del server
Prima di installare il sistema operativo Linux, è necessario configurare alcune impostazioni. Come accennato in precedenza, i sistemi operativi e i dati sono separati su dischi diversi. Su diversi set RAID, per la precisione.
Per il sistema operativo Linux, viene utilizzato un RAID 1 dedicato. 100 GB sono più che sufficienti. Per i dischi dati, la maggior parte dei clienti sceglie RAID 6/60 per un rapporto prezzo/valore migliore rispetto a RAID 10. RAID 5/50 o qualsiasi altra opzione a parità singola non è consigliata per motivi di sicurezza. Il RAID 6/60 deve essere configurato con almeno un disco di riserva in “configurazione roaming”. Ciò significa che il disco di riserva può sostituire qualsiasi disco guasto e diventare un disco di produzione.
Poiché il server è dotato di un controller RAID appropriato con cache write-back, le cache del disco interno devono essere configurate su “disabilitate”. La dimensione dello stripe RAID consigliata è talvolta documentata dal fornitore del server. Se non sono disponibili informazioni, 128 o 256 KB sono buoni valori.
Abilita l’avvio protetto UEFI per impedire il caricamento di moduli del kernel Linux non firmati.
Come ricevere una notifica in caso di dischi rotti?
Una delle maggiori sfide durante il rafforzamento di un server/sistema Linux è il modo in cui ricevere notifiche sui dischi guasti. Tutti i server moderni dispongono di una gestione “out of band” (HPE iLO, Cisco CIMC, Dell iDRAC, Lenovo XCC ecc.). Mostrano lo stato del disco e del RAID e possono notificare via e-mail i dischi guasti. Questo tipo di notifica ha il vantaggio che non è necessario configurare nulla su Linux in seguito. Se l’interfaccia di gestione consente di configurare l’autenticazione a più fattori, va bene e dovrebbe essere usata.
Tieni presente che l’autenticazione a più fattori non protegge dai numerosi problemi di sicurezza che i sistemi di gestione fuori banda avevano in passato. I clienti spesso evitano di utilizzarli per motivi di sicurezza. Se un utente malintenzionato diventa un amministratore della gestione fuori banda, può eliminare tutto il repository con protezione avanzata senza toccare il sistema operativo. Un compromesso potrebbe essere quello di posizionare un firewall davanti alla porta di gestione e consentire solo la comunicazione in uscita. Ciò consentirà di inviare notifiche e-mail in caso di guasto di un disco. Tuttavia, un utente malintenzionato non può attaccare/accedere all’interfaccia di gestione perché il firewall blocca tutte le connessioni in entrata.
Il design potrebbe essere simile all’esempio seguente:
Se si decide di scollegare completamente la porta di gestione fuori banda, le notifiche sui dischi guasti possono essere configurate con il software in esecuzione sul sistema operativo Linux. I fornitori di server spesso forniscono pacchetti per visualizzare lo stato o persino configurare RAID dall’interno del sistema operativo (ad esempio http://downloads.linux.hpe.com/ ). Solitamente questi strumenti possono inviare e-mail direttamente oppure è possibile configurare questa funzione tramite uno script. Lo scripting e la configurazione di strumenti specifici del fornitore non rientrano nell’ambito di questo articolo.
Un’altra opzione è la sorveglianza fisica o con telecamera. Se si cambiano i nastri ogni giorno e si possono controllare fisicamente i LED di stato del server repository con protezione avanzata, questa può essere una soluzione alternativa. Ho anche sentito parlare di clienti che hanno installato telecamere che puntano al server repository con protezione avanzata. Il cliente controlla quindi regolarmente i LED dei dischi tramite la telecamera.
Fuente info
Autor: Andreea Enea
[su_divider]