Configurazione di un dominio multi-AZ in Amazon OpenSearch Service - Amazon OpenSearch Service

Configurazione di un dominio multi-AZ in Amazon OpenSearch Service

Per impedire la perdita di dati e ridurre al minimo i tempi di inattività del cluster in caso di interruzione del servizio, è possibile distribuire i nodi tra due o tre zone di disponibilità nella stessa regione, una configurazione nota come Multi-AZ. Le zone di disponibilità sono più posizioni isolate all'interno di ogni regione AWS.

Per domini che eseguono i carichi di lavoro di produzione, consigliamo la seguente configurazione:

  • Scegliere una regione che supporta tre zone di disponibilità con OpenSearch Service.

  • Distribuire il dominio su tre zone.

  • Scegliere tipi di istanze della generazione attuale per nodi master dedicati e nodi di dati.

  • Utilizzare tre nodi master dedicati e almeno tre nodi di dati.

  • Creare almeno una replica per ogni indice del cluster.

Il resto di questa sezione fornisce spiegazioni e contesto per tali raccomandazioni.

Distribuzione di partizioni

Se si abilita il Multi-AZ, è necessario creare almeno una replica per ogni indice del cluster. Senza repliche, OpenSearch Service non è in grado di distribuire copie dei dati in altre zone di disponibilità, annullando così lo scopo del Multi-AZ. Fortunatamente, la configurazione predefinita per qualsiasi indice prevede un conteggio di repliche pari a 1. Come mostra il diagramma seguente, OpenSearch Service fa il massimo sforzo per distribuire le partizioni primarie e i relativi frammenti di replica corrispondenti a zone diverse.

Oltre a distribuire le partizioni per zona di disponibilità, OpenSearch Service le distribuisce per nodo. Tuttavia, alcune configurazioni di dominio possono portare a conteggi di partizioni squilibrati. Considerare il dominio seguente:

  • 5 nodi di dati

  • 5 partizioni primarie

  • 2 repliche

  • 3 zone di disponibilità

In questo caso, OpenSearch Service deve sovraccaricare un nodo per distribuire le partizioni primaria e di replica tra le zone, come illustrato nel seguente diagramma.

Per evitare questi tipi di situazioni, che possono esaurire singoli nodi e danneggiare le prestazioni, consigliamo di scegliere un conteggio di istanze che sia multiplo di tre se si prevede di avere due o più repliche per indice.

Distribuzione dei nodi principali dedicati

Anche se si selezionano due zone di disponibilità durante la configurazione del dominio, OpenSearch Service distribuisce automaticamente i nodi principali dedicati su tre zone di disponibilità. Questa distribuzione consente di evitare tempi di inattività dei cluster se in una zona si verifica un'interruzione del servizio. Se si utilizzano i tre nodi master dedicati consigliati e una zona di disponibilità è inutilizzabile, il cluster ha ancora un quorum (2) di nodi master dedicati e può eleggere un nuovo nodo master. Il seguente diagramma mostra questa configurazione.

Questa distribuzione automatica ha alcune sostanziali eccezioni:

  • Se si sceglie un tipo di istanza della generazione precedente che non è disponibile nelle tre zone di disponibilità, si verifica lo scenario seguente:

    • Se si scelgono tre zone di disponibilità per il dominio, OpenSearch Service genera un errore. Scegliere un tipo di istanza diverso e riprovare.

    • Se sono state scelte due zone di disponibilità per il dominio, OpenSearch Service distribuisce i nodi principali dedicati tra due zone.

  • Non tutte le regioni AWS hanno tre zone di disponibilità. In queste regioni, è possibile configurare solo un dominio per l'utilizzo di due zone (e OpenSearch Service può solo distribuire nodi principali dedicati tra due zone).

Interruzioni delle zone di disponibilità

I tempi di inattività per le zone di disponibilità sono rari, ma si verificano. La tabella seguente elenca diverse configurazioni con Multi-AZ e comportamenti durante i tempi di inattività.

Numero di zone di disponibilità in una regione Numero delle zone di disponibilità scelte Numero di nodi principali dedicati Comportamento nel caso in cui una zona di disponibilità subisca un'interruzione
2 o più 2 0

Tempo di inattività. Il cluster perde metà dei propri nodi di dati e deve sostituirne almeno uno nella zona di disponibilità rimanente prima di poter eleggere un nodo master.

2 2 3

Possibilità di tempi di inattività 50/50. OpenSearch Service distribuisce due nodi master dedicati in una zona di disponibilità e uno nell'altra:

  • Se la zona di disponibilità con un nodo master dedicato subisce un'interruzione, i due nodi master dedicati nella zona di disponibilità rimanente possono scegliere un nodo master.

  • Se la zona di disponibilità con due nodi master dedicati subisce un'interruzione, il cluster non è disponibile fino a quando la zona di disponibilità rimanente viene ripristinata.

3 o più 2 3

Nessun tempo di inattività. OpenSearch Service distribuisce automaticamente i nodi master dedicati su tre zone di disponibilità, perciò i restanti due nodi principali dedicati possono sceglierne uno master.

3 o più 3 0

Nessun tempo di inattività. Circa due terzi dei nodi di dati sono ancora disponibili per eleggere un nodo master.

3 o più 3 3

Nessun tempo di inattività. I restanti due nodi master dedicati possono scegliere un nodo master.

In tutte le configurazioni, indipendentemente dalla causa, i guasti del cluster possono portare i nodi dei dati rimanenti del cluster a sperimentare un periodo di intensificazione del carico, mentre OpenSearch Service configura automaticamente i nuovi nodi per sostituire quelli mancanti.

Ad esempio, nel caso in cui si verificasse l'interruzione di una zona di disponibilità in una configurazione a tre zone, due terzi dei nodi dei dati devono elaborare tutte le richieste al cluster. Mentre elaborano queste richieste, i nodi rimanenti cercano di replicare le partizioni sui nuovi nodi non appena sono disponibili online, con un ulteriore impatto sulle prestazioni. Se la disponibilità è fondamentale per il carico di lavoro, considerare l'aggiunta di risorse al cluster per alleviare questa preoccupazione.

Nota

OpenSearch Service gestisce i domini Multi-AZ in modo trasparente, quindi non è possibile simulare manualmente le interruzioni della zona di disponibilità.