Bilinen sorunlar - Azure Stack Hub'da Azure Site Recovery

Makale
10/30/2024

Bu makalede, Azure Stack Hub'da Azure Site Recovery ile ilgili bilinen sorunlar açıklanmaktadır. Azure Stack Hub'da Azure Site Recovery'de bilinen geçerli sorunlar ve sınırlamalar hakkında ayrıntılar için aşağıdaki bölümleri kullanın.

Desteklenen en büyük disk boyutu 1022 GB'tır

Bir VM'yi koruduğunuzda Azure Site Recovery'nin mevcut diske 1 GB ek veri eklemesi gerekir. Azure Stack Hub'ın disk boyutu üst sınırı 1023 GB olduğundan, Site Recovery tarafından korunan bir diskin maksimum boyutu 1022'ye eşit veya daha az olmalıdır.

1023 Gb disk içeren bir VM'yi korumaya çalıştığınızda aşağıdaki davranış oluşur:

Yalnızca 1 GB'lık bir tohum diski oluşturulduğundan ve kullanıma hazır olduğundan korumayı etkinleştirme başarılı olur. Bu adımda hata yoktur.
Çoğaltma xx% Eşitlendi konumunda engellenir ve bir süre sonra çoğaltma durumu AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure hatasıyla Kritik hale gelir. Site Recovery, çoğaltma sırasında tohum diskini 1024 GB'a yeniden boyutlandırmaya ve diske yazmaya çalıştığından hata oluşur. Azure Stack Hub 1024 GB diskleri desteklemediğinden bu işlem başarısız olur.
Bu disk için oluşturulan çekirdek diskin (hedef abonelikte) boyutu hala 1 GB'tır ve Etkinlik günlüğü, 'disk.diskSizeGb' parametresinin '1024' değeri aralık dışında hata iletisiyle birkaç Yazma Diski hatası gösterir. '1024' değeri '1' ile '1023' (dahil) arasında olmalıdır.

Bu sorunun geçerli geçici çözümü yeni bir disk (1022 GB veya daha az) oluşturmak, bunu kaynak VM'nize eklemek, 1023 GB diskteki verileri yeni diske kopyalamak ve ardından 1023 GB'lık diski kaynak VM'den kaldırmaktır. Bu yordam tamamlandıktan ve VM'nin tüm diskleri 1022 GB'a eşit veya daha küçük olduğunda, Azure Site Recovery'yi kullanarak korumayı etkinleştirebilirsiniz.

Yeniden koruma: alette kullanılabilir veri diski yuvaları

Yeniden koruma amaçlı çoğaltma diskleri alete bağlı olduğundan alet VM'sinde yeterli veri diski yuvası olduğundan emin olun.
Aynı anda yeniden korunan ilk izin verilen disk sayısı 31'dir. Market öğesinden oluşturulan aletin varsayılan boyutu en fazla 32 veri diskini destekleyen Standard_DS4_v2 ve aletin kendisi bir veri diski kullanır.
Korumalı VM'lerin toplamı 31'den büyükse, aşağıdaki eylemlerden birini gerçekleştirin:
- Yeniden koruma gerektiren VM'leri daha küçük gruplara ayırarak aynı anda yeniden korunan disk sayısının aletin desteklediği en fazla veri diski sayısını aşmamasını sağlayın.
- Azure Site Recovery gereci VM'sinin boyutunu artırın.
Not

Alet VM'leri için büyük VM SKU'larını test edip doğrulamayız.
Bir VM'yi yeniden korumaya çalışıyorsanız ancak alette çoğaltma disklerini tutmak için yeterli yuva yoksa, bir iç hata oluştu hata iletisi görüntülenir. Alette bulunan veri disklerinin sayısını denetleyebilirsiniz veya alette oturum açabilir, Olay Görüntüleyicisi gidebilir ve Uygulamalar ve Hizmet Günlükleri altında Azure Site Recovery günlüklerini açabilirsiniz:

Sorunu tanımlamak için en son uyarıyı bulun.

Linux VM çekirdek sürümü desteklenmiyor

komutunu uname -rçalıştırarak çekirdek sürümünüzü denetleyin.

Desteklenen Linux çekirdek sürümleri hakkında daha fazla bilgi için bkz. Azure desteği matris için Azure.
Desteklenen bir çekirdek sürümüyle, VM'nin yeniden başlatma gerçekleştirmesine neden olan yük devretme, yük devredilen VM'nin desteklenmeyen daha yeni bir çekirdek sürümüne güncelleştirilmesine neden olabilir. Yük devretme VM'sinin yeniden başlatılmasından kaynaklanan bir güncelleştirmeyi önlemek için, çekirdek sürümü güncelleştirmesinin devam edebilmesi için komutunu sudo apt-mark hold linux-image-azure linux-headers-azure çalıştırın.
Desteklenmeyen bir çekirdek sürümü için, VM'niz için uygun komutu çalıştırarak geri dönebileceğiniz eski bir çekirdek sürümünü denetleyin:
- Debian/Ubuntu: dpkg --list | grep linux-image
Aşağıdaki görüntüde, desteklenmeyen 5.4.0-1103-azure sürümündeki Ubuntu VM'sindeki bir örnek gösterilmektedir. Komut çalıştırıldıktan sonra, VM'de zaten yüklü olan desteklenen 5.4.0-1077-azure sürümünü görebilirsiniz. Bu bilgilerle desteklenen sürüme geri dönebilirsiniz.
Aşağıdaki adımları kullanarak desteklenen bir çekirdek sürümüne geri dönün:
1. İlk olarak, bir hata olması durumunda /etc/default/grub dosyasının bir kopyasını oluşturun; örneğin, sudo cp /etc/default/grub /etc/default/grub.bak.
2. Ardından ,/etc/default/grub dosyasını değiştirerek GRUB_DEFAULT kullanmak istediğiniz önceki sürüme ayarlayın. GRUB_DEFAULT="Linux 5.4.0-1077-azure ile Ubuntu>Ubuntu için gelişmiş seçenekler"e benzer bir seçeneğiniz olabilir.
3. Dosyayı kaydetmek için Kaydet'i ve ardından Çıkış'ı seçin.
4. Grub'u güncelleştirmek için komutunu çalıştırın sudo update-grub .
5. Son olarak, VM'yi yeniden başlatın ve desteklenen bir çekirdek sürümüne geri alma işlemine devam edin.
Geri dönebileceğiniz eski bir çekirdek sürümünüz yoksa, çekirdeğinizin desteklenmesi için mobility aracısı güncelleştirmesini bekleyin. Güncelleştirme hazırsa otomatik olarak tamamlanır ve portaldaki sürümü denetledikten sonra şunları onaylayabilirsiniz:

El ile yeniden eşitlemeyi yeniden koruma henüz desteklenmiyor

Yeniden koruma işi tamamlandıktan sonra çoğaltma sırayla başlatılır. Çoğaltma sırasında yeniden eşitleme gerektiren durumlar olabilir; bu da tüm değişiklikleri eşitlemek için yeni bir ilk çoğaltma tetiklendiği anlamına gelir.

İki tür yeniden eşitleme vardır:

Otomatik yeniden eşitleme. Kullanıcı eylemi gerektirmez ve otomatik olarak yapılır. Kullanıcılar portalda gösterilen bazı olayları görebilir:
El ile yeniden eşitleme. Yeniden eşitlemeyi el ile tetikleyen kullanıcı eylemi gerektirir ve aşağıdaki örneklerde gereklidir:
- Yeniden koruma için seçilen depolama hesabı eksik.
- Alet üzerindeki çoğaltma diski eksik.
- Çoğaltma yazma işlemi, alet üzerindeki çoğaltma diskinin kapasitesini aşıyor.
  
  İpucu
  
  Ayrıca, el ile yeniden eşitleme gerekip gerekmediğine karar vermenize yardımcı olması için olaylar dikey penceresinde el ile yeniden eşitleme nedenlerini de bulabilirsiniz.

PowerShell otomasyonundaki bilinen sorunlar

Ve boş veya null bırakırsanız $failbackPolicyName $failbackExtensionName , yeniden koruma başarısız olabilir. Aşağıdaki örneklere bakın:

Aşağıdaki örnekte gösterildiği gibi her zaman ve $failbackExtensionNamedeğerini belirtin$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

Ulaşım hizmeti aracısı uyarısı

Birden çok VM'yi çoğaltırken, Site Recovery işlerinde Korumalı öğe durumunun Uyarı hatası olarak değiştiğini görebilirsiniz.

Bu hata iletisi yalnızca bir uyarı olmalıdır ve gerçek çoğaltma veya yük devretme işlemleri için engelleyici bir sorun değildir.

İpucu

İyi durumda olduğundan emin olmak için ilgili VM'nin durumunu de kontrol edebilirsiniz.

Alet VM'sini silme (kaynak) kasanın silinmesini engeller (hedef)

Hedefte Azure Site Recovery kasasını silmek için önce tüm korumalı VM'leri kaldırmanız gerekir. Önce alet VM'sini silerseniz, Site Recovery kasası korumalı kaynakların silinmesini engeller ve kasayı silmeye çalışırken de başarısız olur. Kaynak grubunu silme işlemi de başarısız olur ve kasayı kaldırmanın tek yolu, kasanın oluşturulduğu Azure Stack Hub kullanıcı aboneliğini silmektir.

Bu sorunu önlemek için alet VM'sini silmeden önce kasadaki tüm öğelerden korumayı kaldırdığınızdan emin olun. Bu, kasanın alet üzerindeki kaynak temizleme işlemini (kaynak tarafı) tamamlayabilmesini sağlar. Korumalı öğeler kaldırıldıktan sonra kasayı silebilir ve alet VM'sini kaldırabilirsiniz.

Aracılığıyla paylaş