Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stockage à 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 UltraWarmstockage, 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).

Prérequis

Les prérequis suivants s'appliquent au stockage à froid :

Configurer des 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, 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 :

Stockage à froid : exigences et considérations relatives aux performances

Comme le stockage à froid utilise Amazon S3, il n'entraîne aucune des surcharges liées au stockage à chaud, telles que 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'ColdStorageSpaceUtilizationindicateur 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.

Activation du stockage à froid

La console est le moyen le plus simple de créer un domaine qui utilise le stockage à froid. Lors de la création du domaine, choisissez Enable cold storage (Activer le stockage à froid). Le même processus s'applique aux domaines existants, à condition de satisfaire les prérequis. 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 ou de l'API de configuration.

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.

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 manuel Amazon OpenSearch Service API Reference.

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.

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.

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 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) 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, qui montre comment migrer automatiquement les index d'un stockage à chaud vers un stockage UltraWarm à froid.

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"
    }
  ]
}

Le 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 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 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.

Suppression d'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, sousColdStorageOptions, 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.