Impatto dei guasti dell'infrastruttura sullo shard in Amazon OpenSearch Service

Impatto dei guasti dell'infrastruttura sullo shard in Amazon OpenSearch Service

Nodo di origine: 1783553

Servizio Amazon OpenSearch è un servizio gestito che semplifica la protezione, la distribuzione e il funzionamento di cluster OpenSearch e legacy Elasticsearch su larga scala nel cloud AWS. Amazon OpenSearch Service esegue il provisioning di tutte le risorse per il tuo cluster, lo avvia e rileva e sostituisce automaticamente i nodi guasti, riducendo il sovraccarico delle infrastrutture autogestite. Il servizio semplifica l'esecuzione di analisi dei log interattive, il monitoraggio delle applicazioni in tempo reale, le ricerche sui siti Web e altro ancora offrendo le ultime versioni di OpenSearch, il supporto per 19 versioni di Elasticsearch (versioni da 1.5 a 7.10) e funzionalità di visualizzazione basate su OpenSearch Dashboards e Kibana (versioni da 1.5 a 7.10).

Nell'ultima versione del software di servizio, abbiamo aggiornato la logica di allocazione degli shard in modo che sia sensibile al carico, in modo che quando gli shard vengono ridistribuiti in caso di errori del nodo, il servizio impedisca ai nodi sopravvissuti di essere sovraccaricati dagli shard precedentemente ospitati sul nodo guasto. Ciò è particolarmente importante per i domini Multi-AZ per fornire prestazioni del cluster coerenti e prevedibili.

Se desideri ulteriori informazioni sulla logica di allocazione degli shard in generale, consulta Demistificazione dell'allocazione dei frammenti di Elasticsearch.

La sfida

Si dice che un dominio Amazon OpenSearch Service è "bilanciato" quando il numero di nodi è distribuito equamente tra le zone di disponibilità configurate e il numero totale di shard è distribuito equamente su tutti i nodi disponibili senza concentrazione di shard di un indice su nessuno nodo. Inoltre, OpenSearch ha una proprietà chiamata "Zone Awareness" che, se abilitata, garantisce che lo shard primario e la sua replica corrispondente siano allocati in diverse zone di disponibilità. Se disponi di più di una copia di dati, disporre di più zone di disponibilità offre una migliore tolleranza agli errori e disponibilità. Nel caso in cui il dominio venga ridimensionato o ridimensionato o durante il guasto dei nodi, OpenSearch ridistribuisce automaticamente gli shard tra i nodi disponibili rispettando le regole di allocazione basate sul riconoscimento della zona.

Sebbene il processo di bilanciamento degli shard assicuri che gli shard siano distribuiti uniformemente tra le zone di disponibilità, in alcuni casi, se si verifica un errore imprevisto in una singola zona, gli shard verranno riallocati ai nodi sopravvissuti. Ciò potrebbe comportare il sovraccarico dei nodi sopravvissuti, con un impatto sulla stabilità del cluster.

Ad esempio, se un nodo in un cluster a tre nodi si interrompe, OpenSearch ridistribuisce gli shard non assegnati, come mostrato nel diagramma seguente. Qui "P" rappresenta una copia di partizione primaria, mentre "R" rappresenta una copia di partizione di replica.

Questo comportamento del dominio può essere spiegato in due parti: durante l'errore e durante il ripristino.

Durante il fallimento

Un dominio distribuito su più zone di disponibilità può incontrare più tipi di errori durante il suo ciclo di vita.

Fallimento completo della zona

Un cluster può perdere una singola zona di disponibilità per una serie di motivi e anche tutti i nodi in quella zona. Oggi, il servizio tenta di posizionare i nodi persi nelle rimanenti zone di disponibilità integre. Il servizio tenta inoltre di ricreare i frammenti persi nei nodi rimanenti pur continuando a seguire le regole di allocazione. Ciò può comportare alcune conseguenze indesiderate.

  • Quando gli shard della zona interessata vengono riallocati in zone sane, attivano ripristini di shard che possono aumentare le latenze poiché consumano ulteriori cicli della CPU e larghezza di banda di rete.
  • Per una configurazione n-AZ, n-copy, (n>1), le zone di disponibilità n-1 sopravvissute vengono allocate con l'ennesima copia dello shard, che può essere indesiderabile in quanto può causare asimmetria nella distribuzione dello shard, che può anche comportare traffico sbilanciato tra i nodi. Questi nodi possono essere sovraccaricati, portando a ulteriori errori.

Guasto zona parziale

In caso di guasto parziale della zona o quando il dominio perde solo alcuni dei nodi in una zona di disponibilità, Amazon OpenSearch Service tenta di sostituire i nodi guasti il ​​più rapidamente possibile. Tuttavia, nel caso in cui la sostituzione dei nodi richieda troppo tempo, OpenSearch prova ad allocare gli shard non assegnati di quella zona nei nodi sopravvissuti nella zona di disponibilità. Se il servizio non è in grado di sostituire i nodi nella zona di disponibilità interessata, potrebbe allocarli nell'altra zona di disponibilità configurata, il che potrebbe distorcere ulteriormente la distribuzione degli shard sia all'interno che all'interno della zona. Anche questo ha conseguenze indesiderate.

  • Se i nodi nel dominio non dispongono di spazio di archiviazione sufficiente per contenere gli shard aggiuntivi, il dominio può essere bloccato in scrittura, con ripercussioni sull'operazione di indicizzazione.
  • A causa della distribuzione asimmetrica degli shard, il dominio potrebbe anche subire un traffico asimmetrico tra i nodi, che può aumentare ulteriormente le latenze o i timeout per le operazioni di lettura e scrittura.

Recupero

Oggi, per mantenere il numero di nodi desiderato del dominio, Amazon OpenSearch Service avvia i nodi di dati nelle restanti zone di disponibilità integre, in modo simile agli scenari descritti nella sezione precedente relativa agli errori. Per garantire una corretta distribuzione dei nodi in tutte le zone di disponibilità dopo un incidente di questo tipo, era necessario un intervento manuale da parte di AWS.

Cosa sta cambiando

Per migliorare la gestione complessiva degli errori e ridurre al minimo l'impatto dell'errore sull'integrità e sulle prestazioni del dominio, Amazon OpenSearch Service sta eseguendo le seguenti modifiche:

  • Consapevolezza della zona forzata: OpenSearch dispone di una configurazione di bilanciamento degli shard preesistente chiamata consapevolezza forzata che viene utilizzata per impostare le zone di disponibilità a cui devono essere allocati gli shard. Ad esempio, se hai un attributo di consapevolezza chiamato zona e configuri i nodi in zone1 ed zone2, puoi utilizzare la consapevolezza forzata per impedire a OpenSearch di allocare le repliche se è disponibile una sola zona:
cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

Con questa configurazione di esempio, se avvii due nodi con node.attr.zone impostato zone1 e crea un indice con cinque shard e una replica, OpenSearch crea l'indice e alloca i cinque shard primari ma nessuna replica. Le repliche vengono allocate solo una volta che i nodi con node.attr.zone impostato zone2 sono disponibili.

Amazon OpenSearch Service utilizzerà la configurazione di riconoscimento forzato sui domini Multi-AZ per garantire che gli shard vengano allocati solo in base alle regole di riconoscimento della zona. Ciò impedirebbe l'improvviso aumento del carico sui nodi delle zone di disponibilità sane.

  • Allocazione dei frammenti in base al carico: Amazon OpenSearch Service prenderà in considerazione fattori come la capacità assegnata, la capacità effettiva e le copie totali di shard per calcolare se un nodo è sovraccarico di più shard in base alla media prevista di shard per nodo. Impedirebbe l'assegnazione di shard quando qualsiasi nodo ha allocato un numero di shard che va oltre questo limite.

Note: che qualsiasi non assegnato primario la copia sarebbe comunque consentita sul nodo in overload per impedire al cluster qualsiasi perdita di dati imminente.

Allo stesso modo, per risolvere il problema del ripristino manuale (come descritto nella sezione Ripristino sopra), Amazon OpenSearch Service sta anche apportando modifiche al suo componente di ridimensionamento interno. Con le modifiche più recenti in atto, Amazon OpenSearch Service non avvierà i nodi nelle rimanenti zone di disponibilità anche quando passa attraverso lo scenario di errore descritto in precedenza.

Visualizzare il comportamento attuale e nuovo

Ad esempio, un dominio Amazon OpenSearch Service è configurato con 3-AZ, 6 nodi di dati, 12 shard primari e 24 shard di replica. Il dominio viene fornito tra AZ-1, AZ-2 e AZ-3, con due nodi in ciascuna delle zone.

Assegnazione shard corrente:
Numero totale di shard: 12 primari + 24 replica = 36 shard
Numero di zone di disponibilità: 3
Numero di shard per zona (la consapevolezza della zona è vera): 36/3 = 12
Numero di nodi per zona di disponibilità: 2
Numero di shard per nodo: 12/2 = 6

Il diagramma seguente fornisce una rappresentazione visiva della configurazione del dominio. I cerchi indicano il numero di shard assegnati al nodo. Amazon OpenSearch Service assegnerà sei shard per nodo.

Durante un guasto parziale della zona, in cui un nodo in AZ-3 si guasta, il nodo guasto viene assegnato alla zona rimanente e gli shard nella zona vengono ridistribuiti in base ai nodi disponibili. Dopo le modifiche sopra descritte, il cluster non creerà un nuovo nodo né ridistribuirà gli shard dopo il guasto del nodo.


Nel diagramma sopra, con la perdita di un nodo in AZ-3, Amazon OpenSearch Service tenterà di lanciare la capacità sostitutiva nella stessa zona. Tuttavia, a causa di un'interruzione, la zona potrebbe essere danneggiata e non riuscirebbe ad avviare la sostituzione. In tal caso, il servizio tenta di avviare la capacità in deficit in un'altra zona integra, il che potrebbe portare a uno squilibrio tra le zone di disponibilità. I frammenti nella zona interessata vengono inseriti nel nodo sopravvissuto nella stessa zona. Tuttavia, con il nuovo comportamento, il servizio tenterà di avviare capacità nella stessa zona ma eviterà di avviare capacità in deficit in altre zone per evitare squilibri. L'allocatore di shard assicurerebbe inoltre che i nodi sopravvissuti non vengano sovraccaricati.


Allo stesso modo, nel caso in cui tutti i nodi in AZ-3 vengano persi o AZ-3 venga danneggiato, Amazon OpenSearch Service richiama i nodi persi nella restante zona di disponibilità e ridistribuisce anche gli shard sui nodi. Tuttavia, dopo le nuove modifiche, Amazon OpenSearch Service non assegnerà i nodi alla zona rimanente né tenterà di riassegnare i frammenti persi alla zona rimanente. Amazon OpenSearch Service attenderà che il ripristino avvenga e che il dominio torni alla configurazione originale dopo il ripristino.

Se il tuo dominio non dispone di una capacità sufficiente per sopportare la perdita di una zona di disponibilità, potresti riscontrare un calo della velocità effettiva per il tuo dominio. Si consiglia pertanto vivamente di seguire le best practice durante il dimensionamento del dominio, il che significa disporre di risorse sufficienti per sopportare la perdita di un singolo guasto della zona di disponibilità.


Attualmente, una volta che il dominio viene ripristinato, il servizio richiede un intervento manuale per bilanciare la capacità tra le zone di disponibilità, che comporta anche spostamenti di shard. Tuttavia, con il nuovo comportamento, non è necessario alcun intervento durante il processo di ripristino perché la capacità ritorna nella zona interessata e anche gli shard vengono allocati automaticamente ai nodi ripristinati. Ciò garantisce che non vi siano priorità concorrenti sulle risorse rimanenti.

Che cosa ci si può aspettare

Dopo aver aggiornato il tuo dominio Amazon OpenSearch Service all'ultima versione del software del servizio, i domini che sono stati configurato con le migliori pratiche avrà prestazioni più prevedibili anche dopo aver perso uno o più nodi di dati in una zona di disponibilità. Ci saranno casi ridotti di sovrassegnazione di shard in un nodo. È buona norma fornire una capacità sufficiente per essere in grado di tollerare un guasto di una singola zona

A volte potresti vedere un dominio diventare giallo durante tali errori imprevisti poiché non assegneremo frammenti di replica ai nodi sovraccarichi. Tuttavia, ciò non significa che ci sarà una perdita di dati in un dominio ben configurato. Ci assicureremo comunque che tutte le primarie vengano assegnate durante le interruzioni. È in atto un ripristino automatizzato, che si occuperà di bilanciare i nodi nel dominio e di garantire che le repliche vengano assegnate una volta ripristinato l'errore.

Aggiorna il software del servizio del tuo dominio Amazon OpenSearch Service per applicare queste nuove modifiche al tuo dominio. Maggiori dettagli sul processo di aggiornamento del software di servizio sono disponibili nel Documentazione di Amazon OpenSearch Service.

Conclusione

In questo post abbiamo visto come Amazon OpenSearch Service ha recentemente migliorato la logica per distribuire nodi e shard tra le zone di disponibilità durante le interruzioni di zona.

Questa modifica aiuterà il servizio a garantire prestazioni più coerenti e prevedibili durante i guasti del nodo o della zona. I domini non vedranno alcuna latenza aumentata o blocchi di scrittura durante l'elaborazione di scritture e letture, che a volte emergevano prima a causa della sovrassegnazione di shard sui nodi.


Circa gli autori

Bukhtawar Khan è un Senior Software Engineer che lavora su Amazon OpenSearch Service. Si interessa di sistemi distribuiti e autonomi. È un collaboratore attivo di OpenSearch.

Anshu Agarwal è un ingegnere software senior che lavora su AWS OpenSearch presso Amazon Web Services. È appassionata di risolvere problemi legati alla costruzione di sistemi scalabili e altamente affidabili.

Shourya Dutta Biswas è un ingegnere del software che lavora su AWS OpenSearch presso Amazon Web Services. È appassionato di creare sistemi distribuiti altamente resilienti.

Rishab Nahata è un ingegnere del software che lavora su OpenSearch presso Amazon Web Services. È affascinato dalla risoluzione di problemi nei sistemi distribuiti. Collabora attivamente con OpenSearch.

Ranjith Ramachandra è un Engineering Manager che lavora su Amazon OpenSearch Service presso Amazon Web Services.

Jon Handler è un Senior Principal Solutions Architect, specializzato nelle tecnologie di ricerca AWS: Amazon CloudSearch e Amazon OpenSearch Service. Con sede a Palo Alto, aiuta un'ampia gamma di clienti a distribuire correttamente e a far funzionare bene i carichi di lavoro di ricerca e analisi dei log.

Timestamp:

Di più da Big Data di AWS