Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Dimensionamento dei domini Amazon OpenSearch Service

Non esiste un metodo perfetto per dimensionare i domini di Amazon OpenSearch Service. Tuttavia, partendo da una comprensione delle tue esigenze di storage, del servizio e di OpenSearch se stesso, puoi fare una stima iniziale approfondita delle tue esigenze 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 OpenSearch carichi di lavoro rientra in una delle due grandi categorie:

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. È·necessario anche considerare quanto segue:

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 del servizio) = requisito minimo di archiviazione OpenSearch

In alternativa, puoi utilizzare questa versione semplificata:

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

Lo spazio di archiviazione insufficiente è una delle cause più comuni di instabilità del cluster. Pertanto quando scegli tipi di istanze, numero di istanze e volumi di archiviazione dovresti controllare i numeri.

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 è suddiviso in cinque shard primari e una replica (per un totale di 10 shard). Questo comportamento è diverso da quello open source OpenSearch, che utilizza per impostazione predefinita uno shard primario e uno di replica. 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 log.

Gli shard di grandi dimensioni possono rendere difficile il ripristino in caso di guasto, ma poiché ogni shard utilizza una certa quantità di memoria, avere troppi shard piccoli può causare problemi di prestazioni CPU ed errori di memoria insufficiente. OpenSearch In altre parole, gli shard devono essere sufficientemente piccoli da consentire all'istanza di OpenSearch Service sottostante di gestirli, ma non così piccoli da sovraccaricare inutilmente l'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 della partizione = Numero approssimativo di partizioni primarie

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. Assicurati che questa preparazione per il futuro non crei frammenti inutilmente minuscoli che consumano enormi quantità di CPU 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. Potreste prendere in considerazione l'idea di optare per middle-of-the-road un approccio a sei shard, che vi lascerà con shard da 12 GiB oggi e shard 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. Elasticsearch 7. x e versioni successive, e tutte le versioni di OpenSearch, hanno un limite di 1.000 shard per nodo. Per regolare il numero massimo di partizioni per nodo, configura l'impostazione cluster.max_shards_per_node. Per un esempio, consulta Impostazioni del cluster.

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 25 partizioni per GiB di heap Java. Ad esempio, un'istanza m5.large.search ha una memoria heap di 4 GiB, quindi ogni nodo non deve avere più di 100 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 corrispondono alla quantità CPU e alla memoria necessarie per carichi di lavoro leggeri. Ad esempio, un'm6g.large.searchistanza ha una dimensione massima del EBS volume di 512 GiB, 2 CPU core v 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 il tuo cluster rientra in una di queste categorie, prova a iniziare con una configurazione più vicina a 2 v CPU core e 8 GiB di memoria per ogni 100 GiB di requisiti di storage.

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

Fase 1: Esecuzione di una stima iniziale

Per iniziare, consigliamo un minimo di tre nodi per evitare potenziali OpenSearch problemi, come uno stato cerebrale diviso (quando un'interruzione della comunicazione porta a un cluster con due nodi principali). 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 hai un requisito di archiviazione di 184 GiB e il numero minimo raccomandato di tre nodi, per trovare la quantità di spazio di archiviazione richiesta da ogni nodo puoi utilizzare l'equazione 184/3 = 61 GiB. In questo esempio, puoi selezionare tre m6g.large.search istanze, ognuna delle quali utilizza un volume di EBS archiviazione da 90 GiB, in modo da avere una rete di sicurezza e un certo margine di crescita nel tempo. Questa configurazione offre CPU core da 6 v e 24 GiB di memoria, quindi è adatta a 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, puoi scegliere di iniziare il test con 2 CPU core da 144 = 288 v e 8 x 144 = 1152 GiB di memoria. Questi numeri portano a circa 18 istanze i3.4xlarge.search. Se non ti serve lo storage locale veloce, puoi anche testare 18 r6g.4xlarge.search istanze, ognuna delle quali utilizza un volume di archiviazione da 1 TiBEBS.

Se il cluster include centinaia di terabyte di dati, consulta Scalabilità in petabyte in Amazon Service OpenSearch .

Fase 3: Esecuzione di test rappresentativi

Dopo aver configurato il cluster, puoi aggiungere gli indici utilizzando il numero di shard calcolato in precedenza, eseguire alcuni test rappresentativi sui client utilizzando un set di dati realistico e monitorare le CloudWatch metriche per vedere come il cluster gestisce il carico di lavoro.

Fase 4: Riuscita o iterazione

Se le prestazioni soddisfano le tue esigenze, i test hanno esito positivo e le CloudWatch metriche sono normali, il cluster è pronto per l'uso. Ricorda di impostare CloudWatch allarmi per rilevare un utilizzo non corretto delle risorse.

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 aggiungi istanze, riequilibra OpenSearch automaticamente la distribuzione degli shard 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.