Przechodzenie w tryb failover na potrzeby ciągłości działania i odzyskiwania po awarii
Aby zmaksymalizować czas pracy, zaplanuj ciągłość działania i przygotuj się do odzyskiwania po awarii za pomocą usługi Azure Machine Learning.
Firma Microsoft stara się zapewnić, że usługi platformy Azure są zawsze dostępne. Mogą jednak wystąpić nieplanowane awarie usług. Zalecamy utworzenie planu odzyskiwania po awarii na potrzeby obsługi awarii usług regionalnych. W tym artykule omówiono sposób wykonywania następujących zadań:
- Planowanie wdrożenia obejmującego wiele regionów usługi Azure Machine Learning i skojarzonych zasobów.
- Maksymalizuj szanse na odzyskanie dzienników, notesów, obrazów platformy Docker i innych metadanych.
- Projektowanie pod kątem wysokiej dostępności rozwiązania.
- Zainicjuj przejście w tryb failover do innego regionu.
Ważne
Usługa Azure Machine Learning nie zapewnia automatycznego trybu failover ani odzyskiwania po awarii. Tworzenie kopii zapasowej i przywracanie metadanych obszaru roboczego, takich jak historia uruchamiania, jest niedostępne.
W przypadku przypadkowego usunięcia obszaru roboczego lub odpowiednich składników ten artykuł zawiera również obecnie obsługiwane opcje odzyskiwania.
Omówienie usług platformy Azure dla usługi Azure Machine Learning
Usługa Azure Machine Learning zależy od wielu usług platformy Azure. Niektóre z tych usług są aprowizowania w ramach subskrypcji. Odpowiadasz za konfigurację tych usług o wysokiej dostępności. Inne usługi są tworzone w ramach subskrypcji firmy Microsoft i są zarządzane przez firmę Microsoft.
Usługi platformy Azure obejmują:
Infrastruktura usługi Azure Machine Learning: środowisko zarządzane przez firmę Microsoft dla obszaru roboczego usługi Azure Machine Learning.
Skojarzone zasoby: zasoby aprowidowane w ramach subskrypcji podczas tworzenia obszaru roboczego usługi Azure Machine Learning. Te zasoby obejmują usługę Azure Storage, usługę Azure Key Vault, usługę Azure Container Registry i usługę Application Insights.
- Magazyn domyślny zawiera dane, takie jak model, dane dziennika trenowania i odwołania do zasobów danych.
- Usługa Key Vault ma poświadczenia dla usług Azure Storage, Container Registry i magazynów danych.
- Usługa Container Registry ma obraz platformy Docker do trenowania i wnioskowania środowisk.
- Usługa Application Insights służy do monitorowania usługi Azure Machine Learning.
Zasoby obliczeniowe: zasoby tworzone po wdrożeniu obszaru roboczego. Możesz na przykład utworzyć wystąpienie obliczeniowe lub klaster obliczeniowy w celu wytrenowania modelu uczenia maszynowego.
- Wystąpienie obliczeniowe i klaster obliczeniowy: środowiska programistyczne modelu zarządzanego przez firmę Microsoft.
- Inne zasoby: zasoby obliczeniowe firmy Microsoft, które można dołączyć do usługi Azure Machine Learning, takie jak Azure Kubernetes Service (AKS), Azure Databricks, Azure Container Instances i Azure HDInsight. Odpowiadasz za konfigurowanie ustawień wysokiej dostępności dla tych zasobów.
Inne magazyny danych: usługa Azure Machine Learning może zainstalować inne magazyny danych, takie jak Azure Storage i Azure Data Lake Storage na potrzeby danych szkoleniowych. Te magazyny danych są aprowizowane w ramach subskrypcji. Odpowiadasz za konfigurowanie ustawień wysokiej dostępności. Aby wyświetlić inne opcje magazynu danych, zobacz Tworzenie magazynów danych.
W poniższej tabeli przedstawiono usługi platformy Azure zarządzane przez firmę Microsoft i zarządzane przez Ciebie. Wskazuje również usługi, które są domyślnie wysoce dostępne.
Usługa | Zarządzane przez | Wysoka dostępność domyślnie |
---|---|---|
Infrastruktura usługi Azure Machine Learning | Microsoft | |
Skojarzone zasoby | ||
Azure Storage | Ty | |
Key Vault | Ty | ✓ |
Container Registry | Ty | |
Szczegółowe dane dotyczące aplikacji | Ty | NA |
Zasoby obliczeniowe | ||
Wystąpienie obliczeniowe | Microsoft | |
Klaster obliczeniowy | Microsoft | |
Inne zasoby obliczeniowe, takie jak AKS, Azure Databricks, Container Instances, HDInsight |
Ty | |
Inne magazyny danych, takie jak Azure Storage, SQL Database, Azure Database for PostgreSQL, Azure Database for MySQL, System plików usługi Azure Databricks |
Ty |
W pozostałej części tego artykułu opisano akcje, które należy wykonać, aby każda z tych usług były wysoce dostępne.
Planowanie wdrożenia w wielu regionach
Wdrożenie obejmujące wiele regionów opiera się na tworzeniu usługi Azure Machine Learning i innych zasobów (infrastruktury) w dwóch regionach świadczenia usługi Azure. Jeśli wystąpi awaria regionalna, możesz przełączyć się do innego regionu. Podczas planowania miejsca wdrażania zasobów należy wziąć pod uwagę następujące kwestie:
Dostępność regionalna: jeśli to możliwe, użyj regionu w tym samym obszarze geograficznym, niekoniecznie takiego, który jest najbliżej. Aby sprawdzić dostępność regionalną usługi Azure Machine Learning, zobacz Produkty platformy Azure według regionów.
Sparowane regiony platformy Azure: sparowane regiony koordynują aktualizacje platformy i ustalają priorytety działań związanych z odzyskiwaniem w razie potrzeby. Jednak nie wszystkie regiony obsługują sparowane regiony. Aby uzyskać więcej informacji, zobacz Regiony sparowane platformy Azure.
Dostępność usługi: zdecyduj, czy zasoby używane przez rozwiązanie powinny być gorące/gorące, gorące/ciepłe, czy gorące/zimne.
- Gorąca/gorąca: Oba regiony są aktywne w tym samym czasie, z jednym regionem gotowym do natychmiastowego rozpoczęcia korzystania.
- Gorąca/ciepła: Aktywny region podstawowy, region pomocniczy ma krytyczne zasoby (na przykład wdrożone modele) gotowe do uruchomienia. Zasoby niekrytyczne muszą być wdrażane ręcznie w regionie pomocniczym.
- Gorąca/zimna: Aktywny region podstawowy, region pomocniczy ma wdrożone usługi Azure Machine Learning i inne zasoby wraz z wymaganymi danymi. Zasoby, takie jak modele, wdrożenia modelu lub potoki, muszą być wdrażane ręcznie.
Napiwek
W zależności od wymagań biznesowych możesz zdecydować się na różne traktowanie różnych zasobów usługi Azure Machine Learning. Na przykład możesz chcieć użyć gorąca/gorąca w przypadku wdrożonych modeli (wnioskowanie) i gorąca/zimna w przypadku eksperymentów (trenowanie).
Usługa Azure Machine Learning bazuje na innych usługach. Niektóre usługi można skonfigurować do replikacji do innych regionów. Inne osoby, które należy utworzyć ręcznie w wielu regionach. Poniższa tabela zawiera listę usług, które są odpowiedzialne za replikację oraz omówienie konfiguracji:
Usługa platformy Azure | Replikacja geograficzna przez | Konfigurowanie |
---|---|---|
Obszar roboczy usługi Machine Learning | Ty | Utwórz obszar roboczy w wybranych regionach. |
Obliczenia usługi Machine Learning | Ty | Utwórz zasoby obliczeniowe w wybranych regionach. W przypadku zasobów obliczeniowych, które mogą dynamicznie skalować, upewnij się, że oba regiony zapewniają wystarczający limit przydziału zasobów obliczeniowych dla Twoich potrzeb. |
Rejestr uczenia maszynowego | Ty | Utwórz rejestr w wielu regionach. |
Key Vault | Microsoft | Użyj tego samego wystąpienia usługi Key Vault z obszarem roboczym i zasobami usługi Azure Machine Learning w obu regionach. Usługa Key Vault automatycznie przełączy się w tryb failover do regionu pomocniczego. Aby uzyskać więcej informacji, zobacz Dostępność i nadmiarowość usługi Azure Key Vault. |
Container Registry | Microsoft | Skonfiguruj wystąpienie usługi Container Registry w celu replikacji geograficznej rejestrów do sparowanego regionu dla usługi Azure Machine Learning. Użyj tego samego wystąpienia dla obu wystąpień obszaru roboczego. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna w usłudze Azure Container Registry. |
Konto magazynu | Ty | Usługa Azure Machine Learning nie obsługuje domyślnego trybu failover konta magazynu przy użyciu magazynu geograficznie nadmiarowego (GRS), magazynu geograficznie nadmiarowego strefowo nadmiarowego (GZRS), magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GRS) ani magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GZRS). Utwórz oddzielne konto magazynu dla domyślnego magazynu każdego obszaru roboczego. Utwórz oddzielne konta magazynu lub usługi dla innego magazynu danych. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage. |
Szczegółowe dane dotyczące aplikacji | Ty | Utwórz usługę Application Insights dla obszaru roboczego w obu regionach. Aby dostosować okres przechowywania danych i szczegóły, zobacz Zbieranie, przechowywanie i przechowywanie danych w usłudze Application Insights. |
Aby włączyć szybkie odzyskiwanie i ponowne uruchomienie w regionie pomocniczym, zalecamy następujące rozwiązania programistyczne:
- Użyj szablonów usługi Azure Resource Manager. Szablony to "infrastruktura jako kod" i umożliwiają szybkie wdrażanie usług w obu regionach.
- Aby uniknąć dryfu między dwoma regionami, zaktualizuj potoki ciągłej integracji i wdrażania w celu wdrożenia w obu regionach.
- Podczas automatyzowania wdrożeń uwzględnij konfigurację dołączonych zasobów obliczeniowych obszaru roboczego, takich jak usługa Azure Kubernetes Service.
- Tworzenie przypisań ról dla użytkowników w obu regionach.
- Utwórz zasoby sieciowe, takie jak sieci wirtualne platformy Azure i prywatne punkty końcowe dla obu regionów. Upewnij się, że użytkownicy mają dostęp do obu środowisk sieciowych. Na przykład konfiguracje sieci VPN i DNS dla obu sieci wirtualnych.
Usługi obliczeniowe i usługi danych
W zależności od potrzeb może istnieć więcej usług obliczeniowych lub danych, które są używane przez usługę Azure Machine Learning. Możesz na przykład użyć usług Azure Kubernetes Services lub Azure SQL Database. Skorzystaj z poniższych informacji, aby dowiedzieć się, jak skonfigurować te usługi pod kątem wysokiej dostępności.
Zasoby obliczeniowe
- Azure Kubernetes Service: zobacz Najlepsze rozwiązania dotyczące ciągłości działania i odzyskiwania po awarii w usłudze Azure Kubernetes Service (AKS) i Tworzenie klastra usługi Azure Kubernetes Service (AKS), który korzysta ze stref dostępności. Jeśli klaster usługi AKS został utworzony przy użyciu programu Azure Machine Learning Studio, zestawu SDK lub interfejsu wiersza polecenia, wysoka dostępność między regionami nie jest obsługiwana.
- Azure Databricks: zobacz Regionalne odzyskiwanie po awarii dla klastrów usługi Azure Databricks.
- Container Instances: Koordynator jest odpowiedzialny za tryb failover. Zobacz Azure Container Instances i koordynatorzy kontenerów.
- HDInsight: zobacz Usługi wysokiej dostępności obsługiwane przez usługę Azure HDInsight.
Usługi danych
- Kontener obiektów blob platformy Azure / Azure Files / Data Lake Storage Gen2: zobacz Nadmiarowość usługi Azure Storage.
- Data Lake Storage Gen1: zobacz Wskazówki dotyczące wysokiej dostępności i odzyskiwania po awarii dla usługi Data Lake Storage Gen1.
Napiwek
Jeśli podasz własny klucz zarządzany przez klienta w celu wdrożenia obszaru roboczego usługi Azure Machine Learning, usługa Azure Cosmos DB jest również aprowizowana w ramach subskrypcji. W takim przypadku ponosisz odpowiedzialność za konfigurowanie ustawień wysokiej dostępności. Zobacz Wysoka dostępność w usłudze Azure Cosmos DB.
Projektowanie na potrzeby wysokiej dostępności
Strefy dostępności
Niektóre usługi platformy Azure obsługują strefy dostępności. W przypadku regionów obsługujących strefy dostępności, jeśli strefa ulegnie awarii, a dane powinny zostać zapisane. Jednak dane są niedostępne do odświeżenia, dopóki strefa nie wróci do trybu online.
Aby uzyskać więcej informacji, zobacz Usługa strefy dostępności i obsługa regionalna.
Wdrażanie krytycznych składników w wielu regionach
Określ poziom ciągłości działania, którego chcesz służyć. Poziom może się różnić między składnikami rozwiązania. Na przykład możesz chcieć mieć konfigurację gorącą/gorącą dla potoków produkcyjnych lub wdrożeń modelu oraz gorącą/zimną na potrzeby eksperymentowania.
Zarządzanie danymi treningowymi w izolowanym magazynie
Dzięki przechowywaniu magazynu danych odizolowanego od domyślnego magazynu obszar roboczy używany przez dzienniki można wykonywać następujące czynności:
- Dołącz te same wystąpienia magazynu co magazyny danych do podstawowych i pomocniczych obszarów roboczych.
- Korzystaj z replikacji geograficznej dla kont magazynu danych i maksymalizuj czas pracy.
Zarządzanie zasobami uczenia maszynowego jako kodem
Uwaga
Tworzenie kopii zapasowych i przywracanie metadanych obszaru roboczego, takich jak historia uruchamiania, modele i środowiska, są niedostępne. Określenie zasobów i konfiguracji jako kodu przy użyciu specyfikacji YAML ułatwi ponowne utworzenie zasobów między obszarami roboczymi w przypadku awarii.
Zadania w usłudze Azure Machine Learning są definiowane przez specyfikację zadania. Ta specyfikacja obejmuje zależności od artefaktów wejściowych zarządzanych na poziomie wystąpienia obszaru roboczego, w tym środowisk i obliczeń. W przypadku przesyłania i wdrożeń zadań obejmujących wiele regionów zalecamy następujące rozwiązania:
Lokalnie zarządzaj bazą kodu wspieraną przez repozytorium Git.
- Eksportowanie ważnych notesów z usługi Azure Machine Learning Studio.
- Eksportowanie potoków utworzonych w programie Studio jako kodu.
Zarządzanie konfiguracjami jako kodem.
- Unikaj zakodowanych na stałe odwołań do obszaru roboczego. Zamiast tego skonfiguruj odwołanie do wystąpienia obszaru roboczego przy użyciu pliku konfiguracji i użyj MLClient.from_config(), aby zainicjować obszar roboczy.
- Użyj pliku Dockerfile, jeśli używasz niestandardowych obrazów platformy Docker.
Inicjowanie trybu failover
Kontynuuj pracę w obszarze roboczym trybu failover
Gdy podstawowy obszar roboczy stanie się niedostępny, możesz przełączyć się na pomocniczy obszar roboczy, aby kontynuować eksperymentowanie i programowanie. Usługa Azure Machine Learning nie przesyła automatycznie zadań do pomocniczego obszaru roboczego, jeśli wystąpi awaria. Zaktualizuj konfigurację kodu, aby wskazywała nowy zasób obszaru roboczego. Zalecamy unikanie odwołań do obszaru roboczego na twardo. Zamiast tego użyj pliku konfiguracji obszaru roboczego, aby zminimalizować ręczne kroki użytkownika podczas zmieniania obszarów roboczych. Pamiętaj również o zaktualizowaniu wszelkich automatyzacji, takich jak potoki ciągłej integracji i wdrażania w nowym obszarze roboczym.
Usługa Azure Machine Learning nie może synchronizować ani odzyskiwać artefaktów ani metadanych między wystąpieniami obszaru roboczego. W zależności od strategii wdrażania aplikacji może być konieczne przeniesienie artefaktów lub ponowne utworzenie danych wejściowych eksperymentów, takich jak zasoby danych, w obszarze roboczym trybu failover w celu kontynuowania przesyłania zadań. W przypadku skonfigurowania podstawowego obszaru roboczego i pomocniczych zasobów obszaru roboczego w celu udostępniania skojarzonych zasobów z włączoną replikacją geograficzną niektóre obiekty mogą być dostępne bezpośrednio w obszarze roboczym trybu failover. Jeśli na przykład oba obszary robocze współdzielą te same obrazy platformy Docker, skonfigurowane magazyny danych i zasoby usługi Azure Key Vault. Na poniższym diagramie przedstawiono konfigurację, w której dwa obszary robocze współdzielą te same obrazy (1), magazyny danych (2) i usługę Key Vault (3).
Uwaga
Wszystkie zadania uruchomione w przypadku awarii usługi nie zostaną automatycznie przełączene do pomocniczego obszaru roboczego. Jest również mało prawdopodobne, że zadania zostaną wznowione i zakończone pomyślnie w podstawowym obszarze roboczym po rozwiązaniu awarii. Zamiast tego należy ponownie przesłać te zadania w pomocniczym obszarze roboczym lub w podstawowym (po rozwiązaniu awarii).
Przenoszenie artefaktów między obszarami roboczymi
W zależności od podejścia do odzyskiwania może być konieczne skopiowanie artefaktów między obszarami roboczymi, aby kontynuować pracę. Obecnie przenośność artefaktów między obszarami roboczymi jest ograniczona. Zalecamy zarządzanie artefaktami jako kodem tam, gdzie to możliwe, aby można je było odtworzyć w wystąpieniu trybu failover.
Następujące artefakty można eksportować i importować między obszarami roboczymi przy użyciu rozszerzenia interfejsu wiersza polecenia platformy Azure na potrzeby uczenia maszynowego:
Napiwek
- Dane wyjściowe zadania są przechowywane na domyślnym koncie magazynu skojarzonym z obszarem roboczym. Dane wyjściowe zadania mogą stać się niedostępne z poziomu interfejsu użytkownika programu Studio w przypadku awarii usługi, ale możesz uzyskać bezpośredni dostęp do danych za pośrednictwem konta magazynu. Aby uzyskać więcej informacji na temat pracy z danymi przechowywanymi w obiektach blob, zobacz Tworzenie, pobieranie i wyświetlanie listy obiektów blob za pomocą interfejsu wiersza polecenia platformy Azure.
Opcje odzyskiwania
Usuwanie obszaru roboczego
Jeśli obszar roboczy został przypadkowo usunięty, możesz go odzyskać. Aby uzyskać instrukcje odzyskiwania, zobacz Odzyskiwanie danych obszaru roboczego po przypadkowym usunięciu przy użyciu usunięcia nietrwałego.
Nawet jeśli nie można odzyskać obszaru roboczego, nadal możesz pobrać notesy z skojarzonego z obszarem roboczym zasobu usługi Azure Storage, wykonując następujące kroki:
- W witrynie Azure Portal przejdź do konta magazynu połączonego z usuniętym obszarem roboczym usługi Azure Machine Learning.
- W sekcji Magazyn danych po lewej stronie wybierz pozycję Udziały plików.
- Notesy znajdują się w udziale plików o nazwie zawierającej identyfikator obszaru roboczego.
Następne kroki
Aby dowiedzieć się więcej o powtarzalnych wdrożeniach infrastruktury za pomocą usługi Azure Machine Learning, użyj szablonu Bicep lub szablonu narzędzia Terraform.