Usare lo stesso server fisico per fare più linux hardened repo: ha senso?

Ciao!

hai fatto bene a introdurre questo topic, sono molto interessato alle opinioni della community a questo riguardo. Personalmente mi sono già trovato alcune volte in una situazione simile, e mi riferisco in particolare agli hardened repo virtuali, e non ho riscontrato problemi.

Immagino che la risposta ufficiale di Veeam sia quella di evitare questo tipo di configurazione poiché il layer di virtualizzazione “complica” il mantenimento della messa in sicurezza dell’ambiente di backup in questo tipo di scenario (è molto più semplice mettere in sicurezza un box fisico autoconsistente). Personalmente ritengo che l’elemento essenziale in questo scenario sia avere molto ben chiari i principi di sicurezza e di segmentazione di rete e degli accessi, dopodiché non vedo particolari problemi.

Rimango super interessato alla finestra per conoscere le opinioni degli altri membri della Community!

Un saluto,

Massimiliano

già, è sicuramente vero che usare come hard repo una vm che sta su una infrastruttura virtuale di produzione o condivisa con altri ha poco senso (e me l’hanno fatto fare ugualmente).

Però quello della mia perversione mattutina (una volta i pensieri mattutini erano assai differenti 😍) sarebbe comunque in un “box fisico autoconsistente”, pur se condiviso fra diversi VBR server. Vediamo che ne pensa la community, intanto grazie per non avermi fatto sentire del tutto impazzito 😉

Si scusami, nella mia testa intendevo “box fisico autoconsistente” la classica implementazione “da manuale” in cui abbiamo un server fisico dedicato con il sistema operativo Linux installato. Allo stesso tempo confermo che il requisito minimo di questo scenario è che l’hypervisor sia completamente indipendente dall’ambiente di produzione, anche come segmentazione di rete.

Un saluto!

Personalmente mi soffermerei solo sulla reale esigenza di avere due Veeam distinti che scrivono su uno stesso VHR..non mi vengono in mente molti use case, e se proprio mi dovesse servire un VBR dedicato per il NAS backup, forse significa che mi servirà anche un VHR dedicato per tutti quei dati! 😅

Comunque curioso di ascoltare altri pareri! 💚

la necessità ce l’avrei per esempio da un cliente che ha un solo VBR, repository su macchina fisica linux immutabile.
Quel VBR gestisce migliaia di VM (vSphere e Ovirt), RMAN e una caterva di dati che vengono riversati su nastro: praticamente non si può fermare mai o quasi mai, oltre ad avere un db di dimensioni elevate e che impiega tempi biblici, per giunta imprevedibili (nemmeno il supporto è riuscito a darmi un modo per stimare né vedere il progresso) quando si tenta di migrarlo su nuova VM o nuovo SQL server.
Fossero due, o tre server VBR sotto un EM, si potrebbe lavorare con una certa serenità.

Sul calcolo sono interessantissime le considerazioni di Andrea ma ogni caso penso vada sempre analizzato per sé: l’appliance da 128TB nel suddetto caso sarebbe microscopica 😉

Fra installare Ubuntu su un Apollo oppure ESXi e due Ubuntu i costi “vivi” sono quelli della licenza ESXi, che sono abbastanza limitati. I costi della “manodopera” sono molto variabili, ad esempio se c’è un IT interno non stracarico in grado di farlo sono limitati o nulli (si può vedere come formazione).
Poi se ormai l’hai comprato, non hai budget per altro, mi sa che l’unico modo per partizionarlo in due è la vecchia virtualizzazione 😊

Secondo me è stato sbagliato il disegno architetturale iniziale. 

Personalmente (e anche con il mio collega Marco) abbiamo fatto una distinzione sui clienti: 

clienti piccoli → LHR

clienti medi → server con appliance software (Ad es. Scality) 

clienti grandi →  appliance storage S3

Enterprise → infrastrutture enterprise 

Il taglio da 128 TB come repository di backup è la base iniziale per i clienti grandi (vado a memoria ma partendo da una source data di 50 TB con 30gg e GFS 8w+12m+3y sei intorno ai 120TB di occupazione)…. se tu sei su cifre più grandi devi per forza mettere in piedi repository di tipo enterprise e non un Hardened repository.

Per il database del tuo cliente mi pare di ricordare che ci fosse di mezzo una tape e il suo catalogo viene memorizzato nel database. Quindi cresce a dismisura.

questo è sicuramente penalizzante però un altro aspetto che i clienti devono conoscere è che è necessario avere delle finestre di manutenzione per gli aggiornamenti. 

Non so, se hai una criticità/collo di bottiglia nelle tape e lo separi in modo da rendere gli altri più flessibili nella gestione, comunque la criticità nelle tape rimane! 😅

Forse in prima battuta conviene ripensare/snellire quei task troppo pesanti..

Per quanto riguarda la migrazione del config db, con la ultima versione dovrebbe essere stato migliorato il processo:

Configuration Backup and Restore improvements — enhanced our code’s reliability in several corner
cases observed in Customer Support particularly around large-scale deployments of File to Tape backup
jobs. These enhancements should facilitate seamless large-scale configuration database migrations from
Microsoft SQL Server to PostgreSQL.

Ricordo che avevi auto problemi un pò di tempo fa..magari riprova (se non l’hai già fatto) e facci sapere!

sto cercando questa frase nelle release notes della 12.2 ma proprio non la trovo… comunque devo fare un sql->sql senza postgres

tutto giusto ma purtroppo ci si scontra con situazioni pregresse ed è nota la necessità di finestre di manutenzione, ma averle solo una volta a settimana o meno complica le cose, si finisce per rimandare e i db crescono 😉

In fondo, sezione “Backup Console”

ak on è nel “What’s new” e non nelle Release Notes.

Peccato che “These enhancements should facilitate seamless large-scale configuration database migrations from Microsoft SQL Server to PostgreSQL”  sembra dire che non ci saranno miglioramenti nel caso a cui lavorerò, ahimè. ma chissà, speriamo….