Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Stockage multiniveau pour Amazon Service OpenSearch
Le stockage multiniveau pour Amazon OpenSearch Service est une solution intelligente de gestion des données qui optimise à la fois les performances et les coûts en gérant les données sur différents niveaux de stockage. Cette architecture permet aux entreprises d'équilibrer efficacement le compromis entre performances et coûts en conservant les données fréquemment consultées dans un stockage à chaud à haute performance tout en transférant les données les moins fréquemment consultées vers un stockage à chaud plus rentable.
Amazon OpenSearch Service propose deux options d'architecture pour le niveau hot/warm de stockage :
+ **OpenSearch Architecture de stockage multiniveau**
+ Combine Amazon S3 avec le stockage d'instance local
+ Propulsé par des instances OpenSearch optimisées
+ Prend en charge les opérations d'écriture dans le niveau chaud
+ Permet une migration fluide des données entre le niveau chaud et le niveau chaud
+ Disponible sur les OpenSearch versions 3.3 et supérieures
+ Non compatible avec Cold Tier
+ **UltraWarmArchitecture basée**
+ Combine Amazon S3 avec le stockage d'instance local
+ Propulsé par UltraWarm des instances
+ Optimisé pour les charges de travail de niveau chaud en lecture seule
+ Disponible sur Elasticsearch version 6.8 et versions ultérieures et sur toutes les versions OpenSearch
+ Supporte Cold Tier
**Note**
Cette documentation se concentre uniquement sur l'architecture multiniveau. [Pour l'architecture de stockage Ultrawarm, voir [Ultrawarm](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html) and Cold Storage](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html)
## Architecture de stockage multiniveau
**Topics**
+ [Principaux avantages](#multi-tier-benefits)
+ [Conditions préalables](#multi-tier-prerequisites)
+ [Limitations](#multi-tier-limitations)
+ [À savoir](#things-to-note)
+ [Création d'un domaine multiniveau](#multi-tier-creating)
+ [Gestion des migrations de niveaux](#multi-tier-managing)
+ [Configuration de sécurité](#multi-tier-security)
+ [Bonnes pratiques](#multi-tier-best-practices)
+ [Surveillance des métriques](#multi-tier-metrics)
### Principaux avantages
+ **Writable Warm :** prend en charge les opérations d'écriture sur des indices chauds
+ **Migration fluide :** transfert fluide des données entre les niveaux de stockage
+ **Optimisation des coûts :** réduisez les coûts de stockage en transférant les données moins actives vers un stockage à chaud rentable
+ **Amélioration des performances :** maintenez des performances élevées pour les données fréquemment consultées dans le hot tier
+ **Gestion flexible des données :** choisissez l'architecture qui répond le mieux aux exigences de votre charge de travail
+ **Gestion automatisée : gestion** simplifiée du cycle de vie des données sur tous les niveaux de stockage
### Conditions préalables
+ **Version du moteur : OpenSearch ** **3.3 ou version ultérieure**
+ **Familles d'instances :**
+ Nœuds chauds : OR1 OR2, OM2, ou OI2
+ Nœuds chauds : OI2
+ **Sécurité :** Node-to-node chiffrement, chiffrement au repos, HTTPS appliqué
### Limitations
+ Fonctionne sur tous les domaines avec des instances OpenSearch optimisées pour lesquelles Ultrawarm n'est pas déjà activé
+ Pas de support pour le niveau froid
### À savoir
+ Les migrations entre chaud et chaud ne déclenchent pas de fusion forcée dans une architecture à plusieurs niveaux. Si nécessaire, l'utilisateur peut toujours orchestrer des fusions forcées à l'aide de la politique de gestion des index.
+ Outre l'indexation, les nœuds chauds effectuent désormais des opérations de fusion en arrière-plan (similaires aux nœuds chauds).
+ Toutes les demandes de recherche sur les index chauds sont acheminées vers la partition principale et les serveurs de réplication ne sont en lecture que lorsque la partition principale est en panne.
+ Les instantanés automatisés pour les indices chauds sont également pris en charge avec cette architecture.
+ La réplication entre clusters n'est prise en charge que pour les index chauds
+ Les index APIs tels que Shrink, Split and Clone ne fonctionnent pas avec des indices chauds.
### Création d'un domaine multiniveau
#### Étape 1 : créer le domaine
```
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
```
#### Étape 2 : vérifier les nœuds chauds
```
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
```
Exemple de réponse (extrait) :
```
{
"NodeType": "Warm",
"InstanceType": "oi2.large.search",
"NodeStatus": "Active"
}
```
### Gestion des migrations de niveaux
Prise en charge des domaines multiniveaux :
+ Nouvelle hiérarchisation APIs pour une expérience simplifiée
+ Legacy UltraWarm APIs en matière de compatibilité
#### Nouvelle hiérarchisation APIs
**Migrer un index vers Warm :**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
```
Réponse :
```
{"acknowledged": true}
```
**Migrer un index vers hot :**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
```
Réponse :
```
{"acknowledged": true}
```
**Vérifiez l'état de la hiérarchisation :**
```
curl -XGET 'https://localhost:9200/index-name/_tier'
```
Exemple de réponse :
```
{
"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
}
}
}
```
**Vue détaillée du partage :**
```
curl 'https://localhost:9200/index1/_tier?detailed=true'
```
**Répertorier toutes les migrations en cours (texte) :**
```
curl 'https://localhost:9200/_tier/all'
```
**Répertoriez toutes les migrations en cours (JSON) :**
```
curl 'https://localhost:9200/_tier/all?format=json'
```
**Filtrer par niveau cible :**
```
curl 'https://localhost:9200/_tier/all?target=_warm'
```
#### Legacy UltraWarm APIs en matière de compatibilité
**Migrer vers le chaud :**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
```
**Migrer vers Hot :**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
```
**Vérifier le statut :**
```
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
```
### Configuration de sécurité
Si vous activez le stockage multiniveau sur un domaine Amazon OpenSearch Service préexistant, le `storage_tiering_manager` rôle risque de ne pas être défini sur le domaine. Les utilisateurs non-administrateurs doivent être mappés à ce rôle pour gérer les index à chaud des domaines utilisant le contrôle précis des accès. Pour créer manuellement le rôle `storage_tiering_manager`, procédez comme suit :
1. Dans les OpenSearch tableaux de bord, accédez à **Sécurité**, puis sélectionnez **Autorisations**.
1. Choisissez **Create action group (Créer un groupe d'actions)** et configurez les groupes suivants :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/multi-tier-storage.html)
1. Choisissez **Roles (Rôles)**, puis **Create role (Créer un rôle)**.
1. Nommez le rôle `storage_tiering_manager`.
1. Pour **Cluster permissions (Autorisations de cluster), **sélectionnez `storage_tiering_cluster` et`cluster_monitor`.
1. Pour **Index**, saisissez `*`.
1. Pour les **autorisations d'indexation**`storage_tiering_index_read`, sélectionnez `storage_tiering_index_write` et`indices_monitor`.
1. Choisissez **Créer**.
1. Après avoir créé le rôle, associez-le à n'importe quel rôle d'utilisateur ou de backend qui gérera les index à plusieurs niveaux.
### Bonnes pratiques
Lorsque vous implémentez le stockage multiniveau dans vos domaines Amazon OpenSearch Service, tenez compte des meilleures pratiques suivantes :
+ Passez régulièrement en revue vos modèles d'accès aux données pour optimiser l'allocation des niveaux
+ Surveillez les indicateurs de performance pour garantir une utilisation efficace des ressources
+ Utilisez la nouvelle hiérarchisation APIs pour un contrôle granulaire de la migration des données
### Surveillance des métriques
Les domaines de stockage multiniveaux fournissent des mesures supplémentaires pour surveiller les performances des niveaux chauds. Ces métriques incluent à la fois les UltraWarm métriques existantes et les nouvelles métriques spécifiques à l'architecture des instances OpenSearch optimisées :
#### Nouvelles métriques
| Nom de la métrique | Statistiques au niveau des nœuds | Statistiques au niveau du cluster | Granularité |
| --- | --- | --- | --- |
| WarmIndexingLatency | Moyenne | Moyenne | 1 min |
| WarmIndexingRate | Moyenne | Moyenne, maximum, somme | 1 min |
| WarmThreadpoolIndexingQueue | Maximum | Somme, maximum, moyenne | 1 min |
| WarmThreadpoolIndexingRejected | Maximum | Somme | 1 min |
| WarmThreadpoolIndexingThreads | Maximum | Somme, moyenne | 1 min |