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

Articolo
10/30/2024

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 al xx% sincronizzata 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 di inizializzazione creato per questo disco (nella sottoscrizione di destinazione) è ancora di 1 GB e il log attività mostra alcuni errori del disco di scrittura 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 del disco dati disponibili 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

Non viene testato e convalidato SKU di macchine virtuali di grandi dimensioni per la macchina virtuale dell'appliance.
Se si sta tentando di proteggere nuovamente una macchina virtuale, ma non sono presenti slot sufficienti nell'appliance per contenere i dischi di replica, viene visualizzato il messaggio di errore Si è verificato un errore interno. È possibile controllare il numero di dischi dati attualmente presenti nell'appliance oppure accedere all'appliance, passare a Visualizzatore eventi e 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 per supporto tecnico di Azure matrice.
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 nel caso in cui si verifichi un errore, sudo cp /etc/default/grub /etc/default/grub.bakad esempio .
2. Modificare quindi /etc/default/grub per impostare GRUB_DEFAULT sulla versione precedente da usare. Si potrebbe 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, 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 è possibile eseguire il rollback, attendere 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 di riprotezione manuale 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.
  
  Suggerimento
  
  È 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 lasciano $failbackPolicyName e $failbackExtensionName vuoti o null, la riprotezione può non riuscire. Vedere gli esempi seguenti:

Specificare sempre e $failbackPolicyName $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 servizio di mobilità

Quando si esegue la replica di più macchine virtuali, è possibile che l'integrità dell'elemento protetto sia stata modificata in Avviso nei processi 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.

Suggerimento

È 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 l'insieme di credenziali di Azure Site Recovery nella destinazione, è prima necessario rimuovere tutte le macchine virtuali protette. Se si elimina prima la macchina virtuale dell'appliance, l'insieme di credenziali di Site Recovery blocca l'eliminazione delle risorse protette e il tentativo di eliminare l'insieme di credenziali stesso ha esito negativo. Anche l'eliminazione del gruppo di risorse ha esito negativo e l'unico modo per rimuovere l'insieme di credenziali consiste nell'eliminare la sottoscrizione utente dell'hub di Azure Stack in cui viene creato l'insieme di credenziali.

Per evitare questo problema, assicurarsi di rimuovere prima di tutto la protezione da tutti gli elementi dell'insieme di credenziali, prima di eliminare la macchina virtuale dell'appliance. Ciò consente all'insieme di credenziali di completare la pulizia delle risorse nell'appliance (lato origine). Dopo aver rimosso gli elementi protetti, è possibile eliminare l'insieme di credenziali e rimuovere la macchina virtuale dell'appliance.

Condividi tramite