Problemi noti - Azure Site Recovery nell'hub di Azure Stack

Articolo
03/18/2025

Questo articolo descrive i problemi noti per Azure Site Recovery nell'hub di Azure Stack. Usare le sezioni seguenti per informazioni dettagliate sui problemi noti e sulle limitazioni correnti in Azure Site Recovery nell'hub di Azure Stack.

La dimensione massima del disco supportata è 1022 GB

Quando si protegge una macchina virtuale, Azure Site Recovery deve aggiungere altri 1 GB di dati a un disco esistente. Poiché l'hub di Azure Stack presenta una limitazione rigida per le dimensioni massime di un disco a 1023 GB, le dimensioni massime di un disco protetto da Site Recovery devono essere uguali o inferiori a 1022.

Quando si tenta di proteggere una macchina virtuale con un disco di 1023 Gb, si verifica il comportamento seguente:

L'abilitazione della protezione ha esito positivo perché viene creato un disco di inizializzazione di soli 1 GB e pronto per l'uso. Non viene visualizzato alcun errore in questo passaggio.
La replica viene bloccata in xx% sincronizzato e, dopo un po', l'integrità della replica diventa critica con l'errore AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. L'errore si verifica perché durante la replica, Site Recovery tenta di ridimensionare il disco di inizializzazione a 1024 GB e di scrivervi. Questa operazione ha esito negativo perché l'hub di Azure Stack non supporta dischi da 1024 GB.
Il disco iniziale creato per questo disco (nella sottoscrizione di destinazione) è ancora di 1 GB, e il log delle attività mostra alcuni errori di scrittura su disco con il messaggio di errore Il valore '1024' del parametro 'disk.diskSizeGb' non è compreso nell'intervallo. Il valore '1024' deve essere compreso tra '1' e '1023'..

La soluzione alternativa corrente per questo problema consiste nel creare un nuovo disco (di almeno 1022 GB), collegarlo alla macchina virtuale di origine, copiare i dati dal disco da 1023 GB al nuovo disco e quindi rimuovere il disco da 1023 GB dalla macchina virtuale di origine. Al termine di questa procedura, la macchina virtuale ha tutti i dischi più piccoli o uguali a 1022 GB, è possibile abilitare la protezione con Azure Site Recovery.

Riprotezione: slot disponibili per dischi dati nell'appliance

Verificare che la macchina virtuale dell'appliance disponga di sufficienti slot del disco dati, perché i dischi di replica per la riprotezione sono collegati all'appliance.
Il numero iniziale consentito di dischi ri-protetti contemporaneamente è 31. Le dimensioni predefinite dell'appliance creata dall'elemento marketplace sono Standard_DS4_v2, che supporta fino a 32 dischi dati e l'appliance stessa usa un disco dati.
Se la somma delle macchine virtuali protette è maggiore di 31, eseguire una delle azioni seguenti:
- Suddividere le macchine virtuali che richiedono la riprotezione in gruppi più piccoli per garantire che il numero di dischi nuovamente protetti contemporaneamente non superi il numero massimo di dischi dati supportati dall'appliance.
- Aumentare le dimensioni della macchina virtuale dell'appliance di Azure Site Recovery.
Nota

Noi non testiamo e convalidiamo i modelli SKU di macchine virtuali di grandi dimensioni per le macchine virtuali dell'appliance.
Se si sta provando a proteggere nuovamente una macchina virtuale, ma nell'appliance non sono presenti slot sufficienti per contenere i dischi di replica, il messaggio di errore Viene visualizzato un errore interno. È possibile controllare il numero di dischi dati attualmente presenti nell'appliance oppure accedere all'appliance, passare a Visualizzatore eventie aprire i log per azure Site Recovery in Registri applicazioni e servizi:

Trovare l'avviso più recente per identificare il problema.

Versione del kernel della macchina virtuale Linux non supportata

Controllare la versione del kernel eseguendo il comando uname -r.

Per altre informazioni sulle versioni del kernel Linux supportate, vedere Azure to Azure support matrix.
Con una versione del kernel supportata, il failover, che fa sì che la macchina virtuale esegua un riavvio, può causare l'aggiornamento della macchina virtuale di failover a una versione del kernel più recente che potrebbe non essere supportata. Per evitare un aggiornamento a causa di un riavvio di una macchina virtuale di failover, eseguire il comando sudo apt-mark hold linux-image-azure linux-headers-azure in modo che l'aggiornamento della versione del kernel possa continuare.
Per una versione del kernel non supportata, verificare la presenza di una versione precedente del kernel a cui è possibile eseguire il rollback eseguendo il comando appropriato per la macchina virtuale:
- Debian/Ubuntu: dpkg --list | grep linux-image
L'immagine seguente mostra un esempio in una macchina virtuale Ubuntu nella versione 5.4.0-1103-azure, che non è supportata. Dopo l'esecuzione del comando, è possibile visualizzare una versione supportata, 5.4.0-1077-azure, già installata nella macchina virtuale. Con queste informazioni, è possibile eseguire il rollback alla versione supportata.
Eseguire il rollback a una versione del kernel supportata seguendo questa procedura:
1. Prima di tutto, creare una copia di /etc/default/grub in caso di errore; ad esempio, sudo cp /etc/default/grub /etc/default/grub.bak.
2. Modificare quindi /etc/default/grub per impostare GRUB_DEFAULT sulla versione precedente da usare. È possibile avere qualcosa di simile a GRUB_DEFAULT="Opzioni avanzate per Ubuntu>Ubuntu, con Linux 5.4.0-1077-azure".
3. Selezionare Salva per salvare il file e quindi selezionare Esci.
4. Eseguire sudo update-grub per aggiornare il grub.
5. Infine, riavviare la macchina virtuale e continuare con il rollback a una versione del kernel supportata.
Se non si dispone di una versione precedente del kernel a cui eseguire il rollback, aspettare l'aggiornamento dell'agente di mobilità in modo che il kernel possa essere supportato. L'aggiornamento viene completato automaticamente, se è pronto ed è possibile controllare la versione nel portale per confermare:

La risincronizzazione manuale per la riprotezione non è ancora supportata

Al termine del processo di riprotezione, la replica viene avviata in sequenza. Durante la replica, possono verificarsi casi che richiedono una risincronizzazione, il che significa che viene attivata una nuova replica iniziale per sincronizzare tutte le modifiche.

Esistono due tipi di risincronizzazione:

Risincronizzazione automatica. Non richiede alcuna azione dell'utente e viene eseguita automaticamente. Gli utenti possono visualizzare alcuni eventi visualizzati nel portale:
Risincronizzazione manuale. Richiede l'azione dell'utente per attivare manualmente la risincronizzazione ed è necessaria nelle istanze seguenti:
- Manca l'account di archiviazione scelto per la riprotezione.
- Il disco di replica nell'appliance è mancante.
- La scrittura della replica supera la capacità del disco di replica nell'appliance.
  
  Mancia
  
  È anche possibile trovare i motivi di risincronizzazione manuale nel pannello eventi per decidere se è necessaria una risincronizzazione manuale.

Problemi noti nell'automazione di PowerShell

Se si lascia $failbackPolicyName e $failbackExtensionName vuoto o null, la riprotezione può non riuscire. Vedere gli esempi seguenti:

Specificare sempre il $failbackPolicyName e $failbackExtensionName, come illustrato nell'esempio seguente:

$failbackPolicyName = "failback-default-replication-policy"
$failbackExtensionName = "default-failback-extension"
$parameters = @{
    "properties" = @{
        "customProperties" = @{
            "instanceType" = "AzStackToAzStackFailback"
            "applianceId" = $applianceId
            "logStorageAccountId" = $LogStorageAccount.Id
            "policyName" = $failbackPolicyName
            "replicationExtensionName" = $failbackExtensionName
        }
    }
}
$result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters

Avviso dell'agente del servizio Mobility

Quando si esegue la replica di più macchine virtuali, è possibile che venga visualizzato l'errore integrità dell'elemento protetto cambiata in Avviso nei job di Site Recovery.

Questo messaggio di errore deve essere solo un avviso e non è un problema di blocco per i processi di replica o failover effettivi.

Consiglio

È possibile controllare lo stato della rispettiva macchina virtuale per assicurarsi che sia integro.

L'eliminazione della macchina virtuale dell'appliance (origine) blocca l'eliminazione dell'insieme di credenziali (destinazione)

Per eliminare la cassaforte di Azure Site Recovery nel target, è necessario prima rimuovere tutte le macchine virtuali protette. Se si elimina prima la macchina virtuale dell'appliance, la cassetta di Azure Site Recovery blocca l'eliminazione delle risorse protette e il tentativo di eliminare la cassetta stessa ha esito negativo. Anche l'eliminazione del gruppo di risorse ha esito negativo e l'unico modo per rimuovere la cassetta delle chiavi è eliminare la sottoscrizione utente di Azure Stack Hub in cui è stata creata la cassetta delle chiavi.

Per evitare questo problema, assicurarsi di rimuovere prima di tutto la protezione da tutti gli elementi nel vault, prima di eliminare la macchina virtuale dell'appliance. Ciò consente alla cassaforte di eseguire la pulizia delle risorse sull'appliance (sul lato sorgente). Dopo aver rimosso gli elementi protetti, è possibile eliminare la cassetta di sicurezza e rimuovere la macchina virtuale dell'appliance.

Condividi tramite