Quando si utilizza VEEAM o qualsiasi altra applicazione di backup che utilizza BOOST per eseguire i backup, utilizza la funzionalità Virtual Synthetics, crea nuovi backup da quelli esistenti unendo parti dei backup precedenti su DD e quindi aggiunge le differenze. I backup precedenti utilizzati per i unione sono denominati "file di base".
La maggior parte delle applicazioni di backup leggerà ma non modificherà i file di base utilizzati per sintetizzare nuove immagini di backup, tuttavia VEEAM funziona in modo diverso, quando si eseguono i backup sovrascrive parti dei file di base già su disco.
Quando la replica MTree in uscita è configurata per questo LSU/MTree VEEAM, è possibile che un file di backup replicato venga modificato da BOOST durante la sintesi dei nuovi file di backup. Se DD di origine esegue DDOS 6.x ed è abilitata la replica della ricetta (un'opzione di ottimizzazione della velocità/delle prestazioni in DDOS 6.x e versioni successive), ciò può comportare l'arrivo di checksum errati sul DD di destinazione, che potrebbe causare ripetutamente l'errore FS (File System) con messaggi come i seguenti:
27 feb 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ERROR: MSG-INTRNL-00001: ERRORE IRREVERSIBILE: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum = repl_chksum).
Nel modo in cui VEEAM sintetizza nuovi backup da quelli esistenti, potrebbero essere presenti sovrascritture di alcune parti dei file replicate quando utilizzate come file di base per sintetizzare nuove immagini di backup. Ciò crea confusione per la replica a livello di ricetta quando la storage unit VEEAM è configurata anche per essere utilizzata come parte della replica MTree, causando potenzialmente un errore irreversibile del DD di destinazione.
Si noti che questo difetto si applica solo all'estremità di destinazione per la replica MTree quando l'origine è:
- Se si esegue DDOS 6.0.1.0 o versioni precedenti (ad esempio, tutto DDOS 6.0.0.x sarà interessato)
- DDOS 6.x precedente a DDOS 6.0.2.0 o 6.1.1.1
- Esecuzione di backup VEEAM su un LSU/MTree e la stessa MTree viene replicata nella destinazione utilizzando la replica MTree
- I backup BOOST con sintetici virtuali abilitati vengono eseguiti sullo stesso LSU/MTree
- Quando viene rilevato questo difetto, può comportare che l'MTree di destinazione replicato diventi non disponibile con più riavvii del processo FS. Coloro che potrebbero utilizzare questa configurazione o stanno pianificando di configurare i propri sistemi in questo modo sono invitati a utilizzare la soluzione alternativa descritta di seguito o a eseguire l'aggiornamento a DDOS 6.0.2.0 o 6.1.1.1 (o a qualsiasi versione successiva).
Nota: è possibile che la stessa stringa panic sul termine di destinazione per la replica MTree possa verificarsi per problemi diversi da questo, in quanto l'errore indica semplicemente che un checksum nella snapshot di replica MTree non corrisponde. Per eventuali dubbi sul problema descritto qui o su come aggirare un problema, contattare il fornitore del supporto con contratto e fare riferimento al numero di questo articolo della Knowledge Base
491049.
DD Engineering ha identificato la root cause per le SCHEDE PANIC FS sul nodo di destinazione e ha stanziato una correzione nelle seguenti versioni:
- DDOS 6.0.2.0 e versioni successive
- DDOS 6.1.1.1 e versioni successive
Chiunque sia interessato da questo difetto o stia pianificando di configurare una configurazione simile è consigliato per aggiornare il DD di origine alle versioni menzionate il prima possibile.
Per coloro che non desiderano eseguire l'aggiornamento o che si trovano ad affrontare il problema prima che la versione corretta diventi disponibile, è disponibile una soluzione alternativa.
Consiste nel disabilitare l'ottimizzazione della replica della ricetta sul sistema DDOS 6.x di origine.
Questa ottimizzazione è presente solo in DDOS 6.x e versioni successive, l'unico svantaggio della disabilitazione sarebbe una velocità di replica inferiore a quella ottenuta su DDOS 5.7.
Prima dell'implementazione è necessario prima verificare se questa soluzione alternativa è applicabile all'installazione corrente:
- Verificare se DD di origine esegue DDOS 6.x prima della release in cui è stato corretto questo problema (bug corretto in DDOS 6.0.2.0 e 6.1.1.1 e versioni successive)
- Verificare che il DD configurato per i backup VEEAM sia configurato anche per la replica MTree per l'LSU/MTree oggetto come origine (il controllo di un ASUP recente sarebbe il modo più semplice per confermare), ad esempio:
CTX: 20 Mode: source Destination: mtree://destination-dd.example.com/data/col1/destination_MTree Enabled : yes (Modalità 20: destinazione origine: mtree://destination-dd.example.com/data/col1/destination_MTree abilitata: sì)
Se si applicano tutte queste condizioni di cui sopra, questo sistema potrebbe essere soggetto ai difetti di cui sopra e potrebbe causare l'arresto anomalo del FS di replica di destinazione.
Per applicare la soluzione alternativa, è innanzitutto necessario assicurarsi che non siano in esecuzione backup di replica o BOOST, quindi modificare l'impostazione del Registro di sistema, che non richiede downtime. Prima di avviare questo processo, leggere l'informativa ATTENZIONE riportata sotto la fase finale di questa procedura.
- Assicurarsi che la replica da DD a DD sia disabilitata sul DD di origine che esegue DDOS 6.x:
# la replica disattiva tutto
- Inoltre, assicurarsi che non siano in corso backup BOOST o BOOST MFR da o verso l'LSU/MTree VEEAM potenzialmente in errore prima di applicare l'impostazione di registro. Se necessario, disabilitare temporaneamente i backup e MFR da o verso questa LSU:
# ddboost file-replication show active all
# ddboost file-replication show stats
- Questa modifica del Registro di sistema richiede privilegi di modalità SE.
NOTA: I comandi SE sono stati obsoleti nelle versioni DDOS 7.7.5.25, 7.10.1.15, 7.13.0.15, 6.2.1.110 e successive e sono accessibili solo dai dipendenti Dell.
- Dalla modalità SE, modificare l'impostazione di registro per disabilitare l'utilizzo della replica di ricetta:
# se sysparam set RECIPE_REPL_ENABLED=FALSE
- Verificare che il parametro di sistema sia stato impostato correttamente e che venga visualizzato come "FALSE" (disabilitato)
# se sysparam show RECIPE_REPL_ENABLED
Descrizione nome Override predefinito corrente
------------------- ------------------------------------------------ ------- ------- --------
RECIPE_REPL_ENABLED Enable recipe replication (apply to source only) FALSE TRUE rpc
------------------- ------------------------------------------------ ------- ------- --------
- Ora è possibile riabilitare DD alla replica DD e riprendere i backup BOOST e BOOST MFR da o verso l'LSU:
# Abilitazione della replica
ATTENZIONE: Se l'elaborazione della ricetta è stata disabilitata su un sistema di origine Data Domain configurato anche come destinazione finale per la replica, anche i sistemi di origine per tali contesti dovranno eseguire il processo di cui sopra (la replica della ricetta è disabilitata).
Inoltre, dopo l'aggiornamento a una versione corretta (DDOS 6.0.2.0 o 6.1.1.1) l'impostazione dovrà essere ripristinata in modo da poter sfruttare la replica della ricetta. L'aggiornamento non reimposta la chiave di registro. Dopo aver completato l'aggiornamento riabilitare la replica della ricetta accedendo a DD, accedere alla modalità privilegio SE ed eseguire:
# se sysparam reset RECIPE_REPL_ENABLED
Se non si è sicuri del processo descritto in precedenza, contattare il fornitore del supporto in questione e fare riferimento
a questo articolo della Knowledge Base 491049 .
C'è sempre la possibilità che i PANIC siano dovuti a un problema diverso e la soluzione alternativa applicata potrebbe non funzionare mentre i FS PANIC sulla DD di destinazione continuano.
In tal caso, è consigliabile che i DD di origine e di destinazione vengano aggiornati al codice sicuro (release DDOS menzionate in precedenza) e che i contesti di replica che presentano un errore vengano interrotti (non configurati), che le snapshot esistenti siano scadute e che il contesto di replica venga aggiunto e reinizializzato. Poiché si tratta di un processo potenzialmente dispendioso in termini di tempo e potrebbero esserci diversi contesti di replica che potrebbero essere la causa del problema, contattare il provider di supporto in questione e fare riferimento al numero di questo articolo della Knowledge Base e a tutte le azioni eseguite finora per assistenza.