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 platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.

Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.

Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.

Usługa Azure Storage Mover obsługuje model wdrażania strefowo nadmiarowego.

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.

Ważne

Metadane wystąpienia usługi Azure Storage Mover obejmują projekty, punkty końcowe, agenty, definicje zadań i historię uruchamiania zadania, ale nie zawierają rzeczywistych danych do zmigrowania. Konta usługi Azure Storage używane jako cele migracji mają własną obsługę niezawodności.

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 sprawdzić, 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 Migrowanie kont usługi Azure Storage do obsługi stref dostępności.

Środowisko strefowe w dół

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 leczyć i ponownie zrównoważyć korzystanie ze strefy w dobrej kondycji.

Każde docelowe konto magazynu 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 dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania 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 agenta napotka awarię, sam agent nie ma wpływu, ale operacje zarządzania, które korzystają z platformy Azure, mogą nie być w stanie ukończyć. 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

Ważne

Odzyskiwanie po awarii lokalnych źródeł danych jest obowiązkiem klienta.

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 zezwalają na pozostawienie lokalizacji geograficznej.

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óż strefowo nadmiarowy magazyn Mover, tworząc zasoby usługi 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 awarii, w której 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ż dostęp do zasobów może mieć wpływ na awarię, warto użyć ostatniej dobrej migawki zasobów.

Napiwek

Jedna z tych strategii nadal może wymagać podjęcia dalszych kroków przed awarią, dlatego należy odpowiednio przejrzeć i zaplanować.

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 magazyn 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 Microsoft.StorageMover/agents zasoby 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 określ, czy zachować identyfikator zasobu istniejącego konta magazynu. W razie potrzeby zastąp go innym kontem magazynu.

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 definiowanie nowego zadania migracji, aby uzyskać wskazówki dotyczące uzyskiwania dostępu do definicji zadań dla 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.

Następne kroki

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