Przygotowanie do migracji przebiegów testowych

Ten artykuł koncentruje się na przygotowaniu zespołu i generowaniu plików wymaganych przez narzędzie do migracji danych.

Wymagania wstępne

Przed rozpoczęciem przygotowania do migracji uruchomienia testowego ukończ fazę Walidacja.

Generowanie ustawień migracji

Wygeneruj specyfikację migracji i powiązane pliki w celu kolejkowania migracji bazy danych kolekcji.

1. Uruchom polecenie Przygotowywanie narzędzia do migracji danych z następującymi parametrami:

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

   • Użyj opcji nazwy domeny dzierżawy jako nazwy dzierżawy Microsoft Entra ID twojej firmy.
   • Polecenie prepare wymaga dostępu do Internetu. Jeśli Azure DevOps Server nie ma łączności z Internetem, uruchom polecenie z innego komputera.
   • Termin "region organizacji" odnosi się do lokalizacji, w której planujesz przeprowadzić migrację kolekcji do usług Azure DevOps. Wcześniej wybrano region i zarejestrowano jego skrócony kod. Użyj tego kodu w poleceniu prepare.

2. Zaloguj się przy użyciu użytkownika z dzierżawy, który ma uprawnienia do odczytywania informacji o wszystkich użytkownikach w dzierżawie Microsoft Entra ID.

Konfigurowanie pliku specyfikacji migracji

Plik specyfikacji migracji to plik JSON, który instruuje narzędzie do migracji danych, jak wykonać następujące czynności:

• Konfigurowanie zmigrowanej organizacji
• Określanie lokalizacji źródłowych
• Dostosowywanie migracji

Wiele pól jest wypełnianych automatycznie podczas kroku przygotowywania, ale należy skonfigurować następujące pola:

• Nazwa organizacji: nazwa organizacji, którą chcesz utworzyć na potrzeby migracji danych.
• Location: Kopia zapasowa bazy danych i plików migracji do przekazania do kontenera magazynu Azure. To pole określa klucz sygnatury dostępu współdzielonego używany przez narzędzie migracji do bezpiecznego łączenia się z kontenerem magazynu Azure i odczytywania z niego plików źródłowych. Tworzenie kontenera magazynu jest omówione później, w fazie 5, a generowanie klucza SAS jest omówione w fazie 6 przed przygotowaniem do nowej migracji.
• DACPAC: plik, który pakuje bazę danych SQL kolekcji.
• Typ migracji: typ migracji: przebieg testu lub uruchomienie produkcyjne.

Każdy plik specyfikacji migracji jest przeznaczony dla pojedynczej kolekcji. Jeśli spróbujesz użyć pliku specyfikacji migracji wygenerowanego dla innej kolekcji, migracja nie zostanie uruchomiona. Musisz przygotować testowe uruchomienie dla każdej kolekcji, którą chcesz migrować, i użyć wygenerowanego pliku specyfikacji migracji do włączenia do kolejki migracji.

Przegląd pliku dziennika mapy tożsamości

Dziennik mapy tożsamości jest tak samo ważny jak rzeczywiste dane, które migrujesz. Podczas badania pliku dziennika należy zrozumieć, jak działa migracja tożsamości i jakie są potencjalne wyniki. Migracja tożsamości może być aktywna lub historyczna. Aktywne tożsamości mogą logować się do usługi Azure DevOps Services, podczas gdy tożsamości historyczne nie mogą. Usługa decyduje, który typ jest używany.

Aktywne tożsamości

Tożsamości aktywne odnoszą się do tożsamości użytkowników w usłudze Azure DevOps Services po zakończeniu migracji. W usługach Azure DevOps tożsamości te są licencjonowane i pojawiają się jako użytkownicy w organizacji. Tożsamości są oznaczone jako aktywne w kolumnie Oczekiwana sytuacja importu w pliku dziennika mapy tożsamości.

Tożsamości historyczne

Plik dziennika mapowania tożsamości zawiera tożsamości historyczne w kolumnie Oczekiwany stan importu. Tożsamości bez wpisu w pliku również stają się historyczne. Przykładem tożsamości bez pozycji w rejestrze może być pracownik, który już nie jest zatrudniony w firmie.

Tożsamości historyczne, w przeciwieństwie do aktywnych tożsamości:

• Nie masz dostępu do organizacji po migracji.
• Nie masz licencji.
• Nie pojawiajcie się jako użytkownicy w organizacji. Pozostaje tylko nazwa tej tożsamości w organizacji, co pozwala na późniejsze przeszukiwanie jej historii. Użyj tożsamości historycznych dla użytkowników, którzy nie pracują już w firmie lub którzy nie potrzebują dalszego dostępu do organizacji.

Licencje

Podczas migracji proces automatycznie przypisuje licencje dla wszystkich użytkowników wyświetlanych jako aktywni w kolumnie Oczekiwany stan importu dziennika mapowania tożsamości. Jeśli automatyczne przypisanie licencji jest niepoprawne, możesz go zmienić, edytując poziom dostępu co najmniej jednego użytkownika po zakończeniu migracji.

Przypisanie może nie zawsze być idealne, więc do pierwszego dnia następnego miesiąca możesz ponownie przypisać licencje zgodnie z potrzebami. Jeśli po raz pierwszy w następnym miesiącu nie połączysz subskrypcji z organizacją i kupisz poprawną liczbę licencji, wszystkie licencje okresu prolongaty zostaną odwołane. Alternatywnie, jeśli automatyczne przypisanie przyznaje więcej licencji niż te, które zostały zakupione na przyszły miesiąc, nie zostaną naliczone opłaty za dodatkowe licencje, ale wszystkie niezapłacone licencje zostaną anulowane.

Aby uniknąć utraty dostępu, połącz subskrypcję i kup wymagane licencje przed pierwszym dniem miesiąca, ponieważ rozliczenia odbywają się co miesiąc. W przypadku wszystkich przebiegów testowych licencje są bezpłatne, o ile organizacja jest aktywna.

subskrypcje Azure DevOps

Visual Studio Subscriptions nie są domyślnie przypisywane do migracji. Zamiast tego użytkownicy z Visual Studio Subscriptions są automatycznie uaktualnieni do korzystania z tej licencji. Jeśli organizacja użytkownika jest poprawnie połączona, Azure DevOps Services automatycznie stosuje korzyści związane z subskrypcją Visual Studio podczas pierwszego logowania po migracji.

Nie musisz powtarzać migracji testowej, jeśli użytkownicy nie zostaną automatycznie uaktualnieni, aby korzystać z subskrypcji Visual Studio usługami Azure DevOps. Linkowanie subskrypcji Visual Studio to proces, który odbywa się poza zakresem migracji. Jeśli organizacja robocza zostanie poprawnie połączona przed lub po migracji, wtedy przy następnym logowaniu licencja użytkownika zostanie automatycznie uaktualniona. Gdy użytkownicy zostaną zaktualizowani, przy następnej migracji będą oni automatycznie uaktualniani przy pierwszym logowaniu do organizacji.

Ograniczanie dostępu tylko do adresów IP usług Azure DevOps

• Opcja 1. Używanie tagów usługi
• Opcja 2. Użyj listy adresów IP

Ogranicz dostęp do konta Azure Storage tylko do adresów IP z usług Azure DevOps Services. Dostęp można ograniczyć, zezwalając tylko na połączenia z adresów IP usług Azure DevOps, które są zaangażowane w proces migracji bazy danych kolekcji. Adresy IP, które muszą mieć dostęp do Twojego konta magazynowego, zależą od regionu docelowego migracji.

Podczas migracji pakietu DACPAC dostęp do kontenera magazynu uzyskują dwa podmioty: komputer używany do przesłania pakietu DACPAC, na przykład za pomocą narzędzia AzCopy lub programu Eksplorator usługi Azure Storage, oraz hostowana usługa importu danych Azure DevOps. Jeśli włączysz zaporę dla konta magazynu, musisz zezwolić na publiczny wychodzący adres IP maszyny przesyłającej, oprócz ograniczenia do tego samego regionu opisanego w Opcji 2: Użyj listy adresów IP.

Polecenia Migrator validate i Migrator prepare nawiązują połączenie z bazą danych kolekcji oraz z usługą Microsoft Entra ID. Polecenie Migrator import nie nawiązuje połączenia z żadnym z nich. Przesyła on przygotowany pakiet do hostowanej usługi importu danych za pośrednictwem protokołu HTTPS przy użyciu osobistego tokenu dostępu (PAT) i może działać z dowolnego komputera, który ma dostęp do Internetu. Żadne z tych poleceń nie odczytuje kontenera magazynowego. Tylko etap przesyłania to robi.

Opcja 1. Używanie tagów usługi

Ta opcja dotyczy metody migracji maszyny wirtualnej Azure SQL, gdzie sieciowa grupa zabezpieczeń chroni maszynę wirtualną. Zapory kont usługi Azure Storage nie obsługują tagów usług, więc nie można użyć tej opcji, aby zezwolić na dostęp do kontenera magazynu dla pakietu DACPAC. W przypadku migracji pakietu DACPAC użyj opcji 2: Użyj listy adresów IP i przejrzyj ograniczenia dotyczące tego samego regionu opisane w tej sekcji.

Możesz łatwo zezwolić na połączenia ze wszystkich regionów usług Azure DevOps, dodając tag usługi azuredevops do sieciowych grup zabezpieczeń lub zapór za pośrednictwem portalu lub programowo.

Opcja 2. Użyj listy adresów IP

Aby obejść ograniczenie tego samego regionu, użyj jednego z następujących podejść. Bardziej bezpieczne podejście jest wymienione jako pierwsze:

• Użyj metody migracji maszyny wirtualnej Azure SQL, gdzie sieciowa grupa zabezpieczeń (NSG) z azuredevops tagiem usługi jest obsługiwaną ścieżką.
• Tymczasowo ustaw dla konta magazynu opcję Dostęp do sieci publicznej na Wszystkie sieci na czas importu. Sygnatura dostępu współdzielonego (SAS) nadal wymusza autoryzację. Przywróć dostęp do sieci publicznej do wybranych sieci natychmiast po zakończeniu importowania. Pozostawienie konta magazynowego dostępnego z poziomu wszystkich sieci po migracji stanowi krok wstecz pod względem bezpieczeństwa.

Użyj polecenia IpList, aby uzyskać listę adresów IP, które wymagają dostępu, aby zezwolić na połączenia z określonego regionu usług Azure DevOps.

Dokumentacja pomocy technicznej zawiera instrukcje i przykłady uruchamiania narzędzia Migrator z wystąpienia Azure DevOps Server oraz z zdalnego komputera. Jeśli uruchamiasz polecenie z poziomu warstwy aplikacji instancji Azure DevOps Server, polecenie powinno mieć następującą strukturę:

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

Listę adresów IP można dodać do sieciowych grup zabezpieczeń lub zapór za pośrednictwem portalu lub programowo.

Konfigurowanie wyjątków zapory ip dla Azure SQL

W tej sekcji opisano konfigurowanie wyjątków zapory dla Azure SQL. Aby uzyskać informacje o migracjach pakietu DACPAC, zobacz Konfiguruj zapory Azure Storage i sieci wirtualne.

Narzędzie do migracji danych wymaga skonfigurowania adresów IP usług Azure DevOps dla połączeń przychodzących tylko na porcie 1433.

Aby udzielić wyjątków dla niezbędnych adresów IP obsługiwanych przez warstwę sieciową Azure dla maszyny wirtualnej Azure SQL, wykonaj następujące kroki:

1. Zaloguj się do portalu Azure.
2. Przejdź do maszyny wirtualnej Azure SQL.
3. W obszarze Ustawienia wybierz pozycję Sieć.
4. Wybierz pozycję Dodaj regułę portu wejściowego.
5. Wybierz pozycję Zaawansowane , aby skonfigurować regułę portu przychodzącego dla określonego adresu IP.
6. Z listy rozwijanej Źródło wybierz pozycję Adresy IP. Wprowadź adres IP, który wymaga wyjątku. Ustaw zakres portów docelowych na 1433. W polu Nazwa wprowadź nazwę, która najlepiej opisuje konfigurowany wyjątek.

W zależności od innych skonfigurowanych reguł portów przychodzących, możesz potrzebować zmienić domyślny priorytet dla wyjątków usługi Azure DevOps, aby nie zostały zignorowane. Jeśli na przykład masz regułę "zablokuj wszystkie połączenia przychodzące na port 1433" z wyższym priorytetem niż wyjątki dla usługi Azure DevOps, narzędzie do migracji danych może nie być w stanie nawiązać pomyślnego połączenia z bazą danych.

Powtarzaj dodawanie reguł portów wejściowych, dopóki wszystkie niezbędne adresy IP usług Azure DevOps nie będą miały wyjątku. Brak jednego adresu IP może spowodować niepowodzenie uruchomienia migracji.

Migrowanie dużych kolekcji

W przypadku baz danych, przed którymi narzędzie do migracji danych ostrzega o zbyt dużym rozmiarze, do migracji do usług Azure DevOps Services wymagane jest zastosowanie innego podejścia do pakietowania danych. Jeśli nie masz pewności, czy kolekcja przekracza próg rozmiaru, uruchom walidację narzędzia do migracji danych w kolekcji. Walidacja informuje o tym, czy do migracji należy użyć metody maszyny wirtualnej Azure SQL.

Określanie, czy można zmniejszyć rozmiar kolekcji

Sprawdź, czy możesz wyczyścić stare dane. W miarę upływu czasu kolekcje mogą gromadzić duże ilości danych. Ten wzrost jest naturalną częścią procesu DevOps, ale może się okazać, że nie musisz przechowywać wszystkich danych. Niektóre typowe przykłady danych, które stały się nieaktualne, to starsze obszary robocze i wyniki budowania.

Narzędzie do migracji danych skanuje kolekcję i porównuje ją z wcześniej wymienionymi limitami. Następnie raportuje, czy kolekcja kwalifikuje się do korzystania z pakietu DACPAC, czy metody migracji SQL. Ogólnie rzecz biorąc, jeśli kolekcja jest wystarczająco mała, aby zmieścić się w granicach DACPAC, możesz użyć szybszego i prostszego podejścia DACPAC. Jeśli jednak kolekcja jest zbyt duża, musisz użyć metody migracji SQL, która obejmuje skonfigurowanie maszyny wirtualnej Azure SQL i ręczne migrowanie bazy danych.

Limity rozmiarów

Bieżące limity to:

• 150 GB całkowity rozmiar bazy danych (metadane bazy danych i bloby) dla DACPAC. Jeśli przekroczysz ten limit, musisz wykonać metodę migracji SQL.
• 30 GB maksymalnej wielkości tabeli (metadane bazy danych + dane blob) dla pliku DACPAC. Jeśli jakakolwiek pojedyncza tabela przekroczy ten limit, musisz wykonać metodę migracji SQL.
• 1536 GB rozmiaru metadanych bazy danych dla metody migracji SQL. Przekroczenie tego limitu powoduje ostrzeżenie. Aby pomyślnie przeprowadzić migrację, utrzymuj rozmiar poniżej zalecanej wartości.
• 2048 GB rozmiaru metadanych bazy danych dla metody migracji SQL. Przekroczenie tego limitu powoduje wystąpienie błędu, aby nie można było przeprowadzić migracji.
• Brak limitu rozmiarów obiektów blob dla metody migracji SQL.

Jeśli wyczyścisz starsze, nieistotne artefakty, możesz usunąć więcej miejsca niż oczekiwano. To oczyszczanie może określić, czy używasz metody migracji DACPAC, czy maszyny wirtualnej Azure SQL.

Jeśli znajdujesz się poniżej progu pakietu DACPAC, postępuj zgodnie z instrukcjami, aby wygenerować pakiet DACPAC na potrzeby migracji. Jeśli nadal nie możesz uzyskać bazy danych w ramach progu pakietu DACPAC, musisz skonfigurować maszynę wirtualną Azure SQL, aby przeprowadzić migrację do usług Azure DevOps.

Konfigurowanie maszyny wirtualnej Azure SQL w celu migracji do usług Azure DevOps

Wykonaj następujące ogólne kroki, aby skonfigurować maszynę wirtualną sql Azure w celu przeprowadzenia migracji do usług Azure DevOps.

1. Kongurowanie maszyny wirtualnej Azure SQL
2. Konfigurowanie wyjątków zapory sieciowej IP
3. Przywracanie bazy danych na maszynie wirtualnej
4. Konfigurowanie kolekcji na potrzeby migracji
5. Konfigurowanie pliku specyfikacji migracji w celu kierowania maszyny wirtualnej

Konfigurowanie maszyny wirtualnej Azure SQL

Maszynę wirtualną Azure SQL można szybko skonfigurować z poziomu portalu Azure. Aby uzyskać więcej informacji, zobacz Użyj portalu Azure, aby aprowizować maszynę wirtualną Windows przy użyciu SQL Server.

Wydajność maszyny wirtualnej Azure SQL i dołączonych dysków danych znacząco wpływa na wydajność migracji. Z tego powodu wykonaj następujące zadania:

• Wybierz rozmiar maszyny wirtualnej na poziomie D8s_v5_* lub większym.
• Użyj dysków zarządzanych.
• Zapoznaj się z wydajnością maszyny wirtualnej i dysku. Upewnij się, że infrastruktura jest skonfigurowana w taki sposób, aby IOPS (liczba operacji wejścia/wyjścia na sekundę) maszyny wirtualnej oraz IOPS pamięci masowej nie stały się wąskim gardłem dla wydajności migracji. Na przykład upewnij się, że liczba dysków danych dołączonych do maszyny wirtualnej jest wystarczająca do obsługi IOPS na tej maszynie.

usługi Azure DevOps są dostępne w kilku regionach Azure na całym świecie. Aby uzyskać najlepszą wydajność migracji, utwórz maszynę wirtualną Azure SQL w tym samym regionie co organizacja docelowa. Maszyna wirtualna (VM) w innym regionie nie blokuje migracji, ale Narzędzie do migracji danych wyświetla ostrzeżenie i prosi o potwierdzenie, zanim doda migrację do kolejki.

Jeśli używasz tej metody migracji, utwórz maszynę wirtualną w obsługiwanym regionie. Mimo że usługi Azure DevOps są dostępne w wielu regionach w Stanach Zjednoczonych (USA), tylko region Środkowe Stany Zjednoczone akceptuje nowe organizacje. Nie można teraz migrować danych do innych regionów Azure USA.

Użyj następujących konfiguracji maszyn wirtualnych Azure SQL:

• Skonfiguruj tymczasową bazę danych SQL tak, aby korzystała z dysku innego niż dysk C. W idealnym przypadku dysk powinien mieć dużo wolnego miejsca, co najmniej odpowiadające największej tabeli bazy danych.
• Jeśli źródłowa baza danych jest nadal ponad 1 terabajta (TB) po zmniejszeniu jej rozmiaru, musisz dołączyć więcej dysków o rozmiarze 1 TB i połączyć je w jedną partycję, aby przywrócić bazę danych na maszynie wirtualnej.
• Jeśli bazy danych kolekcji mają rozmiar ponad 1 TB, rozważ użycie dysków SSD (dysków twardych półprzewodnikowych) zarówno dla tymczasowej bazy danych, jak i bazy danych kolekcji. Należy również rozważyć użycie większych maszyn wirtualnych z 16 wirtualnymi procesorami CPU (procesorami wirtualnymi) i 128 GB (gigabajtami) pamięci RAM (pamięć dostępu losowego).

Przywracanie bazy danych na maszynie wirtualnej

Po przygotowaniu i skonfigurowaniu maszyny wirtualnej Azure, należy przenieść odłączoną kopię zapasową z wystąpienia Azure DevOps Server do maszyny wirtualnej Azure. Baza danych kolekcji musi zostać przywrócona w wystąpieniu SQL i nie wymaga zainstalowania Azure DevOps Server na maszynie wirtualnej.

Konfigurowanie kolekcji na potrzeby migracji

Po przywróceniu bazy danych kolekcji na maszynie wirtualnej Azure skonfiguruj uwierzytelnianie SQL, aby umożliwić usługom Azure DevOps łączenie się z bazą danych i migrowanie danych. To uwierzytelnianie udziela dostępu do odczytu tylko jednej bazie danych.

1. Otwórz SQL Server Management Studio na maszynie wirtualnej, a następnie otwórz nowe okno zapytania dla bazy danych, którą chcesz zmigrować.

2. Ustaw model odzyskiwania bazy danych na prosty:

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

3. Utwórz uwierzytelnianie SQL dla bazy danych i przypisz to uwierzytelnianie TFSEXECROLE , jak pokazano w poniższym przykładzie.

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

Zobacz następujący przykład polecenia 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'

Skonfiguruj plik specyfikacji migracji, aby ustawić docelową maszynę wirtualną

Zaktualizuj plik specyfikacji migracji, aby uwzględnić informacje o sposobie nawiązywania połączenia z wystąpieniem SQL Server. Otwórz plik specyfikacji migracji i wprowadź następujące aktualizacje:

1. Usuń parametr DACPAC z obiektu plików źródłowych. Specyfikacja migracji przed zmianą wygląda jak poniższy przykładowy kod.

   

   Specyfikacja migracji po zmianie wygląda jak poniższy przykładowy kod.

   

2. Wprowadź wymagane parametry i dodaj następujący obiekt właściwości w obiekcie źródłowym w pliku specyfikacji.

   "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 zastosowaniu zmian specyfikacja migracji wygląda jak w poniższym przykładzie.

Specyfikacja migracji jest teraz skonfigurowana do używania maszyny wirtualnej Azure SQL do migracji. Przejdź do pozostałych kroków przygotowywania migracji. Po zakończeniu migracji pamiętaj, aby usunąć logowanie SQL lub obrócić hasło. Microsoft nie zachowuje informacji logowania po zakończeniu migracji.

Tworzenie kontenera Azure Storage w wybranym centrum danych

Użycie narzędzia do migracji danych dla Azure DevOps wymaga kontenera Azure Storage. Aby uzyskać najlepszą wydajność migracji, utwórz kontener w tym samym centrum danych Azure co ostateczna organizacja usług Azure DevOps. Jeśli na przykład zamierzasz utworzyć organizację usług Azure DevOps Services w centrum danych Central Stany Zjednoczone, utwórz kontener Azure Storage w tym samym centrum danych. Ta akcja znacząco skraca czas migracji bazy danych SQL, ponieważ transfer odbywa się w tym samym centrum danych. Kontener w innym centrum danych nie blokuje migracji, ale transfer trwa dłużej i może powodować naliczanie opłat za transfer danych.

Aby uzyskać więcej informacji, zobacz temat Tworzenie konta.

Konfigurowanie rozliczeń

Podczas migracji organizacji usług Azure DevOps nowa organizacja otrzymuje okres prolongaty. Wykorzystaj ten czas, aby zakończyć wszystkie kroki i poprawić przypisania licencji. Jeśli uważasz, że możesz zakupić więcej planów użytkownika, potoków wdrożeń lub kompilacji, albo hostowanych usług kompilacji, upewnij się, że masz subskrypcję Azure gotową do połączenia z Twoją zmigrowaną organizacją. Okres prolongaty kończy się w pierwszym dniu następnego miesiąca po zakończeniu migracji.

Faza po migracji przypomina, kiedy należy wykonać łączenie. Ten krok przygotowawczy polega na upewnieniu się, że wiesz, którą subskrypcję Azure używasz w późniejszym kroku. Aby uzyskać więcej informacji, zobacz Konfigurowanie rozliczeń dla organizacji.

Następny krok

Treści powiązane

• Migracja do usług Azure DevOps Services
• Wykonywanie zadań po migracji