Condividi tramite

Preparare la migrazione dell'esecuzione dei test

  • Articolo

Questo articolo è incentrato sulla preparazione del team e sulla generazione di file richiesta dallo Strumento di migrazione dei dati.

Diagramma dell'evidenziata Preparazione per la fase di esecuzione dei test delle sette fasi della migrazione.

Prerequisiti

Completare la fase convalida prima di iniziare a preparare la migrazione dell'esecuzione dei test.

Generare le impostazioni di migrazione

Seguire questa procedura per generare la specifica di migrazione e i file correlati per accodare la migrazione del database di raccolta.

  1. Eseguire il comando prepare dello strumento di migrazione dei dati con i parametri seguenti:

    /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

    • L'opzione nome di dominio tenant è il nome del tenant microsoft Entra ID dell'azienda.
    • Il comando prepare richiede l'accesso a Internet. Se il server Azure DevOps non dispone della connettività Internet, eseguire il comando da un computer diverso.
    • Il termine "area dell'organizzazione" si riferisce alla posizione in cui si prevede di eseguire la migrazione della raccolta in Azure DevOps Services. In precedenza è stata selezionata un'area e ne è stato registrato il codice abbreviato. Usare questo codice nel comando prepare.

  2. Accedere con un utente dal tenant che dispone dell'autorizzazione per leggere informazioni su tutti gli utenti nel tenant di Microsoft Entra ID.

Configurare il file di specifica della migrazione

Il file di specifica della migrazione è un file JSON che indica allo strumento di migrazione dei dati come eseguire le azioni seguenti.

  • Configurare l'organizzazione migrata
  • Specificare i percorsi di origine
  • Personalizzare la migrazione

Molti campi vengono popolati automaticamente durante il passaggio di preparazione, ma è necessario configurare i campi seguenti:

  • Nome organizzazione: nome dell'organizzazione che si vuole creare per la migrazione dei dati.
  • Percorso: backup dei file di database e migrazione da caricare in un contenitore di archiviazione di Azure. Questo campo specifica la chiave di firma di accesso condiviso usata dallo strumento di migrazione per connettersi e leggere in modo sicuro i file di origine dal contenitore di archiviazione di Azure. La creazione del contenitore di archiviazione viene illustrata più avanti nella fase 5 e la generazione di una chiave di firma di accesso condiviso viene descritta nella fase 6 prima di accodare per una nuova migrazione.
  • DACPAC: file che crea un pacchetto del database SQL della raccolta.
  • Tipo di migrazione: tipo di migrazione: esecuzione di test o esecuzione produzione.

Ogni file di specifica della migrazione è destinato a una singola raccolta. Se si tenta di usare un file di specifica di migrazione generato per un'altra raccolta, la migrazione non viene avviata. È necessario preparare un'esecuzione di test per ogni raccolta di cui si vuole eseguire la migrazione e usare il file di specifiche di migrazione generato per accodare la migrazione.

Esaminare il file di log della mappa delle identità

Il log della mappa delle identità è fondamentale, importante quanto i dati effettivi di cui si esegue la migrazione. Quando si esamina il file di log, comprendere il funzionamento della migrazione delle identità e i potenziali risultati. Quando si esegue la migrazione di un'identità, può essere attiva o cronologica. Le identità attive possono accedere ad Azure DevOps Services, mentre le identità cronologiche non possono. Il servizio decide quale tipo viene usato.

Nota

Una volta eseguita la migrazione di un'identità come identità cronologica, non è possibile convertirla in un'identità attiva.

Identità attive

Le identità attive fanno riferimento alle identità utente in Azure DevOps Services dopo la migrazione. In Azure DevOps Services queste identità vengono concesse in licenza e vengono visualizzate come utenti dell'organizzazione. Le identità sono contrassegnate come attive nella colonna Stato importazione prevista nel file di log della mappa delle identità.

Identità cronologiche

Viene eseguito il mapping delle identità cronologiche, ad esempio nella colonna Stato importazione prevista nel file di log della mappa delle identità. Anche le identità senza una voce di riga nel file diventano cronologiche. Un esempio di identità senza una voce di riga potrebbe essere un dipendente che non lavora più in una società.

A differenza delle identità attive, le identità cronologiche:

  • Non avere accesso a un'organizzazione dopo la migrazione.
  • Non avere licenze.
  • Non visualizzare come utenti dell'organizzazione. Tutto ciò che persiste è la nozione del nome dell'identità nell'organizzazione, in modo che la relativa cronologia possa essere eseguita in un secondo momento. È consigliabile usare le identità cronologiche per gli utenti che non lavorano più nella società o che non necessitano di ulteriore accesso all'organizzazione.

Nota

Dopo la migrazione di un'identità come cronologica, non è possibile renderla attiva.

Licenze

Durante la migrazione, le licenze vengono assegnate automaticamente per tutti gli utenti visualizzati come "attivi" nella colonna Stato importazione previsto del log di mapping delle identità. Se l'assegnazione automatica delle licenze non è corretta, è possibile modificarla modificando il "livello di accesso" di uno o più utenti al termine della migrazione.

L'assegnazione potrebbe non essere sempre perfetta, quindi si ha fino al primo del mese successivo per riassegnare le licenze in base alle esigenze. Se entro il primo del mese successivo non si collega una sottoscrizione all'organizzazione e si è acquistato il numero corretto di licenze, tutte le licenze del periodo di tolleranza vengono revocate. In alternativa, se l'assegnazione automatica ha assegnato più licenze rispetto a quelle acquistate per il mese successivo, non viene addebitato alcun addebito per le licenze aggiuntive, ma tutte le licenze non pagate vengono revocate.

Per evitare di perdere l'accesso, è consigliabile collegare una sottoscrizione e acquistare le licenze necessarie prima del primo mese, perché la fatturazione viene eseguita mensilmente. Per tutte le esecuzioni di test, le licenze sono gratuite finché l'organizzazione è attiva.

Sottoscrizioni di Azure DevOps

Sottoscrizioni di Visual Studio non sono assegnati per impostazione predefinita per le migrazioni. Gli utenti con Sottoscrizioni di Visual Studio vengono invece aggiornati automaticamente per usare tale licenza. Se l'organizzazione aziendale di un utente è collegata correttamente, Azure DevOps Services applica automaticamente i vantaggi della sottoscrizione di Visual Studio al primo accesso dopo la migrazione.

Non è necessario ripetere una migrazione dell'esecuzione di test se gli utenti non vengono aggiornati automaticamente per usare la sottoscrizione di Visual Studio in Azure DevOps Services. Il collegamento alla sottoscrizione di Visual Studio è un elemento che si verifica all'esterno dell'ambito di una migrazione. Se l'organizzazione aziendale viene collegata correttamente prima o dopo la migrazione, l'utente ha automaticamente la licenza aggiornata al successivo accesso. Dopo l'aggiornamento, la prossima volta che si esegue la migrazione dell'utente viene aggiornato automaticamente al momento dell'accesso iniziale all'organizzazione.

Limitare l'accesso solo agli indirizzi IP di Azure DevOps Services

Limitare l'accesso all'account Archiviazione di Azure solo agli indirizzi IP di Azure DevOps Services. È possibile limitare l'accesso consentendo solo le connessioni dagli indirizzi IP di Azure DevOps Services coinvolti nel processo di migrazione del database di raccolta. Gli indirizzi IP a cui è necessario concedere l'accesso all'account di archiviazione dipendono dall'area in cui si esegue la migrazione.

Opzione 1: Usare i tag del servizio

È possibile consentire facilmente le connessioni da tutte le aree di Azure DevOps Services aggiungendo il tag di azuredevops servizio ai gruppi di sicurezza di rete o ai firewall tramite il portale o a livello di codice.

Opzione 2: Usare l'elenco ip

Usare il IpList comando per ottenere l'elenco di indirizzi IP a cui è necessario concedere l'accesso per consentire le connessioni da un'area specifica di Azure DevOps Services.

La documentazione della Guida include istruzioni ed esempi per l'esecuzione di Migrat dall'istanza di Azure DevOps Server stessa e da un computer remoto. Se si esegue il comando da uno dei livelli di applicazione dell'istanza di Azure DevOps Server, il comando deve avere la struttura seguente:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

È possibile aggiungere l'elenco di indirizzi IP ai gruppi di sicurezza di rete o ai firewall tramite il portale o a livello di codice.

Configurare le eccezioni del firewall IP per SQL Azure

Questa sezione si applica solo alla configurazione delle eccezioni del firewall per SQL Azure. Per le migrazioni DACPAC, vedere Configurare Archiviazione di Azure firewall e reti virtuali.

Lo strumento di migrazione dei dati richiede che gli indirizzi IP di Azure DevOps Services vengano configurati per le connessioni in ingresso solo sulla porta 1433.

Seguire questa procedura per concedere eccezioni per gli INDIRIZZI IP necessari gestiti a livello di rete di Azure per la macchina virtuale di SQL Azure.

  1. Accedere al portale di Azure.
  2. Passare alla macchina virtuale di SQL Azure.
  3. In Impostazioni selezionare Rete.
  4. Selezionare Aggiungi regola porta in ingresso. Screenshot del pulsante Aggiungi regola porta in ingresso nella pagina dell'interfaccia di rete della macchina virtuale di SQL Azure.
  5. Selezionare Avanzate per configurare una regola di porta in ingresso per un indirizzo IP specifico. Screenshot del pulsante Avanzate nel riquadro Aggiungi regola di sicurezza in ingresso.
  6. Nell'elenco a discesa Origine selezionare Indirizzi IP, immettere un indirizzo IP che deve essere concesso a un'eccezione, impostare l'intervallo di porte di destinazione su 1433 e, nella casella Nome, immettere un nome che descrive meglio l'eccezione che si sta configurando.

A seconda di altre regole delle porte in ingresso configurate, potrebbe essere necessario modificare la priorità predefinita per le eccezioni di Azure DevOps Services, in modo che non vengano ignorate. Ad esempio, se si dispone di una regola "nega su tutte le connessioni in ingresso a 1433" con una priorità più alta rispetto alle eccezioni di Azure DevOps Services, lo strumento di migrazione dei dati potrebbe non essere in grado di stabilire una connessione corretta al database.

Screenshot di una configurazione della regola della porta in ingresso completata.

Ripetere l'aggiunta di regole delle porte in ingresso fino a quando non viene concessa un'eccezione a tutti gli indirizzi IP di Azure DevOps Services necessari. Un indirizzo IP mancante potrebbe causare l'avvio della migrazione.

Eseguire la migrazione di raccolte di grandi dimensioni

Per i database avvisati dallo strumento di migrazione dei dati sono troppo grandi, è necessario un approccio diverso per la creazione di pacchetti di dati per eseguire la migrazione ad Azure DevOps Services. Se non si è certi che la raccolta superi la soglia delle dimensioni, è necessario eseguire una convalida dello strumento di migrazione dei dati nella raccolta. La convalida consente di sapere se è necessario usare il metodo della macchina virtuale di SQL Azure per la migrazione.

Determinare se è possibile ridurre le dimensioni della raccolta

Verificare se è possibile pulire i dati obsoleti. Nel corso del tempo, le raccolte possono creare grandi volumi di dati. Questa crescita è una parte naturale del processo DevOps, ma potrebbe non essere necessario conservare tutti i dati. Alcuni esempi comuni di dati non più rilevanti sono aree di lavoro meno recenti e risultati di compilazione.

Lo strumento di migrazione dei dati analizza la raccolta e lo confronta con i limiti indicati in precedenza. Segnala quindi se la raccolta è idonea per il metodo di migrazione DACPAC o SQL. In generale, l'idea è che se la raccolta è abbastanza piccola da adattarsi ai limiti daCPAC, è possibile usare l'approccio DACPAC più veloce e semplice. Tuttavia, se la raccolta è troppo grande, è necessario usare il metodo di migrazione SQL, che comporta la configurazione di una macchina virtuale di SQL Azure e la migrazione manuale del database.

Limiti di dimensione

I limiti correnti sono:

  • 150 GB di dimensioni totali del database (metadati del database e BLOB) per DACPAC, se si supera questo limite, è necessario eseguire il metodo di migrazione SQL.
  • 30 GB di dimensioni singole della tabella (metadati del database e BLOB) per DACPAC, se una singola tabella supera questo limite, è necessario eseguire il metodo di migrazione SQL.
  • Dimensioni dei metadati del database di 1.536 GB per il metodo di migrazione SQL. Il superamento di questo limite genera un avviso. È consigliabile mantenere le dimensioni in base a questa dimensione per una migrazione corretta.
  • Dimensioni dei metadati del database da 2.048 GB per il metodo di migrazione SQL. Il superamento di questo limite genera un errore, quindi non è possibile eseguire una migrazione.
  • Nessun limite per le dimensioni dei BLOB per il metodo di migrazione SQL.

Quando si puliscono artefatti meno recenti e non più rilevanti, potrebbe rimuovere molto più spazio di quanto previsto e determinare se si usa il metodo di migrazione DACPAC o una macchina virtuale di SQL Azure.

Importante

Dopo aver eliminato i dati meno recenti, non è possibile recuperarli a meno che non si ripristini un backup precedente della raccolta.

Se si è sotto la soglia DACPAC, seguire le istruzioni per generare un pacchetto di applicazione livello dati per la migrazione. Se non è ancora possibile ottenere il database al di sotto della soglia DACPAC, è necessario configurare una macchina virtuale di SQL Azure per eseguire la migrazione ad Azure DevOps Services.

Configurare una macchina virtuale di SQL Azure per eseguire la migrazione ad Azure DevOps Services

Eseguire i passaggi generali seguenti per configurare una macchina virtuale (VM) di SQL Azure per eseguire la migrazione ad Azure DevOps Services.

  1. Configurare una macchina virtuale di SQL Azure
  2. Configurare le eccezioni del firewall IP
  3. Ripristinare il database nella macchina virtuale
  4. [Configurare la raccolta per la migrazione
  5. Configurare il file della specifica di migrazione per la macchina virtuale

Configurare una macchina virtuale di SQL Azure

È possibile configurare rapidamente una macchina virtuale di SQL Azure dal portale di Azure. Per altre informazioni, vedere Usare il portale di Azure per effettuare il provisioning di una macchina virtuale Windows con SQL Server.

Le prestazioni della macchina virtuale di SQL Azure e dei dischi dati collegati hanno un impatto significativo sulle prestazioni della migrazione. Per questo motivo, è consigliabile eseguire le attività seguenti:

  • Selezionare una dimensione della macchina virtuale a livello di D8s_v5_* o superiore.
  • Usare i dischi gestiti.
  • Consultare le prestazioni della macchina virtuale e del disco. Assicurarsi che l'infrastruttura sia configurata in modo che le operazioni di I/O al secondo (input/output al secondo) e le operazioni di I/O al secondo di archiviazione non diventino un collo di bottiglia sulle prestazioni della migrazione. Ad esempio, assicurarsi che il numero di dischi dati collegati alla macchina virtuale sia sufficiente per supportare le operazioni di I/O al secondo dalla macchina virtuale.

Azure DevOps Services è disponibile in diverse aree di Azure in tutto il mondo. Per assicurarsi che la migrazione venga avviata correttamente, è fondamentale posizionare i dati nell'area corretta. Se si configura la macchina virtuale di SQL Azure in una posizione errata, la migrazione non viene avviata.

Importante

La macchina virtuale di Azure richiede un indirizzo IP pubblico.

Se si usa questo metodo di migrazione, creare la macchina virtuale in un'area supportata. Anche se Azure DevOps Services è disponibile in più aree nella Stati Uniti (Stati Uniti), solo l'area centrale Stati Uniti accetta nuove organizzazioni. Non è ora possibile eseguire la migrazione dei dati in altre aree di Azure degli Stati Uniti.

Nota

I clienti daCPAC devono consultare la tabella dell'area nella sezione "Passaggio 3: Caricare il file DACPAC](migration-test-run.md#)". Le linee guida precedenti sono solo per le macchine virtuali di SQL Azure. Se si è un cliente di applicazione livello dati, vedere Aree di Azure supportate per la migrazione.

Usare le configurazioni di macchine virtuali di SQL Azure seguenti:

  • Configurare il database temporaneo SQL per l'uso di un'unità diversa dall'unità C. Idealmente, l'unità deve disporre di spazio libero sufficiente; almeno equivalente alla tabella più grande del database.
  • Se il database di origine è ancora superiore a 1 terabyte (TB) dopo aver ridotto le dimensioni, è necessario collegare più dischi da 1 TB e combinarli in una singola partizione per ripristinare il database nella macchina virtuale.
  • Se le dimensioni dei database di raccolta sono superiori a 1 TB, è consigliabile usare un'unità SSD (unità disco rigido ssd) sia per il database temporaneo che per il database di raccolta. Prendere in considerazione anche l'uso di macchine virtuali di dimensioni maggiori con 16 CPU virtuali (vCPU) e 128 GB (gigabyte) di RAM (memoria ad accesso casuale).

Ripristinare il database nella macchina virtuale

Dopo aver configurato e configurato una macchina virtuale di Azure, è necessario eseguire il backup scollegato dall'istanza di Azure DevOps Server alla macchina virtuale di Azure. Il database di raccolta deve essere ripristinato nell'istanza di SQL e non richiede l'installazione di Azure DevOps Server nella macchina virtuale.

Configurare la raccolta per la migrazione

Dopo il ripristino del database di raccolta nella macchina virtuale di Azure, configurare un accesso SQL per consentire ad Azure DevOps Services di connettersi al database per eseguire la migrazione dei dati. Questo accesso consente solo l'accesso in lettura a un singolo database.

  1. Aprire SQL Server Management Studio nella macchina virtuale e quindi aprire una nuova finestra di query sul database di cui eseguire la migrazione.

  2. Impostare il ripristino del database su semplice:

    ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

  3. Creare un accesso SQL per il database e assegnargli l'accesso "TFSEXECROLE", come nell'esempio seguente.

    USE [<database name>] 
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' 
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] 
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Vedere l'esempio seguente del comando SQL:

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Importante

Abilitare SQL Server e la modalità autenticazione di Windows in SQL Server Management Studio nella macchina virtuale. Se non si abilita la modalità di autenticazione, la migrazione non riesce.

Configurare il file della specifica di migrazione per la macchina virtuale

Aggiornare il file delle specifiche di migrazione per includere informazioni su come connettersi all'istanza di SQL Server. Aprire il file delle specifiche di migrazione e apportare gli aggiornamenti seguenti:

  1. Rimuovere il parametro DACPAC dall'oggetto file di origine. La specifica di migrazione prima della modifica è simile al codice di esempio seguente.

    Screenshot della specifica di migrazione prima della modifica.

    La specifica di migrazione dopo la modifica è simile al codice di esempio seguente.

    Screenshot della specifica di migrazione dopo la modifica.

  2. Immettere i parametri obbligatori e aggiungere l'oggetto proprietà seguente all'interno dell'oggetto di origine nel file di specifica.

    "Properties": 
{ 
    "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True"  
}

Dopo aver applicato le modifiche, la specifica di migrazione sarà simile all'esempio seguente.

Screenshot della specifica di migrazione che fa riferimento a una macchina virtuale di SQL Azure.

La specifica di migrazione è ora configurata per l'uso di una macchina virtuale di SQL Azure per la migrazione. Procedere con il resto dei passaggi di preparazione per la migrazione. Al termine della migrazione, assicurarsi di eliminare l'accesso SQL o ruotare la password. Microsoft non mantiene le informazioni di accesso al termine della migrazione.

Creare un contenitore Archiviazione di Azure nel data center scelto

L'uso dello strumento di migrazione dei dati per Azure DevOps richiede la presenza di un contenitore Archiviazione di Azure nello stesso data center di Azure dell'organizzazione finale di Azure DevOps Services. Ad esempio, se si intende creare l'organizzazione di Azure DevOps Services nel data center centrale Stati Uniti, creare il contenitore Archiviazione di Azure nello stesso data center. Questa azione accelera drasticamente il tempo necessario per eseguire la migrazione del database SQL, poiché il trasferimento avviene all'interno dello stesso data center.

Per altre informazioni, vedere Creare un account di archiviazione.

Configurare la fatturazione

Un periodo di tolleranza viene inserito nell'organizzazione azure DevOps Services appena migrata per consentire al team di completare i passaggi necessari e correggere le assegnazioni di licenza. Se si prevede di acquistare altri piani utente, pipeline di compilazione o distribuzione, servizi di compilazione ospitati, servizi di test di carico ospitati, ad esempio, è consigliabile disporre di una sottoscrizione di Azure pronta per il collegamento all'organizzazione migrata. Il periodo di tolleranza termina il primo giorno del mese successivo dopo aver completato la migrazione.

Si ricorda di nuovo nella fase post-migrazione (collegamento) per quando è necessario eseguire il collegamento. Questo passaggio di preparazione è più importante per assicurarsi di conoscere la sottoscrizione di Azure usata in questo passaggio successivo. Per altre informazioni, vedere Configurare la fatturazione per l'organizzazione.

Passaggi successivi

Eseguire test di migrazione