Failover voor bedrijfscontinuïteit en herstel na noodgevallen
Als u uw uptime wilt maximaliseren, plant u de bedrijfscontinuïteit en bereidt u zich voor op herstel na noodgevallen met Azure Machine Learning.
Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Er kunnen echter niet-geplande servicestoringen optreden. We raden u aan een noodherstelplan in te stellen voor het afhandelen van regionale servicestoringen. In dit artikel leert u het volgende:
- Plan een implementatie met meerdere regio's van Azure Machine Learning en bijbehorende resources.
- Maximaliseer de kans om logboeken, notebooks, docker-installatiekopieën en andere metagegevens te herstellen.
- Ontwerp voor hoge beschikbaarheid van uw oplossing.
- Start een failover naar een andere regio.
Belangrijk
Azure Machine Learning zelf biedt geen automatische failover of herstel na noodgeval. Back-up en herstel van metagegevens van werkruimten, zoals uitvoeringsgeschiedenis, is niet beschikbaar.
Als u uw werkruimte of bijbehorende onderdelen per ongeluk hebt verwijderd, biedt dit artikel u ook momenteel ondersteunde herstelopties.
Inzicht in Azure-services voor Azure Machine Learning
Azure Machine Learning is afhankelijk van meerdere Azure-services. Sommige van deze services worden ingericht in uw abonnement. U bent verantwoordelijk voor de configuratie van hoge beschikbaarheid van deze services. Andere services worden gemaakt in een Microsoft-abonnement en worden beheerd door Microsoft.
Azure-services zijn onder andere:
Azure Machine Learning-infrastructuur: een door Microsoft beheerde omgeving voor de Azure Machine Learning-werkruimte.
Gekoppelde resources: Resources die zijn ingericht in uw abonnement tijdens het maken van een Azure Machine Learning-werkruimte. Deze resources omvatten Azure Storage, Azure Key Vault, Azure Container Registry en Application Insights.
- Standaardopslag bevat gegevens zoals model, trainingslogboekgegevens en verwijzingen naar gegevensassets.
- Key Vault heeft referenties voor Azure Storage, Container Registry en gegevensarchieven.
- Container Registry heeft een Docker-installatiekopie voor trainings- en deductieomgevingen.
- Application Insights is bedoeld voor het bewaken van Azure Machine Learning.
Rekenresources: resources die u maakt na de implementatie van de werkruimte. U kunt bijvoorbeeld een rekenproces of rekencluster maken om een Machine Learning-model te trainen.
- Rekenproces en rekencluster: door Microsoft beheerde ontwikkelomgevingen voor modellen.
- Andere resources: Microsoft-computingresources die u kunt koppelen aan Azure Machine Learning, zoals Azure Kubernetes Service (AKS), Azure Databricks, Azure Container Instances en Azure HDInsight. U bent verantwoordelijk voor het configureren van instellingen voor hoge beschikbaarheid voor deze resources.
Andere gegevensarchieven: Azure Machine Learning kan andere gegevensarchieven, zoals Azure Storage en Azure Data Lake Storage, koppelen voor trainingsgegevens. Deze gegevensarchieven worden ingericht binnen uw abonnement. U bent verantwoordelijk voor het configureren van hun instellingen voor hoge beschikbaarheid. Zie Gegevensarchieven maken voor meer informatie over andere opties voor gegevensopslag.
In de volgende tabel ziet u dat de Azure-services worden beheerd door Microsoft en die door u worden beheerd. Het geeft ook de services aan die standaard maximaal beschikbaar zijn.
| Service | Beheerd door | Hoge beschikbaarheid standaard |
|---|---|---|
| Azure Machine Learning-infrastructuur | Microsoft | |
| Gekoppelde resources | ||
| Azure Storage | U | |
| Key Vault | U | ✓ |
| Container Registry | U | |
| Analyses van toepassingen | U | N.v.t. |
| Rekenresources | ||
| Rekenproces | Microsoft | |
| Rekencluster | Microsoft | |
| Andere rekenresources, zoals AKS, Azure Databricks, Container Instances, HDInsight |
U | |
| Andere gegevensarchieven , zoals Azure Storage, SQL Database, Azure Database for PostgreSQL, Azure Database for MySQL, Azure Databricks-bestandssysteem |
U |
In de rest van dit artikel worden de acties beschreven die u moet ondernemen om elk van deze services maximaal beschikbaar te maken.
Plannen voor implementatie in meerdere regio's
Een implementatie in meerdere regio's is afhankelijk van het maken van Azure Machine Learning en andere resources (infrastructuur) in twee Azure-regio's. Als er een regionale storing optreedt, kunt u overschakelen naar de andere regio. Wanneer u van plan bent waar uw resources te implementeren, kunt u het volgende overwegen:
Regionale beschikbaarheid: gebruik indien mogelijk een regio in hetzelfde geografische gebied, niet noodzakelijkerwijs het gebied dat het dichtst bij zich ligt. Als u de regionale beschikbaarheid van Azure Machine Learning wilt controleren, raadpleegt u Azure-producten per regio.
Gekoppelde Azure-regio's: gekoppelde regio's coördineren platformupdates en prioriteren waar nodig herstelinspanningen. Niet alle regio's ondersteunen echter gekoppelde regio's. Zie Gekoppelde Azure-regio's voor meer informatie.
Beschikbaarheid van de service: bepaal of de resources die door uw oplossing worden gebruikt hot/hot, hot/warm of hot/cold moeten zijn.
- Dynamisch/dynamisch: beide regio's zijn tegelijkertijd actief, met één regio die direct kan worden gebruikt.
- Dynamisch/warm: primaire regio actief, secundaire regio heeft kritieke resources (bijvoorbeeld geïmplementeerde modellen) die klaar zijn om te starten. Niet-kritieke resources moeten handmatig worden geïmplementeerd in de secundaire regio.
- Dynamisch/koud: actieve primaire regio, secundaire regio heeft Azure Machine Learning en andere resources geïmplementeerd, samen met de benodigde gegevens. Resources zoals modellen, modelimplementaties of pijplijnen moeten handmatig worden geïmplementeerd.
Tip
Afhankelijk van uw zakelijke vereisten, kunt u besluiten om verschillende Azure Machine Learning-resources anders te behandelen. U kunt bijvoorbeeld dynamisch/dynamisch gebruiken voor geïmplementeerde modellen (deductie) en dynamisch/koud voor experimenten (training).
Azure Machine Learning bouwt voort op andere services. Sommige services kunnen worden geconfigureerd voor replicatie naar andere regio's. Anderen die u handmatig moet maken in meerdere regio's. De volgende tabel bevat een lijst met services, die verantwoordelijk zijn voor replicatie en een overzicht van de configuratie:
| Azure-service | Geo-replicatie door | Configuratie |
|---|---|---|
| Werkruimte voor Machine Learning | U | Maak een werkruimte in de geselecteerde regio's. |
| Machine Learning-rekenkracht | U | Maak de rekenresources in de geselecteerde regio's. Voor rekenresources die dynamisch kunnen worden geschaald, moet u ervoor zorgen dat beide regio's voldoende rekenquotum bieden voor uw behoeften. |
| Machine Learning-register | U | Maak het register in meerdere regio's. |
| Key Vault | Microsoft | Gebruik hetzelfde Key Vault-exemplaar met de Azure Machine Learning-werkruimte en -resources in beide regio's. Key Vault voert automatisch een failover uit naar een secundaire regio. Zie Beschikbaarheid en redundantie in Azure Key Vault voor meer informatie. |
| Container Registry | Microsoft | Configureer het Container Registry-exemplaar voor geo-replicatie van registers naar de gekoppelde regio voor Azure Machine Learning. Gebruik hetzelfde exemplaar voor beide werkruimte-exemplaren. Zie Geo-replicatie in Azure Container Registry voor meer informatie. |
| Opslagaccount | U | Azure Machine Learning biedt geen ondersteuning voor failover van standaardopslagaccounts met geografisch redundante opslag (GRS), geografisch zone-redundante opslag (GZRS), geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). Maak een afzonderlijk opslagaccount voor de standaardopslag van elke werkruimte. Maak afzonderlijke opslagaccounts of -services voor andere gegevensopslag. Zie Redundantie in Azure Storage voor meer informatie. |
| Analyses van toepassingen | U | Maak Application Insights voor de werkruimte in beide regio's. Zie Gegevensverzameling, -retentie en -opslag in Application Insights om de gegevensretentieperiode en -details aan te passen. |
Als u snel herstel en opnieuw opstarten in de secundaire regio wilt inschakelen, raden we de volgende ontwikkelprocedures aan:
- Gebruik Azure Resource Manager-sjablonen. Sjablonen zijn 'infrastructuur als code' en bieden u de mogelijkheid om snel services in beide regio's te implementeren.
- Werk uw pijplijnen voor continue integratie en implementatie bij om te implementeren in beide regio's om drift tussen de twee regio's te voorkomen.
- Neem bij het automatiseren van implementaties de configuratie op van rekenresources die aan de werkruimte zijn gekoppeld, zoals Azure Kubernetes Service.
- Roltoewijzingen maken voor gebruikers in beide regio's.
- Maak netwerkbronnen, zoals Azure Virtual Networks en privé-eindpunten voor beide regio's. Zorg ervoor dat gebruikers toegang hebben tot beide netwerkomgevingen. Vpn- en DNS-configuraties bijvoorbeeld voor beide virtuele netwerken.
Compute- en gegevensservices
Afhankelijk van uw behoeften hebt u mogelijk meer reken- of gegevensservices die worden gebruikt door Azure Machine Learning. U kunt bijvoorbeeld Azure Kubernetes Services of Azure SQL Database gebruiken. Gebruik de volgende informatie om te leren hoe u deze services configureert voor hoge beschikbaarheid.
Rekenresources
- Azure Kubernetes Service: Zie best practices voor bedrijfscontinuïteit en herstel na noodgevallen in Azure Kubernetes Service (AKS) en een AKS-cluster (Azure Kubernetes Service) maken dat gebruikmaakt van beschikbaarheidszones. Als het AKS-cluster is gemaakt met behulp van de Azure Machine Learning-studio, SDK of CLI, wordt hoge beschikbaarheid tussen regio's niet ondersteund.
- Azure Databricks: Zie Regionaal herstel na noodgevallen voor Azure Databricks-clusters.
- Container Instances: Een orchestrator is verantwoordelijk voor failover. Zie Azure Container Instances en containerorchestrators.
- HDInsight: Bekijk services met hoge beschikbaarheid die worden ondersteund door Azure HDInsight.
Gegevensservices
- Azure Blob-container/Azure Files/Data Lake Storage Gen2: Zie Azure Storage-redundantie.
- Data Lake Storage Gen1: Zie richtlijnen voor hoge beschikbaarheid en herstel na noodgevallen voor Data Lake Storage Gen1.
Tip
Als u uw eigen door de klant beheerde sleutel opgeeft voor het implementeren van een Azure Machine Learning-werkruimte, wordt Azure Cosmos DB ook ingericht binnen uw abonnement. In dat geval bent u verantwoordelijk voor het configureren van de instellingen voor hoge beschikbaarheid. Zie Hoge beschikbaarheid in Azure Cosmos DB.
Ontwerpen voor hoge beschikbaarheid
Beschikbaarheidszones
Bepaalde Azure-services ondersteunen beschikbaarheidszones. Voor regio's die beschikbaarheidszones ondersteunen, wordt een zone onderbroken en moeten gegevens worden opgeslagen. De gegevens zijn echter niet beschikbaar om te vernieuwen totdat de zone weer online is.
Zie Beschikbaarheidszoneservice en regionale ondersteuning voor meer informatie.
Essentiële onderdelen implementeren in meerdere regio's
Bepaal het niveau van bedrijfscontinuïteit waarnaar u op zoek bent. Het niveau kan verschillen tussen de onderdelen van uw oplossing. U wilt bijvoorbeeld een dynamische/dynamische configuratie hebben voor productiepijplijnen of modelimplementaties en dynamische/koude configuratie voor experimenten.
Trainingsgegevens beheren in geïsoleerde opslag
Door uw gegevensopslag geïsoleerd te houden van de standaardopslag die door de werkruimte wordt gebruikt voor logboeken, kunt u het volgende doen:
- Koppel dezelfde opslagexemplaren als gegevensarchieven aan de primaire en secundaire werkruimten.
- Maak gebruik van geo-replicatie voor gegevensopslagaccounts en maximaliseer uw uptime.
Machine Learning-assets beheren als code
Notitie
Back-up en herstel van metagegevens van werkruimten, zoals uitvoeringsgeschiedenis, modellen en omgevingen, is niet beschikbaar. Als u assets en configuraties opgeeft als code met behulp van YAML-specificaties, kunt u assets opnieuw maken in werkruimten in geval van een noodgeval.
Taken in Azure Machine Learning worden gedefinieerd door een taakspecificatie. Deze specificatie omvat afhankelijkheden van invoerartefacten die worden beheerd op werkruimte-exemplaarniveau, inclusief omgevingen en berekeningen. Voor het indienen en implementeren van taken in meerdere regio's raden we de volgende procedures aan:
Beheer uw codebasis lokaal, ondersteund door een Git-opslagplaats.
- Exporteer belangrijke notitieblokken uit Azure Machine Learning-studio.
- Exporteer pijplijnen die zijn geschreven in Studio als code.
Configuraties beheren als code.
- Vermijd in code vastgelegde verwijzingen naar de werkruimte. Configureer in plaats daarvan een verwijzing naar het werkruimte-exemplaar met behulp van een configuratiebestand en gebruik MLClient.from_config() om de werkruimte te initialiseren.
- Gebruik een Dockerfile als u aangepaste Docker-installatiekopieën gebruikt.
Een failover initiëren
Doorgaan met werken in de failoverwerkruimte
Wanneer uw primaire werkruimte niet meer beschikbaar is, kunt u overschakelen naar de secundaire werkruimte om door te gaan met experimenteren en ontwikkelen. Azure Machine Learning verzendt taken niet automatisch naar de secundaire werkruimte als er een storing is. Werk de codeconfiguratie bij zodat deze verwijst naar de nieuwe werkruimteresource. We raden u aan om verwijzingen naar de werkruimte te vermijden die hardcoding bevatten. Gebruik in plaats daarvan een configuratiebestand voor werkruimten om handmatige gebruikersstappen te minimaliseren bij het wijzigen van werkruimten. Zorg ervoor dat u ook automatisering bijwerkt, zoals pijplijnen voor continue integratie en implementatie naar de nieuwe werkruimte.
Azure Machine Learning kan artefacten of metagegevens tussen werkruimte-exemplaren niet synchroniseren of herstellen. Afhankelijk van de implementatiestrategie van uw toepassing moet u mogelijk artefacten verplaatsen of invoer van experimenten, zoals gegevensassets, opnieuw maken in de failoverwerkruimte om door te gaan met het indienen van taken. Als u uw primaire werkruimte en secundaire werkruimteresources hebt geconfigureerd om gekoppelde resources te delen met geo-replicatie ingeschakeld, zijn sommige objecten mogelijk rechtstreeks beschikbaar voor de failoverwerkruimte. Als beide werkruimten bijvoorbeeld dezelfde Docker-installatiekopieën, geconfigureerde gegevensarchieven en Azure Key Vault-resources delen. In het volgende diagram ziet u een configuratie waarbij twee werkruimten dezelfde installatiekopieën (1), gegevensarchieven (2) en Key Vault (3) delen.
Notitie
Taken die worden uitgevoerd wanneer er een servicestoring optreedt, worden niet automatisch overgezet naar de secundaire werkruimte. Het is ook onwaarschijnlijk dat de taken worden hervat en voltooid in de primaire werkruimte zodra de storing is opgelost. In plaats daarvan moeten deze taken opnieuw worden ingediend in de secundaire werkruimte of in de primaire werkruimte (zodra de storing is opgelost).
Artefacten verplaatsen tussen werkruimten
Afhankelijk van uw herstelbenadering moet u mogelijk artefacten kopiëren tussen de werkruimten om uw werk voort te zetten. Momenteel is de draagbaarheid van artefacten tussen werkruimten beperkt. We raden u aan artefacten indien mogelijk als code te beheren, zodat ze opnieuw kunnen worden gemaakt in het failover-exemplaar.
De volgende artefacten kunnen worden geëxporteerd en geïmporteerd tussen werkruimten met behulp van de Azure CLI-extensie voor machine learning:
Tip
- Taakuitvoer wordt opgeslagen in het standaardopslagaccount dat is gekoppeld aan een werkruimte. Hoewel taakuitvoer mogelijk niet toegankelijk is vanuit de gebruikersinterface van studio in het geval van een servicestoring, hebt u rechtstreeks toegang tot de gegevens via het opslagaccount. Zie Blobs maken, downloaden en vermelden met Azure CLI voor meer informatie over het werken met gegevens die zijn opgeslagen in blobs.
Herstelopties
Werkruimte verwijderen
Als u uw werkruimte per ongeluk hebt verwijderd, kunt u deze mogelijk herstellen. Zie Werkruimtegegevens herstellen na onbedoeld verwijderen met voorlopig verwijderen voor herstelstappen.
Zelfs als uw werkruimte niet kan worden hersteld, kunt u mogelijk nog steeds uw notebooks ophalen uit de aan de werkruimte gekoppelde Azure-opslagresource door de volgende stappen uit te voeren:
- Navigeer in Azure Portal naar het opslagaccount dat is gekoppeld aan de verwijderde Azure Machine Learning-werkruimte.
- Selecteer bestandsshares in de sectie Gegevensopslag aan de linkerkant.
- Uw notitieblokken bevinden zich op de bestandsshare met de naam die uw werkruimte-id bevat.
Volgende stappen
Gebruik een Bicep-sjabloon of Terraform-sjabloon voor meer informatie over herhaalbare infrastructuurimplementaties met Azure Machine Learning.