Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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
Genereer de migratiespecificatie en gerelateerde bestanden om de migratie van uw verzamelingsdatabase in de wachtrij te plaatsen.
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- Gebruik de optie tenantdomeinnaam als 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.
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 kan uitvoeren:
- 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 u wilt uploaden naar een Azure-opslagcontainer. Dit veld geeft de SAS-sleutel op die door het migratieprogramma wordt gebruikt om veilig verbinding te maken met en de bronbestanden te lezen uit de Azure-opslagcontainer. 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 identiteitsmaplogboek controleren
Het identiteitslogboek is van cruciaal belang, net zo belangrijk als de 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 is gemigreerd als een historische identiteit, kunt u deze niet converteren naar een actieve identiteit.
Actieve identiteiten
Actieve identiteiten verwijzen naar gebruikersidentiteiten in Azure DevOps Services na de migratie. 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 identiteitsmap logboekbestand.
Historische identiteiten
In het logboekbestand voor identiteitsoverzichten worden historische identiteiten weergegeven in de kolom Verwachte importstatus . Identiteiten zonder regelvermelding in het bestand worden ook historisch. Een voorbeeld van een identiteit zonder regelvermelding kan een werknemer zijn die niet meer bij een bedrijf werkt.
In tegenstelling tot actieve identiteiten, historische identiteiten:
- Geen toegang tot een organisatie na de migratie.
- Geen licenties.
- Niet worden weergegeven als gebruikers binnen de organisatie. Het enige dat blijft bestaan, is het concept van de naam van die identiteit in de organisatie, zodat de geschiedenis later kan worden doorzocht. Gebruik historische identiteiten voor gebruikers die niet langer in het bedrijf werken of die geen verdere toegang nodig hebben tot de organisatie.
Notitie
Nadat een identiteit als historisch is gemigreerd, kunt u deze niet meer actief maken.
Licenties
Tijdens de migratie wijst het proces automatisch licenties toe 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 koopt, worden al uw respijtperiodelicenties ingetrokken. Als door automatische toewijzing meer licenties dan u voor de volgende maand hebt aangeschaft zijn toegewezen, dan worden er geen extra licenties in rekening gebracht, maar worden alle niet betaalde licenties ingetrokken.
Als u geen toegang wilt verliezen, koppelt u een abonnement en koopt u de benodigde licenties voor de eerste van de maand, aangezien de facturering maandelijks wordt uitgevoerd. Voor alle testuitvoeringen zijn licenties gratis zolang de organisatie actief is.
Azure DevOps abonnementen
Visual Studio Subscriptions zijn niet standaard toegewezen voor migraties. In plaats daarvan worden gebruikers met Visual Studio Subscriptions automatisch geüpgraded 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. Visual Studio Koppelen van 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 geüpgraded, zal de gebruiker bij de volgende migratie automatisch worden geüpgraded bij de eerste aanmelding bij de organisatie.
Toegang beperken tot alleen de IP-adressen van Azure DevOps Services
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 die toegang nodig hebben 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 programmatisch.
Optie 2: IP-lijst gebruiken
Gebruik de opdracht IpList om de lijst met IP-adressen op te halen die toegang nodig hebben om verbindingen vanuit een specifieke regio Azure DevOps Services toe te staan.
De Help-documentatie bevat instructies en voorbeelden voor het uitvoeren van Migrator vanaf het Azure DevOps Server exemplaar zelf en een externe computer. Als u het commando uitvoert vanuit een van de toepassingslagen van een Azure DevOps Server-exemplaar, dient uw commando de volgende structuur te 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
In deze sectie wordt beschreven hoe u firewall-uitzonderingen configureert voor SQL Azure. Zie Configure Azure Storage firewalls en virtuele netwerken voor DACPAC-migraties.
Voor het hulpprogramma voor gegevensmigratie moet u de IP-adressen van Azure DevOps Services alleen configureren voor binnenkomende verbindingen op poort 1433.
Voer de volgende stappen uit om uitzonderingen toe te kennen voor de benodigde IP-adressen die de Azure netwerklaag voor uw SQL-Azure-VM verwerkt:
- Meld u aan bij de Azure-portal.
- Ga naar uw SQL-Azure-VM.
- Selecteer Netwerken onder Instellingen.
- Selecteer Add inbound port rule.
- Selecteer Geavanceerd om een regel voor binnenkomende poorten voor een specifiek IP-adres te configureren.
- Selecteer IP-adressen in de vervolgkeuzelijst Bron. Voer een IP-adres in dat een uitzondering nodig heeft. Stel het doelpoortbereik in op
1433. Voer in het vak Naam een naam in waarmee de uitzondering die u configureert het beste wordt beschreven.
Afhankelijk van andere geconfigureerde regels voor binnenkomende poorten, moet u mogelijk de standaardprioriteit wijzigen voor de uitzonderingen van Azure DevOps Services, zodat ze niet worden genegeerd. Als u bijvoorbeeld een regel 'Weigeren voor alle binnenkomende verbindingen met 1433' hebt met een hogere prioriteit dan de uitzonderingen van uw Azure DevOps Services, kan het hulpprogramma voor gegevensmigratie mogelijk geen verbinding maken met uw database.
Herhaal het toevoegen van regels voor binnenkomende poorten totdat alle benodigde IP-adressen van Azure DevOps Services een uitzondering hebben. Als u één IP-adres mist, kan uw migratie niet worden gestart.
Grote verzamelingen migreren
Voor databases waarvoor het hulpprogramma voor gegevensmigratie waarschuwt dat ze te groot zijn, is een andere aanpak van dataverpakking vereist om naar Azure DevOps Services te migreren. Als u niet zeker weet of uw verzameling de drempelwaarde voor de grootte overschrijdt, voert u een validatie voor het hulpprogramma voor gegevensmigratie uit 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 verzamelen. 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 bouwresultaten.
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. Als uw verzameling in het algemeen klein genoeg is om binnen de DACPAC-limieten te passen, kunt u de snellere en eenvoudigere DACPAC-benadering 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:
- De totale databasegrootte van 150 GB (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 metadatagrootte van 1,536 GB voor de SQL-migratiemethode. Als u deze limiet overschrijdt, wordt een waarschuwing weergegeven. Om een geslaagde migratie te hebben, moet u onder deze grootte blijven.
- 2048 GB databasemetagegevensgrootte voor 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, kunt u meer ruimte verwijderen dan verwacht. Met deze opschoonactie kunt u bepalen 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 kunt ophalen onder de DACPAC-drempelwaarde, moet u een SQL-Azure-VM instellen om te migreren naar Azure DevOps Services.
Een SQL Azure-VM instellen om te migreren naar Azure DevOps Services
Voer de volgende stappen op hoog niveau uit om een SQL-Azure virtuele machine (VM) in te stellen voor migratie naar Azure DevOps Services.
- Een SQL Azure-VM instellen
- IP-firewall-uitzonderingen configureren
- Uw database herstellen op de virtuele machine
- Uw verzameling configureren voor migratie
- Het migratiespecificatiebestand configureren om de VM te targeten
Een SQL Azure-VM instellen
U kunt snel een SQL-Azure-VM instellen vanuit de Azure-portal. Zie Gebruik de Azure-portal voor het inrichten van een Windows virtuele machine met SQL Server voor meer informatie.
De prestaties van uw SQL-Azure-VM en gekoppelde gegevensschijven zijn van invloed op de prestaties van de migratie. Voer daarom de volgende taken uit:
- 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 United States (VS), accepteert alleen de regio Centraal United States nieuwe organisaties. U kunt uw gegevens nu niet migreren naar andere regio's in de VS Azure.
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:
- Stel de tijdelijke SQL-database in om een ander station dan station C te gebruiken. Idealiter heeft het station voldoende vrije ruimte, minstens evenveel als de grootste tabel in 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 Azure VM hebt ingesteld en geconfigureerd, moet u de losgekoppelde back-up van uw Azure DevOps Server exemplaar naar uw Azure-VM maken. De verzamelingsdatabase moet worden hersteld op uw SQL-exemplaar en hoeft niet Azure DevOps Server te worden geïnstalleerd op de VIRTUELE machine.
Uw verzameling configureren voor migratie
Nadat u de verzamelingsdatabase op uw Azure-VM hebt hersteld, configureert u een SQL-verificatie zodat Azure DevOps Services verbinding kunnen maken met de database en de gegevens kunnen migreren. Deze verificatie verleent leestoegang tot slechts één database.
Open SQL Server Management Studio op de virtuele machine en open vervolgens een nieuw queryvenster voor de database die u wilt migreren.
Stel het herstelmodel van de database in op eenvoudig:
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;Maak een SQL-verificatie voor de database en wijs die verificatie toe aan de
TFSEXECROLErol, zoals wordt weergegeven 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 in SQL Server Management Studio op de virtuele machine SQL Server- en Windows authentication modus in. 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:
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.
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 datacenter Central United States, maakt u 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
Wanneer u een Azure DevOps Services-organisatie migreert, krijgt de nieuwe organisatie een respijtperiode. Gebruik deze tijd om alle stappen te voltooien en licentietoewijzingen te corrigeren. Als u denkt dat u meer gebruikersplannen, build- of implementatiepijplijnen of gehoste buildservices wilt aanschaffen, moet u ervoor zorgen dat u een Azure abonnement hebt dat gereed is om te koppelen aan uw gemigreerde organisatie. De respijtperiode eindigt op de eerste dag van de volgende maand nadat u de migratie hebt voltooid.
In de fase na de migratie wordt u eraan herinnerd 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.