Questo documento spiega come ricreare un'istanza Apigee senza incorrere in tempi di inattività della gestione delle API o perdita di dati.
Introduzione
Le istanze Apigee create prima del 25 gennaio 2022 non dispongono di spazio di indirizzi
del protocollo internet (IP) sufficiente per consentire lo scalabilità dei carichi di lavoro Apigee per gestire l'aumento del traffico API e/o
per consentirti di aggiungere più di 10 ambienti a un'istanza.
Il 24 gennaio 2022, Apigee ha introdotto
un miglioramento per risolvere questo problema. Il miglioramento riduce l'intervallo IP richiesto
per il peering della tua rete VPC con Apigee e utilizza
IP pubblici utilizzati
privatamente (PUPI) per consentire ai carichi di lavoro di scalare fino a limiti più elevati.
Che cosa devi fare
Se hai un'istanza Apigee creata prima del 25 gennaio 2022, Apigee consiglia
di sostituirla con una nuova istanza, come spiegato in questo documento. Se non ricrei l'istanza precedente, potresti riscontrare problemi di scalabilità e il numero di ambienti che puoi aggiungere a un'istanza continuerà a essere limitato a 10. Inoltre, la tua istanza potrebbe smettere
di ricevere aggiornamenti regolari, il che influirà sui servizi API.
Determinare la data di creazione di un'istanza
Per determinare la data di creazione di un'istanza Apigee:
Elenca i dettagli di tutte le istanze Apigee nella tua organizzazione:
Per ogni istanza, controlla il valore del campo createdAt decodificando il timestamp Unix
per ottenere la data.
Se un'istanza è stata creata il 25 gennaio 2022 o dopo questa data, non devi fare
altro per quell'istanza.
Se un'istanza è stata creata prima del 25 gennaio 2022, ti consigliamo di sostituirla,
come descritto in questo documento.
Informazioni sulla procedura di ricreazione
Per ricreare un'istanza con tempi di inattività pari a zero e senza perdita di dati, devi prima creare una nuova
istanza in una nuova regione (espansa) e indirizzare il traffico API a questa nuova istanza. Quindi, puoi
svuotare l'istanza esistente, eliminarla e ricrearla nella stessa regione di quella
che hai eliminato.
Apigee ha fornito un insieme di script che eseguono tutti i passaggi necessari per ricreare e configurare
un'istanza. Forniamo un link agli script più avanti in questo documento.
Prerequisiti
Prima di iniziare i passaggi di ricreazione dell'istanza:
Devi avere familiarità con la modalità di creazione dell'istanza Apigee. I passaggi
per ricreare l'istanza dipendono dalla conoscenza dei dettagli sulla configurazione dell'istanza originale.
Devi avere il diritto di eseguire il provisioning di Apigee in almeno due
regioni. Se non hai la certezza di disporre di diritti sufficienti, segui i passaggi per creare un'istanza in una
nuova regione. Se non disponi del diritto appropriato, il tentativo non andrà a buon fine e verrà visualizzato un errore di limite. In questo caso,
contatta l'assistenza Apigee per ottenere un'eccezione temporanea per aumentare
il limite della tua regione. Se hai già diritto a due o più regioni, ti consigliamo di
contattarci per ottenere l'eccezione temporanea ed evitare di eseguire il workload di produzione
con un'istanza ridotta durante il processo di ricreazione.
Per creare la nuova istanza, il progetto deve avere spazio per intervalli IP aggiuntivi di blocchi /22 e
/28. Vedi anche
Dimensionamento della rete.
Puoi rilasciare questi intervalli quando la regione aggiuntiva viene eliminata al termine della ricreazione dell'istanza. Tieni presente che il blocco
/22 è configurabile da te. Puoi scegliere il blocco /28 che Apigee utilizzerà oppure, se non scegli, viene assegnato automaticamente da Apigee da qualsiasi blocco disponibile.
Ricreazione dell'istanza
Apigee ha fornito un insieme di script che eseguono tutti i passaggi necessari per ricreare un'istanza.
Il traffico in direzione nord si riferisce al traffico API dai client esterni o interni ad Apigee tramite un bilanciatore del carico. Quando un'istanza viene eliminata e ricreata, l'indirizzo IP in ingresso e l'ID collegamento al servizio Private Service Connect (PSC) dell'istanza cambieranno per la nuova istanza.
Gli script forniti riconfigurano il backend del bilanciatore del carico per te. Se il routing di rete dell'istanza è stato configurato con un gruppo di istanze gestite (MIG), uno script fornito ricrea il MIG che funge da proxy per il traffico verso l'endpoint Apigee e lo collega come backend al servizio di backend esistente. Se il routing è stato configurato
con Private Service Connect (PSC), uno script ricrea il gruppo di endpoint di rete (NEG) per
il collegamento dell'endpoint di servizio di Apigee e collega il nuovo NEG come backend al servizio di backend esistente.
Tieni presente che non dovrai modificare i record del nome host in nessun
gruppo di ambienti
associato alla vecchia istanza.
Modifiche in direzione sud
Il traffico in uscita si riferisce al traffico API da Apigee ai servizi di destinazione del proxy API.
Quando un'istanza viene eliminata e ricreata, tutti gli indirizzi IP NAT in uscita dedicati vengono rilasciati. Pertanto, devi prenotare e attivare nuovi indirizzi IP per il NAT e riconfigurare
i firewall/l'inserimento nella lista consentita sugli endpoint di destinazione. Uno degli script forniti gestisce
questa riconfigurazione NAT per te, se necessario.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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."]]
