Dimensionamento dei domini Amazon OpenSearch Service - Amazon OpenSearch Service

Dimensionamento dei domini Amazon OpenSearch Service

Non esiste un metodo di dimensionamento infallibile dei domini Amazon OpenSearch Service, ma partendo da una comprensione delle esigenze di archiviazione, del servizio e dello stesso OpenSearch, sarà possibile effettuare una stima iniziale efficace delle esigenze di hardware. Questa stima può essere utilizzata come punto di partenza per l'aspetto più importante del dimensionamento dei domini: testarli con carichi di lavoro rappresentativi e monitorare le prestazioni.

Calcolo dei requisiti di archiviazione

La maggior parte dei carichi di lavoro di OpenSearch rientra in una delle due categorie descritte di seguito:

  • Indice di lunga durata: scrivi il codice che elabora i dati in uno o più indici OpenSearch e quindi aggiorna tali indici periodicamente man mano che i dati di origine cambiano. Alcuni esempi comuni riguardano la ricerca su siti Web, documenti ed e-commerce.

  • Indici in sequenza: i dati fluiscono in modo continuo in un set di indici temporanei, con un periodo di indicizzazione e una finestra di conservazione, ad esempio un set di indici giornalieri che viene conservato per due settimane. Alcuni esempi comuni sono le analisi di log, l'elaborazione delle serie temporali e le analisi clickstream.

Per i carichi di lavoro dell'indice di lunga durata, è possibile esaminare i dati di origine sul disco e determinare facilmente la quantità di spazio di archiviazione che consuma. Se i dati provengono da più origini, devi aggiungere tali origini.

Per gli indici in sequenza, puoi moltiplicare la quantità di dati generati durante un periodo di tempo rappresentativo dal periodo di conservazione. Ad esempio, se generi 200 MiB di dati di log all'ora, questi corrispondono a 4,7 GiB al giorno, 66 GiB di dati in qualsiasi momento, se disponi di un periodo di retention di due settimane.

Le dimensioni dei dati di origine, tuttavia, sono solo un aspetto delle esigenze di archiviazione. Devi anche considerare quanto segue:

  1. Numero di repliche: ogni replica è una copia completa di un indice e richiede la stessa quantità di spazio su disco. Per impostazione predefinita, ogni indice OpenSearch dispone di una replica. Ne consigliamo almeno una per evitare la perdita di dati. Le repliche, inoltre, migliorano le prestazioni di ricerca, perciò potresti volerne di più se hai un carico di lavoro gravoso in lettura. Utilizzare PUT /my-index/_settings per aggiornare l'impostazione number_of_replicas per l'indice.

  2. Sovraccarico di indicizzazione di OpenSearch: le dimensioni del disco di un indice variano, ma sono spesso il 10% più grande dei dati di origine. Dopo l'indicizzazione dei dati, è possibile utilizzare l'API _cat/indices?v e il valore pri.store.size per calcolare l'overhead esatto. _cat/allocation?v fornisce anche un riepilogo utile.

  3. Spazio riservato per il sistema operativo: per impostazione predefinita, Linux riserva il 5% del file system per l'utente root per i processi critici, il ripristino del sistema e per evitare problemi di frammentazione del disco.

  4. Sovraccarico di OpenSearch Service: OpenSearch Service riserva il 20% dello spazio di archiviazione di ogni istanza (fino a 20 GiB) per l'unione di segmenti, log e altre operazioni interne.

    Data la dimensione massima di 20 GiB, la quantità totale di spazio riservato può variare notevolmente in funzione del numero di istanze nel tuo dominio. Ad esempio, un dominio può avere tre istanze m6g.xlarge.search, ognuna con 500 GiB di spazio di archiviazione, per un totale di 1,46 TiB. In questo caso, il totale di spazio riservato è solo 60 GiB. Un altro dominio può avere 10 istanze m3.medium.search, ognuna con 100 GiB di spazio di archiviazione, per un totale di 0,98 TiB. In questo caso, il totale di spazio riservato è di 200 GiB, anche se il primo dominio è il 50% più grande.

    Nella formula seguente viene applicata una stima «peggiore» per il sovraccarico che include spazio libero aggiuntivo per ridurre al minimo l'impatto degli errori dei nodi e delle interruzioni della zona di disponibilità.

Riepilogando, se si dispone di 66 GiB di dati in qualsiasi momento e si desidera una replica, il requisito di archiviazione minimo è più vicino a 66* 2* 1,1/0,95/0,8 = 191 GiB. Puoi generalizzare il calcolo come indicato di seguito:

Dati di origine * (1 + Numero di repliche) * (1 + Sovraccarico di indicizzazione)/(1 - Spazio riservato Linux)/(1 - Sovraccarico OpenSearch Service) = Requisito di archiviazione minimo

In alternativa, puoi utilizzare questa versione semplificata:

Dati di origine* (1+Numero di repliche)* 1,45 = Requisito di storage minimo

Lo spazio di archiviazione insufficiente è una delle cause più frequenti dell'instabilità del cluster, quindi devi verificare i numeri quando scegli i tipi di istanza, i conteggi dell'istanza e i volumi di archiviazione.

Esistono altre considerazioni di archiviazione:

Scelta del numero di partizioni

Dopo aver individuato i requisiti di archiviazione, è possibile esaminare la strategia di indicizzazione. Per impostazione predefinita, in OpenSearch Service, ogni indice è diviso in cinque partizioni primarie e una replica (in totale 10 partizioni). Poiché non è possibile modificare facilmente il numero di partizioni primarie per un indice esistente, è necessario decidere il numero di partizioni prima di indicizzare il primo documento.

L'obiettivo generale della scelta di un numero di partizioni è distribuire un indice in modo uniforme su tutti i nodi di dati del cluster. Tuttavia, queste partizioni non devono essere troppo grandi o troppo numerose. Una buona regola è cercare di mantenere le dimensioni delle partizioni tra 10 e 30 GiB per i carichi di lavoro in cui la latenza di ricerca è un obiettivo chiave delle prestazioni e 30-50 GiB per i carichi di lavoro pesanti in termini di scrittura, come l'analisi dei registri. Partizioni di grandi dimensioni possono rendere difficoltoso il ripristino di OpenSearch, ma poiché ciascuna partizione impiega una quantità di CPU e memoria, avere troppi partizioni piccole può causare problemi di prestazioni ed errori di memoria. In altre parole, le partizioni devono essere abbastanza piccole da essere gestite dall'istanza OpenSearch Service sottostante, ma non così piccole da gravare inutilmente sull'hardware.

Ad esempio, se disponi di 66 GiB di dati. Non si prevede che il numero aumenti nel corso del tempo e si desidera mantenere le dimensioni delle partizioni attorno a 30 GiB ciascuna. Il numero di partizioni perciò deve essere circa 66* 1,1/30 = 3. Puoi generalizzare il calcolo come indicato di seguito:

(Dati di origine +Spazio per crescere)* (1+Gestione indicizzazione)/Dimensione desiderata dello shard = Numero approssimativo di shard primari

Questa equazione aiuta a compensare la crescita dei dati nel tempo. Se si prevede che quegli stessi 66 GiB di dati quadruplicheranno l'anno successivo, il numero approssimativo di partizioni sarà (66+198) * 1,1/30 = 10. Ricorda, tuttavia, che non disponi ancora di questi 198 GiB di dati aggiuntivi. Verificare che la preparazione per il futuro non crei partizioni inutilmente piccole che consumano enormi quantità di CPU e memoria nel presente. In questo caso, 66* 1,1/10 partizioni = 7,26 GiB per partizione. Queste partizioni consumeranno risorse aggiuntive e sono inferiori all'intervallo di dimensione consigliato. Si potrebbe prendere in considerazione l'approccio intermedio di sei partizioni, che lascia partizioni da 12 GiB subito e partizioni da 48 GiB in futuro. Quindi, si potrebbe iniziare con tre partizioni e reindicizzare i dati quando le partizioni superano i 50 GiB.

Un problema molto meno comune comporta la limitazione del numero di partizioni per nodo. Se si dimensionano le partizioni in modo appropriato, in genere si esaurisce lo spazio su disco molto prima di rispettare questo limite. Ad esempio, un'istanza m6g.large.search ha una dimensione massima del disco di 512 GiB. Se si rimane al di sotto dell'80% di utilizzo del disco e si dimensionano le partizioni a 20 GiB, può ospitare circa 20 partizioni. OpenSearch 7.x e versioni successive hanno un limite di 1.000 partizioni per nodo. Per regolare il numero massimo di partizioni per nodo, configura l'impostazione cluster.max_shards_per_node. Consulta un esempio qui.

Il dimensionamento appropriato delle partizioni mantiene l'utente quasi sempre al di sotto di questo limite, ma è anche possibile considerare il numero di partizioni per ogni GiB di heap Java. Su un dato nodo, non avere più di 20 partizioni per GiB di heap Java. Ad esempio, un'istanza m5.large.search ha un heap di 4 GiB, quindi ogni nodo non deve avere più di 80 partizioni. A quel numero di partizioni, ogni partizione ha una dimensione di circa 5 GiB, il che è ben al di sotto della nostra raccomandazione.

Scelta del tipo di istanza e test

Dopo aver calcolato i requisiti di archiviazione e scelto il numero di partizioni di cui si ha bisogno, è possibile iniziare a prendere decisioni sull'hardware. I requisiti hardware variano in modo significativo in base al carico di lavoro, ma possiamo comunque offrire alcune raccomandazioni di base.

In generale, i limiti di archiviazione per ogni tipo di istanza si mappano sulla quantità di CPU e memoria di cui si potrebbe aver bisogno per i carichi di lavoro leggeri. Ad esempio, un'istanza m6g.large.search dispone di dimensioni di volume EBS massime di 512 GiB, 2 core vCPU e 8 GiB di memoria. Se il cluster dispone di molte partizioni, esegue aggregazioni fiscali, aggiorna frequentemente i documenti o elabora un numero elevato di query, tali risorse potrebbero non essere sufficienti per le tue esigenze. Se si ritiene che il cluster rientri in una di queste categorie, provare a partire da una configurazione più vicina a 2 core vCPU e a 8 GiB di memoria per ogni 100 GiB di archiviazione.

Suggerimento

Per un riepilogo delle risorse hardware allocate a ciascun tipo di istanza, consultare Prezzi di Amazon OpenSearch Service.

Tuttavia, anche tali risorse potrebbero essere insufficienti. Alcuni utenti OpenSearch segnalano che devono utilizzare più volte tali risorse per soddisfare i requisiti. Trovare l'hardware appropriato per il tuo carico di lavoro significa fare una stima iniziale efficace, effettuare test con carichi di lavoro rappresentativi, implementare eventuali modifiche ed effettuare nuovamente il test:

Fase 1: Esecuzione di una stima iniziale

Per iniziare, è consigliabile adottare un minimo di tre nodi per evitare potenziali problemi con OpenSearch, come lo split brain (ovvero, quando un intervallo di comunicazione porta a un cluster con due nodi principale). Se si dispone di tre nodi master dedicati, consigliamo un minimo di due nodi di dati per la replica.

Fase 2: Calcolo dei requisiti di archiviazione per nodo

Se si ha un requisito di archiviazione di 184 GiB e il numero minimo raccomandato di tre nodi, è possibile utilizzare l'equazione 184/3 = 61 GiB per trovare la quantità di spazio di archiviazione richiesto da ogni nodo. In questo esempio, è possibile selezionare tre istanze m6g.large.search, di cui ognuna utilizza un volume di archiviazione EBS di 90 GiB in modo da disporre di una rete di sicurezza e di spazio per la crescita nel corso del tempo. Questa configurazione fornisce 6 core vCPU e 24 GiB di memoria, quindi è ideale per i carichi di lavoro più leggeri.

Per un esempio più sostanziale, considerare un requisito di archiviazione di 14 TiB e un carico di lavoro pesante. In questo caso, è possibile scegliere di avviare il test con 2* 144 = 288 core vCPU e 8* 144 = 1152 GiB di memoria. Questi numeri portano a circa 18 istanze i3.4xlarge.search. Se non è necessaria l'archiviazione veloce locale, è possibile anche testare 18 istanze r6g.4xlarge.search, ciascuna con un volume di archiviazione EBS di 1 TiB.

Se il cluster include centinaia di terabyte di dati, vedi Scala in petabyte nel servizio OpenSearch di Amazon.

Fase 3: Esecuzione di test rappresentativi

Dopo aver configurato il cluster, puoi aggiungere gli indici usando il numero di partizioni calcolato in precedenza, effettuare test rappresentativi del client utilizzando un set di dati realistico e monitorare i parametri CloudWatch per vedere in che modo il cluster gestisce il carico di lavoro.

Fase 4: Riuscita o iterazione

Se le prestazioni soddisfano le esigenze, i test hanno esito positivo e i parametri CloudWatch sono normali, il cluster è pronto per l'utilizzo. Ricordarsi di impostare gli allarmi CloudWatch per rilevare l'uso di risorse non integre.

Se le prestazioni non sono accettabili, i test hanno esito negativo o CPUUtilization o JVMMemoryPressure sono elevati, potrebbe essere necessario scegliere un altro tipo di istanza (o aggiungere istanze) e continuare il test. Man mano che si aggiungono istanze, OpenSearch ribilancia automaticamente la distribuzione delle partizioni in tutto il cluster.

Poiché è più semplice misurare le capacità in eccesso di un cluster con più potenza rispetto al disavanzo di uno con meno potenza, consigliamo di iniziare con un cluster di dimensioni maggiori rispetto alle tue esigenze. Successivamente, suggeriamo di testare e ridimensionare fino a un cluster efficiente che disponga di risorse aggiuntive per garantire operazioni stabili durante i periodi di maggiore attività.

I cluster di produzione o i cluster con stati complessi traggono vantaggio dai nodi master dedicati, che migliorano le prestazioni e l'affidabilità del cluster.