Share via


Bekende problemen - Azure Site Recovery in Azure Stack Hub

Waarschuwing

In dit artikel wordt verwezen naar CentOS, een Linux-distributie die de EOL-status (End Of Life) nadert. Overweeg uw gebruik en plan dienovereenkomstig. Zie de richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

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.

Maximale ondersteunde schijfgrootte is 1022 GB

Wanneer u een vm beveiligt, moet Azure Site Recovery 1 GB extra gegevens toevoegen aan een bestaande schijf. Aangezien Azure Stack Hub een vaste beperking heeft voor de maximale grootte van een schijf van 1023 GB, moet de maximale grootte van een schijf die wordt beveiligd door Site Recovery gelijk zijn aan of kleiner zijn dan 1022.

Wanneer u een VM met een schijf van 1023 Gb probeert te beveiligen, treedt het volgende gedrag op:

  • Beveiliging inschakelen slaagt als er een seed-schijf van slechts 1 GB wordt gemaakt en klaar is voor gebruik. Er is geen fout opgetreden bij deze stap.

  • Replicatie wordt geblokkeerd bij xx% Gesynchroniseerd en na een tijdje wordt de replicatiestatus Kritiek met de fout AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. De fout treedt op omdat tijdens de replicatie Site Recovery probeert de grootte van de seed-schijf te wijzigen naar 1024 GB en ernaartoe schrijft. Deze bewerking mislukt, omdat Azure Stack Hub geen ondersteuning biedt voor 1024 GB-schijven.

    Schermopname van Azure Portal met maximale schijffout.

  • De seed-schijf die voor deze schijf is gemaakt (in het doelabonnement) is nog steeds 1 GB groot en in het activiteitenlogboek worden enkele schrijfschijffouten weergegeven met het foutbericht De waarde '1024' van parameter 'disk.diskSizeGb' valt buiten het bereik. De waarde '1024' moet liggen tussen '1' en '1023'.

    Schermopname van Azure Portal met schrijffouten.

De huidige tijdelijke oplossing voor dit probleem is om een nieuwe schijf te maken (van 1022 GB of minder), deze te koppelen aan uw bron-VM, de gegevens van de schijf van 1023 GB naar de nieuwe schijf te kopiëren en vervolgens de schijf van 1023 GB van de bron-VM te verwijderen. Zodra deze procedure is voltooid en de VM alle schijven kleiner of gelijk aan 1022 GB heeft, kunt u de beveiliging inschakelen met behulp van Azure Site Recovery.

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 maximaal 32 gegevensschijven ondersteunt. Het apparaat zelf gebruikt éé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 is 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 vm 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 Logboeken van Azure Site Recovery.

    Zoek de meest recente waarschuwing om het probleem te identificeren.

Kernelversie van Linux-VM 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 vm met failover wordt bijgewerkt naar een nieuwere kernelversie die mogelijk niet wordt ondersteund. Als u een update wilt voorkomen vanwege 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 op 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. Gebruik deze stappen 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 vervolgens Afsluiten.

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

    5. Start ten slotte de VM opnieuw op en ga 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 die een hersynchronisatie vereisen, wat betekent dat een nieuwe initiële replicatie wordt geactiveerd om alle wijzigingen te synchroniseren.

Er zijn twee typen hersynchronisatie:

  • Automatisch opnieuw synchroniseren. Vereist geen gebruikersactie 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. Gebruikersactie vereist om de hersynchronisatie handmatig te activeren en is nodig in de volgende gevallen:

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

    • De replicatieschijf op het apparaat ontbreekt.

    • De replicatieschrijfbewerking 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 is vereist.

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 door 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 
    

Mobility-service agentwaarschuwing

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 beveiligde items.

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 te controleren of deze in orde is.

Als u de apparaat-VM (bron) verwijdert, wordt het verwijderen van de kluis (doel) geblokkeerd

Als u de Azure Site Recovery-kluis op het doel wilt verwijderen, moet u eerst alle beveiligde VM's verwijderen. Als u eerst de vm van het apparaat verwijdert, blokkeert de Site Recovery kluis de verwijdering van de beveiligde resources en mislukt het verwijderen van de kluis zelf ook. Het verwijderen van de resourcegroep mislukt ook. De enige manier om de kluis te verwijderen is door het Azure Stack Hub-gebruikersabonnement te verwijderen waarin de kluis is gemaakt.

U kunt dit probleem voorkomen door eerst de beveiliging van alle items in de kluis te verwijderen voordat u de vm van het apparaat verwijdert. Hierdoor kan de kluis het opschonen van resources op het apparaat (bronzijde) voltooien. Zodra de beveiligde items zijn verwijderd, kunt u de kluis en de vm van het apparaat verwijderen.

Volgende stappen