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.

Clonage entre VPC avec Amazon Aurora

Supposons que vous souhaitiez imposer des contrôles d’accès réseau différents au cluster d’origine et au clone. Par exemple, vous pouvez utiliser le clonage pour créer une copie d’un cluster Aurora de production dans un autre VPC à des fins de développement et de test. Vous pouvez également créer un clone dans le cadre d’une migration de sous-réseaux publics vers des sous-réseaux privés, afin d’améliorer la sécurité de votre base de données.

Les sections suivantes montrent comment configurer la configuration réseau du clone afin que le cluster d'origine et le clone puissent accéder aux mêmes nœuds de stockage Aurora, même à partir de sous-réseaux différents ou différents VPCs. La vérification préalable des ressources du réseau permet d’éviter des erreurs difficiles à diagnostiquer lors du clonage.

Si vous ne connaissez pas la façon dont Aurora interagit avec les sous-réseaux et VPCs les groupes de sous-réseaux de base de données, consultez d'abord. Amazon VPC et Amazon Aurora Vous pouvez suivre les didacticiels de cette section pour créer ce type de ressources dans la AWS console et comprendre comment elles s'intègrent.

Comme les étapes impliquent de basculer entre les services RDS et EC2, les exemples utilisent des commandes AWS CLI pour vous aider à comprendre comment automatiser ces opérations et enregistrer le résultat.

Avant de commencer

Avant de commencer à configurer un clone entre VPC, assurez-vous d’avoir les ressources suivantes :

Collecte d’informations sur l’environnement réseau

Avec le clonage entre VPC, l’environnement réseau peut être très différent entre le cluster d’origine et son clone. Avant de créer le clone, collectez et enregistrez des informations sur le VPC, les sous-réseaux, le groupe de sous-réseaux de base de données et les informations AZs utilisées dans le cluster d'origine. De cette façon, vous minimiserez les risques de problèmes. En cas de problème réseau, vous n’aurez pas à interrompre les activités de dépannage pour rechercher des informations de diagnostic. Les sections suivantes présentent des exemples permettant de recueillir ce type d’informations à l’aide de la CLI. Vous pouvez enregistrer ces informations dans le format qui vous convient le mieux lors de la création du clone et de la résolution des problèmes.

Étape 1 : vérifier les zones de disponibilité du cluster d’origine

Avant de créer le clone, vérifiez celui que AZs le cluster d'origine utilise pour son stockage. Comme expliqué dans la Stockage Amazon Aurora section, le stockage de chaque cluster Aurora est associé à exactement trois AZs. Dans la mesure où Clusters de bases de données Amazon Aurora tire parti de la séparation du calcul et du stockage, cette règle s’applique quel que soit le nombre d’instances présentes dans le cluster.

Par exemple, exécutez une commande d’interface de ligne de commande comme dans cet exemple, en remplaçant my_cluster par le nom de votre propre cluster. L’exemple suivant génère une liste de zones de disponibilité triée par ordre alphabétique.

aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

L’exemple suivant montre un exemple de sortie de la commande describe-db-clusters précédente. Cela montre que le stockage du cluster Aurora en utilise toujours trois AZs.

us-east-1c
us-east-1d
us-east-1e

Pour créer un clone dans un environnement réseau ne disposant pas de toutes les ressources nécessaires pour s'y connecter AZs, vous devez créer des sous-réseaux associés à au moins deux d'entre eux AZs, puis créer un groupe de sous-réseaux de base de données contenant ces deux ou trois sous-réseaux. Les exemples suivants montrent comment procéder.

Étape 2 : vérifier le groupe de sous-réseaux de base de données du cluster d’origine

Si vous souhaitez utiliser le même nombre de sous-réseaux pour le clone que dans le cluster d’origine, vous pouvez obtenir le nombre de sous-réseaux à partir du groupe de sous-réseaux de base de données du cluster d’origine. Un groupe de sous-réseaux de base de données Aurora contient au moins deux sous-réseaux, chacun étant associé à une zone de disponibilité différente. Notez à quels AZs sous-réseaux sont associés.

L'exemple suivant montre comment rechercher le groupe de sous-réseaux de base de données du cluster d'origine, puis revenir au groupe correspondant. AZs Remplacez my_cluster par le nom de votre cluster dans la première commande. Remplacez my_subnet par le nom du groupe de sous-réseaux de base de données dans la deuxième commande.

aws rds describe-db-clusters --db-cluster-identifier my_cluster \
  --query '*[].DBSubnetGroup' --output text

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text

L’exemple de sortie peut ressembler à ce qui suit, pour un cluster avec un groupe de sous-réseaux de base de données contenant deux sous-réseaux. Dans ce cas, two-subnets est un nom qui a été spécifié lors de la création du groupe de sous-réseaux de base de données.

two-subnets

us-east-1d
us-east-1c

Pour un cluster où le groupe de sous-réseaux de base de données contient trois sous-réseaux, la sortie peut ressembler à ce qui suit.

three-subnets

us-east-1f
us-east-1d
us-east-1c

Étape 3 : vérifier les sous-réseaux du cluster d’origine

Si vous avez besoin de plus de détails sur les sous-réseaux du cluster d'origine, exécutez des commandes AWS CLI similaires aux suivantes. Vous pouvez examiner les attributs des sous-réseaux tels que les plages d’adresses IP, le propriétaire, etc. Vous pouvez ainsi déterminer s’il convient d’utiliser différents sous-réseaux dans le même VPC ou de créer des sous-réseaux présentant des caractéristiques similaires dans un VPC différent.

Trouvez le sous-réseau IDs de tous les sous-réseaux disponibles dans votre VPC.

aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

Identifiez les sous-réseaux exacts utilisés dans votre groupe de sous-réseaux de base de données.

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

Spécifiez ensuite les sous-réseaux que vous souhaitez examiner dans une liste, comme dans la commande suivante. Remplacez my_subnet_1 et ainsi de suite par le nom de vos sous-réseaux.

aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

L’exemple suivant montre une sortie partielle de ce type de commande describe-subnets. La sortie montre certains des attributs importants que vous pouvez voir pour chaque sous-réseau, tels que la zone de disponibilité associée et le VPC dont il fait partie.

{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

Étape 4 : vérifier les zones de disponibilité des instances de base de données dans le cluster d’origine

Vous pouvez utiliser cette procédure pour comprendre l' AZs utilisation des instances de base de données dans le cluster d'origine. De cette façon, vous pouvez configurer exactement la même chose AZs pour les instances de base de données du clone. Vous pouvez également utiliser plus ou moins d’instances de base de données dans le clone selon que le clone sera utilisé pour la production, le développement et les tests, etc.

Pour chaque instance du cluster d’origine, exécutez une commande comme la suivante. Assurez-vous d’abord que l’instance a terminé de se créer et que son état indique Available. Remplacez my_instance par l’identifiant de l’instance.

aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

L’exemple suivant illustre la sortie de l’exécution de la commande describe-db-instances précédente. Le cluster Aurora possède quatre instances de base de données. Par conséquent, nous exécutons la commande quatre fois, en indiquant à chaque fois un identifiant d’instance de base de données différent. La sortie montre comment ces instances de base de données sont réparties sur un maximum de trois AZs.

us-east-1a
us-east-1c
us-east-1d
us-east-1a

Une fois que le clone est créé et que vous y avez ajouté des instances de base de données, vous pouvez spécifier le nom de ces mêmes zones de disponibilité dans les commandes create-db-instance. Vous pouvez le faire pour configurer des instances de base de données dans le nouveau cluster, configurées exactement de la même manière AZs que dans le cluster d'origine.

Étape 5 : Vérifiez le VPCs que vous pouvez utiliser pour le clone

Si vous avez l'intention de créer le clone dans un VPC différent de celui d'origine, vous pouvez obtenir une liste des VPC IDs disponibles pour votre compte. Vous pouvez également effectuer cette étape si vous devez créer des sous-réseaux supplémentaires dans le même VPC que le cluster d’origine. Lorsque vous exécutez la commande permettant de créer un sous-réseau, vous spécifiez l’identifiant du VPC en tant que paramètre.

Pour répertorier tous les VPCs éléments de votre compte, exécutez la commande CLI suivante :

aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

L’exemple suivant montre un exemple de sortie de la commande describe-vpcs précédente. Le résultat montre qu'il y en a quatre VPCs dans le AWS compte courant qui peuvent être utilisés comme source ou destination pour le clonage entre VPC.

vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

Vous pouvez utiliser le même VPC que la destination pour le clone, ou un VPC différent. Si le cluster d’origine et le clone se trouvent dans le même VPC, vous pouvez réutiliser le même groupe de sous-réseaux de base de données pour le clone. Vous pouvez également créer un autre groupe de sous-réseaux de base de données. Par exemple, le nouveau groupe de sous-réseaux de base de données peut utiliser des sous-réseaux privés, tandis que le groupe de sous-réseaux de base de données du cluster d’origine peut utiliser des sous-réseaux publics. Si vous créez le clone dans un autre VPC, assurez-vous qu'il y a suffisamment de sous-réseaux dans le nouveau VPC et que les sous-réseaux sont associés au droit du cluster d'origine. AZs

Création de ressources réseau pour le clone

Si, lors de la collecte des informations réseau, vous avez découvert que des ressources réseau supplémentaires sont nécessaires pour le clone, vous pouvez les créer avant d’essayer de configurer le clone. Par exemple, vous devrez peut-être créer d'autres sous-réseaux, des sous-réseaux associés à des sous-réseaux spécifiques AZs ou un nouveau groupe de sous-réseaux de base de données.

Étape 1 : créer les sous-réseaux pour le clone

Si vous devez créer des sous-réseaux pour le clone, exécutez une commande similaire à ce qui suit. Vous devrez peut-être procéder de la sorte lors de la création du clone dans un autre VPC ou lors d’une autre modification du réseau, telle que l’utilisation de sous-réseaux privés au lieu de sous-réseaux publics.

AWS génère automatiquement l'ID du sous-réseau. Remplacez my_vpc par le nom du VPC du clone. Choisissez la plage d’adresses pour l’option --cidr-block pour y autoriser au moins 16 adresses IP. Vous pouvez inclure toutes les autres propriétés que vous souhaitez spécifier. Exécutez la commande aws ec2 create-subnet help pour voir tous les choix.

aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

L’exemple suivant montre certains attributs importants d’un sous-réseau nouvellement créé.

{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

Étape 2 : créer le groupe de sous-réseaux de base de données pour le clone

Si vous créez le clone dans un autre VPC ou dans un ensemble différent de sous-réseaux au sein du même VPC, vous devez créer un nouveau groupe de sous-réseaux de base de données et le spécifier lors de la création du clone.

Veillez à connaître tous les détails suivants. Ils sont tous visibles dans la sortie des exemples précédents.

Vérifiez combien AZs sont à la fois associés au stockage du cluster d'origine et associés aux sous-réseaux du VPC de destination. Pour réussir à créer le clone, il doit y en avoir deux ou trois AZs en commun. Si vous en avez moins de deux AZs en commun, revenez àÉtape 1 : créer les sous-réseaux pour le clone. Créez un, deux ou trois nouveaux sous-réseaux AZs associés au stockage du cluster d'origine.

Choisissez des sous-réseaux dans le VPC de destination qui sont associés au AZs même type de stockage Aurora dans le cluster d'origine. Idéalement, choisissez-en trois AZs. Cela vous donne la plus grande flexibilité pour répartir les instances de base de données du clone sur plusieurs AZs pour une haute disponibilité des ressources de calcul.

Exécutez une commande similaire à ce qui suit afin de créer le groupe de sous-réseaux de base de données. Remplacez IDs vos sous-réseaux dans la liste. Si vous spécifiez le sous-réseau à l' IDs aide de variables d'environnement, veillez à citer la liste des --subnet-ids paramètres de manière à conserver les guillemets doubles autour du IDs.

aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

L’exemple suivant illustre la sortie partielle de la commande create-db-subnet-group.

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

À ce stade, vous n’avez pas encore créé le clone. Vous avez créé toutes les ressources de VPC et de sous-réseau pertinentes afin de pouvoir spécifier les paramètres appropriés pour les commandes restore-db-cluster-to-point-in-time et create-db-instance lors de la création du clone.

Création d’un clone Aurora avec de nouveaux paramètres réseau

Une fois que vous vous êtes assuré que la bonne configuration des VPCs sous-réseaux et des groupes de sous-réseaux est en place pour le nouveau cluster à utiliser, vous pouvez effectuer l'opération de clonage proprement dite. AZs Les exemples suivants de la CLI mettent en évidence les options telles que --db-subnet-group-name, --availability-zone et --vpc-security-group-ids que vous spécifiez dans les commandes pour configurer le clone et ses instances de base de données.

Étape 1 : spécifier le groupe de sous-réseaux de base de données pour le clone

Lorsque vous créez le clone, vous pouvez configurer tous les paramètres appropriés pour les VPC, les sous-réseaux et les zones de disponibilité en spécifiant un groupe de sous-réseaux de base de données. Utilisez les commandes des exemples précédents pour vérifier toutes les relations et tous les mappages inhérents au groupe de sous-réseaux de base de données.

Par exemple, les commandes suivantes illustrent le clonage d’un cluster d’origine vers un clone. Dans le premier exemple, le cluster source est associé à deux sous-réseaux et le clone est associé à trois sous-réseaux. Le deuxième exemple montre le cas contraire, à savoir le clonage d’un cluster de trois sous-réseaux vers un cluster de deux sous-réseaux.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

Si vous avez l’intention d’utiliser des instances Aurora sans serveur v2 dans le clone, incluez une option --serverless-v2-scaling-configuration lors de la création du clone, comme indiqué. Cela vous permet d’utiliser la classe db.serverless lors de la création d’instances de base de données dans le clone. Vous pourrez également modifier le clone ultérieurement pour ajouter cet attribut de configuration de mise à l’échelle. Les valeurs de capacité indiquées dans cet exemple permettent à chaque instance Serverless v2 du cluster d'évoluer entre 2 et 32 unités de capacité Aurora (ACUs). Pour en savoir plus sur la fonctionnalité Aurora sans serveur v2 et sur le choix de la plage de capacité, consultez Utilisation de l’Aurora Serverless v2.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-2-subnets \
  --db-cluster-identifier cluster-cloned-to-3-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name three-subnets \
  --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32'

Quel que soit le nombre de sous-réseaux utilisés par les instances de base de données, le stockage Aurora pour le cluster source et le clone est associé à trois AZs. L'exemple suivant répertorie les commandes AZs associées au cluster d'origine et au clone, pour les deux restore-db-cluster-to-point-in-time commandes des exemples précédents.

aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

Étant donné qu'au moins deux des deux clusters d'origine et de clone AZs se chevauchent, les deux clusters peuvent accéder au même stockage Aurora sous-jacent.

Étape 2 : spécifier les paramètres réseau des instances du clone

Lorsque vous créez des instances de base de données dans le clone, elles héritent par défaut du groupe de sous-réseaux de base de données du cluster lui-même. De cette façon, Aurora assigne automatiquement chaque instance à un sous-réseau particulier et la crée dans la zone de disponibilité associée au sous-réseau. Ce choix est pratique, en particulier pour les systèmes de développement et de test, car vous n'avez pas à suivre le sous-réseau IDs ou à ajouter de nouvelles instances au clone. AZs

Vous pouvez également spécifier la zone de disponibilité lorsque vous créez une instance de base de données Aurora pour le clone. L'AZ que vous spécifiez doit faire partie de l'ensemble AZs des éléments associés au clone. Si le groupe de sous-réseaux de base de données que vous utilisez pour le clone ne contient que deux sous-réseaux, vous ne pouvez choisir que parmi ceux AZs associés à ces deux sous-réseaux. Ce choix offre flexibilité et résilience aux systèmes à haute disponibilité, car vous pouvez vous assurer que l'instance d'écriture et l'instance de lecture de secours sont différentes AZs. Ou si vous ajoutez des lecteurs supplémentaires au cluster, vous pouvez vous assurer qu'ils sont répartis sur trois AZs. Ainsi, même dans les rares cas d'échec d'AZ, vous disposez toujours d'une instance d'écriture et d'une autre instance de lecteur dans deux autres AZs.

L’exemple suivant ajoute une instance de base de données provisionnée à un cluster Aurora PostgreSQL cloné qui utilise un groupe de sous-réseaux de base de données personnalisé.

aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

L’exemple suivant montre une sortie partielle de ce type de commande.

{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

L’exemple suivant ajoute une instance de base de données Aurora sans serveur v2 à un clone Aurora MySQL qui utilise un groupe de sous-réseaux de base de données personnalisé. Pour pouvoir utiliser les instances sans serveur v2, assurez-vous de spécifier l’option --serverless-v2-scaling-configuration pour la commande restore-db-cluster-to-point-in-time, comme indiqué dans les exemples précédents.

aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

L’exemple suivant montre une sortie partielle de ce type de commande.

{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

Étape 3 : établir la connectivité entre un système client et un clone

Si vous vous connectez déjà à un cluster Aurora à partir d’un système client, vous souhaiterez peut-être autoriser le même type de connectivité à un nouveau clone. Par exemple, vous pouvez vous connecter au cluster d’origine à partir d’une instance Amazon Cloud9 ou d’une instance EC2. Pour autoriser les connexions à partir des mêmes systèmes clients ou de nouveaux systèmes que vous créerez dans le VPC de destination, configurez des groupes de sous-réseaux de base de données et des groupes de sécurité VPC équivalents à ceux du VPC. Spécifiez ensuite le groupe de sous-réseaux et les groupes de sécurité lorsque vous créez le clone.

Les exemples suivants configurent un clone Aurora sans serveur v2. Cette configuration est basée sur la combinaison de --engine-mode provisioned et --serverless-v2-scaling-configuration lors de la création du cluster de bases de données, puis --db-instance-class db.serverless lors de la création de chaque instance de base de données du cluster. Le mode moteur provisioned étant le mode par défaut, vous pouvez omettre cette option si vous le souhaitez.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

Ensuite, lors de la création des instances de base de données dans le clone, spécifiez la même option --db-subnet-group-name. Vous pouvez éventuellement inclure l'--availability-zoneoption et spécifier l'un des sous-réseaux AZs associés à ce groupe de sous-réseaux. Cette AZ doit également être l'une des zones AZs associées au cluster d'origine.

aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

Remplacement des sous-réseaux publics par des sous-réseaux privés pour un cluster

Vous pouvez utiliser le clonage pour remplacer les sous-réseaux publics d’un cluster par des sous-réseaux privés. Cette opération peut être utile lorsque vous ajoutez des couches de sécurité supplémentaires à votre application avant de la déployer en production. Pour cet exemple, les sous-réseaux privés et la passerelle NAT devraient déjà être configurés avant que vous ne démarriez le processus de clonage avec Aurora.

Pour les étapes impliquant Aurora, vous pouvez suivre les mêmes étapes générales que dans les exemples précédents pour Collecte d’informations sur l’environnement réseau et Création d’un clone Aurora avec de nouveaux paramètres réseau. La principale différence est que même si vous avez des sous-réseaux publics mappés à tous ceux AZs du cluster d'origine, vous devez maintenant vérifier que vous disposez de suffisamment de sous-réseaux privés pour un cluster Aurora et que ces sous-réseaux sont associés à tous ceux utilisés pour le stockage Aurora dans le cluster d'origine. AZs Comme dans d'autres cas d'utilisation du clonage, vous pouvez créer le groupe de sous-réseaux de base de données pour le clone avec trois ou deux sous-réseaux privés associés au réseau requis. AZs Toutefois, si vous utilisez deux sous-réseaux privés dans le groupe de sous-réseaux de base de données, vous devrez disposer d’un troisième sous-réseau privé associé à la troisième zone de disponibilité utilisée pour le stockage Aurora dans le cluster d’origine.

Vous pouvez consulter cette liste de contrôle pour vérifier que toutes les exigences sont satisfaites pour effectuer ce type d’opération de clonage.

Lorsque toutes les conditions requises sont réunies, vous pouvez suspendre l’activité de la base de données sur le cluster d’origine pendant que vous créez le clone et que vous changez d’application pour l’utiliser. Une fois que le clone est créé et que vous avez vérifié que vous pouvez vous y connecter, exécuter le code de votre application, etc., vous pouvez cesser d’utiliser le cluster d’origine.

End-to-end exemple de création d'un clone cross-VPC

La création d’un clone dans un VPC différent de celui d’origine suit les mêmes étapes générales que dans les exemples précédents. L’ID du VPC étant une propriété des sous-réseaux, vous ne spécifiez pas cet ID en tant que paramètre lorsque vous exécutez l’une des commandes de la CLI RDS. La principale différence est que vous aurez probablement besoin de créer de nouveaux sous-réseaux, de nouveaux sous-réseaux mappés à des groupes spécifiques, un groupe de sécurité VPC et AZs un nouveau groupe de sous-réseaux de base de données. Cela est particulièrement vrai s’il s’agit du premier cluster Aurora que vous créez dans ce VPC.

Vous pouvez consulter cette liste de contrôle pour vérifier que toutes les exigences sont satisfaites pour effectuer ce type d’opération de clonage.

Lorsque toutes les conditions requises sont réunies, vous pouvez suspendre l’activité de la base de données sur le cluster d’origine pendant que vous créez le clone et que vous changez d’application pour l’utiliser. Une fois que le clone est créé et que vous avez vérifié que vous pouvez vous y connecter, exécuter le code de votre application, etc., vous pouvez décider de continuer à exécuter le cluster d’origine ainsi que les clones ou de cesser d’utiliser le cluster d’origine.

Les exemples Linux suivants montrent la séquence d'opérations AWS CLI pour cloner un cluster de base de données Aurora d'un VPC à un autre. Certains champs qui ne sont pas pertinents pour ces exemples ne sont pas affichés dans la sortie de la commande.

Tout d'abord, nous vérifions IDs la source et la destination VPCs. Le nom descriptif que vous attribuez à un VPC lorsque vous le créez est représenté sous forme de balise dans les métadonnées du VPC.

$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

Le cluster d’origine existe déjà dans le VPC source. Pour configurer le clone en utilisant le même ensemble de données AZs pour le stockage Aurora, nous vérifions les valeurs AZs utilisées par le cluster d'origine.

$ aws rds describe-db-clusters --db-cluster-identifier original-cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Nous nous assurons que certains sous-réseaux correspondent à ceux AZs utilisés par le cluster d'origine : us-east-1cus-east-1d, etus-east-1f.

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

Cet exemple confirme que certains sous-réseaux correspondent aux éléments nécessaires AZs dans le VPC de destination.

aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

Avant de créer un cluster de base de données Aurora dans le VPC, vous devez disposer d'un groupe de sous-réseaux de base de données dont les sous-réseaux correspondent à ceux utilisés AZs pour le stockage Aurora. Lorsque vous créez un cluster normal, vous pouvez utiliser n'importe quel ensemble de trois AZs. Lorsque vous clonez un cluster existant, le groupe de sous-réseaux doit correspondre à au moins deux des trois AZs qu'il utilise pour le stockage Aurora.

$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

Les sous-réseaux et le groupe de sous-réseaux de base de données sont maintenant en place. L’exemple suivant montre l’opération restore-db-cluster-to-point-in-time qui clone le cluster. L'--db-subnet-group-nameoption associe le clone au bon ensemble de sous-réseaux mappés au bon ensemble de sous-réseaux AZs du cluster d'origine.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

L'exemple suivant confirme que le stockage Aurora du clone utilise le même ensemble de composants AZs que celui du cluster d'origine.

$ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

À ce stade, vous pouvez créer des instances de base de données pour le clone. Assurez-vous que le groupe de sécurité VPC associé à chaque instance autorise les connexions à partir des plages d’adresses IP que vous utilisez pour les instances EC2, les serveurs d’applications, etc. qui se trouvent dans le VPC de destination.