Niezawodność w usłudze Azure Storage Mover

W tym artykule opisano obsługę niezawodności w usłudze Azure Storage Mover i opisano zarówno odporność wewnątrz regionów, jak i stref dostępności oraz odzyskiwanie po awarii między regionami i ciągłość działalności biznesowej. Aby uzyskać bardziej szczegółowe omówienie zasad niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Obsługa strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Usługa Azure Storage Mover obsługuje model wdrożeniowy ze strefową nadmiarowością.

Podczas wdrażania zasobu usługi Azure Storage Mover należy wybrać określony region , w którym są przechowywane metadane wystąpienia zasobu.

Jeśli region obsługuje strefy dostępności, metadane wystąpienia są automatycznie replikowane w wielu strefach dostępności w tym regionie.

Wymagania wstępne

• Aby wdrożyć przy użyciu obsługi stref dostępności, należy wybrać region obsługujący strefy dostępności. Aby zobaczyć, które regiony obsługują strefy dostępności, zobacz listę obsługiwanych regionów.

• (Opcjonalnie) Jeśli docelowe konto magazynu nie obsługuje stref dostępności i chcesz przeprowadzić migrację konta do obsługi az, zobacz Zmienianie sposobu replikacji konta magazynu.

Doświadczenie zmniejszania strefy

Podczas awarii całej strefy nie jest wymagana żadna akcja podczas odzyskiwania strefy. Usługa Azure Storage Mover została zaprojektowana tak, aby automatycznie samodzielnie naprawiać i ponownie zrównoważyć swoje działanie w zdrowej strefie.

Każde docelowe konto magazynowe migracji może wymagać własnych kroków odzyskiwania. To wymaganie zależy od opcji nadmiarowości wybranych dla każdego konta magazynu. Zapoznaj się z przewodnikiem odzyskiwania po awarii konta magazynu , aby określić, czy konieczne jest wykonanie większej liczby kroków.

Jeśli magazyn lokalny został wybrany zamiast opcji nadmiarowości, może być konieczne utworzenie nowego konta magazynu do użycia w migracjach podczas awarii.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania danych po awarii, który jest dostosowany do Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Po zarejestrowaniu agenta usługi Storage Mover łączy się z regionem, w którym zarejestrowano zasób usługi Storage Mover. Jeśli region platformy Azure, w którym działa agent, napotka awarię, sam agent nie zostanie dotknięty, ale operacje zarządzania, które opierają się na platformie Azure, mogą nie zostać ukończone. Ponadto wszelkie aktywne migracje danych do kont magazynu znajdujących się w danym regionie mogą zakończyć się niepowodzeniem.

Usługa Storage Mover obsługuje dwie formy odzyskiwania po awarii:

• Zainicjowane przez platformę Azure odzyskiwanie po awarii
• Klient zainicjował odzyskiwanie po awarii

Zainicjowane przez platformę Azure odzyskiwanie po awarii

Zainicjowane na platformie Azure odzyskiwanie po awarii ma zastosowanie tylko do tych regionów, które mają pary regionów. W przypadku korzystania z replikacji między regionami metadane wystąpień są replikowane do każdego regionu, ale nigdy nie mogą opuszczać obszaru geograficznego.

Usługa Azure Storage Mover używa usługi Cosmos DB do przechowywania metadanych wystąpienia. Utrata danych może wystąpić tylko w przypadku nieodwracalnej awarii w usłudze Azure Cosmos DB. Aby uzyskać więcej informacji, zobacz Awarie regionów. Odzyskiwanie zainicjowane przez platformę Azure jest aktywne-pasywne, a pełne odzyskiwanie regionu może potrwać do 24 godzin.

Klient zainicjował odzyskiwanie po awarii

Odzyskiwanie po awarii zainicjowane przez klienta nie jest ograniczone do sparowanych regionów.

Przed wystąpieniem awarii regionalnej:

• Wdróż Storage Mover z nadmiarowością strefową, tworząc zasoby Storage Mover w regionie obsługującym strefy dostępności.

• Okresowo — zgodnie z harmonogramem lub po wprowadzeniu istotnych zmian — utwórz migawkę zasobów usługi Storage Mover. Przechowywanie migawek przy użyciu systemu kontroli wersji jest dobrym sposobem przechowywania i śledzenia historii migawek. Użyjesz ostatniej dobrej migawki w przypadku katastrofy, w sytuacji, gdy trzeba odzyskać zasoby w nowym regionie.

Podczas awarii regionalnej:

Możesz wykonać jedną z dwóch czynności:

• Wybierz opcję oczekiwania na odzyskanie regionu przez platformę Azure.
• Zminimalizuj przestój, ponownie wdrażając zasoby w innym regionie. Ponieważ awaria może wpływać na dostęp do zasobów, warto użyć ostatniej dobrej migawki swoich zasobów.

Wdrażanie zasobów w innym regionie

Zapoznaj się z dokumentacją dotyczącą eksportowania szablonów , aby uzyskać dalsze instrukcje dotyczące eksportowania zasobów jako szablonu usługi Azure Resource Manager (ARM).

Jeśli Storage Mover i powiązane zasoby znajdują się w kontenerze bez dodatkowych zasobów, należy wykonać eksport grupy zasobów aby przechwycić bieżący stan. Jeśli jednak grupa zasobów zawiera niepowiązane zasoby, może być konieczne usunięcie lub wykluczenie zasobów z szablonu.

Istniejących agentów nie można ponownie wdrożyć w innym regionie. Jeśli region, w którym zostały pierwotnie skonfigurowane, wystąpi awaria, może nie być możliwe całkowite wyrejestrowanie i ponowne zarejestrowanie agenta. W tym dokumencie przyjęto założenie, że nowi agenci są zarejestrowani w nowym regionie.

Aby użyć wyeksportowanego szablonu na potrzeby odzyskiwania po awarii, wymagane są kilka zmian w szablonie.

• Najpierw usuń wszystkie zasoby Microsoft.StorageMover/agents i Microsoft.HybridCompute/machines z szablonu. Pamiętaj, aby usunąć wszystkie odwołania zależności do tych zasobów.
• Następnie usuń agentResourceId właściwość ze wszystkich definicji zadań. Po wdrożeniu należy przypisać je do nowego agenta.
• Po usunięciu wszystkich odwołań do zasobów agenta i maszyny obliczeniowej hybrydowej zaktualizuj właściwość lokalizacji zasobu Mover magazynu najwyższego poziomu. Zastąp nazwę aktualnie wdrożonego regionu nazwą nowego regionu.
• Na koniec zdecyduj, czy chcesz zachować identyfikator zasobu istniejącego konta magazynowego. Jeśli zajdzie potrzeba, zastąp je innym kontem magazynowym.

Po wykonaniu poprzednich kroków i sprawdzeniu, czy parametry szablonu są poprawne, szablon jest gotowy do wdrożenia w nowym regionie. Szablon należy wdrożyć w nowej grupie zasobów, która ma ten sam region domyślny co właściwość location w szablonie.

Rejestrowanie nowego agenta

Wykonaj kroki opisane w artykule dotyczącym wdrażania agenta usługi Azure Storage Mover , aby zarejestrować nowego agenta w nowym zasobie usługi Storage Mover.

Przypisywanie agenta do definicji zadań

Po zarejestrowaniu nowego agenta i raportach w trybie online użyj witryny Azure Portal lub programu PowerShell, aby skojarzyć istniejące definicje zadań z nowym agentem. Poniższy przykład programu PowerShell jest udostępniany dla wygody.

Zobacz definicję nowego zadania migracji, aby uzyskać wskazówki, jak uzyskać dostęp do definicji zadań projektu.

## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Udzielanie agentowi dostępu do docelowego kontenera magazynu

Aby pomyślnie wykonać zadanie migracji, musisz przypisać rolę współautora danych do tożsamości zarządzanej. Przypisz tożsamość zarządzaną systemu zasobów obliczeniowych hybrydowego do docelowego zasobu konta magazynu. Artykuł Przypisywanie tożsamości zarządzanej do zasobu zawiera wskazówki dotyczące udzielania dostępu do zasobu docelowego.

Teraz możesz rozpocząć zadania migracji przy użyciu nowo wdrożonych zasobów usługi Storage Mover.

Dalsze kroki

• Niezawodność na platformie Azure
• Odzyskiwanie po awarii konta magazynu