Cette page explique comment mettre à niveau vos instances Cloud SQL de l'ancienne architecture réseau vers la nouvelle.
Cette page de mise à niveau de l'architecture réseau Cloud SQL ne s'applique qu'à certaines instances Cloud SQL. Si vos instances Cloud SQL utilisent un projet de réseau cloud privé virtuel (VPC) créé avant août 2021, vous devez mettre à niveau l'architecture réseau Cloud SQL pour vos instances.
Présentation
Le tableau suivant montre les avantages de la nouvelle architecture réseau par rapport à l'ancienne :
Capacité | Ancienne architecture réseau | Nouvelle architecture réseau |
---|---|---|
Migrer de Cloud SQL vers AlloyDB pour PostgreSQL et d'AlloyDB pour PostgreSQL vers Cloud SQL à l'aide de Database Migration Service | Vous devez configurer une adresse IP privée pour la migration | Aucune configuration réseau supplémentaire n'est requise. Par exemple, la migration de Cloud SQL vers AlloyDB pour PostgreSQL ou AlloyDB pour PostgreSQL vers Cloud SQL. |
Connectez votre instance Cloud SQL en utilisant une adresse IP privée à des services privés tels que Cloud Build ou Vertex AI. | Non compatible en raison de l'intransitivité de l'appairage de réseaux | Compatible |
Instances conformes aux charges de travail Assured Workloads | Non compatible | Compatible |
Managed Microsoft AD | Non compatible | Compatible |
Private Service Connect | Non compatible | Compatible |
Quota d'instances Cloud SQL par défaut et par projet | 100 | 1000 |
Planifier votre mise à niveau
Avant de mettre à jour l'architecture réseau de vos instances Cloud SQL, planifiez la mise à niveau en fonction des contraintes de mise à niveau suivantes :
Si vous mettez à niveau votre architecture réseau, votre instance peut être indisponible pendant quatre minutes en moyenne.
Si une migration de données est en cours, vous ne pouvez pas mettre à niveau l'instance source vers la nouvelle architecture pendant la migration de données.
Si vous vous connectez à une instance à partir d'une source externe, vérifiez que toutes les connexions d'appairage sont mises à jour pour permettre l'exportation de routes personnalisées.
Vous ne pouvez pas mettre à niveau l'architecture réseau d'instances sur un réseau comportant plus de 300 instances Cloud SQL.
Si votre réseau comprend au moins deux instances utilisant des adresses IP privées dans la même région, Cloud SQL doit utiliser une ou plusieurs plages /24 supplémentaires de la plage d'adresses IP d'accès aux services privés allouée pour héberger les instances dans la nouvelle architecture réseau. Cette consommation supplémentaire est temporaire et est supprimée lors d'un événement de maintenance Cloud SQL ultérieur.
Planifier la mise à niveau de toutes les instances Clud SQL d'un projet réseau
Vos instances Cloud SQL peuvent se trouver dans le même projet que le réseau VPC ou être hébergées dans un projet distinct. Le projet qui héberge le réseau VPC est le projet réseau.
Si au moins une instance Cloud SQL dans un projet de réseau utilise l'ancienne architecture réseau, l'ensemble du projet utilise l'ancienne architecture réseau. Dans ce cas, votre projet n'est pas complètement mis à niveau vers la nouvelle architecture réseau.
Vous pouvez interroger l'architecture réseau de toutes les instances Cloud SQL d'un projet à l'aide de la gcloud CLI ou de l'API Cloud SQL Admin.
Lorsque vous modifiez le réseau privé d'une instance ou que vous activez une adresse IP privée pour une instance, vous ne pouvez pas modifier l'architecture réseau dans la même requête. Si vous le faites, la requête est rejetée. Pour éviter cela, nous vous recommandons de mettre à niveau toutes les instances d'un projet réseau avant de modifier le projet réseau.
Mettre à niveau l'architecture réseau Cloud SQL
Pour mettre à niveau l'architecture réseau de vos instances Cloud SQL, procédez comme suit :
- Vérifiez l'architecture réseau d'une seule instance Cloud SQL ou de plusieurs instances Cloud SQL.
- Mettez à niveau l'architecture réseau d'une instance Cloud SQL.
Vérifier l'architecture réseau d'une seule instance Cloud SQL
Pour vérifier l'architecture réseau actuelle d'une seule instance, utilisez la commande gcloud sql instances describe
ou la méthode instances.get
.
gcloud
Pour en savoir plus sur l'installation et le démarrage avec la gcloud CLI, consultez la page Installer la gcloud CLI. Pour en savoir plus sur le démarrage de Cloud Shell, consultez la page Utiliser Cloud Shell.
Pour vérifier l'architecture réseau d'une seule instance, exécutez la commande suivante :
gcloud sql instances describe INSTANCE_NAME
Si l'instance utilise l'ancienne architecture réseau, la réponse est semblable à celle-ci :
name: INSTANCE_NAME project: PROJECT_ID ... sqlNetworkArchitecture: OLD_NETWORK_ARCHITECTURE
Si l'instance utilise la nouvelle architecture réseau, la réponse est semblable à celle-ci :
name: INSTANCE_NAME project: PROJECT_ID ... sqlNetworkArchitecture: NEW_NETWORK_ARCHITECTURE
Le paramètre sqlNetworkArchitecture
indique si votre instance utilise l'ancienne architecture réseau (OLD_NETWORK_ARCHITECTURE
) ou la nouvelle (NEW_NETWORK_ARCHITECTURE
).
REST v1
Pour vérifier l'architecture réseau d'une instance, utilisez la méthode instances.get
de l'API Cloud SQL Admin.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- INSTANCE_NAME : nom de l'instance.
- NETWORK_ARCHITECTURE_TYPE : le type d'architecture de réseau est défini comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
REST v1beta4
Pour vérifier l'architecture réseau d'une instance, utilisez la méthode instances.get
de l'API Cloud SQL Admin.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- INSTANCE_NAME : nom de l'instance.
- NETWORK_ARCHITECTURE_TYPE : le type d'architecture de réseau est défini comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
Vérifier l'architecture réseau de plusieurs instances Cloud SQL
Pour vérifier l'architecture réseau de plusieurs instances dans un projet, utilisez la commande gcloud sql instances list
ou la méthode instance.list
.
gcloud
Pour vérifier l'architecture réseau de plusieurs instances d'un projet, exécutez la commande suivante :
gcloud sql instances list --show-sql-network-architecture
La sortie doit ressembler à ce qui suit.
NAME DATABASE_VERSION LOCATION ... SQL_NETWORK_ARCHITECTURE instance_1 POSTGRES_13 asia-northeast1-b OLD_NETWORK_ARCHITECTURE instance_2 MYSQL_5_7 europe-west1-d NEW_NETWORK_ARCHITECTURE ...
REST v1
Pour vérifier l'architecture réseau de plusieurs instances dans un projet, utilisez la méthode instance.list
.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- NETWORK_ARCHITECTURE_TYPE : type d'architecture réseau comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
LIST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
REST v1beta4
Pour vérifier l'architecture réseau de plusieurs instances dans un projet, utilisez la méthode instance.list
.
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- NETWORK_ARCHITECTURE_TYPE : le type d'architecture de réseau est défini comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
LIST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
Mettre à niveau l'architecture réseau d'une seule instance Cloud SQL
Pour mettre à niveau l'architecture réseau pour une seule instance, utilisez la commandegcloud sql instances patch
, la méthode instance.update
ou la méthode instance.patch
.
gcloud
Pour mettre à jour l'architecture réseau d'une instance, exécutez la commande suivante :
gcloud sql instances patch INSTANCE_NAME --upgrade-sql-network-architecture
L'opération de mise à niveau prend quelques minutes.
Pendant la mise à niveau, une opération de longue durée démarre et un jeton d'opération est renvoyé :
operation_id
REST v1
Pour mettre à niveau l'architecture réseau d'une instance, utilisez la méthode instance.update
ou instance.patch
de l'API Cloud SQL Admin.
Lorsque vous mettez à niveau l'architecture réseau Cloud SQL, aucune mise à jour supplémentaire de l'instance n'est autorisée dans la requête. Le corps de la requête contient une instance de l'objet DatabaseInstance
, avec sqlNetworkArchitecture
défini sur NEW_NETWORK_ARCHITECTURE
.
Pendant la mise à niveau, une opération de longue durée démarre et un jeton d'opération est renvoyé :
operation_id
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- INSTANCE_NAME : nom de l'instance.
- NETWORK_ARCHITECTURE_TYPE : le type d'architecture de réseau est défini comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance, "targetLink": string, "status": enum (SqlOperationStatus), "name": string, "insertTime": string, "startTime": string, "endTime": string ... }
Si la mise à niveau de votre instance échoue, relancez l'opération.
REST v1beta4
Pour mettre à niveau l'architecture réseau d'une instance, utilisez la instance.update method
ou la instance.patch method
de l'API Cloud SQL Admin.
Lorsque vous mettez à niveau l'architecture réseau Cloud SQL, aucune mise à jour supplémentaire de l'instance n'est autorisée dans la requête. Le corps de la requête contient une instance de l'objet DatabaseInstance
, avec sqlNetworkArchitecture
défini sur NEW_NETWORK_ARCHITECTURE
.
Pendant la mise à niveau, une opération de longue durée démarre et un jeton d'opération est renvoyé :
operation_id
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet
- INSTANCE_NAME : nom de l'instance.
- NETWORK_ARCHITECTURE_TYPE : le type d'architecture de réseau est défini comme suit :
OLD_NETWORK_ARCHITECTURE
: l'instance utilise l'ancienne architecture réseau.NEW_NETWORK_ARCHITECTURE
: l'instance utilise la nouvelle architecture de réseau.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": sql#instance, "targetLink": string, "status": enum (SqlOperationStatus), "name": string, "insertTime": string, "startTime": string, "endTime": string ... }
Si la mise à niveau de votre instance échoue pour une raison ou une autre, relancez l'opération.
Questions fréquentes
Cette section fournit des réponses aux questions fréquentes sur la mise à niveau de votre architecture réseau Cloud SQL.
- Quel est l'impact de la mise à niveau sur mon instance Cloud SQL ?
- Toutes les fonctionnalités fonctionnent-elles de la même manière après la mise à niveau ?
- Quelles instances utilisent l'ancienne architecture réseau ?
- Toutes les nouvelles instances Cloud SQL sont-elles créées dans la nouvelle architecture réseau ?
- Est-il possible de mettre à jour toutes les instances d'un projet à l'aide d'une seule commande ?
- L'instance répliquée est-elle automatiquement mise à niveau si je mets à niveau l'instance principale ?
- J'ai reçu une notification indiquant que l'architecture réseau de mes instances Cloud SQL allait être mise à niveau. Que dois-je faire ?
- Pourquoi ne puis-je pas mettre à niveau l'architecture réseau de mon instance zonale ?
- Lorsque j'essaie de mettre à niveau mon instance, le message d'erreur "En dehors de la plage d'adresses IP réservées" s'affiche. Que dois-je faire ?
Quel est l'impact de la mise à niveau sur mon instance Cloud SQL ?
Lors de la mise à niveau de votre architecture réseau, l'instance Cloud SQL est à l'état MAINTENANCE. Dans cet état, l'instance subit en moyenne jusqu'à quatre minutes de temps d'arrêt. Aucune modification supplémentaire de l'instance n'est autorisée tant que la mise à niveau n'est pas terminée. Les autres instances de votre projet ou de votre réseau ne sont pas affectées par la mise à niveau.
Toutes les fonctionnalités fonctionnent-elles de la même manière après la mise à niveau ?
Toutes les fonctionnalités de votre instance Cloud SQL fonctionnent de la même manière dans la nouvelle architecture que dans l'ancienne. Après avoir mis à niveau une instance pour utiliser la nouvelle architecture réseau, si vous souhaitez changer le réseau de cette instance, assurez-vous que toutes les instances du réseau de destination sont également mises à niveau vers la nouvelle architecture réseau.
Quelles instances utilisent l'ancienne architecture réseau ?
Tous les projets créés après août 2021 utilisent automatiquement la nouvelle architecture réseau. Les projets existants peuvent contenir des instances Cloud SQL datant de plus de deux ans et utilisant toujours l'ancienne architecture réseau. Par conséquent, toutes les instances d'un projet existant doivent être mises à niveau avant que les nouvelles instances de ce projet puissent commencer à utiliser la nouvelle architecture réseau.
Toutes les nouvelles instances Cloud SQL sont-elles créées dans la nouvelle architecture réseau ?
Par défaut, les instances Cloud SQL créées dans des projets créés après août 2021 utilisent la nouvelle architecture réseau. Si vous souhaitez créer une instance dans un projet créé avant août 2021 et utiliser la nouvelle architecture de réseau, procédez comme suit :
Mettez à jour toutes les instances existantes de ce projet vers la nouvelle architecture réseau.
Si vous disposez d'un contrat d'assistance Google Cloud, créez une demande d'assistance pour remplacer l'architecture réseau par défaut du projet par la nouvelle.
Si vous n'avez pas de contrat d'assistance, créez votre instance, puis mettez-la à niveau vers la nouvelle architecture réseau.
Une fois la valeur par défaut du projet modifiée, vous pouvez créer des instances avec la nouvelle architecture réseau dans ce projet.
Si vous ne modifiez pas l'architecture réseau par défaut de votre projet, toutes les nouvelles instances de ce projet utiliseront l'ancienne architecture réseau. Vous devez ensuite mettre à niveau chacune de ces instances individuellement vers la nouvelle architecture réseau.
Est-il possible de mettre à jour toutes les instances d'un projet à l'aide d'une seule commande ?
Non, la mise à niveau vers la nouvelle architecture réseau est basée sur chaque instance.
L'instance répliquée est-elle automatiquement mise à niveau si je mets à niveau l'instance principale ?
Non, la mise à niveau vers la nouvelle architecture réseau est basée sur chaque instance individuelle. Chaque instance répliquée est traitée comme une instance distincte et doit être mise à jour séparément. Cela signifie que si l'instance principale est mise à niveau et que l'instance répliquée utilise l'ancienne architecture réseau, celle-ci n'est pas affectée. L'inverse est également vrai. Si vous mettez à niveau une instance répliquée, l'instance principale n'est pas affectée.
J'ai reçu une notification indiquant que l'architecture réseau de mes instances Cloud SQL allait être mise à niveau. Que dois-je faire ?
Aucune action spéciale n'est requise de votre part.
Dans certains cas, lorsque la mise à niveau automatique a lieu sur un réseau privé, la demande est temporairement refusée. Pour contourner ce problème, vous pouvez mettre à niveau vous-même l'architecture réseau de votre instance en suivant la procédure décrite dans Mettre à niveau l'architecture réseau d'une seule instance Cloud SQL.
Pourquoi ne puis-je pas mettre à niveau l'architecture réseau de mon instance zonale ?
Si votre instance est configurée avec une disponibilité zonale et qu'elle a ignoré son dernier événement de maintenance programmé, il est possible qu'elle ne n'accepte pas la mise à niveau vers la nouvelle architecture réseau. Pour contourner ce problème, activez la haute disponibilité pour votre instance, puis mettez à niveau l'architecture réseau. Après la mise à niveau, vous pouvez rétablir la disponibilité zonale dans la configuration de l'instance.
Lorsque j'essaie de mettre à niveau mon instance, le message d'erreur "En dehors de la plage d'adresses IP réservées" s'affiche. Que dois-je faire ?
Pour utiliser des instances Cloud SQL dans un réseau VPC avec une adresse IP privée, allouez des plages d'adresses IP lorsque vous configurez l'accès aux services privés pour le réseau VPC.
Par exemple, si une plage d'adresses IP allouée est modifiée ou supprimée, vous pouvez rencontrer une erreur semblable à celle-ci :
Network architecture upgrade not allowed for private-ip instance PROJECT_ID:INSTANCE_NAME
whose IP address range 10.0.0.0/24
is outside the reserved IP address range for
private services access. Re-allocate the IP address range for private services access and retry.
Dans cet exemple, la plage d'adresses IP allouée d'origine est nommée google-managed-services-VPC_NETWORK_NAME
, et la plage d'adresses IP allouée d'origine est 10.0.0.0/16
.
Vous créez ensuite une instance avec une adresse IP privée de 10.0.0.1
.
Si la plage d'adresses IP de google-managed-services-VPC_NETWORK_NAME
est supprimée ou mise à jour pour faire référence à une plage de 10.1.0.0/16
, cette plage ne couvre pas l'adresse IP privée 10.0.0.1
de l'instance.
Ensuite, lorsque vous essayez de mettre à niveau l'architecture réseau de votre instance, vous rencontrez l'erreur outside the reserved IP address range
.
Pour résoudre ce problème, suivez la procédure décrite dans la section Configurer l'accès aux services privés pour Cloud SQL.
Réallouez une plage d'adresses IP incluant l'adresse IP de votre instance dans les plages allouées pour l'accès aux services privés.
Vous pouvez au moins allouer la plage d'adresses IP signalée dans votre message d'erreur (dans l'exemple précédent, 10.0.0.0/24
).
Ensuite, relancez la mise à niveau de l'architecture réseau.
Étape suivante
- Apprenez-en plus sur Private Service Connect.
- Apprenez-en plus sur Assured Workloads.
- Découvrez comment configurer l'accès privé aux services pour Cloud SQL.
- Apprenez-en plus sur Database Migration Service vers AlloyDB pour PostgreSQL