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à.
# Storage a più livelli per Amazon Service OpenSearch
Lo storage multilivello per Amazon OpenSearch Service è una soluzione intelligente di gestione dei dati che ottimizza prestazioni e costi gestendo i dati su diversi livelli di storage. Questa architettura consente alle organizzazioni di bilanciare in modo efficiente il compromesso tra prestazioni e costi conservando i dati a cui si accede di frequente in hot storage ad alte prestazioni e spostando i dati a cui si accede meno frequentemente verso sistemi di storage caldi più convenienti.
Amazon OpenSearch Service offre due opzioni di architettura per il livello hot/warm di storage:
+ **OpenSearch Architettura di storage a più livelli**
+ Combina Amazon S3 con lo storage di istanze locali
+ Basato su istanze OpenSearch ottimizzate
+ Supporta le operazioni di scrittura in modalità warm tier
+ Supporta la migrazione dei dati senza interruzioni tra il livello caldo e quello caldo
+ Disponibile su OpenSearch 3.3 e versioni successive
+ Non supporta Cold Tier
+ **UltraWarmarchitettura basata**
+ Combina Amazon S3 con lo storage di istanze locali
+ Basato su istanze UltraWarm
+ Ottimizzato per carichi di lavoro di sola lettura di livello caldo
+ Disponibile nella versione 6.8 e successive di Elasticsearch e in tutte le versioni OpenSearch
+ Supporta Cold Tier
**Nota**
Questa documentazione si concentra solo sull'architettura a più livelli. [https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html)
## Architettura di storage a più livelli
**Topics**
+ [Vantaggi principali](#multi-tier-benefits)
+ [Prerequisiti](#multi-tier-prerequisites)
+ [Limitazioni](#multi-tier-limitations)
+ [Da sapere](#things-to-note)
+ [Creazione di un dominio a più livelli](#multi-tier-creating)
+ [Gestione delle migrazioni a più livelli](#multi-tier-managing)
+ [Configurazione di sicurezza](#multi-tier-security)
+ [Best practice](#multi-tier-best-practices)
+ [Monitoraggio delle metriche](#multi-tier-metrics)
### Vantaggi principali
+ **Writable Warm:** supporta le operazioni di scrittura su indici caldi
+ **Migrazione senza interruzioni: spostamento** senza interruzioni dei dati tra i livelli di storage
+ **Ottimizzazione dei costi:** riduci i costi di storage spostando i dati meno attivi in sistemi di storage a caldo a costi contenuti
+ **Miglioramento delle prestazioni:** mantenimento di prestazioni elevate per i dati a cui si accede di frequente nella fascia più calda
+ **Gestione flessibile dei dati:** scegli l'architettura più adatta ai requisiti del tuo carico di lavoro
+ **Gestione automatizzata: gestione** semplificata del ciclo di vita dei dati su più livelli di storage
### Prerequisiti
+ **Versione del motore****: 3.3 o successiva OpenSearch **
+ **Famiglie di istanze:**
+ Hot nodes: OR1 OR2, OM2, o OI2
+ Nodi caldi: OI2
+ **Sicurezza:** Node-to-node crittografia, crittografia a riposo, HTTPS applicato
### Limitazioni
+ Funziona su tutti i domini con istanze OpenSearch ottimizzate che non hanno già abilitato Ultrawarm
+ Nessun supporto per la modalità cold tier
### Da sapere
+ Le migrazioni da «hot to warm» non attivano un'unione forzata in un'architettura a più livelli. Se necessario, l'utente può comunque orchestrare le unioni forzate utilizzando la politica di gestione degli indici.
+ Oltre all'indicizzazione, i nodi caldi ora eseguono anche operazioni di unione in background (simili a quelle a caldo).
+ Tutte le richieste di ricerca sugli indici caldi vengono indirizzate allo shard primario e la replica serve le letture solo quando lo shard primario è inattivo.
+ Questa architettura supporta anche le istantanee automatizzate per gli indici caldi
+ La replica tra cluster è supportata solo per gli hot index
+ Indici APIs come Shrink, Split e Clone non funzionano con indici caldi.
### Creazione di un dominio a più livelli
#### Fase 1: Creare il dominio
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version OpenSearch_3.3 \
--cluster-config InstanceCount=3,InstanceType=or2.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3,WarmEnabled=true,WarmCount=3,WarmType=oi2.2xlarge.search \
--ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \
--node-to-node-encryption-options Enabled=true \
--encryption-at-rest-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"user_name","MasterUserPassword":"your_pass"}}' \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":"*","Action":"es:*","Resource":"*"}]}' \
--region us-east-1
```
#### Fase 2: Verifica dei nodi caldi
```
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
```
Esempio di risposta (estratto):
```
{
"NodeType": "Warm",
"InstanceType": "oi2.large.search",
"NodeStatus": "Active"
}
```
### Gestione delle migrazioni a più livelli
Supporto per domini multilivello:
+ Nuovo tiering APIs per un'esperienza semplificata
+ Legacy UltraWarm APIs per la compatibilità
#### Nuova suddivisione in più livelli APIs
**Migra un indice su warm:**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
```
Risposta:
```
{"acknowledged": true}
```
**Migrare un indice su hot:**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
```
Risposta:
```
{"acknowledged": true}
```
**Verifica lo stato del tiering:**
```
curl -XGET 'https://localhost:9200/index-name/_tier'
```
Risposta di esempio:
```
{
"tiering_status": {
"index": "index-name",
"state": "RUNNING_SHARD_RELOCATION",
"source": "HOT",
"target": "WARM",
"start_time": 1745836500563,
"shard_level_status": {
"running": 0,
"total": 100,
"pending": 100,
"succeeded": 0
}
}
}
```
**Vista condivisa dettagliata:**
```
curl 'https://localhost:9200/index1/_tier?detailed=true'
```
**Elenca tutte le migrazioni in corso (testo):**
```
curl 'https://localhost:9200/_tier/all'
```
**Elenca tutte le migrazioni in corso (JSON):**
```
curl 'https://localhost:9200/_tier/all?format=json'
```
**Filtra per livello di destinazione:**
```
curl 'https://localhost:9200/_tier/all?target=_warm'
```
#### Legacy UltraWarm APIs per la compatibilità
**Migra a warm:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
```
**Migrazione a caldo:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
```
**Verifica lo stato:**
```
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
```
### Configurazione di sicurezza
Se abiliti lo storage a più livelli su un dominio Amazon OpenSearch Service preesistente, il `storage_tiering_manager` ruolo potrebbe non essere definito nel dominio. Gli utenti senza privilegi di amministratore devono essere mappati a questo ruolo in modo da gestire gli indici a caldo sui domini che utilizzano il controllo granulare degli accessi. Per creare manualmente il ruolo `storage_tiering_manager`, procedere nel seguente modo:
1. **In OpenSearch Dashboards, vai su **Sicurezza** e scegli Autorizzazioni.**
1. Scegliere **Crea gruppo di operazioni** e configurare i seguenti gruppi:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/multi-tier-storage.html)
1. Scegliere **Ruoli**, quindi selezionare **Crea ruolo**.
1. Denomina il ruolo `storage_tiering_manager`.
1. Per **Autorizzazioni cluster**, selezionare `storage_tiering_cluster` e `cluster_monitor`.
1. Per **Indice**, digitare `*`.
1. Per le autorizzazioni relative all'indice**, seleziona e.** `storage_tiering_index_read` `storage_tiering_index_write` `indices_monitor`
1. Scegli **Create** (Crea).
1. Dopo aver creato il ruolo, associalo a qualsiasi ruolo utente o di backend che gestirà gli indici a più livelli.
### Best practice
Quando implementi lo storage a più livelli nei tuoi domini Amazon OpenSearch Service, prendi in considerazione le seguenti best practice:
+ Rivedi regolarmente i tuoi modelli di accesso ai dati per ottimizzare l'allocazione dei livelli
+ Monitora le metriche delle prestazioni per garantire un utilizzo efficiente delle risorse
+ Utilizza il nuovo tiering APIs per un controllo granulare sulla migrazione dei dati
### Monitoraggio delle metriche
I domini di storage multilivello forniscono parametri aggiuntivi per il monitoraggio delle prestazioni dei livelli più caldi. Queste metriche includono sia metriche esistenti che nuove UltraWarm metriche specifiche dell'architettura Optimized Instances: OpenSearch
#### Nuovi parametri
| Nome parametro | Statistiche a livello di nodo | Statistiche a livello di cluster | Granularity (Granularità) |
| --- | --- | --- | --- |
| WarmIndexingLatency | Media | Media | 1 minuto |
| WarmIndexingRate | Media | Media, massima, somma | 1 minuto |
| WarmThreadpoolIndexingQueue | Massimo | Somma, massimo, media | 1 minuto |
| WarmThreadpoolIndexingRejected | Massimo | Somma | 1 minuto |
| WarmThreadpoolIndexingThreads | Massimo | Somma, media | 1 minuto |