Bekannte Probleme – Azure Site Recovery im Azure Stack Hub

Artikel
10/30/2024

In diesem Artikel werden bekannte Probleme für Azure Site Recovery auf Azure Stack Hub beschrieben. In den folgenden Abschnitten finden Sie Details zu den aktuellen bekannten Problemen und Einschränkungen in Azure Site Recovery auf Azure Stack Hub.

Maximal unterstützte Datenträgergröße beträgt 1022 GB

Wenn Sie einen virtuellen Computer schützen, muss Azure Site Recovery einem vorhandenen Datenträger zusätzliche 1 GB Daten hinzufügen. Da Azure Stack Hub eine harte Einschränkung für die maximale Größe eines Datenträgers mit 1023 GB hat, muss die maximale Größe eines datenträgers, der durch Site Recovery geschützt ist, gleich oder kleiner als 1022 sein.

Wenn Sie versuchen, einen virtuellen Computer mit einem Datenträger von 1023Gb zu schützen, tritt das folgende Verhalten auf:

Der Aktivierungsschutz ist erfolgreich, da nur ein Startdatenträger von nur 1 GB erstellt und einsatzbereit ist. Bei diesem Schritt ist kein Fehler aufgetreten.
Die Replikation wird bei xx % synchronisiert und nach einer Weile wird die Replikationsintegrität kritisch mit dem Fehler AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. Der Fehler tritt auf, da Site Recovery während der Replikation versucht, die Größe des Seeddatenträgers auf 1024 GB zu ändern und in ihn zu schreiben. Dieser Vorgang schlägt fehl, da Azure Stack Hub 1024 GB Datenträger nicht unterstützt.
Der für diesen Datenträger erstellte Startdatenträger (im Zielabonnement) hat weiterhin eine Größe von 1 GB, und das Aktivitätsprotokoll zeigt einige Schreibdatenträgerfehler mit der Fehlermeldung an. Der Wert "1024" des Parameters "disk.diskSizeGb" liegt außerhalb des Zulässigen. Der Wert "1024" muss zwischen "1" und "1023" (einschließlich) liegen.

Die aktuelle Problemumgehung für dieses Problem besteht darin, einen neuen Datenträger (von 1022 GB oder weniger) zu erstellen, sie an Ihre Quell-VM anzufügen, die Daten vom Datenträger 1023 GB auf den neuen datenträger zu kopieren und dann den Datenträger 1023 GB aus der Quell-VM zu entfernen. Sobald dieses Verfahren abgeschlossen ist und der virtuelle Computer alle Datenträger kleiner oder gleich 1022 GB hat, können Sie den Schutz mithilfe von Azure Site Recovery aktivieren.

Erneuter Schutz: verfügbare Datenträgerplätze auf Anwendung

Stellen Sie sicher, dass die Anwendung VM über genügend Datenspeicherplätze verfügt, da die Replikatdatenträger zum erneuten Schutz an die Anwendung angefügt sind.
Die anfänglich zulässige Anzahl von Datenträgern, die gleichzeitig erneut geschützt werden, beträgt 31. Die Standardgröße der aus dem Marketplace-Element erstellten Anwendung ist Standard_DS4_v2, die bis zu 32 Datenträger unterstützt, und die Anwendung selbst verwendet einen Datenträger.
Wenn die Summe der geschützten virtuellen Computer größer als 31 ist, führen Sie eine der folgenden Aktionen aus:
- Teilen Sie die virtuellen Computer, die einen erneuten Schutz erfordern, in kleinere Gruppen auf, um sicherzustellen, dass die Anzahl der Datenträger gleichzeitig erneut geschützt ist, die maximale Anzahl von Datenträgern, die die Anwendung unterstützt, nicht überschreitet.
- Erhöhen Sie die Größe der Azure Site Recovery Anwendung VM.
Hinweis

Wir testen und überprüfen keine großen VM-SKUs für die Anwendung VM.
Wenn Sie versuchen, einen virtuellen Computer erneut zu schützen, aber nicht genügend Steckplätze auf dem Anwendung vorhanden sind, um die Replikationsdatenträger zu halten, wird die Fehlermeldung Angezeigt ein interner Fehler. Sie können die Anzahl der Datenträger überprüfen, die sich derzeit auf dem Anwendung befinden, oder sich beim Anwendung anmelden, zu Ereignisanzeige wechseln und Protokolle für Azure Site Recovery unter Anwendungs- und Dienstprotokolle öffnen:

Suchen Sie die neueste Warnung, um das Problem zu identifizieren.

Linux-VM-Kernelversion nicht unterstützt

Überprüfen Sie Ihre Kernelversion, indem Sie den Befehl uname -rausführen.

Weitere Informationen zu unterstützten Linux-Kernelversionen finden Sie unter Azure zum Azure-Support Matrix.
Bei einer unterstützten Kernelversion kann das Failover, das dazu führt, dass der virtuelle Computer einen Neustart durchführt, dazu führen, dass die fehlgeschlagene VM auf eine neuere Kernelversion aktualisiert wird, die möglicherweise nicht unterstützt wird. Um ein Update aufgrund eines Failover-VM-Neustarts zu vermeiden, führen Sie den Befehl sudo apt-mark hold linux-image-azure linux-headers-azure aus, damit das Kernelversionsupdate fortgesetzt werden kann.
Überprüfen Sie bei einer nicht unterstützten Kernelversion auf eine ältere Kernelversion, auf die Sie einen Rollback ausführen können, indem Sie den entsprechenden Befehl für Ihre VM ausführen:
- Debian/Ubuntu: dpkg --list | grep linux-image
Die folgende Abbildung zeigt ein Beispiel in einer Ubuntu-VM mit Version 5.4.0-1103-azure, die nicht unterstützt wird. Nachdem der Befehl ausgeführt wurde, können Sie eine unterstützte Version 5.4.0-1077-azure sehen, die bereits auf dem virtuellen Computer installiert ist. Mit diesen Informationen können Sie ein Rollback auf die unterstützte Version ausführen.
Führen Sie mithilfe der folgenden Schritte einen Rollback zu einer unterstützten Kernelversion durch:
1. Erstellen Sie zunächst eine Kopie von "/etc/default/grub" , falls ein Fehler auftritt, sudo cp /etc/default/grub /etc/default/grub.bakz. B. .
2. Ändern Sie dann "/etc/default/grub", um GRUB_DEFAULT auf die vorherige Version festzulegen, die Sie verwenden möchten. Möglicherweise haben Sie etwas ähnliches wie GRUB_DEFAULT="Erweiterte Optionen für Ubuntu Ubuntu>, mit Linux 5.4.0-1077-azure".
3. Wählen Sie "Speichern" aus, um die Datei zu speichern, und wählen Sie dann "Beenden" aus.
4. Führen Sie die Ausführung aus sudo update-grub , um die Grub zu aktualisieren.
5. Starten Sie schließlich den virtuellen Computer neu, und fahren Sie mit dem Rollback auf eine unterstützte Kernelversion fort.
Wenn Sie nicht über eine alte Kernelversion verfügen, auf die Sie ein Rollback ausführen können, warten Sie auf das Mobility Agent-Update, damit Ihr Kernel unterstützt werden kann. Das Update wird automatisch abgeschlossen, sofern es bereit ist, und Sie können die Version im Portal überprüfen, um folgendes zu bestätigen:

Manuelle Erneute Synchronisierung wird noch nicht unterstützt

Nachdem der re-protect-Auftrag abgeschlossen ist, wird die Replikation sequenziert gestartet. Während der Replikation kann es Fälle geben, in denen eine erneute Synchronisierung erforderlich ist, was bedeutet, dass eine neue anfängliche Replikation ausgelöst wird, um alle Änderungen zu synchronisieren.

Es gibt zwei Arten von Resync:

Automatische Erneute Synchronisierung. Erfordert keine Benutzeraktion und wird automatisch ausgeführt. Benutzer können einige Ereignisse sehen, die im Portal angezeigt werden:
Manuelle Erneute Synchronisierung. Erfordert eine Benutzeraktion, um die erneute Synchronisierung manuell auszulösen und in den folgenden Instanzen erforderlich:
- Das speicherkonto, das für den erneuten Schutz ausgewählt wurde, fehlt.
- Der Replikationsdatenträger auf der Anwendung fehlt.
- Der Replikationsschreibvorgang überschreitet die Kapazität des Replikationsdatenträgers auf dem Anwendung.
  
  Tipp
  
  Sie finden auch die manuellen Resync-Gründe im Ereignisblatt, um zu entscheiden, ob eine manuelle Erneute Synchronisierung erforderlich ist.

Bekannte Probleme bei der PowerShell-Automatisierung

Wenn Sie den Wert verlassen $failbackPolicyName und $failbackExtensionName leer oder null sind, kann der erneute Schutz fehlschlagen. Hierzu folgende Beispiele:

Geben Sie immer das und $failbackExtensionName, wie im folgenden Beispiel gezeigt, an$failbackPolicyName:

$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

Mobilitätsdienst Agent-Warnung

Beim Replizieren mehrerer VMs wird möglicherweise die Integrität des geschützten Elements in warnungsfehler in den Site Recovery-Aufträgen geändert.

Diese Fehlermeldung sollte nur eine Warnung sein und ist kein Blockierungsproblem für die tatsächlichen Replikations- oder Failoverprozesse.

Tipp

Sie können den Status der jeweiligen VM überprüfen, um sicherzustellen, dass sie fehlerfrei ist.

Durch löschen der Anwendung VM (Quelle) wird das Löschen des Tresors (Ziel) blockiert.

Um den Azure Site Recovery-Tresor auf dem Ziel zu löschen, müssen Sie zuerst alle geschützten virtuellen Computer entfernen. Wenn Sie zuerst den Anwendung virtuellen Computer löschen, blockiert der Site Recovery Vault das Löschen der geschützten Ressourcen und versucht, den Tresor selbst zu löschen, schlägt ebenfalls fehl. Das Löschen der Ressourcengruppe schlägt ebenfalls fehl, und die einzige Möglichkeit zum Entfernen des Tresors besteht darin, das Azure Stack Hub-Benutzerabonnement zu löschen, in dem der Tresor erstellt wird.

Um dieses Problem zu vermeiden, müssen Sie zuerst den Schutz von allen Elementen im Tresor entfernen, bevor Sie die Anwendung VM löschen. Auf diese Weise kann der Tresor die Ressource sauber up auf der Anwendung (Quellseite) abschließen. Nachdem die geschützten Elemente entfernt wurden, können Sie den Tresor löschen und den Anwendung virtuellen Computer entfernen.

Freigeben über