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.
# Gestion des index dans Amazon Service OpenSearch
Après avoir ajouté des données à Amazon OpenSearch Service, vous devez souvent les réindexer, utiliser des alias d'index, déplacer un index vers un stockage plus rentable ou le supprimer complètement. Ce chapitre traite des solutions de hiérarchisation du stockage, de la gestion de l'état des index et d'autres opérations d'indexation. Pour plus d'informations sur l' OpenSearch index APIs, consultez la [OpenSearch documentation](https://docs.opensearch.org/latest/opensearch/reindex-data/).
**Topics**
+ [OpenSearch Instances optimisées pour les domaines Amazon OpenSearch Service](or1.md)
+ [Stockage multiniveau pour Amazon Service OpenSearch](multi-tier-storage.md)
+ [UltraWarm stockage pour Amazon OpenSearch Service](ultrawarm.md)
+ [Stockage à froid pour Amazon OpenSearch Service](cold-storage.md)
+ [Gestion de l'état de l'index dans Amazon OpenSearch Service](ism.md)
+ [Récapitulatif des index dans Amazon OpenSearch Service à l'aide de cumuls d'index](rollup.md)
+ [Transformation des index dans Amazon Service OpenSearch](transforms.md)
+ [Réplication entre clusters pour Amazon Service OpenSearch](replication.md)
+ [Migration des index Amazon OpenSearch Service à l'aide de la réindexation à distance](remote-reindex.md)
+ [Gestion des séries chronologiques dans Amazon OpenSearch Service à l'aide de flux de données](data-streams.md)
# OpenSearch Instances optimisées pour les domaines Amazon OpenSearch Service
La famille d'instances OpenSearch optimisée pour Amazon OpenSearch Service est une solution rentable pour le stockage de gros volumes de données. Un domaine doté d'instances OpenSearch optimisées utilise le stockage local comme principal, les données étant copiées de manière synchrone vers Amazon S3 à leur arrivée. Cette structure de stockage fournit un débit d'indexation accru avec une durabilité élevée. OR1 OR2, OM2 utilise Amazon Elastic Block Store (Amazon EBS`gp3`) `io1` ou des volumes localement, OI2 tandis que les instances utilisent des disques locaux. NVMe La famille d'instances OpenSearch optimisée prend également en charge la restauration automatique des données en cas de panne. Pour plus d'informations sur les options de type d'instance OpenSearch optimisées, consultez[Types d'instance de la génération actuelle](supported-instance-types.md#latest-gen).
Si vous exécutez des charges de travail d'analyse opérationnelles lourdes telles que l'analyse des journaux, l'observabilité ou les analyses de sécurité, vous pouvez bénéficier des performances et de l'efficacité de calcul améliorées des OpenSearch instances optimisées. De plus, la récupération automatique des données proposée par les instances OpenSearch optimisées améliore la fiabilité globale de votre domaine.
OpenSearch Le service envoie à Amazon des métriques d'instance OpenSearch optimisées liées au stockage. CloudWatch Pour obtenir la liste des métriques disponibles, consultez la section [OpenSearch Métriques optimisées pour les instances (OR1)](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-or1).
OpenSearch les instances optimisées sont disponibles à la demande ou avec la tarification des instances réservées, avec un tarif horaire pour les instances et le stockage fournis dans Amazon EBS et Amazon S3.
**Topics**
+ [Limitations](#or1-considerations)
+ [Réglage pour un meilleur débit d'ingestion](#or1-ultrawarm-tuning)
+ [En quoi les instances OpenSearch optimisées diffèrent-elles des autres instances](#or1-optimized-instances)
+ [En quoi les instances OpenSearch optimisées diffèrent-elles des UltraWarm instances](#or1-ultrawarm-differences)
+ [Provisionner un domaine avec des instances OpenSearch optimisées](#or1-using)
## Limitations
Tenez compte des limites suivantes lorsque vous utilisez des instances OpenSearch optimisées pour votre domaine.
+ Les domaines nouvellement créés doivent exécuter OpenSearch la version 2.11 ou supérieure.
+ Les domaines existants doivent exécuter la OpenSearch version 2.15 ou supérieure.
+ Le chiffrement au repos doit être activé sur votre domaine. Pour de plus amples informations, veuillez consulter [Chiffrement des données au repos pour Amazon OpenSearch Service](encryption-at-rest.md).
+ Si votre domaine utilise des nœuds maîtres dédiés, ils doivent utiliser des instances Graviton. Pour plus d'informations sur les nœuds maîtres dédiés, consultez[Nœuds principaux dédiés dans Amazon OpenSearch Service](managedomains-dedicatedmasternodes.md).
+ L'intervalle d'actualisation des index sur les instances OpenSearch optimisées doit être de 10 secondes ou plus. L'intervalle d'actualisation par défaut pour les instances OpenSearch optimisées est de 10 secondes.
## Réglage pour un meilleur débit d'ingestion
Pour obtenir le meilleur débit d'indexation à partir de vos instances OpenSearch optimisées, nous vous recommandons de procéder comme suit :
+ Utilisez de gros volumes pour améliorer l'utilisation de la mémoire tampon. La taille recommandée est de 10 Mo.
+ Utilisez plusieurs clients pour améliorer les performances du traitement parallèle.
+ Définissez le nombre de partitions principales actives pour qu'il corresponde au nombre de nœuds de données afin d'optimiser l'utilisation des ressources.
## En quoi les instances OpenSearch optimisées diffèrent-elles des autres instances
OpenSearch les instances optimisées diffèrent des instances non optimisées de la manière suivante :
+ Pour les instances OpenSearch optimisées, l'indexation n'est effectuée que sur les partitions principales.
+ Si des instances OpenSearch optimisées sont configurées avec des répliques, le taux d'indexation peut sembler inférieur à ce qu'il est réellement. Par exemple, s'il existe une partition principale et une partition répliquée, le taux d'indexation peut être de 1 000 alors que le taux d'indexation réel est de 2 000.
+ OpenSearch les instances optimisées effectuent des opérations de mise en mémoire tampon avant d'envoyer à une source distante. Cela se traduit par des temps d'ingestion plus élevés.
**Note**
La `IndexingLatency` métrique n'est pas affectée, car elle n'inclut pas le temps nécessaire pour synchroniser le translog.
+ Les fragments de réplique peuvent se trouver à quelques secondes de retard sur les fragments principaux. Vous pouvez surveiller le décalage à l'aide de la CloudWatch métrique `ReplicationLagMaxTime` Amazon
## En quoi les instances OpenSearch optimisées diffèrent-elles des UltraWarm instances
OpenSearch Le service fournit des UltraWarm instances qui constituent un moyen rentable de stocker de grandes quantités de données en lecture seule. Les instances OpenSearch optimisées et UltraWarm les instances stockent les données localement dans Amazon EBS et à distance dans Amazon S3. Cependant, les instances OpenSearch optimisées et UltraWarm les instances diffèrent de plusieurs manières importantes :
+ OpenSearch *les instances optimisées conservent une copie des données dans votre magasin local et distant.* Dans UltraWarm certains cas, les données sont principalement conservées dans un magasin distant afin de réduire les coûts de stockage. En fonction de vos habitudes d'utilisation, les données peuvent être déplacées vers le stockage local.
+ OpenSearch les instances optimisées sont actives et peuvent accepter des opérations de lecture et d'écriture, tandis que les données des UltraWarm instances sont en lecture seule jusqu'à ce que vous les redéplaciez manuellement vers le stockage à chaud.
+ UltraWarm s'appuie sur des instantanés d'index pour la durabilité des données. OpenSearch les instances optimisées, en comparaison, effectuent la réplication et la restauration en arrière-plan. En cas d'index rouge, les instances OpenSearch optimisées restaurent automatiquement les fragments manquants de votre stockage distant dans Amazon S3. Le temps de restauration varie en fonction du volume de données à récupérer.
Pour plus d'informations sur UltraWarm le stockage, consultez[UltraWarm stockage pour Amazon OpenSearch Service](ultrawarm.md).
## Provisionner un domaine avec des instances OpenSearch optimisées
Vous pouvez sélectionner des instances OpenSearch optimisées pour vos nœuds de données lorsque vous créez un nouveau domaine avec le AWS Management Console ou le AWS Command Line Interface (AWS CLI). Vous pouvez ensuite indexer et interroger les données à l'aide de vos outils existants.
### Console
1. Accédez à la console Amazon OpenSearch Service à l'adresse[https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Domaines**.
1. Choisissez **Create domain (Créer un domaine)**.
1. Dans la section **Nombre de nœuds de données**, développez le menu de la **famille d'instances** et choisissez **OpenSearch optimisé**.
1. Choisissez le type d'instance et les autres paramètres de stockage.
1. Dans la section **Chiffrement**, assurez-vous que l'**option Activer le chiffrement des données au repos** est sélectionnée.
1. Configurez le reste de votre domaine et choisissez **Create**.
### AWS CLI
Pour provisionner un domaine qui utilise un stockage OpenSearch optimisé à l'aide du AWS CLI, vous devez fournir la valeur de la taille du type d'instance spécifique (telle que OR1 OR2 OM2,, ou OI2) dans le`InstanceType`.
L'exemple suivant crée un domaine avec des OR1 instances de taille `2xlarge` et active le chiffrement au repos.
```
aws opensearch create-domain \
--domain-name test-domain \
--engine-version OpenSearch_2.11 \
--cluster-config "InstanceType=or1.2xlarge.search,InstanceCount=3,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3" \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=200" \
--encryption-at-rest-options Enabled=true \
--advanced-security-options "Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions={MasterUserName=test-user,MasterUserPassword=test-password}" \
--node-to-node-encryption-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:account-id:domain/test-domain/*"}]}'
```
L'exemple suivant crée un domaine avec des OI2 instances de taille `large` et active le chiffrement au repos. Notez que OI2 les instances ne nécessitent pas de configuration EBS car elles utilisent le NVMe stockage local.
```
aws opensearch create-domain \
--domain-name test-domain-oi2 \
--engine-version OpenSearch_2.11 \
--cluster-config "InstanceType=oi2.2xlarge.search,InstanceCount=3,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3" \
--encryption-at-rest-options Enabled=true \
--advanced-security-options "Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions={MasterUserName=test-user,MasterUserPassword=test-password}" \
--node-to-node-encryption-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:account-id:domain/test-domain-oi2/*"}]}'
```
# 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 |
# UltraWarm stockage pour Amazon OpenSearch Service
UltraWarm constitue un moyen rentable de stocker de grandes quantités de données en lecture seule sur Amazon OpenSearch Service. Les nœuds de données standard utilisent un stockage « hot », qui prend la forme de magasins d'instance ou de volumes Amazon EBS attachés à chaque nœud. Le stockage hot offre les performances les plus rapides possibles pour l'indexation et la recherche de nouvelles données.
Plutôt que du stockage attaché, UltraWarm les nœuds utilisent Amazon S3 et une solution de mise en cache sophistiquée pour améliorer les performances. Pour les index sur lesquels vous n'écrivez pas activement, que vous interrogez moins fréquemment et pour lesquels vous n'avez pas besoin des mêmes performances, UltraWarm les coûts par GiB de données sont nettement inférieurs. Étant donné que les index chauds sont en lecture seule sauf si vous les renvoyez vers un stockage à chaud, UltraWarm ils conviennent mieux aux données immuables, telles que les journaux.
Dans OpenSearch, les index chauds se comportent comme n'importe quel autre index. Vous pouvez les interroger en utilisant la même méthode APIs ou les utiliser pour créer des visualisations dans les OpenSearch tableaux de bord.
**Topics**
+ [Conditions préalables](#ultrawarm-pp)
+ [UltraWarm exigences de stockage et considérations relatives aux performances](#ultrawarm-calc)
+ [UltraWarm tarification](#ultrawarm-pricing)
+ [Activant UltraWarm](#ultrawarm-enable)
+ [Migration des index vers le stockage UltraWarm](#ultrawarm-migrating)
+ [Automatisation des migrations](#ultrawarm-ism)
+ [Réglage des migrations](#ultrawarm-settings)
+ [Annulation des migrations](#ultrawarm-cancel)
+ [Liste des index hot et warm](#ultrawarm-api)
+ [Rebasculement d'index à chaud vers le stockage hot](#ultrawarm-migrating-back)
+ [Restaurer des index chauds à partir de snapshots](#ultrawarm-snapshot)
+ [Instantanés manuels des index warm](#ultrawarm-manual-snapshot)
+ [Migration d'index à chaud vers le stockage à froid](#ultrawarm-cold)
+ [Bonnes pratiques pour les indices KNN](#ultrawarm-recommendations)
+ [Désactivation UltraWarm](#ultrawarm-disable)
## Conditions préalables
UltraWarm comporte quelques prérequis importants :
+ UltraWarm nécessite OpenSearch Elasticsearch 6.8 ou version ultérieure.
+ Pour utiliser le stockage à chaud (warm), les domaines doivent disposer de [nœuds principaux dédiés](managedomains-dedicatedmasternodes.md).
+ Lorsque vous utilisez un domaine [Multi-AZ avec veille](managedomains-multiaz.md#managedomains-za-standby), le nombre de nœuds chauds doit être un multiple du nombre de zones de disponibilité utilisées.
+ Si votre domaine utilise un type d'instance T2 ou T3 pour vos nœuds de données, vous ne pouvez pas utiliser le stockage à chaud.
+ Si votre index utilise approximativement K-nn (`"index.knn":true`), vous pouvez le déplacer vers un stockage à chaud à partir de la version 2.17 et des versions ultérieures. Les domaines des versions antérieures à 2.17 peuvent être mis à niveau vers la version 2.17 pour utiliser cette fonctionnalité, mais les index KNN créés sur des versions antérieures à 2.x ne peuvent pas migrer vers cette version. UltraWarm
+ Si le domaine utilise un [contrôle d'accès précis](fgac.md), les utilisateurs doivent être mappés au `ultrawarm_manager` rôle dans les OpenSearch tableaux de bord pour effectuer des appels d'API. UltraWarm
**Note**
Le `ultrawarm_manager` rôle peut ne pas être défini sur certains domaines de OpenSearch service préexistants. Si le rôle n'est pas disponible dans Dashboards, vous devez [le créer manuellement](#ultrawarm-create-role).
### Configurer les autorisations
Si vous l'activez UltraWarm sur un domaine de OpenSearch service préexistant, le `ultrawarm_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 `ultrawarm_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/ultrawarm.html)
1. Choisissez **Roles (Rôles)**, puis **Create role (Créer un rôle)**.
1. Nommez le rôle **ultrawarm\$1manager**.
1. Pour **Cluster permissions (Autorisations de cluster), **sélectionnez `ultrawarm_cluster` et`cluster_monitor`.
1. Pour **Index**, saisissez `*`.
1. Pour **Index permissions (Autorisations d'index)**, sélectionnez `ultrawarm_index_read`, `ultrawarm_index_write` et `indices_monitor`.
1. Choisissez **Créer**.
1. Après avoir créé le rôle, [associez-le à](fgac.md#fgac-mapping) n'importe quel rôle d'utilisateur ou de backend chargé de gérer les UltraWarm index.
## UltraWarm exigences de stockage et considérations relatives aux performances
Comme indiqué dans la [Calcul des exigences de stockage](bp-storage.md) section, les données stockées à chaud entraînent une surcharge importante : réplications, espace réservé Linux et espace réservé aux OpenSearch services. Par exemple, une partition principale de 20 Gio avec une partition de réplica nécessite environ 58 Gio de stockage hot.
Comme il utilise Amazon S3, il n' UltraWarm entraîne aucune de ces surcharges. Lorsque vous calculez les besoins en UltraWarm stockage, vous ne tenez compte que de la taille des partitions principales. La durabilité des données dans S3 élimine le besoin de réplicas et S3 fait fi de toutes les considérations relatives au système d'exploitation ou au service. Cette même partition de 20 Gio nécessite 20 Gio de stockage à chaud (warm). Si vous provisionnez une instance `ultrawarm1.large.search`, vous pouvez utiliser les 20 Tio de son stockage maximale pour les partitions primaires. Reportez-vous à la section [UltraWarm quotas de stockage](limits.md#limits-ultrawarm) pour obtenir un résumé des types d'instance et la quantité maximale de stockage possible selon chaque cas.
Avec UltraWarm, nous recommandons toujours une taille de partition maximale de 50 GiB. Le [nombre de cœurs de processeur et la quantité de RAM allouées à chaque type d' UltraWarm instance](#ultrawarm-pricing) vous donnent une idée du nombre de partitions qu'ils peuvent rechercher simultanément. Notez que même si seules les partitions principales sont prises en compte pour le UltraWarm stockage dans S3, OpenSearch les tableaux de bord indiquent `_cat/indices` toujours la taille de l' UltraWarm index comme le *total* de toutes les partitions principales et répliques.
Par exemple, chaque instance `ultrawarm1.medium.search` deux cœurs CPU et peut traiter jusqu'à 1,5 Tio de stockage sur S3. Deux de ces instances présentent un stockage combiné de 3 Tio, ce qui correspond à environ 62 partitions si chaque partition est de 50 Gio. Si une requête adressée au cluster ne recherche que quatre de ces partitions, les performances peuvent être excellentes. Si la requête est importante et qu'elle recherche tous les 62 cœurs, les quatre cœurs de CPU peuvent avoir du mal à effectuer l'opération. Surveillez les `WarmJVMMemoryPressure` [UltraWarm indicateurs `WarmCPUUtilization` et les indicateurs](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw) pour comprendre comment les instances gèrent vos charges de travail.
Si vos recherches sont volumineuses ou fréquentes, envisagez de conserver les index du stockage hot. Comme pour toute autre OpenSearch charge de travail, l'étape la plus importante pour déterminer si elle UltraWarm répond à vos besoins consiste à effectuer des tests représentatifs auprès des clients à l'aide d'un ensemble de données réaliste.
## UltraWarm tarification
Avec le stockage hot, vous payez pour ce que vous provisionnez. Certaines instances nécessitent un volume Amazon EBS attaché, tandis que d'autres incluent un magasin d'instances. Que ce stockage soit vide ou plein, vous payez le même prix.
Avec UltraWarm le stockage, vous payez pour ce que vous utilisez. Une instance `ultrawarm1.large.search` peut traiter jusqu'à 20 Tio de stockage sur S3, mais si vous stockez seulement 1 Tio de données, vous n'êtes facturé que pour 1 Tio de données. Comme tous les autres types de nœuds, vous payez également un taux horaire pour chaque UltraWarm nœud. Pour de plus amples informations, veuillez consulter [Tarification d'Amazon OpenSearch Service](what-is.md#pricing).
## Activant UltraWarm
La console est le moyen le plus simple de créer un domaine qui utilise un stockage à chaud (warm). Lors de la création du domaine, sélectionnez **Activer les nœuds de données chauds** et le nombre de nœuds chauds que vous souhaitez. Le même processus de base fonctionne sur les domaines existants, à condition qu'ils répondent aux [prérequis](#ultrawarm-pp). Même une fois que l'état du domaine est **passé de Traitement** à **Actif**, il UltraWarm peut ne pas être disponible pendant plusieurs heures.
Lorsque vous utilisez un domaine Multi-AZ avec veille, le nombre de nœuds chauds doit être un multiple du nombre de zones de disponibilité. Pour de plus amples informations, veuillez consulter [Multi-AZ avec mode veille](managedomains-multiaz.md#managedomains-za-standby).
Vous pouvez également utiliser l'[API de configuration [AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html)](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)or pour activer UltraWarm, en particulier`WarmEnabled`, les `WarmType` options`WarmCount`, et dans`ClusterConfig`.
**Note**
Les domaines prennent en charge un nombre maximum de nœuds à chaud. Pour plus d'informations, consultez [Quotas Amazon OpenSearch Service](limits.md).
### Exemple de commande CLI
La AWS CLI commande suivante crée un domaine avec trois nœuds de données, trois nœuds maîtres dédiés, six nœuds actifs et un contrôle d'accès détaillé activé :
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version Opensearch_1.0 \
--cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.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=master-user,MasterUserPassword=master-password}' \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-west-1:123456789012:domain/my-domain/*"}]}' \
--region us-east-1
```
Pour plus d'informations, consultez le [Guide de référence des commandes AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).
### Exemple de demande d'API de configuration
La demande suivante adressée à l'API de configuration crée un domaine avec trois nœuds de données, trois nœuds maîtres dédiés et six nœuds à chaud avec un contrôle précis des accès activé et une stratégie d'accès restrictive :
```
POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain
{
"ClusterConfig": {
"InstanceCount": 3,
"InstanceType": "r6g.large.search",
"DedicatedMasterEnabled": true,
"DedicatedMasterType": "r6g.large.search",
"DedicatedMasterCount": 3,
"ZoneAwarenessEnabled": true,
"ZoneAwarenessConfig": {
"AvailabilityZoneCount": 3
},
"WarmEnabled": true,
"WarmCount": 6,
"WarmType": "ultrawarm1.medium.search"
},
"EBSOptions": {
"EBSEnabled": true,
"VolumeType": "gp2",
"VolumeSize": 11
},
"EncryptionAtRestOptions": {
"Enabled": true
},
"NodeToNodeEncryptionOptions": {
"Enabled": true
},
"DomainEndpointOptions": {
"EnforceHTTPS": true,
"TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
},
"AdvancedSecurityOptions": {
"Enabled": true,
"InternalUserDatabaseEnabled": true,
"MasterUserOptions": {
"MasterUserName": "master-user",
"MasterUserPassword": "master-password"
}
},
"EngineVersion": "Opensearch_1.0",
"DomainName": "my-domain",
"AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"123456789012\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:us-east-1:123456789012:domain/my-domain/*\"}]}"
}
```
Pour obtenir des informations détaillées, consultez le [Amazon OpenSearch Service API Reference](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html).
## Migration des index vers le stockage UltraWarm
Si vous avez terminé d'écrire dans un index et que vous n'avez plus besoin des performances de recherche les plus rapides possibles, migrez-le de hot vers UltraWarm :
```
POST _ultrawarm/migration/my-index/_warm
```
Vérifiez ensuite l'état de la migration :
```
GET _ultrawarm/migration/my-index/_status
{
"migration_status": {
"index": "my-index",
"state": "RUNNING_SHARD_RELOCATION",
"migration_type": "HOT_TO_WARM",
"shard_level_status": {
"running": 0,
"total": 5,
"pending": 3,
"failed": 0,
"succeeded": 2
}
}
}
```
L'état de l'index doit être vert pour effectuer une migration. Si vous migrez plusieurs index en succession rapide, vous pouvez obtenir un résumé de toutes les migrations en texte clair, similaire à l'API `_cat` :
```
GET _ultrawarm/migration/_status?v
index migration_type state
my-index HOT_TO_WARM RUNNING_SHARD_RELOCATION
```
OpenSearch Le service migre un index à la fois vers UltraWarm. Vous pouvez avoir jusqu'à 200 migrations dans la file d'attente. Toute requête dépassant la limite sera rejetée. Pour vérifier le nombre actuel de migrations dans la file d'attente, consultez la [métrique](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw) `HotToWarmMigrationQueueSize`. Les index restent disponibles tout au long du processus de migration, sans temps d'arrêt.
Le processus de migration comporte les états suivants :
```
PENDING_INCREMENTAL_SNAPSHOT
RUNNING_INCREMENTAL_SNAPSHOT
FAILED_INCREMENTAL_SNAPSHOT
PENDING_FORCE_MERGE
RUNNING_FORCE_MERGE
FAILED_FORCE_MERGE
PENDING_FULL_SNAPSHOT
RUNNING_FULL_SNAPSHOT
FAILED_FULL_SNAPSHOT
PENDING_SHARD_RELOCATION
RUNNING_SHARD_RELOCATION
FINISHED_SHARD_RELOCATION
```
Comme l'indiquent ces états, les migrations peuvent échouer pendant les instantanés, les relocations de partition ou les fusions forcées. Les échecs lors des instantanés ou de la relocalisation de partitions sont généralement dus à des défaillances de nœud ou à des problèmes de connectivité S3. Le manque d'espace disque est généralement la cause sous-jacente des échecs de fusion forcée.
Une fois la migration terminée, la même demande `_status` renvoie une erreur. Si vous vérifiez l'index à ce moment-là, vous pouvez voir certains paramètres qui sont propres aux index hot :
```
GET my-index/_settings
{
"my-index": {
"settings": {
"index": {
"refresh_interval": "-1",
"auto_expand_replicas": "false",
"provided_name": "my-index",
"creation_date": "1599241458998",
"unassigned": {
"node_left": {
"delayed_timeout": "5m"
}
},
"number_of_replicas": "1",
"uuid": "GswyCdR0RSq0SJYmzsIpiw",
"version": {
"created": "7070099"
},
"routing": {
"allocation": {
"require": {
"box_type": "warm"
}
}
},
"number_of_shards": "5",
"merge": {
"policy": {
"max_merge_at_once_explicit": "50"
}
}
}
}
}
}
```
+ `number_of_replicas`, dans ce cas, correspond au nombre de réplicas passifs qui ne consomment pas d'espace disque.
+ `routing.allocation.require.box_type` spécifie que l'index doit utiliser des nœuds à chaud plutôt que des nœuds de données standard.
+ `merge.policy.max_merge_at_once_explicit` spécifie le nombre de segments à fusionner simultanément pendant la migration.
Les index du stockage à chaud sont en lecture seule, sauf si vous [les renvoyez vers le stockage à chaud](#ultrawarm-migrating-back), ce qui les rend UltraWarm particulièrement adaptés aux données immuables, telles que les journaux. Vous pouvez interroger les index et les supprimer, mais vous ne pouvez pas ajouter, mettre à jour ou supprimer des documents individuels. Si vous essayez, il se peut que vous receviez l'erreur suivante :
```
{
"error" : {
"root_cause" : [
{
"type" : "cluster_block_exception",
"reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
}
],
"type" : "cluster_block_exception",
"reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
},
"status" : 429
}
```
## Automatisation des migrations
Nous vous recommandons d'utiliser [Gestion de l'état de l'index dans Amazon OpenSearch Service](ism.md) pour automatiser le processus de migration une fois qu'un index atteint un âge défini ou remplit d'autres conditions. Consultez l'[exemple de politique](ism.md#ism-example-cold) qui illustre ce flux de travail.
## Réglage des migrations
Les migrations d'index vers le UltraWarm stockage nécessitent une fusion forcée. Chaque OpenSearch index est composé d'un certain nombre de partitions, et chaque partition est composée d'un certain nombre de segments Lucene. L'opération de fusion forcée purge les documents marqués pour suppression et conserve de l'espace disque. Par défaut, UltraWarm fusionne les index en un seul segment, à l'exception des indices kNN, où une valeur par défaut de 20 est utilisée.
Vous pouvez modifier cette valeur à hauteur de 1 000 segments à l'aide du paramètre `index.ultrawarm.migration.force_merge.max_num_segments`. Des valeurs plus élevées accélèrent le processus de migration, mais augmentent la latence de requête de l'index à chaud une fois la migration terminée. Pour modifier le paramètre, faites la demande suivante :
```
PUT my-index/_settings
{
"index": {
"ultrawarm": {
"migration": {
"force_merge": {
"max_num_segments": 1
}
}
}
}
}
```
Pour vérifier combien de temps dure cette étape du processus de migration, consultez la [métrique](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw) `HotToWarmMigrationForceMergeLatency`.
## Annulation des migrations
UltraWarm gère les migrations de manière séquentielle, dans une file d'attente. Si une migration se trouve dans la file d'attente mais n'a pas encore démarré, vous pouvez la supprimer à l'aide de la demande suivante :
```
POST _ultrawarm/migration/_cancel/my-index
```
Si votre domaine utilise le contrôle précis des accès, vous devez disposer de l'autorisation `indices:admin/ultrawarm/migration/cancel` pour effectuer cette demande.
## Liste des index hot et warm
UltraWarm ajoute deux options supplémentaires, similaires à`_all`, pour aider à gérer les index chauds et chauds. Pour obtenir la liste de tous les index hot ou warm, faites les demandes suivantes :
```
GET _warm
GET _hot
```
Vous pouvez utiliser ces options dans d'autres demandes qui spécifient des index, par exemple :
```
_cat/indices/_warm
_cluster/state/_all/_hot
```
## Rebasculement d'index à chaud vers le stockage hot
Si vous devez écrire à nouveau dans un index, migrez-le vers le stockage hot :
```
POST _ultrawarm/migration/my-index/_hot
```
Vous pouvez avoir jusqu'à 10 migrations en file d'attente entre un stockage chaud et un stockage chaud à la fois. OpenSearch Le service traite les demandes de migration une par une, dans l'ordre dans lequel elles ont été mises en file d'attente. Pour vérifier le nombre actuel, consultez la [métrique](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw) `WarmToHotMigrationQueueSize`.
Une fois la migration terminée, vérifiez les paramètres d'index pour vous assurer qu'ils répondent à vos besoins. Rebasculement des index dans le stockage hot avec un réplica.
## Restaurer des index chauds à partir de snapshots
En plus du référentiel standard pour les instantanés automatisés, UltraWarm ajoute un deuxième référentiel pour les index chauds,. `cs-ultrawarm` Chaque instantané de ce référentiel contient un seul index. Si vous supprimez un index chaud, son instantané reste dans le référentiel `cs-ultrawarm` pendant 14 jours, comme pour tout autre instantané automatique.
Lorsque vous restaurez un instantané à partir de `cs-ultrawarm`, il rebascule dans le stockage à chaud (warm), et non dans le stockage hot. Les instantanés des référentiels `cs-automated` et `cs-automated-enc` rebasculent dans le stockage hot.
**Pour restaurer un UltraWarm instantané dans un espace de stockage chaud**
1. Identifiez le dernier instantané qui contient l'index à restaurer :
```
GET _snapshot/cs-ultrawarm/_all?verbose=false
{
"snapshots": [{
"snapshot": "snapshot-name",
"version": "1.0",
"indices": [
"my-index"
]
}]
}
```
**Note**
Par défaut, l'`GET _snapshot/`opération affiche des informations détaillées telles que l'heure de début, l'heure de fin et la durée de chaque instantané d'un référentiel. L'`GET _snapshot/`opération extrait les informations des fichiers de chaque instantané contenu dans un référentiel. Si vous n'avez pas besoin de l'heure de début, de l'heure de fin et de la durée et que vous avez uniquement besoin du nom et des informations d'index d'un instantané, nous vous recommandons d'utiliser le `verbose=false` paramètre lors de la liste des instantanés afin de minimiser le temps de traitement et d'éviter tout retard.
1. Si l'index existe déjà, supprimez-le :
```
DELETE my-index
```
Si vous ne souhaitez pas supprimer l'index, [renvoyez-le dans le stockage hot](#ultrawarm-migrating-back) et [réindexez-le](https://docs.opensearch.org/latest/opensearch/reindex-data/).
1. Restaurer l'instantané :
```
POST _snapshot/cs-ultrawarm/snapshot-name/_restore
```
UltraWarm ignore les paramètres d'index que vous spécifiez dans cette demande de restauration, mais vous pouvez spécifier des options telles que `rename_pattern` et`rename_replacement`. Pour obtenir un résumé des options de restauration des OpenSearch instantanés, consultez la [OpenSearch documentation](https://docs.opensearch.org/latest/opensearch/snapshot-restore/#restore-snapshots).
## Instantanés manuels des index warm
Vous *pouvez* prendre des instantanés manuels des index warm, mais nous vous le déconseillons. Le référentiel `cs-ultrawarm` automatisé contient déjà un instantané pour chaque index à chaud pris lors de la migration, sans frais supplémentaires.
Par défaut, le OpenSearch service n'inclut pas les index de chaleur dans les instantanés manuels. Par exemple, l'appel suivant inclut uniquement des index hot :
```
PUT _snapshot/my-repository/my-snapshot
```
Si vous choisissez de prendre des instantanés manuels d'index warm, plusieurs considérations importantes s'appliquent.
+ Vous ne pouvez pas mélanger les index hot et warm. Par exemple, la demande suivante échoue :
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1,hot-index-1",
"include_global_state": false
}
```
Si elles combinent des index hot et warm, les instructions avec caractère générique (`*`) échouent également.
+ Vous ne pouvez inclure qu'un index à chaud par instantané. Par exemple, la demande suivante échoue :
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1,warm-index-2,other-warm-indices-*",
"include_global_state": false
}
```
Cette demande a abouti :
```
PUT _snapshot/my-repository/my-snapshot
{
"indices": "warm-index-1",
"include_global_state": false
}
```
+ Les instantanés manuels sont toujours restaurés dans le stockage hot, même s'ils incluaient à l'origine un index à chaud.
## Migration d'index à chaud vers le stockage à froid
Si vous avez des données UltraWarm que vous interrogez rarement, envisagez de les migrer vers un stockage à froid. Le stockage à froid est destiné aux données auxquelles vous n'accédez qu'occasionnellement ou qui ne sont plus utilisées. Vous ne pouvez pas lire ou écrire dans des index cold, mais vous pouvez les migrer vers un stockage warm, sans frais, chaque fois que vous avez besoin de les interroger. Pour obtenir des instructions, consultez la section [Migration des index vers le stockage à froid.](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html#coldstorage-migrating)
## Bonnes pratiques pour les indices KNN
+ Le niveau Ultrawarm/Cold est disponible pour tous les types de moteurs à indice KNN. Nous le recommandons pour les index KNN utilisant le moteur Lucene et la recherche vectorielle optimisée pour les disques, qui ne nécessitent pas de charger complètement les données du graphe dans une mémoire externe. Lorsque vous l'utilisez avec des moteurs en mémoire natifs tels que FAISS et NMSLIB, vous devez tenir compte de la taille du graphe de fragments sur lequel la recherche sera activement effectuée et provisionner les UltraWarm instances, de préférence du type instance, en conséquence. `uw.large` Par exemple, si les clients ont configuré deux `uw.large` instances, chacune d'entre elles disposera d'environ `knn.memory.circuit_breaker.limit * 61` GiB de mémoire externe disponible. Vous obtenez des performances optimales si toutes vos requêtes chaleureuses ciblent des fragments dont la taille cumulée du graphique ne dépasse pas la mémoire hors segment disponible. La latence est affectée si la mémoire disponible est inférieure à celle nécessaire pour charger le graphique en raison d'expulsions et de l'attente de la disponibilité de mémoire hors tas. C'est pourquoi nous ne recommandons pas d'utiliser des `uw.medium` instances pour les cas d'utilisation impliquant l'utilisation de moteurs en mémoire ou pour les cas de débit de recherche plus élevé, quels que soient les moteurs.
+ Les index KNN vers lesquels la migration est effectuée ne UltraWarm seront pas fusionnés de force en un seul segment. Cela évite tout impact sur les nœuds chauds et chauds qui rencontrent des problèmes d'OOM en raison de la taille du graphe devenue trop importante pour les moteurs en mémoire. En raison de l'augmentation du nombre de segments par partition, cela peut entraîner une consommation plus importante d'espace de cache local et permettre à un moins grand nombre d'index de migrer vers le niveau chaud. Vous pouvez choisir de fusionner de force les index vers un seul segment en utilisant le paramètre existant et en le remplaçant avant de migrer les index vers le niveau chaud. Pour de plus amples informations, veuillez consulter [Réglage des migrations](#ultrawarm-settings).
+ Si vous avez un cas d'utilisation dans lequel les index sont rarement recherchés et ne répondent pas à une charge de travail sensible à la latence, vous pouvez choisir de migrer ces index vers le niveau. UltraWarm Cela vous aidera à réduire le nombre d'instances de calcul de niveau élevé et à laisser le UltraWarm niveau de calcul gérer les requêtes sur des index de faible priorité. Cela peut également aider à isoler les ressources consommées entre les requêtes des index de faible priorité et de haute priorité afin qu'elles n'aient pas d'impact mutuel.
## Désactivation UltraWarm
La console est le moyen le plus simple de le désactiver UltraWarm. Choisissez le domaine, **Actions**, et **Edit cluster configuration (Modifier la configuration de cluster)**. Désélectionnez **Activer les nœuds de données chauds** et choisissez **Enregistrer les modifications**. Vous pouvez également utiliser l'option `WarmEnabled` dans l' AWS CLI et dans l'API de configuration.
Avant de procéder à la désactivation UltraWarm, vous devez soit [supprimer](https://opensearch.org/docs/latest/opensearch/rest-api/index-apis/delete-index/) tous les index chauds, soit [les migrer à nouveau vers le stockage à chaud](#ultrawarm-migrating-back). Une fois le stockage à chaud vide, attendez cinq minutes avant de tenter de le désactiver UltraWarm.
# Stockage à froid pour Amazon OpenSearch Service
Le stockage à froid vous permet de stocker toute quantité de données rarement consultées ou historiques sur votre domaine Amazon OpenSearch Service et de les analyser à la demande, à un coût inférieur à celui des autres niveaux de stockage. Le stockage à froid vous conviendra si vous devez effectuer des recherches périodiques ou des analyses sur vos anciennes données. Parmi les exemples pratiques de données stockables à froid figurent les journaux rarement consultés, les données à conserver pour satisfaire des exigences de conformité ou les journaux qui ont une valeur historique.
Tout comme le [UltraWarm](ultrawarm.md)stockage, le stockage à froid est soutenu par Amazon S3. Lorsque vous devez interroger des données confidentielles, vous pouvez les associer de manière sélective à des UltraWarm nœuds existants. Vous pouvez gérer la migration et le cycle de vie de vos données froides manuellement ou à l'aide de politiques ISM (Index State Management).
**Topics**
+ [Conditions préalables](#coldstorage-pp)
+ [Stockage à froid : exigences et considérations relatives aux performances](#coldstorage-calc)
+ [Tarification du stockage à froid](#coldstorage-pricing)
+ [Activation du stockage à froid](#coldstorage-enable)
+ [Gestion des index de froid dans OpenSearch les tableaux de bord](#coldstorage-dashboards)
+ [Migration des index vers le stockage à froid](#coldstorage-migrating)
+ [Automatisation des migrations vers le stockage à froid](#coldstorage-ism)
+ [Annulation des migrations vers le stockage à froid](#coldstorage-cancel)
+ [Répertorier les index froids](#coldstorage-list)
+ [Migration d'index à froid vers le stockage à chaud](#coldstorage-migrating-back)
+ [Restauration des index à froid à partir d'instantanés](#cold-snapshot)
+ [Annulation des migrations du stockage à froid vers le stockage à chaud](#coldtowarm-cancel)
+ [Mise à jour des métadonnées des index froids](#cold-update-metadata)
+ [Supprimer des index froids](#cold-delete)
+ [Désactivation du stockage à froid](#coldstorage-disable)
## Conditions préalables
Les prérequis suivants s'appliquent au stockage à froid :
+ Le stockage à froid nécessite la version 7.9 OpenSearch ou ultérieure d'Elasticsearch.
+ Pour activer le stockage à froid sur un domaine de OpenSearch service, vous devez également activer le stockage à chaud sur le même domaine.
+ Pour utiliser le stockage à froid, les domaines doivent disposer de [nœuds principaux dédiés](managedomains-dedicatedmasternodes.md).
+ Si votre domaine utilise un type d'instance T2 ou T3 pour vos nœuds de données, vous ne pouvez pas utiliser le stockage à froid.
+ Si votre index utilise approximativement k-nn (`"index.knn":true`), vous pouvez le déplacer vers le stockage à froid à partir de la version 2.17 et des versions ultérieures. Les domaines des versions antérieures à 2.17 peuvent passer à la version 2.17 pour utiliser cette fonctionnalité, mais les index KNN créés sur des versions antérieures à 2.x ne peuvent pas migrer vers Cold.
+ Si le domaine utilise un [contrôle d'accès précis](fgac.md), les utilisateurs non administrateurs doivent être [mappés](fgac.md#fgac-mapping) au `cold_manager` rôle dans les OpenSearch tableaux de bord afin de gérer les index froids.
**Note**
Le `cold_manager` rôle peut ne pas exister sur certains domaines de OpenSearch service préexistants. Si le rôle n'est pas disponible dans Dashboards, vous devez [le créer manuellement](#coldstorage-create-role).
### Configurer les autorisations
Si vous activez le stockage à froid sur un domaine de OpenSearch service préexistant, le `cold_manager` rôle risque de ne pas être défini sur le domaine. Si le domaine utilise un [contrôle d'accès précis](fgac.md), les utilisateurs non administrateurs doivent être mappés à ce rôle afin de gérer les index froids. Pour créer manuellement le rôle `cold_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/cold-storage.html)
1. Choisissez **Roles (Rôles)**, puis **Create role (Créer un rôle)**.
1. Nommez le rôle **cold\$1manager**.
1. Dans le champ **Cluster permissions (Autorisations de cluster)**, choisissez le groupe `cold_cluster` que vous avez créé.
1. Dans le champ **Index**, saisissez `*`.
1. Dans le champ **Index permissions (Autorisations d'index)**, choisissez le groupe `cold_index` que vous avez créé.
1. Choisissez **Créer**.
1. Après avoir créé le rôle, [associez-le à](fgac.md#fgac-mapping) n'importe quel rôle d'utilisateur ou de backend qui gère les index froids.
## Stockage à froid : exigences et considérations relatives aux performances
Comme le stockage à froid utilise Amazon S3, il n'entraîne aucune surcharge liée au stockage à chaud, comme les répliques, l'espace réservé à Linux et l'espace réservé aux OpenSearch services. Le stockage à froid ne nécessite aucun type d'instance spécifique, car aucune capacité de calcul n'y est attachée. Vous pouvez stocker n'importe quelle quantité de données dans le stockage à froid. Surveillez l'`ColdStorageSpaceUtilization`indicateur sur Amazon CloudWatch pour connaître l'espace de stockage frigorifique que vous utilisez.
## Tarification du stockage à froid
Comme pour le UltraWarm stockage, le stockage à froid vous ne payez que pour le stockage des données. Il n'y a pas de frais de calcul liés aux données froides et rien ne vous est facturé en l'absence de de données dans le stockage à froid.
Vous ne payez pas de frais de transfert lorsque vous déplacez des données entre le stockage à froid et le stockage à chaud. Pendant la migration d'index entre le stockage à chaud et le stockage à froid, vous continuez à ne payer qu'un seul exemplaire de l'index. Une fois la migration terminée, l'index est facturé en fonction du niveau de stockage vers lequel il a été migré. Pour plus d'informations sur les tarifs des entrepôts frigorifiques, consultez les [tarifs d'Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/pricing/).
## Activation du stockage à froid
La console est le moyen le plus simple de créer un domaine qui utilise le stockage à froid. Lorsque vous créez le domaine, choisissez d'abord **Enable warm data nodes**, car vous devez activer le stockage à chaud sur le même domaine. Choisissez ensuite **Activer le stockage à froid**.
Le même processus s'applique aux domaines existants, à condition de satisfaire les [prérequis](#coldstorage-pp). Une fois l'état du domaine passé de **Traitement en cours** à **Actif**, le stockage à froid peut malgré tout rester indisponible pendant plusieurs heures.
Vous pouvez également activer le stockage à froid à l'aide de l'interface [AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html) ou de l'[API de configuration](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html).
### Exemple de commande de l'interface CLI
La AWS CLI commande suivante crée un domaine avec trois nœuds de données, trois nœuds maîtres dédiés, le stockage à froid activé et le contrôle d'accès détaillé activé :
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version Opensearch_1.0 \
--cluster-config ColdStorageOptions={Enabled=true},WarmEnabled=true,WarmCount=4,WarmType=ultrawarm1.medium.search,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,InstanceCount=3 \
--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=master-user,MasterUserPassword=master-password}' \
--region us-east-2
```
Pour plus d'informations, consultez le [Guide de référence des commandes AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).
### Exemple de demande d'API de configuration
La requête suivante adressée à l'API de configuration crée un domaine constitué de trois nœuds de données et de trois nœuds principaux dédiés, et sur lequel le stockage à froid et le contrôle précis des accès sont activés :
```
POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain
{
"ClusterConfig": {
"InstanceCount": 3,
"InstanceType": "r6g.large.search",
"DedicatedMasterEnabled": true,
"DedicatedMasterType": "r6g.large.search",
"DedicatedMasterCount": 3,
"ZoneAwarenessEnabled": true,
"ZoneAwarenessConfig": {
"AvailabilityZoneCount": 3
},
"WarmEnabled": true,
"WarmCount": 4,
"WarmType": "ultrawarm1.medium.search",
"ColdStorageOptions": {
"Enabled": true
}
},
"EBSOptions": {
"EBSEnabled": true,
"VolumeType": "gp2",
"VolumeSize": 11
},
"EncryptionAtRestOptions": {
"Enabled": true
},
"NodeToNodeEncryptionOptions": {
"Enabled": true
},
"DomainEndpointOptions": {
"EnforceHTTPS": true,
"TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
},
"AdvancedSecurityOptions": {
"Enabled": true,
"InternalUserDatabaseEnabled": true,
"MasterUserOptions": {
"MasterUserName": "master-user",
"MasterUserPassword": "master-password"
}
},
"EngineVersion": "Opensearch_1.0",
"DomainName": "my-domain"
}
```
Pour obtenir des informations détaillées, consultez le [Amazon OpenSearch Service API Reference](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html).
## Gestion des index de froid dans OpenSearch les tableaux de bord
Vous pouvez gérer les index chauds, chauds et froids à l'aide de l'interface Dashboards existante dans votre domaine de OpenSearch service. Dashboards vous permet de migrer des index entre le stockage à chaud et le stockage à froid, et de surveiller le statut de migration des index, sans utiliser l'interface CLI ni l'API de configuration. Pour plus d'informations, consultez la section [Gestion des index dans les OpenSearch tableaux de bord](dashboards.md#dashboards-indices).
## Migration des index vers le stockage à froid
Lorsque vous migrez des index vers le stockage à froid, vous indiquez une plage de temps pour les données afin de faciliter la découverte. Vous pouvez sélectionner un champ d'horodatage basé sur les données de votre index, fournir manuellement un horodatage de début et de fin, ou choisir de ne pas en spécifier.
| Paramètre | Valeur prise en charge | Description |
| --- | --- | --- |
| timestamp\$1field | date/time Champ issu du mappage d'index. | Les valeurs minimales et maximales du champ fourni sont calculées et stockées en tant que métadonnées `start_time` et `end_time` pour l'index froid. |
| start\$1time et end\$1time | Un des formats suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/cold-storage.html) | Les valeurs fournies sont stockées en tant que métadonnées `start_time` et `end_time` pour l'index froid. |
Si vous ne souhaitez pas spécifier d'horodatage, ajoutez `?ignore=timestamp` à la requête.
La requête suivante migre un index chaud vers le stockage à froid, et fournit les heures de début et de fin des données de cet index :
```
POST _ultrawarm/migration/my-index/_cold
{
"start_time": "2020-03-09",
"end_time": "2020-03-09T23:00:00Z"
}
```
Vérifiez ensuite l'état de la migration :
```
GET _ultrawarm/migration/my-index/_status
{
"migration_status": {
"index": "my-index",
"state": "RUNNING_METADATA_RELOCATION",
"migration_type": "WARM_TO_COLD"
}
}
```
OpenSearch Le service migre un index à la fois vers un stockage à froid. Vous pouvez avoir jusqu'à 100 migrations dans la file d'attente. Toute requête dépassant la limite sera rejetée. Pour vérifier le nombre actuel de migrations dans la file d'attente, consultez la [métrique](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage) `WarmToColdMigrationQueueSize`. Le processus de migration comporte les états suivants :
```
ACCEPTED_COLD_MIGRATION - Migration request is accepted and queued.
RUNNING_METADATA_MIGRATION - The migration request was selected for execution and metadata is migrating to cold storage.
FAILED_METADATA_MIGRATION - The attempt to add index metadata has failed and all retries are exhausted.
PENDING_INDEX_DETACH - Index metadata migration to cold storage is completed. Preparing to detach the warm index state from the local cluster.
RUNNING_INDEX_DETACH - Local warm index state from the cluster is being removed. Upon success, the migration request will be completed.
FAILED_INDEX_DETACH - The index detach process failed and all retries are exhausted.
```
## Automatisation des migrations vers le stockage à froid
Nous vous recommandons d'utiliser [ISM (Index State Management)](ism.md) pour automatiser le processus de migration une fois qu'un index atteint un âge défini ou remplit d'autres conditions. Consultez l'[exemple de politique](ism.md#ism-example-cold), qui montre comment migrer automatiquement les index d'un stockage à chaud vers un stockage UltraWarm à froid.
**Note**
Un `timestamp_field` explicite est nécessaire pour déplacer les index vers le stockage à froid à l'aide d'une politique ISM (Index State Management).
## Annulation des migrations vers le stockage à froid
En cas de mise en file d'attente ou d'échec d'une migration vers le stockage à froid, vous pouvez annuler la migration à l'aide de la requête suivante :
```
POST _ultrawarm/migration/_cancel/my-index
{
"acknowledged" : true
}
```
Si votre domaine utilise le contrôle précis des accès, vous devez disposer de l'autorisation `indices:admin/ultrawarm/migration/cancel` pour effectuer cette requête.
## Répertorier les index froids
Avant de lancer une requête, vous pouvez répertorier les index stockés à froid afin de décider vers lesquels migrer UltraWarm pour une analyse plus approfondie. La requête suivante répertorie tous les index froids, triés par nom d'index :
```
GET _cold/indices/_search
```
**Exemple de réponse**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 3,
"indices" : [
{
"index" : "my-index-1",
"index_cold_uuid" : "hjEoh26mRRCFxRIMdgvLmg",
"size" : 10339,
"creation_date" : "2021-06-28T20:23:31.206Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-2",
"index_cold_uuid" : "0vIS2n-oROmOWDFmwFIgdw",
"size" : 6068,
"creation_date" : "2021-07-15T19:41:18.046Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-3",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
### Filtrage
Vous pouvez filtrer les index froids en fonction d'un modèle d'index basé sur un préfixe et de décalages horaires.
La requête suivante répertorie les index qui correspondent au modèle de préfixe `event-*` :
```
GET _cold/indices/_search
{
"filters":{
"index_pattern": "event-*"
}
}
```
**Exemple de réponse**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "events-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
La requête suivante renvoie les index dont les champs de métadonnées `start_time` et `end_time` sont compris entre `2019-03-01` et `2020-03-01` :
```
GET _cold/indices/_search
{
"filters": {
"time_range": {
"start_time": "2019-03-01",
"end_time": "2020-03-01"
}
}
}
```
**Exemple de réponse**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "my-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2019-05-09T00:00Z",
"end_time" : "2019-09-09T23:00Z"
}
]
}
```
### Tri
Vous pouvez trier les index froids par champs de métadonnées, tels que le nom ou la taille de l'index. La requête suivante répertorie tous les index triés par taille dans l'ordre décroissant :
```
GET _cold/indices/_search
{
"sort_key": "size:desc"
}
```
**Exemple de réponse**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 5,
"indices" : [
{
"index" : "my-index-6",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-9",
"index_cold_uuid" : "mbD3ZRVDRI6ONqgEOsJyUA",
"size" : 57922,
"creation_date" : "2021-07-07T23:41:35.640Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-5",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
Les autres clés de tri valides sont `start_time:asc/desc`, `end_time:asc/desc` et `index_name:asc/desc`.
### Pagination
Vous pouvez paginer une liste d'index froids. Configurez le nombre d'index à renvoyer par page à l'aide du paramètre `page_size` (la valeur par défaut est 10). Chaque requête `_search` effectuée sur vos index froids renvoie un `pagination_id` que vous pouvez utiliser pour les appels suivants.
La requête suivante pagine les résultats d'une requête `_search` de vos index froids et affiche les 100 résultats suivants :
```
GET _cold/indices/_search?page_size=100
{
"pagination_id": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY"
}
```
## Migration d'index à froid vers le stockage à chaud
Après avoir affiné votre liste d'index froids à l'aide des critères de filtrage de la section précédente, faites-les migrer vers l' UltraWarm endroit où vous pouvez interroger les données et les utiliser pour créer des visualisations.
La requête suivante migre deux index froids vers le stockage à chaud :
```
POST _cold/migration/_warm
{
"indices": "my-index1,my-index2"
}
{
"acknowledged" : true
}
```
Pour vérifier le statut de la migration et récupérer l'ID de migration, envoyez la requête suivante :
```
GET _cold/migration/_status
```
**Exemple de réponse**
```
{
"cold_to_warm_migration_status" : [
{
"migration_id" : "tyLjXCA-S76zPQbPVHkOKA",
"indices" : [
"my-index1,my-index2"
],
"state" : "RUNNING_INDEX_CREATION"
}
]
}
```
Pour obtenir des informations de migration spécifiques à un index, incluez le nom de l'index :
```
GET _cold/migration/my-index/_status
```
Plutôt que de spécifier un index, vous pouvez répertorier les index en fonction de leur statut de migration actuel. Les valeurs valides sont `_failed`, `_accepted` et `_all`.
La commande suivante permet d'obtenir le statut de tous les index en une seule requête de migration :
```
GET _cold/migration/_status?migration_id=my-migration-id
```
Récupérez l'ID de migration à l'aide de la requête de statut. Pour obtenir des informations détaillées sur la migration, ajoutez `&verbose=true`.
Vous pouvez migrer des index du stockage à froid vers le stockage tiède par lots de 10, avec un maximum de 100 requêtes migrées de manière simultanée. Toute requête dépassant la limite sera rejetée. Pour vérifier le nombre actuel de migrations en cours, consultez la [métrique](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage) `ColdToWarmMigrationQueueSize`. Le processus de migration comporte les états suivants :
```
ACCEPTED_MIGRATION_REQUEST - Migration request is accepted and queued.
RUNNING_INDEX_CREATION - Migration request is picked up for processing and will create warm indexes in the cluster.
PENDING_COLD_METADATA_CLEANUP - Warm index is created and the migration service will attempt to clean up cold metadata.
RUNNING_COLD_METADATA_CLEANUP - Cleaning up cold metadata from the indexes migrated to warm storage.
FAILED_COLD_METADATA_CLEANUP - Failed to clean up metadata in the cold tier.
FAILED_INDEX_CREATION - Failed to create an index in the warm tier.
```
## Restauration des index à froid à partir d'instantanés
Si vous devez restaurer un index froid supprimé, vous pouvez le restaurer vers le niveau chaud en suivant les instructions fournies dans [Restaurer des index chauds à partir de snapshots](ultrawarm.md#ultrawarm-snapshot) puis en faisant migrer à nouveau l'index vers le niveau froid. Vous ne pouvez pas restaurer un index de froid supprimé directement dans le niveau de froid. OpenSearch Le service conserve les index froids pendant 14 jours après leur suppression.
## Annulation des migrations du stockage à froid vers le stockage à chaud
Si une migration d'index du stockage à froid vers le stockage à chaud est mise en file d'attente ou échoue, vous pouvez l'annuler à l'aide de la demande suivante :
```
POST _cold/migration/my-index/_cancel
{
"acknowledged" : true
}
```
Pour annuler la migration d'un lot d'index (10 maximum à la fois), spécifiez l'ID de la migration :
```
POST _cold/migration/_cancel?migration_id=my-migration-id
{
"acknowledged" : true
}
```
Récupérez l'ID de migration à l'aide de la requête de statut.
## Mise à jour des métadonnées des index froids
Vous pouvez mettre à jour les champs `start_time` et `end_time` d'un index froid :
```
PATCH _cold/my-index
{
"start_time": "2020-01-01",
"end_time": "2020-02-01"
}
```
Vous ne pouvez pas mettre à jour le champ `timestamp_field` d'un index dans le stockage à froid.
**Note**
OpenSearch Les tableaux de bord ne prennent pas en charge la méthode PATCH. Utilisez [Curl](https://curl.haxx.se/), [Postman](https://www.getpostman.com/) ou une autre méthode pour mettre à jour les métadonnées froides.
## Supprimer des index froids
Si vous n'utilisez pas de politique ISM, vous pouvez supprimer les index froids manuellement. La demande suivante supprime un index froid :
```
DELETE _cold/my-index
{
"acknowledged" : true
}
```
## Désactivation du stockage à froid
La console OpenSearch de service est le moyen le plus simple de désactiver le stockage à froid. Sélectionnez le domaine et choisissez **Actions**,**Edit cluster configuration (Modifier la configuration de cluster)**, puis désélectionnez **Enable cold storage (Activer le stockage à froid)**.
Pour utiliser la AWS CLI ou l'API de configuration, sous`ColdStorageOptions`, définissez`"Enabled"="false"`.
Avant de désactiver le stockage à froid, vous devez supprimer tous les index froids ou les migrer à nouveau vers le stockage à chaud, sinon la désactivation échouera.
# Gestion de l'état de l'index dans Amazon OpenSearch Service
La gestion de l'état des index (ISM) d'Amazon OpenSearch Service vous permet de définir des politiques de gestion personnalisées qui automatisent les tâches de routine et les appliquent aux index et aux modèles d'index. Vous n'avez plus besoin de configurer et de gérer des processus externes pour exécuter vos opérations d'index.
Chaque politique contient un état par défaut et une liste d'états pour la transition de l'index. Dans chaque état, vous pouvez définir une liste d'actions à effectuer et les conditions qui déclenchent ces transitions. Un cas d'utilisation typique consiste à supprimer périodiquement les anciens index après un certain temps. Par exemple, vous pouvez définir une politique qui déplace votre index dans un état `read_only` après 30 jours, puis les supprime après 90 jours.
Après avoir attaché une politique à un index, ISM crée une tâche qui s'exécute toutes les 5 à 8 minutes (ou 30 à 48 minutes pour les clusters antérieurs à 1.3) pour effectuer des actions de la politique, vérifier les conditions et faire passer l'index par différents états. En général, cette tâche est exécutée toutes les 5 minutes, plus une instabilité aléatoire de 0 à 60 % y est ajoutée pour vous assurer de ne pas voir un pic d'activité de tous vos indices en même temps. ISM n'exécute pas de tâches si l'état du cluster est rouge.
ISM nécessite OpenSearch Elasticsearch 6.8 ou version ultérieure.
**Note**
Cette documentation fournit un bref aperçu de l'ISM ainsi que plusieurs exemples de politiques. Il explique également en quoi l'ISM pour les domaines Amazon OpenSearch Service diffère de l'ISM sur les OpenSearch clusters autogérés. Pour une documentation complète d'ISM, y compris une référence complète des paramètres, une description de chaque paramètre et une référence d'API, consultez la section [Gestion de l'état des index](https://docs.opensearch.org/latest/im-plugin/ism/index/) dans la OpenSearch documentation.
**Important**
Vous ne pouvez plus utiliser de modèles d'index pour appliquer des stratégies ISM aux index nouvellement créés. Vous pouvez continuer à gérer automatiquement les index nouvellement créés via le [champ Modèle ISM](https://opensearch.org/docs/latest/im-plugin/ism/policies/#sample-policy-with-ism-template-for-auto-rollover). Cette mise à jour introduit un changement radical qui affecte les CloudFormation modèles existants utilisant ce paramètre.
## Créer une politique ISM
**Pour commencer à utiliser Index State Management**
1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home).
1. Choisissez le domaine pour lequel vous voulez créer une stratégie ISM.
1. Depuis le tableau de bord du domaine, accédez à l'URL des OpenSearch tableaux de bord et connectez-vous à l'aide de votre nom d'utilisateur et de votre mot de passe principaux. Le format de l'URL est le suivant :
```
domain-endpoint/_dashboards/
```
1. Ouvrez le panneau de navigation de gauche dans les OpenSearch tableaux de bord et choisissez **Gestion des index**, puis **Créer une politique**.
1. Vous pouvez utiliser l'[éditeur visuel](https://opensearch.org/docs/latest/im-plugin/ism/index/#visual-editor) ou l'[éditeur JSON](https://opensearch.org/docs/latest/im-plugin/ism/index/#json-editor) pour créer des stratégies. Nous vous recommandons d'utiliser l'éditeur visuel, car il offre un moyen plus structuré de définir les politiques. Afin d'obtenir de l'aide pour la création de stratégies, consultez les [exemples de stratégies](#ism-example) suivants.
1. Après avoir créé une stratégie, attachez-la à un ou plusieurs index :
```
POST _plugins/_ism/add/my-index
{
"policy_id": "my-policy-id"
}
```
**Note**
Si votre domaine exécute une ancienne version d'Elasticsearch, utilisez `_opendistro` au lieu de `_plugins`.
Vous pouvez également sélectionner l'index dans les OpenSearch tableaux de bord et choisir **Appliquer la politique**.
## Exemples de politiques
Les exemples de politique suivants montrent comment automatiser les cas d'utilisation ISM courants.
### Stockage à chaud > stockage UltraWarm > stockage à froid
Cet exemple de politique déplace un index du stockage à chaud vers [UltraWarm](ultrawarm.md), et éventuellement vers [stockage à froid](cold-storage.md). Ensuite, il supprime l'index.
L'état initial de l'index est `hot`. Après dix jours, ISM le fait passer à l'état `warm`. 80 jours plus tard, l'index a plus de 90 jours et passe à l'état `cold`. Après un an, le service envoie une notification à une salle Amazon Chime pour indiquer que l'index est en cours de suppression, puis le supprime définitivement.
Notez que les index froids requièrent l'opération `cold_delete` plutôt que l'opération `delete` normale. Notez également qu'un `timestamp_field` explicite est nécessaire dans vos données afin de gérer les index froids avec ISM.
```
{
"policy": {
"description": "Demonstrate a hot-warm-cold-delete workflow.",
"default_state": "hot",
"schema_version": 1,
"states": [{
"name": "hot",
"actions": [],
"transitions": [{
"state_name": "warm",
"conditions": {
"min_index_age": "10d"
}
}]
},
{
"name": "warm",
"actions": [{
"warm_migration": {},
"retry": {
"count": 5,
"delay": "1h"
}
}],
"transitions": [{
"state_name": "cold",
"conditions": {
"min_index_age": "90d"
}
}]
},
{
"name": "cold",
"actions": [{
"cold_migration": {
"timestamp_field": ""
}
}
],
"transitions": [{
"state_name": "delete",
"conditions": {
"min_index_age": "365d"
}
}]
},
{
"name": "delete",
"actions": [{
"notification": {
"destination": {
"chime": {
"url": ""
}
},
"message_template": {
"source": "The index {{ctx.index}} is being deleted."
}
}
},
{
"cold_delete": {}
}]
}
]
}
}
```
### Réduire le nombre de réplicas
Cet exemple de politique réduit le nombre de réplicas à zéro au bout de sept jours pour économiser de l'espace disque, puis supprime l'index au bout de 21 jours. Cette politique suppose que votre index n'est pas critique et ne reçoit plus de demandes d'écriture, et qu'aucun réplica ne comporte un risque de perte de données.
```
{
"policy": {
"description": "Changes replica count and deletes.",
"schema_version": 1,
"default_state": "current",
"states": [{
"name": "current",
"actions": [],
"transitions": [{
"state_name": "old",
"conditions": {
"min_index_age": "7d"
}
}]
},
{
"name": "old",
"actions": [{
"replica_count": {
"number_of_replicas": 0
}
}],
"transitions": [{
"state_name": "delete",
"conditions": {
"min_index_age": "21d"
}
}]
},
{
"name": "delete",
"actions": [{
"delete": {}
}],
"transitions": []
}
]
}
}
```
### Prendre un instantané d'index
Cet exemple de politique utilise l'opération `[snapshot](https://docs.opensearch.org/latest/im-plugin/ism/policies/#snapshot)` pour prendre un instantané d'un index dès qu'il contient au moins un document. `repository` correspond au nom du référentiel d'instantanés manuels que vous avez enregistré dans Amazon S3. `snapshot` correspond au nom de l'instantané. Pour connaître les prérequis relatifs aux instantanés ainsi que la procédure à suivre pour enregistrer un référentiel, consultez [Création d'instantanés d'index dans Amazon Service OpenSearch](managedomains-snapshots.md).
```
{
"policy": {
"description": "Takes an index snapshot.",
"schema_version": 1,
"default_state": "empty",
"states": [{
"name": "empty",
"actions": [],
"transitions": [{
"state_name": "occupied",
"conditions": {
"min_doc_count": 1
}
}]
},
{
"name": "occupied",
"actions": [{
"snapshot": {
"repository": "",
"snapshot": ""
}
}],
"transitions": []
}
]
}
}
```
## Modèles ISM
Vous pouvez configurer un champ `ism_template` dans une politique afin que, lorsque vous créez un index qui correspond au modèle, la politique soit automatiquement attachée à cet index. Dans cet exemple, tout index créé dont le nom commence par « log » est automatiquement mis en correspondance avec la politique ISM `my-policy-id` :
```
PUT _plugins/_ism/policies/my-policy-id
{
"policy": {
"description": "Example policy.",
"default_state": "...",
"states": [...],
"ism_template": {
"index_patterns": ["log*"],
"priority": 100
}
}
}
```
Pour un exemple plus détaillé, consultez [Exemple de politique avec modèle ISM pour la substitution automatique](https://opensearch.org/docs/latest/im-plugin/ism/policies/#sample-policy-with-ism-template-for-auto-rollover).
## Différences
Par rapport à OpenSearch Elasticsearch, ISM for Amazon OpenSearch Service présente plusieurs différences.
### Opérations ISM
+ OpenSearch Le service prend en charge trois opérations ISM uniques `warm_migration``cold_migration`,, et `cold_delete` :
+ Si votre domaine est [UltraWarm](ultrawarm.md)activé, l'`warm_migration`action fait passer l'index au stockage à chaud.
+ Si le [stockage à froid](cold-storage.md) est activé sur votre domaine, l'action `cold_migration` fait passer l'index au stockage à froid et l'action `cold_delete` supprime l'index du stockage à froid.
Même si l'une de ces actions ne se termine pas dans le [délai d'attente défini](https://docs.opensearch.org/latest/im-plugin/ism/policies/#actions), la migration ou la suppression des index se poursuit. Définir une notification d'erreur [error\$1notification](https://opensearch.org/docs/latest/im-plugin/ism/policies/#error-notifications) pour l'une des actions ci-dessus vous permettra de savoir que l'action a échoué si elle ne s'est pas terminée dans le délai imparti, elle est toutefois uniquement destinée à votre propre référence. L'opération proprement dite n'a pas dépassé le délai d'attente et continue de s'exécuter jusqu'à ce qu'elle réussisse ou échoue.
+ Si votre domaine fonctionne avec Elasticsearch 7.4 OpenSearch ou version ultérieure, le OpenSearch Service prend en charge l'ISM `open` et `close` les opérations.
+ Si votre domaine fonctionne avec Elasticsearch 7.7 OpenSearch ou version ultérieure, le OpenSearch service prend en charge le fonctionnement ISM`snapshot`.
### Opérations ISM de stockage à froid
Pour les index froids, vous devez spécifier un `?type=_cold` paramètre lorsque vous utilisez l'ISM APIs suivant :
+ [Ajouter une stratégie](https://opensearch.org/docs/latest/im-plugin/ism/api/#add-policy)
+ [Supprimer une stratégie](https://opensearch.org/docs/latest/im-plugin/ism/api/#remove-policy-from-index)
+ [Mettre à jour une stratégie](https://opensearch.org/docs/latest/im-plugin/ism/api/#update-policy)
+ [Réessayer une indexation qui a échoué](https://opensearch.org/docs/latest/im-plugin/ism/api/#retry-failed-index)
+ [Expliquer un index](https://opensearch.org/docs/latest/im-plugin/ism/api/#explain-index)
APIs Pour les indices de froid, ils présentent les différences supplémentaires suivantes :
+ Les opérateurs de caractères génériques ne sont pas pris en charge, à moins que vous les utilisiez à la fin. Par exemple, `_plugins/_ism//logstash-*` est pris en charge, mais `_plugins/_ism//iad-*-prod` ne l'est pas.
+ Les modèles et noms à plusieurs index ne sont pas pris en charge. Par exemple, `_plugins/_ism//app-logs` est pris en charge, mais `_plugins/_ism//app-logs,sample-data` ne l'est pas.
### Paramètres ISM
OpenSearch et Elasticsearch vous permettent de modifier tous les paramètres ISM disponibles à l'aide de l'`_cluster/settings`API. Sur Amazon OpenSearch Service, vous ne pouvez modifier que les [paramètres ISM](https://opensearch.org/docs/latest/im-plugin/ism/settings/) suivants :
+ **Paramètres au niveau du cluster :**
+ `plugins.index_state_management.enabled`
+ `plugins.index_state_management.history.enabled`
+ **Paramètres au niveau de l'index :**
+ `plugins.index_state_management.rollover_alias`
# Didacticiel : automatisation des processus de gestion de l'état des index
Ce didacticiel montre comment implémenter une politique ISM qui automatise les tâches de routine de gestion des index et les applique aux index et aux modèles d'index.
[La gestion de l'état des index (ISM)](ism.md) d'Amazon OpenSearch Service vous permet d'automatiser les activités récurrentes de gestion des index, afin d'éviter d'utiliser des outils supplémentaires pour gérer les cycles de vie des index. Vous pouvez créer une politique qui automatise ces opérations en fonction de l'âge, de la taille de l'index et d'autres conditions, le tout depuis votre domaine Amazon OpenSearch Service.
OpenSearch Le service prend en charge trois niveaux de stockage : l'état « chaud » par défaut pour l'écriture active et les analyses à faible latence, UltraWarm pour les données en lecture seule jusqu'à trois pétaoctets, et le stockage à froid pour un archivage à long terme illimité.
Ce didacticiel présente un exemple de cas d'utilisation de la gestion de données de séries temporelles dans des index quotidiens. Dans ce didacticiel, vous configurez une politique qui prend un instantané automatisé de chaque index attaché après 24 heures. Il fait ensuite migrer l'index de l'état chaud par défaut vers le UltraWarm stockage après deux jours, le stockage à froid après 30 jours, et enfin supprime l'index après 60 jours.
## Conditions préalables
+ Votre domaine OpenSearch de service doit exécuter Elasticsearch version 6.8 ou ultérieure.
+ Le [stockage à froid](cold-storage.md) doit [UltraWarm](ultrawarm.md)être activé sur votre domaine.
+ Vous devez [inscrire un référentiel d'instantanés manuels](managedomains-snapshot-registerdirectory.md) pour votre domaine.
+ Votre rôle d'utilisateur nécessite des autorisations suffisantes pour accéder à la console OpenSearch de service. Si nécessaire, validez et [configurez l'accès à votre domaine](ac.md).
## Étape 1 : Configurer la politique ISM
Tout d'abord, configurez une politique ISM dans les OpenSearch tableaux de bord.
1. Depuis le tableau de bord de votre domaine dans la console de OpenSearch service, accédez à l'URL OpenSearch des tableaux de bord et connectez-vous à l'aide de votre nom d'utilisateur et de votre mot de passe principaux. Le format de l'URL est le suivant : `domain-endpoint/_dashboards/`.
1. Dans OpenSearch Tableaux de bord, choisissez **Ajouter des exemples de données** et ajoutez un ou plusieurs exemples d'index à votre domaine.
1. Ouvrez le panneau de navigation de gauche et choisissez **Index Management** (Gestion des index), puis **Create policy** (Créer une politique).
1. Nommez la stratégie `ism-policy-example`.
1. Remplacez la stratégie par défaut par la stratégie suivante :
```
{
"policy": {
"description": "Move indexes between storage tiers",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "snapshot",
"conditions": {
"min_index_age": "24h"
}
}
]
},
{
"name": "snapshot",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "30m"
},
"snapshot": {
"repository": "snapshot-repo",
"snapshot": "ism-snapshot"
}
}
],
"transitions": [
{
"state_name": "warm",
"conditions": {
"min_index_age": "2d"
}
}
]
},
{
"name": "warm",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"warm_migration": {}
}
],
"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "30d"
}
}
]
},
{
"name": "cold",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"cold_migration": {
"start_time": null,
"end_time": null,
"timestamp_field": "@timestamp",
"ignore": "none"
}
}
],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "60d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"cold_delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"index-*"
],
"priority": 100
}
]
}
}
```
**Note**
Le champ `ism_template` attache automatiquement la politique à tout index nouvellement créé qui correspond à l'un des `index_patterns` spécifiés. Dans ce cas, tous les index qui commencent par `index-`. Vous pouvez modifier ce champ pour qu'il corresponde à un format d'index dans votre environnement. Pour plus d'informations, consultez [Modèles ISM](ism.md#ism-template).
1. Dans la section `snapshot` de la politique, remplacez `snapshot-repo` par le nom du [référentiel d'instantanés](managedomains-snapshot-registerdirectory.md) que vous avez inscrit pour votre domaine. Vous pouvez également remplacer facultativement `ism-snapshot`, qui sera le nom de l'instantané lorsqu'il sera créé.
1. Sélectionnez **Create** (Créer). La politique est maintenant visible sur la page **State management policies** (Politiques de gestion des états).
## Étape 2 : Attacher la politique à un ou plusieurs index
Maintenant que vous avez créé votre politique, attachez-la à un ou plusieurs index dans votre cluster.
1. Accédez à l'onglet **Hot indices** (Index hot) et recherchez `opensearch_dashboards_sample`, qui répertorie tous les exemples d'index que vous avez ajoutés à l'étape 1.
1. Sélectionnez tous les index et choisissez **Appliquer la politique**, puis choisissez la **ism-policy-example**politique que vous venez de créer.
1. Cliquez sur **Appliquer**.
Vous pouvez surveiller les index à mesure qu'ils passent par les différents états sur la page **Policy managed indices** (Index gérés par politique).
# Récapitulatif des index dans Amazon OpenSearch Service à l'aide de cumuls d'index
Les cumuls d'index dans Amazon OpenSearch Service vous permettent de réduire les coûts de stockage en regroupant régulièrement les anciennes données dans des index résumés.
Vous sélectionnez les champs qui vous intéressent et utilisez un cumulatif d'index pour créer un nouvel index avec uniquement ces champs agrégés dans des compartiments de temps plus sommaires. Vous pouvez stocker des mois ou des années de données historiques à une fraction du coût avec les mêmes performances de requête.
Les cumuls d'index nécessitent Elasticsearch 7.9 OpenSearch ou version ultérieure.
**Note**
Cette documentation vous aide à démarrer avec la création d'une tâche de cumul d'index dans Amazon OpenSearch Service. Pour une documentation complète, y compris une liste de tous les paramètres disponibles et une référence complète de l'API, voir [Index cumulés dans](https://docs.opensearch.org/latest/im-plugin/index-rollups/) la OpenSearch documentation.
## Création d'une tâche de cumulatif d'index
Pour commencer, choisissez **Gestion des index** dans les OpenSearch tableaux de bord. Sélectionnez **Tâches de cumulatif** et choisissez **Créer une tâche de cumulatif**.
### Étape 1 : Configuration des index
Configurez les index source et cible. L'index source correspond à l'index que vous souhaitez cumuler. L'index cible correspond à l'emplacement où les résultats du cumulatif d'index sont enregistrés.
Après avoir créé une tâche de cumulatif d'index, vous ne pouvez pas modifier vos sélections d'index.
### Étape 2 : Définir des agrégations et des métriques
Sélectionnez les attributs avec les agrégations (termes et histogrammes) et les métriques (moyenne, somme, max, min et nombre de valeurs) que vous souhaitez cumuler. Assurez-vous de ne pas ajouter trop d'attributs hautement granulaires car vous n'économiseriez pas beaucoup d'espace.
### Étape 3 : Spécifier des planifications
Spécifiez une planification pour cumuler vos index au fur et à mesure de leur ingestion. La tâche de cumulatif d'index est activée par défaut.
### Étape 4 : vérifier et créer
Vérifiez votre configuration et sélectionnez **Créer**.
### Étape 5 : Rechercher dans l'index cible
Vous pouvez utiliser l'API standard `_search` pour effectuer une recherche dans l'index cible. Dans l'index cible, vous ne pouvez pas accéder à la structure interne des données, car le plug-in réécrit automatiquement la requête en arrière-plan pour l'adapter à l'index cible. Ainsi, vous pouvez utiliser la même requête pour l'index source et l'index cible.
Pour interroger l'index cible, définissez `size` sur 0 :
```
GET target_index/_search
{
"size": 0,
"query": {
"match_all": {}
},
"aggs": {
"avg_cpu": {
"avg": {
"field": "cpu_usage"
}
}
}
}
```
**Note**
OpenSearch les versions 2.2 et ultérieures prennent en charge la recherche dans plusieurs index cumulatifs en une seule requête. OpenSearch les versions antérieures à 2.2 et les anciennes versions d'Elasticsearch OSS ne prennent en charge qu'un seul index cumulatif par recherche.
# Transformation des index dans Amazon Service OpenSearch
Alors que les [tâches de cumul d'index](rollup.md) vous permettent de réduire la granularité des données en regroupant les anciennes données en index condensés, les tâches de transformation vous permettent de créer une vue différente et résumée de vos données centrée sur certains champs, afin que vous puissiez visualiser ou analyser les données de différentes manières.
Les transformations d'index disposent d'une interface utilisateur de OpenSearch tableaux de bord et d'une API REST. La fonctionnalité nécessite la OpenSearch version 1.0 ou ultérieure.
**Note**
Cette documentation fournit un bref aperçu des transformations d'index pour vous aider à commencer à les utiliser sur un domaine Amazon OpenSearch Service. Pour une documentation complète et une référence sur l'API REST, voir les [transformations d'index](https://docs.opensearch.org/latest/im-plugin/index-transforms/) dans la OpenSearch documentation open source.
## Création d'une tâche de transformation d'index
Si votre cluster ne contient aucune donnée, utilisez les exemples de données de vol figurant dans les OpenSearch tableaux de bord pour essayer des tâches de transformation. Après avoir ajouté les données, lancez OpenSearch Dashboards. Choisissez ensuite **Index Management** (Gestion des index), **Transform Jobs** (Tâches de transformation) et **Create Transform Job** (Créer une tâche de transformation).
### Étape 1 : Choisissez les index
Dans la section **Indices** (Index), sélectionnez l'index source et l'index cible. Vous pouvez soit sélectionner un index cible existant, soit en créer un nouveau en lui donnant un nom.
Si vous souhaitez transformer uniquement un sous-ensemble de votre index source, choisissez **Ajouter un filtre de données** et utilisez la OpenSearch [requête DSL](https://docs.opensearch.org/latest/opensearch/query-dsl/) pour spécifier un sous-ensemble de votre index source.
### Étape 2 : Choix des champs
Après avoir choisi vos index, choisissez les champs que vous souhaitez utiliser dans votre travail de transformation, et indiquez si vous souhaitez utiliser des groupements ou des agrégations.
+ Vous pouvez utiliser des regroupements pour placer vos données dans des compartiments séparés dans votre index transformé. Par exemple, si vous souhaitez regrouper toutes les destinations aéroportuaires dans les exemples de données de vol, regroupez le `DestAirportID` champ dans un champ ou un champ cible, et vous pourrez retrouver l'aéroport groupé IDs dans votre index transformé une fois la tâche de transformation terminée. `DestAirportID_terms`
+ D'autre part, les agrégations vous permettent d'effectuer des calculs simples. Par exemple, vous pouvez inclure une agrégation dans votre tâche de transformation pour définir un nouveau champ de `sum_of_total_ticket_price` qui calcule la somme de tous les billets d'avion. Vous pouvez ensuite analyser les nouvelles données dans votre index transformé.
### Étape 3 : Spécifier une planification
Les tâches de transformation sont activées par défaut et s'exécutent selon des planifications. Pour **transform execution interval** (intervalle d'exécution de transformation), spécifiez un intervalle en minutes, heures ou jours.
### Étape 4 : Vérifier et surveiller
Vérifiez votre configuration et sélectionnez **Créer**. Surveillez ensuite la colonne **Transform job status** (État de la tâche de transformation).
### Étape 5 : Rechercher dans l'index cible
Une fois la tâche terminée, vous pouvez utiliser l'API standard `_search` pour effectuer une recherche dans l'index cible.
Par exemple, après avoir exécuté une tâche de transformation qui transforme les données de vol en fonction du champ `DestAirportID`, vous pouvez exécuter la requête suivante pour renvoyer tous les champs dont la valeur est `SFO` :
```
GET target_index/_search
{
"query": {
"match": {
"DestAirportID_terms" : "SFO"
}
}
}
```
# Réplication entre clusters pour Amazon Service OpenSearch
Grâce à la réplication entre clusters dans Amazon OpenSearch Service, vous pouvez répliquer les index utilisateur, les mappages et les métadonnées d'un domaine de OpenSearch service à un autre. L'utilisation de la réplication entre clusters contribue à assurer la reprise après sinistre en cas l'interruption de service et vous permet de répliquer des données dans des centres de données géographiquement éloignés afin de réduire la latence. Vous payez les [frais de transfert de AWS données standard](https://aws.amazon.com/opensearch-service/pricing/) pour les données transférées entre les domaines.
*La réplication entre clusters suit un modèle de réplication actif-passif dans lequel l'index *local* ou *suiveur* extrait les données de l'index *distant* ou principal.* L'indice leader fait référence à la source des données, ou à l'index à partir duquel vous souhaitez répliquer les données. L'index suiveur fait référence à la cible des données, ou à l'index vers lequel vous souhaitez répliquer les données.
La réplication entre clusters est disponible sur les domaines exécutant Elasticsearch 7.10 ou 1.1 ou OpenSearch version ultérieure.
**Note**
Cette documentation explique comment configurer la réplication entre clusters du point de vue d'Amazon OpenSearch Service. Cela inclut l'utilisation de AWS Management Console pour configurer des connexions entre clusters, ce qui n'est pas possible sur un cluster autogéré OpenSearch . Pour une documentation complète, y compris une référence aux paramètres et une référence d'API complète, consultez la section [Réplication entre clusters](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/index/) dans la OpenSearch documentation.
**Topics**
+ [Limitations](#replication-limitations)
+ [Conditions préalables](#replication-prereqs)
+ [Conditions d'autorisation](#replication-permissions)
+ [Configurer une connexion inter-clusters](#replication-connect)
+ [Démarrer la réplication](#replication-start)
+ [Confirmer la réplication](#replication-confirm)
+ [Mettre en pause et reprendre la réplication](#replication-pause-resume)
+ [Arrêter la réplication](#replication-stop)
+ [Suivi automatique](#replication-autofollow)
+ [Mise à niveau des domaines connectés](#replication-upgrade)
## Limitations
La réplication inter-clusters (CCR) présente les limitations suivantes :
+ Vous ne pouvez pas répliquer des données entre des domaines Amazon OpenSearch Service et des clusters autogérés OpenSearch ou Elasticsearch.
+ Vous ne pouvez pas répliquer un index d'un domaine suiveur vers un autre domaine suiveur. Si vous souhaitez répliquer un index vers plusieurs domaines abonnés, vous ne pouvez le répliquer qu'à partir du seul domaine leader.
+ Un domaine peut être connecté, via une combinaison de connexions entrantes et sortantes, à un maximum de 20 autres domaines.
+ Lorsque vous configurez initialement une connexion entre clusters, le domaine principal doit se trouver sur une version identique ou supérieure à celle du domaine suiveur.
+ Vous ne pouvez pas l'utiliser CloudFormation pour connecter des domaines.
+ Vous ne pouvez pas utiliser la réplication inter-clusters (CCR) sur des instances M3 ou les instances extensibles (T2 et T3).
+ Vous ne pouvez pas répliquer des données entre des index UltraWarm ou des index à froid. Les deux index doivent être dans un stockage à chaud.
+ Lorsque vous supprimez un index du domaine leader, l'index correspondant du domaine suiveur n'est pas automatiquement supprimé.
+ La réplication entre clusters n'est pas prise en charge entre le mode par défaut et l'[option opt-in](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html). Les deux domaines doivent se trouver soit dans des régions par défaut, soit dans des régions facultatives.
## Conditions préalables
Avant de configurer la réplication inter-clusters (CCR), vérifiez que vos domaines répondent aux exigences suivantes :
+ Elasticsearch 7.10 ou 1.1 ou version ultérieure OpenSearch
+ [Contrôle précis des accès](fgac.md) activé
+ [Node-to-node chiffrement](ntn.md) activé
+ Les indices Leader doivent être `index.soft_deletes.enabled` définis sur`true`. Ce paramètre est activé par défaut pour les indices créés dans Elasticsearch 7.0 ou OpenSearch 1.0 et versions ultérieures. Toutefois, les index créés dans Elasticsearch 6.x puis mis à niveau restent conservés. `soft_deletes=false` Pour répliquer de tels indices, vous devez d'abord les réindexer.
Pour vérifier si les suppressions logicielles sont activées pour un index :
```
GET /_settings?include_defaults=true&flat_settings=true&filter_path=*.settings.index.soft_deletes.enabled
```
Dans `soft_deletes` l'affirmative`false`, réindexez les données dans un nouvel index avant de démarrer la réplication.
## Conditions d'autorisation
Pour commencer la réplication, vous devez inclure l'autorisation `es:ESCrossClusterGet` dans le domaine distant (leader). Nous recommandons la politique IAM suivante pour le domaine distant. Cette politique vous permet également d'effectuer d'autres opérations, telles que l'indexation de documents et la réalisation de recherches standard :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/leader-domain/*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESCrossClusterGet",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/leader-domain"
}
]
}
```
------
Assurez-vous que l'autorisation `es:ESCrossClusterGet` est appliquée pour `/leader-domain` et non pour `/leader-domain/*`.
Pour que les utilisateurs non-administrateurs puissent effectuer des activités de réplication, ils doivent également être mappés aux autorisations appropriées. La plupart des autorisations correspondent à des [opérations d'API REST](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/api/) spécifiques. Par exemple, l'autorisation `indices:admin/plugins/replication/index/_resume` vous permet de reprendre la réplication d'un index. Pour obtenir la liste complète des autorisations, consultez la section [Autorisations de réplication](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#replication-permissions) dans la OpenSearch documentation.
**Note**
Les commandes permettant de démarrer la réplication et de créer une règle de réplication sont des cas particuliers. Comme ils invoquent des processus en arrière-plan sur les domaines leader et suiveur, vous devez transmettre un `leader_cluster_role` et `follower_cluster_role` dans la demande. OpenSearch Le service utilise ces rôles dans toutes les tâches de réplication du backend. Pour plus d'informations sur le mappage et l'utilisation de ces rôles, voir [Mapper les rôles du cluster leader et suiveur](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles) dans la OpenSearch documentation.
## Configurer une connexion inter-clusters
Pour répliquer des index d'un domaine à un autre, vous devez configurer une connexion inter-clusters entre les domaines. La manière la plus simple de connecter des domaines consiste à utiliser l'onglet **Connexions** du tableau de bord du domaine. Vous pouvez également utiliser [l'API de configuration](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html) ou la [CLI AWS](https://docs.aws.amazon.com/cli/latest/reference/opensearch/create-outbound-connection.html). Étant donné que la réplication inter-clusters (CCR) suit un modèle « pull », vous initiez des connexions à partir du domaine suiveur.
**Note**
Si vous avez déjà connecté deux domaines pour effectuer des [recherches inter-clusters](cross-cluster-search.md), vous ne pouvez pas utiliser cette même connexion pour la réplication. La connexion est marquée comme `SEARCH_ONLY` dans la console. Afin d'effectuer une réplication entre deux domaines précédemment connectés, vous devez supprimer la connexion et la recréer. Une fois cette opération effectuée, la connexion est disponible pour la recherche inter-clusters et la réplication inter-clusters.
**Configurer une connexion**
1. Dans la console Amazon OpenSearch Service, sélectionnez le domaine abonné, accédez à l'onglet **Connections**, puis choisissez **Request**.
1. Dans **Alias de la connexion**, saisissez un nom pour votre connexion.
1. Choisissez entre vous connecter à un domaine dans votre Compte AWS région ou dans un autre compte ou région.
+ Pour vous connecter à un domaine dans votre Compte AWS région, sélectionnez le domaine et choisissez **Request**.
+ Pour vous connecter à un domaine situé dans une autre région Compte AWS ou dans une autre région, spécifiez l'ARN du domaine distant et choisissez **Request**.
OpenSearch Le service valide la demande de connexion. Si les domaines sont incompatibles, la connexion échouera. Si la validation réussit, elle sera envoyée au domaine de destination pour approbation. Lorsque le domaine de destination approuvera la demande, vous pourrez commencer la réplication.
La réplication entre clusters prend en charge la réplication bidirectionnelle. Cela signifie que vous pouvez créer une connexion sortante entre le domaine A et le domaine B et une autre connexion sortante entre le domaine B et le domaine A. Vous pouvez ensuite configurer la réplication de telle sorte que le domaine A suive un index dans le domaine B et que le domaine B suive un index dans le domaine A.
## Démarrer la réplication
Après avoir établi une connexion inter-clusters, vous pourrez commencer à répliquer des données. Commencez par créer un index dans le domaine leader à répliquer :
```
PUT leader-01
```
Pour répliquer cet index, envoyez cette commande au domaine suiveur :
```
PUT _plugins/_replication/follower-01/_start
{
"leader_alias": "connection-alias",
"leader_index": "leader-01",
"use_roles":{
"leader_cluster_role": "all_access",
"follower_cluster_role": "all_access"
}
}
```
Vous trouverez l'alias de connexion dans l'onglet **Connexions** du tableau de bord de votre domaine.
Cet exemple suppose qu'un administrateur émette la demande et utilise `all_access` pour le `leader_cluster_role` et le `follower_cluster_role` pour plus de simplicité. Dans les environnements de production, cependant, nous vous recommandons de créer des utilisateurs de réplication à la fois sur les index leader et suiveur et de les mapper en conséquence. Les noms d'utilisateur doivent être identiques. Pour plus d'informations sur ces rôles et sur la façon de les mapper, voir [Mapper les rôles du cluster leader et suiveur](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles) dans la OpenSearch documentation.
## Confirmer la réplication
Pour confirmer que la réplication est en cours, obtenez l'état de la réplication :
```
GET _plugins/_replication/follower-01/_status
{
"status" : "SYNCING",
"reason" : "User initiated",
"leader_alias" : "connection-alias",
"leader_index" : "leader-01",
"follower_index" : "follower-01",
"syncing_details" : {
"leader_checkpoint" : -5,
"follower_checkpoint" : -5,
"seq_no" : 0
}
}
```
Les valeurs du point de contrôle du leader et du suiveur commencent par des entiers négatifs et reflètent le nombre de partitions dont vous disposez (-1 pour une seule partition, -5 pour cinq partitions, etc.). Les valeurs sont incrémentées en entiers positifs à chaque modification apportée. Si les valeurs sont identiques, cela signifie que les index sont parfaitement synchronisés. Vous pouvez utiliser ces valeurs de point de contrôle pour mesurer la latence de réplication entre vos domaines.
Pour mieux valider la réplication, ajoutez un document à l'index leader :
```
PUT leader-01/_doc/1
{
"Doctor Sleep":"Stephen King"
}
```
Et confirmez qu'il s'affiche dans l'index suiveur :
```
GET follower-01/_search
{
...
"max_score" : 1.0,
"hits" : [
{
"_index" : "follower-01",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"Doctor Sleep" : "Stephen King"
}
}
]
}
}
```
## Mettre en pause et reprendre la réplication
Vous pouvez suspendre temporairement la réplication si vous devez résoudre des problèmes ou réduire la charge sur le domaine leader. Envoyez cette demande au domaine suiveur. Veillez à inclure un corps de requête vide :
```
POST _plugins/_replication/follower-01/_pause
{}
```
Obtenez ensuite l'état pour vous assurer que la réplication est suspendue :
```
GET _plugins/_replication/follower-01/_status
{
"status" : "PAUSED",
"reason" : "User initiated",
"leader_alias" : "connection-alias",
"leader_index" : "leader-01",
"follower_index" : "follower-01"
}
```
Lorsque les modifications seront terminées, reprenez la réplication. Envoyez cette demande au domaine suiveur. Veillez à inclure un corps de requête vide :
```
POST _plugins/_replication/follower-01/_resume
{}
```
Vous ne pouvez pas reprendre la réplication après qu'elle a été mise en pause pendant plus de 12 heures. Vous devez arrêter la réplication, supprimer l'index suiveur et redémarrer la réplication du leader.
## Arrêter la réplication
Quand vous arrêtez complètement la réplication, l'index suiveur cessera de suivre le leader et deviendra un index standard. Vous ne pouvez pas redémarrer une réplication après l'avoir arrêtée.
Arrêtez la réplication à partir du domaine suiveur. Veillez à inclure un corps de requête vide :
```
POST _plugins/_replication/follower-01/_stop
{}
```
## Suivi automatique
Vous pouvez définir un ensemble de règles de réplication sur un domaine leader unique qui réplique automatiquement les index correspondant à un modèle spécifié. Lorsqu'un index du domaine leader correspond à l'un des modèles (par exemple,`books*`), un index suiveur correspondant est créé sur le domaine suiveur. OpenSearch Le service réplique tous les index existants qui correspondent au modèle, ainsi que les nouveaux index que vous créez. Il ne réplique pas les index qui existent déjà sur le domaine suiveur.
Pour répliquer tous les index (à l'exception des index créés par le système et ceux qui existent déjà sur le domaine suiveur), utilisez un modèle générique (`*`).
### Créer une règle de réplication.
Créez une règle de réplication sur le domaine suiveur et indiquez le nom de la connexion inter-clusters :
```
POST _plugins/_replication/_autofollow
{
"leader_alias" : "connection-alias",
"name": "rule-name",
"pattern": "books*",
"use_roles":{
"leader_cluster_role": "all_access",
"follower_cluster_role": "all_access"
}
}
```
Vous trouverez l'alias de connexion dans l'onglet **Connexions** du tableau de bord de votre domaine.
Cet exemple suppose qu'un administrateur émet la demande et utilise `all_access` en tant que rôles de domaine leader et suiveur pour plus de simplicité. Dans les environnements de production, cependant, nous vous recommandons de créer des utilisateurs de réplication à la fois sur les index leader et suiveur et de les mapper en conséquence. Les noms d'utilisateur doivent être identiques. Pour plus d'informations sur ces rôles et sur la façon de les mapper, voir [Mapper les rôles du cluster leader et suiveur](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles) dans la OpenSearch documentation.
Pour récupérer la liste des règles de réplication existantes sur un domaine, utilisez l'[opération d'API des statistiques de suivi automatique](https://docs.opensearch.org/latest/tuning-your-cluster/replication-plugin/api/#get-auto-follow-stats).
Pour tester la règle, créez un index correspondant au modèle sur le domaine leader :
```
PUT books-are-fun
```
Et vérifiez que son réplica s'affiche sur le domaine suiveur :
```
GET _cat/indices
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open books-are-fun ldfHO78xYYdxRMULuiTvSQ 1 1 0 0 208b 208b
```
### Supprimer une règle de réplication
Lorsque vous supprimez une règle de réplication, le OpenSearch service arrête de répliquer les *nouveaux* index correspondant au modèle, mais poursuit l'activité de réplication existante jusqu'à ce que vous [arrêtiez la réplication](#replication-stop) de ces index.
Supprimez les règles de réplication du domaine suiveur :
```
DELETE _plugins/_replication/_autofollow
{
"leader_alias" : "connection-alias",
"name": "rule-name"
}
```
## Mise à niveau des domaines connectés
Afin de mettre à niveau la version du moteur de deux domaines dotés d'une connexion entre clusters, mettez d'abord à niveau le domaine suiveur, puis le domaine leader. Ne supprimez pas la connexion entre eux, sinon la réplication s'interrompt et vous ne pourrez pas la reprendre.
# Migration des index Amazon OpenSearch Service à l'aide de la réindexation à distance
La réindexation à distance vous permet de copier des index d'un domaine Amazon OpenSearch Service vers un autre. Vous pouvez migrer des index depuis n'importe quel domaine de OpenSearch service ou depuis des clusters autogérés OpenSearch ou Elasticsearch.
Un domaine et un index *distants* font référence à la source des données, ou au domaine et à l'index à partir desquels vous souhaitez copier les données. Un domaine et un index *locaux* font référence à la cible des données, ou au domaine et à l'index vers lesquels vous souhaitez copier les données.
La réindexation à distance nécessite la OpenSearch version 1.0 ou ultérieure, ou Elasticsearch 6.7 ou version ultérieure, sur le domaine local. Le domaine distant doit présenter une version inférieure ou la même version majeure que le domaine local. Les versions d'Elasticsearch sont considérées comme *inférieures* aux OpenSearch versions, ce qui signifie que vous pouvez réindexer les données des domaines Elasticsearch vers des domaines. OpenSearch Dans la même version majeure, le domaine distant peut correspondre à n'importe quelle version mineure. Par exemple, la réindexation à distance d'Elasticsearch 7.10.x vers 7.9 est prise en charge, mais pas de la version OpenSearch 1.0 vers Elasticsearch 7.10.x.
**Note**
Cette documentation explique comment réindexer les données entre les domaines Amazon OpenSearch Service. Pour une documentation complète de l'`reindex`opération, y compris les étapes détaillées et les options prises en charge, voir le [document Reindex](https://docs.opensearch.org/latest/opensearch/reindex-data/) dans la OpenSearch documentation.
**Topics**
+ [Conditions préalables](#remote-reindex-prereq)
+ [Réindexer les données entre les domaines Internet OpenSearch du service](#remote-reindex-domain)
+ [Réindexer les données entre les domaines OpenSearch de service lorsque la télécommande se trouve dans un VPC](#remote-reindex-vpc)
+ [Réindexer les données entre les domaines non liés OpenSearch aux services](#remote-reindex-non-aos)
+ [Réindexer des jeux de données volumineux](#remote-reindex-largedatasets)
+ [Paramètres de réindexation à distance](#remote-reindex-settings)
## Conditions préalables
La réindexation à distance présente les exigences suivantes :
+ Le domaine distant doit être accessible à partir du domaine local. Pour un domaine distant résidant au sein d'un VPC, le domaine local doit avoir accès au VPC. Ce processus varie en fonction de la configuration du réseau, mais implique probablement la connexion à un VPN ou à un réseau géré, ou l'utilisation de la connexion de point de [terminaison VPC](#remote-reindex-vpc) native. Pour en savoir plus, veuillez consulter la section [Lancement de vos domaines Amazon OpenSearch Service au sein d'un VPC](vpc.md).
+ La demande doit être autorisée par le domaine distant comme toute autre demande REST. Si le contrôle d'accès détaillé est activé dans le domaine distant, vous devez être autorisé à effectuer une réindexation sur le domaine distant et à lire l'index sur le domaine local. Pour obtenir plus d’informations de sécurité, consultez [Contrôle d'accès précis dans Amazon Service OpenSearch](fgac.md).
+ Nous vous recommandons de créer un index avec le paramètre souhaité sur votre domaine local avant de lancer le processus de réindexation.
+ Si votre domaine utilise un type d'instance T2 ou T3 pour vos nœuds de données, vous ne pouvez pas utiliser la réindexation à distance.
## Réindexer les données entre les domaines Internet OpenSearch du service
Le scénario le plus simple est que l'index distant se trouve dans le même Région AWS que votre domaine local avec un point de terminaison accessible au public et que vous avez signé des informations d'identification IAM.
Dans le domaine distant, spécifiez l'index distant à partir duquel vous souhaitez réindexer et l'index local à réindexer :
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
Vous devez ajouter 443 à la fin du point de terminaison du domaine distant à des fins de vérification de validation.
Pour vérifier que l'index est copié sur le domaine local, envoyez cette demande au domaine local :
```
GET local_index/_search
```
Si l'index distant se trouve dans une région différente de votre domaine local, transmettez son nom de région, comme dans cet exemple de demande :
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"region": "eu-west-1"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
Dans le cas d'une région isolée comme une région AWS GovCloud (US) ou une région de Chine, le point de terminaison peut ne pas être accessible car votre utilisateur IAM n'est pas reconnu dans ces régions.
Si le domaine distant est sécurisé par une [authentification de base](fgac-http-auth.md), spécifiez le nom d'utilisateur et le mot de passe :
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"username": "username",
"password": "password"
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
## Réindexer les données entre les domaines OpenSearch de service lorsque la télécommande se trouve dans un VPC
Chaque domaine OpenSearch de service est constitué de sa propre infrastructure interne de cloud privé virtuel (VPC). Lorsque vous créez un nouveau domaine dans un OpenSearch Service VPC existant, une interface Elastic Network est créée pour chaque nœud de données du VPC.
Comme l'opération de réindexation à distance est effectuée à partir du domaine de OpenSearch service distant, et donc au sein de son propre VPC privé, vous devez disposer d'un moyen d'accéder au VPC du domaine local. Vous pouvez le faire soit en utilisant la fonctionnalité intégrée de connexion des points de terminaison VPC pour établir une connexion AWS PrivateLink, soit en configurant un proxy.
Si votre domaine local utilise OpenSearch la version 1.0 ou ultérieure, vous pouvez utiliser la console ou le AWS CLI pour créer une AWS PrivateLink connexion. Une AWS PrivateLink connexion permet aux ressources du VPC local de se connecter de manière privée aux ressources du VPC distant au sein de celui-ci. Région AWS
Pour créer une connexion de point de terminaison VPC, le domaine source à réindexer doit se trouver dans un VPC local, et les domaines source et de destination doivent être identiques. Région AWS
### Réindexez les données avec AWS Management Console
Vous pouvez utiliser la réindexation à distance avec la console pour copier des index entre deux domaines partageant une connexion de point de terminaison VPC.
1. Accédez à la console Amazon OpenSearch Service à l'adresse[https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).
1. Dans le volet de navigation de gauche, choisissez **Domaines**.
1. Sélectionnez le domaine local ou le domaine dans lequel vous souhaitez copier les données. Cette action ouvre la page des détails du domaine. Cliquez sur l'onglet **Connexions** sous les informations générales, puis sélectionnez **Demander**.
1. Sur la page **Demander une connexion**, sélectionnez **VPC Endpoint Connection** pour votre mode de connexion et entrez les autres informations pertinentes. Ces détails incluent le domaine distant, qui est le domaine à partir duquel vous souhaitez copier des données. Choisissez ensuite **Request** (Demander).
1. Accédez à la page de détails du domaine distant, choisissez l'onglet **Connexions** et recherchez le tableau des **connexions entrantes**. Sélectionnez la case à cocher située à côté du nom du domaine à partir duquel vous venez de créer la connexion (le domaine local). Choisissez **Approve** (Approuver).
1. Revenez au domaine local, choisissez l'onglet **Connections** (Connexions) et recherchez le tableau des **connexions sortantes**. Une fois la connexion entre les deux domaines active, un point de terminaison devient disponible dans la colonne **Endpoint** (Point de terminaison) du tableau. Copiez le point de terminaison.
1. Ouvrez le tableau de bord du domaine local et sélectionnez **Dev Tools** (Outils du développeur) dans le menu de navigation de gauche. Pour vérifier que l'index de domaine distant n'existe pas encore sur votre domaine local, exécutez la requête GET suivante. *remote-domain-index-name*Remplacez-le par votre propre nom d'index.
```
GET remote-domain-index-name/_search
{
"query":{
"match_all":{}
}
}
```
Dans le résultat, vous devriez voir une erreur indiquant que l'index n'a pas été trouvé.
1. Sous votre demande GET, créez une demande POST et utilisez votre point de terminaison comme hôte distant, comme suit.
```
POST _reindex
{
"source":{
"remote":{
"host":"connection-endpoint",
"username":"username",
"password":"password"
},
"index":"remote-domain-index-name"
},
"dest":{
"index":"local-domain-index-name"
}
}
```
Exécutez cette demande.
1. Exécutez à nouveau la demande GET. La sortie devrait maintenant indiquer que l'index local existe. Vous pouvez interroger cet index pour vérifier que toutes les données de l'index distant ont OpenSearch été copiées.
### Réindexer les données avec les opérations de l'API OpenSearch de service
Vous pouvez utiliser la réindexation à distance avec l'API pour copier des index entre deux domaines partageant une connexion de point de terminaison VPC.
1. Utilisez l'opération [CreateOutboundConnection](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_CreateOutboundConnection.html)API pour demander une nouvelle connexion entre votre domaine local et votre domaine distant.
```
POST https://es.region.amazonaws.com/2021-01-01/opensearch/cc/outboundConnection
{
"ConnectionAlias": "remote-reindex-example",
"ConnectionMode": "VPC_ENDPOINT",
"LocalDomainInfo": {
"AWSDomainInformation": {
"DomainName": "local-domain-name",
"OwnerId": "aws-account-id",
"Region": "region"
}
},
"RemoteDomainInfo": {
"AWSDomainInformation": {
"DomainName": "remote-domain-name",
"OwnerId": "aws-account-id",
"Region": "region"
}
}
}
```
Vous recevez un `ConnectionId` dans la réponse. Enregistrez cet identifiant pour l'utiliser à l'étape suivante.
1. Utilisez l'opération [AcceptInboundConnection](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_AcceptInboundConnection.html)API avec votre identifiant de connexion pour approuver la demande provenant du domaine local.
```
PUT https://es.region.amazonaws.com/2021-01-01/opensearch/cc/inboundConnection/ConnectionId/accept
```
1. Utilisez l'opération [DescribeOutboundConnections](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DescribeOutboundConnections.html)API pour récupérer le point de terminaison de votre domaine distant.
```
{
"Connections": [
{
"ConnectionAlias": "remote-reindex-example",
"ConnectionId": "connection-id",
"ConnectionMode": "VPC_ENDPOINT",
"ConnectionProperties": {
"Endpoint": "connection-endpoint"
},
...
}
]
}
```
Enregistrez le *connection-endpoint* pour l'utiliser à l'étape 5.
1. Pour vérifier que l'index de domaine distant n'existe pas encore sur votre domaine local, exécutez la requête GET suivante. *remote-domain-index-name*Remplacez-le par votre propre nom d'index.
```
GET local-domain-endpoint/remote-domain-index-name/_search
{
"query":{
"match_all":{}
}
}
```
Dans le résultat, vous devriez voir une erreur indiquant que l'index n'a pas été trouvé.
1. Créez une requête POST et utilisez votre point de terminaison comme hôte distant, comme suit.
```
POST local-domain-endpoint/_reindex
{
"source":{
"remote":{
"host":"connection-endpoint",
"username":"username",
"password":"password"
},
"index":"remote-domain-index-name"
},
"dest":{
"index":"local-domain-index-name"
}
}
```
Exécutez cette demande.
1. Exécutez à nouveau la demande GET. La sortie devrait maintenant indiquer que l'index local existe. Vous pouvez interroger cet index pour vérifier que toutes les données de l'index distant ont OpenSearch été copiées.
Si le domaine distant est hébergé dans un VPC et que vous ne souhaitez pas utiliser la fonctionnalité de connexion du point de terminaison du VPC, vous devez configurer un proxy avec un point de terminaison accessible au public. Dans ce cas, le OpenSearch service nécessite un point de terminaison public car il n'est pas en mesure d'envoyer du trafic vers votre VPC.
Lorsque vous exécutez un domaine en [mode VPC](vpc.md), un ou plusieurs points de terminaison sont placés dans votre VPC. Toutefois, ces points de terminaison ne sont destinés qu'au trafic entrant dans le domaine au sein du VPC, et ils n'autorisent pas le trafic à entrer dans le VPC lui-même.
La commande de réindexation à distance est exécutée depuis le domaine local, de sorte que le trafic d'origine ne peut pas utiliser ces points de terminaison pour accéder au domaine distant. C'est pourquoi un proxy est requis dans ce cas d'utilisation. Le domaine proxy doit disposer d'un certificat signé par une autorité de certification publique (CA). Les certificats auto-signés ou signés par une autorité de certification privée ne sont pas pris en charge.
## Réindexer les données entre les domaines non liés OpenSearch aux services
Si l'index distant est hébergé en dehors de OpenSearch Service, par exemple dans une instance EC2 autogérée, définissez le `external` paramètre sur : `true`
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"username": "username",
"password": "password",
"external": true
},
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
Dans ce cas, seule l'[authentification de base](fgac-http-auth.md) à l'aide d'un nom d'utilisateur et d'un mot de passe est prise en charge. Le domaine distant doit disposer d'un point de terminaison accessible au public (même s'il se trouve dans le même VPC que le domaine de OpenSearch service local) et d'un certificat signé par une autorité de certification publique. Les certificats autosignés ou signés par une autorité de certification privée ne sont pas pris en charge.
## Réindexer des jeux de données volumineux
La réindexation à distance envoie une demande de défilement au domaine distant avec les valeurs par défaut suivantes :
+ Contexte de recherche de 5 minutes
+ Délai d'attente de socket de 30 secondes
+ Taille de lot de 1 000
Nous vous recommandons de régler ces paramètres en fonction de vos données. Pour les documents volumineux, envisagez une taille de lot plus petite, un délai d'attente and/or plus long. Pour plus d'informations, voir [Paginer les résultats](https://docs.opensearch.org/docs/latest/search-plugins/searching-data/paginate/).
```
POST _reindex?pretty=true&scroll=10h&wait_for_completion=false
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443",
"socket_timeout": "60m"
},
"size": 100,
"index": "remote_index"
},
"dest": {
"index": "local_index"
}
}
```
Nous vous recommandons également d'ajouter les paramètres suivants à l'index local pour de meilleures performances :
```
PUT local_index
{
"settings": {
"refresh_interval": -1,
"number_of_replicas": 0
}
}
```
Une fois le processus de réindexation terminé, vous pouvez définir le nombre de réplicas souhaité et supprimer le paramètre d'intervalle d'actualisation.
Pour réindexer uniquement un sous-ensemble de documents sélectionnés par le biais d'une requête, envoyez cette demande au domaine local :
```
POST _reindex
{
"source": {
"remote": {
"host": "https://remote-domain-endpoint:443"
},
"index": "remote_index",
"query": {
"match": {
"field_name": "text"
}
}
},
"dest": {
"index": "local_index"
}
}
```
La réindexation à distance ne prend pas en charge le découpage et dès lors, vous ne pouvez pas effectuer plusieurs opérations de défilement pour la même demande en parallèle.
## Paramètres de réindexation à distance
Outre les options de réindexation standard, OpenSearch Service prend en charge les options suivantes :
| Options | Valeurs valides | Description | Obligatoire |
| --- | --- | --- | --- |
| Externe | Booléenne | Si le domaine distant n'est pas un domaine de OpenSearch service ou si vous effectuez une réindexation entre deux domaines VPC, spécifiez comme. true | Non |
| Région | String | Si le domaine distant se trouve dans une autre région, spécifiez le nom de la région. | Non |
# Gestion des séries chronologiques dans Amazon OpenSearch Service à l'aide de flux de données
Un flux de travail typique pour gérer les données en séries chronologiques comporte plusieurs étapes, telles que la création d'un alias d'index de substitution, la définition d'un index d'écriture et la définition de mappages et de paramètres communs pour les index de support.
Les flux de données dans Amazon OpenSearch Service permettent de simplifier ce processus de configuration initiale. Les flux de données sont prêts à l'emploi pour les données temporelles telles que les journaux d'application qui sont généralement de nature append-only.
Les flux de données nécessitent OpenSearch la version 1.0 ou ultérieure.
**Note**
Cette documentation fournit des étapes de base pour vous aider à démarrer avec les flux de données sur un domaine Amazon OpenSearch Service. Pour une documentation complète, consultez la section [Flux de données](https://docs.opensearch.org/latest/opensearch/data-streams/) dans la OpenSearch documentation.
## Premiers pas avec les flux de données
Un flux de données est composé en interne de plusieurs index de support. Les requêtes de recherche sont acheminées vers tous les index de support, tandis que les requêtes d'indexation sont acheminées vers le dernier index d'écriture.
### Étape 1 : Créer un modèle d'index
Pour créer un flux de données, vous devez d'abord créer un modèle d'index qui configure un ensemble d'index en tant que flux de données. L'objet `data_stream` indique qu'il s'agit d'un flux de données et non d'un modèle d'index ordinaire. Le modèle d'index correspond au nom du flux de données :
```
PUT _index_template/logs-template
{
"index_patterns": [
"my-data-stream",
"logs-*"
],
"data_stream": {},
"priority": 100
}
```
Dans ce cas, chaque document ingéré doit avoir un champ `@timestamp`. Vous pouvez également définir votre propre champ d'horodatage personnalisé comme une propriété de l'objet `data_stream` :
```
PUT _index_template/logs-template
{
"index_patterns": "my-data-stream",
"data_stream": {
"timestamp_field": {
"name": "request_time"
}
}
}
```
### Étape 2 : Création d'un flux de données
Après avoir créé un modèle d'index, vous pouvez directement commencer à ingérer des données sans créer de flux de données.
Comme nous avons un modèle d'index correspondant à un `data_stream` objet, le flux de données est OpenSearch automatiquement créé :
```
POST logs-staging/_doc
{
"message": "login attempt failed",
"@timestamp": "2013-03-01T00:00:00"
}
```
### Étape 3 : Ingestion des données dans le flux de données
Pour intégrer des données dans un flux de données, vous pouvez utiliser l'indexation APIs normale. Assurez-vous que chaque document que vous indexez possède un champ d'horodatage. Si vous essayez d'ingérer un document qui ne possède pas de champ d'horodatage, vous obtenez une erreur.
```
POST logs-redis/_doc
{
"message": "login attempt",
"@timestamp": "2013-03-01T00:00:00"
}
```
### Étape 4 : Recherche dans un flux de données
Vous pouvez effectuer une recherche dans un flux de données de la même manière que dans un index ordinaire ou un alias d'index. L'opération de recherche s'applique à tous les index de support (toutes les données présentes dans le flux).
```
GET logs-redis/_search
{
"query": {
"match": {
"message": "login"
}
}
}
```
### Étape 5 : Substitution d'un flux de données
Vous pouvez configurer une politique [ISM (Index State Management)](ism.md) afin d'automatiser le processus de substitution pour le flux de données. La politique ISM est appliquée aux index de support au moment de leur création. Lorsque vous associez une politique à un flux de données, elle n'affecte que les futurs index de support de ce flux de données. Vous n'avez pas non plus besoin de fournir le paramètre `rollover_alias`, car la politique ISM déduit cette information de l'index de support.
**Note**
Si vous migrez un index de sauvegarde vers un [stockage à froid](cold-storage.md), OpenSearch supprimez cet index du flux de données. Même si vous replacez l'index vers [UltraWarm](ultrawarm.md), il reste indépendant et ne fait pas partie du flux de données d'origine. Une fois qu'un index a été supprimé du flux de données, la recherche par rapport au flux ne renvoie aucune donnée de l'index.
**Avertissement**
L'index d'écriture d'un flux de données ne peut pas être migré vers un stockage à froid. Si vous souhaitez migrer les données de votre flux de données vers un stockage à froid, vous devez transférer le flux de données avant la migration.
### Étape 6 : Gérer les flux de données dans les OpenSearch tableaux de bord
Pour gérer les flux de données à partir de OpenSearch tableaux de bord, ouvrez les **OpenSearchtableaux** de bord, choisissez **Gestion des index**, sélectionnez **Indices ou Indices** **gérés par des politiques**.
### Étape 7 : Suppression d'un flux de données
L'opération de suppression supprime d'abord les index de support d'un flux de données, puis supprime le flux de données lui-même.
Pour supprimer un flux de données et tous ses index de support cachés :
```
DELETE _data_stream/name_of_data_stream
```