Affidabilità in Azure Batch

Questo articolo descrive il supporto per l'affidabilità in Azure Batch e illustra sia la resilienza all'interno dell'area con le zone di disponibilità che i collegamenti alle informazioni sul ripristino tra aree e la continuità aziendale.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.

Batch mantiene la parità con Azure per supportare le zone di disponibilità.

Prerequisiti

• Per gli account Batch in modalità sottoscrizione utente, assicurarsi che la sottoscrizione in cui si sta creando il pool non abbia una restrizione dell'offerta di zona per lo SKU di macchina virtuale richiesto. Per verificare se la sottoscrizione non ha restrizioni, chiamare l'API Elenco SKU di risorse e controllare .ResourceSkuRestrictions Se esiste una restrizione della zona, è possibile inviare un ticket di supporto per rimuovere la restrizione della zona.

• Poiché InfiniBand non supporta la comunicazione tra zone, non è possibile creare un pool con criteri di zona se è abilitata la comunicazione tra nodi e usa uno SKU di macchina virtuale che supporta InfiniBand.

• Batch mantiene la parità con Azure per supportare le zone di disponibilità. Per usare l'opzione zonale, il pool deve essere creato in un'area di Azure con supporto per la zona di disponibilità.

• Per allocare il pool di Batch tra zone di disponibilità, l'area di Azure in cui è stato creato il pool deve supportare lo SKU della macchina virtuale richiesto in più zone. Per verificare che l'area supporti lo SKU della macchina virtuale richiesto in più di una zona, chiamare l'API Elenco SKU di risorse e controllare il locationInfo campo di resourceSku. Assicurarsi che più di una zona sia supportata per lo SKU di macchina virtuale richiesto. È anche possibile usare l'interfaccia della riga di comando di Azure per elencare tutti gli SKU di risorse disponibili con il comando seguente:

  
      az vm list-skus
  
  

Creare un pool di Azure Batch tra zone di disponibilità

Per esempi su come creare un pool di Batch tra zone di disponibilità, vedere Creare un pool di Azure Batch tra zone di disponibilità.

Altre informazioni sulla creazione di account Batch con il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell o l'API di gestione Batch.

Esperienza di inattività della zona

Durante un'interruzione della zona, i nodi all'interno di tale zona diventano non disponibili. Tutti i nodi all'interno dello stesso pool di nodi di altre zone non sono interessati e continuano a essere disponibili.

L'account Azure Batch non rialloca o crea nuovi nodi per compensare i nodi che sono stati disattivati a causa dell'interruzione. Gli utenti devono aggiungere altri nodi al pool di nodi, che vengono quindi allocati da altre zone integre.

Tolleranza di errore

Per prepararsi a un possibile errore della zona di disponibilità, è necessario effettuare il over-provisioning della capacità del servizio per garantire che la soluzione possa tollerare una perdita di capacità di 1/3 e continuare a funzionare senza prestazioni ridotte durante interruzioni a livello di zona. Poiché la piattaforma distribuisce le macchine virtuali tra tre zone ed è necessario tenere conto dell'errore di almeno una zona, moltiplicare il numero massimo di istanze del carico di lavoro per un fattore di zone/(zone-1) o 3/2. Ad esempio, se il carico di lavoro di picco tipico richiede quattro istanze, è necessario effettuare il provisioning di sei istanze: (2/3 * 6 istanze) = 4 istanze.

Migrazione della zona di disponibilità

Non è possibile eseguire la migrazione di un pool di Batch esistente al supporto della zona di disponibilità. Per ricreare il pool di Batch tra zone di disponibilità, vedere Creare un pool di Azure Batch tra zone di disponibilità.

Ripristino di emergenza e continuità aziendale tra aree

Azure Batch è disponibile in tutte le aree di Azure. Tuttavia, quando viene creato un account Batch, deve essere associato a un'area specifica. Tutte le operazioni successive per l'account Batch si applicano solo a tale area. I pool e le macchine virtuali associate, ad esempio, dovranno essere creati nella stessa area dell'account Batch.

Quando si progetta un'applicazione che usa Batch, è necessario considerare la possibilità che Batch potrebbe non essere disponibile in un'area. È possibile riscontrare una rara situazione in cui si è verificato un problema con l'area nel suo complesso, l'intero servizio Batch nell'area o l'account Batch specifico.

Se l'applicazione o la soluzione che usa Batch deve essere sempre disponibile, deve essere progettata per eseguire il failover in un'altra area o avere sempre il carico di lavoro diviso tra due o più aree. Entrambi gli approcci richiedono almeno due account Batch, che devono essere creati in aree diverse.

Si è responsabili della configurazione del ripristino di emergenza tra aree con Azure Batch. Se si eseguono più account Batch in aree specifiche e si sfruttano le zone di disponibilità, l'applicazione può soddisfare gli obiettivi di ripristino di emergenza quando uno degli account Batch diventa non disponibile.

Quando si fornisce la possibilità di eseguire il failover in un'area alternativa, è necessario considerare tutti i componenti di una soluzione; non è sufficiente avere semplicemente un secondo account Batch. Nella maggior parte delle applicazioni Batch, ad esempio, è necessario un account di archiviazione di Azure. L'account di archiviazione e l'account Batch devono trovarsi nella stessa area per ottenere prestazioni accettabili.

Quando si progetta una soluzione di cui poter eseguire il failover, tenere presente quanto segue:

• Precreare tutti i servizi necessari in ogni area, ad esempio l'account Batch e l'account di archiviazione. Spesso non è previsto alcun addebito per la creazione degli account e gli addebiti si accumulano solo quando viene usato l'account o quando vengono archiviati i dati.

• Assicurarsi che in anticipo siano impostate le quote appropriate per tutti gli account Batch della sottoscrizione utente per allocare il numero di core necessario usando l'account Batch.

• Usare modelli e/o script per automatizzare la distribuzione dell'applicazione in un'area.

• Mantenere costantemente aggiornati i file binari dell'applicazione e i dati di riferimento in tutte le aree. Rimanere aggiornati garantisce che l'area possa essere portata online rapidamente senza dover attendere il caricamento e la distribuzione dei file. Si consideri ad esempio il caso in cui un'applicazione personalizzata da installare nei nodi del pool venga archiviata e a cui viene fatto riferimento usando i pacchetti dell'applicazione Batch. Quando viene rilasciato un aggiornamento dell'applicazione, deve essere caricato in ogni account Batch e a cui fa riferimento la configurazione del pool (o rendere la versione predefinita la versione più recente).

• Nell'applicazione che chiama Batch, archiviazione e qualsiasi altro servizio, semplifica il passaggio dei client o del carico in aree diverse.

• Prendere in considerazione il passaggio frequente a un'area alternativa come parte del normale funzionamento. Ad esempio, con due distribuzioni in aree separate, passare all'area alternativa ogni mese.

La durata del ripristino da un'emergenza dipende dalla configurazione scelta. Batch è indipendente dal fatto che si usino più account o un singolo account. Nelle configurazioni attive-attive, in cui due istanze di Batch ricevono contemporaneamente il traffico, il ripristino di emergenza è più veloce rispetto a una configurazione attiva-passiva. Quale configurazione scegliere deve essere basata sulle esigenze aziendali (aree diverse, requisiti di latenza) e considerazioni tecniche.

Ripristino di emergenza a singola area

Il modo in cui si implementa il ripristino di emergenza in Batch è lo stesso, indipendentemente dal fatto che si stia lavorando in un'area geografica singola o in più aree geografiche. Le uniche differenze sono lo SKU usato per l'archiviazione e se si intende usare lo stesso account di archiviazione o diverso in tutte le aree.

Test di ripristino di emergenza

È consigliabile eseguire test di ripristino di emergenza personalizzati della soluzione abilitata per Batch. È considerata una procedura consigliata per consentire un semplice passaggio tra il carico client e il carico del servizio tra aree diverse.

Il test del piano di ripristino di emergenza per Batch può essere semplice come gli account Batch alternati. Ad esempio, è possibile basarsi su un singolo account Batch in un'area specifica per un giorno operativo. Quindi, il giorno successivo, è possibile passare a un secondo account Batch in un'area diversa. Il ripristino di emergenza viene gestito principalmente sul lato client. Questo approccio a più account per il ripristino di emergenza si occupa delle aspettative RTO e RPO nelle aree geografiche a singola area o a più aree.

Resilienza della capacità e del ripristino di emergenza proattivo

Microsoft e i suoi clienti operano nel modello Di responsabilità condivisa. Microsoft è responsabile della resilienza infrastrutturale e della piattaforma. L'utente è responsabile del ripristino di emergenza per qualsiasi servizio specifico distribuito e controllato. Per assicurarsi che il ripristino sia proattivo:

• È consigliabile predistribuire sempre i database secondari. La pre-distribuzione dei database secondari è necessaria perché non esiste alcuna garanzia di capacità al momento dell'impatto per coloro che non hanno preallocato tali risorse.

• Precreare tutti i servizi necessari in ogni area, ad esempio gli account Batch e gli account di archiviazione associati. Non è previsto alcun addebito per la creazione di nuovi account; gli addebiti si accumulano solo quando l'account viene usato o quando vengono archiviati i dati.

• Assicurarsi che le quote appropriate siano impostate in anticipo su tutte le sottoscrizioni, in modo da poter allocare il numero di core richiesto usando l'account Batch. Come con altri servizi di Azure, sono previsti limiti per determinate risorse associate al servizio Batch. Molti di questi limiti sono quote predefinite applicate da Azure a livello di account o di sottoscrizione. Tenere presenti queste quote quando si progettano i carichi di lavoro di Batch e se ne aumentano le prestazioni.

Nota

Se si prevede di eseguire carichi di lavoro di produzione in Batch, potrebbe essere necessario incrementare il valore predefinito di una o più quote. Per aumentare una quota, è possibile richiedere un aumento della quota senza alcun addebito. Per altre informazioni, vedere Richiedere un aumento della quota.

Storage

È necessario configurare l'archiviazione Batch per assicurarsi che venga eseguito il backup dei dati tra aree; la responsabilità del cliente è l'impostazione predefinita. La maggior parte delle soluzioni Batch usa l'Archiviazione di Azure per archiviare i file delle risorse e i file di output. Ad esempio, le attività di Batch, incluse le attività standard, le attività di avvio, le attività di preparazione del processo e le attività di rilascio del processo, devono specificare in genere file di risorse che si trovano in un account di archiviazione. Gli account di archiviazione archiviano anche i dati elaborati e i dati di output generati. Comprendere le possibili perdite di dati tra le aree delle operazioni del servizio è una considerazione importante. È inoltre necessario verificare se i dati sono riscrivibili o di sola lettura.

Batch supporta i tipi di account di Archiviazione di Azure seguenti:

• Account per utilizzo generico v2 (GPv2)
• Account per utilizzo generico v1 (GPv1)
• Gli account di archiviazione BLOB (attualmente supportati per i pool nella configurazione macchina virtuale)

Per altre informazioni sugli account di archiviazione, vedere Panoramica dell'account di archiviazione di Azure.

È possibile associare un account di archiviazione all'account Batch quando si crea l'account o si esegue questo passaggio in un secondo momento.

Se si configura un account di archiviazione separato per ogni area in cui è disponibile il servizio, è necessario usare gli account di archiviazione con ridondanza della zona. Usare gli account di archiviazione con ridondanza geografica della zona (GZRS) se si usa lo stesso account di archiviazione in più aree abbinate. Per le aree geografiche che contengono una singola area, è necessario creare un account di archiviazione con ridondanza della zona perché L'archiviazione con ridondanza della zona non è disponibile.

La pianificazione della capacità è un'altra considerazione importante per l'archiviazione e deve essere affrontata in modo proattivo. Prendere in considerazione i requisiti relativi a costi e prestazioni durante la scelta di un account di archiviazione. Ad esempio, le opzioni dell'account di archiviazione per utilizzo generico v2 e BLOB supportano limiti di capacità e scalabilità superiori rispetto all'utilizzo generico v1. Contattare il supporto tecnico di Azure per richiedere un incremento del limite di archiviazione. Queste opzioni dell'account possono migliorare le prestazioni delle soluzioni Batch che contengono un numero elevato di attività parallele che leggono da o scrivono nell'account di archiviazione.

Quando un account di archiviazione è collegato a un account Batch, considerarlo come l'account di archiviazione automatica. Se si prevede di usare la funzionalità pacchetti dell'applicazione, è necessario un account di archiviazione automatica, perché viene usato per archiviare il pacchetto dell'applicazione .zip file. È anche possibile usare un account di archiviazione automatica per i file di risorse delle attività. Poiché l'account di archiviazione automatica è già collegato all'account Batch, evita la necessità di URL di firma di accesso condiviso per accedere ai file di risorse.

Passaggi successivi

• Affidabilità in Azure