Affidabilità in Ricerca cognitiva di Azure
In Azure l'affidabilità significa mantenere la resilienza e la disponibilità in caso di interruzione o riduzione del servizio. In Ricerca cognitiva, l'affidabilità viene ottenuta quando si:
Configurare un servizio per usare più repliche, abbinate al supporto della zona di disponibilità.
Distribuire più servizi in aree geografiche diverse.
Tutti i carichi di lavoro di ricerca sono completamente contenuti all'interno di un singolo servizio che viene eseguito in una singola area geografica. In un servizio è possibile configurare più repliche eseguite automaticamente in diverse zone di disponibilità. Questa funzionalità è il modo in cui si ottiene la disponibilità elevata.
Per la continuità aziendale e il ripristino da emergenze a livello regionale, è necessario sviluppare una strategia che include una topologia tra aree, costituita da più servizi di ricerca con configurazione e contenuto identici. Lo script o il codice personalizzato fornisce il meccanismo di "failover" a un servizio di ricerca alternativo se uno diventa improvvisamente non disponibile.
Disponibilità elevata
In Ricerca cognitiva le repliche sono copie dell'indice. Un servizio di ricerca viene installato con almeno una replica e può avere fino a 12 repliche. L'aggiunta di repliche consente Ricerca cognitiva di Azure di eseguire il riavvio e la manutenzione del computer in una replica, mentre l'esecuzione di query continua su altre repliche.
Per ogni singolo servizio di ricerca, Microsoft garantisce almeno il 99,9% di disponibilità per le configurazioni che soddisfano questi criteri:
Due repliche per la disponibilità elevata di carichi di lavoro di sola lettura, vale a dire query.
Tre o più repliche per la disponibilità elevata dei carichi di lavoro di lettura/scrittura (query e indicizzazione)
Per il livello gratuito non è disponibile alcun Contratto di servizio. Per altre informazioni, vedere Contratto di servizio per Ricerca cognitiva di Azure.
Supporto della zona di disponibilità
Le zone di disponibilità sono una funzionalità della piattaforma Azure che divide i data center di un'area in gruppi di posizioni fisiche distinti per offrire disponibilità elevata, all'interno della stessa area. Se si usano zone di disponibilità per Ricerca cognitiva, le singole repliche sono le unità per l'assegnazione di zona. Un servizio di ricerca viene eseguito all'interno di un'area; le repliche vengono eseguite in zone diverse.
È possibile usare zone di disponibilità con Ricerca cognitiva di Azure aggiungendo due o più repliche al servizio di ricerca. Ogni replica viene inserita in una zona di disponibilità diversa all'interno dell'area. Se sono presenti più repliche rispetto alle zone di disponibilità, le repliche vengono distribuite in più zone di disponibilità il più possibile. Non esiste alcuna azione specifica nella tua parte, ad eccezione della creazione di un servizio di ricerca in un'area che fornisce zone di disponibilità e quindi per configurare il servizio per l'uso di più repliche.
Prerequisiti
Come indicato, è necessario disporre di più repliche per la disponibilità elevata: due per carichi di lavoro di query di sola lettura, tre per carichi di lavoro di lettura-scrittura che includono l'indicizzazione.
Il servizio deve essere distribuito in un'area che supporta le zone di disponibilità. Ricerca cognitiva di Azure supporta attualmente le zone di disponibilità per il livello Standard o versioni successive, in una delle aree seguenti:
Region | Implementazione |
---|---|
Australia orientale | 30 gennaio 2021 o versioni successive |
Brasile meridionale | 2 maggio 2021 o versione successiva |
Canada centrale | 30 gennaio 2021 o versioni successive |
India centrale | 20 gennaio 2022 o versioni successive |
Stati Uniti centrali | 4 dicembre 2020 o versioni successive |
Cina settentrionale 3 | 7 settembre 2022 o versioni successive |
Asia orientale | 13 gennaio 2022 o versioni successive |
Stati Uniti orientali | 27 gennaio 2021 o versioni successive |
Stati Uniti orientali 2 | 30 gennaio 2021 o versioni successive |
Francia centrale | 23 ottobre 2020 o versioni successive |
Germania centro-occidentale | 3 maggio 2021 o versioni successive |
Giappone orientale | 30 gennaio 2021 o versioni successive |
Corea centrale | 20 gennaio 2022 o versioni successive |
Europa settentrionale | 28 gennaio 2021 o versioni successive |
Norvegia orientale | 20 gennaio 2022 o versioni successive |
Qatar centrale | 25 agosto 2022 o versioni successive |
Sudafrica settentrionale | 7 settembre 2022 o versioni successive |
Stati Uniti centro-meridionali | 30 aprile 2021 o versioni successive |
Asia sud-orientale | 31 gennaio 2021 o versioni successive |
Svezia centrale | 21 gennaio 2022 o versioni successive |
Svizzera settentrionale | 7 settembre 2022 o versioni successive |
Emirati Arabi Uniti settentrionali | 9 settembre 2022 o versioni successive |
Regno Unito meridionale | 30 gennaio 2021 o versioni successive |
US Gov Virginia | 30 aprile 2021 o versioni successive |
Europa occidentale | 29 gennaio 2021 o versioni successive |
West US 2 | 30 gennaio 2021 o versioni successive |
Stati Uniti occidentali 3 | Giugno 02, 2021 o versione successiva |
zone di disponibilità non influiscono sul contratto di servizio Ricerca cognitiva di Azure. Sono ancora necessarie tre o più repliche per la disponibilità elevata delle query.
Più servizi in aree geografiche separate
La ridondanza del servizio è necessaria se i requisiti operativi includono:
Continuità aziendale e ripristino di emergenza (BCDR) ( Ricerca cognitiva non fornisce failover immediato in caso di interruzione).
Disponibilità globale. Se le richieste di query e indicizzazione provengono da tutto il mondo, gli utenti più vicini al data center host avranno prestazioni più veloci. La creazione di servizi aggiuntivi nelle aree con prossimità a questi utenti può equalizzare le prestazioni per tutti gli utenti.
Se sono necessari due o più servizi di ricerca, la creazione di tali servizi in aree diverse può soddisfare i requisiti dell'applicazione per la continuità e il ripristino, nonché tempi di risposta più rapidi per una base utente globale.
Ricerca cognitiva di Azure non fornisce un metodo automatizzato per replicare gli indici di ricerca in aree geografiche, ma esistono alcune tecniche che possono rendere questo processo semplice da implementare e gestire. Queste tecniche sono descritte nelle prossime sezioni.
L'obiettivo di un set di servizi di ricerca con distribuzione geografica consiste nell'avere due o più indici disponibili in due o più aree, in cui un utente viene instradato al servizio Ricerca cognitiva di Azure che fornisce la latenza più bassa:
È possibile implementare questa architettura creando più servizi e progettando una strategia per la sincronizzazione dei dati. Facoltativamente, è possibile includere una risorsa come Gestione traffico di Azure per il routing delle richieste. Per altre informazioni, vedere Creare un servizio di ricerca.
Sincronizzare i dati tra più servizi
Sono disponibili due opzioni per mantenere sincronizzati due o più servizi di ricerca distribuiti:
- Eseguire il pull degli aggiornamenti del contenuto in un indice di ricerca usando un indicizzatore.
- Eseguire il push del contenuto in un indice usando l'API REST (Add or Update Documents) o un'API equivalente di Azure SDK.
Opzione 1: Usare gli indicizzatori per aggiornare il contenuto in più servizi
Se si usa già l'indicizzatore in un servizio, è possibile configurare un secondo indicizzatore in un secondo servizio per usare lo stesso oggetto origine dati, eseguendo il pull dei dati dalla stessa posizione. Ogni servizio in ogni area ha un proprio indicizzatore e un indice di destinazione (l'indice di ricerca non è condiviso, ovvero i dati vengono duplicati), ma ogni indicizzatore fa riferimento alla stessa origine dati.
Ecco un oggetto visivo generale dell'aspetto dell'architettura.
Opzione 2: Usare le API REST per il push degli aggiornamenti del contenuto in più servizi
Se si usa l'API REST Ricerca cognitiva di Azure per eseguire il push del contenuto nell'indice di ricerca, è possibile mantenere sincronizzati i vari servizi di ricerca eseguendo il push delle modifiche a tutti i servizi di ricerca ogni volta che è necessario un aggiornamento. Nel codice assicurarsi di gestire i casi in cui un aggiornamento a un servizio di ricerca ha esito negativo, ma ha esito positivo per altri servizi di ricerca.
Usare Gestione traffico di Azure per coordinare le richieste
Gestione traffico di Azure consente di instradare le richieste a più siti Web localizzati geograficamente supportati da più servizi di ricerca. Uno dei vantaggi di Gestione traffico è che può eseguire il probe di Ricerca cognitiva di Azure per confermare la disponibilità e instradare gli utenti a servizi di ricerca alternativi in caso di inattivo di un servizio. Inoltre, se si instradano le richieste di ricerca tramite siti Web di Azure, Gestione traffico di Azure consente di bilanciare il carico dei casi in cui il sito Web è operativo, ma la ricerca non è. Ecco un esempio di architettura che usa Gestione traffico.
Residenza dei dati
Quando si distribuiscono più servizi di ricerca in aree geografiche diverse, il contenuto viene archiviato nell'area scelta.
Ricerca cognitiva di Azure non archivierà i dati all'esterno dell'area specificata senza l'autorizzazione. In particolare, le funzionalità seguenti scrivono in una risorsa di Archiviazione di Azure: cache di arricchimento, sessione di debug, archivio conoscenze. L'account di archiviazione è uno specificato e può trovarsi in qualsiasi area.
Se sia l'account di archiviazione che il servizio di ricerca si trovano nella stessa area, il traffico di rete tra la ricerca e l'archiviazione usa un indirizzo IP privato e si verifica sulla rete backbone Microsoft. Poiché vengono usati indirizzi IP privati, non è possibile configurare firewall IP o un endpoint privato per la sicurezza di rete. Usare invece l'eccezione del servizio attendibile come alternativa quando entrambi i servizi si trovano nella stessa area.
Interruzioni di servizio e ripristino di emergenza
Come indicato nel Contratto di servizio, Microsoft garantisce un livello elevato di disponibilità per le richieste di query sugli indici quando un'istanza del servizio Ricerca cognitiva di Azure è configurata con due o più repliche e le richieste di aggiornamento dell'indice quando un'istanza del servizio Ricerca cognitiva di Azure è configurata con tre o più repliche. Tuttavia, non esiste alcun meccanismo predefinito per il ripristino di emergenza. Se il servizio continuo è necessario in caso di errore irreversibile al di fuori del controllo di Microsoft, è consigliabile effettuare il provisioning di un secondo servizio in un'area diversa e implementare una strategia di replica geografica per garantire che gli indici siano completamente ridondanti in tutti i servizi.
I clienti che usano gli indicizzatori per popolare e aggiornare gli indici possono gestire il ripristino di emergenza tramite indicizzatori specifici dell'area geografica che recuperano dati dalla stessa origine dati. Due servizi in diverse aree, ognuno dei quali esegue un indicizzatore, possono indicizzare la stessa origine dati per ottenere la ridondanza geografica. Se si esegue l'indicizzazione da origini dati che sono anche con ridondanza geografica, tenere presente che Ricerca cognitiva di Azure indicizzatori possono eseguire solo l'indicizzazione incrementale (unione di aggiornamenti da documenti nuovi, modificati o eliminati) dalle repliche primarie. In un evento di failover assicurarsi di reindirizzare l'indicizzatore alla nuova replica primaria.
Se non si usano indicizzatori, si userà il codice dell'applicazione per eseguire il push di oggetti e dati in diversi servizi di ricerca in parallelo. Per altre informazioni, vedere Mantenere sincronizzati i dati tra più servizi.
Backup e ripristino di alternative
Poiché Ricerca cognitiva di Azure non è una soluzione di archiviazione dati primaria, Microsoft non fornisce un meccanismo formale per il backup e il ripristino self-service. Tuttavia, è possibile usare il codice di esempio index-backup-restore in questo repository di esempio Ricerca cognitiva di Azure .NET per eseguire il backup della definizione dell'indice e dello snapshot in una serie di file JSON e quindi usare questi file per ripristinare l'indice, se necessario. Questo strumento può anche spostare gli indici tra i livelli di servizio.
In caso contrario, il codice dell'applicazione usato per creare e popolare un indice è l'opzione di ripristino di fatto se si elimina un indice per errore. Per ricompilare un indice, è necessario eliminarlo (supponendo che sia presente), ricreare l'indice nel servizio e ricaricare recuperando i dati dall'archivio dati primario.
Passaggi successivi
Vedere Limiti del servizio per altre informazioni sui piani tariffari e sui limiti dei servizi per ognuno di essi.
Per altre informazioni sulle combinazioni di partizione e replica, vedere Pianificare la capacità .
Esaminare il case study: usare Ricerca cognitiva per supportare scenari di intelligenza artificiale complessi per suggerimenti reali.