DR tenant da VCD a VCD

Probabilmente un minimo di managed è cmq necessario, non credo che tramite EM il tenant possa creare job di copia ma solo di backup. Corretto?

ciao, purtroppo ho pochissima esperienza con le soluzioni ?Cloud?

credo che le alternative non ci siano e i problemi più noiosi possano essere nel creare opportunamente la parte rete, aggiornando la regione 2 quando/se sono fatti cambiamenti sulla 1.

Eh, hai ragione. In effetti però in questo caso il tenant sarebbe autonomo, se dimentica di replicare la parte di rete sulla region 2, come dire…. sua responsabilità :-) E cmq poco male, la VM viene su, poi si accorgerà che non ha la rete associata…

come dice il proverbio “uomo avvertito, mezzo replicato”

😂

Ciao Raffaello,

immagino che l’esigenza sia quella di sostituire VCDA per il DR tra datacenter (se è così, siamo anche noi alla ricerca di una soluzione).

Da EM non mi risulta sia possibile creare job di copia, quindi andrebbe gestito come servizio managed.
A questo punto però non sarebbe meglio farlo tramite i job di replica? In caso di DR il cliente potrebbe avviare le VM direttamente da VCD con RPO e RTO conformi.

Si, la situazione è quella.

Con i job di replica però si troverebbe nella stessa situazione dei job di copia: non sarebbe autonomo. E’ vero, sarebbe una situazione Managed, ma nel caso di copia il cliente sarebbe autonomo anche nel ripristino tramite EM, mentre in caso di replica per ripristinare, non avendo accesso al VBR, dovrebbe comunque chiamarci. Diciamo che la prima soluzione la vedo “mezza” managed, mentre la seconda è full. Se accade alle 3 di notte, deve aprire un ticket al reperibile, lui passarlo al secondo livello, ed effettuare l’operazione.

Da quanto ho potuto provare, quando configuri una replica verso VCD hai le VM disponibili e spente nel vDC, con le snapshot dei vari restore points. Sarebbe quindi una soluzione “mezza” managed anche quella, in quanto per il cliente sarebbe sufficiente collegarsi al vDC di replica e avviare manualmente le VM (non ideale dal punto di vista di Veeam, ma comunque funzionante).

Purtroppo in Veeam mancano alcune funzionalità per la replica che sono presenti in un altro concorrente, chissà se coglieranno l’occasione per fare qualche sviluppo in questo ambito 😉

Purtroppo no, le VM nel tenant target sono si, spente, ma non visibili. Occorre fare “failover” da parte del CSP.

Come da documentazione:

https://helpcenter.veeam.com/docs/vbr/cloud/cloud_vcloud_director_quickstart.html?ver=13

“Veeam Cloud Connect does not support VMware Cloud Director as a source for replication to a VMware Cloud Director target.”

Probabilmente la soluzione può essere Orchestrator. Che però conosco veramente poco

ho dato un’occhiata rapida alla doc di VRO, mi pare che il VCD non sia supportato al momento come recovery location.

Ah aspetta, io intendevo utilizzare il VCD primario come sorgente dal backup server nel sito di DR, senza Cloud Connect in mezzo.

Certo che rimarrebbe comunque una soluzione meno flessibile rispetto a VCDA, alcune funzionalità non sono disponibili in Veeam (es. possibilità di assegnare una storage policy diversa per ogni disco delle VM, configurazioni diverse per DR Test e Produzione, ...).

VCD come sorgente su VBR di destinazione, quindi no replica, resterebbe il problema della visibilità della VM replicata, quella è visibile solo su vSphere sottostante. E se fai backup, non credo che EM te lo faccia vedere perchè il job del VBR di destinazione prende la VM da backuppare sul VCD di origine, ma non lo mette a disposizione del tenant sull’EM di destinazione. Certo VCDA sarebbe la soluzione migliore, ma sarebbe troppo lungo spiegarti il motivo per cui non lo adottiamo...

Lo temevo, purtroppo

VCDA è stato dichiarato EoL, quindi è inutile perderci tempo...peccato perchè era una bella soluzione!

i don’t have a lot of experience with cloud solutions - thank you for sharing!