La nuova Veeam Availability Suite v9, presto in arrivo, offre tantissime nuove e interessanti funzionalità progettate per migliorare gli ambienti enterprise. Questi ambienti presentano solitamente due caratteristiche che richiedono soluzioni adeguate: scalabilità e gestione di sedi e uffici remoti.
L’interazione con l’OS guest delle macchine virtuali protette, al fine di eseguire correttamente backup e ripristini, rappresenta una fantastica funzionalità avanzata del nostro software. In quanto soluzione totalmente “agentless”, i backup eseguono un processo temporaneo all’interno di tutte le macchine virtuali sulle quali è stato abilitato l’“Application Aware Image Processing”. Questo processo è responsabile dell’elaborazione VSS ed esegue operazioni specifiche per l’applicazione, come il troncamento dei log e l’indicizzazione del file system.
Prima della versione v9, tutte le interazioni con il guest erano eseguite dal server di backup. Per ciascuna VM protetta, il Veeam Backup Server centrale lanciava il processo di interazione guest direttamente nella VM (direttamente nell’OS tramite rete o via API VIX, sfruttando la connessione con l’host per le VMs su reti disconnesse). Questo sistema ha sempre funzionato perfettamente, ma con l’aumentare delle dimensioni e della complessità degli ambienti protetti, sono emerse due limitazioni.
Per prima cosa, la scalabilità. L’elaborazione guest è gestita dal server di backup, tuttavia il numero di VM protette in un ambiente aziendale tipico è aumentata così tanto da provocare colli di bottiglia, limitando quindi la quantità di interazioni guest concorrenti.
La seconda limitazione è in qualche modo legata alla prima. Gli ambienti enterprise sono solitamente caratterizzati da molti uffici remoti, con ambienti virtuali utilizzati localmente per servire gli utenti di tali filiali. Poiché in questo tipo di scenari il server VBR è solitamente installato presso la sede centrale, tutte le interazioni guest devono avvenire tramite collegamento WAN, che spesso potrebbe essere poco performante.
Se nell’ufficio remoto sono stati implementati backup proxy e repository per mantenere il traffico generato da backup e ripristini locale, l’interazione con i guest OS deve comunque attraversare la rete WAN, il potrebbe introdurre problemi di scalabilità di questi ambienti.
Per migliorare le prestazioni, la versione v9 introduce il Guest Interaction Proxy. I clienti possono assegnare questo ruolo virtuale a qualsiasi server Windows gestito (inclusi i proxy di backup e i repository esistenti). Il proxy di backup remoto all’interno di una filiale rappresenta solitamente il candidato ideale, poiché si tratta di quello più vicino alle macchine virtuali che protegge:
Con il Guest Interaction Proxy locale, il server di backup dovrà solo inviare i comandi di controllo via WAN. Sarà il Guest Interaction Proxy “locale” ad interagire con il guest OS delle VMs locali. Di conseguenza, il traffico che attraversa il collegamento lento sarà ridotto al minimo, mentre il carico sul server VBR diminuirà. Poiché un singolo server di backup sarà in grado di controllare più Guest Interaction Proxy, la scalabilità migliorerà notevolmente. Prendiamo come esempio clienti enterprise con 500 siti remoti. Questa società può ora definire che il proxy di backup di ciascun sito operi anche come Guest Interaction Proxy, il tutto controllato dal server di backup centrale. Ovviamente si possono usare più Guest Interaction Proxy all’interno di un unico grande data center per migliorare le performance e scalare le attività di interazione con i guest OS.
Un altro vantaggio nascosto di questa funzionalità, che potrebbe non risultare immediatamente visibile, consiste nella possibilità di accedere al guest OS anche quando non è possibile l’elaborazione networkless tramite VIX (per esempio quando un account con privilegi avanzati non può essere fornito per motivi di sicurezza). Di fatto, è ora possibile selezionare un computer Windows con NIC sulle reti di produzione e backup e utilizzarlo como Guest Interaction Proxy per “inoltrare” le comunicazioni dalla rete di backup alla rete di produzione.
Tuttavia, i backup rappresentano soltanto metà del processo. Una volta che i dati sono conservati in modo sicuro all’interno di un repository, potrebbe essere necessario eseguire un ripristino. Pensando nuovamente allo scenario di un ufficio remoto, attualmente i ripristini a livello di singolo file devono essere eseguiti dal server di backup centrale, con i file di backup letti remotamente da tale server:
Anche quando il repository di backup è locale nel sito remoto, durante i ripristini in-place a livello di singolo file i dati dovrebbero attraversare il collegamento WAN lento due volte: prima per essere estratti dal server di backup e di nuovo per essere rispediti alla macchina virtuale, target del ripristino, presso il sito remoto. Una soluzione comune a questo problema è stata, finora, l’utilizzo del wizard Multi-OS File Level Restore (FLR) con la FLR appliance installata presso l’infrastruttura remota, tuttavia questo approccio presenta degli svantaggi.
Con la versione v9 tutto ciò non è più necessario: grazie alla nuova impostazione Mount Server per ciascun repository di backup, qualsiasi server Windows gestito da Veeam può ora essere selezionato mount point per i backup Veeam. Naturalmente non vi è un’opzione migliore di un repository Windows già esistente e utilizzabile come mount point!
Ora, grazie a questo nuovo ruolo virtuale, il server VBR centrale invierà solo i comandi di controllo via WAN, mentre il backup remoto sarà montato dal server locale scelto per il ripristino dei file direttamente sulla macchina virtuale remota e tutti i rimanenti trasferimenti di dati rimarranno all’interno sito remoto.
Rimanendo in tema di operazioni “remote”, un’altra novità importante della versione v9 è la console indipendente. Sì, stiamo parlando proprio dell’attesissima console Veeam Backup & Replication che gli amministratori Veeam saranno in grado di installare separatamente dal server di backup, per esempio sulla loro workstation, così da consentire la gestione remota del backup server. Possiamo dire addio alle sessioni RDP o alle sessioni con più utenti che sgomitano connettendosi allo stesso server di backup, ciascun operatore disporrà ora della propria console. La console assume inoltre il ruolo di mount point per i ripristini avanzati che richiedono il caricamento locale dei backup (come nel caso di Veeam Explorers); questa funzionalità sarà molto utile negli scenari ROBO.
Ma non finisce qui! Già dalla versione v8 ci stiamo impegnando ad offrire il miglior supporto su nastro disponibile sul mercato per i clienti di qualsiasi dimensione e la versione v9 introdurrà nuove funzionalità per le librerie, attesissime dai nostri clienti enterprise. Qui parlerò solo dei più importanti, ma vi assicuro che ce ne sono molti di più!
Per prima cosa, sarà ora possibile creare un Media Pool indipendente dalla singola libreria fisica e in grado di essere utilizzato da più device. Questo “media pool globale” diventerà la destinazione principale dei backup su nastro e migliorerà sia le performance, sia l’esperienza di gestione complessiva.
Con il “media pool globale”, un backup su nastro può utilizzare più librerie o unità indipendenti in base all’ordine di failover configurato per tale libreria. Immaginiamo per esempio che tutti i supporti di una libreria siano pieni, oppure che tutte le unità a nastro siano occupate. Grazie ai media pool globali, un backup su nastro potrà ora passare ad un’altra libreria che abbia spazio disponibile.
Quali altre fantastiche funzionalità stiamo introducendo per migliorare le performance delle attività su nastro? La tanto desiderata elaborazione parallela tra unità a nastro diventa disponibile con la versione v9! Ciò che in precedenza richiedeva l’impostazione di più media pool e job di backup su nastro, con conseguente aumento delle complessità, sarà ora disponibile “out of the box”!
Si tratta di un’opzione semplice ma potente, che vi consentirà di eseguire job su nastro sullo stesso media pool contemporaneamente, oppure di distribuire l’archiviazione dei file di backup sorgente su più unità.
Parliamo ora di rotazione dei supporti nastro. Sono certo che tanti di voi saranno felici di scoprire che nella versione v9 sarà disponibile un nuovo tipo di media pool: il GFS Media Pool per i backup full. Anche in questo caso, sebbene con la versione v8 fosse possibile ottenere un risultato molto simile con più media pool, la versione v9 fa un ulteriore passo avanti e rimuove completamente qualsiasi complessità di gestione.
Se conoscete il nostro meccanismo di rotazione esistente Grandfather – Father – Son (GFS) per la copia dei backup nella versione v8, il concetto rimane pressoché immutato. Quando i backup full su nastro vengono scritti nel GFS Media Pool, i nastri corrispondenti saranno conservati in base ad uno specifico schema basato su settimane, mesi, trimestri e persino anni; di fatto, per tutto il tempo che desiderate.
Con un GFS Media Pool sono necessari meno nastri per ottenere un periodo di conservazione più lungo. Per esempio, configurando lo schema di rotazione GFS affinché mantenga 4 anni di backup full saranno necessari solo 19 nastri: 4 settimanali, 12 mensili e 3 annuali. I media pool tradizionali continueranno ad essere disponibili per la conservazione dei backup a breve termine e per i backup incrementali, quindi sarete voi a decidere quale sia il media pool più adeguato per le vostre esigenze di conservazione dei dati.
Come potete vedere, ci sono tantissime nuove funzionalità di livello enterprise in arrivo con la versione v9. E questo è solo l’inizio: la funzionalità più incredibile della versione v9 non è stata ancora svelata. Spero che il nostro lavoro dimostri chiaramente l’interesse che abbiamo nei confronti dei clienti enterprise e delle loro esigenze specifiche. Siamo convinti di potere offrire un prodotto che sia enterprise-ready al 100% e che possa scalare facilmente per garantire sempre la disponibilità al vostro business in espansione.
