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!

Ciao @atinivelli ho letto il tuo blog e a questo punto mi pongo una domanda: come mai avere più VBR server all’interno di una stessa infrastruttura e non affidare risorse a proxy dedicati a tali attività? 

Quando lavoravo per un grosso Service Provider gestivamo circa 30 VBR server e 3-400 proxies ma si parlava di ambienti diversi completamente isolati tra di loro. 

Comunque la virtualizzazione di più LHR è sconsigliata nell’utilizzo per i motivi che tu e @mrizzi2 avete descritto. 

non la discuto dal punto di vista della fattibilità ma ne faccio una questione più tecnico/pratica a livello hardware. Le appliance hardware che offrono servizi S3 montano almeno 192GB di ram. Questo perchè la necessità di elaborazione deve essere alta e rapida. 

Volendo fare n LHR su un server fisico utilizzando la virtualizzazione dovresti comunque avere almeno 192 x n = xxx GB di ram.

Ti porto un esempio pratico… ultimamente abbiamo avuto un preventivo per un server fisico biprocessore con 192GB di ram e 36TB di dischi. 

Costo di listino circa 20K 

facciamo che vogliamo creare 4 LHR dovremmo avere almeno 1*4 768GB di ram e 36*4=144 TB di dischi. Ti direi che siamo almeno a 50K.

Aggiungi i seguenti costi tra acquisto licenze e gestioni operative:

licenze VMWAre

licenze RedHat

installazione a rack (1 gg/uomo)

installazione VMWare (2gg/uomo)

installazione Sistemi operativi hardenizzati (2gg * 4OS = 8 gg/uomo)

configurazioni per segmentazioni di rete (2 gg/uomo)

manutenzione dei software per 5 anni (3 update vmware + 2 update OS per ogni anno = 25gg/uomo)  

licenze a parte ci sono circa 40 gg/uomo Senior a 500€ = 20K

Siamo a un totale di almeno 70K licenze a parte. facciamo lo sconto del 40% siamo a 42K + licenze software facciamo un totale di 45K

Ti dico che con quel prezzo ce la compri una appliance da 128TB con protocollo S3. La monti e non devi fare più nulla!

Come vedi il costo dell’hardware, le licenze VMware e il costo umano vanno a superare di gran lunga l’acquisizione di una appliance hardware con protocollo S3 da cui puoi esportare più bucket e creare più repository sui tuoi diversi VBR server.  

Keep it simple!  

My 2 cents.

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….