Migrer vos charges de travail Redis et Valkey vers Memorystore pour Valkey

Aperçu

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Memorystore est compatible avec la migration automatisée de vos charges de travail Redis et Valkey autogérées vers Memorystore pour Valkey. Cette fonctionnalité vous permet de passer facilement de la charge opérationnelle de la gestion de votre propre infrastructure. En migrant vers un environnement entièrement géré dans Memorystore pour Valkey, vous n'avez plus besoin de corriger manuellement l'OS, de configurer la réplication ni d'utiliser des scripts de sauvegarde personnalisés. Vous bénéficiez également de fonctionnalités de basculement automatique et de sécurité native au VPC, et vous pouvez évoluer vers des centaines de nœuds avec un temps d'arrêt quasi nul.

En migrant vos charges de travail autogérées vers Memorystore for Valkey, vous bénéficiez des avantages suivants, qui éliminent les tâches opérationnelles répétitives et modernisent votre infrastructure de base de données :

• Éliminez vos frais généraux opérationnels : déléguez les tâches manuelles et chronophages à Google Cloud, comme l'application de correctifs à l'OS, la surveillance de l'infrastructure, les scripts de sauvegarde et la gestion de la réplication. Vous pouvez ainsi vous concentrer sur le développement d'applications plutôt que sur la maintenance de la base de données.
• Bénéficiez d'une haute disponibilité de niveau Enterprise : profitez d'un contrat de niveau de service entièrement géré de 99,99 %. Memorystore pour Valkey fournit un basculement automatique, ainsi que des fonctionnalités de sauvegarde et de restauration intégrées. Cela protège vos applications contre les défaillances de nœuds inattendues et assure une reprise après sinistre rapide.
• Faites évoluer votre infrastructure avec un temps d'arrêt quasi nul : augmentez ou diminuez le nombre de vos instances pour faire face aux pics de trafic imprévisibles de manière dynamique. Vous pouvez passer à des centaines de nœuds (jusqu'à 250 partitions) de manière fluide sans mettre vos applications hors connexion.
• Renforcez votre sécurité : remplacez les règles réseau complexes configurées manuellement par une connectivité VPC sécurisée et des contrôles des accès précis basés sur Identity and Access Management (IAM). Cela garantit que les limites de sécurité strictes deGoogle Cloudprotègent vos données.
• Consolidez et migrez vos instances : fusionnez facilement vos instances dispersées, cloisonnées et autogérées en un seul déploiement hautes performances dans Memorystore for Valkey. Lors de cette migration, vous pouvez également mettre à niveau automatiquement vos versions obsolètes de Redis ou Valkey vers les dernières versions compatibles.
• Débloquez l'analyse avancée en temps réel et l'IA générative : passez à un environnement optimisé qui offre des latences de l'ordre de la microseconde pour la mise en cache et la gestion des sessions. Pour alimenter vos applications d'IA générative, vous bénéficiez d'un accès immédiat et géré à des fonctionnalités avancées comme la recherche vectorielle.

Compatibilité avec les versions

Le tableau de cette section liste les informations suivantes sur vos instances Redis et Valkey sources autogérées, ainsi que sur les instances cibles dans Memorystore pour Valkey :

• Types et versions des instances sources compatibles avec la migration
• Versions des instances Memorystore for Valkey cibles vers lesquelles vous pouvez migrer vos charges de travail

Type d'instance source	Version de l'instance source	Version de l'instance cible
Redis	3.2.x à 7.2.x	Valkey 7.2, 8.0 et 9.0
Valkey	7.x, 8.x et 9.x	Valkey 7.2, 8.0 et 9.0

Important : La version de l'instance cible doit être identique ou ultérieure à celle de l'instance source. Vous ne pouvez pas rétrograder l'instance cible vers une version antérieure.

Avant de commencer

Avant de commencer à migrer vos charges de travail, remplissez les conditions préalables décrites dans cette section.

Utiliser la console Google Cloud , la Google Cloud CLI et les API

Pour utiliser la console Google Cloud , la gcloud CLI et les API, procédez comme suit :

1. Dans la console Google Cloud , sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud .

   Accéder au sélecteur de projet

2. Assurez-vous que la facturation est activée pour votre projet. Découvrez comment vérifier si la facturation est activée sur un projet.

3. Installez et initialisez la Google Cloud CLI.

   Remarque : Si vous avez déjà installé la gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant gcloud components update. Vous devez disposer au moins de la version 489.0.0 de gcloud CLI pour accéder aux commandes gcloud CLI de Memorystore pour Valkey.

4. Activez l'API Memorystore pour Valkey.
   API Memorystore pour Valkey
5. Activez l'API Network Connectivity.
   API Network Connectivity
6. Activez l'API Service Consumer Management.
   API Service Consumer Management
7. Activez l'API Compute Engine.
   API Compute Engine

Attribuer des rôles et des autorisations

Pour effectuer toutes les opérations de migration des charges de travail de vos instances Redis et Valkey autogérées vers Memorystore pour Valkey, demandez à votre administrateur de vous accorder le rôle IAM Administrateur Memorystore (roles/memorystore.admin) sur votre projetGoogle Cloud .

Pour créer et afficher des rattachements de réseau, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de réseaux Compute (roles/compute.networkAdmin) sur votre projet.

Workflow pour migrer vos charges de travail

Pour migrer les charges de travail de vos instances Redis et Valkey autogérées vers Memorystore pour Valkey, procédez comme suit :

1. Préparez votre instance source : configurez votre instance Redis ou Valkey autogérée pour autoriser les connexions sécurisées et la réplication sortante vers Memorystore pour Valkey.
2. Préparez l'instance cible : déterminez les spécifications requises pour votre instance, telles que le nombre de partitions et le type de nœud.
3. Créez l'instance cible : provisionnez l'instance Memorystore for Valkey qui recevra vos données migrées.
4. Configurer un rattachement de réseau : configurez un rattachement de réseau. Ce rattachement permet à l'instance cible du réseau VPC producteur d'établir des connexions à l'instance source qui s'exécute dans le réseau VPC consommateur. La réplication est donc établie.
5. Démarrer la migration : lancez le processus de synchronisation. L'instance cible se connecte automatiquement à votre instance source et commence à répliquer vos données en tant qu'instance répliquée en lecture seule de manière continue.
6. Surveillez la migration : vérifiez qu'elle se déroule sans problème et que son état est SAIN.
7. Terminez la migration : transférez le trafic de votre application vers l'instance cible.

Préparer votre instance source

Vous devez préparer votre instance Redis ou Valkey autogérée pour pouvoir migrer vos charges de travail vers une instance Memorystore pour Valkey cible.

Pour autoriser les connexions des nœuds de l'instance cible à ceux de l'instance source, procédez comme suit :

• Si le mode protégé est activé sur les nœuds sources, désactivez-le.
• Si vous avez configuré les nœuds sources avec une directive bind explicite, mettez à jour les nœuds pour autoriser les connexions entrantes depuis les nœuds cibles. Les nœuds cibles initient les connexions à partir des adresses IP du sous-réseau de l'association réseau.
• Mettez à jour les règles de pare-feu qui pourraient bloquer les connexions entrantes depuis les nœuds cibles.
• Si l'authentification et le protocole TLS (Transport Layer Security) sont activés sur les nœuds sources, désactivez-les.

Pour permettre l'établissement de la réplication à partir des nœuds de l'instance cible vers les nœuds de l'instance source, procédez comme suit :

• Ne renommez aucune commande Valkey ni Redis requise pour la migration ou la modification des données (par exemple, PING, PSYNC et HSET).
• Assurez-vous que l'instance source dispose de suffisamment de mémoire et de capacité de processeur pour gérer la charge de réplication supplémentaire provenant des nœuds de l'instance cible.

Important : Notez l'adresse IP et le numéro de port de l'instance source. Vous aurez besoin de ces informations pour lancer le processus de migration.

De plus, Memorystore pour Valkey doit pouvoir communiquer avec cette adresse IP et ce port tout au long du processus de migration. Memorystore pour Valkey utilise l'adresse IP et le port pour découvrir automatiquement les autres nœuds de la topologie de l'instance.

Préparer l'instance cible

Pour que la réplication se déroule sans problème, vous devez dimensionner correctement votre instance Memorystore pour Valkey cible afin qu'elle puisse gérer la charge de travail entrante de votre instance source. Pour ce faire, vous devez déterminer les spécifications exactes de votre instance cible. Ces spécifications incluent la compatibilité avec l'instance source, le type de mode de cluster, le nombre de bases de données, le nombre de partitions, la version et le type de nœud de l'instance cible.

Pour préparer l'instance cible, suivez les consignes suivantes :

• Compatibilité avec l'instance source : les instances source et cible doivent résider dans le même projet et la même région.
• Mode cluster : le mode cluster de l'instance cible doit correspondre à celui de l'instance source. Si l'instance source est en mode cluster désactivé, l'instance cible doit également être en mode cluster désactivé. Sinon, l'instance cible doit être en mode cluster activé.
• Nombre de bases de données : si le mode cluster est désactivé sur l'instance cible, le nombre de bases de données logiques sur l'instance doit être supérieur ou égal au nombre de bases de données sur l'instance source.
• Nombre de partitions : si le mode cluster est activé sur l'instance cible, le nombre de partitions sur l'instance cible doit être identique à celui de l'instance source. Toutefois, le nombre de répliques sur les instances source et cible peut être différent.
• Version de l'instance : la version de l'instance cible doit être compatible avec celle de l'instance source. Pour en savoir plus, consultez Compatibilité avec les versions.
• Version de maintenance : la version de maintenance de l'instance cible doit être MEMORYSTORE_20260313_01_00 ou ultérieure. Pour en savoir plus, consultez À propos de la maintenance.
• Type de nœud : le type de nœud de l'instance cible doit être suffisamment grand pour gérer les données qu'il reçoit des nœuds de l'instance source. Pour en savoir plus sur les types de nœuds que vous pouvez sélectionner pour l'instance cible et sur la capacité d'espace de clés correspondante pour chaque type de nœud, consultez Spécifications des types de nœuds.

Important : Vous ne pouvez pas utiliser d'instances de réplication multirégionale comme instances cibles. Vérifiez également que Memorystore pour Valkey ne bloque aucune des commandes que vous utilisez dans l'instance source.

Créer l'instance cible

Si vous ne disposez pas d'instance cible répondant aux exigences pour recevoir les données migrées depuis l'instance source, vous devez créer l'instance.

Vous pouvez créer cette instance à l'aide de la console Google Cloud ou de la gcloud CLI.

Important : Avant de créer l'instance cible, assurez-vous de consulter les consignes de la section Préparer l'instance cible.

Console

Pour créer l'instance cible, consultez Créer des instances.

gcloud

Pour créer l'instance cible, consultez Créer des instances.

Configurer un rattachement de réseau

Pour migrer les charges de travail d'une instance source vers une instance cible, les nœuds de l'instance cible doivent établir une connexion avec les nœuds de l'instance source. Les données de l'instance source peuvent ainsi être répliquées dans l'instance cible.

Pour que cette connexion et cette réplication aient lieu, vous devez utiliser un rattachement de réseau. Les tentatives de connexion à partir des nœuds cibles proviennent du sous-réseau du réseau VPC de l'instance source qui est associé au rattachement réseau.

Vous pouvez utiliser une pièce jointe réseau qui répond aux exigences suivantes :

• Elle doit se trouver dans le même projet et la même région que l'instance cible.
• Son sous-réseau doit se trouver dans le même réseau VPC que l'instance source.
• Le sous-réseau de l'instance source doit disposer d'une plage CIDR d'adresses IP adéquate, compatible avec au moins N+1 adresses IP utilisables (où N correspond au nombre de nœuds de l'instance cible). Par exemple, si une instance cible comporte trois shards et un réplica, elle comporte six nœuds : trois nœuds pour l'instance principale et trois nœuds pour le réplica. Vous avez donc besoin d'au moins sept adresses IP.
• La plage de sous-réseaux ne peut pas chevaucher 10.0.0.0/23, car cette plage est réservée à Memorystore pour Valkey.

Si votre rattachement de réseau ne répond pas à ces exigences ou si vous n'en avez pas, vous devez en créer un.

Lancer la migration

En lançant la migration, l'instance cible établit une réplication avec l'instance source. Toutes les données écrites dans l'instance source sont automatiquement répliquées dans l'instance cible. L'instance cible devient une réplique en lecture de l'instance source.

Vous pouvez lancer la migration à l'aide de la console Google Cloud ou de la gcloud CLI.

Important : Avant de commencer la migration, veillez à consulter les consignes de la section Configurer une pièce jointe réseau. De plus, une fois la migration lancée, n'effectuez aucune opération de migration d'emplacement sur l'instance source tant que vous n'avez pas terminé la migration.

Console

1. Dans la console Google Cloud , accédez à la page Memorystore pour Valkey.

   Memorystore for Valkey

2. Cliquez sur l'ID de l'instance cible.

3. Sur la page Instance en un coup d'œil, cliquez sur Lancer la migration.

4. Dans la fenêtre Migrer des instances Redis et Valkey autogérées, procédez comme suit :

5. Dans l'onglet Préparer, lisez les informations sur les conditions préalables pour l'instance source et les consignes pour l'association réseau. Cliquez ensuite sur Continuer.

6. Dans l'onglet Connect (Connecter), procédez comme suit :

   1. Saisissez l'adresse IP et le port de l'instance source. Vous avez noté ces informations dans Préparer votre instance source.
   2. Sélectionnez le stockage réseau que vous souhaitez utiliser pour migrer les données.
   3. Cliquez sur Continuer.

7. Dans l'onglet Examiner, vérifiez les informations associées au processus de migration. Ces informations incluent l'ID de l'instance cible, l'adresse IP et le port de l'instance source, ainsi que le nom de l'association réseau. Après avoir vérifié ces informations, cliquez sur Lancer la migration.

8. Sur la page Instance en un coup d'œil, vérifiez que l'état Migration en cours s'affiche.

Si les nœuds de l'instance cible ne peuvent pas se connecter à ceux de l'instance source ou si les données de l'instance source ne peuvent pas être répliquées dans l'instance cible, la migration échoue.

Dans ce cas, Memorystore for Valkey rétablit l'état de l'instance cible tel qu'il était avant le début du processus de migration. L'état de l'instance cible revient à Prêt, et l'instance retrouve ses capacités de lecture et d'écriture.

Une fois les problèmes de migration résolus, vous pouvez relancer la migration.

gcloud

Pour lancer la migration, utilisez la commande gcloud beta memorystore instances start-migration.

gcloud beta memorystore instances start-migration INSTANCE_ID \
--project=PROJECT_ID \
--location=REGION \
--source-ip=SOURCE_IP_ADDRESS \
--source-port=SOURCE_PORT \
--network-attachment=projects/NETWORK_ATTACHMENT_PROJECT_ID/locations/NETWORK_ATTACHMENT_REGION/networkAttachments/NETWORK_ATTACHMENT_ID

Effectuez les remplacements suivants :

• INSTANCE_ID : ID de l'instance cible.
• PROJECT_ID : ID ou numéro de projet du Google Cloud projet contenant l'instance cible.
• REGION : région dans laquelle se trouve l'instance cible.
• SOURCE_IP_ADDRESS : adresse IP de l'instance source. Vous avez noté cette adresse IP dans Préparer votre instance source.
• SOURCE_PORT : numéro de port de l'instance source. Vous avez noté ce port dans Préparer votre instance source.
• NETWORK_ATTACHMENT_PROJECT_ID : ID ou numéro du projetGoogle Cloud contenant le rattachement de réseau que vous souhaitez utiliser pour migrer les données.
• NETWORK_ATTACHMENT_REGION : région où se trouve le rattachement de réseau.
• NETWORK_ATTACHMENT_ID : ID du rattachement de réseau.

Pour vérifier que la migration a bien démarré, utilisez la commande gcloud memorystore instances describe.

gcloud memorystore instances describe INSTANCE_ID \
--project=PROJECT_ID \
--location=REGION_ID

Vérifiez qu'un état MIGRATING s'affiche à côté du paramètre state.

Si les nœuds de l'instance cible ne peuvent pas se connecter à ceux de l'instance source ou si les données de l'instance source ne peuvent pas être répliquées dans l'instance cible, la migration échoue.

Dans ce cas, Memorystore for Valkey rétablit l'état de l'instance cible tel qu'il était avant le début du processus de migration. L'état de l'instance cible revient à ACTIVE, et l'instance retrouve ses capacités de lecture et d'écriture.

Une fois les problèmes de migration résolus, vous pouvez relancer la migration.

Surveiller la migration

Pour vous assurer que la migration se déroule sans problème, vous pouvez la surveiller sur les instances source et de destination.

Surveiller l'instance source

Sur l'instance source, vérifiez que l'utilisation du tampon de sortie du client reste faible sur les nœuds sources. Une utilisation faible et continue indique un décalage minimal et une synchronisation réussie des données de l'instance source vers l'instance cible.

Surveiller l'instance cible

Pour chaque nœud principal de l'instance cible, vérifiez que l'état de la métrique État de la migration des nœuds est défini sur SAIN. Cet état indique que les liens de réplication entre les shards des instances source et cible sont opérationnels et actifs.

Vous pouvez surveiller la migration de l'instance cible à l'aide de la consoleGoogle Cloud . Pour vérifier la valeur de la métrique État de la migration des nœuds pour chaque nœud principal de l'instance cible, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page Explorateur de métriques.

   Explorateur de métriques

2. Dans le menu Métriques, sélectionnez la métrique État de la migration des nœuds. Pour ce faire, sélectionnez Nœud d'instance Memorystore > Instance > État de la migration du nœud, puis cliquez sur Appliquer.

3. Dans le champ Filtre, ajoutez les filtres suivants :

   • instance_id = (equals) INSTANCE_ID
   • role = (equals) primary
   • status != (does not equal) HEALTHY

   Remplacez INSTANCE_ID par l'ID de l'instance cible.

   En ajoutant ces filtres, vous pouvez surveiller les nœuds principaux de l'instance cible pour voir si des nœuds ne sont pas en bon état. Si aucun nœud ne s'affiche, cela signifie qu'ils sont tous opérationnels et que vous pouvez terminer la migration.

Terminer la migration

Lorsque vous êtes prêt à transférer le trafic de votre application vers l'instance cible, terminez la migration. Les nœuds de l'instance cible ne sont alors plus répliqués avec ceux de l'instance source. L'instance cible autorise toutes les opérations de lecture et d'écriture.

Vous pouvez terminer la migration à l'aide de la console Google Cloud ou de la gcloud CLI.

Important : Par défaut, Memorystore for Valkey s'assure que l'instance cible est entièrement synchronisée avec l'instance source jusqu'à la fin de la migration. Toute écriture dans l'instance source après la fin de la migration peut ne pas être répliquée.

Si vous souhaitez une cohérence totale des données entre les instances source et cible, et aucune perte de données, arrêtez toutes les opérations d'écriture sur l'instance source avant de terminer la migration.

Console

1. Dans la console Google Cloud , accédez à la page Memorystore pour Valkey.

   Memorystore for Valkey

2. Cliquez sur l'ID de l'instance cible.

3. Sur la page Instance en un coup d'œil, cliquez sur Terminer la migration.

4. Dans la boîte de dialogue Terminer la migration, procédez comme suit :

   1. Si vous souhaitez vous assurer que toutes les données de l'instance source sont répliquées sur l'instance cible, sélectionnez Standard.

      Attention : Si vous souhaitez transférer immédiatement le trafic de votre application vers la nouvelle instance cible, sélectionnez Forcer (ignorer la synchronisation). Toutefois, si vous faites ce choix, il est possible que Memorystore pour Valkey ne puisse pas répliquer toutes les données de l'instance source dans l'instance cible.

   2. Dans le champ de texte ID d'instance, saisissez l'ID de l'instance cible.

   3. Cliquez sur Terminer la migration.

5. Sur la page Instance en un coup d'œil, vérifiez que l'état Migrée s'affiche.

Important : Une fois la migration terminée, mettez à jour les fichiers de configuration de votre application pour rediriger tout le trafic vers l'instance cible.

gcloud

Pour terminer la migration, utilisez la commande gcloud beta memorystore instances finish-migration.

gcloud beta memorystore instances finish-migration INSTANCE_ID \
--project=PROJECT_ID \
--location=REGION

Effectuez les remplacements suivants :

• INSTANCE_ID : ID de l'instance cible
• PROJECT_ID : ID ou numéro de projet du Google Cloud projet contenant l'instance cible.
• REGION : région où se trouve l'instance cible

Attention : Si vous souhaitez transférer immédiatement le trafic de votre application vers la nouvelle instance cible, utilisez le paramètre --force. Toutefois, en utilisant ce paramètre, il est possible que Memorystore pour Valkey ne puisse pas répliquer toutes les données de l'instance source dans l'instance cible.

Pour vérifier que la migration s'est bien déroulée, utilisez la commande gcloud memorystore instances describe.

gcloud memorystore instances describe INSTANCE_ID \
--project=PROJECT_ID \
--location=REGION_ID

Vérifiez qu'un état MIGRATED s'affiche à côté du paramètre state.

Important : Une fois la migration terminée, mettez à jour les fichiers de configuration de votre application pour rediriger tout le trafic vers l'instance cible.