Příprava na migraci testovacího spuštění

Tento článek se zaměřuje na přípravu týmu a generování souborů vyžadované nástrojem pro migraci dat.

Požadavky

Než začnete s přípravou na migraci testovacího běhu, dokončete fázi ověření.

Generování nastavení migrace

Pomocí následujících kroků vygenerujte specifikaci migrace a související soubory, které zařadí migraci databáze kolekce do fronty.

1. Spusťte příkaz Přípravy nástroje pro migraci dat s následujícími parametry:

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

   • Možnost názvu domény tenanta je název tenanta Microsoft Entra ID vaší společnosti.
   • Příkaz prepare vyžaduje přístup k internetu. Pokud váš Azure DevOps Server nemá připojení k internetu, spusťte příkaz z jiného počítače.
   • Termín "oblast organizace" odkazuje na umístění, ve kterém plánujete migrovat kolekci do Azure DevOps Services. Dříve jste vybrali oblast a zaznamenali její zkrácený kód. Tento kód použijte v příkazu prepare.

2. Přihlaste se pomocí uživatele z tenanta, který má oprávnění ke čtení informací o všech uživatelích v tenantovi Microsoft Entra ID.

Konfigurace souboru specifikace migrace

Soubor specifikace migrace je soubor JSON, který dává nástroji pro migraci dat pokyn, jak provést následující akce.

• Konfigurace migrované organizace
• Určení zdrojových umístění
• Přizpůsobení migrace

Mnoho polí se během kroku přípravy vyplní automaticky, ale musíte nakonfigurovat následující pole:

• Název organizace: Název organizace, kterou chcete vytvořit pro migraci dat.
• Umístění: Záloha souborů databáze a migrace, které se mají nahrát do kontejneru úložiště Azure. Toto pole určuje klíč SAS používaný nástrojem pro migraci k zabezpečenému připojení ke zdrojovým souborům a čtení zdrojových souborů z kontejneru úložiště Azure. Vytvoření kontejneru úložiště se probírá později ve fázi 5 a vygenerování klíče SAS se probírá ve fázi 6 před frontou pro novou migraci.
• DACPAC: Soubor, který zabalí databázi SQL vaší kolekce.
• Typ migrace: Typ migrace: Testovací spuštění nebo spuštění v produkčním prostředí.

Každý soubor specifikace migrace je určený pro jednu kolekci. Pokud se pokusíte použít soubor specifikace migrace vygenerovaný pro jinou kolekci, migrace se nespustí. Potřebujete připravit testovací běh pro každou kolekci, kterou chcete migrovat, a použít vygenerovaný soubor specifikace migrace k vytvoření fronty migrace.

Kontrola souboru protokolu mapování identit

Protokol mapování identit je zásadní, stejně důležitý jako skutečná data, která migrujete. Když prozkoumáte soubor protokolu, porozumíte tomu, jak funguje migrace identit a potenciální výsledky. Při migraci identity může být aktivní nebo historická. Aktivní identity se můžou přihlásit ke službě Azure DevOps Services, zatímco historické identity ne. Služba rozhoduje, který typ se použije.

Aktivní identity

Aktivní identity odkazují na identity uživatelů v Azure DevOps Services po migraci. V Azure DevOps Services jsou tyto identity licencované a zobrazují se jako uživatelé v organizaci. Identity jsou v souboru protokolu mapování identit označené jako aktivní ve sloupci Očekávaný stav importu.

Historické identity

Historické identity se mapují jako například ve sloupci Očekávaný stav importu v souboru protokolu mapování identit. Identity bez položky řádku v souboru se také stanou historickými. Příkladem identity bez zadání řádku může být zaměstnanec, který už ve společnosti nespravuje.

Na rozdíl od aktivních identit jsou historické identity:

• Po migraci nemáte přístup k organizaci.
• Nemáte licence.
• Nezobrazujte se jako uživatelé v organizaci. Vše, co přetrvává, je pojem názvu této identity v organizaci, aby bylo možné později vyhledat jeho historii. Doporučujeme používat historické identity pro uživatele, kteří už ve společnosti nefungují nebo nepotřebují další přístup k organizaci.

Licence

Během migrace se licence automaticky přiřazují všem uživatelům, kteří se v protokolu mapování identit zobrazují jako aktivní ve sloupci Očekávaný stav importu. Pokud je přiřazení automatické licence nesprávné, můžete ho po dokončení migrace změnit úpravou úrovně přístupu jednoho nebo více uživatelů.

Přiřazení nemusí být vždy dokonalé, takže budete mít až do prvního z následujícího měsíce, abyste podle potřeby znovu přiřadili licence. Pokud do prvního měsíce příštího měsíce nepropojíte předplatné s vaší organizací a koupíte si správný počet licencí, všechny licence na období odkladu se zruší. Případně pokud vám automatické přiřazení přiřadí více licencí, než jste si koupili pro příští měsíc, nebudeme vám účtovat poplatky za dodatečné licence, ale odvoláme všechny nezaplacené licence.

Pokud se chcete vyhnout ztrátě přístupu, doporučujeme propojit předplatné a koupit potřebné licence před prvním měsícem, protože fakturace se spouští měsíčně. Pro všechna testovací spuštění jsou licence bezplatné, pokud je organizace aktivní.

Předplatná Azure DevOps

Předplatná sady Visual Studio nejsou ve výchozím nastavení přiřazené k migracím. Místo toho se uživatelé s Předplatná sady Visual Studio automaticky upgradovali na používání této licence. Pokud je pracovní organizace uživatele propojená správně, azure DevOps Services automaticky použije výhody předplatného sady Visual Studio při prvním přihlášení po migraci.

Pokud se uživatelé automaticky neupgradují tak, aby používali své předplatné sady Visual Studio ve službě Azure DevOps Services, nemusíte opakovat migraci testovacího spuštění. Propojení předplatného sady Visual Studio je něco, co se děje mimo rozsah migrace. Pokud se organizace práce správně propojí před migrací nebo po migraci, uživatel automaticky upgraduje licenci při příštím přihlášení. Po upgradu se při příštím upgradu uživatele automaticky upgraduje při počátečním přihlášení do organizace.

Omezení přístupu pouze k IP adresám Azure DevOps Services

• Možnost 1: Použití značek služeb
• Možnost 2: Použití seznamu IP adres

Omezte přístup k vašemu účtu Azure Storage jenom na IP adresy z Azure DevOps Services. Přístup můžete omezit tak, že povolíte pouze připojení z IP adres Azure DevOps Services, které jsou součástí procesu migrace databáze kolekce. IP adresy, které je potřeba udělit přístup k vašemu účtu úložiště, závisí na oblasti, do které migrujete.

Možnost 1: Použití značek služeb

Připojení ze všech oblastí Azure DevOps Services můžete snadno povolit přidáním azuredevops značky služby do skupin zabezpečení sítě nebo bran firewall prostřednictvím portálu nebo prostřednictvím kódu programu.

Možnost 2: Použití seznamu IP adres

IpList Pomocí příkazu získáte seznam IP adres, kterým je potřeba udělit přístup, aby bylo možné povolit připojení z konkrétní oblasti Azure DevOps Services.

Součástí dokumentace nápovědy jsou pokyny a příklady pro spuštění nástroje Migrator ze samotné instance Azure DevOps Serveru a vzdáleného počítače. Pokud spouštíte příkaz z jedné z aplikačních vrstev instance Azure DevOps Serveru, měl by mít váš příkaz následující strukturu:

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

Seznam IP adres můžete přidat do skupin zabezpečení sítě nebo bran firewall buď prostřednictvím portálu, nebo prostřednictvím kódu programu.

Konfigurace výjimek brány firewall protokolu IP pro SQL Azure

Tato část se týká pouze konfigurace výjimek brány firewall pro SQL Azure. Informace o migracích DACPAC najdete v tématu Konfigurace bran firewall služby Azure Storage a virtuálních sítí.

Nástroj pro migraci dat vyžaduje, aby IP adresy azure DevOps Services byly nakonfigurované pro příchozí připojení pouze na portu 1433.

Následujícím postupem udělte výjimky potřebným IP adresám zpracovaným na síťové vrstvě Azure pro virtuální počítač SQL Azure.

1. Přihlaste se k portálu Azure.
2. Přejděte na virtuální počítač SQL Azure.
3. V části Nastavení vyberte Sítě.
4. Vyberte Přidat pravidlo portu pro příchozí provoz.
5. Vyberte Upřesnit a nakonfigurujte pravidlo příchozího portu pro konkrétní IP adresu.
6. V rozevíracím seznamu Zdroj vyberte IP adresy, zadejte IP adresu, která musí být udělena výjimka, nastavte rozsah 1433 cílových portů na a do pole Název zadejte název, který nejlépe popisuje výjimku, kterou konfigurujete.

V závislosti na jiných nakonfigurovaných pravidlech portů příchozích přenosů možná budete muset změnit výchozí prioritu výjimek služby Azure DevOps Services, takže se nebudou ignorovat. Pokud máte například pravidlo odepření všech příchozích připojení na verzi 1433 s vyšší prioritou než výjimky služby Azure DevOps Services, nástroj pro migraci dat pravděpodobně nebude moct úspěšně připojit k vaší databázi.

Opakujte přidávání příchozích pravidel portů, dokud nebudou uděleny výjimky všechny nezbytné IP adresy azure DevOps Services. Chybějící jedna IP adresa může způsobit selhání migrace.

Migrace velkých kolekcí

U databází, které nástroj pro migraci dat varuje, jsou příliš velké, je k migraci do Azure DevOps Services potřeba jiný přístup k balení dat. Pokud si nejste jistí, jestli vaše kolekce překročí prahovou hodnotu velikosti, měli byste v kolekci spustit ověření nástroje pro migraci dat. Ověření vám umožní zjistit, jestli k migraci potřebujete použít metodu virtuálního počítače SQL Azure.

Určení, jestli můžete zmenšit velikost kolekce

Zkontrolujte, jestli můžete vyčistit stará data. Kolekce v průběhu času můžou vytvářet velké objemy dat. Tento růst je přirozenou součástí procesu DevOps, ale možná zjistíte, že nemusíte uchovávat všechna data. Mezi běžné příklady, které už nejsou relevantní data, patří starší pracovní prostory a výsledky sestavení.

Nástroj pro migraci dat zkontroluje kolekci a porovná ji s limity uvedenými dříve. Potom hlásí, jestli je vaše kolekce způsobilá pro metodu migrace DACPAC nebo SQL. Obecně platí, že pokud je vaše kolekce dostatečně malá, aby se vešla do limitů DACPAC, můžete použít rychlejší a jednodušší přístup DACPAC. Pokud je ale vaše kolekce příliš velká, musíte použít metodu migrace SQL, která zahrnuje nastavení virtuálního počítače Azure SQL a ruční migraci databáze.

Omezení velikosti

Aktuální limity jsou:

• 150 GB celkové velikosti databáze (metadata databáze a objekty blob) pro DACPAC, pokud tento limit překročíte, musíte provést metodu migrace SQL.
• 30 GB velikosti jednotlivých tabulek (metadata databáze a objekty blob) pro DACPAC, pokud některý z tabulek překročí tento limit, je potřeba provést metodu migrace SQL.
• Velikost metadat databáze 1 536 GB pro metodu migrace SQL Překročení tohoto limitu zobrazí upozornění, že máte pod touto velikostí úspěšnou migraci.
• Velikost metadat databáze 2 048 GB pro metodu migrace SQL Překročení tohoto limitu způsobí chybu, takže nemůžete provést migraci.
• Pro metodu migrace SQL není žádný limit velikostí objektů blob.

Když vyčistíte starší artefakty, které už nejsou relevantní, může se odebrat mnohem více místa, než byste očekávali, a mohlo by se určit, jestli používáte metodu migrace DACPAC nebo virtuální počítač SQL Azure.

Pokud jste pod prahovou hodnotou DACPAC, postupujte podle pokynů a vygenerujte DACPAC pro migraci. Pokud stále nemůžete získat databázi pod prahovou hodnotou DACPAC, musíte nastavit virtuální počítač SQL Azure pro migraci do Azure DevOps Services.

Nastavení virtuálního počítače Azure SQL pro migraci na Azure DevOps Services

Pokud chcete nastavit virtuální počítač SQL Azure pro migraci na Azure DevOps Services, proveďte následující základní kroky.

1. Nastavení virtuálního počítače Azure s SQL
2. Konfigurace výjimek brány firewall protokolu IP
3. Obnovení databáze na virtuálním počítači
4. [Konfigurace kolekce pro migraci
5. Konfigurace souboru specifikace migrace pro cílení na virtuální počítač

Nastavení virtuálního počítače Azure s SQL

Virtuální počítač Sql Azure můžete rychle nastavit na webu Azure Portal. Další informace najdete v tématu Použití webu Azure Portal ke zřízení virtuálního počítače s Windows s SQL Serverem.

Výkon virtuálního počítače Azure SQL a připojených datových disků má významný dopad na výkon migrace. Z tohoto důvodu důrazně doporučujeme provádět následující úlohy:

• Vyberte velikost virtuálního počítače na úrovni D8s_v5_* nebo vyšší.
• Používejte spravované disky.
• Projděte si výkon virtuálního počítače a disku. Ujistěte se, že je vaše infrastruktura nakonfigurovaná tak, aby se počet IOPS virtuálního počítače (vstupně-výstupní za sekundu) a IOPS úložiště nestaly kritickým bodem výkonu migrace. Například zajistěte, aby počet datových disků připojených k vašemu virtuálnímu počítači byl dostatečný pro podporu IOPS z virtuálního počítače.

Azure DevOps Services je k dispozici v několika oblastech Azure po celém světě. Pokud chcete zajistit úspěšné spuštění migrace, je důležité umístit data do správné oblasti. Pokud jste virtuální počítač Azure s SQL nastavili v nesprávném umístění, migrace se nepovede spustit.

Pokud používáte tuto metodu migrace, vytvořte virtuální počítač v podporované oblasti. Přestože je služba Azure DevOps Services dostupná v několika oblastech v USA (USA), přijímá nové organizace pouze oblast – střed USA. Teď nemůžete migrovat data do jiných oblastí Azure v USA.

Použijte následující konfigurace virtuálních počítačů Azure SQL:

• Nakonfigurujte dočasnou databázi SQL tak, aby používala jinou jednotku než jednotku C. V ideálním případě by měla mít jednotka volné místo; aspoň ekvivalentní největší tabulce vaší databáze.
• Pokud vaše zdrojová databáze po zmenšení velikosti stále překročila 1 terabajt (TB), musíte připojit více disků o velikosti 1 TB a zkombinovat je do jednoho oddílu, aby se databáze na virtuálním počítači obnovila.
• Pokud jsou vaše databáze kolekcí větší než 1 TB, zvažte použití ssd (pevných disků SSD) pro dočasnou databázi i databázi kolekce. Zvažte také použití větších virtuálních počítačů s 16 virtuálními procesory (vCPU) a 128 GB (gigabajty) paměti RAM (paměť s náhodným přístupem).

Obnovení databáze na virtuálním počítači

Po nastavení a konfiguraci virtuálního počítače Azure je potřeba provést odpojení zálohy z instance Azure DevOps Serveru na virtuální počítač Azure. Databáze kolekce se musí obnovit ve vaší instanci SQL a nevyžaduje instalaci Azure DevOps Serveru na virtuální počítač.

Konfigurace kolekce pro migraci

Po obnovení databáze kolekce na virtuálním počítači Azure nakonfigurujte přihlášení SQL tak, aby se služba Azure DevOps Services mohla připojit k databázi a migrovat data. Toto přihlášení umožňuje přístup jen pro čtení k jedné databázi.

1. Na virtuálním počítači otevřete APLIKACI SQL Server Management Studio a pak otevřete nové okno dotazu pro migraci databáze.

2. Nastavte obnovení databáze na jednoduché:

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

3. Vytvořte pro databázi přihlášení SQL a přiřaďte ho k přihlášení TFSEXECROLE, podobně jako v následujícím příkladu.

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

Podívejte se na následující příklad příkazu 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'

Konfigurace souboru specifikace migrace pro cílení na virtuální počítač

Aktualizujte soubor specifikace migrace tak, aby obsahoval informace o tom, jak se připojit k instanci SQL Serveru. Otevřete soubor specifikace migrace a proveďte následující aktualizace:

1. Odeberte parametr DACPAC ze zdrojového objektu souborů. Specifikace migrace před změnou vypadá jako následující ukázkový kód.

   

   Specifikace migrace po změně vypadá jako následující ukázkový kód.

   

2. Zadejte požadované parametry a do souboru specifikace přidejte následující objekt vlastností.

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

Po použití změn bude specifikace migrace vypadat jako v následujícím příkladu.

Vaše specifikace migrace je teď nakonfigurovaná tak, aby k migraci používala virtuální počítač SQL Azure. Pokračujte zbývajícími kroky přípravy migrace. Po dokončení migrace nezapomeňte odstranit přihlášení k SQL nebo otočit heslo. Microsoft po dokončení migrace nezachová přihlašovací údaje.

Vytvoření kontejneru Azure Storage ve zvoleném datovém centru

Použití nástroje pro migraci dat pro Azure DevOps vyžaduje mít kontejner Azure Storage ve stejném datovém centru Azure jako konečná organizace Azure DevOps Services. Pokud například máte v úmyslu vytvořit organizaci Azure DevOps Services v datacentru centrálního USA, vytvořte kontejner Azure Storage ve stejném datovém centru. Tato akce výrazně urychlí dobu potřebnou k migraci databáze SQL, protože k přenosu dochází ve stejném datacentru.

Další informace najdete v článku o vytvoření účtu úložiště.

Nastavení fakturace

V nově migrované organizaci Azure DevOps Services se umístí období odkladu, aby váš tým mohl dokončit všechny potřebné kroky a správná přiřazení licencí. Pokud předpokládáte, že si budete chtít koupit další plány uživatelů, kanály sestavení nebo nasazení, hostované služby sestavení, hostované služby zátěžového testu, například důrazně doporučujeme, abyste měli připravené předplatné Azure pro propojení s migrovanou organizací. Období odkladu končí prvním dnem následujícího měsíce po dokončení migrace.

V fázi po migraci vám znovu připomínáme, že pokud potřebujete propojení provést. Tento přípravný krok je další informace o tom, abyste věděli, které předplatné Azure v tomto pozdějším kroku používáte. Další informace najdete v tématu Nastavení fakturace pro vaši organizaci.

Další kroky

Související články

• Migrace na Azure DevOps Services
• Dokončení úkolů po migraci