Ismert problémák – Azure Site Recovery az Azure Stack Hubon

Ez a cikk az Azure Stack Hubon futó Azure Site Recovery ismert problémáit ismerteti. Az azure Stack Hubon futó Azure Site Recovery aktuális ismert problémáiról és korlátairól az alábbi szakaszokban tájékozódhat.

A maximálisan támogatott lemezméret 1022 GB

A virtuális gépek védelmekor az Azure Site Recoverynek további 1 GB adatot kell hozzáadnia egy meglévő lemezhez. Mivel az Azure Stack Hub szigorúan korlátozza a lemez maximális méretét 1023 GB-on, a Site Recovery által védett lemezek maximális méretének legalább 1022-nek kell lennie.

Amikor 1023 Gb-os lemezzel próbál védeni egy virtuális gépet, a következő viselkedés következik be:

• A védelem engedélyezése sikeres, mivel a rendszer csak 1 GB-os maglemezt hoz létre, és használatra kész. Ebben a lépésben nincs hiba.

• A replikáció xx%-ban szinkronizálva van, és egy idő után a replikáció állapota kritikussá válik az AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure hibával. A hiba azért fordul elő, mert a replikáció során a Site Recovery megpróbálja átméretezni a maglemezt 1024 GB-ra, és írni rá. Ez a művelet meghiúsul, mivel az Azure Stack Hub nem támogatja az 1024 GB-os lemezeket.

  

• A lemezhez létrehozott maglemez (a cél-előfizetésben) még mindig 1 GB méretű, és a tevékenységnaplóban néhány írási lemezhiba jelenik meg a "disk.diskSizeGb" paraméter "1024" értéke kívül esik a tartományon. Az "1024" értéknek 1 és 1023 közöttinek kell lennie.

  

A probléma jelenlegi kerülő megoldása egy új (legfeljebb 1022 GB méretű) lemez létrehozása, a forrás virtuális géphez való csatolása, az 1023 GB-os lemez adatainak másolása az újba, majd az 1023 GB-os lemez eltávolítása a forrás virtuális gépről. Ha ez az eljárás befejeződött, és a virtuális gép összes lemeze kisebb vagy egyenlő 1022 GB-tal, engedélyezheti a védelmet az Azure Site Recovery használatával.

Újravédelem: rendelkezésre álló adatlemez-tárolóhelyek a berendezésen

1. Győződjön meg arról, hogy a berendezés virtuális gépe rendelkezik elegendő adatlemez-tárolóhellyel, mivel az újravédelemhez szükséges replikalemezek a berendezéshez vannak csatlakoztatva.

2. Az egyidejűleg védett lemezek kezdeti engedélyezett száma 31. A marketplace-elemből létrehozott berendezés alapértelmezett mérete Standard_DS4_v2, amely legfeljebb 32 adatlemezt támogat, és maga a berendezés egy adatlemezt használ.

3. Ha a védett virtuális gépek összege nagyobb, mint 31, hajtsa végre az alábbi műveletek egyikét:

   • Ossza fel az újravédelmet igénylő virtuális gépeket kisebb csoportokra, hogy az egyidejűleg védett lemezek száma ne haladja meg a berendezés által támogatott adatlemezek maximális számát.
   • Növelje az Azure Site Recovery-berendezés virtuális gépének méretét.

   Feljegyzés

   Nem teszteljük és nem érvényesítjük a berendezés virtuális gépéhez tartozó nagyméretű virtuálisgép-termékváltozatokat.

4. Ha újra szeretne védeni egy virtuális gépet, de nincs elegendő tárolóhely a berendezésen a replikációs lemezek tárolásához, a hibaüzenet belső hiba történt . Ellenőrizheti a berendezésen jelenleg található adatlemezek számát, vagy bejelentkezhet a berendezésbe, megnyithatja a Eseménynapló, és megnyithatja az Azure Site Recovery naplóit az Alkalmazások és szolgáltatások naplói területen:

   

   

   Keresse meg a legújabb figyelmeztetést a probléma azonosításához.

A Linux rendszerű virtuális gép kernelverziója nem támogatott

1. Ellenőrizze a kernel verzióját a parancs futtatásával uname -r.

   

   A linuxos kernelek támogatott verzióiról további információt az Azure-ban Azure-támogatás mátrixban talál.

2. Egy támogatott kernelverzió esetén a feladatátvétel, amely miatt a virtuális gép újraindítást hajt végre, a feladatátvételi virtuális gép frissíthető egy újabb kernelverzióra, amely esetleg nem támogatott. A feladatátvevő virtuális gép újraindítása miatti frissítés elkerülése érdekében futtassa a parancsot sudo apt-mark hold linux-image-azure linux-headers-azure , hogy a kernel verziófrissítése folytatódjon.

3. Nem támogatott kernelverzió esetén ellenőrizze, hogy van-e régebbi kernelverzió, amelyre vissza lehet állítani a virtuális gép megfelelő parancsának futtatásával:

   • Debian/Ubuntu: dpkg --list | grep linux-image

   Az alábbi képen egy 5.4.0-1103-azure-os verziójú Ubuntu virtuális gépen látható példa, amely nem támogatott. A parancs futtatása után megjelenik egy támogatott verzió, az 5.4.0-1077-azure, amely már telepítve van a virtuális gépen. Ezekkel az információkkal visszatérhet a támogatott verzióra.

   

4. Térjen vissza egy támogatott kernelverzióra az alábbi lépésekkel:

   1. Először készítsen másolatot a /etc/default/grub fájlról, ha hiba történt, például sudo cp /etc/default/grub /etc/default/grub.bak.

   2. Ezután módosítsa a /etc/default/grub parancsot, hogy a GRUB_DEFAULT a használni kívánt előző verzióra állítsa. Lehet, hogy a GRUB_DEFAULT="Speciális lehetőségek az Ubuntu>Ubuntu-hoz linuxos 5.4.0-1077-azure".

      

   3. A fájl mentéséhez válassza a Mentés, majd a Kilépés lehetőséget.

   4. Futtassa sudo update-grub a grub frissítését.

   5. Végül indítsa újra a virtuális gépet, és folytassa a visszaállítást egy támogatott kernelverzióra.

5. Ha nem rendelkezik régi kernelverzióval, amelyre visszatérhet, várja meg a mobilitási ügynök frissítését, hogy a kernel támogatott legyen. A frissítés automatikusan befejeződik, ha készen áll, és a portálon ellenőrizheti a verziót, hogy megerősítse:

   

A manuális újraszinkronizálás ismételt védelme még nem támogatott

Az újravédett feladat befejezése után a replikáció egymás után indul el. A replikáció során előfordulhatnak olyan esetek, amelyek újraszinkronizálást igényelnek, ami azt jelenti, hogy egy új kezdeti replikáció aktiválódik az összes módosítás szinkronizálásához.

Az újraszinkronizálásnak két típusa van:

• Automatikus újraszinkronizálás. Nem igényel felhasználói műveletet, és automatikusan megtörténik. A felhasználók láthatnak néhány eseményt a portálon:

  

• Manuális újraszinkronizálás. Az újraszinkronizálás manuális aktiválásához felhasználói művelet szükséges, amely a következő esetekben szükséges:

  • Hiányzik az újravédéshez kiválasztott tárfiók.

  • A berendezés replikációs lemeze hiányzik.

  • A replikáció írása meghaladja a berendezés replikációs lemezének kapacitását.

    Tipp.

    Az események panelen a manuális újraszinkronizálás okait is megtalálhatja, hogy eldönthesse, szükség van-e manuális újraszinkronizálásra.

A PowerShell automatizálásának ismert problémái

• Ha üres $failbackPolicyName vagy $failbackExtensionName null értékű, az ismételt védelem sikertelen lehet. Lásd az alábbi példákat:

  

  

• Mindig adja meg az $failbackPolicyName és $failbackExtensionName, az alábbi példában látható módon:

  $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 szolgáltatás ügynök figyelmeztetése

Több virtuális gép replikálásakor előfordulhat, hogy a Védett elem állapota figyelmeztetési hibára módosul a Site Recovery-feladatokban.

Ez a hibaüzenet csak figyelmeztetés lehet, és nem blokkolja a tényleges replikációs vagy feladatátvételi folyamatokat.

Tipp.

A megfelelő virtuális gép állapotának ellenőrzéséhez ellenőrizze, hogy kifogástalan állapotban van-e.

A berendezés virtuális gépének (forrásának) törlése blokkolja a tároló (cél) törlését

A cél Azure Site Recovery-tárolójának törléséhez először el kell távolítania az összes védett virtuális gépet. Ha először törli a berendezés virtuális gépét, a Site Recovery-tároló blokkolja a védett erőforrások törlését, és magát a tárolót is megpróbálja törölni. Az erőforráscsoport törlése is sikertelen, és a tároló eltávolításának egyetlen módja az, ha törli azt az Azure Stack Hub felhasználói előfizetést, amelyben a tároló létrejön.

A probléma elkerülése érdekében először távolítsa el a védelmet a tároló összes eleméből, mielőtt törölné a berendezés virtuális gépét. Ez lehetővé teszi, hogy a tároló elvégezze az erőforrás-tisztítást a berendezésen (a forrásoldalon). A védett elemek eltávolítása után törölheti a tárolót, és eltávolíthatja a berendezés virtuális gépét.

Következő lépések

• Azure Site Recovery az Azure Stack Hubon
• Azure Site Recovery az Azure Stack Hub kapacitástervezésén