Utilisation de Neptune Streams pour la réplication entre régions pour la reprise après sinistre - Amazon Neptune

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.

Utilisation de Neptune Streams pour la réplication entre régions pour la reprise après sinistre

Neptune propose deux méthodes de mise en œuvre des fonctionnalités de basculement entre régions :

  • Copie et restauration d'instantanés entre régions

  • Utilisation des flux Neptune pour répliquer les données entre deux clusters dans deux régions différentes.

La copie et la restauration de snapshots entre régions présentent les coûts opérationnels les plus faibles pour la restauration d'un cluster Neptune dans une région différente. Cependant, la copie d'un instantané entre les régions peut nécessiter un temps de transfert de données important, car un instantané est une sauvegarde complète du cluster Neptune. Par conséquent, la copie et la restauration d'instantanés entre régions peuvent être utilisées pour des scénarios qui ne nécessitent qu'un objectif de point de récupération (RPO) de quelques heures et un objectif de temps de récupération (RTO) de quelques heures.

Un objectif de point de récupération (RPO) est mesuré par le temps écoulé entre les sauvegardes. Il définit la quantité de données qui peut être perdue entre le moment où la dernière sauvegarde a été effectuée et le moment où la base de données est restaurée.

Un objectif de temps de récupération (RTO) est mesuré par le temps nécessaire pour effectuer une opération de récupération. Il s'agit du temps nécessaire au cluster de bases de données pour basculer vers une base de données restaurée après une défaillance.

Les flux Neptune permettent de garder un cluster Neptune de sauvegarde synchronisé avec le cluster de production principal à tout moment. En cas de défaillance, votre base de données bascule vers le cluster de sauvegarde. Cela réduit le RPO et le RTO à quelques minutes, car les données sont constamment copiées sur le cluster de sauvegarde, qui est immédiatement disponible en tant que cible de basculement à tout moment.

L'inconvénient d'utiliser les flux Neptune de cette manière est que la surcharge opérationnelle requise pour maintenir les composants de réplication et le coût d'avoir un second cluster de bases de données Neptune en ligne en permanence peuvent être importants.

Configuration de la réplication Neptune-à-Neptune

Votre cluster de base de données de production principal réside dans un VPC d'une région source donnée. Il y a trois éléments principaux que vous devez répliquer ou émuler dans une autre région de reprise d'activité à des fins de reprise après sinistre :

  • Les données stockées dans le cluster.

  • Configuration du cluster principal. Cela inclut s'il utilise l'authentification IAM, s'il est crypté, ses paramètres de cluster de bases de données, ses paramètres d'instance, la taille des instances, etc.).

  • La topologie de mise en réseau qu'il utilise, y compris le VPC cible, ses groupes de sécurité, etc.

Vous pouvez utiliser les API de gestion Neptune telles que les suivantes pour recueillir ces informations :

Avec les informations que vous collectez, vous pouvez utiliser la procédure suivante pour configurer un cluster de sauvegarde dans une autre région, vers lequel votre cluster de production peut basculer en cas de panne.

1 : Activation de Streams Neptune

Vous pouvez utiliser le pluginModifyDBClusterParameterGrouppour définir leneptune_streamsparamètre à 1. Ensuite, redémarrez toutes les instances du cluster de bases de données pour que la modification prenne effet.

Il est conseillé d'effectuer au moins une opération d'ajout ou de mise à jour sur le cluster de bases de données source après l'activation des flux Neptune. Cela remplit le flux de modifications avec des points de données qui peuvent être référencés ultérieurement lors de la resynchronisation du cluster de production avec le cluster de sauvegarde.

2: Créez un nouveau VPC dans la région où vous souhaitez configurer votre cluster de sauvegarde.

Avant de créer un nouveau cluster de bases de données Neptune dans une région différente de celle de votre cluster principal, vous devez établir un nouveau VPC dans la région cible pour héberger le cluster. La connectivité entre les clusters principal et de sauvegarde est établie via l'appairage de VPC, qui utilise le trafic sur les sous-réseaux privés de différents VPC. Toutefois, pour établir l'appairage de VPC entre deux VPC, ceux-ci ne doivent pas comporter de blocs d'adresse IP ou d'espaces d'adresses IP qui se chevauchent. Cela signifie que vous ne pouvez pas simplement utiliser le VPC par défaut dans les deux régions, car le bloc d'adresse CIDR pour un VPC par défaut est toujours le même (172.31.0.0/16).

Vous pouvez utiliser un VPC existant dans la région cible, à condition qu'il respecte les conditions suivantes :

  • Il ne possède pas de bloc d'adresse CIDR qui chevauche celui du VPC où se trouve votre cluster principal.

  • Il n'est pas déjà appairé à un autre VPC qui possède le même bloc d'adresse CIDR que le VPC où se trouve votre cluster principal.

Si aucun VPC approprié n'est disponible dans la région cible, créez-en un à l'aide d'Amazon EC2CreateVpcAPI.

3: Créez un instantané de votre cluster principal, puis restaurez-le dans la région de sauvegarde cible.

Vous créez maintenant un nouveau cluster Neptune dans un VPC approprié dans la région de sauvegarde cible qui est une copie de votre cluster de production :

Faites une copie de votre cluster de production dans la région de sauvegarde

  1. Dans votre région de sauvegarde cible, recréez les paramètres et les groupes de paramètres utilisés par votre cluster de bases de données de production. Pour ce faire, vous pouvez utiliser :CreateDBClusterParameterGroup,CreateDBParameterGroup,ModifyDBClusterParameterGroupetModifyDBParameterGroup.

    Notez queCopyDBClusterParameterGroupetCopyDBParameterGroupLes API ne prennent pas en charge la copie entre régions.

  2. UtiliserCreateDBClusterSnapshotpour créer un instantané de votre cluster de production dans le VPC de votre région de production.

  3. UtiliserCopyDBClusterSnapshotpour copier le snapshot sur le VPC de votre région de sauvegarde cible.

  4. UtiliserRestoreDBClusterFromSnapshotpour créer un nouveau cluster de bases de données dans le VPC de votre région de sauvegarde cible à l'aide du snapshot copié. Utilisez les paramètres de configuration et les paramètres que vous avez copiés à partir de votre cluster de production principal.

  5. Le nouveau cluster Neptune existe désormais, mais il ne contient aucune instance. UtiliserCreateDBInstancepour créer une nouvelle instance principale/scripteur ayant le même type et la même taille d'instance que l'instance d'écriture de votre cluster de production. Il n'est pas nécessaire de créer des réplicas en lecture supplémentaires à ce stade, sauf si votre instance de sauvegarde sera utilisée pour traiter les E/S en lecture dans la région cible avant un basculement.

4 : Établissez l'appairage de VPC entre le VPC de votre cluster principal et le VPC de votre nouveau cluster de sauvegarde

En configurant l'appairage de VPC, vous permettez au VPC de votre cluster principal de communiquer avec le VPC de votre cluster de sauvegarde comme s'il s'agissait d'un seul réseau privé. Pour cela, effectuez les opérations suivantes :

  1. À partir du VPC de votre cluster de production, appelez leCreateVpcPeeringConnectionAPI pour établir la connexion d'appairage.

  2. À partir du VPC de votre cluster de sauvegarde cible, appelez leAcceptVpcPeeringConnectionAPI pour accepter la connexion d'appairage.

  3. À partir du VPC de votre cluster de production, utilisez leCreateRouteAPI pour ajouter une route à la table de routage du VPC qui redirige tout le trafic vers le bloc d'adresse CIDR du VPC cible afin qu'il utilise la liste de préfixes d'appairage de VPC.

  4. De même, à partir du VPC de votre cluster de sauvegarde cible, utilisez leCreateRouteAPI permettant d'ajouter une route à la table de routage du VPC qui achemine le trafic vers le VPC du cluster principal.

5 : Configuration de l'infrastructure de réplication des flux Neptune

Maintenant que les deux clusters sont déployés et que la communication réseau entre les deux régions est établie, utilisez leNeptune-à-NeptuneAWS CloudFormationmodèlepour déployer la fonction Lambda consommateur Neptune Streams avec l'infrastructure supplémentaire qui prend en charge la réplication des données. Effectuez cette opération dans le VPC de votre cluster de production principal.

Les paramètres que vous devrez fournir pour celaAWS CloudFormationstack sont :

  • NeptuneStreamEndpoint— Point de terminaison du flux pour le cluster principal, au format URL. Par exemple :https://(cluster name):8182/pg/stream.

  • QueryEngine— Ce doit être ougremlin,sparql, ouopenCypher.

  • RouteTableIds— Vous permet d'ajouter des routes pour un point de terminaison de VPC DynamoDB et un point de terminaison de VPC de surveillance.

    Deux paramètres supplémentaires, à savoir :CreateMonitoringEndpointetCreateDynamoDBEndpoint, doivent également être définis sur true s'ils n'existent pas déjà sur le VPC du cluster principal. S'ils existent déjà, assurez-vous qu'ils sont définis sur false ou que l'optionAWS CloudFormationla création va échouer.

  • SecurityGroupIds— Spécifie le groupe de sécurité utilisé par le consommateur Lambda pour communiquer avec le point de terminaison de flux Neptune du cluster principal.

    Dans le cluster de sauvegarde cible, attachez un groupe de sécurité qui autorise le trafic provenant de ce groupe de sécurité.

  • SubnetIds: liste d'ID de sous-réseau dans le VPC du cluster principal qui peut être utilisée par le consommateur Lambda pour communiquer avec le cluster principal.

  • TargetNeptuneClusterEndpoint— Point de terminaison du cluster (nom d'hôte uniquement) du cluster de sauvegarde cible.

  • TargetAWSRegion— Le cluster de sauvegarde cibleAWSrégion, telle queus-east-1). Vous devez fournir ce paramètre uniquement lorsque le paramètreAWSrégion du cluster de sauvegarde cible est différente de la région du cluster source Neptune, comme dans le cas de la réplication entre régions. Si les régions source et cible sont identiques, ce paramètre est facultatif.

    Remarque :TargetAWSRegionvalue n'est pas unvalideAWSrégion prise en charge par Neptune, le processus échoue.

  • VPC— ID du VPC du cluster principal.

Tous les autres paramètres peuvent être conservés avec leurs valeurs par défaut.

Une fois leAWS CloudFormationa été déployé, Neptune commencera à répliquer toutes les modifications du cluster principal vers le cluster de sauvegarde. Vous pouvez surveiller cette réplication dans le CloudWatch journaux générés par la fonction consommateur Lambda.

Autres considérations

  • Si vous avez besoin d'utiliser l'authentification IAM entre le cluster principal et le cluster de sauvegarde, vous pouvez également la configurer lorsque vous appelez leAWS CloudFormationTemplate.

  • Si le chiffrement au repos est activé sur votre cluster principal, réfléchissez à la manière de gérer les clés KMS associées lors de la copie de l'instantané dans la région cible et associez une nouvelle clé KMS dans la région cible.

  • Une bonne pratique consiste à utiliser les CNAME DNS devant les points de terminaison Neptune utilisés dans vos applications. Ensuite, si vous devez effectuer un basculement manuel vers le cluster de sauvegarde cible, ces CNAME peuvent être modifiés pour pointer vers le cluster cible et/ou les points de terminaison d'instance.