Creare attività di replica per le risorse di Azure usando App per la logica di Azure (anteprima)
Importante
Questa funzionalità è disponibile in anteprima ed è soggetta alle Condizioni per l'utilizzo supplementari 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 sono "disastrose" in modo che si voglia 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 pochi 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 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, ma 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 di bus di servizio di Azure. Se non si ha familiarità con le app per la logica e i flussi di lavoro, vedere What is App per la logica di Azure and Single-tenant versus multi-tenant and integration service environment for App per la logica di Azure (Che cos'è App per la logica di Azure e Ambiente del servizio di integrazione multi-tenant e multi-tenant per App per la logica di Azure).
Che cos'è 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 l'origine è 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 aggiungere 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à Funzioni di Azure ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e prestazioni maggiori per i flussi di lavoro delle app per la logica, oltre ad altre funzionalità e vantaggi ereditati dalla piattaforma Funzioni di Azure e dall'ecosistema di servizi app Azure.
Per altre informazioni sulla replica e la federazione, vedere la documentazione seguente:
- Federazione multisito e multisito di Hub eventi
- Modelli di attività di replica di eventi
- bus di servizio la replica dei messaggi e la federazione tra aree
- Modelli di attività di replica dei messaggi
Modelli di attività di replica
Attualmente, i modelli di attività di replica sono disponibili per Hub eventi di Azure e bus di servizio di Azure. La tabella seguente elenca i modelli di attività di replica attualmente disponibili in questa anteprima:
| Tipo di risorsa | Origine e destinazione della replica |
|---|---|
| Spazio dei nomi di Hub eventi di Azure | - Istanza di Hub eventi nell'istanza di Hub eventi - Istanza di Hub eventi per bus di servizio coda - Istanza di Hub eventi per bus di servizio argomento |
| Spazio dei nomi del bus di servizio di Azure | - bus di servizio coda per bus di servizio coda - bus di servizio coda per bus di servizio argomento - bus di servizio argomento bus di servizio - bus di servizio coda all'istanza di Hub eventi - bus di servizio argomento per bus di servizio coda - bus di servizio argomento dell'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 di 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 la federazione in Hub eventi di Azure, vedere la documentazione seguente:
Topologia di replica per bus di servizio
Il diagramma seguente illustra il flusso di lavoro dell'attività di topologia e replica tra le code bus di servizio:
Per informazioni sulla replica e la federazione in bus di servizio di Azure, vedere la documentazione seguente:
- bus di servizio la replica dei messaggi e la federazione tra aree
- Modelli di attività di replica dei 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-sequencee repl-offset. Queste proprietà hanno il string tipo 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 bus di servizio, gli elementi seguenti ottenuti dalla coda o dall'argomento di bus di servizio di origine vengono sostituiti da nuovi valori assegnati dal servizio nella coda o nell'argomento bus di servizio di destinazione: metadati assegnati dal 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 string tipo 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 da bus di servizio a Hub eventi, l'attività esegue il mapping solo della User Properties proprietà alla Properties proprietà . Tuttavia, quando l'attività viene replicata da Hub eventi a bus di servizio, l'attività esegue il mapping delle proprietà seguenti:
| Da Hub eventi | Per bus di servizio |
|---|---|
| ContentType | ContentType |
| CorrelationId | CorrelationId |
| MessageId | MessageId |
| PartitionKey | PartitionKey SessionId |
| Proprietà | Proprietà utente |
| ReplyTo | ReplyTo |
| ReplyToGroupName | ReplyToSessionId |
| Subject | Label |
| Per | Per |
Conservazione degli ordini
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, la 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 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 proccessing 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 modifica il valore dell'input.
Per altre informazioni sulla federazione multisito e su più aree per i servizi di Azure in cui è possibile creare attività di replica, vedere la documentazione seguente:
- Federazione multisito e multisito di Hub eventi
- Modelli di attività di replica di eventi
- bus di servizio la replica dei messaggi e la federazione tra aree
- Modelli di attività di replica dei 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 incorrere immediatamente. Utilizzo, misurazione, fatturazione e modello tariffario seguono il piano di hosting Standard e i piani tariffari standard.
In base al numero di eventi ricevuti da Hub eventi o messaggi che bus di servizio handle, il piano di hosting potrebbe aumentare o ridurre le prestazioni per mantenere l'utilizzo minimo di vCPU e bassa latenza durante la replica attiva. Questo comportamento richiede che quando si crea una risorsa dell'app per la logica da usare per l'attività di replica, scegliere il piano tariffario Standard appropriato in modo che App per la logica di Azure non limiti o avvii l'utilizzo massimo 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 prelettura, le dimensioni massime del batch di eventi per Hub eventi e il numero massimo di messaggi per 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 prelettura, 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 conteggio dei prelettura e il numero massimo di batch di eventi o messaggi da 800.
Scalabilità orizzontale 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 prelettura 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 prelettura 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 prelettura e le dimensioni massime del batch di eventi da 800.
| Piano tariffario | Numero di partizioni | Eventi al secondo | Picchi massimi* | Istanze sempre pronte* | Conteggio prelettura* | 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ò continuare a aumentare fino a quando il numero di istanze raggiunge il limite massimo di burst. Per modificare questo valore, vedere Modificare le impostazioni di scalabilità orizzontale del piano di hosting più avanti in questo articolo. Nota: tutte le istanze oltre le dimensioni del piano vengono fatturate solo quando vengono eseguite e allocate all'utente in base al secondo. La piattaforma fa del meglio 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 aumentare il numero di istanze 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 Workflow Standard condivide alcuni aspetti con il piano Funzioni di Azure Premium: - Impostazioni di piano e SKU - piano Funzioni di Azure Premium |
| 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 scalabilità orizzontale 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 always ready - Funzioni di Azure piano Premium. |
| Conteggio prelettura | Valore predefinito per l'impostazione dell'app nella risorsa dell'app per AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__prefetchCount 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 - impostazioni host.json : trigger e associazioni 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 - impostazioni host.json : trigger e associazioni Hub eventi di Azure per Funzioni di Azure |
bus di servizio aumentare il numero di istanze
Gli esempi seguenti illustrano il piano tariffario di hosting e le opzioni di configurazione per un'attività di replica tra due spazi dei nomi 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 prelettura 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 prelettura 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 prelettura e il numero massimo di messaggi da 800.
| Piano tariffario | Messaggi al secondo | Picchi massimi* | Istanze sempre pronte* | Conteggio prelettura* | 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ò continuare a aumentare fino a quando il numero di istanze raggiunge il limite massimo di burst. Per modificare questo valore, vedere Modificare le impostazioni di scalabilità orizzontale del piano di hosting più avanti in questo articolo. Nota: tutte le istanze oltre le dimensioni del piano vengono fatturate solo quando vengono eseguite e allocate all'utente in base al secondo. La piattaforma fa del meglio 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 aumentare il numero di istanze 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 Workflow Standard condivide alcuni aspetti con il piano Funzioni di Azure Premium: - Impostazioni di piano e SKU - piano Funzioni di Azure Premium |
| 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 scalabilità orizzontale 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 always ready - Funzioni di Azure piano Premium. |
| Conteggio prelettura | Valore predefinito per l'impostazione dell'app nella risorsa dell'app per AzureFunctionsJobHost__extensions__serviceBus__prefetchCount 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 - impostazioni host.json : associazioni 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 |
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 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, ad esempio 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. In uno scenario di failover, l'attività non può anche 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) nella 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 il stringa di connessione per l'entità di destinazione, seguire questa procedura:
Nella portale di Azure passare allo spazio dei nomi di destinazione.
Nel menu di spostamento dello spazio dei nomi, in Impostazioni, selezionare Criteri di accesso condiviso.
Nel riquadro Criteri di accesso condiviso visualizzato in Criteri selezionare RootManageSharedAccessKey.
Nel riquadro Criteri di firma di accesso condiviso: RootManageSharedAccessKey visualizzato copiare il valore Stringa di Connessione primaria.
Salvare il stringa di connessione da qualche parte 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 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 |
Workflow: <name> |
jobs-transfer-workflow |
Coda: <name> |
jobs |
Creare un'attività di replica
Questo esempio illustra come creare un'attività di replica per le code bus di servizio.
Nella portale di Azure trovare lo spazio dei nomi bus di servizio che si vuole usare come origine.
Nella sezione Automazione del menu di spostamento dello spazio dei nomi 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 Selezionare un modello, nel modello per l'attività di replica da creare selezionare Seleziona. Se la pagina successiva non viene visualizzata, selezionare Avanti: Autentica.
Questo esempio continua selezionando il modello di attività Replica da bus di servizio coda a coda, che replica il contenuto tra le code bus di servizio.
Nella sezione Connessione ions della scheda Autentica 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à.
In questo esempio viene illustrato il prompt per creare la connessione allo spazio dei nomi bus di servizio di destinazione in cui esiste la coda di destinazione. La connessione esiste per lo spazio dei nomi bus di servizio di origine.
Specificare le informazioni necessarie sulla destinazione e quindi selezionare Crea.
Per questo esempio, specificare un nome visualizzato per la connessione e quindi selezionare lo spazio dei nomi bus di servizio in cui esiste la coda di destinazione.
Suggerimento
È anche possibile creare la connessione con un 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 un stringa di connessione, seguire questa procedura:
Nel riquadro Connessione selezionare Connessione tramite stringa di connessione.
Nella casella Connessione ion String (Stringa di Connessione) immettere il 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 scheda Configura specificare un nome per l'attività e tutte le altre informazioni necessarie per l'attività.
Nota
Non è possibile modificare il nome dell'attività dopo la creazione, quindi prendere in considerazione un nome ancora applicabile 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 lalogica (Standard) esistente, 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 è problematica 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 Prerequisiti.
Al termine, selezionare Rivedi e crea.
Nella scheda Rivedi e 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 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 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.
L'esempio seguente mostra la scheda Rivedi e 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 e 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. Sulla 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 i criteri di ripetizione dei tentativi
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, esaminare 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.
Esaminare la cronologia delle 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 di bus di servizio.
Nella 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 bus di servizio.
Nel menu di spostamento delle risorse, in Impostazioni, nella sezione Automazione selezionare Attività (anteprima).
Nel riquadro Attività individuare 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, 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à insieme 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 di 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à è attualmente 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 bus di servizio che attende l'arrivo dei messaggi nella coda di 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, che apre un riquadro che mostra gli input, gli output e i dettagli delle proprietà per tale passaggio.
Questo esempio mostra gli input per il trigger 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 le 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, anche una funzionalità in 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.
Modificare il flusso di lavoro sottostante dell'attività nella finestra di progettazione.
Modificare l'attività inline
Nella portale di Azure trovare la risorsa con l'attività da aggiornare.
Nella sezione Automazione del menu di spostamento delle risorse selezionare Attività (anteprima).
Nell'elenco delle attività trovare l'attività da aggiornare. Aprire il menu con i puntini di sospensione (...) dell'attività e selezionare Modifica in linea.
Per impostazione predefinita, viene visualizzata la scheda Autentica e mostra le connessioni esistenti.
Per aggiungere nuove credenziali di autenticazione o selezionare credenziali di autenticazione diverse per una connessione, aprire il menu con i puntini di sospensione (...) della connessione e selezionare Aggiungi nuova connessione o, se disponibile, 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: Configura.
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 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) nella portale di Azure.
Nella portale di Azure trovare la risorsa con l'attività da aggiornare.
Nel menu di spostamento delle risorse selezionare Attività nella sezione Automazione.
Nell'elenco delle attività trovare l'attività 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, sulla 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>Esecuzione trigger.>
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, che apre un 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 bus di servizio selezionati, insieme al valore della proprietà del 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 Hub eventi di Azure replica 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 e ai produttori interessati 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.
Nella 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. Sulla barra degli strumenti Panoramica selezionare Disabilita per il flusso di lavoro o 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 delle risorse dell'app per la logica, in Impostazioni selezionare Configurazione.
Nel riquadro Configurazione selezionare l'impostazione dell'app AzureWebJobs Archiviazione nella scheda Impostazioni applicazione.
Questa impostazione specifica il 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 AzureWebJobs Archiviazione in modo da poter visualizzare il nome dell'account di archiviazione.
Questo esempio mostra come trovare il nome per questo account di archiviazione, disponibile
storagefabrikamreplb0cqui:
- Per verificare che la risorsa dell'account di archiviazione esista, nella casella di ricerca 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 più recente Archiviazione di Azure Explorer, se non si ha la versione più recente.
Nota
Per l'attività di pulizia dell'eliminazione, è attualmente necessario usare il client di Archiviazione di Azure Explorer, non l'esperienza di esplorazione dell'archiviazione, del browser, dell'editor o della gestione nel portale di Azure.
Anche se è possibile eliminare cartelle contenitore con il comando di PowerShell
Remove-AzStorageDirectory, 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 Introduzione a Archiviazione Explorer.
Nella finestra Esplora risorse, sotto il nome della sottoscrizione di Azure, passare a Archiviazione Account>{nome-account-archiviazione}>Contenitori>BLOB azure-webjobs-eventhub.
Nota
Se la cartella azure-webjobs-eventhub non esiste, 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>. Dal 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 scalabilità orizzontale del piano di hosting
Nella 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 Impostazioni selezionare Scale out (piano servizio app).
In Base alle esigenze dello scenario, in Piano di scalabilità orizzontale e scalabilità orizzontale delle 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 Workflow Standard condivide alcuni aspetti con il piano Funzioni di Azure Premium:
- Impostazioni di piano e SKU - piano Funzioni di Azure Premium
- Che cos'è il bursting del cloud?
- Istanze sempre pronte - piano Funzioni di Azure Premium
Problemi e errori di replica
Questa sezione descrive i possibili modi in cui la replica può avere esito negativo o interrompere il funzionamento:
Limiti delle 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