Failover per la continuità aziendale e il ripristino di emergenza
Per ottimizzare il tempo di attività, pianificare in anticipo la continuità aziendale e prepararsi al ripristino di emergenza con Azure Machine Learning.
Microsoft si impegna per fare in modo che i servizi di Azure siano sempre disponibili. Potrebbero tuttavia verificarsi interruzioni dei servizi non pianificate. È consigliabile disporre di un piano di ripristino di emergenza per la gestione delle interruzioni del servizio a livello di area. In questo articolo vengono illustrate le operazioni seguenti:
- Pianificare una distribuzione a più aree di Azure Machine Learning e le risorse associate.
- Possibilità di recuperare log, notebook, immagini Docker e altri metadati.
- Progettare per la disponibilità elevata della soluzione.
- Avviare un failover in un'altra area.
Importante
Azure Machine Learning non offre alcun failover automatico o ripristino di emergenza. Il backup e il ripristino dei metadati dell'area di lavoro, ad esempio la cronologia di esecuzione, non sono disponibili.
Nel caso in cui l'area di lavoro o i componenti corrispondenti siano stati eliminati accidentalmente, questo articolo offre anche opzioni di ripristino attualmente supportate.
Informazioni sui servizi di Azure per Azure Machine Learning
Azure Machine Learning dipende da più servizi di Azure. È stato effettuato il provisioning di alcuni di questi servizi nella sottoscrizione. L'utente è responsabile della configurazione a disponibilità elevata di questi servizi. Altri servizi vengono creati in una sottoscrizione Microsoft e gestiti da Microsoft.
I servizi di Azure includono:
Infrastruttura di Azure Machine Learning: un ambiente gestito da Microsoft per l'area di lavoro di Azure Machine Learning.
Risorse associate: risorse sottoposte a provisioning nella sottoscrizione durante la creazione dell'area di lavoro di Azure Machine Learning. Queste risorse includono Archiviazione di Azure, Azure Key Vault, Registro Azure Container e Application Insights.
- L'archiviazione predefinita include dati come modello, dati di log di training e riferimenti agli asset di dati.
- Key Vault dispone di credenziali per Archiviazione di Azure, Registro Container e archivi dati.
- Registro Container ha un'immagine Docker per ambienti di training e inferenza.
- Application Insights è per il monitoraggio di Azure Machine Learning.
Risorse di calcolo: risorse create dopo la distribuzione dell'area di lavoro. Ad esempio, è possibile creare un'istanza di ambiente di calcolo o un cluster di elaborazione per eseguire il training di un modello di Machine Learning.
- Istanza di ambiente di calcolo e cluster di elaborazione: ambienti di sviluppo di modelli gestiti da Microsoft.
- Altre risorse: risorse di calcolo Microsoft che è possibile collegare ad Azure Machine Learning, ad esempio il servizio Azure Kubernetes, Azure Databricks, Istanze di Azure Container e Azure HDInsight. Si è responsabili della configurazione delle impostazioni di disponibilità elevata per queste risorse.
Altri archivi dati: Azure Machine Learning può montare altri archivi dati, ad esempio Archiviazione di Azure e Azure Data Lake Storage per i dati di training. Il provisioning di questi archivi dati viene eseguito all'interno della sottoscrizione. L'utente è responsabile della configurazione delle impostazioni di disponibilità elevata. Per visualizzare altre opzioni dell'archivio dati, vedere Creare archivi dati.
La tabella seguente illustra i servizi di Azure gestiti da Microsoft e gestiti dall'utente. Indica anche i servizi a disponibilità elevata per impostazione predefinita.
| Servizio | Gestito da | Disponibilità elevata per impostazione predefinita |
|---|---|---|
| Infrastruttura di Azure Machine Learning | Microsoft | |
| Risorse associate | ||
| Archiviazione di Azure | Te | |
| Key Vault | Te | ✓ |
| Registro Container | Te | |
| Application Insights | Te | N/D |
| Risorse di calcolo | ||
| Istanza di calcolo | Microsoft | |
| Cluster di elaborazione | Microsoft | |
| Altre risorse di calcolo, ad esempio il servizio Azure Kubernetes, Azure Databricks, Istanze di Container, HDInsight |
Te | |
| Altri archivi dati, ad esempio Archiviazione di Azure, database SQL, Database di Azure per PostgreSQL, Database di Azure per MySQL, Azure Databricks File System |
Te |
Nella parte restante di questo articolo vengono descritte le azioni da eseguire per rendere ognuno di questi servizi a disponibilità elevata.
Eseguire la pianificazione per la distribuzione in più aree
Una distribuzione su più aree si basa sulla creazione di Azure Machine Learning e di altre risorse (infrastruttura) in due aree di Azure. Se si verifica un'interruzione a livello di area, è possibile passare all'altra area. Quando si pianifica la posizione in cui distribuire le risorse, prendere in considerazione:
Disponibilità a livello di area: se possibile, usare un'area nella stessa area geografica, non necessariamente quella più vicina. Per verificare la disponibilità a livello di area per Azure Machine Learning, vedere Prodotti Azure per area.
Aree abbinate di Azure: le aree abbinate coordinano gli aggiornamenti della piattaforma e assegnano priorità alle attività di ripristino dove necessario. Tuttavia, non tutte le aree supportano aree abbinate. Per altre informazioni, vedere Aree abbinate di Azure.
Disponibilità del servizio: decidere se le risorse usate dalla soluzione devono essere hot/hot (accesso frequente/accesso frequente), hot/warm (accesso frequente/accesso a frequenza media) o hot/cold (accesso frequente/accesso saltuario).
- Accesso frequente/accesso frequente: entrambe le aree sono attive contemporaneamente, con un'area pronta per iniziare immediatamente l'uso.
- Accesso frequente/accesso a frequenza media: l'area primaria è attiva, l'area secondaria ha delle risorse critiche (ad esempio, modelli distribuiti) pronte per l'avvio. Le risorse non critiche devono essere distribuite manualmente nell'area secondaria.
- Accesso frequente/accesso sporadico: l'area primaria è attiva, l'area secondaria include Azure Machine Learning e altre risorse distribuite, insieme ai dati necessari. È necessario distribuire manualmente risorse come modelli, distribuzioni di modelli o pipeline.
Suggerimento
A seconda dei requisiti aziendali, è possibile decidere di gestire diverse risorse di Azure Machine Learning in modo diverso. Ad esempio, è possibile usare l'accesso frequente/frequente per i modelli distribuiti (inferenza) e ad accesso frequente/sporadico per gli esperimenti (training).
Azure Machine Learning si basa su altri servizi. Alcuni servizi possono essere configurati per la replica in altre aree. Altri utenti devono essere creati manualmente in più aree. La tabella seguente fornisce un elenco di servizi, responsabili della replica e una panoramica della configurazione:
| Servizio di Azure | Con replica geografica da | Impostazione |
|---|---|---|
| Area di lavoro di Machine Learning | Te | Creare un'area di lavoro nelle aree selezionate. |
| Ambiente di calcolo di Machine Learning | Te | Creare le risorse di calcolo nelle aree selezionate. Per le risorse di calcolo che possono essere ridimensionate in modo dinamico, assicurarsi che entrambe le aree forniscano una quota di calcolo sufficiente per le proprie esigenze. |
| Registro di Machine Learning | Te | Creare il Registro di sistema in più aree. |
| Key Vault | Microsoft | Usare la stessa istanza di Key Vault con l'area di lavoro e le risorse di Azure Machine Learning in entrambe le aree. Key Vault esegue automaticamente il failover in un'area secondaria. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault. |
| Registro Container | Microsoft | Configurare l'istanza di Registro Container per replicare geograficamente i registri nell'area abbinata per Azure Machine Learning. Usare la stessa istanza per entrambe le istanze dell'area di lavoro. Per altre informazioni, vedere Replica geografica in Registro Azure Container. |
| Account di archiviazione | Te | Azure Machine Learning non supporta il failover predefinito dell'account di archiviazione usando l'archiviazione con ridondanza geografica (GRS), l'archiviazione con ridondanza geografica della zona (GZRS), l'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) o l'archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS). Creare un account di archiviazione separato per l'archiviazione predefinita di ogni area di lavoro. Creare account di archiviazione o servizi separati per altre risorse di archiviazione dati. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure. |
| Application Insights | Te | Creare Application Insights per l'area di lavoro in entrambe le aree. Per modificare il periodo di conservazione dei dati e i dettagli, vedere Raccolta, conservazione e archiviazione dei dati in Application Insights. |
Per abilitare il ripristino rapido e il riavvio nell'area secondaria, è consigliabile seguire le procedure di sviluppo seguenti:
- Usare i modelli di Azure Resource Manager. I modelli sono "infrastruttura come codice" e consentono di distribuire rapidamente i servizi in entrambe le aree.
- Per evitare deviazioni tra le due aree, aggiornare le pipeline di integrazione continua e distribuzione per la distribuzione in entrambe le aree.
- Quando si automatizzano le distribuzioni, includere la configurazione delle risorse di calcolo associate all'area di lavoro, ad esempio il servizio Azure Kubernetes.
- Creare assegnazioni di ruolo per gli utenti in entrambe le aree.
- Creare risorse di rete, ad esempio reti virtuali di Azure ed endpoint privati per entrambe le aree. Assicurarsi che gli utenti abbiano accesso a entrambi gli ambienti di rete. Ad esempio, configurazioni VPN e DNS per entrambe le reti virtuali.
Servizi di calcolo e dati
A seconda delle esigenze, potrebbero essere disponibili più servizi di calcolo o dati usati da Azure Machine Learning. Ad esempio, è possibile usare i servizi Azure Kubernetes o il database SQL di Azure. Usare le informazioni seguenti per informazioni su come configurare questi servizi per la disponibilità elevata.
Risorse di calcolo
- Servizio Azure Kubernetes: vedere Procedure consigliate per la continuità aziendale e il ripristino di emergenza nel servizio Azure Kubernetes e Creare un cluster del servizio Azure Kubernetes che usa zone di disponibilità. Se il cluster del servizio Azure Kubernetes è stato creato usando Studio di Azure Machine Learning, SDK o l'interfaccia della riga di comando, la disponibilità elevata tra aree non è supportata.
- Azure Databricks: vedere Ripristino di emergenza a livello di area per i cluster di Azure Databricks.
- Istanze di Container: un agente di orchestrazione è responsabile del failover. Vedere Istanze di Azure Container e agenti di orchestrazione dei contenitori.
- HDInsight: vedere Servizi a disponibilità elevata supportati da Azure HDInsight.
Servizi dati
- Contenitore BLOB di Azure/File di Azure/Data Lake Storage Gen2: vedere Ridondanzadi Archiviazione di Azure.
- Data Lake Storage Gen1: vedere Linee guida per la disponibilità elevata e il ripristino di emergenza per Data Lake Storage Gen1.
Suggerimento
Se si specifica una chiave gestita dal cliente per distribuire un'area di lavoro di Azure Machine Learning, viene effettuato anche il provisioning di Azure Cosmos DB all'interno della sottoscrizione. In tal caso, si è responsabili della configurazione delle impostazioni di disponibilità elevata. Vedere Disponibilità elevata con Azure Cosmos DB.
Progettare la disponibilità elevata
Zone di disponibilità
Alcuni servizi di Azure supportano le zone di disponibilità. Per le aree che supportano le zone di disponibilità, se una zona diventa inattiva, qualsiasi carico di lavoro viene sospeso ed è necessario salvare i dati. Tuttavia, i dati non possono essere aggiornati fino a quando la zona non torna online.
Per altre informazioni, consultare Servizio di zona di disponibilità e supporto regionale.
Distribuire componenti critici in più aree
Determinare il livello di continuità aziendale che si intende raggiungere. Il livello potrebbe variare tra i componenti della soluzione. Ad esempio, si potrebbe avere una configurazione ad accesso frequente/accesso frequente per le pipeline di produzione o le distribuzioni di modelli e accesso frequente/accesso sporadico per la sperimentazione.
Gestire i dati di training nell'archiviazione isolata
Mantenendo l'archiviazione dei dati isolata dall'archiviazione predefinita usata dall'area di lavoro per i log, è possibile:
- Collegare le stesse istanze di archiviazione degli archivi dati alle aree di lavoro primarie e secondarie.
- Usare la replica geografica per gli account di archiviazione dati e ottimizzare il tempo di attività.
Gestire gli asset di Machine Learning come codice
Nota
Il backup e il ripristino dei metadati dell'area di lavoro, ad esempio cronologia di esecuzione, modelli e ambienti non sono disponibili. Se si specificano asset e configurazioni come codice usando specifiche YAML, sarà possibile ricreare gli asset tra le aree di lavoro in caso di emergenza.
I processi in Azure Machine Learning sono definiti da una specifica del processo. Questa specifica include dipendenze da artefatti di input gestiti a livello di istanza dell'area di lavoro, inclusi ambienti e calcolo. Per l'invio e le distribuzioni di processi in più aree, è consigliabile seguire queste procedure:
Gestire la codebase in locale, supportata da un repository Git.
- Esportare i notebook importanti dallo studio di Azure Machine Learning.
- Esportare le pipeline create in Studio come codice.
Gestire le configurazioni come codice.
- Evitare riferimenti hardcoded all'area di lavoro. Configurare invece un riferimento all'istanza dell'area di lavoro usando un file di configurazione e usare MLClient.from_config() per inizializzare l'area di lavoro.
- Usare un Dockerfile se si usano immagini Docker personalizzate.
Avviare un failover
Continuare a lavorare nell'area di lavoro di failover
Quando l'area di lavoro primaria non è più disponibile, è possibile passare all'area di lavoro secondaria per continuare la sperimentazione e lo sviluppo. Azure Machine Learning non invia automaticamente processi all'area di lavoro secondaria in caso di interruzione. Aggiornare la configurazione del codice in modo che punti alla nuova risorsa dell'area di lavoro. È consigliabile evitare riferimenti all'area di lavoro hardcoding. Usare invece un file di configurazione dell'area di lavoro per ridurre al minimo i passaggi utente manuali durante la modifica delle aree di lavoro. Assicurarsi di aggiornare anche qualsiasi automazione, ad esempio l'integrazione continua e le pipeline di distribuzione nella nuova area di lavoro.
Azure Machine Learning non è in grado di sincronizzare o ripristinare artefatti o metadati tra le istanze dell'area di lavoro. A seconda della strategia di distribuzione dell'applicazione, potrebbe essere necessario spostare artefatti o ricreare input di sperimentazione, ad esempio asset di dati nell'area di lavoro di failover per continuare l'invio di processi. Nel caso in cui l'area di lavoro primaria e le risorse dell'area di lavoro secondaria siano state configurate per condividere le risorse associate con la replica geografica abilitata, alcuni oggetti potrebbero essere direttamente disponibili per l'area di lavoro di failover. Ad esempio, se entrambe le aree di lavoro condividono le stesse immagini Docker, gli archivi dati configurati e le risorse di Azure Key Vault. Il diagramma seguente illustra una configurazione in cui due aree di lavoro condividono le stesse immagini (1), gli archivi dati (2) e Key Vault (3).
Nota
Tutti i processi in esecuzione quando si verifica un'interruzione del servizio non passano automaticamente all'area di lavoro secondaria. È anche improbabile che i processi vengano ripresi e completati correttamente nell'area di lavoro primaria dopo la risoluzione dell'interruzione. Al contrario, questi processi devono essere inviati di nuovo, nell'area di lavoro secondaria o nel database primario (una volta risolta l'interruzione).
Spostamento di elementi tra aree di lavoro
A seconda dell'approccio di ripristino, potrebbe essere necessario copiare artefatti tra le aree di lavoro per continuare il lavoro. Attualmente, la portabilità degli artefatti tra aree di lavoro è limitata. È consigliabile gestire gli artefatti come il codice, quando possibile, in modo che possano essere ricreati nell'istanza di failover.
È possibile esportare e importare gli artefatti seguenti tra aree di lavoro usando l'estensione dell'interfaccia della riga di comando di Azure per Machine Learning:
Suggerimento
- Gli output dei processi vengono archiviati nell'account di archiviazione predefinito associato a un'area di lavoro. Anche se gli output del processo potrebbero diventare inaccessibili dall'interfaccia utente di Studio in caso di interruzione del servizio, è possibile accedere direttamente ai dati tramite l'account di archiviazione. Per altre informazioni sull'uso dei dati archiviati nei BLOB, vedere Creare, scaricare ed elencare BLOB con l'interfaccia della riga di comando di Azure.
Opzioni di ripristino
Eliminazione dell'area di lavoro
Se l'area di lavoro è stata eliminata accidentalmente, potrebbe essere possibile recuperarla. Per i passaggi di recupero, vedere Recuperare i dati dell'area di lavoro dopo l'eliminazione accidentale con eliminazione temporanea.
Anche se l'area di lavoro non può essere ripristinata, è comunque possibile recuperare i notebook dalla risorsa di archiviazione di Azure associata all'area di lavoro seguendo questa procedura:
- Nel portale di Azure andare all'account di archiviazione collegato all'area di lavoro di Azure Machine Learning eliminata.
- Nella sezione Archiviazione dati a sinistra seleziona Condivisione file.
- I notebook si trovano tra i file condivisi con un nome che contiene l'ID dell'area di lavoro.
Passaggi successivi
Per informazioni sulle distribuzioni dell'infrastruttura ripetibili con Azure Machine Learning, usare unmodello Bicepo un modello Terraform.