Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Gli account di archiviazione funzionano in modo diverso rispetto a molti altri servizi di Azure quando si tratta di configurazioni a disponibilità elevata. Spesso non usano un'istanza secondaria distribuita dal cliente per la resilienza. Gli account di archiviazione configurati per la replica con ridondanza geografica vengono invece replicati in un'altra area, in base alle coppie di aree. Quando necessario, l'account di archiviazione può eseguire il failover su questa copia replicata e operare nell'area secondaria.
Questa funzionalità significa che i clienti non devono pianificare di avere già un secondo account di archiviazione attivo nella loro seconda area. È possibile avere più account di archiviazione e usare le operazioni gestite dal cliente per spostare i dati tra di essi, ma si tratta di un modello non comune.
Quando viene eseguito il failover di un account di archiviazione, il nome del servizio stesso non cambia. Se si usa l'endpoint pubblico per l'ingresso, i sistemi possono usare la stessa risoluzione DNS per accedere al servizio indipendentemente dal relativo stato di failover.
La risoluzione DNS funziona quando sia l'account di archiviazione che i sistemi che accedono ad esso vengono sottoposti a failover. Funziona anche quando è stato eseguito il failover di un solo set di servizi. Questa resilienza riduce il numero di attività BCDR necessarie per l'account di archiviazione.
Se si usano endpoint privati, sono necessarie altre configurazioni per supportare questa funzionalità. Questo articolo fornisce un'architettura di esempio di un account di archiviazione con replica geografica usando endpoint privati per la rete sicura e ciò che è necessario per ogni scenario BCDR.
Annotazioni
Non tutti i tipi di account di archiviazione supportano l'archiviazione con ridondanza geografica (GRS) o l'archiviazione con ridondanza geografica con accesso in lettura (RA-GRS) (RA-GRS). Ad esempio, i data lake distribuiti con blob di blocco Premium possono essere ridondanti localmente o avere ridondanza di zona in una singola regione. Esaminare la ridondanza di Archiviazione di Azure per assicurarsi che lo scenario sia supportato.
Architettura di esempio
Questa architettura usa un'area primaria e secondaria che può essere usata per gestire scenari attivi/attivi o di failover. Ogni area ha una rete hub per l'infrastruttura di rete condivisa. Ogni area ha anche uno spoke in cui vengono distribuiti l'account di archiviazione e altre soluzioni per i carichi di lavoro.
L'account di archiviazione con ridondanza geografica viene distribuito nell'area primaria, ma ha endpoint privati per l'endpoint BLOB in entrambe le aree.
I due endpoint privati non possono usare la stessa zona DNS privata per lo stesso endpoint. Di conseguenza, ogni area usa la propria zona DNS privata. Ogni zona a livello di area è collegata alla rete hub per l'area. Questa progettazione usa lo scenario del server d'inoltro DNS per fornire la risoluzione.
Di conseguenza, indipendentemente dall'area della macchina virtuale che tenta di accedere all'endpoint privato, è disponibile un endpoint locale che può accedere al BLOB di archiviazione, indipendentemente dall'area in cui è attualmente operativo l'account di archiviazione.
Per le connessioni da un data center, viene stabilita una connessione VPN alla rete hub nell'area. Tuttavia, per la risoluzione DNS, ogni data center avrà l'inoltro condizionale configurato su uno dei due set di server DNS resolver, per garantire la risoluzione verso la posizione di rete più vicina.
Concetti relativi all'architettura
Questa architettura utilizza le funzionalità degli endpoint privati che potrebbero non essere comunemente riscontrate nelle distribuzioni in una singola regione.
In primo luogo, un singolo servizio può avere più endpoint privati collegati. Ad esempio, un account di archiviazione potrebbe avere un endpoint privato per i contenitori BLOB che si trovano in più reti virtuali diverse e ognuna funzioni in modo indipendente.
Tuttavia, questo modello non viene usato spesso negli scenari hub-spoke perché una zona DNS privata può avere un solo record per un endpoint privato. Se si registra il primo endpoint privato nella zona DNS privata, altri endpoint privati dovranno usare altre zone.
Inoltre, gli endpoint privati non devono trovarsi nella stessa area della risorsa a cui si connettono. Un account di archiviazione negli Stati Uniti orientali 2 può avere un endpoint privato distribuito negli Stati Uniti centrali, per fornire un esempio.
Fintanto che è presente una zona DNS privata alternativa per quella specifica area, le risorse nella seconda regione possono risolvere e interagire con l'account di archiviazione.
È comune usare endpoint privati che si trovano nella stessa area per ridurre i costi. Tuttavia, quando si considera il failover, questa funzionalità può consentire il funzionamento della rete privata a livello di area nonostante gli errori in un'area.
Costi del traffico tra aree
Esistono costi associati alla presenza di endpoint privati in più aree. Prima di tutto, è previsto un costo per endpoint privato. Il design precedente avrebbe due endpoint e perciò sarebbe addebitato due volte. Inoltre, è previsto un costo per l'invio del traffico tra aree. Per altre informazioni sui costi degli endpoint privati, vedere Prezzi di Collegamento privato di Azure.
Il peering di rete virtuale globale è un servizio che connette reti virtuali in più aree. Include anche un costo di trasferimento dei dati tra aree. Questo costo dipende dalla zona in cui si trovano le reti. Per altre informazioni sui costi di rete, vedere Prezzi della rete virtuale.
Il peering globale può essere usato per consentire ai servizi di comunicare tra loro durante un errore del servizio in un'area. Tuttavia, supporta un minor numero di scenari e potrebbe avere più attività manuali coinvolte nell'attivazione di un failover. Un'organizzazione deve esaminare i costi di funzionamento in un'architettura a disponibilità elevata o resiliente e confrontarlo con i rischi di durate più lunghe per il ripristino del servizio.
Scenari di failover
Questa topologia supporta gli scenari seguenti e ogni scenario ha le proprie considerazioni per il failover DNS.
| Sceneggiatura | Descrizione | Considerazioni sul DNS |
|---|---|---|
| Scenario 1 - Ripristino dell'account di archiviazione | Un'interruzione del servizio per l'account di archiviazione ospitato nell'area primaria richiede che venga eseguito il failover in un'area secondaria. | Nessuna modifica necessaria. |
| Scenario 2 - Failover di altri servizi | In caso di interruzione dei servizi nella regione primaria, è necessario eseguire il failover verso una regione secondaria. Non è necessario eseguire il failover dell'account di archiviazione. | Se l'interruzione influisce sui server DNS ospitati nell'area primaria, i server d'inoltro condizionale dall'ambiente locale devono essere aggiornati all'area secondaria. |
| Scenario 3 - Interruzione della regione intera | Per un'interruzione del servizio a più servizi in un'area è necessario eseguire il failover sia dell'account di archiviazione che di altri servizi. | I server d'inoltro condizionale dal DNS locale devono essere aggiornati all'area secondaria. |
| Scenario 4 - Esecuzione in disponibilità elevata | I servizi e gli account di archiviazione funzionano in Azure in una configurazione attiva/attiva. | Se è interessato il DNS o l'account di archiviazione di un'area, i server d'inoltro condizionale locali devono essere aggiornati alle aree operative. |
Scenario 1 - Failover del conto di archiviazione
In questo scenario, un problema con l'account di archiviazione richiede che venga eseguito il failover nelle aree secondarie. Con gli account di archiviazione con ridondanza della zona e con ridondanza geografica, queste interruzioni non sono comuni, ma devono comunque essere pianificate.
Quando viene eseguito il failover dell'account di archiviazione nell'area secondaria associata, il routing di rete rimane invariato. Non sono necessarie modifiche al DNS. Ogni area può continuare a usare l'endpoint locale per comunicare con l'account di archiviazione.
Anche le connessioni da un data center locale connesso tramite VPN continueranno a funzionare. Ogni endpoint può rispondere alle connessioni indirizzate verso di esso, ed entrambe le reti hub sono in grado di risolvere verso un endpoint valido.
Dopo il failover, il servizio funzionerà come illustrato:
Quando il servizio viene ripristinato nell'area primaria, è possibile eseguire il failback dell'account di archiviazione.
Scenario 2: failover di altri servizi
In questo scenario si verifica un problema con i servizi che si connettono all'account di archiviazione. Nell'ambiente, si tratta di macchine virtuali, ma potrebbero essere servizi applicativi o altri servizi.
Queste risorse devono essere sottoposte a failover nell'area secondaria seguendo il proprio processo. Le macchine virtuali possono usare Azure Site Recovery per replicare le macchine virtuali prima dell'interruzione oppure distribuire una nuova istanza dell'app Web nell'area secondaria.
Quando i servizi sono attivi nell'area secondaria, possono iniziare a connettersi all'account di archiviazione tramite l'endpoint a livello di area. Non sono necessarie modifiche per supportare le connessioni.
Le connessioni da un data center locale connesso tramite VPN continueranno a funzionare finché l'interruzione del servizio non influisce sui servizi di risoluzione DNS nell'hub. Se l'hub è disabilitato, ad esempio a causa di un'interruzione del servizio vm, i server d'inoltro condizionale nel data center devono essere modificati in modo da puntare all'area secondaria fino al ripristino del servizio.
Dopo il failover, il servizio funzionerà come illustrato:
Quando il servizio viene ripristinato nell'area primaria, è possibile eseguire il failback dei servizi e la reimpostazione DNS locale.
Annotazioni
Se è sufficiente connettersi all'account di archiviazione dall'ambiente locale per le attività amministrative, è possibile usare una jump box nell'area secondaria anziché aggiornare IL DNS nell'area primaria. IL DNS locale deve essere aggiornato solo se è necessaria una connessione diretta all'account di archiviazione dai sistemi locali.
Scenario 3 - Interruzione dell'intera regione
In questo scenario si verifica un'interruzione regionale di ampia portata, che richiede il failover sia dell'account di archiviazione che di altri servizi.
Questo failover funziona come una combinazione di Scenario 1 e Scenario 2. L'account di archiviazione viene trasferito al failover, così come i servizi di Azure. L'area primaria non è in grado di funzionare, ma i servizi possono continuare a funzionare nell'area secondaria fino a quando il servizio non viene ripristinato.
Analogamente allo scenario 2, se l'hub primario non è in grado di gestire le risposte DNS al relativo endpoint o ci sono altre interruzioni di rete, i server d'inoltro condizionale in locale devono essere aggiornati all'area secondaria.
Dopo il failover, il servizio funzionerà come illustrato:
Quando i servizi vengono ristabiliti, è possibile riportare le risorse allo stato originale e reimpostare il DNS locale alla sua impostazione originale.
Scenario 4: esecuzione a disponibilità elevata
In questo scenario il carico di lavoro è in esecuzione in modalità attiva/attiva. Sono in esecuzione risorse di calcolo sia nell'area primaria che secondaria e i client si connettono a entrambe le aree in base alle regole di bilanciamento del carico.
In questo contesto, entrambi i servizi possono comunicare con l'account di archiviazione tramite i loro endpoint privati regionali. Consulta Statistiche di latenza di rete Azure andata e ritorno per esaminare la latenza tra regioni.
In caso di interruzione a livello di area, il front-end di bilanciamento del carico deve reindirizzare tutto il traffico dell'applicazione all'area attiva.
Per la connettività dal data center on-premises, se l'interruzione influisce sul DNS o sull'account di archiviazione di una regione, i server di inoltro condizionale del data center devono essere impostati su regioni che sono ancora disponibili. Questa modifica non influisce sui servizi di Azure.
Mentre entrambe le aree sono integre, il servizio funziona come illustrato:
Passaggi successivi
Nell'ambito della pianificazione della resilienza dell'account di archiviazione, è possibile consultare gli articoli seguenti per altre informazioni: