Replica geografica in Azure Web PubSub

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 alle interruzioni a livello di area: in caso di 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 apprezza di poter affidare la gestione delle connessioni WebSocket a Web PubSub, ma non gradisce leggere segnalazioni secondo cui gli utenti in Canada riscontrano 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.

Tutto quanto sopra distoglie le risorse ingegneristiche dal concentrarsi sull’innovazione di 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

@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
  }
}

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

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

Prezzi e unità di risorse

Ogni replica ha un propriounit 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 per la replica in Canada centrale in base al prezzo Premium per unità e per messaggio.

Saranno previsti costi per il traffico in uscita tra regioni. 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 regionale più vicina.
2. Con questo CNAME, il client stabilisce una connessione WebSocket all'istanza regionale (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 superi il controllo di integrità eseguito da Traffic Manager (TM), il TM escluderà l'endpoint dell'istanza non funzionante dai risultati di risoluzione del nome di dominio. Per informazioni dettagliate, fare riferimento alla resilienza e al ripristino di emergenza seguenti

Resilienza e ripristino di emergenza

Il servizio Azure Web PubSub utilizza un gestore del traffico per i controlli di integrità e la risoluzione DNS per le proprie 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 regionale in eastus (illustrata di seguito), Gestione traffico rileverà l'errore del controllo di 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 una volta che l'area geografica sarà di nuovo online, il controllo di integrità avrà esito positivo. I client in eastus verranno quindi indirizzati, ancora una volta, 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. Nella scheda Repliche della risorsa primaria fare clic sul pulsante con i puntini di sospensione a destra 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.

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

Una volta abilitate le repliche, i client si distribuiranno naturalmente in base alla loro posizione geografica. 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 invii messaggi a piccoli gruppi (dimensione < 10), potresti notare un sovraccarico di sincronizzazione leggermente più elevato.

Per garantire una gestione efficace del failover, si consiglia di impostare la dimensione dell'unità di ciascuna replica in modo da gestire tutto il traffico. In alternativa, è possibile abilitare la scalabilità automatica per gestirla.

Per una valutazione delle prestazioni maggiore, vedere Prestazioni.

Configurazioni non ereditarie ed ereditarie

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: sebbene gli endpoint privati condivisi vengano replicati automaticamente nelle repliche, sono necessarie approvazioni separate per le risorse Private Link di destinazione. Per aggiungere o rimuovere endpoint privati condivisi, gestiscili nella risorsa primaria. Non abilitare la replica finché l'endpoint privato condiviso non viene approvato.
3. Impostazioni della destinazione dei 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.