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 à l'aide des mêmes API ou les utiliser pour créer des visualisations dans les OpenSearch tableaux de bord.

Prérequis

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.

• 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é 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 le k-NN approximatif ("index.knn": true), vous ne pouvez pas le déplacer vers le stockage à chaud.

• Si le domaine utilise un contrôle d'accès précis, 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.

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

2. Choisissez Create action group (Créer un groupe d'actions) et configurez les groupes suivants :

   Nom du groupe	Autorisations
   ultrawarm_cluster	cluster:admin/ultrawarm/migration/list cluster:monitor/nodes/stats
   ultrawarm_index_read	indices:admin/ultrawarm/migration/get indices:admin/get
   ultrawarm_index_write	indices:admin/ultrawarm/migration/warm indices:admin/ultrawarm/migration/hot indices:monitor/stats indices:admin/ultrawarm/migration/cancel

3. Choisissez Roles (Rôles), puis Create role (Créer un rôle).

4. Nommez le rôle ultrawarm_manager.

5. Pour Cluster permissions (Autorisations de cluster), sélectionnez ultrawarm_cluster etcluster_monitor.

6. Pour Index, saisissez *.

7. Pour Index permissions (Autorisations d'index), sélectionnez ultrawarm_index_read, ultrawarm_index_write et indices_monitor.

8. Choisissez Créer.

9. Après avoir créé le rôle, associez-le à 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 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 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 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 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 plus d’informations, consultez Tarification d'Amazon OpenSearch Service.

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 UltraWarm les nœuds de données 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. 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é utilisées. Pour plus d’informations, consultez Multi-AZ avec mode veille.

Vous pouvez également utiliser l'API de configuration AWS CLIor pour activer UltraWarm, en particulierWarmEnabled, les WarmType optionsWarmCount, et dansClusterConfig.

Note

Les domaines prennent en charge un nombre maximum de nœuds à chaud. Pour plus d'informations, consultez Quotas Amazon OpenSearch Service.

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.

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

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

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 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 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/<repo>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/<repo>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 les délais d'expiration.

2. 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 et réindexez-le.

3. 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 etrename_replacement. Pour obtenir un résumé des options de restauration des OpenSearch instantanés, consultez la OpenSearch documentation.

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, veuillez consulter Migration des index vers le stockage à froid.

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 UltraWarm les nœuds de données, puis sélectionnez 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 tous les index chauds, soit les migrer à nouveau vers le stockage à chaud. Une fois le stockage à chaud vide, attendez cinq minutes avant de tenter de le désactiver UltraWarm.