Voorbereiden op migratie van testuitvoering

Dit artikel is gericht op teamvoorbereiding en bestandsgeneratie die vereist zijn voor het hulpprogramma voor gegevensmigratie.

Vereisten

Voltooi de validatiefase voordat u begint met de voorbereiding op de migratie van de testuitvoering.

Migratie-instellingen genereren

Voer de volgende stappen uit om de migratiespecificatie en gerelateerde bestanden te genereren om de migratie van uw verzamelingsdatabase in de wachtrij te plaatsen.

1. Voer de opdracht voor het voorbereiden van het hulpprogramma voor gegevensmigratie uit met de volgende parameters:

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

   • De optie voor de domeinnaam van de tenant is de naam van de Microsoft Entra ID-tenant van uw bedrijf.
   • Voor de voorbereidingsopdracht is internettoegang vereist. Als uw Azure DevOps-server geen internetverbinding heeft, voert u de opdracht uit vanaf een andere computer.
   • De term 'organisatieregio' verwijst naar de locatie waar u uw verzameling wilt migreren naar Azure DevOps Services. U hebt eerder een regio geselecteerd en de verkorte code vastgelegd. Gebruik deze code in de voorbereidingsopdracht.

2. Meld u aan met een gebruiker van de tenant die gemachtigd is om informatie over alle gebruikers in de Microsoft Entra ID-tenant te lezen.

Het migratiespecificatiebestand configureren

Het migratiespecificatiebestand is een JSON-bestand waarmee het hulpprogramma voor gegevensmigratie de volgende acties uitvoert.

• Uw gemigreerde organisatie configureren
• De bronlocaties opgeven
• De migratie aanpassen

Veel van de velden worden automatisch ingevuld tijdens de voorbereidingsstap, maar u moet de volgende velden configureren:

• Organisatienaam: de naam van de organisatie die u wilt maken voor het migreren van uw gegevens.
• Locatie: Een back-up van uw database- en migratiebestanden die moeten worden geüpload naar een Azure-opslagcontainer. In dit veld wordt de SAS-sleutel opgegeven die door het migratieprogramma wordt gebruikt om veilig verbinding te maken met en de bronbestanden uit de Azure-opslagcontainer te lezen. Het maken van de opslagcontainer wordt later in fase 5 behandeld en het genereren van een SAS-sleutel wordt behandeld in fase 6 voordat u een nieuwe migratie in de wachtrij zet.
• DACPAC: een bestand dat de SQL-database van uw verzameling verpakt.
• Migratietype: Het type migratie: Testuitvoering of Productieuitvoering.

Elk migratiespecificatiebestand is bedoeld voor één verzameling. Als u probeert een migratiespecificatiebestand te gebruiken dat is gegenereerd voor een andere verzameling, wordt de migratie niet gestart. U moet een testuitvoering voorbereiden voor elke verzameling die u wilt migreren en het gegenereerde migratiespecificatiebestand gebruiken om de migratie in de wachtrij te plaatsen.

Het logboekbestand voor identiteitstoewijzing controleren

Het identiteitsoverzichtlogboek is van cruciaal belang, net zo belangrijk als de werkelijke gegevens die u migreert. Wanneer u het logboekbestand bekijkt, begrijpt u hoe identiteitsmigratie functioneert en wat de mogelijke resultaten zijn. Wanneer u een identiteit migreert, kan deze actief of historisch zijn. Actieve identiteiten kunnen zich aanmelden bij Azure DevOps Services, terwijl historische identiteiten dat niet kunnen. De service bepaalt welk type wordt gebruikt.

Notitie

Zodra een identiteit wordt gemigreerd als een historische identiteit, kunt u deze niet converteren naar een actieve identiteit.

Actieve identiteiten

Actieve identiteiten verwijzen na de migratie naar gebruikersidentiteiten in Azure DevOps Services. In Azure DevOps Services worden deze identiteiten gelicentieerd en weergegeven als gebruikers in de organisatie. De identiteiten worden gemarkeerd als actief in de kolom Verwachte importstatus in het logboekbestand voor identiteitstoewijzing.

Historische identiteiten

Historische identiteiten worden als zodanig toegewezen in de kolom Verwachte importstatus in het logboekbestand voor identiteitstoewijzing. Identiteiten zonder regelvermelding in het bestand worden ook historisch. Een voorbeeld van een identiteit zonder regelvermelding kan een werknemer zijn die niet meer in een bedrijf werkt.

In tegenstelling tot actieve identiteiten, historische identiteiten:

• Geen toegang tot een organisatie na de migratie.
• Geen licenties.
• Niet weergeven als gebruikers in de organisatie. Alles wat zich blijft voordoen, is het idee van de naam van die identiteit in de organisatie, zodat de geschiedenis later kan worden doorzocht. U wordt aangeraden historische identiteiten te gebruiken voor gebruikers die niet langer in het bedrijf werken of die geen verdere toegang tot de organisatie nodig hebben.

Notitie

Nadat een identiteit als historisch is gemigreerd, kunt u deze niet meer actief maken.

Licenties

Tijdens de migratie worden licenties automatisch toegewezen voor alle gebruikers die als 'actief' worden weergegeven in de kolom Verwachte importstatus van het logboek voor identiteitstoewijzing. Als automatische licentietoewijzing onjuist is, kunt u deze wijzigen door het 'toegangsniveau' van een of meer gebruikers te bewerken nadat de migratie is voltooid.

Toewijzing is mogelijk niet altijd perfect, dus u hebt tot de eerste van de volgende maand licenties opnieuw toe te wijzen als dat nodig is. Als u voor de eerste van de volgende maand geen abonnement aan uw organisatie koppelt en het juiste aantal licenties hebt gekocht, worden al uw respijtperiodelicenties ingetrokken. Als aan automatische toewijzing meer licenties zijn toegewezen dan u de volgende maand hebt gekocht, worden er geen kosten in rekening gebracht voor de extra licenties, maar we trekken alle onbetaalde licenties in.

Om verlies van toegang te voorkomen, raden we u aan om een abonnement te koppelen en benodigde licenties aan te schaffen voordat de eerste van de maand wordt uitgevoerd, aangezien de facturering maandelijks wordt uitgevoerd. Voor alle testuitvoeringen zijn licenties gratis zolang de organisatie actief is.

Azure DevOps-abonnementen

Visual Studio-abonnementen worden niet standaard toegewezen voor migraties. In plaats daarvan krijgen gebruikers met Visual Studio-abonnementen automatisch een upgrade om die licentie te gebruiken. Als de werkorganisatie van een gebruiker correct is gekoppeld, past Azure DevOps Services automatisch de voordelen van hun Visual Studio-abonnement toe bij de eerste aanmelding na de migratie.

U hoeft geen testuitvoeringsmigratie te herhalen als gebruikers niet automatisch een upgrade krijgen om hun Visual Studio-abonnement te gebruiken in Azure DevOps Services. Het koppelen van Visual Studio-abonnementen is iets dat buiten het bereik van een migratie valt. Als de werkorganisatie correct wordt gekoppeld vóór of na de migratie, wordt de licentie automatisch bijgewerkt bij de volgende aanmelding. Zodra ze zijn bijgewerkt, wordt de volgende keer dat u de gebruiker migreert, automatisch geüpgraded bij de eerste aanmelding bij de organisatie.

Alleen ip-adressen van Azure DevOps Services beperken

• Optie 1: Servicetags gebruiken
• Optie 2: IP-lijst gebruiken

Beperk de toegang tot uw Azure Storage-account tot alleen IP-adressen van Azure DevOps Services. U kunt de toegang beperken door alleen verbindingen toe te staan van IP-adressen van Azure DevOps Services die betrokken zijn bij het migratieproces van de verzamelingsdatabase. De IP-adressen waaraan toegang moet worden verleend tot uw opslagaccount, zijn afhankelijk van de regio waarnaar u migreert.

Optie 1: Servicetags gebruiken

U kunt eenvoudig verbindingen vanuit alle Azure DevOps Services-regio's toestaan door de azuredevops servicetag toe te voegen aan uw netwerkbeveiligingsgroepen of firewalls via de portal of via programmacode.

Optie 2: IP-lijst gebruiken

Gebruik de IpList opdracht om de lijst met IP-adressen op te halen die toegang moeten krijgen om verbindingen vanuit een specifieke Azure DevOps Services-regio toe te staan.

Opgenomen in de Help-documentatie zijn instructies en voorbeelden voor het uitvoeren van Migrator vanuit het Azure DevOps Server-exemplaar zelf en een externe computer. Als u de opdracht uitvoert vanuit een van de toepassingslagen van het Azure DevOps Server-exemplaar, moet uw opdracht de volgende structuur hebben:

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

U kunt de lijst met IP-adressen toevoegen aan uw netwerkbeveiligingsgroepen of firewalls via de portal of programmatisch.

IP-firewall-uitzonderingen configureren voor SQL Azure

Deze sectie is alleen van toepassing op het configureren van firewall-uitzonderingen voor SQL Azure. Zie Azure Storage-firewalls en virtuele netwerken configureren voor DACPAC-migraties.

Voor het hulpprogramma voor gegevensmigratie zijn de IP-adressen van Azure DevOps Services alleen geconfigureerd voor binnenkomende verbindingen op poort 1433.

Voer de volgende stappen uit om uitzonderingen toe te kennen voor de benodigde IP-adressen die worden verwerkt in de Azure-netwerklaag voor uw SQL Azure-VM.

1. Meld u aan bij het Azure-portaal.
2. Ga naar uw SQL Azure-VM.
3. Selecteer Netwerken onder Instellingen.
4. Selecteer Add inbound port rule.
5. Selecteer Geavanceerd om een regel voor binnenkomende poorten voor een specifiek IP-adres te configureren.
6. Selecteer IP-adressen in de vervolgkeuzelijst Bron, voer een IP-adres in waaraan een uitzondering moet worden toegekend, stel het bereik van de doelpoort 1433 in en voer in het vak Naam een naam in waarmee de uitzondering die u het beste configureert, wordt beschreven.

Afhankelijk van andere geconfigureerde regels voor binnenkomende poorten, moet u mogelijk de standaardprioriteit voor de Uitzonderingen van Azure DevOps Services wijzigen, zodat ze niet worden genegeerd. Als u bijvoorbeeld een regel 'Weigeren voor alle binnenkomende verbindingen met 1433' hebt met een hogere prioriteit dan uw Uitzonderingen voor Azure DevOps Services, kan het hulpprogramma voor gegevensmigratie mogelijk geen verbinding maken met uw database.

Herhaal het toevoegen van binnenkomende poortregels totdat alle benodigde IP-adressen van Azure DevOps Services een uitzondering krijgen. Als u één IP-adres mist, kan uw migratie niet worden gestart.

Grote verzamelingen migreren

Voor databases waarvoor het hulpprogramma voor gegevensmigratie te groot is, is een andere benadering voor het verpakken van gegevens vereist om te migreren naar Azure DevOps Services. Als u niet zeker weet of uw verzameling de drempelwaarde voor de grootte overschrijdt, moet u een validatie voor het hulpprogramma voor gegevensmigratie uitvoeren voor de verzameling. Met de validatie kunt u zien of u de SQL Azure VM-methode voor migratie moet gebruiken.

Bepalen of u de verzamelingsgrootte kunt verkleinen

Controleer of u oude gegevens kunt opschonen. In de loop van de tijd kunnen verzamelingen grote hoeveelheden gegevens opbouwen. Deze groei is een natuurlijk onderdeel van het DevOps-proces, maar mogelijk hebt u niet alle gegevens nodig. Enkele veelvoorkomende voorbeelden van niet langer relevante gegevens zijn oudere werkruimten en buildresultaten.

Het hulpprogramma voor gegevensmigratie scant uw verzameling en vergelijkt deze met de eerder genoemde limieten. Vervolgens wordt gerapporteerd of uw verzameling in aanmerking komt voor DE DACPAC- of SQL-migratiemethode. Over het algemeen is het idee dat als uw verzameling klein genoeg is om binnen de DACPAC-limieten te passen, u de snellere en eenvoudigere DACPAC-benadering kunt gebruiken. Als uw verzameling echter te groot is, moet u de SQL-migratiemethode gebruiken. Hiervoor moet u een SQL Azure-VM instellen en de database handmatig migreren.

Maximale grootte

De huidige limieten zijn:

• 150 GB totale databasegrootte (databasemetagegevens + blobs) voor DACPAC, als u deze limiet overschrijdt, moet u de SQL-migratiemethode uitvoeren.
• 30 GB afzonderlijke tabelgrootte (databasemetagegevens + blobs) voor DACPAC, als één tabel deze limiet overschrijdt, moet u de SQL-migratiemethode uitvoeren.
• De grootte van 1536 GB databasemetagegevens voor de SQL-migratiemethode. Als u deze limiet overschrijdt, raden we u aan om onder deze grootte te blijven om een geslaagde migratie te hebben.
• De grootte van 2048 GB databasemetagegevens voor de SQL-migratiemethode. Als u deze limiet overschrijdt, treedt er een fout op, zodat u geen migratie kunt uitvoeren.
• Geen limiet voor blobgrootten voor sql-migratiemethode.

Wanneer u oudere, niet langer relevante artefacten opschoont, kan deze veel meer ruimte verwijderen dan u zou verwachten en kan worden bepaald of u de DACPAC-migratiemethode of een SQL Azure-VM gebruikt.

Belangrijk

Nadat u oudere gegevens hebt verwijderd, kunt u deze alleen herstellen als u een oudere back-up van de verzameling herstelt.

Als u de DACPAC-drempelwaarde hebt bereikt, volgt u de instructies voor het genereren van een DACPAC voor migratie. Als u de database nog steeds niet onder de DACPAC-drempelwaarde kunt krijgen, moet u een SQL Azure-VM instellen om te migreren naar Azure DevOps Services.

Een VIRTUELE SQL Azure-machine instellen om te migreren naar Azure DevOps Services

Volg de volgende stappen op hoog niveau om een virtuele SQL Azure-machine (VM) in te stellen om te migreren naar Azure DevOps Services.

1. Een SQL Azure-VM instellen
2. IP-firewall-uitzonderingen configureren
3. Uw database herstellen op de virtuele machine
4. [Uw verzameling configureren voor migratie
5. Het migratiespecificatiebestand configureren om de VM te targeten

Een SQL Azure-VM instellen

U kunt snel een VIRTUELE SQL Azure-machine instellen vanuit Azure Portal. Zie De Azure-portal gebruiken om een virtuele Windows-machine in te richten met SQL Server voor meer informatie.

De prestaties van uw SQL Azure-VM en gekoppelde gegevensschijven hebben een aanzienlijke invloed op de prestaties van de migratie. Daarom raden we u ten zeerste aan de volgende taken uit te voeren:

• Selecteer een VM-grootte op het niveau van D8s_v5_* of hoger.
• Beheerde schijven gebruiken.
• Raadpleeg de prestaties van virtuele machines en schijven. Zorg ervoor dat uw infrastructuur zo is geconfigureerd dat de IOPS van de VM (invoer/uitvoer per seconde) en opslag-IOPS geen knelpunt worden in de prestaties van de migratie. Zorg er bijvoorbeeld voor dat het aantal gegevensschijven dat is gekoppeld aan uw VIRTUELE machine voldoende is om de IOPS van de VIRTUELE machine te ondersteunen.

Azure DevOps Services is beschikbaar in verschillende Azure-regio's over de hele wereld. Om ervoor te zorgen dat de migratie succesvol wordt gestart, is het essentieel om uw gegevens in de juiste regio te plaatsen. Als u uw SQL Azure-VM op een verkeerde locatie instelt, kan de migratie niet worden gestart.

Belangrijk

Voor de Azure-VM is een openbaar IP-adres vereist.

Als u deze migratiemethode gebruikt, maakt u uw VIRTUELE machine in een ondersteunde regio. Hoewel Azure DevOps Services beschikbaar is in meerdere regio's in de Verenigde Staten (VS), accepteert alleen de regio Centraal Verenigde Staten nieuwe organisaties. U kunt uw gegevens nu niet migreren naar andere Azure-regio's in de VS.

Notitie

DACPAC-klanten moeten de regiotabel raadplegen in de sectie 'Stap 3: Het DACPAC-bestand uploaden](migration-test-run.md#)'. De voorgaande richtlijnen zijn alleen bedoeld voor SQL Azure-VM's. Als u een DACPAC-klant bent, raadpleegt u ondersteunde Azure-regio's voor migratie.

Gebruik de volgende SQL Azure VM-configuraties:

• Configureer de TIJDELIJKE SQL-database voor het gebruik van een ander station dan station C. In het ideale geval moet het station voldoende vrije ruimte hebben; ten minste gelijk aan de grootste tabel van uw database.
• Als uw brondatabase nog steeds groter is dan 1 terabyte (TB) nadat u de grootte hebt verkleind, moet u meer schijven van 1 TB koppelen en deze combineren in één partitie om uw database op de VIRTUELE machine te herstellen.
• Als uw verzamelingsdatabases groter zijn dan 1 TB, kunt u overwegen om een SSD (ssd-harde schijven) te gebruiken voor zowel de tijdelijke database als de verzamelingsdatabase. Overweeg ook om grotere VM's te gebruiken met 16 virtuele CPU's (vCPU's) en 128 GB (gigabytes) ram-geheugen (random access memory).

Uw database herstellen op de virtuele machine

Nadat u een Virtuele Azure-machine hebt ingesteld en geconfigureerd, moet u de losgekoppelde back-up van uw Azure DevOps Server-exemplaar naar uw Azure-VM nemen. De verzamelingsdatabase moet worden hersteld op uw SQL-exemplaar en vereist niet dat Azure DevOps Server op de VIRTUELE machine is geïnstalleerd.

Uw verzameling configureren voor migratie

Nadat de verzamelingsdatabase is hersteld op uw Azure-VM, configureert u een SQL-aanmelding zodat Azure DevOps Services verbinding kan maken met de database om de gegevens te migreren. Met deze aanmelding is alleen leestoegang tot één database toegestaan.

1. Open SQL Server Management Studio op de virtuele machine en open vervolgens een nieuw queryvenster voor de database die moet worden gemigreerd.

2. Stel het herstel van de database in op eenvoudig:

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

3. Maak een SQL-aanmelding voor de database en wijs die aanmelding toe aan TFSEXECROLE, zoals in het volgende voorbeeld.

   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>'
   

Zie het volgende voorbeeld van de SQL-opdracht:

    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'

Belangrijk

Schakel sql Server- en Windows-verificatiemodus in in SQL Server Management Studio op de VIRTUELE machine. Als u de verificatiemodus niet inschakelt, mislukt de migratie.

Het migratiespecificatiebestand configureren om de VM te targeten

Werk het migratiespecificatiebestand bij met informatie over het maken van verbinding met het SQL Server-exemplaar. Open uw migratiespecificatiebestand en voer de volgende updates uit:

1. Verwijder de DACPAC-parameter uit het bronbestandenobject. De migratiespecificatie voordat de wijziging eruitziet als de volgende voorbeeldcode.

   

   De migratiespecificatie na de wijziging ziet eruit als de volgende voorbeeldcode.

   

2. Voer de vereiste parameters in en voeg het volgende eigenschappenobject toe in uw bronobject in het specificatiebestand.

   "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"  
   }
   

Nadat u de wijzigingen hebt toegepast, ziet de migratiespecificatie eruit zoals in het volgende voorbeeld.

Uw migratiespecificatie is nu geconfigureerd voor het gebruik van een SQL Azure-VM voor migratie. Ga verder met de rest van de voorbereidingsstappen voor migratie. Nadat de migratie is voltooid, moet u de SQL-aanmelding verwijderen of het wachtwoord roteren. Microsoft behoudt de aanmeldingsgegevens niet nadat de migratie is voltooid.

Een Azure Storage-container maken in het gekozen datacenter

Als u het hulpprogramma voor gegevensmigratie voor Azure DevOps gebruikt, moet u een Azure Storage-container in hetzelfde Azure-datacenter hebben als de uiteindelijke Azure DevOps Services-organisatie. Als u bijvoorbeeld van plan bent om uw Azure DevOps Services-organisatie te maken in het central Verenigde Staten datacenter, maakt u vervolgens de Azure Storage-container in hetzelfde datacenter. Met deze actie wordt de tijd die nodig is om de SQL-database te migreren drastisch versneld, omdat de overdracht plaatsvindt binnen hetzelfde datacenter.

Zie Een opslagaccount maken voor meer informatie.

Facturering instellen

Er wordt een respijtperiode geplaatst in de zojuist gemigreerde Azure DevOps Services-organisatie, zodat uw team alle benodigde stappen kan voltooien en licentietoewijzingen kan corrigeren. Als u verwacht dat u meer gebruikersplannen, build- of implementatiepijplijnen, gehoste buildservices, gehoste belastingtestservices wilt aanschaffen, raden we u bijvoorbeeld ten zeerste aan dat u zeker weet dat u een Azure-abonnement hebt dat gereed is voor het koppelen aan uw gemigreerde organisatie. De respijtperiode eindigt op de eerste dag van de volgende maand nadat u de migratie hebt voltooid.

We herinneren u er opnieuw aan in de fase na de migratie (koppeling) voor wanneer u de koppeling moet uitvoeren. Deze voorbereidingsstap gaat over het controleren of u weet welk Azure-abonnement u in die latere stap gebruikt. Zie Facturering instellen voor uw organisatie voor meer informatie.

Volgende stappen

Testuitvoeringsmigratie uitvoeren

Verwante artikelen:

• Migreren naar Azure DevOps Services
• Taken na de migratie voltooien