Bekende problemen - Azure Site Recovery in Azure Stack Hub

Artikel
06/19/2024

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 in Azure Stack Hub.

De maximale schijfgrootte die wordt ondersteund, is 1022 GB

Wanneer u een virtuele machine beveiligt, moet Azure Site Recovery extra 1 GB aan gegevens toevoegen aan een bestaande schijf. Omdat 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 door Site Recovery wordt beveiligd, gelijk zijn aan of kleiner dan 1022.

Wanneer u een VIRTUELE machine probeert te beveiligen met een schijf van 1023 Gb, gebeurt het volgende:

Beveiliging inschakelen slaagt als 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 AzStackToAzStackAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. De fout treedt op omdat Site Recovery tijdens de replicatie probeert de grootte van de seed-schijf te wijzigen in 1024 GB en ernaar te schrijven. Deze bewerking mislukt, omdat Azure Stack Hub geen ondersteuning biedt voor schijven van 1024 GB.
De seed-schijf die voor deze schijf is gemaakt (in het doelabonnement) heeft nog steeds een grootte van 1 GB en het activiteitenlogboek toont enkele schrijfschijffouten met het foutbericht De waarde '1024' van de parameter disk.diskSizeGb valt buiten het bereik. De waarde 1024 moet tussen 1 en 1023 liggen.

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

Opnieuw beveiligen: beschikbare gegevensschijfsleuven op het apparaat

Zorg ervoor dat de vm van het apparaat voldoende gegevensschijfsleuven heeft, omdat de replicaschijven voor opnieuw beveiligen aan het apparaat zijn gekoppeld.
Het eerste 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, die maximaal 32 gegevensschijven ondersteunt en het apparaat zelf één gegevensschijf gebruikt.
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 het apparaat ondersteunt.
- Vergroot de grootte van de VM van het Azure Site Recovery-apparaat.
Notitie

We testen en valideren geen grote VM-SKU's voor de vm van het apparaat.
Als u een virtuele machine opnieuw probeert te beveiligen, maar er onvoldoende sleuven zijn op het apparaat om de replicatieschijven op te houden, wordt het foutbericht weergegeven dat er een interne fout is opgetreden . U kunt het aantal gegevensschijven controleren dat zich momenteel op het apparaat bevindt, of u aanmelden bij het apparaat, naar Logboeken gaan en logboeken voor Azure Site Recovery openen onder Logboeken toepassingen en services:

Zoek de meest recente waarschuwing om het probleem te identificeren.

Linux VM-kernelversie wordt niet ondersteund

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

Zie Azure om ondersteuning voor Azure matrix te ondersteuning voor Azure voor meer informatie over ondersteunde Linux-kernelversies.
Met een ondersteunde kernelversie kan de failover, waardoor de VIRTUELE machine 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 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-update kan worden voortgezet.
Voor een niet-ondersteunde kernelversie controleert u op een oudere kernelversie waarnaar u kunt terugdraaien door de juiste opdracht voor uw VM uit te voeren:
- Debian/Ubuntu: dpkg --list | grep linux-image
In de volgende afbeelding ziet u een voorbeeld in een Ubuntu-VM op versie 5.4.0-1103-azure, dat niet wordt ondersteund. Nadat de opdracht is uitgevoerd, ziet u een ondersteunde versie, 5.4.0-1077-azure, die al op de virtuele machine is geïnstalleerd. Met deze informatie kunt u teruggaan naar de ondersteunde versie.
Ga terug naar een ondersteunde kernelversie met behulp van deze stappen:
1. Maak eerst een kopie van /etc/default/grub voor het geval er een fout is, sudo cp /etc/default/grub /etc/default/grub.bakbijvoorbeeld.
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".
3. Selecteer Opslaan om het bestand op te slaan en selecteer vervolgens Afsluiten.
4. Voer sudo update-grub uit om de grub bij te werken.
5. Ten slotte start u de VIRTUELE machine opnieuw op en gaat u verder met het terugdraaien naar een ondersteunde kernelversie.
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 te bevestigen:

Handmatige hersynchronisatie opnieuw beveiligen wordt nog niet ondersteund

Nadat de taak voor opnieuw beveiligen is voltooid, wordt de replicatie op volgorde 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:
Handmatig opnieuw synchroniseren. Gebruikersactie vereist om de hersynchronisatie handmatig te activeren en is nodig in de volgende exemplaren:
- 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 handmatige hersynchronisatieredenen vinden op de blade gebeurtenissen om u te helpen bepalen of een handmatige hersynchronisatie vereist is.

Bekende problemen in PowerShell-automatisering

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

Geef altijd het $failbackPolicyName en $failbackExtensionName, 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 het beveiligde item is gewijzigd in de waarschuwingsfout in de Site Recovery-taken.

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

Tip

U kunt de status van de betreffende VIRTUELE machine controleren om ervoor te zorgen dat deze in orde is.

Als u de VM (bron) van het apparaat 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 het verwijderen van de beveiligde resources en mislukt het verwijderen van de kluis zelf. Het verwijderen van de resourcegroep mislukt ook en de enige manier om de kluis te verwijderen, is door het Azure Stack Hub-gebruikersabonnement te verwijderen waarin de kluis wordt gemaakt.

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

Delen via