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

Créer une politique ISM

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, et éventuellement vers stockage à froid. 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": "<your timestamp field>"
            }
          }
        ],
        "transitions": [{
          "state_name": "delete",
          "conditions": {
             "min_index_age": "365d"
          }
        }]
      },
      {
        "name": "delete",
        "actions": [{
          "notification": {
            "destination": {
              "chime": {
                "url": "<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 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 .

{
  "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": "<my-repository>",
            "snapshot": "<my-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.

Différences

Par rapport à OpenSearch Elasticsearch, ISM for Amazon OpenSearch Service présente plusieurs différences.

Opérations ISM

Opérations ISM de stockage à froid

Pour les index cold, vous devez indiquer un paramètre ?type=_cold lorsque vous utilisez les API ISM suivantes :

Ces API pour les index à froid présentent les différences supplémentaires suivantes :

Paramètres ISM

OpenSearch et Elasticsearch vous permettent de modifier tous les paramètres ISM disponibles à l'aide de l'_cluster/settingsAPI. Sur Amazon OpenSearch Service, vous ne pouvez modifier que les paramètres ISM suivants :