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à.
# Best practice operative per Amazon OpenSearch Service
Questo capitolo fornisce le best practice per la gestione dei domini Amazon OpenSearch Service e include linee guida generali che si applicano a molti casi d'uso. Ogni carico di lavoro è unico, con caratteristiche uniche, quindi nessun suggerimento generico è adatto per ogni caso d'uso. La best practice più importante consiste nell'implementare, testare e ottimizzare i domini in un ciclo continuo per trovare la configurazione, la stabilità e il costo ottimali per il tuo carico di lavoro.
**Topics**
+ [Monitoraggio e avvisi](#bp-monitoring)
+ [Strategia di partizione](#bp-sharding-strategy)
+ [Stabilità](#bp-stability)
+ [Performance](#bp-perf)
+ [Sicurezza](#bp-security)
+ [Ottimizzazione dei costi](#bp-cost-optimization)
+ [CloudWatch Allarmi consigliati per Amazon Service OpenSearch](cloudwatch-alarms.md)
+ [Dimensionamento dei domini Amazon OpenSearch Service](sizing-domains.md)
+ [Scalabilità in petabyte in Amazon Service OpenSearch](petabyte-scale.md)
+ [Nodi coordinatori dedicati in Amazon Service OpenSearch](Dedicated-coordinator-nodes.md)
+ [Nodi master dedicati in Amazon OpenSearch Service](managedomains-dedicatedmasternodes.md)
## Monitoraggio e avvisi
Le seguenti best practice si applicano al monitoraggio dei domini OpenSearch di servizio.
### Configura CloudWatch gli allarmi
OpenSearch Il servizio invia metriche sulle prestazioni ad Amazon. CloudWatch Esamina regolarmente i [parametri del cluster e dell'istanza](managedomains-cloudwatchmetrics.md) e configura gli [ CloudWatch allarmi consigliati in base alle prestazioni](cloudwatch-alarms.md) del carico di lavoro.
### Abilitazione della pubblicazione dei log
OpenSearch Il servizio espone i log degli OpenSearch errori, gli slow log di ricerca, gli slow log di indicizzazione e i log di controllo in Amazon Logs. CloudWatch I log di ricerca lenti, i log di indicizzazione lenti e i log di errore sono utili per la risoluzione dei problemi relativi alle prestazioni e alla stabilità. I log di verifica, disponibili solo se abiliti il [controllo granulare degli accessi](fgac.md), monitorano l'attività dell'utente. [Per ulteriori informazioni, consulta Logs nella documentazione.](https://opensearch.org/docs/latest/monitoring-your-cluster/logs/) OpenSearch
I log di ricerca lenti e i log di indicizzazione lenti sono uno strumento importante per comprendere e risolvere i problemi delle prestazioni delle operazioni di ricerca e indicizzazione. [Abilita la distribuzione di log lenti di ricerca e di indice](createdomain-configure-slow-logs.md#createdomain-configure-slow-logs-console) per tutti i domini di produzione. È inoltre necessario [configurare le soglie di registrazione](createdomain-configure-slow-logs.md#createdomain-configure-slow-logs-indices), altrimenti i registri CloudWatch non verranno acquisiti.
## Strategia di partizione
Gli shard distribuiscono il carico di lavoro tra i nodi di dati del dominio di servizio. OpenSearch Gli indici configurati correttamente possono contribuire a migliorare le prestazioni complessive del dominio.
Quando invii dati a OpenSearch Service, invii tali dati a un indice. Un indice è analogo a una tabella di database, con *documenti* come le righe e *campi* come le colonne. Quando crei l'indice, dici OpenSearch quanti shard primari vuoi creare. Gli shard primari sono partizioni indipendenti dell'intero set di dati. OpenSearch Il servizio distribuisce automaticamente i dati tra gli shard primari di un indice. Puoi inoltre configurare le *repliche* dell'indice. Ogni partizione di replica comprende un set completo di copie delle partizioni primarie per quell'indice.
OpenSearch Il servizio mappa gli shard per ogni indice tra i nodi di dati del cluster. Questo assicura che le partizioni primarie e di replica per l'indice risiedano su nodi di dati diversi. La prima replica garantisce la presenza di due copie dei dati nell'indice. Dovresti sempre usare almeno una replica. Le repliche aggiuntive forniscono ridondanza e capacità di lettura aggiuntive.
OpenSearch invia richieste di indicizzazione a tutti i nodi di dati che contengono frammenti che appartengono all'indice. Invia le richieste di indicizzazione prima ai nodi di dati che contengono partizioni primarie e poi ai nodi di dati che contengono partizioni di replica. Le richieste di ricerca vengono indirizzate dal nodo coordinatore a una partizione primaria o di replica per tutte le partizioni appartenenti all'indice.
Ad esempio, per un indice con cinque partizioni primarie e una replica, ogni richiesta di indicizzazione interessa 10 partizioni. Le richieste di ricerca, invece, vengono inviate a *n* partizioni, dove *n* è il numero di partizioni primarie. Per un indice con cinque partizioni primarie e una replica, ogni query di ricerca interessa cinque partizioni (primarie o di replica) da quell'indice.
### Determinazione del numero di partizioni e di nodi di dati
Utilizza le seguenti best practice per determinare il numero di partizioni e nodi di dati per il tuo dominio.
**Dimensione delle partizioni**: la dimensione dei dati su disco è il risultato diretto della dimensione dei dati di origine e cambia man mano che indicizzi più dati. Il source-to-index rapporto può variare notevolmente, da 1:10 a 10:1 o più, ma in genere è di circa 1:1,10. Puoi utilizzare questo rapporto per prevedere la dimensione dell'indice su disco. Puoi inoltre indicizzare alcuni dati e recuperare le dimensioni effettive dell'indice per determinare il rapporto per il tuo carico di lavoro. Una volta ottenuta una dimensione dell'indice prevista, imposta un numero di partizioni in modo che ogni partizione abbia una dimensione compresa tra 10 e 30 GiB (per i carichi di lavoro di ricerca) o tra 30 e 50 GiB (per i carichi di lavoro dei log). 50 GiB dovrebbe essere il massimo; assicurati di pianificare la crescita.
**Conteggio partizioni**: la distribuzione delle partizioni sui nodi di dati ha un grande impatto sulle prestazioni di un dominio. Quando hai indici con più shard, prova a fare in modo che gli shard contino un multiplo 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.
**Partizioni per nodo di dati**: il numero totale di partizioni che un nodo può contenere è proporzionale alla memoria heap JVM (Java Virtual Machine) del nodo. Punta a 25 partizioni o meno per GiB di memoria heap. Ad esempio, un nodo con 32 GiB di memoria heap non deve contenere più di 800 partizioni. Sebbene la distribuzione degli shard possa variare in base ai modelli di carico di lavoro, esiste un limite di 1.000 shard per nodo per Elasticsearch e da OpenSearch 1,1 a 2,15 e 4.000 per 2.17 e versioni successive. OpenSearch L'API [cat/allocation](https://opensearch.org/docs/latest/api-reference/cat/cat-allocation/) fornisce una visualizzazione rapida del numero di partizioni e dello storage totale delle partizioni tra i nodi di dati.
**Rapporto partizione/CPU**: quando una partizione è coinvolta in una richiesta di indicizzazione o ricerca, utilizza una vCPU per elaborare la richiesta. Come best practice, utilizza un punto di scala iniziale di 1,5 vCPU per partizione. Se il tuo tipo di istanza ha 8 vCPUs, imposta il conteggio dei nodi di dati in modo che ogni nodo non abbia più di sei shard. Si tratta di un'approssimazione. Assicurati di testare il carico di lavoro e dimensionare il cluster di conseguenza.
Per suggerimenti sul volume di storage, la dimensione delle partizioni e il tipo di istanza, consulta le seguenti risorse:
+ [Dimensionamento dei domini Amazon OpenSearch Service](sizing-domains.md)
+ [Scalabilità in petabyte in Amazon Service OpenSearch](petabyte-scale.md)
### Evitare l'asimmetria di storage
L'asimmetria di archiviazione si verifica quando uno o più nodi all'interno di un cluster detengono una percentuale maggiore di archiviazione per uno o più indici rispetto agli altri. L'utilizzo non uniforme della CPU, la latenza intermittente e irregolare e l'accodamento non uniforme tra i nodi di dati sono tutte indicazioni di asimmetria di archiviazione. Per determinare se sono presenti problemi di asimmetria, consulta le seguenti sezioni sulla risoluzione dei problemi:
+ [Asimmetria di partizioni e storage di nodi](handling-errors.md#handling-errors-node-skew)
+ [Asimmetria di partizioni e storage di indici](handling-errors.md#handling-errors-index-skew)
## Stabilità
Le seguenti best practice si applicano al mantenimento di un dominio di OpenSearch servizio stabile e integro.
### Resta aggiornato con OpenSearch
**Aggiornamenti del software del servizio**
OpenSearch Il servizio rilascia regolarmente [aggiornamenti software](service-software.md) che aggiungono funzionalità o migliorano in altro modo i tuoi domini. Gli aggiornamenti non modificano né la versione del motore Elasticsearch OpenSearch né quella del motore Elasticsearch. Ti consigliamo di pianificare un orario ricorrente per eseguire l'operazione dell'[DescribeDomain](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DescribeDomain.html)API e di avviare un aggiornamento del software di servizio, se lo è. `UpdateStatus` `ELIGIBLE` Se non aggiorni il dominio entro un determinato periodo di tempo (in genere due settimane), il OpenSearch Servizio esegue automaticamente l'aggiornamento.
**OpenSearch aggiornamenti di versione**
OpenSearch Il servizio aggiunge regolarmente il supporto per le versioni gestite dalla community di. OpenSearch Effettua sempre l'upgrade alle OpenSearch versioni più recenti quando sono disponibili.
OpenSearch Il servizio aggiorna contemporaneamente entrambe le OpenSearch OpenSearch dashboard (o Elasticsearch e Kibana se il dominio utilizza un motore legacy). Se il cluster dispone di nodi master dedicati, gli aggiornamenti vengono completati senza tempi di inattività. In caso contrario, il cluster potrebbe non rispondere per diversi secondi dopo l'aggiornamento mentre elegge un nodo principale. OpenSearch I dashboard potrebbero non essere disponibili durante alcuni o tutti gli upgrade.
Ci sono due modi per aggiornare un dominio:
+ [Aggiornamento in loco](starting-upgrades.md): questa opzione è più semplice perché si mantiene lo stesso cluster.
+ [Aggiornamento di snapshot/ripristino](snapshot-based-migration.md): questa opzione è ideale per testare nuove versioni su un nuovo cluster o per eseguire la migrazione tra cluster
Indipendentemente dal processo di aggiornamento utilizzato, ti consigliamo di mantenere un dominio destinato esclusivamente allo sviluppo e al test e di aggiornarlo alla nuova versione *prima* di aggiornare il dominio di produzione. Quando crei il dominio di test, scegli **Development and testing** (Sviluppo e test) per il tipo di implementazione. Assicurati di aggiornare tutti i client alle versioni compatibili subito dopo l'aggiornamento del dominio.
### Migliora le prestazioni delle istantanee
Per evitare che l'istantanea rimanga bloccata durante l'elaborazione, il tipo di istanza per il nodo master dedicato deve corrispondere al numero di shard. Per ulteriori informazioni, consulta [Scelta dei tipi di istanza per nodi principali dedicati](managedomains-dedicatedmasternodes.md#dedicatedmasternodes-instance). Inoltre, ogni nodo non deve avere più dei 25 shard consigliati per GiB di memoria heap Java. Per ulteriori informazioni, consulta [Scelta del numero di partizioni](bp-sharding.md).
### Abilitare nodi principali dedicati
I [nodi principali dedicati](managedomains-dedicatedmasternodes.md) migliorano la stabilità del cluster. Un nodo principale dedicato esegue attività di gestione del cluster ma non conserva dati di indice né risponde a richieste del client. Questo offload delle attività di gestione del cluster aumenta la stabilità del dominio e consente di apportare [modifiche alla configurazione](managedomains-configuration-changes.md) senza avere tempi di inattività.
Abilita e utilizza tre nodi principali dedicati per una stabilità ottimale del dominio in tre zone di disponibilità. L'implementazione con [Multi-AZ con Standby](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-multiaz.html#managedomains-za-standby) configura tre nodi master dedicati per te. Per suggerimenti sul tipo di istanza, consulta [Scelta dei tipi di istanza per nodi principali dedicati](managedomains-dedicatedmasternodes.md#dedicatedmasternodes-instance).
### Esecuzione dell'implementazione in più zone di disponibilità
Per prevenire la perdita di dati e ridurre al minimo i tempi di inattività del cluster in caso di interruzione del servizio, puoi distribuire i nodi tra due o tre [zone di disponibilità](managedomains-multiaz.md) nella stessa Regione AWS. La migliore pratica consiste nell'implementare [Multi-AZ with Standby](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-multiaz.html#managedomains-za-standby), che configura tre zone di disponibilità, con due zone attive e una che funge da standby, e con due shard di replica per indice. Questa configurazione consente a OpenSearch Service di distribuire gli shard di replica su shard primari diversi dai corrispondenti shard primari. AZs Non sono previsti costi di trasferimento dei dati tra zone di disponibilità per le comunicazioni dei cluster tra zone di disponibilità.
Le zone di disponibilità sono più posizioni isolate all'interno di ogni regione . Con una configurazione a due zone di disponibilità, perdere una zona di disponibilità significa perdere metà della capacità totale del dominio. Il passaggio a tre zone di disponibilità riduce ulteriormente l'impatto della perdita di una singola zona di disponibilità.
### Controllo del flusso di importazione e del buffering
Consigliamo di limitare il numero complessivo delle richieste utilizzando l'operazione API [\$1bulk](https://opensearch.org/docs/latest/api-reference/document-apis/bulk/). È più efficace inviare una richiesta `_bulk` contenente 5.000 documenti anziché inviare 5.000 richieste contenenti un singolo documento.
Per una stabilità operativa ottimale, a volte è necessario limitare o addirittura sospendere il flusso upstream delle richieste di indicizzazione. Limitare la percentuale di richieste di indicizzazione è un meccanismo importante per gestire picchi imprevisti o occasionali nelle richieste che potrebbero altrimenti sovraccaricare il cluster. Valuta la possibilità di creare un meccanismo di controllo del flusso nella tua architettura upstream.
Il diagramma seguente mostra più opzioni di componenti per un'architettura di importazione dei log. Configura il livello di aggregazione per avere spazio sufficiente per il buffering dei dati in ingresso per picchi di traffico improvvisi e brevi interventi di manutenzione del dominio.
![\[Log ingest architecture with producers, collectors, aggregators, and dashboards components.\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/log-ingest.png)
### Creare mappature per i carichi di lavoro di ricerca
Per i carichi di lavoro di ricerca, crea [mappature](https://opensearch.org/docs/latest/field-types/index/) che definiscono il modo in cui OpenSearch archivia e indicizza i documenti e i relativi campi. Imposta `dynamic` su `strict` per evitare l'aggiunta accidentale di nuovi campi.
```
PUT my-index
{
"mappings": {
"dynamic": "strict",
"properties": {
"title": { "type" : "text" },
"author": { "type" : "integer" },
"year": { "type" : "text" }
}
}
}
```
### Utilizzare modelli di indici
È possibile utilizzare un [modello di indice](https://opensearch.org/docs/latest/opensearch/index-templates/) per spiegare OpenSearch come configurare un indice al momento della creazione. Configura i modelli di indice prima di creare gli indici. Quindi, quando crei un indice, l'indice eredita le impostazioni e le mappature dal modello. Puoi applicare più di un modello a un singolo indice, quindi puoi specificare le impostazioni in un modello e le mappature in un altro. Questa strategia consente un modello per le impostazioni comuni su più indici e modelli separati per impostazioni e mappature più specifiche.
Le seguenti impostazioni sono particolarmente utili per la configurazione nei modelli:
+ Numero di partizioni primarie e di replica
+ Intervallo di aggiornamento (con quale frequenza aggiornare e rendere disponibili per la ricerca le modifiche recenti all'indice)
+ Controllo dinamico delle mappature
+ Mappature di campi esplicite
Il seguente modello di esempio contiene ognuna di queste impostazioni:
```
{
"index_patterns":[
"index-*"
],
"order": 0,
"settings": {
"index": {
"number_of_shards": 3,
"number_of_replicas": 1,
"refresh_interval": "60s"
}
},
"mappings": {
"dynamic": false,
"properties": {
"field_name1": {
"type": "keyword"
}
}
}
}
```
Anche se cambiano raramente, avere impostazioni e mappature definite centralmente OpenSearch è più semplice da gestire rispetto all'aggiornamento di più client upstream.
### Gestire gli indici con Index State Management
Se gestisci log o dati di serie temporali, ti consigliamo di utilizzare [Index State Management](ism.md) (ISM). ISM consente di automatizzare attività regolari di gestione del ciclo di vita degli indici. Con ISM, puoi creare policy che attivano i rollover degli alias degli indici, eseguire snapshot degli indici, spostare gli indici tra i livelli di archiviazione ed eliminare gli indici precedenti. Puoi persino usare le operazioni di [rollover](https://opensearch.org/docs/latest/im-plugin/ism/policies/#rollover) di ISM come strategia alternativa di gestione del ciclo di vita dei dati per evitare asimmetrie di partizioni.
In primo luogo, configura una policy ISM. Per un esempio, consulta [Policy di esempio](ism.md#ism-example). Quindi, collega la policy a uno o più indici. Se includi un campo [modello ISM](ism.md#ism-template) nella policy, OpenSearch Service applica automaticamente la policy a qualsiasi indice che corrisponda al modello specificato.
### Rimuovere gli indici inutilizzati
Esamina regolarmente gli indici nel tuo cluster e identifica quelli che non sono in uso. Esegui uno snapshot di questi indici in modo che siano archiviati in S3, quindi eliminali. Quando rimuovi gli indici inutilizzati, riduci il numero di partizioni e si consente una distribuzione dell'archiviazione e un utilizzo delle risorse più bilanciati tra i nodi. Anche quando sono inattivi, gli indici consumano alcune risorse durante le attività interne di manutenzione degli indici.
Anziché eliminare manualmente gli indici inutilizzati, puoi utilizzare ISM per eseguire automaticamente un'istantanea ed eliminare gli indici dopo un certo periodo di tempo.
### Utilizzare più domini per un'elevata disponibilità
Per ottenere un'elevata disponibilità oltre un [tempo di attività del 99,9%](https://aws.amazon.com/opensearch-service/sla/) in più regioni, prendi in considerazione l'utilizzo di due domini. Per set di dati piccoli o che cambiano lentamente, puoi configurare la [replica tra cluster](replication.md) in modo da mantenere un modello attivo-passivo. In questo modello è scritto solo il dominio leader, da cui possono essere letti entrambi i domini. Per set di dati più grandi e dati che cambiano rapidamente, configura la distribuzione doppia nella pipeline di importazione, in modo che tutti i dati vengano scritti indipendentemente in entrambi i domini in un modello attivo-attivo.
Progetta le tue applicazioni upstream e downstream tenendo presente il failover. Assicurati di testare il processo di failover insieme ad altri processi di ripristino di emergenza.
## Performance
Le seguenti best practice si applicano all'ottimizzazione dei domini per ottenere prestazioni ottimali.
### Ottimizzare le dimensioni e la compressione delle richieste in blocco
Il dimensionamento in blocco dipende dai dati, dall'analisi e dalla configurazione del cluster, ma un buon punto di partenza è 3-5 MiB per ciascuna richiesta in blocco.
Invia richieste e ricevi risposte dai tuoi OpenSearch domini utilizzando la [compressione gzip](gzip.md) per ridurre la dimensione del payload di richieste e risposte. Puoi usare la compressione gzip con il client [OpenSearch Python](gzip.md#gzip-code) o includendo [le seguenti](gzip.md#gzip-headers) intestazioni dal lato client:
+ `'Accept-Encoding': 'gzip'`
+ `'Content-Encoding': 'gzip'`
Per ottimizzare le dimensioni delle richieste in blocco, inizia con una richiesta in blocco di 3 MiB. Quindi, aumentane lentamente la dimensione finché le prestazioni di indicizzazione non smettono di migliorare.
**Nota**
Per abilitare la compressione gzip sui domini che eseguono Elasticsearch versione 6.x, devi impostare `http_compression.enabled` a livello di cluster. Questa impostazione è vera per impostazione predefinita nelle versioni 7.x di Elasticsearch e in tutte le versioni di. OpenSearch
### Ridurre le dimensioni delle risposte alle richieste in blocco
Per ridurre la dimensione delle OpenSearch risposte, escludi i campi non necessari con il parametro. `filter_path` Assicurati di non escludere i campi necessari per identificare o provare nuovamente le richieste non riuscite. Per maggiori informazioni ed esempi, consulta [Riduzione delle dimensioni della risposta](indexing.md#indexing-size).
### Ottimizzare gli intervalli di aggiornamento
OpenSearch gli indici alla fine hanno una consistenza di lettura. Un'operazione di aggiornamento rende disponibili per la ricerca tutti gli aggiornamenti eseguiti su un indice. L'intervallo di aggiornamento predefinito è di un secondo, il che significa che OpenSearch esegue un aggiornamento ogni secondo durante la scrittura di un indice.
Meno frequentemente si aggiorna un indice (intervallo di aggiornamento più elevato), migliori sono le prestazioni complessive di indicizzazione. L'aumento dell'intervallo di aggiornamento comporta un ritardo maggiore tra l'aggiornamento dell'indice e la disponibilità dei nuovi dati per la ricerca. Imposta l'intervallo di aggiornamento al livello più alto che puoi tollerare per migliorare le prestazioni complessive.
Consigliamo di impostare il parametro `refresh_interval` per tutti gli indici su 30 secondi o più.
### Abilitare la regolazione automatica
[Auto-Tune](auto-tune.md) utilizza i parametri di prestazioni e utilizzo del OpenSearch cluster per suggerire modifiche alle dimensioni delle code, alle dimensioni della cache e alle impostazioni della macchina virtuale Java (JVM) sui nodi. Queste modifiche facoltative migliorano la velocità e la stabilità del cluster. È possibile ripristinare le impostazioni predefinite OpenSearch del servizio in qualsiasi momento. La regolazione automatica è abilitata per impostazione predefinita sui nuovi domini a meno che non venga esplicitamente disabilitata.
Consigliamo di abilitare la regolazione automatica su tutti i domini e di impostare una finestra di manutenzione ricorrente o di rivedere periodicamente i relativi suggerimenti.
## Sicurezza
Le seguenti best practice si applicano alla protezione dei domini.
### Abilitare il controllo granulare degli accessi
[Il controllo granulare degli accessi consente di controllare](fgac.md) chi può accedere a determinati dati all'interno di un dominio di servizio. OpenSearch Rispetto al controllo degli accessi generalizzato, il controllo granulare degli accessi fornisce a ciascun cluster, indice, documento e campo la propria policy specifica per l'accesso. I criteri di accesso possono essere basati su una serie di fattori, tra cui il ruolo della persona che richiede l'accesso e l'azione che intende eseguire sui dati. Ad esempio, potresti concedere a un utente l'accesso per scrivere su un indice, mentre a un altro potrebbe essere concesso l'accesso solo per leggere i dati sull'indice senza apportare alcuna modifica.
Il controllo granulare degli accessi consente ai dati con requisiti di accesso diversi di esistere nello stesso spazio di storage senza incorrere in problemi di sicurezza o conformità.
Si consiglia di abilitare il controllo granulare degli accessi sui domini.
### Distribuire domini all'interno di un VPC
Posizionare il dominio del OpenSearch servizio all'interno di un cloud privato virtuale (VPC) consente una comunicazione sicura tra il OpenSearch Servizio e altri servizi all'interno del VPC, senza la necessità di un gateway Internet, un dispositivo NAT o una connessione VPN. Tutto il traffico rimane in modo sicuro all'interno del Cloud. AWS Grazie a loro isolamento logico, i domini che si trovano all'interno di un VPC hanno un ulteriore livello di sicurezza rispetto ai domini che usano gli endpoint pubblici.
Consigliamo di [creare domini all'interno di un VPC](vpc.md).
### Applicare una policy di accesso restrittiva
Anche se il tuo dominio è implementato all'interno di un VPC, è meglio implementare la sicurezza a più livelli. Assicurati di [controllare la configurazione](createupdatedomains.md#createdomain-configure-access-policies) delle tue attuali policy di accesso.
Applica una [politica di accesso restrittiva basata sulle risorse](ac.md#ac-types-resource) ai tuoi domini e segui il [principio del privilegio minimo quando concedi](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) l'accesso all'API di configurazione e alle operazioni dell'API. OpenSearch Come regola generale, evita di utilizzare il principale utente anonimo`"Principal": {"AWS": "*" }` nelle policy di accesso.
Esistono tuttavia alcune situazioni in cui è accettabile utilizzare una policy di accesso aperto, ad esempio quando abiliti il controllo degli accessi granulare. Una policy di accesso aperto può consentirti di accedere al dominio nei casi in cui la firma delle richieste è difficile o impossibile, ad esempio da determinati client e strumenti.
### Abilitare la crittografia dei dati a riposo
OpenSearch I domini di servizio offrono la crittografia dei dati inattivi per impedire l'accesso non autorizzato ai dati. Encryption at rest utilizza AWS Key Management Service (AWS KMS) per archiviare e gestire le chiavi di crittografia e l'algoritmo Advanced Encryption Standard con chiavi a 256 bit (AES-256) per eseguire la crittografia.
Se il dominio archivia i dati sensibili, [abilita la crittografia dei dati a riposo](encryption-at-rest.md).
### Abilita la crittografia node-to-node
Node-to-node la crittografia fornisce un ulteriore livello di sicurezza oltre alle funzionalità di sicurezza predefinite di OpenSearch Service. Implementa Transport Layer Security (TLS) per tutte le comunicazioni tra i nodi che vengono forniti all'interno. OpenSearch Node-to-nodecrittografia, tutti i dati inviati al dominio del OpenSearch servizio tramite HTTPS rimangono crittografati in transito mentre vengono distribuiti e replicati tra i nodi.
Se il tuo dominio memorizza dati sensibili, [abilita node-to-node la crittografia.](ntn.md)
### Monitora con AWS Security Hub CSPM
Monitora l'utilizzo del OpenSearch Servizio in relazione alle migliori pratiche di sicurezza utilizzando [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html). Security Hub CSPM utilizza i controlli di sicurezza per valutare le configurazioni delle risorse e gli standard di sicurezza per aiutarti a rispettare vari framework di conformità. Per ulteriori informazioni sull'utilizzo di Security Hub CSPM per valutare le risorse OpenSearch del servizio, vedere [Amazon OpenSearch Service i controlli nella Guida](https://docs.aws.amazon.com/securityhub/latest/userguide/opensearch-controls.html) per l'*AWS Security Hub utente*.
## Ottimizzazione dei costi
Le seguenti best practice si applicano all'ottimizzazione e al risparmio sui costi del OpenSearch Servizio.
### Utilizzare tipi di istanza di ultima generazione
OpenSearch Service adotta sempre nuovi tipi di [istanze Amazon EC2](supported-instance-types.md) che offrono prestazioni migliori a un costo inferiore. Si consiglia di utilizzare sempre istanze di ultima generazione.
Non utilizzare istanze T2 o `t3.small` per i domini di produzione in quanto possono diventare instabili in presenza di carichi pesanti sostenuti. Le istanze `r6g.large` sono un'opzione per piccoli carichi di lavoro di produzione (sia come nodi di dati che come nodi principali dedicati).
### Utilizzo dei volumi gp3 di Amazon EBS più recenti
OpenSearch i nodi di dati richiedono uno storage a bassa latenza e ad alto throughput per fornire indicizzazione e query rapide. Utilizzando i volumi gp3 Amazon EBS, ottieni prestazioni di base (IOPS e velocità di trasmissione effettiva) più elevate a un costo inferiore del 9,6% rispetto al tipo di volume gp2 Amazon EBS offerto in precedenza. È possibile fornire IOPS evelocità di trasmissione effettiva aggiuntivi indipendentemente dalle dimensioni del volume tramite gp3. Questi volumi sono inoltre più stabili rispetto ai volumi della generazione precedente in quanto non utilizzano crediti di espansione. Il tipo di volume gp3 raddoppia anche i limiti di dimensione del volume del tipo di per-data-node volume gp2. Con questi volumi più grandi, è possibile ridurre il costo dei dati passivi aumentando la quantità di spazio di archiviazione per nodo di dati.
### Utilizzo UltraWarm e conservazione a freddo dei dati di registro delle serie temporali
Se li utilizzi OpenSearch per l'analisi dei log, trasferisci i dati in una cella frigorifera per ridurre i costi. UltraWarm Utilizza Index State Management (ISM) per migrare i dati tra livelli di storage e gestire la conservazione dei dati.
[UltraWarm](ultrawarm.md)offre un modo conveniente per archiviare grandi quantità di dati di sola lettura in Service. OpenSearch UltraWarm utilizza Amazon S3 per lo storage, il che significa che i dati sono immutabili e ne è necessaria solo una copia. Paghi solo per lo spazio di archiviazione equivalente alla dimensione delle partizioni primarie negli indici. Le latenze per le UltraWarm query crescono con la quantità di dati S3 necessari per soddisfare la query. Dopo che i dati sono stati memorizzati nella cache dei nodi, le query sugli indici hanno prestazioni simili alle query sugli UltraWarm indici caldi.
Lo [storage a freddo](cold-storage.md) è supportato anche da S3. Quando è necessario interrogare dati non aggiornati, è possibile collegarli in modo selettivo ai nodi esistenti. UltraWarm I cold data comportano gli stessi costi di storage gestito UltraWarm, ma gli oggetti in cold storage non consumano le risorse dei UltraWarm nodi. Pertanto, la conservazione a freddo offre una notevole capacità di archiviazione senza influire sulle dimensioni o sul numero dei UltraWarm nodi.
UltraWarm diventa conveniente quando si dispone di circa 2,5 TiB di dati da migrare dallo storage a caldo. Monitora il tasso di riempimento e pianifica di spostare gli indici UltraWarm prima di raggiungere quel volume di dati.
### Rivedere i suggerimenti per le istanze riservate
Prendi in considerazione l'acquisto di [istanze riservate](ri.md) (RIs) dopo aver stabilito una buona base per quanto riguarda le prestazioni e il consumo di elaborazione. Gli sconti partono dal 30% circa per prenotazioni di 1 anno senza anticipo e possono aumentare fino al 50% per tutti gli impegni anticipati di 3 anni.
*Dopo aver osservato un funzionamento stabile per almeno 14 giorni, consulta [Accedere ai consigli di prenotazione](https://docs.aws.amazon.com/cost-management/latest/userguide/ri-recommendations.html) nella Guida per l'AWS Cost Management utente.* L'intestazione **Amazon OpenSearch Service** mostra consigli di acquisto del RI specifici e risparmi previsti.
# CloudWatch Allarmi consigliati per Amazon Service OpenSearch
CloudWatch gli allarmi eseguono un'azione quando una CloudWatch metrica supera un valore specificato per un certo periodo di tempo. Ad esempio, potresti voler AWS inviarti un'e-mail se lo stato di salute del cluster dura più `red` di un minuto. Questa sezione include alcuni allarmi consigliati per Amazon OpenSearch Service e come rispondere ad essi.
Puoi distribuire automaticamente questi allarmi utilizzando. CloudFormation[Per uno stack di esempio, consulta il relativo repository. GitHub](https://github.com/ev2900/OpenSearch_CloudWatch_Alarms)
**Nota**
Se distribuisci lo CloudFormation stack, gli `KMSKeyInaccessible` allarmi `KMSKeyError` and esisteranno in `Insufficient Data` uno stato perché queste metriche vengono visualizzate solo se un dominio riscontra un problema con la sua chiave di crittografia.
Per ulteriori informazioni sulla configurazione degli allarmi, consulta Creating [Amazon CloudWatch Alarms nella *Amazon CloudWatch *](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) User Guide.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/cloudwatch-alarms.html)
**Nota**
Se si desidera soltanto *visualizzare* i parametri, consultare [Monitoraggio delle metriche dei OpenSearch cluster con Amazon CloudWatch](managedomains-cloudwatchmetrics.md).
## Altri allarmi che potresti prendere in considerazione
Valuta la possibilità di configurare i seguenti allarmi a seconda delle funzionalità di OpenSearch servizio che utilizzi regolarmente.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/cloudwatch-alarms.html)
# 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.
**Topics**
+ [Calcolo dei requisiti di archiviazione](bp-storage.md)
+ [Scelta del numero di partizioni](bp-sharding.md)
+ [Scelta del tipo di istanza e test](bp-instances.md)
# Calcolo dei requisiti di archiviazione
La maggior parte dei OpenSearch carichi di lavoro rientra in una delle due grandi categorie:
+ **Indice di lunga durata**: scrivi codice che elabora i dati in uno o più OpenSearch indici 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. È·necessario anche considerare quanto segue:
+ **Numero di repliche**: ogni replica è una copia completa dello shard principale, la dimensione dell'archivio dell'indice mostra la dimensione occupata dallo shard primario e da quello di replica. Per impostazione predefinita, ogni OpenSearch indice ha 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.
+ **OpenSearch sovraccarico di indicizzazione: la** dimensione su disco di un indice varia. La dimensione totale dei dati di origine e dell'indice spesso è pari al 110% dell'origine, dove l'indice rappresenta fino al 10% dei dati di origine. Dopo l'indicizzazione dei dati, è possibile utilizzare l'API `_cat/indices?v` e il valore `pri.store.size` per calcolare il sovraccarico esatto. `_cat/allocation?v` fornisce anche un riepilogo utile.
+ **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.
+ **OpenSearch Sovraccarico** del OpenSearch servizio: il servizio riserva il 20% dello spazio di archiviazione di ogni istanza (fino a 20 GiB) per fusioni 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, applichiamo una stima "nel peggiore dei casi" per un sovraccarico. Questa stima include spazio libero aggiuntivo per ridurre al minimo l'impatto degli errori dei nodi e delle interruzioni delle zone 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\$1 2\$1 1,1/0,95/0,8 = 191 GiB. Puoi generalizzare il calcolo come indicato di seguito:
**Dati di origine\$1 (1\$1 numero di repliche) \$1 (1\$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 (1 \$1 Numero di repliche) \$1 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](bp-instances.md) dovresti controllare i numeri.
Esistono altre considerazioni di archiviazione:
+ Se i requisiti di archiviazione minimi superano 1 PB, consultare [Scalabilità in petabyte in Amazon Service OpenSearch](petabyte-scale.md).
+ Se disponi di indici in sequenza e desideri utilizzare un'architettura a caldo/ad accesso frequente, consulta [UltraWarm spazio di archiviazione per Amazon OpenSearch Service](ultrawarm.md).
# 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 CPU e memoria, avere troppi shard di piccole dimensioni può causare problemi di prestazioni 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,1/30 = 3. Puoi generalizzare il calcolo come indicato di seguito:
**(Dati di origine \$1 Spazio per crescere) \$1 (1 \$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\$1198) \$1 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,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 OpenSearch fino alla 2.15, 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 la versione OpenSearch 2.17 e successive, OpenSearch Service supporta 1000 shard per ogni 16 GB di memoria heap JVM fino a un massimo di 4000 shard per nodo. Per un esempio, consulta [Impostazioni del cluster](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body). Per ulteriori informazioni sul numero di frammenti, vedere. [Quote di conteggio condivise](limits.md#shard-count)
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](limits.md) 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 ritieni che il tuo cluster rientri in una di queste categorie, prova a partire da una configurazione più vicina a 2 core vCPU e 8 GiB di memoria per ogni 100 GiB di archiviazione.
**Suggerimento**
Per un riepilogo delle risorse hardware allocate a ciascun tipo di istanza, consulta [i prezzi di Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/pricing/).
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](managedomains-dedicatedmasternodes.md), 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 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\$1 144 = 288 core vCPU e 8\$1 144 = 1152 GiB di memoria. Questi numeri portano a circa 18 istanze `i3.4xlarge.search`. Se non è necessaria un'archiviazione veloce locale, puoi 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, consulta [Scalabilità in petabyte in Amazon Service OpenSearch](petabyte-scale.md).
## Fase 3: Esecuzione di test rappresentativi
Dopo aver configurato il cluster, puoi [aggiungere gli indici utilizzando il](indexing.md) numero di shard calcolato in precedenza, eseguire alcuni test rappresentativi sui client utilizzando un set di dati realistico e [monitorare le CloudWatch metriche](managedomains-cloudwatchmetrics.md) 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](cloudwatch-alarms.md) 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](managedomains-dedicatedmasternodes.md), che migliorano le prestazioni e l'affidabilità del cluster.
# Scalabilità in petabyte in Amazon Service OpenSearch
I domini Amazon OpenSearch Service offrono storage collegato fino a 10 PB. Puoi configurare un dominio con 1000 tipi di `OR1.16xlarge.search` istanze, ciascuna con 36 TB di spazio di archiviazione. A causa dell'enorme differenza in scala, le raccomandazioni per i domini di queste dimensioni differiscono dalle [nostre raccomandazioni generali](bp.md). In questa sezione sono riportate le considerazioni sulla creazione di domini, sui costi, sull'archiviazione e sulle dimensioni delle partizioni.
Sebbene questa sezione faccia spesso riferimento ai tipi di `i3.16xlarge.search` istanze, puoi utilizzare diversi altri tipi di istanza per raggiungere 10 PB di storage totale del dominio.
**Creazione di domini**
I domini di queste dimensioni superano il limite predefinito di 80 istanze per dominio. Per richiedere un aumento del limite di servizio fino a 1000 istanze per dominio, apri una richiesta presso il [AWS Support Center](https://console.aws.amazon.com/support/home#/).
**Prezzi**
Prima di creare un dominio di queste dimensioni, consulta la pagina [dei prezzi di Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/pricing/) per assicurarti che i costi associati corrispondano alle tue aspettative. Esamina [UltraWarm spazio di archiviazione per Amazon OpenSearch Service](ultrawarm.md) per vedere se un'architettura a caldo si adatta al tuo caso d'uso.
**Archiviazione**
I tipi di `i3` istanza sono progettati per fornire uno storage rapido e locale non volatile su memoria express (NVMe). Poiché questo storage locale tende a offrire vantaggi in termini di prestazioni rispetto ad Amazon Elastic Block Store, i volumi EBS non sono un'opzione quando si selezionano questi tipi di istanze in OpenSearch Service. Se si preferisce una archiviazione EBS, utilizzare un altro tipo di istanza, ad esempio `r6.12xlarge.search`.
**Dimensioni e conteggio di partizioni**
Una OpenSearch linea guida comune è quella di non superare i 50 GB per shard. Considerato il numero di partizioni necessarie per gestire domini di grandi dimensioni e le risorse disponibili per le istanze `i3.16xlarge.search`, consigliamo una dimensione della partizione pari a 100 GB.
Ad esempio, se si dispone di 450 TB di dati di origine e si desidere una replica, il requisito di *archiviazione* minimo è più vicino a 450 TB\$1 2\$1 1,1/0,95 = 1,04 PB. Per una spiegazione del calcolo, consulta [Calcolo dei requisiti di archiviazione](bp-storage.md). Anche se 1,04 PB/15 TB = 70 istanze, è possibile selezionare 90 o più istanze `i3.16xlarge.search` per garantire una rete di sicurezza per l'archiviazione, gestire i guasti dei nodi e tenere conto di alcune variazioni nella quantità di dati nel tempo. Ogni istanza aggiunge altri 20 GiB al requisito di archiviazione minimo, ma per dischi di queste dimensioni, questi 20 GiB sono quasi trascurabili.
Controllare il numero di shard è complicato. OpenSearch gli utenti spesso ruotano gli indici su base giornaliera e conservano i dati per una o due settimane. In questo caso, può essere utile distinguere tra partizioni "attive" e "inattive". Le partizioni attive sono attivamente oggetto di operazioni di lettura o scrittura. Le partizioni inattive potrebbero servire le richieste occasionali di lettura, ma sono fondamentalmente inattive. In generale, è consigliabile mantenere il numero di partizioni attive al di sotto di alcune migliaia. Se il numero di partizioni attive si avvicina a 10.000, potrebbero emergere rischi considerevoli in termini di prestazioni e stabilità.
Per calcolare il numero di partizioni primarie, utilizzare questa formula: 450.000 GB\$1 1,1/100 GB per partizione = 4.950 partizioni. Raddoppiando il numero per tenere conto delle repliche, raggiungiamo 9.900 partizioni, il che diventa motivo di grande preoccupazione se tutte le partizioni sono attive. Tuttavia, se si ruotano gli indici e solo 1/7° o 1/14° delle partizioni è attivo in un dato giorno (1.414 o 707 partizioni, rispettivamente), il cluster potrebbe funzionare perfettamente. Come sempre, la fase più importante del dimensionamento e della configurazione del dominio è eseguire il test rappresentativo del client utilizzando un set di dati realistico.
# Nodi coordinatori dedicati in Amazon Service OpenSearch
I nodi coordinatori dedicati in Amazon OpenSearch Service sono nodi specializzati che scaricano le attività di coordinamento dai nodi di dati. Queste attività includono la gestione delle richieste di ricerca e l'hosting OpenSearch di dashboard. Separando queste funzioni, i nodi coordinatori dedicati riducono il carico sui nodi di dati, il che consente loro di concentrarsi sull'archiviazione dei dati, sull'indicizzazione e sulle operazioni di ricerca. Ciò migliora le prestazioni complessive del cluster e l'utilizzo delle risorse.
Inoltre, i nodi coordinatori dedicati aiutano a ridurre il numero di indirizzi IP privati richiesti per le configurazioni VPC, il che porta a una gestione della rete più efficiente. Questa configurazione può comportare un miglioramento fino al 15% del throughput di indicizzazione e un miglioramento delle prestazioni delle query del 20%, a seconda delle caratteristiche del carico di lavoro.
## Quando utilizzare i nodi coordinatori dedicati
I nodi coordinatori dedicati sono particolarmente utili nei seguenti scenari.
+ **Cluster di grandi dimensioni**: in ambienti con un volume elevato di dati o query complesse, l'assegnazione delle attività di coordinamento su nodi dedicati può migliorare le prestazioni del cluster.
+ Interrogazioni **frequenti**: i carichi di lavoro che comportano query di ricerca o aggregazioni frequenti, in particolare quelli con istogrammi di data complessi o aggregazioni multiple, traggono vantaggio da un'elaborazione più rapida delle query.
+ **Uso intensivo delle dashboard: le dashboard possono richiedere molte risorse**. OpenSearch Affidare questa responsabilità a nodi coordinatori dedicati riduce il carico sui nodi di dati.
## Architettura e comportamento
In un OpenSearch cluster, i nodi coordinatori dedicati gestiscono due responsabilità chiave.
+ **Gestione delle richieste**: questi nodi ricevono le richieste di ricerca in entrata e le inoltrano ai nodi di dati appropriati, che archiviano i dati pertinenti. Quindi consolidano i risultati di più nodi di dati in un unico set di risultati globale, che viene restituito al client.
+ **Hosting di dashboard**: i nodi Coordinator gestiscono le OpenSearch dashboard, il che allevia i nodi di dati dall'onere aggiuntivo di ospitare OpenSearch dashboard e gestire il traffico correlato.
Nei domini VPC, ai nodi coordinatori dedicati vengono assegnate Interfacce di rete elastiche (ENIs) anziché nodi dati. Questa disposizione consente di ridurre il numero di indirizzi IP privati necessari VPCs, migliorando così l'efficienza della rete. In genere, i nodi coordinatori dedicati rappresentano circa il 10% del totale dei nodi di dati.
## Requisiti e limitazioni
I nodi coordinatori dedicati presentano i requisiti e le limitazioni seguenti.
+ I nodi coordinatori dedicati sono supportati in tutte le OpenSearch versioni e nelle versioni di Elasticsearch da 6.8 a 7.10.
+ Per abilitare i nodi coordinatori dedicati, il tuo dominio deve avere nodi master dedicati abilitati. Per ulteriori informazioni, consulta [Nodi master dedicati in Amazon OpenSearch Service](managedomains-dedicatedmasternodes.md).
+ Il provisioning di nodi coordinatori dedicati può comportare costi aggiuntivi. Tuttavia, la maggiore efficienza delle risorse e le migliori prestazioni giustificano l'investimento, in particolare per cluster di grandi dimensioni o complessi.
## Fornitura di nodi coordinatori dedicati
Esegui i passaggi seguenti per effettuare il provisioning di nodi coordinatori dedicati in un dominio esistente. Assicurati che nel tuo dominio siano abilitati i nodi *master* dedicati prima di effettuare il provisioning dei nodi coordinatori.
### Console
**Per fornire nodi coordinatori dedicati in Console di gestione AWS**
1. Accedi alla console di Amazon OpenSearch Service da [https://console.aws.amazon.com/aos/casa](https://console.aws.amazon.com/aos/home).
1. Scegli **Domini**, quindi seleziona il dominio che desideri modificare.
1. Nella sezione **Configurazione del cluster**, scegli **Modifica**.
1. Scegli **Abilita nodi coordinatori dedicati**.
1. Seleziona il tipo di istanza e il numero di nodi coordinatori da fornire.
1. Scegli **Save changes** (Salva modifiche). L'aggiornamento del dominio potrebbe richiedere alcuni minuti.
### AWS CLI
Per effettuare il provisioning di nodi coordinatori dedicati utilizzando il AWS CLI, usa il [update-domain-config](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-domain-config.html)comando. L'esempio seguente fornisce tre nodi `r6g.large.search` coordinatori in un dominio.
```
aws opensearch update-domain-config \
--domain-name my-opensearch-domain \
--cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedCoordinatorCount=3,ZoneAwarenessEnabled=true,DedicatedCoordinatorEnabled=true
```
Questo comando abilita i nodi coordinatori dedicati, imposta il tipo e il numero di istanze per i nodi coordinatori e abilita il riconoscimento delle zone per una maggiore disponibilità.
## Best practice
Prendi in considerazione le seguenti best practice quando utilizzi nodi coordinatori dedicati.
+ Utilizza istanze generiche per la maggior parte dei casi d'uso. Offrono un approccio equilibrato tra costi e prestazioni. Le istanze ottimizzate per la memoria sono ideali per carichi di lavoro che richiedono notevoli risorse di memoria, come quelli che implicano aggregazioni complesse o ricerche su larga scala.
+ Un buon punto di partenza consiste nel fornire tra il 5% e il 10% dei nodi di dati come nodi coordinatori dedicati. Ad esempio, se il tuo dominio ha 90 nodi di dati di un particolare tipo di istanza, valuta la possibilità di fornire da 5 a 9 nodi di coordinazione dello stesso tipo di istanza.
**Nota**
La disponibilità del tipo di istanza varia in base all'area geografica. Quando selezioni i tipi di istanza per i nodi coordinatori, verifica che il tipo di istanza scelto sia disponibile nella regione di destinazione. Puoi verificare la disponibilità del tipo di istanza nella console OpenSearch di servizio durante la creazione o la modifica del dominio.
+ Per ridurre al minimo il rischio di un singolo punto di errore, fornisci almeno due nodi di coordinamento dedicati. Ciò garantisce che il cluster rimanga operativo anche in caso di guasto di un nodo.
+ Se utilizzi la ricerca interregionale, fornisci nodi coordinatori dedicati nei domini di destinazione. I domini di origine in genere non gestiscono le attività di coordinamento.
+ Per ambienti ad alta intensità di indicizzazione, prendi in considerazione le istanze ottimizzate per la CPU che corrispondono alle dimensioni dell'istanza dei nodi di dati per prestazioni ottimali.
+ Per carichi di lavoro che richiedono molta memoria, utilizza un tipo di istanza leggermente più grande per i nodi coordinatori dedicati per gestire l'aumento delle richieste di memoria.
+ Tieni traccia della CloudWatch metrica `CoordinatorCPUUtilization` Amazon. Se supera costantemente l'80%, potrebbe indicare che hai bisogno di nodi coordinatori più grandi o aggiuntivi per gestire il carico.
+ Dimensiona i nodi coordinatori dedicati in modo che corrispondano ai nodi di dati. Ad esempio, inizia con 4 nodi di coordinamento generici quando usi nodi di dati 4xlarge.
+ Utilizza più istanze più piccole anziché un numero inferiore di istanze più grandi per i nodi coordinatori, a meno che le tue richieste o risposte individuali non richiedano una quantità di memoria (in) estremamente elevata. GBs Ad esempio, scegli 12 istanze 4xl anziché 6 istanze generiche da 8 istanze di grandi dimensioni.
### Consigli sui nodi in base alla dimensione del cluster
Utilizza le seguenti linee guida come punto di partenza per il provisioning di nodi coordinatori dedicati in base alle dimensioni del cluster. Modifica il numero e il tipo di nodi in base alle caratteristiche del carico di lavoro e alle metriche delle prestazioni.
| Dimensione del cluster | Nodi coordinatori consigliati | Tipo di istanza |
| --- | --- | --- |
| Piccoli (fino a 50 nodi) | 3-5 nodi | Uso generale |
| Medio (50-100 nodi) | 5-9 nodi | Memoria ottimizzata |
| Grande (oltre 100 nodi) | 10-15 nodi | Memoria ottimizzata |
# Nodi master dedicati in Amazon OpenSearch Service
Amazon OpenSearch Service utilizza *nodi master dedicati* per aumentare la stabilità del cluster. Un nodo master dedicato esegue task di gestione cluster ma non conserva dati né risponde a richieste di caricamento dei dati. L'offload dei task di gestione del cluster aumenta la stabilità del dominio. Come tutti gli altri tipi di nodo, per ogni nodo principale dedicato si paga una tariffa oraria.
I nodi master dedicati eseguono le seguenti attività di gestione del cluster:
+ Monitora tutti i nodi del cluster.
+ Monitora il numero di indici nel cluster.
+ Monitora il numero di partizioni appartenenti a ciascun indice.
+ Gestisci le informazioni di instradamento per i nodi del cluster.
+ Aggiorna lo stato del cluster dopo aver apportato modifiche allo stato, ad esempio la creazione di un indice e l'aggiunta o la rimozione di nodi nel cluster.
+ Replica le modifiche allo stato del cluster in tutti i nodi del cluster.
+ Monitora l'integrità di tutti i nodi del cluster inviando *segnali heartbeat*, segnali periodici che monitorano la disponibilità dei nodi di dati nel cluster.
L'illustrazione seguente mostra un dominio OpenSearch di servizio con 10 istanze. Sette delle istanze sono nodi di dati e tre sono nodi master dedicati. È attivo solo uno dei nodi principali dedicati. I due nodi principali dedicati grigi attenderanno come backup nel caso in cui il nodo principale dedicato attivo riporti un errore. Tutte le richieste di caricamento dati vengono elaborate dai sette nodi di dati e su tutte le attività di gestione del cluster viene effettuato l'offload al nodo master dedicato attivo.
![\[OpenSearch Service domain with data nodes and dedicated master nodes, illustrating cluster management.\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/DedicatedMasterNodes_no-caption.png)
## Scelta del numero di nodi principali dedicati
Si consiglia di utilizzare Multi-AZ con Standby, che aggiunge **tre** nodi master dedicati a ciascun dominio del servizio di produzione. OpenSearch Se utilizzi Multi-AZ senza Standby o Single-AZ, consigliamo comunque tre nodi master dedicati. Non scegliere mai un numero pari di nodi principali dedicati. Quando si sceglie il numero di nodi principali dedicati, tenere presente quanto segue:
+ Un nodo master dedicato è esplicitamente vietato dal OpenSearch servizio perché non è disponibile alcun backup in caso di guasto. Se si prova a creare un dominio con un solo nodo principale dedicato, viene ricevuta un'eccezione di convalida.
+ Se hai due nodi principali dedicati, allora il cluster non ha il quorum di nodi necessario per eleggere un nuovo nodo principale in caso di errore.
Un quorum è il numero di nodi principali dedicati / 2 \$1 1 arrotondato per difetto al numero intero più vicino. In questo caso: 2 / 2 \$1 1 = 2. Poiché un nodo master dedicato non è andato a buon fine ed esiste un solo backup, il cluster non dispone di un quorum e non è in grado di eleggere un nuovo master.
+ Tre nodi master dedicati, il numero consigliato, offrono due nodi di backup in caso di guasto del nodo master e il quorum necessario (2) per eleggere un nuovo master.
+ Quattro nodi principali dedicati non sono meglio di tre e possono causare problemi se utilizzi [più zone di disponibilità](managedomains-multiaz.md).
+ Se un nodo master ha esito negativo, hai il quorum (3) per eleggere un nuovo master. Se due nodi hanno esito negativo, perdi il quorum, in modo analogo a quando disponi di tre nodi master dedicati.
+ In una configurazione a tre zone di disponibilità, due AZs hanno un nodo master dedicato e una zona AZ ne ha due. Se in quella zona si verifica un'interruzione, le due restanti AZs non hanno il quorum necessario (3) per eleggere un nuovo master.
+ Avere cinque nodi master dedicati funziona così come tre e consente di perdere due nodi mantenendo un quorum. Ma poiché solo un nodo principale dedicato è attivo in un dato momento, questa configurazione implica pagare per quattro nodi inattivi. Molti clienti ritengono che questo livello di protezione failover sia eccessivo.
Se un cluster ha un numero pari di nodi idonei per il master e le versioni di Elasticsearch 7. OpenSearch *x* e versioni successive ignorano un nodo in modo che la configurazione di voto sia sempre un numero dispari. In questo caso, quattro nodi master dedicati sono essenzialmente equivalenti a tre (e due a uno).
**Nota**
Se il cluster non ha il quorum necessario per eleggere un nuovo nodo master, le richieste di lettura *e* scrittura al cluster non andranno a buon fine. Questo comportamento è diverso da quello OpenSearch predefinito.
## Scelta dei tipi di istanza per nodi principali dedicati
### OpenSearch Quote di dominio e istanza del servizio
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 frammenti che possono gestire. Per i cluster di produzione, consigliamo almeno i seguenti tipi di istanza per nodi master dedicati.
Queste raccomandazioni sono basate su carichi di lavoro tipici e possono variare in base alle tue esigenze. I cluster con molte partizioni o mappature di campi possono trarre vantaggio da tipi di istanze di dimensioni maggiori. Per ulteriori informazioni, consulta la sezione [ CloudWatch Allarmi consigliati per Amazon OpenSearch Service](cloudwatch-alarms.md) per determinare se è necessario utilizzare un tipo di istanza più grande.
| RAM | Max Node Support per Elasticsearch and OpenSearch Service da 1.x a 2.15 | Max Shard Support per Elasticsearch and OpenSearch Service da 1.x a 2.15 | Max Node Support for OpenSearch Service 2.17 e versioni successive | Max Shard Support for OpenSearch Service 2.17 e versioni successive |
| --- | --- | --- | --- | --- |
| 2 GB | Non applicabile | Non applicabile | 10 | 1K |
| 4 GB | Non applicabile | Non applicabile | 10 | 5K |
| 8 GB | 10 | 10.000 | 30 | 15.000 |
| 16 GB | 30 | 30K | 60 | 30K |
| 32 GB | 75 | 40K | 120 | 60 K |
| 64 GB | 125 | 75K | 240 | 120 K |
| 128 GB | 200 | 75K | 480 | 240 K |
| 256 GB | Non applicabile | Non applicabile | 1002 | 500 K |