Replica geografica in Azure SignalR

Le aziende che cercano la presenza locale o richiedono un sistema di failover affidabile spesso scelgono di distribuire servizi in più aree di Azure. Con l'integrazione della replica geografica in Azure SignalR, la gestione di scenari in più aree è diventata notevolmente più semplice.

Vantaggi dell'uso della replica geografica

• Maggiore resilienza all'interruzione a livello di area: se si verifica un'interruzione a livello di area, il DNS di Azure SignalR verrà risolto in repliche integre in altre aree.
• Comunicazione tra aree. Le repliche diverse possono comunicare tra loro come se fossero la stessa istanza.
• 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.
• Configurazioni condivise. Tutte le repliche mantengono la configurazione della risorsa Servizio Azure SignalR primaria.

Prerequisiti

• Un Servizio Azure SignalR nel livello Premium.

Esempio di caso d'uso

Contoso è una società di social media con la sua base di clienti distribuita negli Stati Uniti e in Canada. Per servire questi clienti e consentire loro di comunicare tra loro, Contoso esegue i servizi negli Stati Uniti centrali. Servizio Azure SignalR viene usato per gestire le connessioni utente e facilitare la comunicazione tra gli utenti. Gli utenti finali di Contoso sono principalmente utenti telefonici. A causa delle lunghe distanze geografiche, gli utenti finali in Canada potrebbero riscontrare una latenza elevata e una scarsa qualità della rete.

Prima dell'avvento della funzionalità di replica geografica, Contoso potrebbe configurare un altro Servizio Azure SignalR in Canada centrale per servire gli utenti canadesi. Configurando un Servizio Azure SignalR geograficamente più vicino, gli utenti finali hanno ora una migliore qualità di rete e una latenza inferiore.

Tuttavia, la gestione di più Servizio Azure SignalR comporta alcune sfide:

1. Sarebbe necessario un meccanismo di comunicazione tra aree per abilitare la conversazione tra canada e utenti degli Stati Uniti.
2. Il team di sviluppo dovrà gestire due Servizio Azure SignalR separate, ognuna con dominio distinto e stringa di connessione.
3. Se si verifica un'interruzione a livello di area, il traffico deve essere passato a un'altra area.

Uso della replica geografica

Con la nuova funzionalità di replica geografica, Contoso può ora stabilire una replica in Canada centrale, superando efficacemente gli ostacoli indicati sopra.

Creare una replica SignalR

Portale

Per creare una replica, passare al pannello Repliche SignalR nel portale di Azure e fare clic su Aggiungi per creare una replica. Verrà abilitato automaticamente al momento della creazione.

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 SignalR service')
param primaryName string = 'contoso'

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

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

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

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

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

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

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

resource replica 'Microsoft.SignalRService/signalr/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

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 di Servizio Azure SignalR. 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 il Servizio Azure SignalR, è possibile eliminarla in qualsiasi momento, se non è più necessaria.

Per eliminare una replica nel portale di Azure:

1. Passare al Servizio Azure SignalR e selezionare Il pannello Repliche. Fare clic sulla replica da eliminare.
2. Fare clic sul pulsante Elimina nel pannello panoramica della replica.

Informazioni sul funzionamento della replica SignalR

Il diagramma seguente fornisce una breve illustrazione delle funzionalità delle repliche SignalR:

1. Il client negozia con il server app e riceve un reindirizzamento al servizio Azure SignalR. Risolve quindi il nome di dominio completo (FQDN) del servizio SignalR : contoso.service.signalr.net. Questo FQDN punta a un Gestione traffico, che restituisce il nome canonico (CNAME) dell'istanza signalR regionale più vicina.
2. Con questo CNAME, il client stabilisce una connessione 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 dal processo di risoluzione del dominio. Per informazioni dettagliate, fare riferimento alla resilienza e al ripristino di emergenza seguenti

Nota

• Nel piano dati, una risorsa azure SignalR primaria funziona in modo identico alle repliche

Resilienza e ripristino di emergenza

Servizio Azure SignalR utilizza una gestione traffico per i controlli di integrità e la risoluzione DNS verso le relative 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.

Per le connessioni server, il failover e il ripristino funzionano allo stesso modo delle connessioni client.

Nota

• Questo meccanismo di failover è per il servizio Azure SignalR. Le interruzioni a livello di area del server app non rientrano nell'ambito di questo documento.

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'aggiornamento DNS potrebbe richiedere alcuni minuti.
• Le connessioni esistenti rimangono invariate fino a quando non si disconnettono.

Impatto sulle prestazioni dopo l'aggiunta di repliche

Dopo l'abilitazione delle repliche, i client verranno distribuiti naturalmente in base alle posizioni geografiche. Anche se SignalR 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) o singoli utenti, è 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.