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.
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 environnement à des VPC 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érentsVPCs. 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 passer d'un EC2 service à l'autre, les exemples utilisent des AWS CLI commandes pour vous aider à comprendre comment automatiser ces opérations et enregistrer le résultat. RDS
Rubriques
Avant de commencer
Avant de commencer à configurer un VPC clonage croisé, assurez-vous de disposer des ressources suivantes :
-
Un cluster de base de données Aurora à utiliser comme source pour le clonage. Si c'est la première fois que vous créez un cluster de base de données Aurora, consultez les didacticiels Mise en route avec Amazon Aurora ci-dessous pour configurer un cluster à l'aide du moteur de SQL base de données My SQL ou Postgre.
-
Une secondeVPC, si vous avez l'intention de créer un VPC clone croisé. Si vous n'en avez pas VPC à utiliser pour le clone, consultez Tutoriel : créer un VPC à utiliser avec un(e) cluster de base de données (IPv4 uniquement) ouTutoriel : Créer un VPC à utiliser avec un cluster de base de données (mode double-pile).
Collecte d'informations sur l'environnement réseau
Avec le VPC clonage croisé, 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 les informations relatives aux sous-réseauxVPC, au groupe de sous-réseaux de base de données et aux informations AZs utilisées dans le cluster d'origine. De cette façon, vous pouvez minimiser 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 CLI des exemples de collecte de ce type d'informations. Vous pouvez enregistrer les détails 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 troisAZs. Dans la mesure où ils Clusters de bases de données Amazon Aurora tirent parti de la séparation du calcul et du stockage, cette règle est vraie quel que soit le nombre d'instances présentes dans le cluster.
Par exemple, exécutez une CLI commande telle que la suivante en remplaçant le nom de votre propre cluster par. my_cluster
aws rds describe-db-clusters \ --db-cluster-identifiermy_cluster\ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \ --output text
L'exemple suivant montre un exemple de sortie de la describe-db-clusters commande précédente. Cela montre que le stockage du cluster Aurora en utilise toujours troisAZs.
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 connecterAZs, vous devez créer des sous-réseaux associés à au moins deux d'entre euxAZs, 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érifiez 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 Aurora DB contient au moins deux sous-réseaux, chacun étant associé à une AZ 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 le nom de votre cluster par my_clustermy_subnet
aws rds describe-db-clusters --db-cluster-identifiermy_cluster\ --query '*[].DBSubnetGroup' --output text aws rds describe-db-subnet-groups --db-subnet-group-namemy_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, il s'two-subnetsagit d'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, le résultat 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 AWS CLI des commandes similaires aux suivantes. Vous pouvez examiner les attributs du sous-réseau tels que les plages d'adresses IP, le propriétaire, etc. Ainsi, vous pouvez déterminer s'il convient d'utiliser différents sous-réseaux dans un même VPC sous-réseau ou de créer des sous-réseaux présentant des caractéristiques similaires dans un autre. VPC
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
Trouvez 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-namemy_subnet_group\ --query '*[].Subnets[].[SubnetIdentifier]' --output text
Spécifiez ensuite les sous-réseaux que vous souhaitez étudier dans une liste, comme dans la commande suivante. Remplacez les noms de vos sous-réseaux par my_subnet_1
aws ec2 describe-subnets \ --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'
L'exemple suivant montre une sortie partielle d'une telle describe-subnets commande. La sortie montre certains des attributs importants que vous pouvez voir pour chaque sous-réseau, tels que l'AZ associé et VPC celui 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'AZsutilisation 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 est utilisé pour la production, le développement et les tests, etc.
Pour chaque instance du cluster d'origine, exécutez une commande telle que la suivante. Assurez-vous que la création de l'instance est terminée et qu'elle est dans son Available état initial. Remplacez l'identifiant de l'instance parmy_instance
aws rds describe-db-instances --db-instance-identifiermy_instance\ --query '*[].AvailabilityZone' --output text
L'exemple suivant montre le résultat de l'exécution de la describe-db-instances commande 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 remplaçant à 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 troisAZs.
us-east-1a
us-east-1c
us-east-1d
us-east-1a
Une fois le clone créé et que vous y avez ajouté des instances de base de données, vous pouvez spécifier ces mêmes noms AZ dans les create-db-instance commandes. 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 sous une VPC forme différente de l'original, vous pouvez obtenir une liste des VPC IDs versions disponibles pour votre compte. Vous pouvez également effectuer cette étape si vous devez créer des sous-réseaux supplémentaires identiques VPC à ceux du cluster d'origine. Lorsque vous exécutez la commande pour créer un sous-réseau, vous spécifiez l'VPCID en tant que paramètre.
Pour répertorier toutes les VPCs informations associées à votre compte, exécutez la CLI commande suivante :
aws ec2 describe-vpcs --query '*[].[VpcId]' --output text
L'exemple suivant montre un exemple de sortie de la describe-vpcs commande 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 VPC clonage croisé.
vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad
Vous pouvez utiliser la VPC même destination pour le clone, ou une autreVPC. Si le cluster d'origine et le clone se trouvent dans le même groupeVPC, 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 clusterVPC, assurez-vous qu'il y a suffisamment de sous-réseaux dans le nouveau VPC et que les sous-réseaux sont associés directement au cluster AZs d'origine.
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 créer ces ressources 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éation des sous-réseaux pour le clone
Si vous devez créer de nouveaux sous-réseaux pour le clone, exécutez une commande similaire à la suivante. Vous devrez peut-être le faire lors de la création du clone dans un autre environnement ou lors d'une autre modification du réseauVPC, par exemple en utilisant des sous-réseaux privés au lieu de sous-réseaux publics.
AWS génère automatiquement l'ID du sous-réseau. Remplacez le nom du clone VPC parmy_vpc--cidr-blockoption permettant d'autoriser au moins 16 adresses IP dans la plage. 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-idmy_vpc\ --availability-zoneAZ_name--cidr-blockIP_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 ensemble de sous-réseaux différent VPC ou différent au sein du mêmeVPC, vous créez un nouveau groupe de sous-réseaux de base de données et vous le spécifiez lors de la création du clone.
Assurez-vous de connaître tous les détails suivants. Vous pouvez trouver tous ces éléments à partir des résultats des exemples précédents.
-
VPCdu cluster d'origine. Pour obtenir des instructions, consultez Étape 3 : vérifier les sous-réseaux du cluster d'origine.
-
VPCdu clone, si vous le créez dans un autreVPC. Pour obtenir des instructions, consultez Étape 5 : Vérifiez le VPCs que vous pouvez utiliser pour le clone.
-
Trois AZs sont associés au stockage Aurora du cluster d'origine. Pour obtenir des instructions, consultez Étape 1 : vérifier les zones de disponibilité du cluster d'origine.
-
Deux ou trois AZs associés au groupe de sous-réseaux de base de données pour le cluster d'origine. Pour obtenir des instructions, consultez Étape 2 : Vérifiez le groupe de sous-réseaux de base de données du cluster d'origine.
-
Le sous-réseau IDs associé à AZs tous les sous-réseaux VPC que vous souhaitez utiliser pour le clone. Utilisez la même
describe-subnetscommande que dansÉtape 3 : vérifier les sous-réseaux du cluster d'origine, en remplaçant l'VPCID de la destination. VPC
Vérifiez combien AZs sont à la fois associés au stockage du cluster d'origine et associés aux sous-réseaux de la destinationVPC. 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éation des 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 la destination VPC qui sont associés au même type AZs de stockage Aurora dans le cluster d'origine. Idéalement, choisissez-en troisAZs. 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 à la suivante pour créer le nouveau 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'IDsaide de variables d'environnement, veillez à citer la liste des --subnet-ids paramètres de manière à conserver les guillemets doubles autour duIDs.
aws rds create-db-subnet-group --db-subnet-group-namemy_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 montre une sortie partielle de la create-db-subnet-group commande.
{
'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 pertinentes VPC et les ressources de sous-réseau afin de pouvoir spécifier les paramètres appropriés pour les create-db-instance commandes restore-db-cluster-to-point-in-time et lors de la création du clone.
Création d'un clone d'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 CLI exemples suivants 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ésVPC, de sous-réseau et AZ 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 qui entrent dans le 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 Serverless v2 dans le clone, incluez une --serverless-v2-scaling-configuration option lors de la création du clone, comme indiqué. Cela vous permet d'utiliser la db.serverless classe lors de la création d'instances de base de données dans le clone. Vous pouvez également modifier le clone ultérieurement pour ajouter cet attribut de configuration de dimensionnement. 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 plus d'informations sur la fonctionnalité Aurora Serverless v2 et sur le choix de la plage de capacité, consultezUtilisation 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é à troisAZs. 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 textus-east-1c us-east-1d us-east-1faws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output textus-east-1c us-east-1d us-east-1faws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output textus-east-1a us-east-1c us-east-1daws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output textus-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 pour les 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. Ainsi, Aurora assigne automatiquement chaque instance à un sous-réseau particulier et la crée dans l'AZ 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 l'AZ 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érentesAZs. Ou si vous ajoutez des lecteurs supplémentaires au cluster, vous pouvez vous assurer qu'ils sont répartis sur troisAZs. 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 autresAZs.
L'exemple suivant ajoute une instance de base de données provisionnée à un SQL cluster Aurora Postgre cloné qui utilise un groupe de sous-réseaux de base de données personnalisé.
aws rds create-db-instance --db-cluster-identifiermy_aurora_postgresql_clone\ --db-instance-identifiermy_postgres_instance\ --db-subnet-group-namemy_new_subnet\ --engine aurora-postgresql \ --db-instance-class db.t4g.medium
L'exemple suivant montre une sortie partielle d'une telle 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 Serverless v2 à un SQL clone Aurora My qui utilise un groupe de sous-réseaux de base de données personnalisé. Pour pouvoir utiliser les instances Serverless v2, assurez-vous de spécifier l'--serverless-v2-scaling-configurationoption pour la restore-db-cluster-to-point-in-time commande, comme indiqué dans les exemples précédents.
aws rds create-db-instance --db-cluster-identifiermy_aurora_mysql_clone\ --db-instance-identifiermy_mysql_instance\ --db-subnet-group-namemy_other_new_subnet\ --engine aurora-mysql \ --db-instance-class db.serverless
L'exemple suivant montre une sortie partielle d'une telle commande.
{
'DBInstanceIdentifier': 'my_mysql_instance',
'DBClusterIdentifier': 'my_aurora_mysql_clone',
'DBInstanceClass': 'db.serverless',
'DBInstanceStatus': 'creating'
...
}
Étape 3 : établissement de 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 ou EC2 d'une instance Amazon Cloud9. Pour autoriser les connexions provenant des mêmes systèmes clients, ou de nouveaux systèmes que vous créez dans la destinationVPC, configurez des groupes de sous-réseaux de base de données et des groupes VPC de sécurité équivalents à ceux duVPC. 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 Serverless 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 provisioned moteur é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 --db-subnet-group-name option. 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
Déplacement d'un cluster de sous-réseaux publics vers des sous-réseaux privés
Vous pouvez utiliser le clonage pour faire migrer un cluster entre des sous-réseaux publics et privés. Vous pouvez le faire 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 NAT passerelle devraient déjà être configurés avant de démarrer 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 etCréation d'un clone d'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 devez disposer d'un troisième sous-réseau privé associé à la troisième AZ 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 réunies pour effectuer ce type d'opération de clonage.
-
Enregistrez les trois AZs qui sont associés au cluster d'origine. Pour obtenir des instructions, consultez Étape 1 : vérifier les zones de disponibilité du cluster d'origine.
-
Enregistrez les trois ou deux AZs associés aux sous-réseaux publics dans le groupe de sous-réseaux de base de données du cluster d'origine. Pour obtenir des instructions, consultez Étape 3 : vérifier les sous-réseaux du cluster d'origine.
-
Créez des sous-réseaux privés qui correspondent aux trois sous-réseaux associés au cluster d'origine. AZs Effectuez également toute autre configuration réseau, telle que la création d'une NAT passerelle, pour pouvoir communiquer avec les sous-réseaux privés. Pour obtenir des instructions, consultez la section Créer un sous-réseau dans le guide de l'utilisateur d'Amazon Virtual Private Cloud.
-
Créez un nouveau groupe de sous-réseaux de base de données contenant trois ou deux des sous-réseaux privés associés au AZs depuis le premier point. Pour obtenir des instructions, consultez Étape 2 : créer le groupe de sous-réseaux de base de données pour le clone.
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 qu'elle l'utilise. 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 VPC clone croisé
La création d'un clone dans un VPC format différent de l'original suit les mêmes étapes générales que dans les exemples précédents. L'VPCID étant une propriété des sous-réseaux, vous ne le spécifiez pas réellement en tant que paramètre lorsque vous exécutez l'une des RDS CLI commandes. VPC 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 à un groupe spécifiqueAZs, un groupe de VPC sécurité et 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 clusterVPC.
Vous pouvez consulter cette liste de contrôle pour vérifier que toutes les exigences sont réunies pour effectuer ce type d'opération de clonage.
-
Enregistrez les trois AZs qui sont associés au cluster d'origine. Pour obtenir des instructions, consultez Étape 1 : vérifier les zones de disponibilité du cluster d'origine.
-
Enregistrez les trois ou deux AZs associés aux sous-réseaux du groupe de sous-réseaux de base de données pour le cluster d'origine. Pour obtenir des instructions, consultez Étape 2 : Vérifiez le groupe de sous-réseaux de base de données du cluster d'origine.
-
Créez des sous-réseaux qui correspondent aux trois sous-réseaux associés au cluster d'origine. AZs Pour obtenir des instructions, consultez Étape 1 : Création des sous-réseaux pour le clone.
-
Effectuez toute autre configuration réseau, telle que la configuration d'un groupe de VPC sécurité, pour les systèmes clients, les serveurs d'applications, etc. afin de pouvoir communiquer avec les instances de base de données du clone. Pour obtenir des instructions, consultez Contrôle d'accès par groupe de sécurité.
-
Créez un nouveau groupe de sous-réseaux de base de données contenant trois ou deux des sous-réseaux associés à AZs partir du premier point. Pour obtenir des instructions, consultez Étape 2 : créer le groupe de sous-réseaux de base de données pour le clone.
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 qu'elle l'utilise. 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 conserver l'original et les clones en cours d'exécution ou de cesser d'utiliser le cluster d'origine.
Les exemples Linux suivants montrent la séquence d' AWS CLIopérations permettant de cloner un cluster de base de données Aurora de l'un VPC à l'autre. Certains champs qui ne sont pas pertinents pour les exemples ne sont pas affichés dans le résultat de la commande.
Tout d'abord, nous vérifions IDs la source et la destinationVPCs. Le nom descriptif que vous attribuez à un VPC lorsque vous le créez est représenté sous forme de balise dans les VPC métadonnées.
$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 la sourceVPC. 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 textus-east-1c us-east-1d us-east-1f
Nous nous assurons qu'il existe des sous-réseaux qui correspondent à ceux AZs utilisés par le cluster d'origine :us-east-1c,us-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 qu'il existe des sous-réseaux mappés vers le nécessaire AZs dans la destinationVPC.
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 leVPC, vous devez disposer d'un groupe de sous-réseaux de base de données dont les sous-réseaux correspondent à ceux AZs utilisés pour le stockage Aurora. Lorsque vous créez un cluster normal, vous pouvez utiliser n'importe quel ensemble de troisAZs. 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 celui 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 textus-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 VPC de sécurité associé à chaque instance autorise les connexions à partir des plages d'adresses IP que vous utilisez pour les EC2 instances, les serveurs d'applications, etc. qui se trouvent dans la destinationVPC.
