Dela via

Förbereda för testkörningsmigrering

  • Artikel

Den här artikeln fokuserar på teamförberedelser och filgenerering som krävs av datamigreringsverktyget.

Diagram över markerade Förbered för testkörningssteg i de sju faserna av migreringen.

Förutsättningar

Slutför valideringsfasen innan du börjar förbereda för testkörningsmigrering.

Generera migreringsinställningar

Utför följande steg för att generera migreringsspecifikationen och relaterade filer för att köa migreringen av samlingsdatabasen.

  1. Kör kommandot Förbered datamigreringsverktyget med följande parametrar:

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

    • Alternativet för klientdomännamn är namnet på företagets Microsoft Entra ID-klientorganisation.
    • Kommandot prepare kräver internetåtkomst. Om Din Azure DevOps Server saknar internetanslutning kör du kommandot från en annan dator.
    • Termen "organisationsregion" refererar till den plats där du planerar att migrera din samling till Azure DevOps Services. Du har tidigare valt en region och spelat in dess kortfattade kod. Använd den här koden i kommandot prepare.

  2. Logga in med en användare från klientorganisationen som har behörighet att läsa information om alla användare i Microsoft Entra ID-klientorganisationen.

Konfigurera migreringsspecifikationsfilen

Migreringsspecifikationsfilen är en JSON-fil som instruerar datamigreringsverktyget hur du utför följande åtgärder.

  • Konfigurera din migrerade organisation
  • Ange källplatserna
  • Anpassa migreringen

Många av fälten fylls i automatiskt under förberedelsesteget, men du måste konfigurera följande fält:

  • Organisationsnamn: Namnet på den organisation som du vill skapa för att migrera dina data.
  • Plats: En säkerhetskopia av databasen och migreringsfilerna som ska laddas upp till en Azure Storage-container. Det här fältet anger den SAS-nyckel som används av migreringsverktyget för att ansluta till och läsa källfilerna från Azure Storage-containern på ett säkert sätt. Skapandet av lagringscontainern beskrivs senare i fas 5 och genereringen av en SAS-nyckel beskrivs i fas 6 innan du köar för en ny migrering.
  • DACPAC: En fil som paketera samlingens SQL-databas.
  • Migreringstyp: Typ av migrering: Testkörning eller Produktionskörning.

Varje migreringsspecifikationsfil är avsedd för en enda samling. Om du försöker använda en migreringsspecifikationsfil som genererats för en annan samling startar inte migreringen. Du måste förbereda en testkörning för varje samling som du vill migrera och använda den genererade migreringsspecifikationsfilen för att köa migreringen.

Granska loggfilen för identitetskartan

Identitetsmappningsloggen är avgörande, lika viktig som de faktiska data som du migrerar. När du undersöker loggfilen ska du förstå hur identitetsmigrering fungerar och möjliga resultat. När du migrerar en identitet kan den vara aktiv eller historisk. Aktiva identiteter kan logga in på Azure DevOps Services, men historiska identiteter kan inte göra det. Tjänsten bestämmer vilken typ som används.

Kommentar

När en identitet migreras som en historisk identitet går det inte att konvertera den till en aktiv identitet.

Aktiva identiteter

Aktiva identiteter refererar till användaridentiteter i Azure DevOps Services efter migreringen. I Azure DevOps Services licensieras dessa identiteter och visas som användare i organisationen. Identiteterna markeras som aktiva i kolumnen Förväntad importstatus i identitetsmappningsloggfilen.

Historiska identiteter

Historiska identiteter mappas som sådana i kolumnen Förväntad importstatus i identitetsmappningsloggfilen. Identiteter utan radpost i filen blir också historiska. Ett exempel på en identitet utan en radpost kan vara en anställd som inte längre arbetar på ett företag.

Till skillnad från aktiva identiteter, historiska identiteter:

  • Har inte åtkomst till en organisation efter migreringen.
  • Har inte licenser.
  • Visa inte som användare i organisationen. Allt som kvarstår är begreppet identitetens namn i organisationen, så att dess historik kan sökas senare. Vi rekommenderar att du använder historiska identiteter för användare som inte längre arbetar på företaget eller som inte behöver ytterligare åtkomst till organisationen.

Kommentar

När en identitet har migrerats som historisk kan du inte göra den aktiv.

Licenser

Under migreringen tilldelas licenser automatiskt för alla användare som visas som "aktiva" i kolumnen Förväntad importstatus i identitetsmappningsloggen. Om den automatiska licenstilldelningen är felaktig kan du ändra den genom att redigera åtkomstnivån för en eller flera användare när migreringen har slutförts.

Tilldelningen kanske inte alltid är perfekt, så du har till den första månaden på dig att omtilldela licenser efter behov. Om du inte länkar en prenumeration till din organisation och har köpt rätt antal licenser under den första månaden återkallas alla dina respitperiodlicenser. Om automatisk tilldelning tilldelas fler licenser än du har köpt för nästa månad debiterar vi dig inte för de extra licenserna, men vi återkallar alla obetalda licenser.

För att undvika att förlora åtkomst rekommenderar vi att du länkar en prenumeration och köper nödvändiga licenser före den första i månaden, eftersom faktureringen körs varje månad. För alla testkörningar är licenser kostnadsfria så länge organisationen är aktiv.

Azure DevOps-prenumerationer

Visual Studio-prenumerationer tilldelas inte som standard för migreringar. I stället uppgraderas användare med Visual Studio-prenumerationer automatiskt för att använda den licensen. Om en användares arbetsorganisation är korrekt länkad tillämpar Azure DevOps Services automatiskt sina Visual Studio-prenumerationsförmåner vid den första inloggningen efter migreringen.

Du behöver inte upprepa en testkörningsmigrering om användarna inte uppgraderas automatiskt för att använda sin Visual Studio-prenumeration i Azure DevOps Services. Visual Studio-prenumerationslänkning är något som sker utanför migreringens omfång. Om arbetsorganisationen länkas korrekt före eller efter migreringen får användaren automatiskt sin licens uppgraderad vid nästa inloggning. När de har uppgraderats uppgraderas användaren automatiskt nästa gång du migrerar vid den första inloggningen till organisationen.

Begränsa endast åtkomsten till Azure DevOps Services-IP-adresser

Begränsa åtkomsten till ditt Azure Storage-konto till endast IP-adresser från Azure DevOps Services. Du kan begränsa åtkomsten genom att endast tillåta anslutningar från Azure DevOps Services-IP-adresser som ingår i insamlingsdatabasmigreringsprocessen. De IP-adresser som måste beviljas åtkomst till ditt lagringskonto beror på vilken region du migrerar till.

Alternativ 1: Använda tjänsttaggar

Du kan enkelt tillåta anslutningar från alla Azure DevOps Services-regioner genom att lägga till azuredevops tjänsttaggen i dina nätverkssäkerhetsgrupper eller brandväggar antingen via portalen eller programmatiskt.

Alternativ 2: Använd IP-lista

IpList Använd kommandot för att hämta listan över IP-adresser som måste beviljas åtkomst för att tillåta anslutningar från en specifik Azure DevOps Services-region.

I hjälpdokumentationen finns instruktioner och exempel för att köra Migrator från själva Azure DevOps Server-instansen och en fjärrdator. Om du kör kommandot från någon av Azure DevOps Server-instansens programnivåer bör kommandot ha följande struktur:

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

Du kan lägga till listan över IP-adresser i dina nätverkssäkerhetsgrupper eller brandväggar antingen via portalen eller programmatiskt.

Konfigurera IP-brandväggsfel för SQL Azure

Det här avsnittet gäller endast för att konfigurera brandväggsfel för SQL Azure. Information om DACPAC-migreringar finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

Datamigreringsverktyget kräver att Azure DevOps Services-IP-adresser konfigureras för inkommande anslutningar endast på port 1433.

Utför följande steg för att bevilja undantag för nödvändiga IP-adresser som hanteras på Azure-nätverksskiktet för din virtuella SQL Azure-dator.

  1. Logga in på Azure-portalen.
  2. Gå till din virtuella SQL Azure-dator.
  3. Under Inställningar väljer du Nätverk.
  4. Välj Lägg till regel för inkommande port. Skärmbild av knappen Lägg till regel för inkommande portar på nätverksgränssnittssidan för den virtuella SQL Azure-datorn.
  5. Välj Avancerat för att konfigurera en regel för inkommande portar för en specifik IP-adress. Skärmbild av knappen Avancerat i fönstret Lägg till inkommande säkerhetsregel.
  6. I listrutan Källa väljer du IP-adresser, anger en IP-adress som måste beviljas ett undantag, anger målportintervallet till 1433 och anger i rutan Namn ett namn som bäst beskriver undantaget du konfigurerar.

Beroende på andra konfigurerade regler för inkommande portar kan du behöva ändra standardprioriteten för Azure DevOps Services-undantagen, så att de inte ignoreras. Om du till exempel har en "neka på alla inkommande anslutningar till 1433"-regeln med högre prioritet än dina Azure DevOps Services-undantag kanske datamigreringsverktyget inte kan upprätta en lyckad anslutning till databasen.

Skärmbild av en slutförd konfiguration av inkommande portregler.

Upprepa att du lägger till regler för inkommande portar tills alla nödvändiga Ip-adresser för Azure DevOps Services har beviljats ett undantag. Om du saknar en IP-adress kan det leda till att migreringen inte startar.

Migrera stora samlingar

För databaser som datamigreringsverktyget varnar för är för stora krävs en annan metod för datapaketering för att migrera till Azure DevOps Services. Om du är osäker på om samlingen överskrider storlekströskelvärdet bör du köra en validering av datamigreringsverktyget i samlingen. Med verifieringen får du veta om du behöver använda SQL Azure VM-metoden för migrering.

Kontrollera om du kan minska samlingens storlek

Kontrollera om du kan rensa gamla data. Med tiden kan samlingar bygga upp stora mängder data. Den här tillväxten är en naturlig del av DevOps-processen, men du kanske inte behöver behålla alla data. Några vanliga exempel på data som inte längre är relevanta är äldre arbetsytor och byggresultat.

Datamigreringsverktyget söker igenom din samling och jämför den med de gränser som nämnts tidigare. Den rapporterar sedan om din samling är berättigad till DACPAC- eller SQL-migreringsmetod. I allmänhet är tanken att om din samling är tillräckligt liten för att passa inom DACPAC-gränserna kan du använda den snabbare och enklare DACPAC-metoden. Men om samlingen är för stor måste du använda SQL-migreringsmetoden, vilket innebär att du konfigurerar en virtuell SQL Azure-dator och migrerar databasen manuellt.

Storleksbegränsningar

De aktuella gränserna är:

  • 150 GB total databasstorlek (databasmetadata + blobar) för DACPAC, om du överskrider den här gränsen måste du utföra SQL-migreringsmetoden.
  • 30 GB individuell tabellstorlek (databasmetadata + blobar) för DACPAC, om en enskild tabell överskrider den här gränsen måste du utföra SQL-migreringsmetoden.
  • 1 536 GB databasmetadatastorlek för SQL-migreringsmetod. Om du överskrider det här gränsproblemet rekommenderar vi att du håller dig under den här storleken för att få en lyckad migrering.
  • 2 048 GB databasmetadatastorlek för SQL-migreringsmetod. Om du överskrider den här gränsen uppstår ett fel, så du kan inte utföra en migrering.
  • Ingen gräns för blobstorlekar för SQL-migreringsmetod.

När du rensar äldre, inte längre relevanta artefakter kan det ta bort mycket mer utrymme än du kan förvänta dig, och det kan avgöra om du använder DACPAC-migreringsmetoden eller en virtuell SQL Azure-dator.

Viktigt!

När du har tagit bort äldre data kan du inte återställa dem om du inte återställer en äldre säkerhetskopia av samlingen.

Om du står under DACPAC-tröskelvärdet följer du anvisningarna för att generera en DACPAC för migrering. Om du fortfarande inte kan hämta databasen under DACPAC-tröskelvärdet måste du konfigurera en virtuell SQL Azure-dator för att migrera till Azure DevOps Services.

Konfigurera en virtuell SQL Azure-dator för migrering till Azure DevOps Services

Utför följande övergripande steg för att konfigurera en virtuell SQL Azure-dator (VM) för migrering till Azure DevOps Services.

  1. Konfigurera en virtuell SQL Azure-dator
  2. Konfigurera IP-brandväggsfel
  3. Återställa databasen på den virtuella datorn
  4. [Konfigurera din samling för migrering
  5. Konfigurera migreringsspecifikationsfilen för att rikta in sig på den virtuella datorn

Konfigurera en virtuell SQL Azure-dator

Du kan snabbt konfigurera en virtuell SQL Azure-dator från Azure-portalen. Mer information finns i Använda Azure-portalen för att etablera en virtuell Windows-dator med SQL Server.

Prestandan för din virtuella SQL Azure-dator och anslutna datadiskar har en betydande inverkan på migreringens prestanda. Därför rekommenderar vi starkt att du utför följande uppgifter:

  • Välj en VM-storlek på nivån D8s_v5_* eller större.
  • Använd hanterade diskar.
  • Läs om prestanda för virtuella datorer och diskar. Se till att infrastrukturen är konfigurerad så att den virtuella datorns IOPS (indata/utdata per sekund) och lagrings-IOPS inte blir en flaskhals i migreringens prestanda. Kontrollera till exempel att antalet datadiskar som är anslutna till den virtuella datorn är tillräckligt för att stödja IOPS från den virtuella datorn.

Azure DevOps Services är tillgängligt i flera Azure-regioner över hela världen. För att säkerställa att migreringen startar är det viktigt att placera dina data i rätt region. Om du konfigurerar din virtuella SQL Azure-dator på fel plats startar inte migreringen.

Viktigt!

Den virtuella Azure-datorn kräver en offentlig IP-adress.

Om du använder den här migreringsmetoden skapar du den virtuella datorn i en region som stöds. Även om Azure DevOps Services är tillgängligt i flera regioner i USA (USA) accepterar endast den centrala USA regionen nya organisationer. Du kan inte migrera dina data till andra AMERIKANSKA Azure-regioner nu.

Kommentar

DACPAC-kunder bör läsa regiontabellen i avsnittet "Steg 3: Ladda upp DACPAC-filen](migration-test-run.md#)". De föregående riktlinjerna gäller endast virtuella SQL Azure-datorer. Om du är DACPAC-kund kan du läsa mer i Azure-regioner som stöds för migrering.

Använd följande SQL Azure VM-konfigurationer:

  • Konfigurera den tillfälliga SQL-databasen så att den använder en annan enhet än enhet C. Helst bör enheten ha gott om ledigt utrymme. minst motsvarar databasens största tabell.
  • Om källdatabasen fortfarande är över 1 terabyte (TB) när du har minskat dess storlek måste du ansluta fler diskar på 1 TB och kombinera dem i en enda partition för att återställa databasen på den virtuella datorn.
  • Om dina samlingsdatabaser är över 1 TB stora kan du överväga att använda en SSD (solid state-hårddiskar) för både den tillfälliga databasen och samlingsdatabasen. Överväg också att använda större virtuella datorer med 16 virtuella processorer (vCPU:er) och 128 GB (gigabyte) RAM-minne (minne för slumpmässig åtkomst).

Återställa databasen på den virtuella datorn

När du har konfigurerat en virtuell Azure-dator måste du ta den frånkopplade säkerhetskopieringen från din Azure DevOps Server-instans till den virtuella Azure-datorn. Samlingsdatabasen måste återställas på din SQL-instans och kräver inte att Azure DevOps Server installeras på den virtuella datorn.

Konfigurera din samling för migrering

När insamlingsdatabasen har återställts på den virtuella Azure-datorn konfigurerar du en SQL-inloggning så att Azure DevOps Services kan ansluta till databasen för att migrera data. Den här inloggningen tillåter endast läsåtkomst till en enda databas.

  1. Öppna SQL Server Management Studio på den virtuella datorn och öppna sedan ett nytt frågefönster mot databasen som ska migreras.

  2. Ange databasens återställning till enkel:

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

  3. Skapa en SQL-inloggning för databasen och tilldela inloggningen "TFSEXECROLE", som i följande exempel.

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

Se följande exempel på SQL-kommandot:

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

Viktigt!

Aktivera SQL Server- och Windows-autentiseringsläge i SQL Server Management Studio på den virtuella datorn. Om du inte aktiverar autentiseringsläge misslyckas migreringen.

Konfigurera migreringsspecifikationsfilen för att rikta in sig på den virtuella datorn

Uppdatera migreringsspecifikationsfilen så att den innehåller information om hur du ansluter till SQL Server-instansen. Öppna migreringsspecifikationsfilen och gör följande uppdateringar:

  1. Ta bort DACPAC-parametern från källfilsobjektet. Migreringsspecifikationen före ändringen ser ut som följande exempelkod.

    Skärmbild av migreringsspecifikationen före ändringen.

    Migreringsspecifikationen efter ändringen ser ut som följande exempelkod.

    Skärmbild av migreringsspecifikationen efter ändringen.

  2. Ange de obligatoriska parametrarna och lägg till följande egenskapsobjekt i källobjektet i specifikationsfilen.

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

När du har tillämpat ändringarna ser migreringsspecifikationen ut som i följande exempel.

Skärmbild av migreringsspecifikationen som refererar till en virtuell SQL Azure-dator.

Migreringsspecifikationen är nu konfigurerad för att använda en virtuell SQL Azure-dator för migrering. Fortsätt med resten av förberedelsestegen för migrering. När migreringen är klar måste du ta bort SQL-inloggningen eller rotera lösenordet. Microsoft behåller inte inloggningsinformationen när migreringen har slutförts.

Skapa en Azure Storage-container i valt datacenter

Om du använder datamigreringsverktyget för Azure DevOps måste du ha en Azure Storage-container i samma Azure-datacenter som den slutliga Azure DevOps Services-organisationen. Om du till exempel vill att din Azure DevOps Services-organisation ska skapas i central USA datacenter skapar du Azure Storage-containern i samma datacenter. Den här åtgärden påskyndar drastiskt den tid det tar att migrera SQL-databasen eftersom överföringen sker i samma datacenter.

Mer information finns i Skapa ett lagringskonto.

Konfigurera fakturering

En respitperiod placeras i den nyligen migrerade Azure DevOps Services-organisationen så att ditt team kan slutföra alla steg som behövs och korrigera licenstilldelningar. Om du tror att du kanske vill köpa fler användarplaner, bygg- eller distributionspipelines, värdbaserade byggtjänster, värdbaserade lasttesttjänster, till exempel rekommenderar vi starkt att du är säker på att du har en Azure-prenumeration redo att länka till din migrerade organisation. Respitperioden upphör den första dagen i följande månad efter att du har slutfört migreringen.

Vi påminner dig igen i fasen efter migreringen (länk) för när du behöver länka. Det här förberedelsesteget handlar mer om att se till att du vet vilken Azure-prenumeration du använder i det senare steget. Mer information finns i Konfigurera fakturering för din organisation.

Nästa steg

Gör testkörningsmigrering