Bekende problemen - Azure Site Recovery in Azure Stack Hub (preview)

In dit artikel worden bekende problemen beschreven voor Azure Site Recovery in Azure Stack Hub. Gebruik de volgende secties voor meer informatie over de huidige bekende problemen en beperkingen in Azure Site Recovery op Azure Stack Hub.

Herbeveiliging: beschikbare gegevensschijfsleuven op apparaat

  1. Zorg ervoor dat de vm van het apparaat voldoende gegevensschijfsleuven heeft, omdat de replicaschijven voor opnieuw beveiligen aan het apparaat zijn gekoppeld.

  2. Het initiële toegestane aantal schijven dat tegelijkertijd opnieuw wordt beveiligd, is 31. De standaardgrootte van het apparaat dat is gemaakt op basis van het Marketplace-item is Standard_DS4_v2, dat ondersteuning biedt voor maximaal 32 gegevensschijven, en het apparaat zelf maakt gebruik van één gegevensschijf.

  3. Als de som van de beveiligde VM's groter is dan 31, voert u een van de volgende acties uit:

    • Splits de VM's die opnieuw moeten worden beveiligd in kleinere groepen om ervoor te zorgen dat het aantal schijven dat tegelijkertijd opnieuw wordt beveiligd, niet groter is dan het maximum aantal gegevensschijven dat door het apparaat wordt ondersteund.
    • Vergroot de grootte van de VM van het Azure Site Recovery-apparaat.

    Notitie

    We testen en valideren geen grote VM-SKU's voor de apparaat-VM.

  4. Als u een virtuele machine opnieuw probeert te beveiligen, maar er onvoldoende sleuven op het apparaat zijn om de replicatieschijven op te kunnen plaatsen, wordt het foutbericht Er is een interne fout opgetreden weergegeven. U kunt het aantal gegevensschijven controleren dat zich momenteel op het apparaat bevindt of u aanmelden bij het apparaat, naar Logboeken gaan en logboeken openen voor Azure Site Recovery onder Logboeken toepassingen en services:

    Voorbeeldschermopname van Logboeken voor Azure Site Recovery.

    Voorbeeldschermopname van Azure Site Recovery-logboeken.

    Zoek de meest recente waarschuwing om het probleem te identificeren.

Linux-VM-kernelversie wordt niet ondersteund

  1. Controleer uw kernelversie door de opdracht uname -ruit te voeren.

    Voorbeeldschermopname van linux-kernelversie.

    Zie Azure-naar-ondersteuning voor Azure matrix voor meer informatie over ondersteunde Linux-kernelversies.

  2. Met een ondersteunde kernelversie kan de failover, waardoor de VM opnieuw wordt opgestart, ertoe leiden dat de failover van de VM wordt bijgewerkt naar een nieuwere kernelversie die mogelijk niet wordt ondersteund. Als u een update wilt voorkomen als gevolg van een failover-VM opnieuw opstarten, voert u de opdracht sudo apt-mark hold linux-image-azure linux-headers-azure uit zodat de kernelversie kan worden bijgewerkt.

  3. Voor een niet-ondersteunde kernelversie controleert u op een oudere kernelversie waarnaar u kunt terugdraaien door de juiste opdracht uit te voeren voor uw VM:

    • Debian/Ubuntu: dpkg --list | grep linux-image
    • RedHat/CentOS/RHEL: rpm -qa kernel

    In de volgende afbeelding ziet u een voorbeeld in een Ubuntu-VM met versie 5.4.0-1103-azure, die niet wordt ondersteund. Nadat de opdracht is uitgevoerd, ziet u een ondersteunde versie, 5.4.0-1077-azure, die al op de VM is geïnstalleerd. Met deze informatie kunt u teruggaan naar de ondersteunde versie.

    Voorbeeldschermopname van een ubuntu-VM-kernelversiecontrole.

  4. Ga als volgt te werk om terug te keren naar een ondersteunde kernelversie:

    1. Maak eerst een kopie van /etc/default/grub voor het geval er een fout optreedt; bijvoorbeeld sudo cp /etc/default/grub /etc/default/grub.bak.

    2. Wijzig vervolgens /etc/default/grub om GRUB_DEFAULT in te stellen op de vorige versie die u wilt gebruiken. Mogelijk hebt u iets vergelijkbaars met GRUB_DEFAULT="Geavanceerde opties voor Ubuntu>Ubuntu, met Linux 5.4.0-1077-azure".

      Voorbeeldschermopname van het terugdraaien van de kernelversie van een Ubuntu-VM.

    3. Selecteer Opslaan om het bestand op te slaan en selecteer afsluiten.

    4. Voer uit sudo update-grub om de grub bij te werken.

    5. Ten slotte start u de VM opnieuw op en gaat u verder met het terugdraaien naar een ondersteunde kernelversie.

  5. Als u geen oude kernelversie hebt waarnaar u kunt terugdraaien, wacht u op de update van de Mobility-agent, zodat uw kernel kan worden ondersteund. De update wordt automatisch voltooid, als deze gereed is, en u kunt de versie in de portal controleren om het volgende te bevestigen:

    Voorbeeldschermopname van de updatecontrole van de Mobility-agent.

Handmatig opnieuw synchroniseren opnieuw beveiligen wordt nog niet ondersteund

Nadat de taak voor opnieuw beveiligen is voltooid, wordt de replicatie opeenvolgend gestart. Tijdens de replicatie kunnen er gevallen zijn waarin een hersynchronisatie vereist is, wat betekent dat een nieuwe initiële replicatie wordt geactiveerd om alle wijzigingen te synchroniseren.

Er zijn twee soorten hersynchronisatie:

  • Automatisch opnieuw synchroniseren. Vereist geen actie van de gebruiker en wordt automatisch uitgevoerd. Gebruikers kunnen enkele gebeurtenissen zien die worden weergegeven in de portal:

    Voorbeeldschermopname van Automatisch opnieuw synchroniseren in de gebruikersportal.

  • Handmatig opnieuw synchroniseren. Vereist actie van de gebruiker om het opnieuw synchroniseren handmatig te activeren en is nodig in de volgende gevallen:

    • Het opslagaccount dat is gekozen voor opnieuw beveiligen, ontbreekt.

    • De replicatieschijf op het apparaat ontbreekt.

    • De replicatie-schrijfbewerking overschrijdt de capaciteit van de replicatieschijf op het apparaat.

      Tip

      U kunt ook de redenen voor handmatig opnieuw synchroniseren vinden op de gebeurtenisblade om u te helpen bepalen of handmatig opnieuw synchroniseren vereist is.

Bekende problemen in PowerShell-automatisering

  • Als u leeg of null verlaat $failbackPolicyName$failbackExtensionName , kan het opnieuw beveiligen mislukken. Zie de volgende voorbeelden:

    Voorbeeldschermopname van een fout bij het uitvoeren van de bewerking van een VM.

    Voorbeeldschermopname van een tweede bewerkingsfout op een andere VM.

  • Geef altijd de $failbackPolicyName en $failbackExtensionNameop, zoals wordt weergegeven in het volgende voorbeeld:

    $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 
    

waarschuwing voor Mobility-service agent

Wanneer u meerdere VM's repliceert, ziet u mogelijk dat de status van beveiligd item is gewijzigd in Waarschuwingsfout in de Site Recovery-taken.

Voorbeeldschermopname van de waarschuwing voor het wijzigen van de status van beveiligd item.

Dit foutbericht mag alleen een waarschuwing zijn en is geen blokkerend probleem voor de werkelijke replicatie- of failoverprocessen.

Tip

U kunt de status van de betreffende VM controleren om er zeker van te zijn dat deze in orde is.

Volgende stappen