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
Il dimensionamento consente di determinare il tipo di istanza, il numero di nodi di dati e i requisiti di storage corretti per l'ambiente di destinazione. Ti consigliamo di ridimensionare prima in base allo spazio di archiviazione e poi in base CPUs al. Se stai già utilizzando Elasticsearch oppure OpenSearch, il dimensionamento rimarrà generalmente lo stesso. Tuttavia, è necessario identificare il tipo di istanza equivalente all'ambiente corrente. Per determinare la dimensione corretta, consigliamo di utilizzare le seguenti linee guida.
Storage
Il dimensionamento del cluster inizia con la definizione dei requisiti di archiviazione. Identifica lo storage raw di cui hai bisogno per il tuo cluster. Ciò viene determinato valutando i dati generati dal sistema di origine (ad esempio, i server che generano i log o le dimensioni grezze del catalogo dei prodotti). Dopo aver identificato la quantità di dati grezzi a tua disposizione, utilizza la formula seguente per calcolare i requisiti di archiviazione. Puoi quindi utilizzare il risultato come punto di partenza per il tuo PoC.
storage needed = (daily source data in bytes × 1.45)
(number_of_replicas + 1) × number of days retained
La formula prende in considerazione quanto segue:
-
La dimensione su disco di un indice varia, ma spesso è superiore del 10% rispetto ai dati di origine.
-
Il sovraccarico del sistema operativo del 5% viene riservato da Linux al ripristino del sistema e alla protezione dai problemi di deframmentazione del disco.
-
OpenSearch riserva il 20 percento dello spazio di archiviazione di ogni istanza per le unioni di segmenti, i log e altre operazioni interne.
-
Consigliamo di mantenere il 10% di storage aggiuntivo per ridurre al minimo l'impatto dei guasti dei nodi e delle interruzioni delle zone di disponibilità.
Nel complesso, questi costi generali e queste prenotazioni richiedono il 45% di spazio aggiuntivo in base ai dati grezzi effettivi presenti nella fonte. Ecco perché moltiplichi i dati di origine per 1,45. Quindi, moltiplicalo per il numero di copie dei dati (ad esempio, una copia principale più il numero di repliche che utilizzerai). Il numero di repliche dipende dai requisiti di resilienza e velocità effettiva. Per un caso d'uso medio, si inizia con una replica principale e una replica. Infine, moltiplicalo per il numero di giorni in cui desideri conservare i dati in un livello di storage a caldo.
Amazon OpenSearch Service offre livelli di archiviazione a caldo, a caldo e a freddo. Il livello di archiviazione a temperatura ambiente utilizza UltraWarm lo storage. UltraWarm offre un modo conveniente per archiviare grandi quantità di dati di sola lettura su Amazon Service. OpenSearch I nodi di dati standard utilizzano lo storage a caldo, che assume la forma di store di istanze o volumi Amazon Elastic Block Store (Amazon EBS) collegati a ciascun nodo. L'hot storage offre le prestazioni più veloci possibili per l'indicizzazione e la ricerca di nuovi dati. UltraWarm i nodi utilizzano Amazon Simple Storage Service (Amazon S3) come storage e una sofisticata soluzione di caching per migliorare le prestazioni. Per gli indici su cui non scrivi attivamente o esegui query meno frequentemente e che non hanno gli stessi requisiti di prestazioni, UltraWarm offre costi per GiB di dati notevolmente inferiori. Per ulteriori informazioni in merito UltraWarm, consulta la documentazione AWS.
Quando crei un dominio OpenSearch di servizio e utilizzi lo storage a caldo, potresti dover definire la dimensione del volume EBS. Dipende dalla scelta del tipo di istanza per i nodi di dati. Puoi utilizzare la stessa formula dei requisiti di storage per determinare la dimensione del volume per le istanze supportate da Amazon EBS. Consigliamo di utilizzare volumi gp3 per famiglie di istanze T3, R5, R6G, M5, m5G, C5 e C6g di ultima generazione. Utilizzando i volumi Amazon EBS gp3, puoi fornire prestazioni indipendentemente dalla capacità di storage. I volumi gp3 di Amazon EBS offrono anche prestazioni di base migliori, a un costo per GB inferiore del 9,6% rispetto ai volumi gp2 esistenti su Service. OpenSearch Con gp3, ottieni anche uno storage più denso sulle famiglie di istanze R5, R6g, M5 e M6g, che può aiutarti a ottimizzare ulteriormente i costi. Puoi creare volumi EBS fino alla quota supportata. Per ulteriori informazioni sulle quote, consulta la sezione Quote OpenSearch del servizio Amazon.
Per i nodi di dati che dispongono di unità NVM Express (NVMe), come le istanze i3 e r6gd, la dimensione del volume è fissa, quindi i volumi EBS non sono un'opzione.
Numero di nodi e tipi di istanze
Il numero di nodi si basa sul numero di nodi CPUs necessari per gestire il carico di lavoro. Il numero di CPUs si basa sul numero di frammenti. Un indice in OpenSearch è composto da più frammenti. Quando si crea un indice, si specifica il numero di frammenti per l'indice. Pertanto, è necessario effettuare le seguenti operazioni:
-
Calcola il numero totale di shard che intendi archiviare nel dominio.
-
Determina la CPU.
-
Trova il tipo di nodo e il numero di nodi più convenienti che ti offra il numero di nodi CPUs e lo spazio di archiviazione richiesti.
Di solito si tratta di un punto di partenza. Esegui dei test per determinare che la dimensione stimata soddisfi i tuoi requisiti funzionali e non funzionali.
Determinazione della strategia di indicizzazione e del numero di frammenti
Dopo aver conosciuto i requisiti di archiviazione, puoi decidere quanti indici ti servono e identificare il numero di frammenti per ciascuno. In genere, i casi d'uso della ricerca hanno uno o pochi indici, ciascuno dei quali rappresenta un'entità o un catalogo ricercabile. Per i casi d'uso dell'analisi dei log, un indice può rappresentare un file di registro giornaliero o settimanale. Dopo aver deciso il numero di indici, inizia con le seguenti linee guida sulla scala e determina il numero di frammenti appropriato:
-
Casi d'uso della ricerca: 10-30 GB/shard
-
Casi d'uso per l'analisi dei log: 50 GB/shard
Puoi dividere il volume totale di dati in un unico indice per la dimensione del frammento a cui miri nel tuo caso d'uso. Questo ti darà il numero di frammenti per l'indice. L'identificazione del numero totale di shard vi aiuterà a trovare i tipi di istanza più adatti al vostro carico di lavoro. I frammenti non devono essere né troppo grandi né troppo numerosi. Gli shard di grandi dimensioni possono rendere difficile il OpenSearch ripristino in caso di guasto, ma poiché ogni shard utilizza una certa quantità di CPU e memoria, avere troppi shard piccoli può causare problemi di prestazioni ed errori. out-of-memory Inoltre, uno squilibrio nell'allocazione degli shard ai nodi di dati può portare a distorsioni. Quando disponi di indici con più partizioni, prova a rendere il conteggio delle partizioni un multiplo pari del conteggio dei nodi di dati. Ciò aiuta a garantire che le partizioni siano distribuite uniformemente tra i nodi di dati e previene i nodi ad accesso frequente. Ad esempio, se disponi di 12 partizioni primarie, il numero di nodi di dati deve essere 2, 3, 4, 6 o 12. Tuttavia, il numero delle partizioni è secondario rispetto alla dimensione delle partizioni; se disponi di 5 GiB di dati, dovresti comunque usare una singola partizione. Il bilanciamento uniforme del numero di shard di replica nella zona di disponibilità aiuta anche a migliorare la resilienza.
Utilizzo CPU
Il passaggio successivo consiste nell'identificare quanti ne servono per il carico di CPUs lavoro. Ti consigliamo di iniziare con un numero di CPU 1,5 volte superiore a quello degli shard attivi. Uno shard attivo è qualsiasi shard per un indice che riceve scritture consistenti. Utilizzate il numero di shard primario per determinare gli shard attivi per gli indici che ricevono richieste di lettura o scrittura importanti. Per l'analisi dei log, in genere è attivo solo l'indice corrente. Per i casi d'uso nella ricerca, tutti gli shard primari verranno considerati shard attivi. Sebbene raccomandiamo 1,5 CPU per shard attivo, ciò dipende in larga misura dal carico di lavoro. Assicurati di testare e monitorare l'utilizzo della CPU e di ridimensionarlo di conseguenza.
Una procedura ottimale per mantenere l'utilizzo della CPU consiste nell'assicurarsi che il dominio del OpenSearch servizio disponga di risorse sufficienti per eseguire le relative attività. Un cluster che utilizza costantemente la CPU può compromettere la stabilità del cluster. Quando il cluster è sovraccarico, il OpenSearch Servizio bloccherà le richieste in arrivo, con conseguente rifiuto delle richieste. Questo serve a proteggere il dominio da eventuali errori. Le linee guida generali sull'utilizzo della CPU saranno circa il 60% in media e l'80% nell'utilizzo massimo della CPU. Picchi occasionali del 100% sono ancora accettabili e potrebbero non richiedere il ridimensionamento o la riconfigurazione.
Tipi di istanza
Amazon OpenSearch Service ti offre una scelta tra diversi tipi di istanze. Puoi scegliere i tipi di istanza più adatti al tuo caso d'uso. Amazon OpenSearch Service supporta le famiglie di istanze R, C, M, T e I. Scegli una famiglia di istanze in base al carico di lavoro: ottimizzata per la memoria, ottimizzata per il calcolo o mista. Dopo aver identificato una famiglia di istanze, scegli il tipo di istanza di ultima generazione. In generale, consigliamo Graviton e le generazioni successive perché sono progettate per offrire prestazioni migliori a costi inferiori rispetto alle istanze della generazione precedente.
Sulla base di vari test eseguiti per l'analisi dei log e i casi d'uso della ricerca, consigliamo quanto segue:
-
Per i casi d'uso dell'analisi dei log, una linea guida generale è iniziare con la famiglia R di istanze Graviton per nodi di dati. Ti consigliamo di eseguire test, stabilire benchmark per i tuoi requisiti e identificare la dimensione dell'istanza appropriata per il tuo carico di lavoro.
-
Per i casi d'uso di ricerca, consigliamo di utilizzare le istanze Graviton delle famiglie R e C per i nodi di dati, poiché i casi d'uso di ricerca richiedono più CPU rispetto ai casi d'uso di analisi dei log. Per carichi di lavoro più piccoli, puoi utilizzare le istanze Graviton della famiglia M sia per la ricerca che per i log. Le istanze della famiglia I offrono NVMe unità e vengono utilizzate da clienti con requisiti di indicizzazione rapida e ricerca a bassa latenza.
Il cluster è composto da nodi di dati e nodi di gestione del cluster. Sebbene i nodi master dedicati non elaborino le richieste di ricerca e di interrogazione, la loro dimensione è strettamente correlata alla dimensione dell'istanza e al numero di istanze, indici e shard che possono gestire. La documentazione di AWS fornisce una matrice che consiglia il tipo minimo di istanza di cluster manager dedicato.
AWS offre applicazioni generiche (M6g), ottimizzate per il calcolo (C6g) e ottimizzate per la memoria (R6g e R6gd) per Amazon OpenSearch Service versione 7.9 o successiva con processori AWS Graviton2.
La famiglia di istanze Graviton2 riduce la latenza di indicizzazione fino al 50 percento e migliora le prestazioni delle query fino al 30 percento rispetto alle istanze basate su Intel della generazione precedente disponibili in Service (M5, C5, R5). OpenSearch
