Stödmatris för VMware-identifiering

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som närmar sig slutstatus. Överväg att använda och planera i enlighet med detta.

Den här artikeln sammanfattar krav och supportkrav för att använda verktyget Azure Migrate: Identifiering och utvärdering för att identifiera och utvärdera servrar i en VMware-miljö för migrering till Azure.

För att utvärdera servrar skapar du först ett Azure Migrate-projekt. Verktyget Azure Migrate: Identifiering och utvärdering läggs automatiskt till i projektet. Distribuera sedan Azure Migrate-installationen. Installationen identifierar kontinuerligt lokala servrar och skickar konfigurations- och prestandametadata till Azure. När identifieringen är klar samlar du in de identifierade servrarna i grupper och kör utvärderingar per grupp.

När du planerar migreringen av VMware-servrar till Azure läser du migreringssupportmatrisen.

Krav för VMware

VMware Details
vCenter Server Servrar som du vill identifiera och utvärdera måste hanteras av vCenter Server version 8.0, 7.0, 6.7, 6.5, 6.0 eller 5.5.

Identifiering av servrar genom att ange ESXi-värdinformation i installationen stöds för närvarande inte.

IPv6-adresser stöds inte för vCenter Server (för identifiering och utvärdering av servrar) och ESXi-värdar (för replikering av servrar).
Behörigheter Verktyget Azure Migrate: Identifiering och utvärdering kräver ett skrivskyddat vCenter Server-konto.

Om du vill använda verktyget för programvaruinventering, agentlös beroendeanalys, webbappar och SQL-identifiering måste kontot ha behörighet för gäståtgärder på virtuella VMware-datorer (VM).

Serverkrav

VMware Details
Operativsystem Alla Windows- och Linux-operativsystem kan utvärderas för migrering.
Lagring Diskar som är anslutna till SCSI-, IDE- och SATA-baserade styrenheter stöds.

Installationskrav för Azure Migrate

Azure Migrate och Modernize använder Azure Migrate-installationen för identifiering och utvärdering. Du kan distribuera installationen som en server i din VMware-miljö med hjälp av en mall för VMware Open Virtualization Appliance som importerats till vCenter Server. Du kan också använda ett PowerShell-skript. Läs mer om installationskrav för VMware.

Här följer fler krav för installationen:

  • I Azure Government måste du distribuera installationen med hjälp av ett skript.
  • Installationen måste kunna komma åt specifika URL:er i offentliga moln och myndighetsmoln.

Krav för portåtkomst

Enhet Anslutning
Azure Migrate-installation Inkommande anslutningar på TCP-port 3389 för att tillåta fjärrskrivbordsanslutningar till installationen.

Inkommande anslutningar på port 44368 för fjärråtkomst till programhanteringsappen med hjälp av URL:en https://<appliance-ip-or-name>:44368.

Utgående anslutningar på port 443 (HTTPS) för att skicka identifierings- och prestandametadata till Azure Migrate och Modernisera.
vCenter Server Inkommande anslutningar på TCP-port 443 så att installationen kan samla in konfigurations- och prestandametadata för utvärderingar.

Enheten ansluter till vCenter på port 443 som standard. Om vCenter Server lyssnar på en annan port kan du ändra porten när du konfigurerar identifiering.
ESXi-värdar För identifiering av programvaruinventering eller agentlös beroendeanalys ansluter enheten till ESXi-värdar på TCP-port 443 för att identifiera programvaruinventering och beroenden på servrarna.

Krav för programvaruinventering

Förutom att identifiera servrar kan Azure Migrate: Identifiering och utvärdering utföra programvaruinventering på servrar. Programvaruinventering innehåller en lista över program, roller och funktioner som körs på Windows- och Linux-servrar som identifieras med hjälp av Azure Migrate och Modernisera. Det gör att du kan identifiera och planera en migreringsväg som är anpassad för dina lokala arbetsbelastningar.

Support Details
Servrar som stöds Du kan utföra programvaruinventering på upp till 10 000 servrar som körs på vCenter-servrar som läggs till i varje Azure Migrate-installation.
Operativsystem Servrar som kör alla Windows- och Linux-versioner stöds.
Serverkrav För programvaruinventering måste VMware Tools installeras och köras på dina servrar. VMware Tools-versionen måste vara version 10.2.1 eller senare.

Windows-servrar måste ha PowerShell version 2.0 eller senare installerat.

Windows Management Instrumentation (WMI) måste vara aktiverat och tillgängligt på Windows-servrar för att samla in information om de roller och funktioner som är installerade på servrarna.
vCenter Server-konto För att interagera med servrarna för programvaruinventering måste det skrivskyddade vCenter Server-kontot som används för utvärdering ha behörighet för gäståtgärder på virtuella VMware-datorer.
Serveråtkomst Du kan lägga till autentiseringsuppgifter för flera domäner och icke-domäner (Windows/Linux) i installationskonfigurationshanteraren för programvaruinventering.

Du måste ha ett gästanvändarkonto för Windows-servrar och ett standardanvändarkonto (icke-sudo-åtkomst) för alla Linux-servrar.
Portåtkomst Azure Migrate-installationen måste kunna ansluta till TCP-port 443 på ESXi-värdar som kör servrar där du vill utföra programvaruinventering. Servern som kör vCenter Server returnerar en ESXi-värdanslutning för att ladda ned filen som innehåller information om programvaruinventeringen.

Om du använder domänautentiseringsuppgifter måste Azure Migrate-installationen kunna ansluta till följande TCP- och UDP-portar:

TCP 135 – RPC-slutpunkt
TCP 389 – LDAP
TCP 636 – LDAP SSL
TCP 445 – SMB
TCP/UDP 88 – Kerberos-autentisering
TCP/UDP 464 – Kerberos-ändringsåtgärder
Identifiering Programvaruinventering utförs från vCenter Server med hjälp av VMware Tools som är installerat på servrarna.

Installationen samlar in information om programvaruinventeringen från servern som kör vCenter Server via vSphere-API:er.

Programvaruinventeringen är agentlös. Ingen agent är installerad på servern och installationen ansluter inte direkt till servrarna.

Krav för SQL Server-instans och databasidentifiering

Programvaruinventering identifierar SQL Server-instanser. Installationen försöker ansluta till respektive SQL Server-instanser via autentiseringsuppgifterna för Windows-autentisering eller SQL Server-autentisering i installationskonfigurationshanteraren med hjälp av den här informationen. Enheten kan bara ansluta till de SQL Server-instanser som den har nätverksansikte till. Programvaruinventering i sig kanske inte behöver någon nätverkslinje.

När installationen är ansluten samlar den in konfigurations- och prestandadata för SQL Server-instanser och databaser. Installationen uppdaterar SQL Server-konfigurationsdata en gång var 24:e timme och samlar in prestandadata var 30:e sekund.

Support Details
Servrar som stöds Stöds endast för servrar som kör SQL Server i dina VMware-, Microsoft Hyper-V- och fysiska/bare metal-miljöer och IaaS-servrar (infrastruktur som en tjänst) i andra offentliga moln, till exempel Amazon Web Services (AWS) och Google Cloud Platform (GCP).

Du kan identifiera upp till 750 SQL Server-instanser eller 15 000 SQL-databaser, beroende på vilket som är mindre, från en enskild installation. Vi rekommenderar att du ser till att en installation är begränsad till att identifiera färre än 600 servrar som kör SQL för att undvika skalningsproblem.
Windows-servrar Windows Server 2008 och senare stöds.
Linux-servrar Stöds inte för närvarande.
Autentiseringsmekanism Både Windows- och SQL Server-autentisering stöds. Du kan ange autentiseringsuppgifter för båda autentiseringstyperna i konfigurationshanteraren för installationen.
SQL Server-åtkomst För att identifiera SQL Server-instanser och databaser måste Windows- eller SQL Server-kontot vara medlem i sysadmin-serverrollen eller ha dessa behörigheter för varje SQL Server-instans.
SQL Server-versioner SQL Server 2008 och senare stöds.
SQL Server-utgåvor Enterprise-, Standard-, Developer- och Express-utgåvor stöds.
SQL-konfiguration som stöds Identifiering av fristående, högtillgängliga och katastrofskyddade SQL-distributioner stöds. Identifiering av SQL-distributioner med hög tillgänglighet för haveriberedskap som drivs av AlwaysOn-redundansklusterinstanser och AlwaysOn-tillgänglighetsgrupper stöds också.
SQL-tjänster som stöds Endast SQL Server Database Engine stöds.

Identifiering av SQL Server Reporting Services, SQL Server Integration Services och SQL Server Analysis Services stöds inte.

Kommentar

Som standard använder Azure Migrate och Modernize det säkraste sättet att ansluta till SQL-instanser. Azure Migrate och Modernize krypterar alltså kommunikationen mellan Azure Migrate-installationen och SQL Server-källinstanserna genom att ställa in TrustServerCertificate egenskapen på true. Dessutom använder transportlagret Secure Socket Layer för att kryptera kanalen och kringgå certifikatkedjan för att verifiera förtroendet. Därför måste installationsservern konfigureras för att kunna lita på certifikatets rotutfärdare.

Du kan dock ändra anslutningsinställningarna genom att välja Redigera SQL Server-anslutningsegenskaper på enheten. Lär dig mer om vad du ska välja.

Konfigurera anpassad inloggning för SQL Server-identifiering

Använd följande exempelskript för att skapa en inloggning och etablera den med nödvändiga behörigheter.

Windows-autentisering

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

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

Krav för identifiering av webbappar

Programvaruinventering identifierar webbserverrollen som finns på identifierade servrar. Om en server har en webbserver installerad identifierar Azure Migrate och Modernize webbappar på servern.

Du kan lägga till både domän- och icke-domänautentiseringsuppgifter på enheten. Kontrollera att det konto som används har lokal administratörsbehörighet på källservrar. Azure Migrate och Modernize mappar automatiskt autentiseringsuppgifter till respektive servrar, så du behöver inte mappa dem manuellt. Viktigast av allt är att dessa autentiseringsuppgifter aldrig skickas till Microsoft och finns kvar på enheten som körs i källmiljön.

När installationen är ansluten samlar den in konfigurationsdata för ASP.NET webbappar (IIS-webbserver) och Java-webbappar (Tomcat-servrar). Konfigurationsdata för webbappar uppdateras en gång var 24:e timme.

Support ASP.NET-webbappar Java-webbappar
Stack VMware, Hyper-V och fysiska servrar. VMware, Hyper-V och fysiska servrar.
Windows-servrar Windows Server 2008 R2 och senare stöds. Stöds ej.
Linux-servrar Stöds ej. Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7 och Red Hat Enterprise Linux 5/6/7.
Webbserverversioner IIS 7.5 och senare. Tomcat 8 eller senare.
Protokoll WinRM-port 5985 (HTTP) SSH-port 22 (TCP)
Privilegier som krävs Lokal administratör. Rot- eller sudo-användare.

Kommentar

Data krypteras alltid i vila och under överföring.

Krav för beroendeanalys (agentlös)

Beroendeanalys hjälper dig att analysera beroendena mellan de identifierade servrarna. Du kan enkelt visualisera beroenden med en kartvy i ett Azure Migrate-projekt. Du kan använda beroenden för att gruppera relaterade servrar för migrering till Azure. I följande tabell sammanfattas kraven för att konfigurera agentlös beroendeanalys.

Support Details
Servrar som stöds Du kan aktivera agentlös beroendeanalys på upp till 1 000 servrar (över flera vCenter-servrar) som identifieras per installation.
Windows-servrar Windows Server 2022
Windows Server 2019
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 (64-bitars)
Windows Server 2008 (32-bitars)
Linux-servrar Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x
CentOS 5.1, 5.9, 5.11, 6.x, 7.x, 8.x
Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04
OracleLinux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5
SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3
Debian 7, 8, 9, 10, 11
Serverkrav VMware Tools (10.2.1 och senare) måste installeras och köras på servrar som du vill analysera.

Servrar måste ha PowerShell version 2.0 eller senare installerat.

WMI ska vara aktiverat och tillgängligt på Windows-servrar.
vCenter Server-konto Det skrivskyddade kontot som används av Azure Migrate och Modernisera för utvärdering måste ha behörighet för gäståtgärder på virtuella VMware-datorer.
Åtkomst till Windows-server Ett användarkonto (lokalt eller domän) med administratörsbehörighet på servrar.
Åtkomst till Linux-server Ett sudo-användarkonto med behörighet att köra ls- och netstat-kommandon. Om du anger ett sudo-användarkonto kontrollerar du att du aktiverar NOPASSWD för kontot för att köra nödvändiga kommandon utan att fråga efter ett lösenord varje gång ett sudo-kommando anropas.

Du kan också skapa ett användarkonto som har CAP_DAC_READ_SEARCH- och CAP_SYS_PTRACE behörigheter för /bin/netstat- och /bin/ls-filer som angetts med hjälp av följande kommandon:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Portåtkomst Azure Migrate-installationen måste kunna ansluta till TCP-port 443 på ESXi-värdar som kör de servrar som har beroenden som du vill identifiera. Servern som kör vCenter Server returnerar en ESXi-värdanslutning för att ladda ned filen som innehåller beroendedata.
Identifieringsmetod Beroendeinformation mellan servrar samlas in med hjälp av VMware Tools installerat på servern som kör vCenter Server.

Installationen samlar in information från servern med hjälp av vSphere-API:er.

Ingen agent är installerad på servern och installationen ansluter inte direkt till servrarna.

Krav för beroendeanalys (agentbaserad)

Beroendeanalys hjälper dig att identifiera beroenden mellan lokala servrar som du vill utvärdera och migrera till Azure. I följande tabell sammanfattas kraven för att konfigurera agentbaserad beroendeanalys.

Krav Information
Före distributionen Du bör ha ett projekt på plats med verktyget Azure Migrate: Discovery och utvärdering som lagts till i projektet.

Du distribuerar beroendevisualisering när du har konfigurerat en Azure Migrate-installation för att identifiera dina lokala servrar.

Lär dig hur du skapar ett projekt för första gången.
Lär dig hur du lägger till ett identifierings- och utvärderingsverktyg i ett befintligt projekt.
Lär dig hur du konfigurerar Azure Migrate-installationen för utvärdering av Hyper-V, VMware eller fysiska servrar.
Servrar som stöds Stöds för alla servrar i din lokala miljö.
Log Analytics Azure Migrate och Modernize använder lösningen Tjänstkarta i Azure Monitor-loggar för beroendevisualisering.

Du associerar en ny eller befintlig Log Analytics-arbetsyta med ett projekt. Du kan inte ändra arbetsytan för ett projekt när du har lagt till arbetsytan.

Arbetsytan måste finnas i samma prenumeration som projektet.

Arbetsytan måste finnas i regionerna USA, östra, Asien, sydöstra eller Europa, västra. Arbetsytor i andra regioner kan inte associeras med ett projekt.

Arbetsytan måste finnas i en region där tjänstkarta stöds. Du kan övervaka virtuella Azure-datorer i valfri region. De virtuella datorerna är inte begränsade till de regioner som stöds av Log Analytics-arbetsytan.

I Log Analytics taggas arbetsytan som är associerad med Azure Migrate med projektnyckeln och projektnamnet.
Obligatoriska agenter Installera följande agenter på varje server som du vill analysera:
- Microsoft Monitoring Agent (MMA)
- Beroendeagent

Om lokala servrar inte är anslutna till Internet laddar du ned och installerar Log Analytics-gatewayen på dem.

Läs mer om att installera beroendeagentenoch MMA.
Log Analytics-arbetsyta Arbetsytan måste finnas i samma prenumeration som projektet.

Azure Migrate stöder arbetsytor som finns i regionerna USA, östra, Sydostasien och Europa, västra.

Arbetsytan måste finnas i en region där tjänstkarta stöds. Du kan övervaka virtuella Azure-datorer i valfri region. De virtuella datorerna är inte begränsade till de regioner som stöds av Log Analytics-arbetsytan.

Du kan inte ändra arbetsytan för ett projekt när du har lagt till arbetsytan.
Kostnad Service Map-lösningen medför inga avgifter under de första 180 dagarna. Antalet börjar från den dag då du associerar Log Analytics-arbetsytan med projektet.

Efter 180 dagar gäller standardpriserna för Log Analytics.

Om du använder någon annan lösning än Tjänstkarta på den associerade Log Analytics-arbetsytan debiteras standardavgifter för Log Analytics.

När projektet tas bort tas arbetsytan inte bort automatiskt. När du har tagit bort projektet är användning av tjänstkarta inte kostnadsfritt. Varje nod debiteras enligt den betalda nivån på Log Analytics-arbetsytan.

Om du har projekt som du skapade före allmän tillgänglighet för Azure Migrate (GA den 28 februari 2018) kan du debiteras andra Service Map-avgifter. För att säkerställa att du debiteras först efter 180 dagar rekommenderar vi att du skapar ett nytt projekt. Arbetsytor som skapades före allmän tillgänglighet kan fortfarande debiteras.
Hantering När du registrerar agenter på arbetsytan använder du det ID och den nyckel som tillhandahålls av projektet.

Du kan använda Log Analytics-arbetsytan utanför Azure Migrate och Modernisera.

Om du tar bort det associerade projektet tas arbetsytan inte bort automatiskt. Ta bort den manuellt.

Ta inte bort arbetsytan som skapats av Azure Migrate och Modernisera om du inte tar bort projektet. Om du gör det fungerar inte beroendevisualiseringsfunktionen som förväntat.
Internet-anslutning Om servrar inte är anslutna till Internet installerar du Log Analytics-gatewayen på servrarna.
Azure Government Agentbaserad beroendeanalys stöds inte.

Begränsningar

Krav Information
Projektgränser Du kan skapa flera Azure Migrate-projekt i en Azure-prenumeration.

Du kan identifiera och utvärdera upp till 50 000 servrar i en VMware-miljö i ett enda projekt. Ett projekt kan innehålla fysiska servrar och servrar från en Hyper-V-miljö, upp till utvärderingsgränserna.
Identifiering Azure Migrate-installationen kan identifiera upp till 10 000 servrar som körs på flera vCenter-servrar.

Installationen har stöd för att lägga till flera vCenter-servrar. Du kan lägga till upp till 10 vCenter-servrar per installation.

Det här beloppet är giltigt även för Azure VMware Solution.
Utvärdering Du kan lägga till upp till 35 000 servrar i en enda grupp.

Du kan utvärdera upp till 35 000 servrar i en enda utvärdering.

Läs mer om utvärderingar.

Importera servrar med hjälp av RVTools XLSX (förhandsversion)

Som en del av migreringsresan till Azure med hjälp av Azure Migrate-installationen identifierar du först servrar, lager och arbetsbelastningar. Men för en snabb utvärdering innan du distribuerar installationen kan du importera servrarna med hjälp av RVTools XLSX-filen (förhandsversion).

Viktiga fördelar

Använda en RVTools XLSX-fil:

  • Hjälper till att skapa ett affärsfall eller utvärdera servrarna innan du distribuerar installationen.
  • Hjälpmedel som ett alternativ när det finns en organisationsbegränsning för att distribuera Azure Migrate-installationen.
  • Är användbart när du inte kan dela autentiseringsuppgifter som tillåter åtkomst till lokala servrar.
  • Är användbart när säkerhetsbegränsningar hindrar dig från att samla in och skicka data som samlas in av installationen till Azure.

Begränsningar

I det här avsnittet beskrivs begränsningar att tänka på.

Här följer några begränsningar om du importerar servrar med hjälp av en RVTools XLSX-fil och skapar ett affärsfall:

  • Varaktighet för prestandahistorik i Azure-inställningar är inte tillämpliga.
  • Servrar klassificeras som okända i diagrammet med insikter om användning av affärsfall och är lika stora som utan rätt storlek för Azure eller Azure VMware Solution-kostnaden.

Nästa steg