Condividi tramite

Eseguire la migrazione di un'istanza di Gestione API inserita nella rete virtuale ospitata sulla piattaforma stv1 alla piattaforma stv2

  • Articolo

SI APPLICA A: Sviluppatore | Premium

Questo articolo illustra la procedura per eseguire la migrazione di un'istanza di Gestione API ospitata nella piattaforma di calcolo stv1 sul posto alla piattaforma stv2 quando l'istanza è inserita (distribuita) in una rete virtuale esterna o interna. Scoprire se è necessario eseguire questa operazione.

Nota

Novità di agosto 2024: per facilitare la migrazione dell'istanza inserita nella rete virtuale, sono state migliorate le opzioni di migrazione nel portale. È ora possibile eseguire la migrazione dell'istanza sul posto e mantenere la stessa subnet e lo stesso indirizzo IP.

Per un'istanza inserita dalla rete virtuale, sono disponibili le seguenti opzioni di migrazione:

  • Opzione 1: mantenere la stessa subnet: eseguire la migrazione dell'istanza sul posto e mantenere la configurazione della subnet esistente delle istanze. È possibile scegliere se mantenere l'indirizzo VIP originale dell'istanza di Gestione API (scelta consigliata) oppure se generarne uno nuovo.

  • Opzione 2: passare a una nuova subnet: eseguire la migrazione dell'istanza specificando una subnet diversa nella stessa rete virtuale o in una rete virtuale diversa. Dopo la migrazione, eseguire facoltativamente la migrazione alla subnet originale dell'istanza. Il processo di migrazione modifica gli indirizzi VIP dell'istanza. Dopo la migrazione, è necessario aggiornare tutte le dipendenze di rete, tra cui DNS, regole del firewall e reti virtuali, per usare i nuovi indirizzi VIP.

Se è necessario eseguire la migrazione di un'istanza di Gestione API non inserita nella rete virtuale ospitata nella piattaforma stv1, vedere Eseguire la migrazione di un'istanza di Gestione API non inserita nella rete virtuale alla piattaforma stv2.

Importante

Il supporto per le istanze di Gestione API ospitate nella piattaforma stv1 verrà ritirato. In Azure globale, la data di ritiro è il 31 agosto 2024. In Azure per enti pubblici e in Azure gestito da 21Vianet (Azure in Cina), la data di ritiro è il 24 febbraio 2025. Se sono presenti istanze ospitate sulla piattaforma stv1, eseguirne la migrazione sulla piattaforma stv2 prima della data di ritiro per evitare interruzioni del servizio.

Attenzione

  • La migrazione dell'istanza di Gestione API alla piattaforma stv2 è un'operazione che richiede tempo.
  • La migrazione a stv2 non è reversibile.

Cosa accade durante la migrazione?

La migrazione della piattaforma Gestione API da stv1 a stv2 comporta l'aggiornamento del solo calcolo sottostante e non ha alcun impatto sulla configurazione del servizio o dell'API conservata nel livello di archiviazione.

  • Il processo di aggiornamento comporta la creazione di un nuovo ambiente di calcolo in parallelo all'ambiente di calcolo precedente, che può richiedere fino a 45 minuti. Pianificare tempi più lunghi per distribuzioni multi-area e in scenari che comportano la modifica della subnet più di una volta.
  • Lo stato di Gestione API nel portale sarà In fase di aggiornamento.
  • Per determinate opzioni di migrazione, è possibile scegliere di mantenere l'indirizzo VIP o verrà generato un nuovo indirizzo VIP pubblico.
  • Per gli scenari di migrazione in cui viene generato un nuovo indirizzo VIP:
    • Azure gestisce la migrazione.
    • Il DNS del gateway punta ancora all'ambiente di calcolo precedente se è in so un dominio personalizzato.
    • Se il DNS personalizzato non è in uso, il DNS del gateway e del portale punta immediatamente al nuovo ambiente di calcolo.
    • Per un'istanza in modalità rete virtuale interna, il cliente gestisce il DNS, quindi le voci DNS continuano a puntare al calcolo precedente fino a quando non viene aggiornato dal cliente.
    • È il DNS che punta al nuovo calcolo o al precedente, quindi non si verificano tempi di inattività per le API.
    • Le modifiche alle regole del firewall, se presenti, sono necessarie per consentire alla nuova subnet di calcolo di raggiungere i back-end.
    • Al termine della migrazione, l'ambiente di calcolo precedente viene dismesso automaticamente dopo un breve periodo. Quando si passa a una nuova subnet, usando il pannello Migrazione della piattaforma nel portale, è possibile abilitare un'impostazione di migrazione per mantenere il vecchio gateway per 48 ore. L'opzione di ritardo di 48 ore è disponibile solo per i servizi inseriti nella rete virtuale.

Prerequisiti

Altri prerequisiti sono specifici per le opzioni di migrazione riportate nelle sezioni seguenti.

Opzione 1: eseguire la migrazione e mantenere la stessa subnet

È possibile eseguire la migrazione dell'istanza di Gestione API alla piattaforma stv2 mantenendo la configurazione della subnet esistente e semplificando così la migrazione. È possibile eseguire la migrazione usando il pannello Migrazione della piattaforma nel portale di Azure o nell'API REST di migrazione a Stv2.

Prerequisiti

  • È necessario collegare un gruppo di sicurezza di rete a ogni subnet e configurare le regole del gruppo di sicurezza di rete per la Gestione API nella piattaforma stv2. Di seguito sono riportate le impostazioni minime di connettività:

    • In uscita in Archiviazione di Azure sulla porta 443
    • In uscita in Azure SQL sulla porta 1433
    • In uscita in Azure Key Vault sulla porta 443
    • In ingresso da Azure Load Balancer sulla porta 6390
    • In ingresso dal tag del servizio ApiManagement sulla porta 3443
    • In ingresso sulla porta 80/443 per i client che chiamano il servizio Gestione API
    • La subnet deve avere endpoint di servizio abilitati per Archiviazione di Azure, Azure SQL e Azure Key Vault

  • Lo spazio degli indirizzi di ogni subnet esistente deve essere sufficientemente ampio da ospitare una copia del servizio esistente accanto al servizio esistente durante la migrazione.

  • Altre considerazioni sulla rete:

    • Disattivare tutte le regole di scalabilità automatica configurate per le istanze di Gestione API distribuite nella subnet. Le regole di scalabilità automatica possono interferire con il processo di migrazione.
    • Se nella stessa subnet sono presenti più istanze di Gestione API, eseguire la migrazione di ogni istanza in sequenza. È consigliabile eseguire tempestivamente la migrazione di tutte le istanze nella subnet per evitare potenziali problemi con le istanze ospitate in piattaforme diverse nella stessa subnet.

Opzioni dell'indirizzo IP pubblico: migrazione della stessa subnet

È possibile scegliere se mantenere l'indirizzo VIP originale dell'istanza di Gestione API (scelta consigliata) oppure se generarne uno nuovo.

  • Mantenere l'indirizzo IP virtuale: se si mantiene l'indirizzo VIP in una rete virtuale in modalità esterna, le richieste API possono continuare a rispondere durante la migrazione (vedere Tempo di inattività previsto); per una rete virtuale in modalità interna è previsto un tempo di inattività temporaneo. La configurazione dell'infrastruttura (ad esempio domini personalizzati, percorsi e certificati della CA) verrà bloccata per 45 minuti. Non sono necessarie altre configurazioni dopo la migrazione.

    Con questa opzione, l'ambiente di calcolo stv1 viene eliminato definitivamente al termine della migrazione. Non è possibile conservarlo temporaneamente.

    L'immagine seguente mostra una panoramica generale di cosa accade quando viene mantenuto l'indirizzo IP.

    Diagramma della migrazione sul posto alla stessa subnet e del mantenimento dell'indirizzo IP.

  • Nuovo indirizzo IP virtuale: se si sceglie questa opzione, Gestione API genera un nuovo indirizzo VIP per l'istanza. Tuttavia, le richieste API rimangono reattive durante la migrazione. La configurazione dell'infrastruttura (ad esempio domini personalizzati, percorsi e certificati CA) verrà bloccata per 30 minuti. Dopo la migrazione, sarà necessario aggiornare eventuali dipendenze di rete, tra cui DNS, regole del firewall e reti virtuali in modo che usino il nuovo indirizzo VIP.

    Con questa opzione, l'ambiente di calcolo stv1 viene conservato per un breve periodo per impostazione predefinita al termine della migrazione in modo da consentire la convalida dell'istanza di cui è stata eseguita la migrazione e confermare la configurazione di rete e DNS.

    L'immagine seguente mostra una panoramica generale di cosa accade quando viene generato un nuovo indirizzo IP.

    Diagramma della migrazione sul posto alla stessa subnet e della generazione di un nuovo indirizzo IP.

Indirizzo IP precreato per la migrazione

Per le istanze di Gestione API raggiungibili tramite un indirizzo IP pubblico, Gestione API precrea un indirizzo IP pubblico per il processo di migrazione. Trovare l'indirizzo IP precreato nell'output JSON delle proprietà della tua istanza di Gestione API. In customProperties, l'indirizzo IP precreato è il valore della proprietà Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps. Per una distribuzione multi-area, il valore è un elenco delimitato da virgole di indirizzi IP creati in precedenza.

Usare l'indirizzo IP precreato (o gli indirizzi) per gestire il processo di migrazione:

  • Quando si esegue la migrazione e si mantiene l'indirizzo VIP, l'indirizzo IP precreato viene assegnato temporaneamente alla nuova distribuzione stv2, prima che l'indirizzo IP originale venga assegnato alla distribuzione stv2. Ad esempio, se sono presenti regole del firewall che limitano l'accesso all'istanza di Gestione API, ad esempio è possibile aggiungere l'indirizzo IP precreato all'elenco consentiti per mantenere la continuità dell'accesso client durante la migrazione. Al termine della migrazione, è possibile rimuovere l'indirizzo IP precreato dall'elenco elementi consentiti.
  • Quando si esegue la migrazione e si genera un nuovo indirizzo VIP, l'indirizzo IP precreato viene assegnato alla nuova distribuzione stv2 durante la migrazione e viene mantenuto al termine della migrazione. Usare l'indirizzo IP precreato per aggiornare le dipendenze di rete, ad esempio le regole DNS e firewall, in modo che punti al nuovo indirizzo IP.

Tempo di inattività previsto e conservazione delle risorse dell'ambiente di calcolo

Quando si esegue la migrazione di un'istanza inserita nella rete virtuale e si mantiene la stessa configurazione della subnet, è previsto un tempo di inattività minimo o nullo per il gateway API. La tabella seguente riepiloga i tempi di inattività previsti e la conservazione delle risorse dell'ambiente di calcolo stv1 per ogni scenario di migrazione mantenendo la stessa subnet:

Modalità rete virtuale Opzione IP pubblico Tempo di inattività previsto Conservazione delle risorse dell'ambiente di calcolo stv1
Esterno Mantenere l'indirizzo VIP Nessun tempo di inattività; il traffico viene gestito in un indirizzo IP temporaneo per un massimo di 20 minuti durante la migrazione alla nuova distribuzione stv2 Nessuna conservazione
Esterno Nuovo indirizzo VIP Nessun tempo di inattività Conservato per impostazione predefinita per 15 minuti per consentire l'aggiornamento delle dipendenze di rete
Internal Mantenere l'indirizzo VIP Tempo di inattività per circa 20 minuti durante la migrazione mentre l'indirizzo IP esistente viene assegnato alla nuova distribuzione stv2. Nessuna conservazione
Internal Nuovo indirizzo VIP Nessun tempo di inattività Conservato per impostazione predefinita per 15 minuti per consentire di aggiornare le dipendenze di rete. Può essere esteso fino a 48 ore quando si usa il portale

Procedura di migrazione: mantenere la stessa subnet

  1. Nel portale di Azure accedere all'istanza di Gestione API.
  2. Nel menu a sinistra, in Impostazioni, selezionare Migrazione della piattaforma.
  3. In Selezionare un'opzione di migrazione selezionare Mantieni la stessa subnet.
  4. In Scegliere un'opzione per l'indirizzo IP selezionare una delle due opzioni per l'indirizzo IP.

    Nota

    Se la rete virtuale è in modalità esterna, prendere nota dell'indirizzo IP pubblico precreato per il processo di migrazione. Usare questo indirizzo per configurare la connettività di rete per l'istanza sottoposta a migrazione.

  5. (Per le istanze inserite in modalità interna e di cui viene eseguita la migrazione a un nuovo indirizzo VIP) In Scegliere lo scenario in linea con i requisiti scegliere una delle due opzioni disponibili, a seconda che si voglia mantenere l'ambiente di calcolo stv1 originale per un determinato periodo dopo la migrazione.
  6. Selezionare Verifica per eseguire controlli automatizzati nella subnet. Se vengono rilevati problemi, modificare la configurazione della subnet ed eseguire di nuovo i controlli. Per altre dipendenze di rete, ad esempio DNS e regole del firewall, controllare manualmente.
  7. Confermare che si vuole eseguire la migrazione e selezionare Avvia migrazione. Lo stato dell'istanza di Gestione API passa a In fase di aggiornamento. Il completamento di questo processo richiede circa 45 minuti. Quando lo stato passa a Online, la migrazione è stata completata.

Opzione 2: eseguire la migrazione e passare alla nuova subnet

Usando il portale di Azure, è possibile eseguire la migrazione dell'istanza specificando una subnet diversa nella stessa rete virtuale o in una rete virtuale diversa. Dopo la migrazione, eseguire facoltativamente la migrazione alla subnet originale dell'istanza.

L'immagine seguente mostra una panoramica generale di cosa accade durante la migrazione a una nuova subnet.

Diagramma della migrazione sul posto a una nuova subnet.

Prerequisiti

  • Una nuova subnet nella rete virtuale corrente, in ogni area in cui è distribuita l'istanza di Gestione API. In alternativa, configurare una subnet in una rete virtuale diversa nella stessa area e nella stessa sottoscrizione dell'istanza di Gestione API. È necessario collegare un gruppo di sicurezza di rete a ogni subnet e configurare le regole del gruppo di sicurezza di rete per la Gestione API nella piattaforma stv2.

  • (Facoltativo) Una nuova risorsa indirizzo IPv4 pubblico con SKU Standard nella stessa area e nella stessa sottoscrizione dell'istanza di Gestione API. Per informazioni dettagliate, vedere Prerequisiti per le connessioni di rete.

Importante

  • A partire da maggio 2024, la risorsa di indirizzo IP pubblico non è più necessaria durante la distribuzione (inserimento) di un'istanza di Gestione API in una rete virtuale in modalità interna o si esegue la migrazione della configurazione della rete virtuale interna a una nuova subnet. In modalità rete virtuale esterna la specifica di un indirizzo IP pubblico è facoltativa. Se non ne viene specificato uno, verrà automaticamente configurato e usato un indirizzo IP pubblico gestito da Azure per il traffico API di runtime. Specificare l'indirizzo IP pubblico solo se si vuole possedere e controllare l'indirizzo IP pubblico usato per le comunicazioni in ingresso o in uscita su Internet.
  • Attualmente, se si abilita la ridondanza della zona per un'istanza di Gestione API in una rete virtuale in modalità interna o esterna, è necessario specificare un nuovo indirizzo IP pubblico.

Procedura di migrazione: passare a una nuova subnet

  1. Nel portale di Azure accedere all'istanza di Gestione API.

  2. Nel menu a sinistra, in Impostazioni, selezionare Migrazione della piattaforma.

  3. In Selezionare un'opzione di migrazione selezionare Passa a una nuova subnet.

  4. In Scegliere lo scenario in linea con i requisiti scegliere una delle due opzioni disponibili, a seconda che si voglia mantenere l'ambiente di calcolo stv1 originale per un determinato periodo dopo la migrazione.

    Screenshot delle opzioni per mantenere l'ambiente di calcolo stv1 nel portale.

  5. In Definire le impostazioni di migrazione per ogni posizione:

    1. Selezionare una località in cui eseguire la migrazione.
    2. Selezionare Rete virtuale, Subnet e Indirizzo IP pubblico facoltativo a cui si vuole eseguire la migrazione.

    Screenshot della selezione delle impostazioni di migrazione della rete nel portale.

  6. In Verificare che la subnet soddisfi i requisiti di migrazione selezionare Verifica per eseguire controlli automatizzati nella subnet. Se vengono rilevati problemi, modificare la configurazione della subnet ed eseguire di nuovo i controlli. Per altre dipendenze di rete, ad esempio DNS e regole del firewall, controllare manualmente.

  7. Confermare che si vuole eseguire la migrazione e selezionare Esegui la migrazione. Lo stato dell'istanza di Gestione API passa a In fase di aggiornamento. Il completamento di questo processo richiede circa 45 minuti. Quando lo stato passa a Online, la migrazione è stata completata.

Se l'istanza di Gestione API viene distribuita in più aree, ripetere i passaggi precedenti per continuare a eseguire la migrazione delle impostazioni della rete virtuale per le località rimanenti dell'istanza.

(Facoltativo) Eseguire nuovamente la migrazione alla subnet originale

Se è stata eseguita la migrazione e si è passati a una nuova subnet, è possibile eseguire la migrazione alla subnet originale usata in ogni area. A tale scopo, aggiornare nuovamente la configurazione della rete virtuale, questa volta specificando la rete virtuale e la subnet originali in ogni area. Come nella migrazione precedente, prevedere un'operazione di lunga durata e la modifica dell'indirizzo VIP.

L'immagine seguente mostra una panoramica generale di cosa accade durante la migrazione alla subnet originale.

Diagramma della migrazione sul posto alla subnet originale.

Importante

Se la rete virtuale e la subnet sono bloccate (perché sono distribuite altre istanze di Gestione API basate sulla piattaforma stv1) o il gruppo di risorse in cui è distribuita la rete virtuale originale ha un blocco delle risorse, assicurarsi di rimuovere il blocco prima di eseguire la migrazione alla subnet originale. Attendere il completamento della rimozione del blocco prima di tentare la migrazione alla subnet originale. Altre informazioni.

Prerequisiti aggiuntivi

  • Subnet originale sbloccata, in ogni area in cui è distribuita l'istanza di Gestione API. Un gruppo di sicurezza di rete deve essere collegato alla subnet e devono essere configurate le regole del gruppo di sicurezza di rete per Gestione API.

  • (Facoltativo) Una nuova risorsa indirizzo IPv4 pubblico con SKU Standard nella stessa area e nella stessa sottoscrizione dell'istanza di Gestione API.

    Importante

    • A partire da maggio 2024, la risorsa di indirizzo IP pubblico non è più necessaria durante la distribuzione (inserimento) di un'istanza di Gestione API in una rete virtuale in modalità interna o si esegue la migrazione della configurazione della rete virtuale interna a una nuova subnet. In modalità rete virtuale esterna la specifica di un indirizzo IP pubblico è facoltativa. Se non ne viene specificato uno, verrà automaticamente configurato e usato un indirizzo IP pubblico gestito da Azure per il traffico API di runtime. Specificare l'indirizzo IP pubblico solo se si vuole possedere e controllare l'indirizzo IP pubblico usato per le comunicazioni in ingresso o in uscita su Internet.
    • Attualmente, se si abilita la ridondanza della zona per un'istanza di Gestione API in una rete virtuale in modalità interna o esterna, è necessario specificare un nuovo indirizzo IP pubblico.

Aggiornare la configurazione della rete virtuale

  1. Nel portale passare alla rete virtuale originale.
  2. Nel menu a sinistra selezionare Subnet, quindi la subnet originale.
  3. Verificare che gli indirizzi IP originali siano stati rilasciati da Gestione API. In IP disponibili prendere nota del numero di indirizzi IP disponibili nella subnet. Dovrebbero essere disponibili tutti gli indirizzi (ad eccezione degli indirizzi riservati di Azure). Se necessario, attendere il rilascio degli indirizzi IP.
  4. Passare all'istanza di Gestione API.
  5. Nel menu a sinistra, in Rete selezionare Rete virtuale.
  6. Selezionare la connessione di rete nel percorso da aggiornare.
  7. Selezionare la rete virtuale e la subnet originali. Facoltativamente, selezionare un nuovo indirizzo IP pubblico. Selezionare Applica.
  8. Se l'istanza di Gestione API è distribuita in più aree, continuare a configurare le impostazioni della rete virtuale per le località rimanenti dell'istanza.
  9. Nella barra di spostamento in alto selezionare Salva.

Dopo aver aggiornato la configurazione della rete virtuale, lo stato dell'istanza di Gestione API passa a In fase di aggiornamento. Il completamento di questo processo richiede circa 45 minuti. Quando lo stato passa a Online, la migrazione è stata completata.

Verificare la migrazione

Per verificare che la migrazione abbia avuto esito positivo, quando lo stato passa a Online, controllare la versione della piattaforma dell'istanza di Gestione API. Al termine della migrazione, il valore è stv2 o stv2.1.

Confermare le impostazioni prima della rimozione del gateway precedente

Per gli scenari in cui il gateway precedente viene conservato temporaneamente dopo la migrazione, il vecchio e il nuovo ambiente di calcolo creato durante la migrazione coesistono per un breve periodo di tempo, circa 15 minuti, che possono essere usati per convalidare la distribuzione e verificare che le applicazioni funzionino come previsto. Per determinati scenari, è facoltativamente possibile estendere il periodo di conservazione fino a 48 ore tramite un'impostazione del portale.

  • Durante questa finestra, il gateway precedente e quello nuovo sono entrambi online e gestiscono il traffico. Non vengono fatturati durante questo periodo.
  • Usare questa finestra per aggiornare eventuali dipendenze di rete, tra cui DNS, regole del firewall e reti virtuali in modo che usino il nuovo spazio indirizzi della subnet e l'indirizzo VIP.
  • Controllare inoltre lo stato della rete dell'istanza aggiornata per garantire la connettività dell'istanza con le relative dipendenze. Nel portale, nel menu a sinistra, in Distribuzione e infrastruttura, selezionare Rete>Stato rete. Se necessario, aggiornare le impostazioni, ad esempio le route definite dall'utente e le regole del gruppo di sicurezza di rete.
  • Dopo la finestra, il gateway precedente viene ritirato e il nuovo gateway è l'unico che gestisce il traffico.

Eseguire il ripristino automatico se la migrazione non riesce

Se si verifica un errore durante il processo di migrazione, l'istanza verrà automaticamente ripristinata alla piattaforma stv1. Se la migrazione ha esito positivo (la versione della piattaforma dell'istanza viene visualizzata come stv2 o stv2.1 e lo stato come Online), non è possibile eseguire il rollback alla piattaforma stv1.

Per assistenza in caso di migrazione non riuscita, contattare il supporto tecnico di Azure.

Se occorre eseguire manualmente il rollback, è consigliabile distribuire una nuova istanza di stv2 affiancata all'istanza originale di Gestione API.

Assistenza e supporto

Il supporto tecnico è a disposizione per assistere gli utenti nella migrazione alla piattaforma stv2 con interruzioni minime dei servizi.

In caso di domande, è possibile ottenere risposte rapide dagli esperti della community in Microsoft Q&A. Se hai un piano di supporto e ti serve supporto tecnico, crea una richiesta di supporto.

  1. Per il Riepilogo digitare una descrizione del problema, ad esempio "ritiro stv1".
  2. In Tipo di problema, selezionare Tecnico.
  3. In Sottoscrizione selezionare la propria sottoscrizione.
  4. In Servizio selezionare Servizi personali, quindi selezionare Servizio Gestione API.
  5. In Risorsa selezionare la risorsa di Azure per cui si sta creando una richiesta di supporto.
  6. Per Tipo di problema selezionare Amministrazione e gestione.
  7. Per Sottotipo del problema selezionare Aggiorna, Ridimensiona o Modifiche SKU.

Domande frequenti

  • Quali sono le informazioni necessarie per scegliere un percorso di migrazione?

    • Qual è la modalità di rete dell'istanza di Gestione API?
    • I domini personalizzati sono configurati?
    • È coinvolto un firewall?
    • Ci sono dipendenze note eseguite da upstream/downstream sugli indirizzi IP coinvolti?
    • Si tratta di una distribuzione in più aree?
    • È possibile modificare l'istanza esistente o è necessaria una configurazione parallela?
    • Può verificarsi un tempo di inattività?
    • La migrazione può essere eseguita in orario non lavorativo?

  • Quali sono i prerequisiti per la migrazione?

    Per le istanze inserite dalla rete virtuale, vedere i prerequisiti per le opzioni per eseguire la migrazione e mantenere la stessa subnet o per eseguire la migrazione e passare a una nuova subnet.

  • La migrazione causerà tempo di inattività?

    Quando si esegue la migrazione di un'istanza inserita nella rete virtuale e si mantiene la stessa configurazione della subnet, è previsto un tempo di inattività minimo o nullo per il gateway API. Vedere la tabella di riepilogo in Tempo di inattività previsto.

    Durante la migrazione e il passaggio a un nuovo indirizzo VIP, non dovrebbero verificarsi tempi di inattività se sono in uso i nomi host predefiniti. Perché le API interessate siano funzionali è fondamentale che tutte le dipendenze di rete vengano prese in considerazione in anticipo. Tuttavia, se i domini personalizzati sono in uso, questi puntano al calcolo eliminato fino a quando non vengono aggiornati, causando un tempo di inattività. In alternativa, per determinate opzioni di migrazione, abilitare un'impostazione di migrazione per mantenere il gateway precedente per 48 ore. La coesistenza dei nuovi e vecchi calcoli faciliterà la convalida e sarà quindi possibile aggiornare le voci DNS personalizzate in base alle necessità.

  • Il traffico viene sottoposto a tunneling forzato attraverso un firewall. Quali sono le modifiche necessarie?

    • Per prima cosa, assicurarsi che le subnet usate per la migrazione mantengano la configurazione seguente (dovrebbero essere già configurate se si esegue la migrazione e si mantiene la subnet corrente):
      • Abilitare gli endpoint servizio come descritto qui
      • La route definita dall'utente ha l'hop del tag del servizio ApiManagement impostato su "Internet" e non solo sull'indirizzo del firewall
    • I requisiti per la configurazione del gruppo di sicurezza di rete per stv2 rimangono invariati indipendentemente dal fatto che il firewall sia presente o meno. Assicurarsi che la nuova subnet lo abbia
    • Le regole del firewall che fanno riferimento all'intervallo di indirizzi IP corrente dell'istanza di Gestione API devono essere aggiornate in modo che usino l'intervallo di indirizzi IP della nuova subnet.

  • Possono verificarsi perdite di dati o della configurazione durante la migrazione?

    La migrazione da stv1 a stv2 comporta l'aggiornamento della sola piattaforma di calcolo, e il livello di archiviazione interno non viene modificato. Di conseguenza, durante il processo di migrazione tutte le configurazioni sono sicure. Ciò include l'identità gestita assegnata dal sistema, che se abilitata viene mantenuta.

  • Come si verifica che la migrazione sia stata completata correttamente?

    La migrazione viene considerata completata e riuscita quando lo stato nella pagina Panoramica mostra Online insieme alla versione della piattaforma, stv2 o stv2.1. Verificare anche che lo stato della rete nel pannello Rete sia verde per tutta la connettività necessaria.

  • È possibile eseguire la migrazione usando il portale?

    Sì, è possibile eseguire la migrazione delle istanze inserite dalla rete virtuale usando il pannello Migrazione della piattaforma.

  • È possibile mantenere l'indirizzo IP dell'istanza?

    Sì, il pannello Migrazione della piattaforma nel portale e l'API REST hanno opzioni per mantenere l'indirizzo IP.

  • Esiste un percorso di migrazione per il quale non è necessario modificare l'istanza esistente?

    Sì, è necessaria una migrazione side-by-side. Ciò significa che si crea una nuova istanza di Gestione API in parallelo con l'istanza corrente e si copia la configurazione nella nuova istanza.

  • Cosa accade se la migrazione non riesce?

    Se l'istanza di Gestione API non mostra stv2 o stv2.1 come versione della piattaforma e Online come stato dopo l'avvio della migrazione, probabilmente non è riuscita. Viene eseguito automaticamente il rollback del servizio all'istanza precedente e non vengono apportate modifiche.

  • Quali funzionalità non sono disponibili durante la migrazione?

    Tuttavia, le richieste API rimangono reattive durante la migrazione. La configurazione dell'infrastruttura (ad esempio domini personalizzati, percorsi e certificati CA) è bloccata per 30 minuti.

  • Quanto tempo richiederà la migrazione?

    La durata prevista per una migrazione a una nuova configurazione della rete virtuale è di circa 45 minuti. Come indicatore per verificare se la migrazione è già stata eseguita, si può controllare se lo stato dell'istanza è di nuovo Online e non In fase di aggiornamento. Pianificare tempi più lunghi per distribuzioni multi-area e in scenari che comportano la modifica della subnet più di una volta.

  • È possibile convalidare la configurazione della rete virtuale prima di tentare la migrazione?

    Se si prevede di modificare la subnet durante la migrazione, è possibile distribuire una nuova istanza di Gestione API con la rete virtuale, la subnet e (opzionale) la risorsa indirizzo IP da usare per la migrazione effettiva. Accedere alla pagina Stato della rete dopo il completamento della distribuzione e verificare se ogni stato di connettività dell'endpoint è verde. In caso affermativo, è possibile rimuovere questa nuova istanza di Gestione API e procedere con la migrazione reale con il servizio ospitato da stv1 originale.

  • Se necessario, è possibile eseguire il rollback della migrazione?

    Se si verifica un errore durante il processo di migrazione, l'istanza eseguirà automaticamente il rollback alla piattaforma stv1. Tuttavia, dopo la corretta migrazione del servizio, non sarà possibile eseguire il rollback alla piattaforma stv1.

  • Sono necessarie modifiche nelle zone DNS private/dominio personalizzato?

    Con le istanze inserite dalla rete virtuale in modalità interna e passando a un nuovo indirizzo VIP, è necessario aggiornare le zone DNS private al nuovo indirizzo IP della rete virtuale acquisito dopo la migrazione. Prestare attenzione anche all'aggiornamento delle zone DNS non di Azure, ad esempio i server DNS locali che puntano all'indirizzo IP privato di Gestione API. Tuttavia, in modalità esterna, il processo di migrazione aggiornerà automaticamente i domini predefiniti se in uso.

  • L'istanza di stv1 viene distribuita in più aree di Azure. Come si esegue l'aggiornamento a stv2?

    Le distribuzioni in più aree includono più gateway gestiti distribuiti in altre località. Quando si esegue la migrazione usando il pannello Migrazione della piattaforma nel portale, si esegue la migrazione di ogni posizione separatamente. L'API REST Eseguire la migrazione a Stv2 esegue la migrazione di tutte le posizioni in una sola chiamata. L'istanza viene considerata migrata nella nuova piattaforma solo quando viene eseguita la migrazione di tutte le posizioni. Tutti i gateway a livello di area continuano a funzionare normalmente durante il processo di migrazione.

  • È possibile aggiornare l'istanza stv1 alla stessa subnet?

    Sì, usare il pannello Migrazione della piattaforma nel portale oppure usare Esegui la migrazione all'API REST stv2.

  • È possibile testare il nuovo gateway in una nuova subnet prima di passare al traffico live?

    • Quando si esegue la migrazione a una nuova subnet, per impostazione predefinita i gateway gestiti precedenti e i nuovi gateway gestiti coesistono per 15 minuti, ovvero c’è un piccolo intervallo di tempo per convalidare la distribuzione. È possibile abilitare un'impostazione di migrazione per conservare il gateway precedente per 48 ore. Questa modifica mantiene attivi i gateway gestiti precedenti e i nuovi gateway gestiti per ricevere traffico e facilitare la convalida.
    • Il processo di migrazione aggiorna automaticamente i nomi di dominio predefiniti e, se in uso, il traffico viene instradato immediatamente verso i nuovi gateway.
    • Se sono in uso nomi di dominio personalizzati, potrebbe essere necessario aggiornare i record DNS corrispondenti con il nuovo indirizzo IP, se non si usa CNAME. I clienti possono aggiornare il file host con il nuovo indirizzo IP di Gestione API e convalidare l'istanza prima di effettuare il passaggio. Durante questo processo di convalida, il gateway precedente continua a gestire il traffico live.

  • Quando si usa il nome di dominio predefinito in una nuova subnet, occorre tenere presenti alcune considerazioni?

    Le istanze che usano il nome DNS predefinito in modalità esterna hanno l'aggiornamento automatico DNS eseguito dal processo di migrazione. Inoltre, l'endpoint di gestione, che usa sempre il nome di dominio predefinito, viene aggiornato automaticamente dal processo di migrazione. Poiché con una migrazione corretta il passaggio avviene immediatamente, la nuova istanza inizia subito a ricevere traffico ed è fondamentale che tutte le restrizioni o le dipendenze di rete vengano prese in considerazione in anticipo per evitare che le API interessate non siano disponibili.

  • Cosa occorre valutare per i gateway self-hosted?

    Non è necessario eseguire alcuna operazione nei gateway self-hosted. È sufficiente eseguire la migrazione delle istanze di Gestione API in esecuzione in Azure interessate dal ritiro della piattaforma stv1. Si noti che potrebbe essere presente un nuovo IP per l'endpoint di configurazione dell'istanza di Gestione API, perciò eventuali restrizioni di rete aggiunte all'IP devono essere aggiornate.

  • Qual è l’impatto della migrazione sul portale per sviluppatori?

    Non c'è alcun impatto sul portale per sviluppatori. Se vengono usati domini personalizzati, il record DNS deve essere aggiornato con l'indirizzo IP effettivo, dopo la migrazione. Tuttavia, se i domini predefiniti sono in uso, vengono aggiornati automaticamente al completamento della migrazione. Durante la migrazione non sono previsti tempi di inattività per il portale per sviluppatori.

  • Una volta eseguita la migrazione a stv2, ci sono impatti sui costi?

    Il modello di fatturazione rimane invariato per stv2 e non verranno addebitati costi aggiuntivi durante e dopo la migrazione.

  • Quali autorizzazioni di controllo degli accessi in base al ruolo sono necessarie per la migrazione da stv1 a stv2?

    L'utente/processo che esegue la migrazione dovrà disporre dell'accesso in scrittura all'istanza di Gestione API. Sono inoltre necessarie le due autorizzazioni seguenti:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

Contenuto correlato