Questo post è disponibile anche in: Inglese

Nel post precedente ho descritto come migrare i volumi tra due o più EqualLogic all’interno dello stesso gruppo, usando semplicemente due diversi storage pool.

Allo stesso modo è possibile gestire la migrazione dei dati nel sito di disaster recovery: in questo caso i dati sono in realtà le repliche dei volumi che non possono essere spostate come fossero singoli volumi, ma va gestito lo spostamento dell’intero “contenitore”, chiamato delegated space.

Ogni destinazione di una replica (asincrona) deve avere uno (e uno solo) spazio di “delega” dove saranno salvate le repliche e della dimesione corretta per gestirle tutte con le relative versioni. Notare che un delegated space può risiedere solo in un singolo storage pool.

La migrazione delle repliche si traduce in una semplice rilocazione del delegated space, gestibile direttamente modifincandone le sue proprietà e cambiando lo storage pool dove deve risiedere. In questo modo partirà la procedura di migrazione che potrà richiedere anche giorni (a seconda della mole dei dati) ma avrà in grande vantaggio di mantenere le replice attive e funzionanti e non dover costringere una nuova sincronia full tra sito primario e sito di disaster recovery.

La procedura è quindi veramente semplice: si aggiuge il nuovo storage (o i nuovi storage) nel gruppo di disaster recovery esistente, creando però un nuovo pool, si cambia la configurazione del delegated space, si aspetta pazientemente (è possibile controllare questa operazione all’interno nel pannello operations, esattamente come per la migrazione dei volumi) e alla fine si rimove il vecchio storage e il vecchio pool.

Nel caso si voglia semplicemente aggiungere nuovo spazio nel sito di disaster recovery, è possibile inserire il nuovo storage all’interno del pool già esistente e poi ingrandire lo spazio di delega, ma in questo caso tutte repliche saranno sparse tra i vari storage, con il potenziale rischio di perdere tutto nel caso si perda un singolo storage (da non usare assolutamente nel caso di storage single controller).

Una strada alternativa sarebbe di creare un nuovo gruppo da usare come nuovo partner di replica. Ma in questo caso è necessaria una nuova sincronizzazione full che potrebbe richiedere molto tempo. Inoltre si perderanno anche le schedulazioni esistenti relative alla replica. L’unico vantaggio di questa soluzione è di avere alla fine due diversi spazi delegati che potrebbero corrispondere a due pool distinti (ad esempio un pool SATA e un pool SAS).

This post has already been read 378 times.

Andrea MauroAbout Andrea Mauro (2717 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Related Post:

Share