Mise à niveau des domaines Amazon OpenSearch Service

Note

OpenSearch et les mises à niveau des versions d'Elasticsearch diffèrent des mises à jour du logiciel de service. Pour plus d'informations sur la mise à jour du logiciel de OpenSearch service pour votre domaine de service, consultezMises à jour du logiciel de service dans Amazon OpenSearch Service.

Amazon OpenSearch Service propose des mises à niveau sur place pour les domaines qui exécutent la OpenSearch version 1.0 ou ultérieure, ou Elasticsearch 5.1 ou version ultérieure. Si vous utilisez des services tels qu'Amazon Data Firehose ou Amazon CloudWatch Logs pour diffuser des données vers OpenSearch Service, vérifiez que ces services prennent en charge la nouvelle version de OpenSearch avant de procéder à la migration.

Chemins de mise à niveau pris en charge

Actuellement, le OpenSearch service prend en charge les chemins de mise à niveau suivants :

De la version	Vers la version
OpenSearch 1.3 ou 2. x	OpenSearch 2. x La version 2.3 comporte les modifications majeures suivantes : Le type paramètre a été supprimé de tous les points de terminaison de OpenSearch l'API dans la version 2.0. Pour plus d'informations, veuillez consulter la rubrique Modifications majeures (langue française non garantie). Si votre domaine contient des index (chauds ou froids) créés à l'origine dans Elasticsearch 6.8, ces index ne sont pas compatibles avec la version 2.3. UltraWarm OpenSearch Avant de passer à la version 2.3, vous devez réindexer les index incompatibles. Pour les index incompatibles UltraWarm ou froids, migrez-les vers un stockage à chaud, réindexez les données, puis migrez-les vers un stockage à chaud ou à froid. Vous pouvez également supprimer les index si vous n'en avez plus besoin. Si vous mettez accidentellement à niveau votre domaine vers la version 2.3 sans effectuer ces étapes au préalable, vous ne pourrez pas migrer les index incompatibles hors de leur niveau de stockage actuel. Votre seule option est de les supprimer.
OpenSearch 1. x	OpenSearch 1. x
Elasticsearch 7.x	Elasticsearch 7. x ou OpenSearch 1. x Important OpenSearch 1. x introduit de nombreux changements décisifs. Pour plus de détails, consultez Changement de nom d'Amazon OpenSearch Service : résumé des modifications.
Elasticsearch 6.8	Elasticsearch 7. x ou OpenSearch 1. x Important Elasticsearch 7.0 et OpenSearch 1.0 incluent de nombreuses modifications majeures. Avant de lancer une mise à niveau sur place, nous vous recommandons de prendre un instantané manuel du 6. domaine x, en le restaurant lors d'un test 7. x ou OpenSearch 1. domaine x, et utilisation de ce domaine de test pour identifier les problèmes de mise à niveau potentiels. Pour les principales modifications apportées à la OpenSearch version 1.0, voirChangement de nom d'Amazon OpenSearch Service : résumé des modifications. Comme Elasticsearch 6.x, les index ne peuvent contenir qu'un seul type de mappage, mais celui-ci doit désormais être nommé _doc. Par conséquent, certaines API n'ont plus besoin d'un type de mappage dans le corps de la demande (comme l'API _bulk). Pour les nouveaux index, auto-hébergez Elasticsearch 7. x et OpenSearch 1. x ont un nombre de partitions par défaut de un. OpenSearch Domaines de service sur Elasticsearch 7. x et conservez ultérieurement la valeur par défaut précédente de cinq.
Elasticsearch 6.x	Elasticsearch 6.x
Elasticsearch 5.6	Elasticsearch 6.x Important Les index créés dans la version 6.x ne prennent plus en charge plusieurs types de mappages. Les index créés dans la version 5.x prennent toujours en charge plusieurs types de mappages lors de leur restauration dans un cluster 6.x. Vérifiez que votre code client ne crée qu'un seul type de mappage par index. Pour minimiser les temps d'arrêt lors de la mise à niveau d'Elasticsearch 5.6 vers la version 6. x, OpenSearch Service réindexe l'.kibanaindex, le supprime .kibana-6.kibana, crée un alias nommé .kibana et mappe le nouvel index avec le nouvel alias.
Elasticsearch 5.x	Elasticsearch 5.x

Le processus de mise à niveau comporte trois étapes :

1. Contrôles préalables à la mise à niveau : le OpenSearch service recherche les problèmes susceptibles de bloquer une mise à niveau et ne passe à l'étape suivante que si ces vérifications aboutissent.

2. Instantané : le OpenSearch service prend un instantané du cluster Elasticsearch OpenSearch ou du cluster Elasticsearch et ne passe à l'étape suivante que si le cliché aboutit. Si la mise à niveau échoue, le OpenSearch service utilise cet instantané pour restaurer le cluster dans son état d'origine. Pour plus d’informations, consultez Impossible de revenir à une version plus ancienne après la mise à niveau.

3. Mise à niveau : le OpenSearch service lance la mise à niveau, qui peut prendre de 15 minutes à plusieurs heures. OpenSearch Les tableaux de bord peuvent être indisponibles pendant une partie ou la totalité de la mise à niveau.

Démarrage d'une mise à niveau (console)

Le processus de mise à niveau est irréversible et ne peut pas être suspendu ou annulé. Au cours d'une mise à niveau, vous ne pouvez pas apporter de modifications à la configuration du domaine. Avant de commencer une mise à niveau, assurez-vous de vouloir poursuivre. Vous pouvez utiliser ces mêmes étapes pour effectuer la vérification avant la mise à niveau, sans réellement démarrer de mise à niveau.

Si le cluster possède des nœuds maîtres dédiés, les OpenSearch mises à niveau sont effectuées sans interruption de service. Sinon, le cluster peut ne pas répondre pendant plusieurs secondes après la mise à niveau pendant qu'il choisit un nœud maître.

Pour mettre à niveau un domaine vers une version ultérieure d' OpenSearch Elasticsearch

1. Prenez un instantané manuel de votre domaine. Cet instantané sert de sauvegarde que vous pouvez restaurer sur un nouveau domaine si vous souhaitez revenir à la OpenSearch version précédente.

2. Accédez à https://aws.amazon.com et choisissez Se connecter à la console.

3. Sous Analytics, sélectionnez Amazon OpenSearch Service.

4. Dans le volet de navigation, sous Domains (Domaines), choisissez le domaine que vous voulez mettre à jour.

5. Choisissez Actions et Upgrade (Mise à niveau).

6. Choisissez la version cible de la mise à niveau. Si vous effectuez une mise à niveau vers une OpenSearch version, l'option Activer le mode de compatibilité apparaît. Si vous activez ce paramètre, il OpenSearch indique que sa version est 7.10 pour permettre aux clients et aux plug-ins Elasticsearch OSS tels que Logstash de continuer à fonctionner avec Amazon Service. OpenSearch Vous pouvez désactiver cette configuration plus tard

7. Choisissez Upgrade (Mise à niveau).

8. Vérifiez le Statut sur le tableau de bord du domaine pour surveiller le statut de la mise à niveau.

Démarrage d'une mise à niveau (CLI)

Vous pouvez utiliser les opérations suivantes pour identifier la bonne version d' OpenSearch Elasticsearch pour votre domaine, démarrer une mise à niveau sur place, effectuer la vérification préalable à la mise à niveau et suivre la progression :

• get-compatible-versions (GetCompatibleVersions)

• upgrade-domain (UpgradeDomain)

• get-upgrade-status (GetUpgradeStatus)

• get-upgrade-history (GetUpgradeHistory)

Pour plus d'informations, consultez la référence des commandesAWS CLI et la référence OpenSearch de l'API Amazon Service.

Démarrage d'une mise à niveau (SDK)

Cet exemple utilise le client Python de OpenSearchServicebas niveau du AWS SDK for Python (Boto) pour vérifier si un domaine est éligible à la mise à niveau vers une version spécifique, le met à niveau et vérifie en permanence l'état de la mise à niveau.

import boto3
from botocore.config import Config
import time

# Build the client using the default credential configuration.
# You can use the CLI and run 'aws configure' to set access key, secret
# key, and default Region.

DOMAIN_NAME = ''  # The name of the domain to upgrade
TARGET_VERSION = ''  # The version you want to upgrade the domain to. For example, OpenSearch_1.1

my_config = Config(
    # Optionally lets you specify a Region other than your default.
    region_name='us-east-1'
)
client = boto3.client('opensearch', config=my_config)


def check_versions():
    """Determine whether domain is eligible for upgrade"""
    response = client.get_compatible_versions(
        DomainName=DOMAIN_NAME
    )
    compatible_versions = response['CompatibleVersions']
    for i in range(len(compatible_versions)):
        if TARGET_VERSION in compatible_versions[i]["TargetVersions"]:
            print('Domain is eligible for upgrade to ' + TARGET_VERSION)
            upgrade_domain()
            print(response)
        else:
            print('Domain not eligible for upgrade to ' + TARGET_VERSION)


def upgrade_domain():
    """Upgrades the domain"""
    response = client.upgrade_domain(
        DomainName=DOMAIN_NAME,
        TargetVersion=TARGET_VERSION
    )
    print('Upgrading domain to ' + TARGET_VERSION + '...' + response)
    time.sleep(5)
    wait_for_upgrade()


def wait_for_upgrade():
    """Get the status of the upgrade"""
    response = client.get_upgrade_status(
        DomainName=DOMAIN_NAME
    )
    if (response['UpgradeStep']) == 'UPGRADE' and (response['StepStatus']) == 'SUCCEEDED':
        print('Domain successfully upgraded to ' + TARGET_VERSION)
    elif (response['StepStatus']) == 'FAILED':
        print('Upgrade failed. Please try again.')
    elif (response['StepStatus']) == 'SUCCEEDED_WITH_ISSUES':
        print('Upgrade succeeded with issues')
    elif (response['StepStatus']) == 'IN_PROGRESS':
        time.sleep(30)
        wait_for_upgrade()


def main():
    check_versions()


if __name__ == "__main__":
    main()

Résolution des problèmes liés aux échecs de validation

Lorsque vous lancez une mise à niveau de version OpenSearch ou d'Elasticsearch, le OpenSearch Service effectue d'abord une série de contrôles de validation pour s'assurer que votre domaine est éligible à une mise à niveau. Si l'un de ces contrôles échoue, vous recevez une notification contenant les problèmes spécifiques que vous devez résoudre avant de mettre à niveau votre domaine. Pour obtenir la liste des problèmes potentiels et les étapes à suivre pour les résoudre, consultez Résolution des erreurs de validation.

Dépannage d'une mise à niveau

Les mises à niveau sur place requièrent des domaines sains. Votre domaine peut être inéligible pour une mise à niveau ou peut échouer à effectuer une mise à niveau pour une multitude de raisons. Le tableau suivant indique les problèmes les plus courants.

Problème	Description
Plug-in optionnel non pris en charge	Lorsque vous mettez à niveau un domaine avec des plugins optionnels, le OpenSearch Service met également automatiquement à jour les plugins. Par conséquent, la version cible de votre domaine doit également prendre en charge ces plugins facultatifs. Si le domaine possède un plug-in optionnel qui n'est pas disponible pour la version cible, la demande de mise à niveau échoue.
Trop de partitions par nœud	OpenSearch, ainsi que 7. x versions d'Elasticsearch ont un paramètre par défaut de 1 000 partitions maximum par nœud. Si un nœud de votre cluster actuel dépasse ce paramètre, le OpenSearch service ne vous autorise pas à effectuer la mise à niveau. Consultez Limite maximale de partitions dépassée pour les options de dépannage.
Domaine en cours de traitement	Un changement de configuration est actuellement en cours pour le domaine. Une fois l'opération terminée, vérifiez l'éligibilité pour la mise à niveau.
Statut de cluster rouge	Un ou plusieurs index dans le cluster sont rouges. Pour obtenir les étapes de dépannage, consultez Statut de cluster rouge.
Taux d'erreur élevé	Le cluster renvoie un grand nombre d'erreurs 5xx lors de sa tentative de traitement des demandes. Ce problème est généralement dû à un trop grand nombre de demandes simultanées de lecture ou d'écriture. Envisagez de réduire le trafic vers le cluster ou de redimensionner votre domaine.
Split-Brain	Split-Brain signifie que votre cluster possède plusieurs nœuds principaux et s'est scindé en deux clusters qui ne refusionneront jamais d'eux-mêmes. Vous pouvez éviter le problème Split-Brain en utilisant le nombre recommandé de nœuds principaux dédiés. Pour obtenir de l'aide afin de résoudre le problème Split-Brain, contactez AWS Support.
Nœud principal introuvable	OpenSearch Le service ne trouve pas le nœud principal du cluster. Si votre domaine utilise multi-AZ, il se peut qu'un échec de zones de disponibilité ait entraîné la perte du quorum par le cluster, empêchant ainsi ce dernier de choisir un nouveau nœud principal. Si le problème ne se résout pas automatiquement, contactez AWS Support.
Trop de tâches en attente	Le nœud principal est soumis à une charge importante et a de nombreuses tâches en attente. Envisagez de réduire le trafic vers le cluster ou de redimensionner votre domaine.
Volume de stockage défaillant	Le volume de disque d'un ou plusieurs nœuds ne fonctionne pas correctement. Ce problème se produit souvent parallèlement à d'autres problèmes, comme un taux d'erreur élevé ou un trop grand nombre de tâches en attente. Si ce problème est isolé et ne se résout pas automatiquement, contactez AWS Support.
Problème lié à la clé KMS	La clé KMS utilisée pour chiffrer le domaine est inaccessible ou manquante. Pour plus d'informations, consultez Surveillance des domaines qui chiffrent les données au repos.
Instantané en cours	Le domaine prend actuellement un instantané. Une fois l'instantané pris, vérifiez l'éligibilité pour la mise à niveau. Vérifiez également que vous pouvez lister les référentiels d'instantanés manuels, lister les instantanés dans ces référentiels et prendre des instantanés manuels. Si le OpenSearch service n'est pas en mesure de vérifier si un instantané est en cours, les mises à niveau peuvent échouer.
Délai d'expiration ou échec de l'instantané	La création de l'instantané avant la mise à niveau a été trop longue ou a échoué. Vérifiez l'état du cluster et réessayez. Si le problème persiste, contactez AWS Support.
Index incompatibles	Une ou plusieurs index sont incompatibles avec la version cible. Ce problème peut se produire si vous avez migré les index depuis une ancienne version d' OpenSearch Elasticsearch. Réindexez les index et réessayez.
Utilisation du disque élevée	L'utilisation du disque pour le cluster est supérieure à 90 %. Supprimez des données ou redimensionnez le domaine, puis réessayez.
Utilisation JVM élevée	La sollicitation de mémoire JVM est supérieure à 75 %. Réduisez le trafic vers le cluster ou redimensionnez le domaine, puis réessayez.
OpenSearch Problème d'alias des tableaux de bord	.dashboardsest déjà configuré en tant qu'alias et correspond à un index incompatible, probablement issu d'une version antérieure de OpenSearch Dashboards. Réindexez et réessayez.
Statut de Dashboards rouge	OpenSearch L'état du tableau de bord est rouge. Essayez d'utiliser Dashboards une fois la mise à niveau terminée. Si le statut rouge persiste, résolvez-le manuellement, puis réessayez.
Compatibilité inter-clusters	Vous pouvez uniquement effectuer la mise à niveau si, après cette dernière, la compatibilité inter-clusters est maintenue entre les domaines source et destination. Au cours du processus de mise à niveau, toutes les connexions incompatibles sont identifiées. Ensuite, mettez à niveau le domaine distant ou supprimez les connexions incompatibles. Notez que si la réplication est active sur le domaine, vous ne pouvez pas la reprendre une fois la connexion supprimée.
Autre problème de OpenSearch service	Des problèmes liés OpenSearch au service lui-même peuvent entraîner l'affichage de votre domaine comme non éligible à une mise à niveau. Si aucune des conditions précédentes ne s'applique à votre domaine et que le problème persiste pendant plus d'une journée, contactez AWS Support.

Utilisation d'un instantané pour migrer des données

Les mises à niveau sur place constituent le moyen le plus simple, le plus rapide et le plus fiable de mettre à niveau un domaine vers une version ultérieure OpenSearch ou vers une version d'Elasticsearch. Les instantanés sont une bonne option si vous devez effectuer une migration à partir d'une version d'Elasticsearch antérieure à 5.1 ou que vous voulez migrer vers un tout nouveau cluster.

Le tableau suivant indique comment utiliser des instantanés pour migrer des données vers un domaine qui utilise une version différente OpenSearch ou une version d'Elasticsearch. Pour plus d'informations sur la prise d'instantanés et leur restauration, consultez Création d'instantanés d'index dans Amazon Service OpenSearch .

De la version	Vers la version	Processus de migration
OpenSearch 1.3 ou 2. x	OpenSearch 2. x	Passez en revue les principales modifications apportées à la version OpenSearch 2.3 pour voir si vous devez apporter des modifications à vos index ou à vos applications. Créez un instantané manuel de la version 1.3 ou 2. domaine x. Créez un 2. domaine x dont la version est supérieure à celle de votre version 1.3 ou 2 d'origine. domaine x. Restaurez l'instantané du domaine d'origine vers le 2. domaine x. Au cours de l'opération, il se peut que vous deviez restaurer votre .opensearch index sous un nouveau nom : POST _snapshot/<repository-name>/<snapshot-name>/_restore { "indices": "*", "ignore_unavailable": true, "rename_pattern": ".opensearch", "rename_replacement": ".backup-opensearch" } Ensuite, vous pouvez réindexer .backup-opensearch sur le nouveau domaine et lui donner l'alias .opensearch. Notez que l'appel _restore REST n'inclut pas include_global_state car la valeur par défaut _restore est false. Par conséquent, le domaine de test n'inclura aucun modèle d'index et ne disposera pas de l'état complet de la sauvegarde. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
OpenSearch 1. x	OpenSearch 1. x	Créez un instantané manuel du 1. domaine x. Créez un 1. x domaine dont la version est supérieure à votre 1 d'origine. domaine x. Restaurez l'instantané du domaine d'origine vers le nouveau 1. domaine x. Au cours de l'opération, il se peut que vous deviez restaurer votre .opensearch index sous un nouveau nom : POST _snapshot/<repository-name>/<snapshot-name>/_restore { "indices": "*", "ignore_unavailable": true, "rename_pattern": ".opensearch", "rename_replacement": ".backup-opensearch" } Ensuite, vous pouvez réindexer .backup-opensearch sur le nouveau domaine et lui donner l'alias .opensearch. Notez que l'appel _restore REST n'inclut pas include_global_state car la valeur par défaut _restore est false. Par conséquent, le domaine de test n'inclura aucun modèle d'index et ne disposera pas de l'état complet de la sauvegarde. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 6.x ou 7.x	OpenSearch 1. x	Passez en revue les principales modifications apportées à la OpenSearch version 1.0 pour voir si vous devez apporter des modifications à vos index ou à vos applications. Créez un instantané manuel de votre domaine Elasticsearch 7.x ou 6.x Créez un OpenSearch 1. domaine x. Restaurez le snapshot du domaine Elasticsearch vers le OpenSearch domaine. Au cours de l'opération, il se peut que vous deviez restaurer votre .elasticsearch index sous un nouveau nom : POST _snapshot/<repository-name>/<snapshot-name>/_restore { "indices": "*", "ignore_unavailable": true, "rename_pattern": ".elasticsearch", "rename_replacement": ".backup-opensearch" } Ensuite, vous pouvez réindexer .backup-opensearch sur le nouveau domaine et lui donner l'alias .elasticsearch. Notez que l'appel _restore REST n'inclut pas include_global_state car la valeur par défaut _restore est false. Par conséquent, le domaine de test n'inclura aucun modèle d'index et ne disposera pas de l'état complet de la sauvegarde. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 6.x	Elasticsearch 7.x	Examinez les modifications importantes de la version 7.0 pour savoir si vous devez faire des modifications aux index ou aux applications. Créez un instantané manuel du domaine 6.x. Créez un domaine 7.x. Restaurez l'instantané du domaine d'origine vers le domaine 7.x. Au cours de l'opération, vous devrez probablement restaurer l'index .opensearch sous un nouveau nom : POST _snapshot/<repository-name>/<snapshot-name>/_restore { "indices": "*", "ignore_unavailable": true, "rename_pattern": ".elasticsearch", "rename_replacement": ".backup-elasticsearch" } Ensuite, vous pouvez réindexer .backup-elasticsearch sur le nouveau domaine et lui donner l'alias .elasticsearch. Notez que l'appel _restore REST n'inclut pas include_global_state car la valeur par défaut _restore est false. Par conséquent, le domaine de test n'inclura aucun modèle d'index et ne disposera pas de l'état complet de la sauvegarde. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 6.x	Elasticsearch 6.8	Créez un instantané manuel du domaine 6.x. Créez un domaine 6.8. Restaurez l'instantané du domaine d'origine vers le domaine 6.8. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 5.x	Elasticsearch 6.x	Passez en revue les modifications importantes pour la version 6.0 afin de voir si vous devez apporter des modifications à vos index ou à vos applications. Créez un instantané manuel du domaine 5.x. Créez un domaine 6.x. Restaurez l'instantané du domaine d'origine vers le domaine 6.x. Si vous n'avez plus besoin de votre domaine 5x, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 5.x	Elasticsearch 5.6	Créez un instantané manuel du domaine 5.x. Créez un domaine 5.6. Restaurez l'instantané du domaine d'origine vers le domaine 5.6. Si vous n'avez plus besoin de votre domaine d'origine, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 2.3	Elasticsearch 6.x	Les instantanés Elasticsearch 2.3 ne sont pas compatibles avec la version 6.x. Pour migrer les données directement de la version 2.3 vers la version 6.x, vous devez recréer manuellement les index dans le nouveau domaine. Vous pouvez également suivre les étapes pour migrer de la version 2.3 vers la version 5.x dans ce tableau, effectuer des opérations _reindex dans le nouveau domaine 5.x pour convertir les index 2.3 en index 5.x, puis suivre les étapes pour migrer de la version 5.x vers la version 6.x.
Elasticsearch 2.3	Elasticsearch 5.x	Examinez les modifications importantes de la version 5.0 pour savoir si vous devez faire des modifications aux index ou aux applications. Créez un instantané manuel du domaine 2.3. Créez un domaine 5.x. Restaurez l'instantané du domaine 2.3 vers le domaine 5x. Si vous n'avez plus besoin de votre domaine 2.3, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.
Elasticsearch 1.5	Elasticsearch 5.x	Les instantanés Elasticsearch 1.5 ne sont pas compatibles avec la version 5.x. Pour migrer vos données de la version 1.5 vers la version 5.x, vous devez recréer manuellement les index dans le nouveau domaine. Important Les instantanés 1.5 sont compatibles avec 2.3, mais les domaines OpenSearch Service 2.3 ne prennent pas en charge cette _reindex opération. Comme vous ne pouvez pas les réindexer, les index issus d'un domaine 1.5 ne peuvent toujours pas être restaurés depuis des instantanés 2.3 vers des domaines 5.x.
Elasticsearch 1.5	Elasticsearch 2.3	Utilisez le plugin de migration pour déterminer si vous pouvez directement passer à la version 2.3. Vous aurez peut-être besoin d'apporter des modifications à vos données avant de procéder à la migration. Dans un navigateur web, ouvrez http://domain-endpoint/_plugin/migration/. Choisissez Run checks now (Exécuter les vérifications maintenant). Vérifiez les résultats et, si nécessaire, suivez les instructions pour apporter des modifications à vos données. Créez un instantané manuel du domaine 1.5. Créez un domaine 2.3. Restaurez l'instantané du domaine 1.5 vers le domaine 2.3. Si vous n'avez plus besoin de votre domaine 1.5, supprimez-le. Sinon, vous continuez à payer des frais pour le domaine.