Replica geografica in PubSub Web di Azure

Le app cruciali spesso devono avere un sistema di failover affidabile e servire gli utenti più vicini alla posizione in cui si trovano. Prima del rilascio della funzionalità di replica geografica, gli sviluppatori dovevano distribuire più risorse Web PubSub e scrivere codice personalizzato per orchestrare la comunicazione tra le risorse. Ora, con la configurazione rapida tramite portale di Azure, è possibile abilitare facilmente questa funzionalità.

Vantaggi dell'uso della replica geografica

• Maggiore resilienza all'interruzione a livello di area: se si verifica un'interruzione a livello di area, i client verranno indirizzati automaticamente a una replica integra.
• Comunicazione tra aree: gli sviluppatori usano una risorsa abilitata per la replica geografica come di consueto, anche se in background sono presenti più di una risorsa. La comunicazione tra repliche viene gestita dal servizio.
• Velocità di rete avanzata: i client distribuiti geograficamente si connetteranno alla replica più vicina. Queste repliche comunicano tramite il backbone della rete globale di Azure, garantendo una rete veloce e stabile.
• Facilità di gestione. Tutte le repliche condividono la configurazione della risorsa Web PubSub primaria.

Prerequisiti

• Una risorsa Web PubSub in livello Premium.

Esempio di caso d'uso

Contoso, una società di social media

Contoso è una società di social media con la sua base di clienti distribuita negli Stati Uniti e in Canada. Contoso fornisce agli utenti un'app Per dispositivi mobili e Web in modo che possano connettersi tra loro. L'applicazione Contoso viene distribuita negli Stati Uniti centrali. Nell'ambito dell'architettura di Contoso, Web PubSub viene usato per stabilire connessioni WebSocket persistenti tra le app client e il server applicazioni. Contoso ama eseguire l'offload della gestione delle connessioni WebSocket a Web PubSub, ma non piace leggere i report degli utenti in Canada riscontrando una latenza più elevata. Inoltre, il team di sviluppo di Contoso vuole assicurare l'app in caso di interruzione a livello di area in modo che gli utenti possano accedere all'app senza interruzioni.

Contoso potrebbe configurare un'altra risorsa Web PubSub in Canada centrale, geograficamente più vicina agli utenti in Canada. Tuttavia, la gestione di più risorse Web PubSub comporta alcune sfide:

1. Un meccanismo di comunicazione tra aree deve essere implementato in modo che gli utenti in Canada e negli Stati Uniti possano interagire tra loro.
2. Il team di sviluppo dovrà gestire due risorse Web PubSub separate, ognuna con dominio distinto e stringa di connessione.
3. Se si verifica un'interruzione a livello di area, il traffico deve essere indirizzato a una risorsa disponibile.

Tutte le risorse di progettazione precedenti si allontanano dall'attenzione all'innovazione del prodotto.

Uso della funzionalità di replica geografica

Con la funzionalità di replica geografica, Contoso può ora stabilire una replica in Canada centrale, superando efficacemente le sfide indicate in precedenza. Il team di sviluppo è lieto di scoprire che non è necessario apportare modifiche al codice. È facile come fare clic su alcuni pulsanti su portale di Azure. Il team di sviluppo è anche felice di condividere con gli stakeholder che, come Contoso intende entrare nel mercato europeo, è sufficiente aggiungere un'altra replica in Europa.

Come abilitare la replica geografica in una risorsa Web PubSub

Portale

Per creare una replica in un'area di Azure, passare alla risorsa Web PubSub e trovare il pannello Repliche nel portale di Azure e fare clic su Aggiungi per creare una replica.

Dopo la creazione, sarà possibile visualizzare o modificare la replica nel portale facendo clic sul nome della replica.

Bicep

Usare Visual Studio Code o l'editor preferito per creare un file con il contenuto seguente e denominarlo main.bicep:

@description('The name for your Web PubSub service')
param primaryName string = 'contoso'

@description('The region in which to create your Web Pubsub service')
param primaryLocation string = 'eastus'

@description('Unit count of your Web PubSub service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/webpubsub@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your Web PubSub replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the Web PubSub replica')
param replicaLocation string = 'westus'

@description('Unit count of the Web PubSub replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/webpubsub/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Distribuire il file Bicep tramite l'interfaccia della riga di comando di Azure

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

CLI

Aggiornare l'estensione webpubsub alla versione più recente, quindi eseguire:

az webpubsub replica create --sku Premium_P1 -l eastus --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Nota

• Il numero di repliche è attualmente limitato a un massimo di 8 per risorsa primaria.

Prezzi e unità di risorse

Ogni replica ha un proprio unit e autoscale settings.

Replica è una funzionalità del livello Premium del servizio Web PubSub di Azure. Ogni replica viene fatturata separatamente in base alla propria unità e al traffico in uscita. La quota di messaggi gratuiti viene calcolata separatamente.

Nell'esempio precedente Contoso ha aggiunto una replica in Canada Centrale. Contoso pagherebbe la replica in Canada Centrale in base all'unità e al messaggio in Premium Price.

Saranno previsti costi in uscita per il traffico in uscita tra aree. Se un messaggio viene trasferito tra repliche e inviato correttamente a un client o a un server dopo il trasferimento, verrà fatturato come messaggio in uscita.

Eliminare una replica

Dopo aver creato una replica per una risorsa Web PubSub, è possibile eliminarla in qualsiasi momento se non è più necessaria.

Per eliminare una replica nel portale di Azure:

1. Passare alla risorsa Web PubSub e selezionare il pannello Repliche. Fare clic sulla replica da eliminare.
2. Fare clic sul pulsante Elimina nel pannello panoramica della replica.

Per eliminare una replica usando l'interfaccia della riga di comando di Azure:

 az webpubsub replica delete --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Informazioni sul funzionamento della funzionalità di replica geografica

1. Il client risolve il nome di dominio completo (FQDN) contoso.webpubsub.azure.com del servizio Web PubSub. Questo FQDN punta a un Gestione traffico, che restituisce il nome canonico (CNAME) dell'istanza Web PubSub più vicina.
2. Con questo CNAME, il client stabilisce una connessione Websocket all'istanza di area (replica).
3. Le due repliche sincronizzano i dati tra loro. I messaggi inviati a una replica verranno trasferiti ad altre repliche, se necessario.
4. Nel caso in cui una replica non riesca il controllo di integrità eseguito dal Gestione traffico (TM), il tm escluderà l'endpoint dell'istanza non riuscita dai risultati della risoluzione del dominio. Per informazioni dettagliate, fare riferimento alla resilienza e al ripristino di emergenza seguenti

Nota

• Nel piano dati, una risorsa Web PubSub di Azure primaria funziona in modo identico alle repliche

---

Resilienza e ripristino di emergenza

Il servizio Web PubSub di Azure usa una gestione traffico per i controlli di integrità e la risoluzione DNS verso le repliche. In circostanze normali, quando tutte le repliche funzionano correttamente, i client verranno indirizzati alla replica più vicina. Ad esempio:

• I client vicini a eastus verranno indirizzati alla replica che si trova in eastus.
• Analogamente, i client vicini a westus verranno indirizzati alla replica in westus.

In caso di interruzione a livello di area in eastus (illustrato di seguito), gestione traffico rileverà l'errore di controllo integrità per tale area. Il DNS di questa replica difettosa verrà quindi escluso dai risultati della risoluzione DNS di Gestione traffico. Dopo una durata TTL (Time-to-Live) DNS, impostata su 90 secondi, i client in eastus verranno reindirizzati per connettersi alla replica in westus.

Una volta risolto il problema in eastus e l'area è di nuovo online, il controllo integrità avrà esito positivo. I client in eastus verranno quindi indirizzati nuovamente alla replica nella propria area. Questa transizione è fluida perché i client connessi non saranno interessati fino alla chiusura di tali connessioni esistenti.

Questo processo di failover e ripristino è automatico e non richiede alcun intervento manuale.

Disabilitare o abilitare l'endpoint di replica

Quando si configura una replica, è possibile abilitare o disabilitare l'endpoint. Se è disabilitato, la risoluzione DNS del nome di dominio completo primario non includerà la replica e pertanto il traffico non verrà indirizzato a esso.

È anche possibile abilitare la disabilitazione dell'endpoint dopo la creazione. Nel pannello repliche della risorsa primaria fare clic sul pulsante con i puntini di sospensione sul lato destro della replica e scegliere Abilita endpoint o Disabilita endpoint:

Prima di eliminare una replica, provare a disabilitare prima il relativo endpoint. Nel corso del tempo, le connessioni esistenti si disconnetteranno. Man mano che non arrivano nuove connessioni, la replica diventa finalmente inattiva. In questo modo si garantisce un processo di eliminazione senza problemi.

Questa funzionalità è utile anche per la risoluzione dei problemi a livello di area.

Nota

• A causa della cache DNS, l'applicazione dell'aggiornamento DNS potrebbe richiedere alcuni minuti.
• Le connessioni esistenti rimangono invariate fino a quando non si disconnettono.

Impatto sulle prestazioni dopo l'abilitazione della funzionalità di replica geografica

Dopo l'abilitazione delle repliche, i client verranno distribuiti naturalmente in base alle posizioni geografiche. Anche se Web PubSub assume la responsabilità di sincronizzare i dati tra queste repliche, si sarà lieti di sapere che il sovraccarico associato sul carico del server è minimo per i casi d'uso più comuni.

In particolare, se l'applicazione trasmette in genere a gruppi più grandi (dimensioni >10) o una singola connessione, l'impatto sulle prestazioni della sincronizzazione è appena evidente. Se si sta messaggindo piccoli gruppi (dimensioni < 10), è possibile notare un sovraccarico di sincronizzazione leggermente maggiore.

Per garantire una gestione efficace del failover, è consigliabile impostare le dimensioni dell'unità di ogni replica per gestire tutto il traffico. In alternativa, è possibile abilitare la scalabilità automatica per gestirla.

Per una valutazione delle prestazioni maggiore, vedere Prestazioni.

Configurazioni non ereditate e ereditate

Le repliche ereditano la maggior parte delle configurazioni dalla risorsa primaria; Tuttavia, alcune impostazioni devono essere configurate direttamente nelle repliche. Di seguito è riportato l'elenco di queste configurazioni:

1. SKU: ogni replica ha il proprio nome SKU e le dimensioni dell'unità. Le regole di scalabilità automatica per le repliche devono essere configurate separatamente in base alle singole metriche.
2. Endpoint privati condivisi: mentre gli endpoint privati condivisi vengono replicati automaticamente nelle repliche, sono necessarie approvazioni separate nelle risorse di collegamento privato di destinazione. Per aggiungere o rimuovere endpoint privati condivisi, gestirli nella risorsa primaria. Non abilitare la replica finché l'endpoint privato condiviso non è stato approvato.
3. Impostazioni destinazione log. Se non è configurato nelle repliche, verranno trasferiti solo i log della risorsa primaria.
4. Avvisi.

Tutte le altre configurazioni vengono ereditate dalla risorsa primaria. Ad esempio, chiavi di accesso, identità, application firewall, domini personalizzati, endpoint privati e controllo di accesso.