Ce document explique comment recréer une instance Apigee sans entraîner de temps d'arrêt pour la gestion des API ni de pertes de données.
Introduction
Les instances Apigee créées avant le 25 janvier 2022 ne disposent pas d'un espace d'adressage de protocole Internet (IP) suffisant pour permettre aux charges de travail Apigee d'évoluer afin de gérer l'augmentation du trafic d'API et/ou d'ajouter plus de 10 environnements dans une instance
Le 24 janvier 2022, Apigee a apporté une amélioration pour résoudre ce problème. L'amélioration réduit la plage d'adresses IP requise pour appairer votre réseau VPC avec Apigee et utilise des adresses IP publiques utilisées en mode privé (PUPI) pour permettre aux charges de travail d'évoluer jusqu'à des limites plus élevées.
Que faire ?
Si vous disposez d'une instance Apigee créée avant le 25 janvier 2022, Apigee recommande de la remplacer par une nouvelle instance, comme expliqué dans ce document. Si vous ne recréez pas l'ancienne instance, vous risquez de rencontrer des problèmes de scaling et le nombre d'environnements que vous pouvez ajouter à une instance restera limité à 10. En outre, votre instance peut cesser de recevoir des mises à jour régulières, ce qui aura une incidence sur les services d'API.
Déterminer la date de création d'une instance
Pour déterminer la date de création d'une instance Apigee, procédez comme suit :
Répertoriez les détails de toutes les instances Apigee de votre organisation :
Pour chaque instance, vérifiez la valeur du champ createdAt en décodant l'horodatage Unix pour obtenir la date.
Si une instance a été créée le 25 janvier 2022 ou après cette date, vous n'avez rien d'autre à faire.
Si une instance a été créée avant le 25 janvier 2022, nous vous recommandons de la remplacer, comme indiqué dans ce document.
À propos de la procédure de recréation
Pour recréer une instance sans temps d'arrêt et sans perte de données, vous devez d'abord créer une instance dans une nouvelle région (étendue) et diriger le trafic des API vers cette nouvelle instance. Vous pouvez ensuite drainer l'instance existante, la supprimer et la recréer dans la même région.
Apigee a fourni un ensemble de scripts qui effectuent toutes les étapes requises pour recréer et configurer une instance. Un lien vers ces scripts est fourni dans la suite du présent document.
Prérequis
Avant de commencer les étapes de recréation d'instances :
Vous devez savoir comment l'instance Apigee a initialement été créée. Les étapes permettant de recréer l'instance dépendent de votre niveau de connaissance de la configuration de l'instance d'origine.
Vous devez être autorisé à provisionner Apigee dans au moins deux régions. Si vous n'êtes pas sûr de disposer de droits suffisants, suivez les étapes suivantes pour créer une instance dans une nouvelle région. Si vous ne disposez pas des droits d'accès appropriés, la tentative échoue avec une erreur de limite. Dans ce cas, contactez l'assistance Apigee pour obtenir une exception temporaire permettant d'augmenter la limite de votre région. Si vous êtes déjà autorisé dans au moins deux régions, nous vous recommandons tout de même de demander l'exception temporaire pour éviter d'exécuter votre charge de travail de production avec une instance réduite pendant le processus de recréation.
Vous devez disposer d'un espace suffisant dans votre projet pour les plages d'adresses IP supplémentaires des blocs /22 et /28 afin de pouvoir créer une instance. Consultez également la section Dimensionnement du réseau.
Vous pouvez libérer ces plages lorsque la région supplémentaire est supprimée une fois la recréation de l'instance terminée. Notez que le bloc /22 est configurable par vous-même. Vous pouvez choisir le bloc /28 qu'Apigee utilisera ou laisser Apigee choisir automatiquement l'un des blocs disponibles.
Recréer l'instance
Apigee a fourni un ensemble de scripts qui effectuent toutes les étapes requises pour recréer une instance.
Northbound fait référence au trafic d'API en provenance de clients externes ou internes et à destination d'Apigee qui passe par un équilibreur de charge. Lorsqu'une instance est supprimée et recréée, l'adresse IP Northbound et l'ID de rattachement de service Private Service Connect (PSC) changent pour la nouvelle instance.
Les scripts fournis reconfigurent le backend de l'équilibreur de charge à votre place. Si le routage réseau de l'instance a été configuré avec un groupe d'instances géré (MIG), un script fourni recrée le MIG qui relaie le trafic au point de terminaison Apigee et associe le MIG en tant que backend du service de backend existant. Si le routage a été configuré avec Private Service Connect (PSC), un script recrée le groupe de points de terminaison du réseau (NEG) pointant vers le rattachement de point de terminaison du service Apigee et associe ce nouveau NEG en tant que backend du service de backend existant.
Notez que vous n'aurez pas à modifier les enregistrements de nom d'hôte dans les groupes d'environnements associés à l'ancienne instance.
Modifications Southbound
Southbound fait référence au trafic d'API provenant d'Apigee et à destination de vos services cibles de proxy d'API.
Lorsqu'une instance est supprimée et recréée, toutes les adresses IP NAT Southbound dédiées sont libérées. Vous devez donc réserver et activer de nouvelles adresses IP pour votre NAT, puis reconfigurer vos pare-feu/listes d'autorisation sur vos points de terminaison cibles. L'un des scripts fournis gère cette reconfiguration NAT pour vous si nécessaire.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (UTC)."],[[["\u003cp\u003eThis document guides Apigee users with instances created before January 25, 2022, to replace them due to IP scaling limitations and to ensure continued updates and full API service functionality.\u003c/p\u003e\n"],["\u003cp\u003eRecreating an older Apigee instance is recommended to resolve scaling issues and environment limitations, otherwise, there is potential to experience scaling issues or limitations on the number of environments.\u003c/p\u003e\n"],["\u003cp\u003eThe recreation process involves creating a new instance in an expanded region, directing traffic to it, draining the old instance, and then recreating it in the original region, which enables zero downtime and no data loss.\u003c/p\u003e\n"],["\u003cp\u003eApigee provides a set of scripts to automate the instance recreation and reconfiguration process, including managing load balancers and, if needed, southbound NAT IP addresses.\u003c/p\u003e\n"],["\u003cp\u003ePrior to starting the recreation, users must be familiar with their instance's initial configuration, have entitlements to provision Apigee in multiple regions, and ensure sufficient IP ranges are available.\u003c/p\u003e\n"]]],[],null,["# Recreating an Apigee instance with zero downtime\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Important:** This topic only applies to organizations that were created with VPC peering enabled. See also [Apigee networking options](/apigee/docs/api-platform/get-started/networking-options).\n\n\nThis document explains how to recreate an Apigee\n[instance](/apigee/docs/api-platform/get-started/basic-concepts#instance)\nwithout incurring API management downtime or data loss.\n\nIntroduction\n------------\n\n\nApigee instances created before January 25, 2022, do not have sufficient internet protocol (IP)\naddress space to allow Apigee workloads to scale to handle increasing API traffic and/or\nto allow you to add more than 10 environments to an instance.\n\n\nOn January 24, 2022, Apigee [introduced\nan enhancement](/apigee/docs/release-notes#January_24_2022) to address this problem. The enhancement reduces the IP range required\nto peer your VPC network with Apigee and uses\n[privately\nused public IPs](https://cloud.google.com/architecture/configuring-privately-used-public-ips-for-GKE) (PUPI) to allow workloads to scale to higher limits.\n\nWhat you need to do\n-------------------\n\n\nIf you have an Apigee instance that was created before January 25, 2022, Apigee recommends\nthat you replace it with a new instance, as explained in this document. If you do not\nrecreate the older instance, you may experience scaling issues and the number of environments\nyou can add to an instance will continue to be limited to 10. Also, your instance may stop\ngetting regular updates which will impact the API services.\n\nDetermining an instance's creation date\n---------------------------------------\n\n\nTo determine the creation date of an Apigee instance:\n\n1. List details for all of the Apigee instances in your organization: \n\n AUTH=\"Authorization: Bearer $(gcloud auth print-access-token)\"\n\n curl -i -X GET -H \"$AUTH\" \\\n \"https://apigee.googleapis.com/v1/organizations/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/instances\"\n\n\n Where:\n - `AUTH` is the Authentication header with a bearer token. Be sure the default project for `gcloud` is set to the `PROJECT_ID`.\n - `PROJECT_ID` is the Cloud project ID that you created when you provisioned Apigee.\n\n\n Sample output: \n\n ```verilog\n {\n \"instances\": [\n {\n \"name\": \"us-west1\",\n \"location\": \"us-west1\",\n \"host\": \"10.117.200.2\",\n \"port\": \"443\",\n \"createdAt\": \"1642698826000\",\n \"lastModifiedAt\": \"1655745226000\",\n \"diskEncryptionKeyName\": \"projects/myproject/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key\",\n \"state\": \"ACTIVE\",\n \"peeringCidrRange\": \"SLASH_22\",\n \"runtimeVersion\": \"1-8-0-apigee-33\",\n \"ipRange\": \"10.117.200.0/22,10.81.174.192/28\",\n \"consumerAcceptList\": [\n \"myproject\"\n ],\n \"serviceAttachment\": \"projects/z11f28c6f3104980e-tp/regions/us-west1/serviceAttachments/apigee-us-west1-lbko\"\n }\n ]\n }\n ```\n2. For each instance, check the value of the `createdAt` field by decoding the Unix timestamp to get the date.\n - If an instance was created on or after January 25, 2022, then you do not have to do anything further for that instance.\n - If an instance was created before January 25, 2022, we recommend you replace the instance, as discussed in this document.\n\nAbout the recreation procedure\n------------------------------\n\n\nTo recreate an instance with zero downtime and no data loss, you need to first create a new\ninstance in a new (expanded) region and direct API traffic to that new instance. Then, you\ncan drain down the existing instance, delete it, and recreate it in the same region as the\none you deleted.\n\n\nApigee has provided a set of scripts that perform all of the required steps to recreate and configure\nan instance. We provide a link to the scripts later in this document.\n\nPrerequisites\n-------------\n\n\nBefore you begin the instance recreation steps:\n\n- You must be familiar with how the Apigee instance was created in the first place. The steps for recreating the instance depend on you knowing details about how the original instance was configured.\n- You must be entitled to provision Apigee in at least two regions. If you aren't sure if you have sufficient entitlement, follow the steps to create an instance in a new region. If you do not have the proper entitlement the attempt will fail with a limit error. In that case, contact Apigee support to get a temporary exception to increase your region limit. If you are already entitled for two or more regions, we recommend you reach out to get the temporary exception to avoid running your production workload with a reduced instance during the recreation process. The process of recreating an instance includes deleting the old instance. If you do not follow the step to create a new instance in an expanded region, you will incur downtime and runtime data loss, including KVMs, cache data, quota data, and KMS data. Therefore, region expansion is mandatory to recreate an instance without downtime or data loss.\n- You must have room in your project for additional IP ranges of **/22** and **/28** blocks to create the new instance. See also [Network sizing](https://cloud.google.com/apigee/docs/api-platform/system-administration/peering-ranges#sizing). You can release these ranges when the additional region is deleted after instance recreation is complete. Note that the **/22** block is configurable by you. You can choose which **/28** block Apigee will use, or if you don't choose, it is auto-assigned by Apigee from any available block.\n\nRecreating the instance\n-----------------------\n\n\nApigee has provided a set of scripts that perform all of the required steps to recreate an instance.\n\n1. Be sure you have met the [prerequisites](#prerequisites).\n2. [Download the scripts](https://github.com/apigee/apigee-x-pupi-migration) from GitHub.\n3. Follow the steps in the Git repository's [README](https://github.com/apigee/apigee-x-pupi-migration#readme) file to create the new instance.\n4. Reconfigure the northbound and southbound connections to point to the new Apigee instance. See [About northbound changes](#about-northbound-changes) and [About southbound changes](#about-southbound-changes).\n\n### About northbound changes\n\n\nNorthbound refers to API traffic from external or internal clients to Apigee through a load\nbalancer. When an instance is deleted and recreated, the northbound IP address and\n[Private\nService Connect](/apigee/docs/api-platform/system-administration/northbound-networking-psc) (PSC) service attachment ID of the instance will change for the new instance.\n\n\nThe provided scripts reconfigure the load balancer's\nbackend for you. If the instance's [network routing](/apigee/docs/api-platform/get-started/install-cli#configure-routing)\nwas configured with a managed instance\ngroup (MIG), a provided script recreates the MIG that proxies traffic to the Apigee endpoint,\nand attaches the MIG as a backend to the existing backend service. If routing was configured\nwith private service connect (PSC), a script recreates the network endpoint group (NEG) to\nApigee's service endpoint attachment and attaches the new NEG as a backend to the existing\nbackend service.\n\nNote that you will not have to change the hostname records in any\n[environment groups](/apigee/docs/api-platform/fundamentals/environments-overview)\nassociated with the old instance.\n\n### Southbound changes\n\n\nSouthbound refers to API traffic from Apigee to your API proxy target services.\n\n\n| **Note:** Southbound changes are only needed if you used NAT IPs for Apigee instances, as described in [Provisioning\n| NAT IPs](/apigee/docs/api-platform/security/nat-provisioning).\n\n\nWhen an instance is deleted and recreated, any dedicated southbound NAT IP addresses will be\nreleased. So, you must reserve and activate new IP addresses for your NAT and reconfigure\nyour firewalls/allowlisting on your target endpoints. One of the provided scripts handles\nthis NAT reconfiguration for you, if needed."]]
