Creare attività di replica per le risorse di Azure usando App per la logica di Azure (anteprima)
Importante
Questa funzionalità è in anteprima ed è soggetta alle Condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure.
Sebbene la disponibilità e l'affidabilità massime siano le principali priorità operative per i servizi di Azure, esistono ancora molti modi per arrestare la comunicazione a causa di problemi di rete o risoluzione dei nomi, errori o mancata risposta temporanea. Tali condizioni non tali da far desiderare di abbandonare completamente la distribuzione a livello di area, come si potrebbe fare in una situazione di ripristino di emergenza. Tuttavia, lo scenario aziendale per alcune app potrebbe essere influenzato dagli eventi di disponibilità che durano non più di alcuni minuti o addirittura secondi.
Per ridurre l'effetto che gli eventi imprevedibili possono avere sulle risorse di Azure in un'area di Azure, è possibile replicare il contenuto in queste risorse da un'area a un'altra in modo da mantenere la continuità aziendale. In Azure è possibile creare un'attività di replica che sposta i dati, gli eventi o i messaggi da un'origine in un'area a una destinazione in un'altra area. In questo modo, è possibile avere la destinazione prontamente disponibile se l'origine passa allo stato offline e la destinazione deve assumere il controllo.
Nota
È anche possibile usare le attività di replica per spostare il contenuto tra entità nella stessa area; tuttavia, se l'intera area diventa non disponibile o si verifica un'interruzione, sia l'origine che la destinazione sono interessate.
Questo articolo offre una panoramica delle attività di replica basate su App per la logica di Azure e illustra come creare un'attività di replica di esempio per le code del bus di servizio di Azure. Se non si ha familiarità con le app per la logica e i flussi di lavoro, vedere Che cos'è App per la logica di Azure e Single-Tenant rispetto a multi-tenant in App per la logica di Azure.
Cosa è un'attività di replica?
In genere, un'attività di replica riceve dati, eventi o messaggi da un'origine, sposta il contenuto in una destinazione e quindi elimina il contenuto dall'origine, tranne quando la suddetta è un'entità di Hub eventi. L'attività di replica sposta in genere il contenuto invariato, ma anche le attività di replica basate su App per la logica di Azure aggiungono proprietà di replica. Se i protocolli di origine e di destinazione differiscono, queste attività eseguono anche mapping tra strutture di metadati. Le attività di replica sono senza stato, ovvero non condividono stati o altri effetti collaterali tra esecuzioni parallele o sequenziali di un'attività.
Quando si usano i modelli di attività di replica disponibili, ogni attività di replica creata ha un flusso di lavoro senza stato sottostante in una risorsa dell'App per la logica (Standard), che può includere più flussi di lavoro per le attività di replica. Questa risorsa è ospitata in App per la logica di Azure a tenant singolo, che è un ambiente di esecuzione scalabile e affidabile per la configurazione e l'esecuzione di applicazioni serverless, incluse le attività di replica e federazione. Il runtime di App per la logica di Azure a tenant singolo usa anche il modello di estendibilità di Funzioni di Azure ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e più prestazioni per il flussi di lavoro delle app per la logica, oltre ad altre funzionalità e vantaggi ereditati dalla piattaforma Funzioni di Azure e dall'ecosistema del Servizio app di Azure.
Per altre informazioni sulla replica e sulla federazione, vedere la documentazione seguente:
- Federazione multi-sito e multi-area di Hub eventi
- Modelli di attività di replica di eventi
- Replica di messaggi e federazione tra aree di Bus di servizio
- Modelli di attività di replica di messaggi
Modelli di attività di replica
Attualmente, i modelli di attività di replica sono disponibili per Hub eventi di Azure e il Bus di servizio di Azure. La tabella seguente elenca i modelli di attività di replica attualmente disponibili in questa anteprima:
| Tipo di risorsa | L'origine e la destinazione della replica |
|---|---|
| Spazio dei nomi di Hub eventi di Azure | - Da istanza di Hub eventi a istanza di Hub eventi - Da istanza di Hub eventi alla coda del Bus di servizio - Da istanza di Hub eventi all'argomento del Bus di servizio |
| Spazio dei nomi del bus di servizio di Azure | - Da coda del Bus di servizio a coda del Bus di servizio - Da coda del Bus di servizio ad argomento del Bus di servizio - Da argomento del Bus di servizio a argomento del Bus di servizio - Da coda del bus di servizio a istanza di Hub eventi - Da argomento del Bus di servizio alla coda del Bus di servizio - Da argomento del Bus di servizio a istanza di Hub eventi Importante: quando una coda è l'origine, un'attività di replica non copia i messaggi ma li sposta dall'origine alla destinazione e li elimina dall'origine. Per eseguire il mirroring dei messaggi, usare invece un argomento come origine in cui la sottoscrizione "principale" funge da endpoint della coda. In questo modo, la destinazione ottiene una copia di ogni messaggio dall'origine. Per instradare i messaggi tra aree diverse, è possibile creare una coda in cui i messaggi vengono inviati da un'app. L'attività di replica trasferisce i messaggi da tale coda a una coda di destinazione in uno spazio dei nomi che si trova in un'altra area. È anche possibile usare una sottoscrizione di argomento come entità che funge da coda di trasferimento. Per altre informazioni, vedere Topologia di replica per ServiceBusCopy. |
Topologia di replica e flusso di lavoro
Per visualizzare il funzionamento di un'attività di replica basata su App per la logica di Azure (Standard), i diagrammi seguenti illustrano la struttura delle attività di replica e il flusso di lavoro per le istanze di Hub eventi e per le code del Bus di servizio.
Topologia di replica per Hub eventi
Il diagramma seguente illustra il flusso di lavoro delle attività di topologia e replica tra le istanze di Hub eventi:
Per informazioni sulla replica e sulla federazione in Hub eventi di Azure, vedere la documentazione seguente:
Topologia di replica per il Bus di servizio
Il diagramma seguente illustra il flusso di lavoro dell'attività di topologia e replica tra le code del Bus di servizio:
Per informazioni sulla replica e sulla federazione nel Bus di servizio di Azure, vedere la documentazione seguente:
- Replica di messaggi e federazione tra aree di Bus di servizio
- Modelli di attività di replica di messaggi
Mapping di metadati e proprietà
Per Hub eventi, gli elementi seguenti ottenuti dallo spazio dei nomi di Hub eventi di origine vengono sostituiti da nuovi valori assegnati dal servizio nello spazio dei nomi di Hub eventi di destinazione: metadati assegnati dal servizio di un evento, ora di accodamento originale, numero di sequenza e offset. Tuttavia, per le funzioni helper e le attività di replica negli esempi forniti da Azure, i valori originali vengono mantenuti nelle proprietà utente: repl-enqueue-time(ISO8601 stringa), repl-sequence e repl-offset. Queste proprietà hanno il tipo string e contengono il valore stringato delle rispettive proprietà originali. Se l'evento viene inoltrato più volte, i metadati assegnati dal servizio dell'origine immediata vengono accodati a qualsiasi proprietà esistente, con valori separati da punti e virgola. Per altre informazioni, vedere Metadati assegnati dal servizio - Modelli di attività di replica degli eventi.
Per il Bus di servizio, gli elementi seguenti ottenuti dalla coda o dall'argomento del bus di servizio di origine vengono sostituiti da nuovi valori assegnati dal servizio nella coda o nell'argomento del Bus di servizio di destinazione: metadati assegnati al servizio di un messaggio, ora di accodamento originale e numero di sequenza. Tuttavia, per le attività di replica predefinite negli esempi forniti da Azure, i valori originali vengono mantenuti nelle proprietà utente: repl-enqueue-time (ISO8601 stringa) e repl-sequence. Queste proprietà hanno il tipo string e contengono il valore stringato delle rispettive proprietà originali. Se il messaggio viene inoltrato più volte, i metadati assegnati dal servizio dell'origine immediata vengono accodati a qualsiasi proprietà esistente, con valori separati da punti e virgola. Per altre informazioni, vedere Metadati assegnati al servizio - Modelli di attività di replica dei messaggi.
Quando un'attività viene replicata dal bus di servizio a Hub eventi, l'attività esegue il mapping solo della proprietà User Properties alla proprietà Properties. Tuttavia, quando l'attività viene replicata da Hub eventi al Bus di servizio, l'attività esegue il mapping delle proprietà seguenti:
| Da Hub eventi | Al Bus di servizio |
|---|---|
| ContentType | ContentType |
| CorrelationId | CorrelationId |
| MessageId | MessageId |
| PartitionKey | PartitionKey SessionId |
| Proprietà | Proprietà utente |
| ReplyTo | ReplyTo |
| ReplyToGroupName | ReplyToSessionId |
| Oggetto | Etichetta |
| Per | Per |
Conservazione dell'ordine
Per Hub eventi, la replica tra lo stesso numero di partizioni crea cloni 1:1 senza modifiche negli eventi, ma può includere anche duplicati. Tuttavia, nella replica tra diversi numeri di partizioni, solo l'ordine relativo degli eventi viene mantenuto in base alla chiave di partizione, ma può anche includere duplicati. Per altre informazioni, vedere Flussi e conservazione degli ordini.
Per il Bus di servizio, è necessario abilitare le sessioni in modo che le sequenze di messaggi con lo stesso ID sessione recuperato dall'origine vengano inviate alla coda o all'argomento di destinazione come batch nella sequenza originale e con lo stesso ID sessione. Per altre informazioni, vedere Sequenze e conservazione degli ordini.
Importante
Le attività di replica non tengono traccia dei messaggi già elaborati quando l'origine presenta un evento di interruzione. Per impedire la rielaborazione dei messaggi già elaborati, è necessario configurare un modo per tenere traccia dei messaggi già elaborati in modo che l'elaborazione venga ripresa solo con i messaggi non elaborati.
Ad esempio, è possibile configurare un database che archivia lo stato di elaborazione per ogni messaggio. Quando arriva un messaggio, controllare lo stato e l'elaborazione del messaggio solo quando il messaggio non è elaborato. In questo modo, non viene eseguita alcuna elaborazione per un messaggio già elaborato.
Questo modello illustra il concetto di idempotenza in cui la ripetizione di un'azione su un input produce lo stesso risultato senza altri effetti collaterali o non modificherà il valore dell'input.
Per altre informazioni sulla federazione multi-sito e su più aree per i servizi di Azure in cui è possibile creare attività di replica, vedere la documentazione seguente:
- Federazione multi-sito e multi-area di Hub eventi
- Modelli di attività di replica di eventi
- Replica di messaggi e federazione tra aree di Bus di servizio
- Modelli di attività di replica di messaggi
Prezzi
Di seguito, un'attività di replica è basata su un flusso di lavoro senza stato in una risorsa dell'App per la logica (Standard) ospitata in App per la logica di Azure a tenant singolo. Quando si crea questa attività di replica, gli addebiti iniziano a essere applicati immediatamente. Utilizzo, misurazione, fatturazione e modello tariffario seguono il piano di hosting Standard e i piani tariffari standard.
In base al numero di eventi che Hub eventi riceve o messaggi gestiti dal Bus di servizio, il piano di hosting potrebbe aumentare o ridurre le prestazioni per mantenere l'utilizzo minimo di vCPU e bassa latenza durante la replica attiva. Quando si crea una risorsa dell'app per la logica da usare per l'attività di replica, questo comportamento richiede di scegliere il piano tariffario Standard appropriato in modo che App per la logica di Azure non limiti o inizi a limitare l'utilizzo della CPU e possa comunque garantire velocità di replica rapida.
Nota
Se l'app inizia con un'istanza del piano WS1 e quindi aumenta il numero di istanze, il costo è il doppio del costo di WS1, presupponendo che i piani vengano eseguiti tutto il giorno. Se si aumentano le prestazioni dell'app al piano WS2 e si usa un'istanza, il costo è effettivamente uguale a due istanze del piano WS1. Analogamente, se si aumentano le prestazioni dell'app al piano WS3 e si usa un'istanza, il costo è lo stesso di due istanze del piano WS2 o quattro istanze del piano WS1.
Gli esempi seguenti illustrano il piano tariffario di hosting e le opzioni di configurazione che offrono la velocità effettiva e il costo migliori per scenari di attività di replica specifici, in base al fatto che lo scenario sia Hub eventi o Bus di servizio e vari valori di configurazione.
Nota
Gli esempi nelle sezioni seguenti usano 800 come valore predefinito per il numero di preletture, le dimensioni massime del batch di eventi per Hub eventi e il numero massimo di messaggi per il Bus di servizio, presupponendo che la dimensione dell'evento o del messaggio sia di 1 KB. In base alle dimensioni degli eventi, è possibile modificare il numero di preletture, le dimensioni massime del batch di eventi o il numero massimo di messaggi. Ad esempio, se le dimensioni degli eventi o dei messaggi superano i 1 KB, è possibile ridurre i valori per il numero di preletture e il numero massimo di batch di eventi o messaggi da 800.
Scale-out di Hub eventi
Gli esempi seguenti illustrano il piano tariffario di hosting e le opzioni di configurazione per un'attività di replica tra due spazi dei nomi di Hub eventi nella stessa area, in base al numero di partizioni, al numero di eventi al secondo e ad altri valori di configurazione.
Gli esempi in questa sezione usano 800 come valore predefinito per il numero di preletture e le dimensioni massime del batch di eventi, presupponendo che le dimensioni dell'evento siano pari a 1 KB. In base alle dimensioni degli eventi, è possibile modificare il numero di preletture e le dimensioni massime del batch di eventi. Ad esempio, se le dimensioni dell'evento sono superiori a 1 KB, è possibile ridurre i valori per il numero di preletture e le dimensioni massime del batch di eventi da 800.
| Piano tariffario | Numero di partizioni | Eventi al secondo | Picchi massimi* | Istanze sempre pronte* | Numero preletture* | Dimensioni massime del batch di eventi* |
|---|---|---|---|---|---|---|
| WS1 | 1 | 1000 | 1 | 1 | 800 | 800 |
| WS1 | 2 | 2000 | 1 | 1 | 800 | 800 |
| WS2 | 4 | 4000 | 2 | 1 | 800 | 800 |
| WS2 | 8 | 8000 | 2 | 1 | 800 | 800 |
| WS3 | 16 | 16000 | 2 | 1 | 800 | 800 |
| WS3 | 32 | 32000 | 3 | 1 | 800 | 800 |
* Per altre informazioni sui valori che è possibile modificare per ogni piano tariffario, vedere la tabella seguente:
| valore | Descrizione |
|---|---|
| Picchi massimi | Numero massimo di ruoli di lavoro elastici da aumentare in base al carico. Se l'app sottostante richiede istanze oltre le istanze sempre pronte nella riga di tabella successiva, l'app può proseguire con l'aumento fino a quando il numero di istanze raggiunge il limite massimo di burst. Per modificare questo valore, vedere Modificare le impostazioni di scale-out del piano di hosting più avanti in questo articolo. Nota: le istanze oltre le dimensioni del piano vengono fatturate solo quando vengono eseguite e allocate all'utente in base al secondo. La piattaforma fa quanto possibile per aumentare il numero di istanze dell'app fino al limite massimo definito. Suggerimento: come raccomandazione, selezionare un valore massimo superiore a quello che potrebbe essere necessario in modo che la piattaforma possa eseguire l'aumento per gestire un carico maggiore, se necessario, in quanto le istanze inutilizzate non vengono fatturate. Per altre informazioni, vedere la documentazione seguente, perché il piano Flusso di lavoro Standard condivide alcuni aspetti con il piano Premium di Funzioni di Azure: - Impostazioni di piano e SKU - Piano Premium di Funzioni di Azure |
| Istanze sempre pronte | Numero minimo di istanze sempre pronte e calde per l'hosting dell'app. Il numero minimo è sempre 1. Per modificare questo valore, vedere Modificare le impostazioni di scale-out del piano di hosting più avanti in questo articolo. Nota: tutte le istanze oltre le dimensioni del piano vengono fatturate indipendentemente dal fatto che siano in esecuzione quando vengono allocate all'utente. Per altre informazioni, vedere la documentazione seguente, perché il piano Workflow Standard condivide alcuni aspetti con il piano Funzioni di Azure Premium: Istanze sempre pronte - Piano Premium di Funzioni di Azure. |
| Numero preletture | Valore predefinito per l'impostazione dell'app AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__prefetchCount nella risorsa dell'app per la logica che determina il conteggio di prelettura usato dalla classe sottostante EventProcessorHost. Per aggiungere o specificare un valore diverso per questa impostazione dell'app, vedere Gestire le impostazioni dell'app - local.settings.json, ad esempio: - Nome: Per altre informazioni sulla proprietà - impostazioni host.json - Trigger e associazioni di Hub eventi di Azure per Funzioni di Azure |
| Dimensioni massime del batch di eventi | Valore predefinito per l'impostazione dell'app AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__maxBatchSize nella risorsa dell'app per la logica che determina il numero massimo di eventi ricevuti da ogni ciclo di ricezione. Per aggiungere o specificare un valore diverso per questa impostazione dell'app, vedere Gestire le impostazioni dell'app - local.settings.json, ad esempio: - Nome: Per altre informazioni sulla proprietà - impostazioni host.json - Trigger e associazioni di Hub eventi di Azure per Funzioni di Azure |
Scale Out del Bus di servizio
Gli esempi seguenti illustrano il piano tariffario di hosting e le opzioni di configurazione per un'attività di replica tra due spazi dei nomi del Bus di servizio nella stessa area, in base al numero di messaggi al secondo e ad altri valori di configurazione.
Gli esempi in questa sezione usano 800 come valore predefinito per il numero di preletture e il numero massimo di messaggi, presupponendo che le dimensioni del messaggio siano pari a 1 KB. In base alle dimensioni dei messaggi, è possibile modificare il numero di preletture e il numero massimo di messaggi. Ad esempio, se la dimensione del messaggio è superiore a 1 KB, è possibile ridurre i valori per il numero di preletture e il numero massimo di messaggi da 800.
| Piano tariffario | Messaggi al secondo | Picchi massimi* | Istanze sempre pronte* | Numero preletture* | Numero massimo di messaggi* |
|---|---|---|---|---|---|
| WS1 | 2000 | 1 | 1 | 800 | 800 |
| WS2 | 2500 | 1 | 1 | 800 | 800 |
| WS3 | 3500 | 1 | 1 | 800 | 800 |
* Per altre informazioni sui valori che è possibile modificare per ogni piano tariffario, vedere la tabella seguente:
| valore | Descrizione |
|---|---|
| Picchi massimi | Numero massimo di ruoli di lavoro elastici da aumentare in base al carico. Se l'app sottostante richiede istanze oltre le istanze sempre pronte nella riga di tabella successiva, l'app può proseguire con l'aumento fino a quando il numero di istanze raggiunge il limite massimo di burst. Per modificare questo valore, vedere Modificare le impostazioni di scale-out del piano di hosting più avanti in questo articolo. Nota: le istanze oltre le dimensioni del piano vengono fatturate solo quando vengono eseguite e allocate all'utente in base al secondo. La piattaforma fa quanto possibile per aumentare il numero di istanze dell'app fino al limite massimo definito. Suggerimento: come raccomandazione, selezionare un valore massimo superiore a quello che potrebbe essere necessario in modo che la piattaforma possa eseguire l'aumento per gestire un carico maggiore, se necessario, in quanto le istanze inutilizzate non vengono fatturate. Per altre informazioni, vedere la documentazione seguente, perché il piano Flusso di lavoro Standard condivide alcuni aspetti con il piano Premium di Funzioni di Azure: - Impostazioni di piano e SKU - Piano Premium di Funzioni di Azure |
| Istanze sempre pronte | Numero minimo di istanze sempre pronte e calde per l'hosting dell'app. Il numero minimo è sempre 1. Per modificare questo valore, vedere Modificare le impostazioni di scale-out del piano di hosting più avanti in questo articolo. Nota: tutte le istanze oltre le dimensioni del piano vengono fatturate indipendentemente dal fatto che siano in esecuzione quando vengono allocate all'utente. Per altre informazioni, vedere la documentazione seguente, perché il piano Workflow Standard condivide alcuni aspetti con il piano Funzioni di Azure Premium: Istanze sempre pronte - Piano Premium di Funzioni di Azure. |
| Numero preletture | Valore predefinito per l'impostazione dell'app AzureFunctionsJobHost__extensions__serviceBus__prefetchCount nella risorsa dell'app per la logica che determina il conteggio di prelettura usato dalla classe sottostante ServiceBusProcessor. Per aggiungere o specificare un valore diverso per questa impostazione dell'app, vedere Gestire le impostazioni dell'app - local.settings.json, ad esempio: - Nome: Per altre informazioni sulla proprietà - impostazioni di host.json - Associazioni del Bus di servizio di Azure per Funzioni di Azure |
| Numero massimo di messaggi | Valore predefinito per l'impostazione dell'app AzureFunctionsJobHost__extensions__serviceBus__batchOptions__maxMessageCount nella risorsa dell'app per la logica che determina il numero massimo di messaggi da inviare quando viene attivato. Per aggiungere o specificare un valore diverso per questa impostazione dell'app, vedere Gestire le impostazioni dell'app - local.settings.json, ad esempio: - Nome: Per altre informazioni sulla proprietà |
Prerequisiti
Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.
Le risorse o le entità di origine e di destinazione, che devono esistere in aree di Azure diverse, in modo da poter testare lo scenario di failover di ripristino di emergenza geografico. Queste entità possono variare in base al modello di attività che si vuole usare. L'esempio in questo articolo usa due code del Bus di servizio, che si trovano in spazi dei nomi e aree di Azure diverse.
Una risorsa dell'App per la logica (Standard) che è possibile riutilizzare quando si crea l'attività di replica. In questo modo, è possibile personalizzare questa risorsa specificamente per l'attività di replica, ad esempio scegliendo il piano di hosting e il piano tariffario in base alle esigenze dello scenario di replica, come capacità, velocità effettiva e scalabilità. Sebbene sia possibile creare questa risorsa quando si crea l'attività di replica, non è possibile modificare l'area, il piano di hosting e il piano tariffario. L'elenco seguente fornisce altri motivi e procedure consigliate per una risorsa dell'app per la logica creata in precedenza:
È possibile creare questa risorsa dell'app per la logica in un'area diversa dalle entità di origine e di destinazione nell'attività di replica.
Attualmente, queste indicazioni vengono fornite a causa dell'integrazione nativa dell'attività di replica all'interno delle risorse di Azure. Quando si crea un'attività di replica tra entità e si sceglie di creare una nuova risorsa dell'app per la logica anziché usarne una esistente, la nuova app per la logica viene creata nella stessa area dell'entità di origine. Se l'area di origine non è più disponibile, l'attività di replica non può funzionare. Inoltre, in uno scenario di failover, l'attività non può iniziare a leggere i dati dalla nuova origine, in precedenza l'entità di destinazione, ovvero ciò che il modello di replica attivo-passivo tenta di ottenere.
È possibile personalizzare in anticipo questa risorsa dell'app per la logica scegliendo il piano di hosting e il piano tariffario, invece di usare gli attributi predefiniti. In questo modo, l'attività di replica può elaborare più eventi o messaggi al secondo per una replica più veloce. Se si crea questa risorsa quando si crea l'attività di replica, questi attributi predefiniti vengono corretti.
È possibile assicurarsi che questa risorsa dell'app per la logica contenga solo flussi di lavoro delle attività di replica, soprattutto se si vuole seguire il modello di replica attivo-passivo. Quando si usa un'app per la logica esistente per creare l'attività di replica, questa opzione aggiunge l'attività (flusso di lavoro senza stato) alla risorsa dell'app per la logica.
Per altre informazioni, vedere Creare un flusso di lavoro di integrazione con App per la logica di Azure a tenant singolo (Standard) nel portale di Azure.
Facoltativo: stringa di connessione per lo spazio dei nomi di destinazione. Questa opzione abilita la presenza della destinazione in una sottoscrizione diversa, in modo da poter configurare la replica tra sottoscrizioni.
Per trovare la stringa di connessione per l'entità di destinazione, seguire questa procedura:
Nel portale di Azure passare allo spazio dei nomi di destinazione.
Nel menu dello spazio dei nomi, selezionare Criteri di accesso condivisi in Impostazioni.
Nel riquadro Criteri di accesso condiviso visualizzato, in Criteri, selezionare RootManageSharedAccessKey.
Nel riquadro Criteri SAS: RootManageSharedAccessKey visualizzato copiare il valore della Stringa di connessione primaria.
Salvare la stringa di connessione in un punto qualsiasi in modo che sia possibile usare successivamente la stringa per connettersi allo spazio dei nomi di destinazione.
Convenzioni di denominazione
Prestare attenzione alla strategia di denominazione usata per le attività o le entità di replica, se non sono ancora state create. Assicurarsi che i nomi siano facilmente identificabili e differenziati. Ad esempio, se si usa lo spazio dei nomi di Hub eventi, l'attività di replica viene replicata da ogni istanza di Hub eventi nello spazio dei nomi di origine. Se si lavora con le code del Bus di servizio, la tabella seguente fornisce un esempio per la denominazione delle entità e dell'attività di replica:
| Nome origine | Esempio | App di replica | Esempio | Nome di destinazione | Esempio |
|---|---|---|---|---|---|
Spazio dei nomi: <name>-sb-<region> |
fabrikam-sb-weu |
App per la logica: <name-source-region-target-region> |
fabrikam-rep-weu-wus |
Spazio dei nomi: <name>-sb-<region> |
fabrikam-sb-wus |
Coda: <name> |
jobs-transfer |
Flusso di lavoro: <name> |
jobs-transfer-workflow |
Coda: <name> |
jobs |
Creare un processo di replica
Questo esempio illustra come creare un'attività di replica per le code del Bus di servizio.
Nel portale di Azure trovare lo spazio dei nomi del Bus di servizio che si vuole usare come origine.
Nel menu di spostamento dello spazio dei nomi, nella sezione Automazione selezionare Attività (anteprima).
Nel riquadro Attività selezionare Aggiungi un'attività in modo da poter selezionare un modello di attività.
Nel riquadro Aggiungi un'attività, in Seleziona un modello, nel modello per l'attività di replica da creare fare clic su Seleziona. Se la pagina successiva non viene visualizzata, selezionare Avanti: Autentica.
Questo esempio continua selezionando il modello di attività Replica dalla coda del Bus di servizio alla coda, per replicare il contenuto tra le code del Bus di servizio.
Nella scheda Autentica, nella sezione Connessioni selezionare Crea per ogni connessione visualizzata nell'attività in modo da poter fornire le credenziali di autenticazione per tutte le connessioni. I tipi di connessioni in ogni attività variano in base all'attività stessa.
Questo esempio mostra la richiesta di creare la connessione allo spazio dei nomi del Bus di servizio di destinazione in cui esiste la coda di destinazione. La connessione esiste per lo spazio dei nomi del Bus di servizio di origine.
Specificare le informazioni necessarie sulla destinazione, quindi selezionare Crea.
Per questo esempio, specificare un nome visualizzato per la connessione e quindi selezionare lo spazio dei nomi del Bus di servizio in cui esiste la coda di destinazione.
Suggerimento
È anche possibile creare la connessione con una stringa di connessione. Questa opzione consente di avere la destinazione in una sottoscrizione diversa, in modo da poter configurare la replica tra sottoscrizioni. La destinazione o l'origine in base alla posizione in cui è stata avviata la creazione dell'attività di replica, viene configurata dinamicamente in modo da poter connettere solo la destinazione. Per usare una stringa di connessione, seguire questa procedura:
Nel riquadro Connetti selezionare Connetti tramite stringa di connessione.
Nella casella Stringa di connessione immettere la stringa di connessione per lo spazio dei nomi di destinazione.
L'esempio seguente mostra la connessione creata correttamente:
Dopo aver completato tutte le connessioni, selezionare Avanti: Configura.
Nella schedaConfigura specificare un nome per l'attività ed eventuali altre informazioni necessarie per l'attività.
Nota
Non è possibile modificare il nome dell'attività dopo la creazione, quindi prendere in considerazione un nome ancora che rimarrà applicabile anche se si modifica il flusso di lavoro sottostante. Le modifiche apportate al flusso di lavoro sottostante si applicano solo all'attività creata, non al modello di attività.
Ad esempio, se si assegna un nome all'attività
fabrikam-rep-weu-wus, ma successivamente si modifica il flusso di lavoro sottostante per uno scopo diverso, non è possibile modificare il nome dell'attività in modo che corrisponda.Per aggiungere il flusso di lavoro dell'attività a una risorsa dell'App per la logica (Standard) esistente, nell'elenco App per la logica selezionare l'app per la logica esistente. Per creare invece una nuova risorsa App per la logica (Standard), nell'elenco App per la logica selezionare Crea nuovo e specificare il nome da usare per la nuova app per la logica.
Nota
Se si crea una nuova risorsa dell'app per la logica durante la creazione dell'attività di replica, l'app per la logica viene creata nella stessa area dell'entità di origine, che può causare problemi se l'area di origine diventa non disponibile e non funziona in uno scenario di failover. La procedura consigliata consiste nel creare una risorsa dell'App per la logica (Standard) in un'area diversa rispetto all'origine. Quando si crea l'attività di replica, selezionare invece l'app per la logica esistente e aggiungere il flusso di lavoro senza stato sottostante all'app per la logica esistente. Per altre informazioni, vedere i Prerequisiti.
Al termine, selezionare Rivedi e crea.
Nella scheda Rivedi + crea verificare le risorse di Azure richieste dall'attività di replica per l'operazione.
Se si sceglie di creare una nuova risorsa dell'app per la logica per l'attività di replica, nel riquadro vengono visualizzate le risorse di Azure necessarie create dall'attività di replica per il funzionamento. Ad esempio, queste risorse includono un account di archiviazione di Azure che contiene informazioni di configurazione per la risorsa dell'app per la logica, il flusso di lavoro e altre operazioni di runtime. Ad esempio con Hub eventi, questo account di archiviazione contiene informazioni sul checkpoint e sulla posizione o sull'offset nel flusso in cui l'entità di origine si arresta se l'area di origine viene interrotta o diventa non disponibile.
L'esempio seguente mostra la scheda Rivedi + crea se si sceglie di creare una nuova app per la logica:
Se si è scelto di riutilizzare una risorsa dell'app per la logica esistente per l'attività di replica, nel riquadro vengono visualizzate le risorse di Azure che verranno riutilizzate per il funzionamento della replica.
L'esempio seguente mostra la scheda Rivedi + crea se si sceglie di riutilizzare un'app per la logica esistente:
Nota
Se l'origine, la destinazione o entrambi si trovano dietro una rete virtuale, è necessario configurare le autorizzazioni e l'accesso dopo aver creato l'attività. In questo scenario sono necessarie autorizzazioni e accesso in modo che il flusso di lavoro dell'app per la logica possa eseguire l'attività di replica.
Al termine, selezionare Crea.
L'attività creata, che è attiva e in esecuzione automaticamente, viene ora visualizzata nell'elenco Attività.
Suggerimento
Se l'attività non viene visualizzata immediatamente, provare ad aggiornare l'elenco delle attività o attendere qualche istante prima dell'aggiornamento. Nella barra degli strumenti selezionare Aggiorna.
Se le risorse si trovano dietro una rete virtuale, ricordarsi di configurare le autorizzazioni per la risorsa dell'app per la logica e il flusso di lavoro per accedere a tali risorse.
Configurare criteri di ripetizione
Per evitare la perdita di dati durante un evento di disponibilità su entrambi i lati di una relazione di replica, è necessario configurare i criteri di ripetizione dei tentativi per garantire affidabilità. Per configurare i criteri di ripetizione dei tentativi per un'attività di replica, vedere la documentazione sui criteri di ripetizione dei tentativi in App per la logica di Azure e i passaggi per modificare il flusso di lavoro sottostante.
Rivedere la cronologia attività
Questo esempio illustra come visualizzare la cronologia del flusso di lavoro di un'attività insieme ai relativi stati, input, output e altre informazioni e continua a usare l'esempio per un'attività di replica della coda del Bus di servizio.
Nel portale di Azure trovare la risorsa o l'entità di Azure con la cronologia delle attività da esaminare.
Per questo esempio, questa risorsa è uno spazio dei nomi del Bus di servizio.
Nel menu di spostamento delle risorse, nella sezione Automazione di Impostazioni selezionare Attività (anteprima).
Nell'elenco Attività trovare l'attività da rivedere. Nella colonna Esecuzioni dell'attività selezionare Visualizza.
Questo passaggio apre il riquadro Panoramica per il flusso di lavoro senza stato sottostante, che è incluso in una risorsa dell'app per la logica Standard.
Per visualizzare la cronologia di esecuzione per un flusso di lavoro senza stato, nella barra degli strumenti del riquadro Panoramica selezionare Abilita modalità di debug.
La scheda Cronologia di esecuzione mostra tutte le esecuzioni precedenti, in corso e in attesa per l'attività, oltre agli identificatori, agli stati, agli orari di inizio e alle durate di esecuzione.
Nella tabella seguente vengono descritti gli stati possibili per un'esecuzione:
Etichetta stato Descrizione Annullata L'attività è stata annullata durante l'esecuzione. Non riuscito L'attività ha almeno un'azione non riuscita, ma non esiste alcuna azione successiva per gestire l'errore. In esecuzione L'attività è in esecuzione. Completato Tutte le azioni hanno avuto esito positivo. Un'attività può comunque terminare correttamente se un'azione non è riuscita, ma esiste un'azione successiva per gestire l'errore. In attesa L'esecuzione non è ancora stata avviata e viene sospesa perché un'istanza precedente dell'attività è ancora in esecuzione. Per visualizzare gli stati e altre informazioni per ogni passaggio di un'esecuzione, selezionare tale esecuzione.
Viene aperto il riquadro dei dettagli dell'esecuzione e viene visualizzato il flusso di lavoro sottostante eseguito.
Un flusso di lavoro inizia sempre con un trigger. Per questa attività, il flusso di lavoro inizia con un trigger del Bus di servizio che attende l'arrivo dei messaggi nella coda del Bus di servizio di origine.
Ogni passaggio mostra lo stato e la durata dell'esecuzione. I passaggi con durate di 0 secondi hanno richiesto meno di 1 secondo per l'esecuzione.
Per esaminare gli input e gli output per ogni passaggio, selezionare il passaggio per aprire il riquadro che mostra gli input, gli output e i dettagli delle proprietà per tale passaggio.
Questo esempio mostra gli input per il trigger del Bus di servizio.
Per informazioni su come creare flussi di lavoro automatizzati in modo da poter integrare app, dati, servizi e sistemi diversi dal contesto delle attività di replica per le risorse di Azure, vedere Creare un flusso di lavoro di integrazione con App per la logica di Azure a tenant singolo (Standard) nel portale di Azure.
Monitorare attività di replica
Per controllare le prestazioni e l'integrità dell'attività di replica o il flusso di lavoro dell'app per la logica sottostante, è possibile usare Application Insights, una funzionalità di Monitoraggio di Azure. Application Insights Application Map è uno strumento visivo utile che è possibile usare per monitorare le attività di replica. Questa mappa viene generata automaticamente dalle informazioni di monitoraggio acquisite, in modo da poter esplorare le prestazioni e l'affidabilità dei trasferimenti di destinazione e dell'origine dell'attività di replica. Per informazioni dettagliate diagnostiche immediate e visualizzazione a bassa latenza dei dettagli del log, è possibile usare lo strumento del portale delle Metriche attive, un'altra funzionalità di Monitoraggio di Azure.
Modificare l'attività
Per modificare un'attività, sono disponibili queste opzioni:
Modificare l'attività "inline" in modo da poter modificare le proprietà dell'attività, ad esempio informazioni di connessione o informazioni di configurazione, come l'indirizzo e-mail.
Modificare il flusso di lavoro sottostante dell'attività nella finestra di progettazione.
Modificare l'attività inline
Nel portale di Azure trovare la risorsa con l'attività da aggiornare.
Nel menu di spostamento delle risorse, nella sezione Automazione selezionare Attività (anteprima).
Nell'elenco delle attività trovare quella da aggiornare. Aprire i puntini di sospensione dell'attività (...) e selezionare Modifica.
Per impostazione predefinita, viene visualizzata la scheda Autentica con le connessioni esistenti.
Per aggiungere nuove credenziali di autenticazione o selezionare credenziali esistenti diverse per una connessione, aprire i puntini di sospensione della connessione (...) e selezionare Aggiungi nuova connessione o, se disponibili, credenziali di autenticazione diverse.
Nota
È possibile modificare solo la connessione di destinazione, non la connessione di origine.
Per aggiornare altre proprietà dell'attività, selezionare Avanti: Configurare.
Per l'attività in questo esempio, è possibile specificare code di origine e di destinazione diverse. Tuttavia, il nome dell'attività e l'app per la logica sottostante e il flusso di lavoro rimangono invariati.
Al termine, seleziona Salva.
Modificare il flusso di lavoro sottostante dell'attività
È possibile modificare il flusso di lavoro sottostante dietro un'attività di replica, che modifica la configurazione originale per l'attività creata ma non il modello di attività stesso. Dopo aver apportato e salvato le modifiche, l'attività modificata non esegue più la stessa funzione dell'attività originale. Se si desidera un'attività che esegue la funzionalità originale, potrebbe essere necessario creare una nuova attività con lo stesso modello. Se non si vuole ricreare l'attività originale, evitare di modificare il flusso di lavoro dietro l'attività usando la finestra di progettazione. Creare invece un flusso di lavoro senza stato (Standard) dell'App per la logica (Standard) per soddisfare le esigenze di integrazione. Per altre informazioni, vedere Creare un flusso di lavoro di integrazione con App per la logica di Azure a tenant singolo (Standard) nel portale di Azure.
Nel portale di Azure trovare la risorsa con l'attività da aggiornare.
Nel menu di spostamento delle risorse, nella sezione Automazione selezionare Attività.
Nell'elenco delle attività trovare quella da aggiornare. Aprire il menu con i puntini di sospensione (...) dell'attività e selezionare Apri in App per la logica.
Il portale di Azure modifica il contesto della finestra di progettazione in cui è ora possibile modificare il flusso di lavoro.
È ora possibile modificare il trigger e le azioni del flusso di lavoro, nonché le proprietà per il trigger e le azioni.
Per visualizzare le proprietà per il trigger o un'azione, selezionare tale trigger o azione.
Per questo esempio, la proprietà IsSessionsEnabled del trigger viene modificata in Sì.
Per salvare le modifiche, nella barra degli strumenti della finestra di progettazione selezionare Salva.
Per testare ed eseguire il flusso di lavoro aggiornato, aprire la risorsa dell'app per la logica che contiene il flusso di lavoro aggiornato. Nel menu di spostamento del flusso di lavoro selezionare Panoramica>Esegui trigger>Esegui.
Al termine dell'esecuzione, nella finestra di progettazione vengono visualizzati i dettagli di esecuzione del flusso di lavoro. Per esaminare gli input e gli output per ogni passaggio, selezionare il passaggio per aprire il riquadro che mostra gli input, gli output e i dettagli delle proprietà per tale passaggio.
Questo esempio mostra gli input, gli output e le proprietà del trigger del Bus di servizio selezionati, insieme al valore della proprietà trigger aggiornato.
Per disabilitare il flusso di lavoro in modo che l'attività non continui a essere in esecuzione, nella barra degli strumenti Panoramica selezionare Disabilita. Per altre informazioni, vedere Disabilitare o abilitare flussi di lavoro a tenant singolo.
Configurare il failover per Hub eventi di Azure
Per la replica di Hub eventi di Azure tra gli stessi tipi di entità, il ripristino di emergenza geografico richiede l'esecuzione di un failover dall'entità di origine all'entità di destinazione e quindi indica a tutti i consumer di eventi interessati e ai producer di usare l'endpoint per l'entità di destinazione, che diventa la nuova origine. Pertanto, se si verifica un'emergenza e l'entità di origine esegue il failover, i consumer e i produttori, inclusa l'attività di replica, vengono reindirizzati alla nuova origine. L'account di archiviazione creato dall'attività di replica contiene informazioni sul checkpoint e la posizione o l'offset nel flusso in cui l'entità di origine si arresta se l'area di origine viene interrotta o diventa non disponibile.
Per assicurarsi che l'account di archiviazione non contenga informazioni legacy dall'origine originale e che l'attività di replica inizi a leggere e replicare gli eventi dall'inizio del nuovo flusso di origine, è necessario pulire manualmente tutte le informazioni legacy dall'origine originale e riconfigurare l'attività di replica.
Nel portale di Azure aprire la risorsa dell'app per la logica o il flusso di lavoro sottostante dietro l'attività di replica.
Nota
La risorsa dell'app per la logica deve contenere solo flussi di lavoro delle attività di replica.
Nel menu di spostamento della risorsa o del flusso di lavoro selezionare Panoramica. Nella barra degli strumenti Panoramica selezionare Disabilita per il flusso di lavoro oppure selezionare Arresta per la risorsa dell'app per la logica.
Per trovare l'account di archiviazione usato dalla risorsa dell'app per la logica sottostante dell'attività di replica per archiviare il checkpoint e trasmettere le informazioni sull'offset dall'entità di origine, seguire questa procedura:
Nel menu della risorsa App per la logica, in Impostazioni selezionare Configurazione.
Nel riquadro Configurazione selezionare l'impostazione dell'app AzureWebJobsStorage nella scheda Impostazioni applicazione.
Questa impostazione specifica la stringa di connessione e l'account di archiviazione usati dalla risorsa dell'app per la logica.
Nota
Se l'impostazione dell'app non viene visualizzata nell'elenco, selezionare Mostra valori.
Selezionare l'impostazione dell'app AzureWebJobsStorage in modo da poter visualizzare il nome dell'account di archiviazione.
Questo esempio mostra come trovare il nome per questo account di archiviazione, che è
storagefabrikamreplb0cqui:
- Per verificare che la risorsa dell'account di archiviazione esista, nella casella di ricerca del portale di Azure immettere il nome e quindi selezionare l'account di archiviazione, ad esempio:
Eliminare ora la cartella che contiene il checkpoint e le informazioni sull'offset dell'entità di origine attenendosi alla procedura seguente:
Scaricare, installare e aprire il client desktop di Azure Storage Explorer più recente, se non si ha la versione più recente.
Nota
Per l'attività di pulizia dell'eliminazione, è attualmente necessario usare il client di Azure Storage Explorer, non lo strumento di esplorazione dell'archiviazione, il browser, l'editor o l'esperienza di gestione nel portale di Azure.
Anche se è possibile eliminare cartelle contenitore con il
Remove-AzStorageDirectorycomando di PowerShell, questo comando funziona solo su cartelle vuote.Se non è già stato fatto, accedere con l'account Azure e assicurarsi che sia selezionata la sottoscrizione di Azure per la risorsa dell'account di archiviazione. Per altre informazioni, vedere Informazioni di base su Storage Explorer.
Nella finestra Esplora risorse, sotto il nome della sottoscrizione di Azure, passare a Account di archiviazione>{your-storage-account-name}>Contenitori BLOB>azure-webjobs-eventhub.
Nota
Se la cartella azure-webjobs-eventhub non esiste, significa che l'attività di replica non è ancora stata eseguita. La cartella viene visualizzata solo dopo l'esecuzione dell'attività di replica almeno una volta.
Nel riquadro azure-webjobs-eventhub visualizzato selezionare la cartella dello spazio dei nomi di Hub eventi con un nome con il formato seguente:
<source-Event-Hubs-namespace-name>.servicebus.windows.net.Dopo aver aperto la cartella dello spazio dei nomi, nel riquadro azure-webjobs-eventhub selezionare la cartella <former-source-entity-name>. Nel menu di scelta rapida della barra degli strumenti o della cartella selezionare Elimina, ad esempio:
Verificare di voler eliminare la cartella.
Tornare alla risorsa o al flusso di lavoro dell'app per la logica dietro l'attività di replica. Riavviare l'app per la logica o abilitare di nuovo il flusso di lavoro.
Per rendere i producer e i consumer a usare il nuovo endpoint di origine, è necessario rendere disponibili informazioni sulla nuova entità di origine da usare e trovare in una posizione facile da raggiungere e aggiornare. Se i produttori o i consumer riscontrano errori frequenti o persistenti, devono controllare tale posizione e regolare la configurazione. Esistono diversi modi per condividere tale configurazione, ma le condivisioni DNS e file sono esempi.
Per altre informazioni sul ripristino di emergenza geografico, vedere la documentazione seguente:
- Hub eventi di Azure - Ripristino di emergenza geografico
- Bus di servizio di Azure - Ripristino di emergenza geografico
Modificare le impostazioni di scale-out del piano di hosting
Nel portale di Azure aprire la risorsa dell'app per la logica sottostante per l'attività di replica.
Nel menu delle risorse dell'app per la logica, in Impostazioniselezionare Scale-out (Piano di servizio app).
In Base alle esigenze dello scenario, in Scale Out piano e Scale Out app, modificare rispettivamente i valori per il burst massimo e le istanze Sempre pronte.
Al termine, nella barra degli strumenti del riquadro Scale-out (Piano di servizio app) selezionare Salva.
Per altre informazioni, vedere la documentazione seguente, perché il piano Flusso di lavoro Standard condivide alcuni aspetti con il piano Premium di Funzioni di Azure:
- Impostazioni di piano e SKU - Piano Premium di Funzioni di Azure
- Che cos'è il bursting del cloud?
- Istanze sempre pronte - Piano Premium di Funzioni di Azure
Problemi e errori di replica
Questa sezione descrive i possibili modi in cui la replica può avere esito negativo o interrompere il funzionamento:
Limiti sulle dimensioni dei messaggi
Assicurarsi di inviare messaggi inferiori a 1 MB perché l'attività di replica aggiunge proprietà di replica. In caso contrario, se la dimensione del messaggio è maggiore delle dimensioni degli eventi che possono essere inviati a un'entità di Hub eventi dopo che l'attività aggiunge proprietà di replica, il processo di replica non riesce.
Si supponga, ad esempio, che la dimensione del messaggio sia 1 MB. Dopo che l'attività aggiunge le proprietà di replica, le dimensioni del messaggio sono superiori a 1 MB. La chiamata in uscita che tenta di inviare il messaggio avrà esito negativo.
Chiavi di partizione
Se esistono chiavi di partizione negli eventi, la replica tra istanze di Hub eventi ha esito negativo se tali istanze hanno lo stesso numero di partizioni.
Passaggi successivi
- Informazioni sulla finestra di progettazione del flusso di lavoro in App per la logica di Azure a tenant singolo
- Modificare le impostazioni dell'host e dell'app per le App per la logica in App per la logica di Azure a tenant singolo
- Creare parametri da usare nei flussi di lavoro in ambienti in App per la logica di Azure a tenant singolo