Vorbereitung der Migration von Testläufen

Dieser Artikel konzentriert sich auf die Teamvorbereitung und die Generierung von Dateien, die vom Datenmigrationstool benötigt werden.

Voraussetzungen

Führen Sie die Validierungsphase durch, bevor Sie mit der Vorbereitung der Testausführungsmigration beginnen.

Generieren von Migrationseinstellungen

Generieren Sie die Migrationsspezifikation und die zugehörigen Dateien, um die Migration Ihrer Sammlungsdatenbank in die Warteschlange zu stellen.

1. Führen Sie den Befehl "Datenmigrationstool vorbereiten" mit den folgenden Parametern aus:

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

   • Verwenden Sie die Option "Mandantendomänenname" als Namen des Microsoft Entra ID Mandanten Ihres Unternehmens.
   • Der Befehl "Vorbereiten" erfordert Internetzugriff. Wenn Ihre Azure DevOps Server keine Internetverbindung hat, führen Sie den Befehl von einem anderen Computer aus.
   • Der Begriff "Organisationsregion" bezieht sich auf den Speicherort, an dem Sie Ihre Sammlung in Azure DevOps Services migrieren möchten. Sie haben zuvor einen Bereich ausgewählt und dessen Kurzcode aufgezeichnet. Verwenden Sie diesen Code im Befehl "Vorbereiten".

2. Melden Sie sich mit einem Benutzer vom Mandanten an, der über die Berechtigung zum Lesen von Informationen zu allen Benutzern im Microsoft Entra ID Mandanten verfügt.

Konfigurieren der Migrationsspezifikationsdatei

Die Migrationsspezifikationsdatei ist eine JSON-Datei, die das Datenmigrationstool anweist, wie die folgenden Aktionen ausgeführt werden:

• Konfigurieren Ihrer migrierten Organisation
• Geben Sie die Quellorte an
• Anpassen der Migration

Viele der Felder werden während des Vorbereitungsschritts automatisch ausgefüllt, aber Sie müssen die folgenden Felder konfigurieren:

• Name der Organisation: Der Name der Organisation, die Sie zum Migrieren Ihrer Daten erstellen möchten.
• Location: Eine Sicherung Ihrer Datenbank- und Migrationsdateien zum Hochladen in einen Azure Speichercontainer. Dieses Feld gibt den SAS-Schlüssel an, der vom Migrationstool zum sicheren Herstellen einer Verbindung mit den Quelldateien aus dem Azure-Speichercontainer verwendet wird. Das Erstellen des Speichercontainers wird später in Phase 5 behandelt und das Generieren eines SAS-Schlüssels wird in Phase 6 behandelt, bevor Sie mit einer neuen Migration beginnen.
• DACPAC: Eine Datei, die die SQL-Datenbank Ihrer Sammlung packt.
• Migrationstyp: Testlauf oder Produktionslauf.

Jede Migrationsspezifikationsdatei ist für eine einzelne Sammlung vorgesehen. Wenn Sie versuchen, eine Migrationsspezifikationsdatei zu verwenden, die für eine andere Sammlung generiert wurde, wird die Migration nicht gestartet. Sie müssen eine Testausführung für jede Sammlung vorbereiten, die Sie migrieren möchten, und die generierte Migrationsspezifikationsdatei verwenden, um die Migration in die Warteschlange zu stellen.

Überprüfen Sie die Identitätszuordnungsprotokolldatei

Das Identitätszuordnungsprotokoll ist entscheidend, ebenso wichtig wie die tatsächlichen Daten, die Sie migrieren. Wenn Sie die Protokolldatei untersuchen, verstehen Sie, wie Identitätsmigration und mögliche Ergebnisse funktionieren. Wenn Sie eine Identität migrieren, kann sie entweder aktiv oder historisch sein. Aktive Identitäten können sich bei Azure DevOps Services anmelden, während historische Identitäten nicht möglich sind. Der Dienst entscheidet, welcher Typ verwendet wird.

Aktive Identitäten

Aktive Identitäten beziehen sich auf Benutzeridentitäten in Azure DevOps Services nach der Migration. In Azure DevOps Services werden diese Identitäten lizenziert und als Benutzer in der Organisation angezeigt. Die Identitäten werden in der Spalte "Erwarteter Importstatus " in der Identitätszuordnungsprotokolldatei als aktiv markiert.

Historische Identitäten

Die Identitätszuordnungsprotokolldatei zeigt historische Identitäten in der Spalte "Erwarteter Importstatus " an. Identitäten ohne Zeileneintrag in der Datei werden ebenfalls historisch. Ein Beispiel für eine Identität ohne Zeileneintrag kann ein Mitarbeiter sein, der nicht mehr in einem Unternehmen arbeitet.

Im Gegensatz zu aktiven Identitäten, historische Identitäten:

• Nach der Migration haben Sie keinen Zugriff auf eine organization.
• Sie verfügen nicht über Lizenzen.
• Nicht als Benutzer in der Organisation angezeigt werden. Es bleibt nur das Konzept des Namens dieser Identität in der Organisation erhalten, damit der Verlauf später durchsucht werden kann. Verwenden Sie historische Identitäten für Benutzer, die nicht mehr im Unternehmen arbeiten oder keinen weiteren Zugriff auf die Organisation benötigen.

Lizenzen

Während der Migration weist der Prozess automatisch Lizenzen für alle Benutzer zu, die in der Spalte "Erwarteter Importstatus" des Identitätszuordnungsprotokolls als aktiv angezeigt werden. Wenn die automatische Lizenzzuweisung falsch ist, können Sie sie ändern, indem Sie die Zugriffsebene eines oder mehrerer Benutzer nach Abschluss der Migration bearbeiten.

Die Aufgabe ist möglicherweise nicht immer perfekt, sodass Sie bis zum ersten des folgenden Monats lizenzen nach Bedarf neu zuweisen müssen. Wenn Sie bis zum ersten des nächsten Monats kein Abonnement mit Ihrer Organisation verknüpfen und die richtige Anzahl von Lizenzen erwerben, werden alle Ihre Nachfristlizenzen widerrufen. Wenn die automatische Zuweisung mehr Lizenzen zugewiesen hat, als Sie für den nächsten Monat erworben haben, werden Sie für die zusätzlichen Lizenzen nicht in Rechnung gestellt, aber alle nicht bezahlten Lizenzen werden widerrufen.

Um den Verlust des Zugriffs zu vermeiden, verknüpfen Sie ein Abonnement und erwerben Sie erforderliche Lizenzen vor dem Ersten des Monats, da die Abrechnung monatlich erfolgt. Für alle Testläufe sind Lizenzen kostenlos, solange die Organisation aktiv ist.

Azure DevOps Abonnements

Visual Studio-Abonnements werden für Migrationen nicht standardmäßig zugewiesen. Stattdessen werden Benutzer mit Visual Studio-Abonnements automatisch aktualisiert, um diese Lizenz zu verwenden. Wenn die Arbeitsorganisation eines Benutzers ordnungsgemäß verknüpft ist, wendet Azure DevOps Dienste automatisch ihre Visual Studio Abonnementvorteile für die erste Anmeldung nach der Migration an.

Sie müssen keine Testausführungsmigration wiederholen, wenn Benutzer nicht automatisch aktualisiert werden, um ihr Visual Studio-Abonnement in Azure DevOps Services zu verwenden. Visual Studio-Abonnementverknüpfung erfolgt außerhalb des Rahmens einer Migration. Wenn die Arbeitsorganisation vor oder nach der Migration ordnungsgemäß verknüpft wird, wird die Lizenz automatisch für die nächste Anmeldung aktualisiert. Nachdem sie aktualisiert wurden, wird beim nächsten Migrieren des Benutzers bei der ersten Anmeldung bei der Organisation automatisch ein Upgrade ausgeführt.

Zugriff nur auf Azure DevOps Services-IPs einschränken

• Option 1: Diensttags verwenden
• Option 2: IP-Liste verwenden

Beschränken Sie den Zugriff auf Ihr Azure Storage Konto nur auf IPs von Azure DevOps Services. Sie können den Zugriff einschränken, indem Sie nur Verbindungen von Azure DevOps Services-IPs zulassen, die am Migrationsprozess der Sammlungsdatenbank beteiligt sind. Die IPs, die Zugriff auf Ihr Speicherkonto benötigen, hängen von der Region ab, zu der Sie migrieren.

Option 1: Diensttags verwenden

Sie können problemlos Verbindungen von allen Azure DevOps Services-Regionen zulassen, indem Sie das azuredevops-Dienst-Tag entweder über das Portal oder programmgesteuert zu Ihren Netzwerksicherheitsgruppen oder Firewalls hinzufügen.

Option 2: IP-Liste verwenden

Verwenden Sie den Befehl IpList, um die Liste der Ip-Adressen abzurufen, die Zugriff benötigen, um Verbindungen aus einer bestimmten region Azure DevOps Services zuzulassen.

Die Hilfedokumentation enthält Anweisungen und Beispiele für die Ausführung von Migrator sowohl auf der Azure DevOps Server-Instanz selbst als auch auf einem Remotecomputer. Wenn Sie den Befehl über eine der Anwendungsebenen der Azure DevOps Server Instanz ausführen, sollte der Befehl die folgende Struktur aufweisen:

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

Sie können die Liste der Ip-Adressen entweder über das Portal oder programmgesteuert zu Ihren Netzwerksicherheitsgruppen oder Firewalls hinzufügen.

Konfigurieren von IP-Firewall-Ausnahmen für SQL-Azure

In diesem Abschnitt wird die Konfiguration von Firewall-Ausnahmen für SQL-Azure behandelt. Informationen zu DACPAC-Migrationen finden Sie unter Configure Azure Storage Firewalls und virtuellen Netzwerken.

Das Datenmigrationstool erfordert, dass Sie die Azure DevOps-Dienst-IPs nur für eingehende Verbindungen auf Port 1433 konfigurieren.

Führen Sie die folgenden Schritte aus, um Ausnahmen für die erforderlichen IPs zu gewähren, die die Azure Netzwerkschicht für Ihre SQL-Azure-VM verarbeitet:

1. Melden Sie sich beim Azure-Portal an.
2. Wechseln Sie zu Ihrer SQL-Azure-VM.
3. Wählen Sie unter Einstellungen die Option Netzwerk.
4. Wählen Sie Regel für eingehenden Port hinzufügen aus.
5. Wählen Sie "Erweitert" aus, um eine eingehende Portregel für eine bestimmte IP zu konfigurieren.
6. Wählen Sie in der Dropdownliste " Quelle " die Option "IP-Adressen" aus. Geben Sie eine IP-Adresse ein, die eine Ausnahme benötigt. Legen Sie den Zielportbereich auf 1433. Geben Sie im Feld "Name " einen Namen ein, der die Ausnahme, die Sie konfigurieren, am besten beschreibt.

Je nach anderen konfigurierten eingehenden Portregeln müssen Sie möglicherweise die Standardpriorität für die ausnahmen von Azure DevOps Services ändern, sodass sie nicht ignoriert werden. Wenn Sie beispielsweise eine Regel "Für alle eingehenden Verbindungen mit 1433 verweigern" mit einer höheren Priorität als Ihre Azure DevOps Services-Ausnahmen haben, kann das Datenmigrationstool möglicherweise keine erfolgreiche Verbindung mit Ihrer Datenbank herstellen.

Fügen Sie weiterhin eingehende Portregeln hinzu, bis alle erforderlichen Azure DevOps Service-IPs ausgenommen sind. Fehlende IP-Adresse kann dazu führen, dass die Migration nicht gestartet werden konnte.

Migrieren großer Sammlungen

Bei Datenbanken, vor denen das Datenmigrationstool aufgrund ihrer Größe warnt, ist ein anderer Datenverpackungsansatz erforderlich, um zu Azure DevOps Services zu migrieren. Wenn Sie nicht sicher sind, ob Ihre Sammlung den Größenschwellenwert überschreitet, führen Sie eine Überprüfung des Datenmigrationstools für die Sammlung aus. Die Überprüfung informiert Sie darüber, ob Sie die SQL-Azure VM-Methode für die Migration verwenden müssen.

Ermitteln, ob Sie die Sammlungsgröße reduzieren können

Überprüfen Sie, ob Sie alte Daten bereinigen können. Im Laufe der Zeit können Sammlungen große Datenmengen ansammeln. Dieses Wachstum ist ein natürlicher Bestandteil des DevOps-Prozesses, aber Möglicherweise müssen Sie nicht alle Daten aufbewahren. Einige übliche Beispiele für nicht mehr relevante Daten sind veraltete Arbeitsbereiche und Buildergebnisse.

Das Datenmigrationstool überprüft Ihre Sammlung und vergleicht sie mit den zuvor erwähnten Grenzwerten. Anschließend wird gemeldet, ob Ihre Sammlung für die DACPAC- oder SQL-Migrationsmethode geeignet ist. Wenn Ihre Sammlung im Allgemeinen klein genug ist, um in die DACPAC-Grenzwerte zu passen, können Sie den schnelleren und einfacheren DACPAC-Ansatz verwenden. Wenn Ihre Sammlung jedoch zu groß ist, müssen Sie die SQL-Migrationsmethode verwenden, bei der eine SQL-Azure VM eingerichtet und die Datenbank manuell migriert wird.

Größenbeschränkungen

Die aktuellen Limits lauten wie folgt:

• 150 GB Gesamtdatenbankgröße (Datenbankmetadaten + Blobs) für DACPAC. Wenn Sie diesen Grenzwert überschreiten, müssen Sie die SQL-Migrationsmethode ausführen.
• 30 GB einzelne Tabellengröße (Datenbankmetadaten + Blobs) für DACPAC. Wenn eine einzelne Tabelle diesen Grenzwert überschreitet, müssen Sie die SQL-Migrationsmethode ausführen.
• Größe der 1.536-GB-Datenbankmetadaten für die SQL-Migrationsmethode. Wenn Sie diesen Grenzwert überschreiten, wird eine Warnung ausgegeben. Um eine erfolgreiche Migration durchzuführen, bleiben Sie unter dieser Größe.
• Größe der 2.048 GB großen Datenbankmetadaten für die SQL-Migrationsmethode. Das Überschreiten dieses Grenzwerts führt zu einem Fehler, sodass Sie keine Migration durchführen können.
• Kein Grenzwert für BLOB-Größen für die SQL-Migrationsmethode.

Wenn Sie ältere, nicht mehr relevante Artefakte bereinigen, entfernen Sie möglicherweise mehr Platz als erwartet. Diese Bereinigung kann bestimmen, ob Sie die DACPAC-Migrationsmethode oder eine SQL-Azure-VM verwenden.

Wenn Sie sich unter dem DACPAC-Schwellenwert befinden, befolgen Sie die Anweisungen zum Generieren eines DACPAC für die Migration. Wenn Sie die Datenbank immer noch nicht unter dem DACPAC-Schwellenwert abrufen können, müssen Sie eine SQL-Azure VM einrichten, um zu Azure DevOps Services zu migrieren.

Einrichten einer SQL-Azure-VM für die Migration zu Azure DevOps Services

Führen Sie die folgenden allgemeinen Schritte aus, um einen SQL-Azure virtuellen Computer (VM) einzurichten, der zu Azure DevOps Services migriert werden soll.

1. Setup a SQL Azure VM
2. Konfigurieren von IP-Firewall-Ausnahmen
3. Wiederherstellen der Datenbank auf dem virtuellen Computer
4. Konfigurieren Ihrer Sammlung für die Migration
5. Konfigurieren der Migrationsspezifikationsdatei für den virtuellen Computer

Einrichten einer SQL-Azure-VM

Sie können eine SQL-Azure VM schnell über das Azure-Portal einrichten. Weitere Informationen finden Sie unter Verwenden Sie das Azure-Portal, um eine Windows-VM mit SQL Server bereitzustellen.

Die Leistung Ihrer SQL-Azure VM und angefügter Datenträger wirkt sich erheblich auf die Leistung der Migration aus. Führen Sie aus diesem Grund die folgenden Aufgaben aus:

• Wählen Sie eine VM-Größe von mindestens D8s_v5_* aus.
• Verwaltete Datenträger verwenden.
• Sehen Sie sich die Leistung des virtuellen Computers und der Datenträger an. Stellen Sie sicher, dass Ihre Infrastruktur so konfiguriert ist, dass die VM-IOPS (Eingabe/Ausgabe pro Sekunde) und Speicher-IOPS nicht zu einem Engpass bei der Leistung der Migration werden. Stellen Sie beispielsweise sicher, dass die Anzahl der an Ihre VM angefügten Datenträger ausreicht, um die IOPS von der VM zu unterstützen.

Azure DevOps Services sind in mehreren Azure Regionen auf der ganzen Welt verfügbar. Um sicherzustellen, dass die Migration erfolgreich gestartet wird, ist es wichtig, Ihre Daten in der richtigen Region zu platzieren. Wenn Sie Ihre SQL-Azure VM an einem falschen Speicherort einrichten, kann die Migration nicht gestartet werden.

Wenn Sie diese Migrationsmethode verwenden, erstellen Sie Ihren virtuellen Computer in einer unterstützten Region. Obwohl Azure DevOps Services in mehreren Regionen im USA (USA) verfügbar ist, akzeptiert nur die Region "Central USA" neue Organisationen. Sie können Ihre Daten jetzt nicht in andere US-Azure Regionen migrieren.

Verwenden Sie die folgenden SQL-Azure-VM-Konfigurationen:

• Konfigurieren Sie die temporäre SQL-Datenbank so, dass ein anderes Laufwerk als Laufwerk C verwendet wird. Im Idealfall sollte das Laufwerk ausreichend freien Speicherplatz haben, mindestens gleichbedeutend mit der größten Tabelle Ihrer Datenbank.
• Wenn Ihre Quelldatenbank noch über 1 Terabyte (TB) liegt, nachdem Sie die Größe reduziert haben, müssen Sie mehr 1 TB Datenträger anfügen und sie in einer einzigen Partition kombinieren, um Ihre Datenbank auf dem virtuellen Computer wiederherzustellen.
• Wenn Ihre Sammlungsdatenbanken mehr als 1 TB groß sind, sollten Sie eine SSD (Festkörperfestlaufwerke) sowohl für die temporäre Datenbank als auch für die Sammlungsdatenbank verwenden. Ziehen Sie außerdem die Verwendung größerer VMs mit 16 virtuellen CPUs (vCPUs) und 128 GB (Gigabyte) ram (Random Access Memory) in Betracht.

Wiederherstellen der Datenbank auf dem virtuellen Computer

Nachdem Sie einen Azure virtuellen Computer eingerichtet und konfiguriert haben, müssen Sie ihre getrennten Sicherungen von Ihrer Azure DevOps Server Instanz auf Ihren Azure virtuellen Computer übernehmen. Die Sammlungsdatenbank muss in Ihrer SQL-Instanz wiederhergestellt werden und erfordert nicht, dass Azure DevOps Server auf dem virtuellen Computer installiert werden.

Konfigurieren Ihrer Sammlung für die Migration

Konfigurieren Sie nach dem Wiederherstellen der Sammlungsdatenbank auf ihrem Azure virtuellen Computer eine SQL-Authentifizierung, damit Azure DevOps Dienste eine Verbindung mit der Datenbank herstellen und die Daten migrieren können. Diese Authentifizierung gewährt nur lesezugriff auf eine Datenbank.

1. Öffnen Sie SQL Server Management Studio auf dem virtuellen Computer, und öffnen Sie dann ein neues Abfragefenster für die Datenbank, die Sie migrieren möchten.

2. Legen Sie das Wiederherstellungsmodell der Datenbank auf "einfach" fest:

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

3. Erstellen Sie eine SQL-Authentifizierung für die Datenbank, und weisen Sie diese Authentifizierung der TFSEXECROLE Rolle zu, wie im folgenden Beispiel gezeigt.

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

Sehen Sie sich das folgende Beispiel des SQL-Befehls an:

    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'

Konfigurieren Sie die Migrationsspezifikationsdatei, um den virtuellen Computer zu adressieren.

Aktualisieren Sie die Migrationsspezifikationsdatei, um Informationen zum Herstellen einer Verbindung mit der SQL Server-Instanz einzuschließen. Öffnen Sie Die Migrationsspezifikationsdatei, und nehmen Sie die folgenden Aktualisierungen vor:

1. Entfernen Sie den DACPAC-Parameter aus dem Quelldateiobjekt. Die Migrationsspezifikation vor der Änderung sieht wie der folgende Beispielcode aus.

   

   Die Migrationsspezifikation nach der Änderung sieht wie der folgende Beispielcode aus.

   

2. Geben Sie die erforderlichen Parameter ein, und fügen Sie das folgende Eigenschaftenobjekt in Ihrem Quellobjekt in der Spezifikationsdatei hinzu.

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

Nachdem Sie die Änderungen angewendet haben, sieht die Migrationsspezifikation wie im folgenden Beispiel aus.

Ihre Migrationsspezifikation ist jetzt für die Verwendung einer SQL-Azure-VM für die Migration konfiguriert. Fahren Sie mit den restlichen Vorbereitungsschritten für die Migration fort. Achten Sie nach Abschluss der Migration darauf, die SQL-Anmeldung zu löschen oder das Kennwort zu drehen. Microsoft behält die Anmeldeinformationen nach Abschluss der Migration nicht bei.

Erstellen eines Azure Storage Containers im ausgewählten Rechenzentrum

Die Verwendung des Datenmigrationstools für Azure DevOps erfordert, dass ein Azure Storage Container im selben Azure Rechenzentrum wie die endgültige Azure DevOps Services-Organisation vorhanden ist. Wenn Sie beispielsweise beabsichtigen, dass Ihre Azure DevOps Services-Organisation im zentralen USA Rechenzentrum erstellt werden soll, erstellen Sie den Azure Storage Container im selben Rechenzentrum. Diese Aktion beschleunigt drastisch die Zeit, die zum Migrieren der SQL-Datenbank benötigt wird, da die Übertragung innerhalb desselben Rechenzentrums erfolgt.

Weitere Informationen finden Sie unter Erstellen eines Speicherkontos.

Einrichten der Abrechnung

Wenn Sie eine Azure DevOps Services-Organisation migrieren, erhält die neue Organisation eine Nachfrist. Verwenden Sie diese Zeit, um alle Schritte abzuschließen und Lizenzzuweisungen zu korrigieren. Wenn Sie denken, dass Sie möglicherweise weitere Benutzerpläne, Build- oder Bereitstellungspipelinen oder gehostete Builddienste erwerben möchten, stellen Sie sicher, dass Sie über ein Azure Abonnement verfügen, das für die Verknüpfung mit Ihrer migrierten Organisation bereit ist. Die Nachfrist endet am ersten Tag des folgenden Monats, nachdem Sie die Migration abgeschlossen haben.

Die Phase nach der Migration erinnert Sie daran, wann die Verknüpfung erfolgt. Dieser Vorbereitungsschritt besteht darin, sicherzustellen, dass Sie wissen, welches Azure Abonnement Sie in diesem späteren Schritt verwenden. Weitere Informationen finden Sie unter Einrichten der Abrechnung für Ihre Organisation.

Nächste Schritte

Verwandte Inhalte

• Migrate to Azure DevOps Services
• Ausführen von Aufgaben nach der Migration