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 przebiegu testowego ukończ fazę Walidacja.

Generowanie ustawień migracji

Wykonaj poniższe kroki, aby wygenerować 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

   • Opcja nazwy domeny dzierżawy to nazwa dzierżawy firmy Microsoft Entra ID.
   • Polecenie prepare wymaga dostępu do Internetu. Jeśli serwer 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 Services. 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 wykonywać następujące akcje.

• 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.
• Lokalizacja: kopia zapasowa plików bazy danych i migracji, które mają zostać przekazane do kontenera usługi Azure Storage. To pole określa klucz sygnatury dostępu współdzielonego używany przez narzędzie migracji do bezpiecznego nawiązywania połączenia i odczytywania plików źródłowych z kontenera usługi Azure Storage. Tworzenie kontenera magazynu jest omówione w dalszej części fazy 5 i generowanie klucza sygnatury dostępu współdzielonego jest omówione w fazie 6 przed kolejką na potrzeby 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ć przebieg testu dla każdej kolekcji, którą chcesz migrować, i użyć wygenerowanego pliku specyfikacji migracji do kolejki migracji.

Przeglądanie pliku dziennika mapy tożsamości

Dziennik mapy tożsamości ma kluczowe znaczenie, ponieważ rzeczywiste dane są migrowane. Podczas badania pliku dziennika zrozumiesz, jak funkcje migracji tożsamości i potencjalne wyniki. Migracja tożsamości może być aktywna lub historyczna. Aktywne tożsamości mogą logować się do usług Azure DevOps Services, podczas gdy tożsamości historyczne nie mogą. Usługa decyduje, który typ jest używany.

Uwaga

Gdy tożsamość zostanie zmigrowana jako tożsamość historyczna, nie ma możliwości przekonwertowania jej na aktywną.

Aktywne tożsamości

Aktywne tożsamości odnoszą się do tożsamości użytkowników w usłudze Azure DevOps Services po migracji. W usłudze Azure DevOps Services te tożsamości są licencjonowane i wyświetlane jako użytkownicy w organizacji. Tożsamości są oznaczone jako aktywne w kolumnie Oczekiwany stan importu w pliku dziennika mapy tożsamości.

Tożsamości historyczne

Tożsamości historyczne są mapowane jako takie w kolumnie Oczekiwany stan importu w pliku dziennika mapy tożsamości. Tożsamości bez wpisu wiersza w pliku również stają się historyczne. Przykładem tożsamości bez wpisu wiersza może być pracownik, który nie pracuje już w firmie.

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

• Nie masz dostępu do organizacji po migracji.
• Nie masz licencji.
• Nie wyświetlaj się jako użytkownicy w organizacji. Wszystko, co się utrzymuje, to pojęcie nazwy tej tożsamości w organizacji, dzięki czemu jej historia może być przeszukiwana później. Zalecamy używanie 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.

Uwaga

Po migracji tożsamości jako historycznej nie można go uaktywnić.

Licencje

Podczas migracji licencje są przypisywane automatycznie dla wszystkich użytkowników wyświetlanych jako "aktywne" w kolumnie Oczekiwany stan importu dziennika mapowania tożsamości. Jeśli automatyczne przypisanie licencji jest nieprawidłowe, możesz ją 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 z następnych miesięcy należy ponownie przypisać licencje zgodnie z potrzebami. Jeśli po raz pierwszy w następnym miesiącu nie połączysz subskrypcji z organizacją i kupiono poprawną liczbę licencji, wszystkie licencje okresu prolongaty będą odwoływane. Alternatywnie, jeśli automatyczne przypisanie przypisano więcej licencji niż zakupione w przyszłym miesiącu, nie naliczamy opłat za dodatkowe licencje, ale odwołujemy wszystkie niezapłacone licencje.

Aby uniknąć utraty dostępu, zalecamy połączenie subskrypcji i zakup wymaganych licencji przed pierwszym miesiącem, ponieważ rozliczenia są uruchamiane co miesiąc. W przypadku wszystkich przebiegów testowych licencje są bezpłatne, o ile organizacja jest aktywna.

Subskrypcje usługi Azure DevOps

Subskrypcje programu Visual Studio nie są domyślnie przypisywane do migracji. Zamiast tego użytkownicy z subskrypcjami programu Visual Studio automatycznie otrzymują uaktualnienie do korzystania z tej licencji. Jeśli organizacja służbowa użytkownika jest poprawnie połączona, usługa Azure DevOps Services automatycznie stosuje swoje korzyści z subskrypcji programu Visual Studio podczas pierwszej migracji logowania.

Nie musisz powtarzać migracji przebiegu testowego, jeśli użytkownicy nie zostaną automatycznie uaktualnioni, aby korzystać z subskrypcji programu Visual Studio w usłudze Azure DevOps Services. Łączenie subskrypcji programu Visual Studio to coś, co dzieje się poza zakresem migracji. Jeśli organizacja robocza zostanie poprawnie połączona przed migracją lub po migracji, użytkownik automatycznie uaktualnił licencję podczas następnego logowania. Po uaktualnieniu użytkownik zostanie automatycznie uaktualniony po pierwszym zalogowaniu się do organizacji.

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

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

Ogranicz dostęp do konta usługi 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 Services, które są zaangażowane w proces migracji bazy danych kolekcji. Adresy IP, które muszą mieć dostęp do konta magazynu, zależą od regionu, do którego przeprowadzasz migrację.

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

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

Opcja 2. Użyj listy adresów IP

IpList Użyj polecenia , aby uzyskać listę adresów IP, którym należy udzielić dostępu, aby zezwolić na połączenia z określonego regionu usługi Azure DevOps Services.

W dokumentacji pomocy znajdują się instrukcje i przykłady uruchamiania narzędzia Migrator z samego wystąpienia usługi Azure DevOps Server i maszyny zdalnej. Jeśli uruchamiasz polecenie z jednej z warstw aplikacji wystąpienia usługi 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 Usługi SQL Azure

Ta sekcja dotyczy tylko konfigurowania wyjątków zapory dla Usługi SQL Azure. Aby uzyskać informacje na temat migracji pakietu DACPAC, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

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

Wykonaj następujące kroki, aby udzielić wyjątków dla niezbędnych adresów IP obsługiwanych w warstwie sieci platformy Azure dla maszyny wirtualnej Usługi SQL Azure.

1. Zaloguj się w witrynie Azure Portal.
2. Przejdź do maszyny wirtualnej Usługi SQL Azure.
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 musi otrzymać wyjątek, ustaw zakres portów docelowych na 1433 i 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że być konieczne zmianę domyślnego priorytetu wyjątków usługi Azure DevOps Services, aby nie były ignorowane. Jeśli na przykład masz regułę "odmów dla wszystkich połączeń przychodzących do 1433" z wyższym priorytetem niż wyjątki usługi Azure DevOps Services, 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 przychodzących, dopóki wszystkie niezbędne adresy IP usług Azure DevOps Services nie otrzymają wyjątku. Brak jednego adresu IP może spowodować niepowodzenie uruchomienia migracji.

Migrowanie dużych kolekcji

W przypadku baz danych ostrzeganych przez narzędzie do migracji danych jest zbyt duże, do migracji do usług Azure DevOps Services jest wymagane inne podejście do tworzenia pakietów danych. Jeśli nie masz pewności, czy kolekcja przekracza próg rozmiaru, należy uruchomić walidację narzędzia do migracji danych w kolekcji. Walidacja informuje o konieczności użycia metody Usługi SQL Azure maszyny wirtualnej do migracji.

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

Sprawdź, czy możesz wyczyścić stare dane. W czasie kolekcje mogą tworzyć 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 przestawnych danych to starsze obszary robocze i wyniki kompilacji.

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, chodzi o to, że 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 Usługi SQL Azure maszyny wirtualnej i ręczne migrowanie bazy danych.

Limity rozmiarów

Bieżące limity to:

• 150 GB całkowitego rozmiaru bazy danych (metadanych bazy danych i obiektów blob) dla pakietu DACPAC, jeśli przekroczysz ten limit, musisz wykonać metodę migracji SQL.
• 30 GB rozmiaru pojedynczej tabeli (metadanych bazy danych i obiektów blob) dla pakietu DACPAC, jeśli którakolwiek pojedyncza tabela przekroczy ten limit, należy wykonać metodę migracji SQL.
• Rozmiar metadanych bazy danych 1536 GB dla metody migracji SQL. Przekroczenie tego limitu powoduje ostrzeżenie. Zalecamy, aby zachować ten rozmiar w celu pomyślnej migracji.
• Rozmiar metadanych bazy danych 2048 GB 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że usunąć o wiele więcej miejsca niż można się spodziewać i określić, czy używasz metody migracji DACPAC, czy Usługi SQL Azure maszyny wirtualnej.

Ważne

Po usunięciu starszych danych nie można go odzyskać, chyba że przywrócisz starszą kopię zapasową kolekcji.

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ą Usługi SQL Azure w celu przeprowadzenia migracji do usług Azure DevOps Services.

Konfigurowanie maszyny wirtualnej Usługi SQL Azure do migrowania do usług Azure DevOps Services

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

1. Konfigurowanie maszyny wirtualnej Usługi SQL Azure
2. Konfigurowanie wyjątków zapory adresów 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 Usługi SQL Azure

Maszynę wirtualną Usługi SQL Azure można skonfigurować szybko w witrynie Azure Portal. Aby uzyskać więcej informacji, zobacz Aprowizuj maszynę wirtualną z systemem Windows przy użyciu programu SQL Server przy użyciu witryny Azure Portal.

Wydajność maszyny wirtualnej Usługi SQL Azure i dołączonych dysków danych ma znaczący wpływ na wydajność migracji. Z tego powodu zdecydowanie zalecamy wykonywanie następujących zadań:

• 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 tak, aby liczba operacji we/wy na sekundę (wejście/wyjście) maszyny wirtualnej i liczba operacji we/wy na sekundę nie stała się wąskim gardłem w zakresie wydajności migracji. Na przykład upewnij się, że liczba dysków danych dołączonych do maszyny wirtualnej jest wystarczająca do obsługi operacji we/wy na sekundę z maszyny wirtualnej.

Usługi Azure DevOps Services są dostępne w kilku regionach świadczenia usługi Azure na całym świecie. Aby upewnić się, że migracja zostanie pomyślnie uruchomiona, niezwykle ważne jest umieszczenie danych w odpowiednim regionie. Jeśli skonfigurujesz maszynę wirtualną Usługi SQL Azure w niewłaściwej lokalizacji, migracja nie powiedzie się.

Ważne

Maszyna wirtualna platformy Azure wymaga publicznego adresu IP.

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

Uwaga

Klienci pakietu DACPAC powinni zapoznać się z tabelą regionów w sekcji "Krok 3: Przekazywanie pliku DACPAC](migration-test-run.md#)". Powyższe wytyczne dotyczą tylko Usługi SQL Azure maszyn wirtualnych. Jeśli jesteś klientem DACPAC, zobacz obsługiwane regiony platformy Azure na potrzeby migracji.

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

• Skonfiguruj tymczasową bazę danych SQL tak, aby korzystała z dysku innego niż dysk C. Najlepiej, aby dysk miał dużo wolnego miejsca; co najmniej odpowiada 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 skonfigurowaniu i skonfigurowaniu maszyny wirtualnej platformy Azure należy podjąć odłączone tworzenie kopii zapasowej z wystąpienia usługi Azure DevOps Server na maszynę wirtualną platformy Azure. Baza danych kolekcji musi zostać przywrócona w wystąpieniu SQL i nie wymaga zainstalowania programu Azure DevOps Server na maszynie wirtualnej.

Konfigurowanie kolekcji na potrzeby migracji

Po przywróceniu bazy danych kolekcji na maszynie wirtualnej platformy Azure skonfiguruj logowanie SQL, aby umożliwić usłudze Azure DevOps Services łączenie się z bazą danych w celu migracji danych. To logowanie umożliwia dostęp tylko do odczytu do pojedynczej bazy danych.

1. Otwórz program SQL Server Management Studio na maszynie wirtualnej, a następnie otwórz nowe okno zapytania względem bazy danych, która ma zostać zmigrowana.

2. Ustaw odzyskiwanie bazy danych na proste:

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

3. Utwórz logowanie SQL dla bazy danych i przypisz to logowanie "TFSEXECROLE", jak 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 = 'fabrikamimport1!' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Ważne

Włącz tryb uwierzytelniania programu SQL Server i systemu Windows w programie SQL Server Management Studio na maszynie wirtualnej. Jeśli nie włączysz trybu uwierzytelniania, migracja zakończy się niepowodzeniem.

Konfigurowanie pliku specyfikacji migracji w celu kierowania maszyny wirtualnej

Zaktualizuj plik specyfikacji migracji, aby uwzględnić informacje o sposobie nawiązywania połączenia z wystąpieniem programu 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 Usługi SQL Azure maszyny wirtualnej 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. Firma Microsoft nie zachowuje informacji logowania po zakończeniu migracji.

Tworzenie kontenera usługi Azure Storage w wybranym centrum danych

Użycie narzędzia do migracji danych dla usługi Azure DevOps wymaga posiadania kontenera usługi Azure Storage w tym samym centrum danych platformy Azure co ostateczna organizacja usługi Azure DevOps Services. Jeśli na przykład zamierzasz utworzyć organizację usługi Azure DevOps Services w centrum danych Central Stany Zjednoczone, utwórz kontener usługi 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.

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

Konfigurowanie rozliczeń

Okres prolongaty jest umieszczany w nowo zmigrowanej organizacji usługi Azure DevOps Services, aby umożliwić zespołowi zakończenie wszelkich kroków, których potrzebuje, i poprawne przypisanie licencji. Jeśli przewidujesz, że chcesz kupić więcej planów użytkowników, potoków kompilacji lub wdrażania, hostowanych usług kompilacji, hostowanych usług testów obciążeniowych, na przykład zdecydowanie zalecamy, aby mieć subskrypcję platformy Azure gotową do łączenia się z zmigrowanej organizacji. Okres prolongaty kończy się w pierwszym dniu następnego miesiąca po zakończeniu migracji.

Przypominamy ci ponownie w fazie po migracji (link) dla tego, kiedy musisz wykonać połączenie. Ten krok przygotowania polega na upewnieniu się, że wiesz, która subskrypcja platformy Azure jest używana w tym późniejszym kroku. Aby uzyskać więcej informacji, zobacz Konfigurowanie rozliczeń dla organizacji.

Następne kroki

Przetestuj migrację przebiegów

Powiązane artykuły

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