Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden Voraussetzungen und Supportanforderungen zusammengefasst, wenn Sie lokale Server, die in einer Hyper-V Umgebung ausgeführt werden, ermitteln und bewerten, um die Migration zu Azure mithilfe des Tools Azure Migrate: Discovery and Assessment vorzubereiten. Wenn Sie Server migrieren möchten, die auf Hyper-V zu Azure ausgeführt werden, lesen Sie die migrationsunterstützungsmatrix.
Zum Einrichten der Ermittlung und Bewertung von Servern, die auf Hyper-V ausgeführt werden, erstellen Sie ein Projekt und fügen dem Projekt das Azure Migrate: Ermittlungs- und Bewertungstool hinzu. Nachdem das Tool hinzugefügt wurde, stellen Sie die Azure Migrate Appliance bereit. Die Appliance ermittelt kontinuierlich lokale Server und sendet Servermetadaten und Leistungsdaten an Azure. Nach Abschluss der Ermittlung ordnen Sie die ermittelten Server in Gruppen und führen eine Bewertung für eine Gruppe aus.
Einschränkungen
| Support | Einzelheiten |
|---|---|
| Bewertungseinschränkungen | Sie können bis zu 35.000 Server in einem einzelnen Projekt ermitteln und bewerten. |
| Projektgrenzen | Sie können mehrere Projekte in einem Azure-Abonnement erstellen. Neben Servern auf Hyper-V kann ein Projekt Server auf VMware und physischen Servern bis zu den Bewertungsgrenzwerten für jeden enthalten. |
| Ermittlung | Die Azure Migrate Appliance kann bis zu 5.000 Server ermitteln, die auf Hyper-V ausgeführt werden. Die Appliance kann eine Verbindung mit bis zu 300 Hyper-V Hosts herstellen. |
| Bewertung | Sie können einer einzelnen Gruppe bis zu 35.000 Server hinzufügen. Sie können in einem einzelnen Vorgang für eine Gruppe bis zu 35.000 Server bewerten. |
Hier erfahren Sie mehr über Bewertungen.
Hyper-V Hostanforderungen
| Support | Einzelheiten |
|---|---|
| Hyper-V-Host | Der Hyper-V-Host kann eigenständig oder in einem Cluster bereitgestellt werden. Der Hyper-V-Host kann Windows Server 2022, Windows Server 2019, Windows Server 2016 oder Windows Server 2012 R2 ausführen. Server Core-Installationen dieser Betriebssysteme werden ebenfalls unterstützt. Sie können server, die sich auf Hyper-V Hosts befinden, die Windows Server 2012 ausführen, nicht bewerten. |
| Berechtigungen | Sie benötigen Administratorberechtigungen für den Hyper-V Host. Wenn Sie keine Administratorberechtigungen zuweisen möchten, erstellen Sie ein lokales Benutzerkonto oder ein Domänenbenutzerkonto, und fügen Sie das Benutzerkonto zu diesen Gruppen hinzu: Remoteverwaltungsbenutzer, Hyper-V Administratoren und Leistungsmonitor Benutzer. |
| PowerShell-Remoting | PowerShell-Remoting muss auf jedem Hyper-V Host aktiviert sein. |
| Hyper-V-Replikat | Wenn Sie Hyper-V Replikat verwenden (oder mehrere Server mit denselben Serverbezeichnern haben), und Sie die ursprünglichen und replizierten Server mithilfe von Azure Migrate und Modernisieren ermitteln, ist die von Azure Migrate und Modernize generierte Bewertung möglicherweise nicht korrekt. |
Serveranforderungen
| Support | Einzelheiten |
|---|---|
| Betriebssystem | Alle Betriebssysteme können für die Migration ausgewertet werden. |
| Integration Services | Hyper-V Integrationsdienste müssen auf Servern ausgeführt werden, die Sie bewerten, um Betriebssysteminformationen zu erfassen. |
| Lagerung | Lokaler Datenträger, DAS, JBOD, Speicherplätze, CSV und SMB. Diese Hyper-V Hostspeicher, auf denen VHD/VHDX gespeichert werden, werden unterstützt. Virtuelle IDE- und SCSI-Controller werden unterstützt. |
Die Anforderungen für die Azure Migrate Appliance
Azure Migrate und Modernize verwendet die Azure Migrate Appliance für die Ermittlung und Bewertung. Sie können die Appliance mithilfe einer komprimierten Hyper-V VHD bereitstellen, die Sie aus dem Portal herunterladen, oder mithilfe eines PowerShell-Skripts. Weitere Informationen finden Sie unter:
- Erfahren Sie mehr über Appliance-Anforderungen für Hyper-V.
- Informationen zu den URLs, auf die die Appliance Zugriff benötigt, finden Sie unter URLs für die öffentliche Cloud und URLs für Azure Government-Clouds.
- Verwenden Sie das Skript, um das Appliance in Azure Government bereitzustellen.
Portzugriff
Die folgende Tabelle fasst die Portanforderungen für die Bewertung zusammen.
| Sicherungsmedium | Verbindung |
|---|---|
| Gerät | Eingehende Verbindungen an TCP-Port 3389, um Remotedesktopverbindungen mit der Appliance zu ermöglichen Eingehende Verbindungen an Port 44368, um über Remotezugriff mithilfe der URL https://<appliance-ip-or-name>:44368 auf die App zur Applianceverwaltung zugreifen zu können.Ausgehende Verbindungen über Port 443 (HTTPS), um Ermittlungs- und Leistungsmetadaten an Azure Migrate and Modernize zu senden. |
| Hyper-V-Host/Cluster | Eingehende Verbindungen nutzen standardmäßig den WinRM-Port 5986 (HTTPS). Wenn HTTPS-Voraussetzungen nicht auf den Zielservern konfiguriert sind, greift die Kommunikation auf WinRM-Port 5985 (HTTP) zurück, um Metadaten und Leistungsdaten für Hyper-V-Server mithilfe einer Common Information Model (CIM)-Sitzung zu sammeln. |
| Server | Windows Server benötigen Zugriff auf Port 5986 (HTTPS) oder Port 5985 (HTTP). Linux-Server benötigen Zugriff auf Port 22 (TCP), um Softwareinventar- und agentenlose Abhängigkeitsanalysen durchzuführen. |
Softwareinventarisierungsanforderungen
Zusätzlich zur Ermittlung von Servern kann die Azure Migrate-Ermittlung und -Bewertung Softwareinventarisierung für Server ausführen. Der Softwarebestand stellt die Liste der Anwendungen, Rollen und Features bereit, die auf Windows- und Linux-Servern ausgeführt werden, die mithilfe von Azure Migrate und Modernize ermittelt werden. Sie hilft bei der Ermittlung und Planung eines maßgeschneiderten Migrationspfads für Ihre lokalen Workloads.
| Support | Einzelheiten |
|---|---|
| Unterstützte Server | Sie können ein Softwareinventar auf bis zu 5.000 Servern durchführen, die auf Hyper-V-Hosts/-Clustern ausgeführt werden, die zu jedem Azure Migrate Appliance hinzugefügt werden. |
| Betriebssysteme | Alle Windows- und Linux-Versionen mit Hyper-V Integrationsdiensten aktiviert. |
| Serveranforderungen | Windows Server müssen PowerShell-Remoting aktiviert und PowerShell Version 2.0 oder höher installiert sein. WMI muss aktiviert und auf Windows Servern verfügbar sein, um die Details der auf den Servern installierten Rollen und Features zu erfassen. Für Linux-Server muss Secure Shell (SSH)-Konnektivität aktiviert und sichergestellt sein, dass die folgenden Befehle auf den Linux-Servern ausgeführt werden können, um die Anwendungsdaten zu pullen: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Je nach Betriebssystemtyp und dem Typ des verwendeten Paket-Managers gibt es noch einige weitere Befehle: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| Serverzugriff | Sie können mehrere Domänen und Nichtdomänenanmeldeinformationen (Windows/Linux) im Appliance-Konfigurations-Manager für den Softwarebestand hinzufügen. Sie müssen über ein Gastbenutzerkonto für Windows Server und ein Standardbenutzerkonto (nicht-sudo-Zugriff) für alle Linux-Server verfügen. |
| Portzugriff | Windows Server benötigen Zugriff auf Port 5986 (HTTPS) oder Port 5985 (HTTP). Linux-Server benötigen Zugriff auf Port 22 (TCP). Wenn Sie Domänenanmeldeinformationen verwenden, muss die Azure Migrate Appliance eine Verbindung mit den folgenden TCP- und UDP-Ports herstellen können: TCP 135 – RPC-Endpunkt TCP 389 – LDAP TCP 636 – LDAP SSL TCP 445 – SMB TCP/UDP 88 – Kerberos-Authentifizierung TCP/UDP 464 – Kerberos-Änderungsvorgänge |
| Ermittlung | Die Softwareinventarisierung erfolgt durch direkte Verbindung mit den Servern unter Verwendung der auf der Appliance hinzugefügten Server-Anmeldeinformationen. Die Appliance sammelt die Informationen zum Softwarebestand von Windows Servern mithilfe von PowerShell-Remoting und von Linux-Servern mithilfe der SSH-Verbindung. Softwareinventarisierung erfolgt ohne Agent. Auf den Servern wird kein Agent installiert. |
Anforderungen für SQL Server-Instanz und Datenbankerkennung
Software inventory identifiziert SQL Server Instanzen. Die Appliance verwendet diese Informationen und versucht, eine Verbindung mit den entsprechenden SQL Server Instanzen über die Windows-Authentifizierung oder SQL Server Authentifizierungsanmeldeinformationen herzustellen, die im Appliance-Konfigurations-Manager bereitgestellt werden. Die Appliance kann nur eine Verbindung mit den SQL Server Instanzen herstellen, mit denen sie über eine Netzwerklinie verfügt. Die Softwareinventarisierung allein benötigt möglicherweise keine Netzwerksichtverbindung.
Nachdem die Appliance verbunden wurde, sammelt sie Konfigurations- und Leistungsdaten für SQL Server Instanzen und Datenbanken. SQL Server Konfigurationsdaten werden alle 24 Stunden aktualisiert. Leistungsdaten werden alle 30 Sekunden erfasst.
| Support | Einzelheiten |
|---|---|
| Unterstützte Server | Wird nur für Server unterstützt, auf denen SQL Server in Ihren VMware-, Microsoft Hyper-V- und physischen/Bare-Metal-Umgebungen und Infrastruktur-as-a-Service (IaaS)-Servern anderer öffentlicher Clouds ausgeführt wird, z. B. Azure-Webdienste und Google Cloud Platform. Sie können bis zu 750 SQL Server Instanzen oder 15.000 SQL-Datenbanken ermitteln, je nachdem, welcher Wert kleiner ist, aus einer einzelnen Appliance. Es wird empfohlen, sicherzustellen, dass eine Appliance auf die Ermittlung von weniger als 600 Servern beschränkt ist, auf denen SQL ausgeführt wird, um Skalierungsprobleme zu vermeiden. |
| Windows-Server | Windows Server 2008 und höher werden unterstützt. |
| Linux-Server | Wird derzeit nicht unterstützt. |
| Authentifizierungsmechanismus | Sowohl Windows als auch SQL Server Authentifizierung werden unterstützt. Sie können im Appliance-Konfigurations-Manager Anmeldeinformationen für beide Authentifizierungstypen angeben. |
| SQL Server Zugriff | Zum Ermitteln von SQL Server-Instanzen und -Datenbanken erfordert das Windows-/Domänenkonto oder SQL Server-Konto diese niedrige Berechtigungsstufe von Leseberechtigungen für jede SQL Server-Instanz. Sie können das Dienstprogramm zur Bereitstellung von Konten mit niedrigen Berechtigungen verwenden, um benutzerdefinierte Konten zu erstellen oder ein vorhandenes Konto zu verwenden, das Mitglied der Sysadmin-Serverrolle ist. |
| SQL Server Versionen | SQL Server 2008 und höher werden unterstützt. |
| SQL Server Editionen | Die Enterprise, Standard, Developer und Express Edition werden unterstützt. |
| Unterstützte SQL-Konfiguration | Die Ermittlung eigenständiger, hochverfügbarer und notfallgeschützter SQL-Bereitstellungen wird unterstützt. Die Ermittlung von SQL-Bereitstellungen mit Hochverfügbarkeit und Notfallwiederherstellung, die von Always On-Failoverclusterinstanzen und Always On-Verfügbarkeitsgruppen wird ebenfalls unterstützt. |
| Unterstützte SQL-Dienste | Nur SQL Server-Datenbank-Engine wird unterstützt. Die Erkennung von SQL Server Reporting Services, SQL Server Integration Services und SQL Server Analysis Services wird nicht unterstützt. |
Hinweis
Standardmäßig verwendet Azure Migrate und Modernize die sicherste Methode zum Herstellen einer Verbindung mit SQL-Instanzen. Das heißt, Azure Migrate und Modernize verschlüsselt die Kommunikation zwischen der Azure Migrate Appliance und den Quell-SQL-Server-Instanzen, indem die Eigenschaft TrustServerCertificate auf true festgelegt wird. Zudem verwendet die Transportschicht Secure Socket Layer zum Verschlüsseln des Kanals und Umgehen der Zertifikatkette zur Überprüfung der Vertrauenswürdigkeit. Deshalb muss der Applianceserver so eingerichtet sein, dass er die Stammzertifizierungsstelle des Zertifikats als vertrauenswürdig einstuft.
Sie können die Verbindungseinstellungen jedoch ändern, indem Sie Edit SQL Server Verbindungseigenschaften in der Appliance auswählen. Hier erfahren Sie mehr, um zu verstehen, was Sie auswählen müssen.
Konfigurieren der benutzerdefinierten Anmeldung für SQL Server Discovery
Verwenden Sie die folgenden Beispielskripte zum Erstellen einer Anmeldung und Bereitstellen mit den erforderlichen Berechtigungen.
Windows-Authentifizierung
-- Create a login to run the assessment
use master;
DECLARE @SID NVARCHAR(MAX) = N'';
CREATE LOGIN [MYDOMAIN\MYACCOUNT] FROM WINDOWS;
SELECT @SID = N'0x'+CONVERT(NVARCHAR, sid, 2) FROM sys.syslogins where name = 'MYDOMAIN\MYACCOUNT'
IF (ISNULL(@SID,'') != '')
PRINT N'Created login [MYDOMAIN\MYACCOUNT] with SID = ' + @SID
ELSE
PRINT N'Login creation failed'
GO
-- Create a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
USE [?];
IF (''?'' NOT IN (''tempdb'',''model''))
BEGIN
DECLARE @is_secondary_replica BIT = 0;
IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
BEGIN
DECLARE @innersql NVARCHAR(MAX);
SET @innersql = N''
SELECT @is_secondary_replica = IIF(
EXISTS (
SELECT 1
FROM sys.availability_replicas a
INNER JOIN sys.dm_hadr_database_replica_states b
ON a.replica_id = b.replica_id
WHERE b.is_local = 1
AND b.is_primary_replica = 0
AND a.secondary_role_allow_connections = 2
AND b.database_id = DB_ID()
), 1, 0
);
'';
EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
END
IF (@is_secondary_replica = 0)
BEGIN
CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
END
END'
GO
-- Provide server level read-only permissions
use master;
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT];
GO
-- Provide msdb specific permissions
use msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [MYDOMAIN\MYACCOUNT];
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; DROP USER [MYDOMAIN\MYACCOUNT]'
-- DROP LOGIN [MYDOMAIN\MYACCOUNT];
--GO
SQL Server Authentifizierung
--- Create a login to run the assessment
use master;
-- NOTE: SQL instances that host replicas of Always On availability groups must use the same SID for the SQL login.
-- After the account is created in one of the members, copy the SID output from the script and include this value
-- when executing against the remaining replicas.
-- When the SID needs to be specified, add the value to the @SID variable definition below.
DECLARE @SID NVARCHAR(MAX) = N'';
IF (@SID = N'')
BEGIN
CREATE LOGIN [evaluator]
WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
DECLARE @SQLString NVARCHAR(500) = 'CREATE LOGIN [evaluator]
WITH PASSWORD = ''<provide a strong password>''
, SID = ' + @SID
EXEC SP_EXECUTESQL @SQLString
END
SELECT @SID = N'0x'+CONVERT(NVARCHAR(100), sid, 2) FROM sys.syslogins where name = 'evaluator'
IF (ISNULL(@SID,'') != '')
PRINT N'Created login [evaluator] with SID = '''+ @SID +'''. If this instance hosts any Always On Availability Group replica, use this SID value when executing the script against the instances hosting the other replicas'
ELSE
PRINT N'Login creation failed'
GO
-- Create a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
USE [?];
IF (''?'' NOT IN (''tempdb'',''model''))
BEGIN
DECLARE @is_secondary_replica BIT = 0;
IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
BEGIN
DECLARE @innersql NVARCHAR(MAX);
SET @innersql = N''
SELECT @is_secondary_replica = IIF(
EXISTS (
SELECT 1
FROM sys.availability_replicas a
INNER JOIN sys.dm_hadr_database_replica_states b
ON a.replica_id = b.replica_id
WHERE b.is_local = 1
AND b.is_primary_replica = 0
AND a.secondary_role_allow_connections = 2
AND b.database_id = DB_ID()
), 1, 0
);
'';
EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
END
IF (@is_secondary_replica = 0)
BEGIN
CREATE USER [evaluator] FOR LOGIN [evaluator];
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
END
END'
GO
-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO
-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO
Anforderungen für die Erkennung von Web-Apps
Die Softwareinventarisierung identifiziert die Webserverrolle, die auf entdeckten Servern vorhanden ist. Wenn festgestellt wird, dass auf einem Server ein Webserver installiert ist, erkennt Azure Migrate und Modernize die Web-Apps auf dem Server.
Sie können sowohl Domänen- als auch Nicht-Domänen-Anmeldeinformationen auf der Appliance hinzufügen. Stellen Sie sicher, dass das verwendete Konto über lokale Administratorrechte auf Quellservern verfügt. Azure Migrate und Modernisieren ordnet Anmeldeinformationen automatisch den jeweiligen Servern zu, sodass Sie sie nicht manuell zuordnen müssen. Diese Anmeldeinformationen werden nie an Microsoft gesendet und verbleiben in der Appliance, die in der Quellumgebung ausgeführt wird.
Nachdem die Appliance verbunden ist, werden Konfigurationsdaten für ASP.NET Web-Apps (IIS-Webserver) und Java Web-Apps (Tomcat-Server) erfasst. Konfigurationsdaten von Web-Apps werden alle 24 Stunden aktualisiert.
| Support | ASP.NET Web-Apps | Java Web-Apps |
|---|---|---|
| Stapel | VMware, Hyper-V und physische Server. | VMware, Hyper-V und physische Server. |
| Windows-Server | Windows Server 2008 R2 und höher werden unterstützt. | Wird nicht unterstützt. |
| Linux-Server | Nicht unterstützt | Server, die die Anforderungen erfüllen. |
| Webserverversionen | IIS 7.5 und höher | Tomcat 8 oder höher |
| Protokoll | WinRM-Port 5986 (HTTPS) standardmäßig, wenn HTTPS-Voraussetzungen nicht auf den Zielservern konfiguriert sind, fällt die Kommunikation auf WinRM-Port 5985 (HTTP) zurück. | SSH-Port 22 (TCP) |
| Erforderliche Berechtigungen | Der am wenigsten privilegierte Benutzer sollte Teil der beiden Benutzergruppen 1 sein. Remoteverwaltungsbenutzer 2. IIS_IUSRS. Die Benutzer müssen über Leseberechtigungen für die folgenden Speicherorte verfügen: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config und C:\Windows\system32\inetsrv\config\redirection.config. Fügen Sie den Benutzer mithilfe von secpol.msc zu "Anmelden als Batchauftrag" hinzu, und stellen Sie sicher, dass der Benutzer nicht Teil von "Verweigern der Anmeldung als Batchauftrag" ist. |
Rekursive Berechtigungen zum Lesen (r) und Ausführen (x) für alle CATALINA_HOME-Verzeichnisse. |
Hinweis
Daten werden im Ruhezustand und während der Übertragung immer verschlüsselt.
Anforderungen der Abhängigkeitsanalyse (ohne Agent)
Die Abhängigkeitsanalyse hilft Ihnen, die Abhängigkeiten zwischen den ermittelten Servern zu analysieren. Sie können Abhängigkeiten mit einer Kartenansicht in einem Azure Migrate Projekt ganz einfach visualisieren. Sie können Abhängigkeiten verwenden, um verwandte Server für die Migration zu Azure zu gruppieren. In der folgenden Tabelle werden die Anforderungen zum Einrichten der Abhängigkeitsanalyse ohne Agent zusammengefasst.
| Support | Einzelheiten |
|---|---|
| Unterstützte Server | Sie können die agentlose Abhängigkeitsanalyse für bis zu 1.000 Server (über mehrere Hyper-V Hosts/Cluster hinweg) pro Appliance aktivieren. |
| Betriebssysteme | Alle Windows- und Linux-Versionen mit Hyper-V Integrationsdiensten aktiviert. |
| Serveranforderungen | Windows Server müssen PowerShell-Remoting aktiviert und PowerShell Version 2.0 oder höher installiert sein. Für Linux-Server muss SSH-Konnektivität aktiviert und sichergestellt sein, dass die folgenden Befehle auf den Linux-Servern ausgeführt werden können: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date. |
| Windows Serverzugriff | Ein Benutzerkonto (lokal oder Domänenkonto) mit Administratorberechtigungen für Server |
| Linux-Serverzugriff | Ein sudo-Benutzerkonto mit Berechtigungen zum Ausführen der Befehle „ls“ und „netstat“. Wenn Sie ein sudo-Benutzerkonto bereitstellen, stellen Sie sicher, dass Sie NOPASSWD für das Konto aktiviert haben, um die erforderlichen Befehle auszuführen, ohne bei jedem Aufruf eines sudo-Befehls ein Kennwort eingeben zu müssen. |
| Portzugriff | Windows Server benötigen Zugriff auf Port 5986 (HTTPS) oder Port 5985 (HTTP). Linux-Server benötigen Zugriff auf Port 22 (TCP). |
| Ermittlungsmethode | Eine Abhängigkeitsanalyse ohne Agent wird durchgeführt, indem unter Verwendung der Serveranmeldeinformationen, die auf der Appliance hinzugefügt wurden, eine direkte Verbindung mit den Servern hergestellt wird. Die Appliance sammelt die Abhängigkeitsinformationen von Windows Servern mithilfe von PowerShell-Remoting und von Linux-Servern mithilfe der SSH-Verbindung. Auf den Servern wird kein Agent zum Pullen von Abhängigkeitsdaten installiert. |
Anforderungen der Agent-basierten Abhängigkeitsanalyse
Dependency Analysis hilft Ihnen, Abhängigkeiten zwischen lokalen Servern zu identifizieren, die Sie bewerten und zu Azure migrieren möchten. In der Tabelle werden die Anforderungen zum Einrichten der Agent-basierten Abhängigkeitsanalyse zusammengefasst. Hyper-V unterstützt derzeit nur die agentbasierte Abhängigkeitsvisualisierung.
| Anforderung | Einzelheiten |
|---|---|
| Vor der Bereitstellung | Sie sollten über ein Projekt verfügen, dem das Azure Migrate-Tool zur Ermittlung und Bewertung hinzugefügt wurde. Sie stellen die Abhängigkeitsvisualisierung bereit, nachdem Sie eine Azure Migrate Appliance eingerichtet haben, um Ihre lokalen Server zu ermitteln. Erfahren Sie, wie Sie erstmalig ein Projekt erstellen. Erfahren Sie, wie Sie das Azure Migrate: Discovery- und Bewertungstool zu einem bestehenden Projekt hinzufügen. Erfahren Sie, wie Sie die Appliance für die Ermittlung und Bewertung von servern auf Hyper-V einrichten. |
| Azure Government (bei Microsoft speziell für Regierungsbehörden entwickelte Cloud-Dienste) | Die Abhängigkeitsvisualisierung ist in Azure Government nicht verfügbar. |
| Protokollanalyse | Azure Migrate und Modernize verwendet die Lösung Service Map in Azure Monitor Protokollen zur Abhängigkeitsvisualisierung. Sie ordnen einem Projekt einen neuen oder vorhandenen Log Analytics Arbeitsbereich zu. Sie können den Arbeitsbereich für ein Projekt nicht ändern, nachdem Sie den Arbeitsbereich hinzugefügt haben. Der Arbeitsbereich muss sich in demselben Abonnement befinden wie das Projekt. Der Arbeitsbereich muss sich in einer der Regionen „USA, Osten“, „Asien, Südosten“ oder „Europa, Westen“ befinden. Arbeitsbereiche in anderen Regionen können keinem Projekt zugeordnet werden. Der Arbeitsbereich muss sich in einer Region befinden, in der die Dienstzuordnung unterstützt wird. Sie können Azure VMs in einer beliebigen Region überwachen. Die virtuellen Computer selbst sind nicht auf die Regionen beschränkt, die vom Log Analytics Arbeitsbereich unterstützt werden. In Log Analytics wird der mit Azure Migrate und Modernize verknüpfte Arbeitsbereich mit dem Schlüssel "Migration Project" und dem Namen "project" markiert. |
| Erforderliche Agents | Installieren Sie auf jedem Server, den Sie analysieren möchten, die folgenden Agents: Microsoft Monitoring Agent (MMA) Dependency-Agent Wenn lokale Server nicht mit dem Internet verbunden sind, müssen Sie das Log Analytics Gateway herunterladen und installieren. Erfahren Sie mehr über das Installieren von Dependency-Agent und MMA. |
| Log Analytics Arbeitsbereich | Der Arbeitsbereich muss sich in demselben Abonnement befinden wie das Projekt. Azure Migrate and Modernize unterstützt Arbeitsbereiche, die sich in den Regionen „USA, Osten“, „Asien, Südosten“ und „Europa, Westen“ befinden. Der Arbeitsbereich muss sich in einer Region befinden, in der die Dienstzuordnung unterstützt wird. Sie können Azure VMs in einer beliebigen Region überwachen. Die virtuellen Computer selbst sind nicht auf die Regionen beschränkt, die vom Log Analytics Arbeitsbereich unterstützt werden. Sie können den Arbeitsbereich für ein Projekt nicht ändern, nachdem Sie den Arbeitsbereich hinzugefügt haben. |
| Kosten | Die Dienstzuordnungslösung verursacht in den ersten 180 Tagen keine Gebühren. Die Anzahl beginnt am Tag, an dem Sie den Log Analytics Arbeitsbereich dem Projekt zuordnen. Nach 180 Tagen, gelten Standardgebühren für Log Analytics. Die Verwendung einer anderen Lösung als "Service Map" im zugeordneten Log Analytics Arbeitsbereich verursacht standardgebühren für Log Analytics. Beim Löschen des Projekts wird der Arbeitsbereich nicht zusammen mit dem Projekt gelöscht. Nachdem Sie das Projekt gelöscht haben, ist die Nutzung der Dienstzuordnung nicht mehr kostenlos. Jeder Knoten wird gemäß der kostenpflichtigen Stufe des Log Analytics Arbeitsbereichs in Rechnung gestellt. Wenn Sie Projekte haben, die Sie vor Azure Migrate allgemeinen Verfügbarkeit (GA am 28. Februar 2018) erstellt haben, fallen möglicherweise andere Service Map-Gebühren an. Um sicherzustellen, dass Sie erst nach 180 Tagen bezahlen müssen, empfehlen wir Ihnen, ein neues Projekt zu erstellen. Arbeitsbereiche, die vor der allgemeinen Verfügbarkeit erstellt wurden, sind weiterhin kostenpflichtig. |
| Verwaltung | Wenn Sie Agents im Arbeitsbereich registrieren, verwenden Sie die ID und den Schlüssel, die vom Projekt bereitgestellt werden. Sie können den Log Analytics-Arbeitsbereich außerhalb von Azure Migrate und Modernization verwenden. Wenn Sie das zugehörige Projekt löschen, wird der Arbeitsbereich nicht automatisch gelöscht. Löschen Sie ihn manuell. Löschen Sie den von Azure Migrate and Modernize erstellten Arbeitsbereich nur, wenn Sie auch das Projekt löschen. Wenn Sie anders vorgehen, funktioniert die Abhängigkeitsvisualisierung nicht wie erwartet. |
| Internetkonnektivität | Wenn Server nicht mit dem Internet verbunden sind, müssen Sie das Log Analytics Gateway darauf installieren. |
| Azure Government (bei Microsoft speziell für Regierungsbehörden entwickelte Cloud-Dienste) | Die Agent-basierte Abhängigkeitsanalyse wird nicht unterstützt. |
Nächste Schritte
Bereiten Sie sich auf Ermittlung von Servern vor, die auf Hyper-V ausgeführt werden.