Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln sammanfattar krav och supportkrav när du utvärderar fysiska servrar för migrering till Azure med hjälp av verktyget Azure Migrate: Discovery och utvärdering . Om du vill migrera fysiska servrar till Azure kan du läsa migreringssupportmatrisen.
För att utvärdera fysiska servrar skapar du ett projekt och lägger till verktyget Azure Migrate: Discovery och utvärdering i projektet. När du har lagt till verktyget distribuerar du Azure Migrate-installationen. Installationen identifierar kontinuerligt lokala servrar och skickar servrarnas metadata och prestandadata till Azure. När identifieringen är klar samlar du in identifierade servrar i grupper och kör en utvärdering för en grupp.
Begränsningar
| Stöd | Detaljer |
|---|---|
| Utvärderingsgränser | Du kan identifiera och utvärdera upp till 35 000 fysiska servrar i ett enda projekt. |
| Projektgränser | Du kan skapa flera projekt i en Azure-prenumeration. Förutom fysiska servrar kan ett projekt innehålla servrar på VMware och på Hyper-V, upp till utvärderingsgränserna för varje projekt. |
| Upptäckt | Azure Migrate-installationen kan identifiera upp till 1 000 fysiska servrar. |
| 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.
Krav för fysisk server
Distribution av fysisk server: Den fysiska servern kan vara fristående eller distribuerad i ett kluster.
Typ av servrar: Bare metal-servrar, virtualiserade servrar som körs lokalt eller andra moln som Amazon Web Services (AWS), Google Cloud Platform (GCP) och Xen.
Anteckning
För närvarande stöder Inte Azure Migrate identifiering av paravirtualiserade servrar.
Operativsystem: Alla Windows- och Linux-operativsystem kan utvärderas för migrering.
Försiktighet
Den här artikeln refererar till Windows Server-versioner som har nått End of Support (EOS). Microsoft har officiellt upphört med supporten för följande operativsystem:
- Windows Server 2003
- Windows Server 2008 (inklusive SP2 och R2 SP1)
- Windows Server 2012
- Windows Server 2012 R2 Därför garanterar Azure Migrate inte konsekventa eller tillförlitliga resultat för dessa OS-versioner. Kunder kan stöta på problem och rekommenderas starkt att uppgradera till en Windows Server-version som stöds innan migreringen påbörjas.
Installationskrav för Azure Migrate
Azure Migrate använder Azure Migrate-installationen för identifiering och utvärdering. Installationen för fysiska servrar kan köras på en virtuell dator (VM) eller en fysisk server.
- Lär dig mer om installationskrav för fysiska servrar.
- Lär dig mer om URL:er som enheten behöver åtkomst till i offentliga moln och myndighetsmoln .
- Använd ett PowerShell-skript som du laddar ned från Azure-portalen för att konfigurera installationen.
- Använd det här skriptet för att distribuera installationen i Azure Government.
Portåtkomst
I följande tabell sammanfattas portkraven för utvärdering.
| Apparat | Anslutning |
|---|---|
| Apparat | 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. |
| Fysiska servrar |
Windows: Inkommande anslutningar på WinRM-port 5986 (HTTPS) används för att hämta konfigurations- och prestandametadata från Windows-servrar. Om HTTPS-kraven inte har konfigurerats på målservrarna Hyper-V kommer installationens kommunikation att återgå till WinRM-port 5985 (HTTP). För att framtvinga HTTPS-kommunikation utan återgång, aktivera eller inaktivera Appliance Config Manager. När du har aktiverat kontrollerar du att förutsättningarna har konfigurerats på målservrarna. – Om certifikaten inte har konfigurerats på målservrarna misslyckas identifieringen på både de identifierade servrarna och de nyligen tillagda servrarna. – WinRM HTTPS kräver ett lokalt serverautentiseringscertifikat med ett gemensamt namn (CN) som matchar värdnamnet. Certifikatet får inte ha upphört att gälla, återkallats eller självsignerats. Se artikeln om hur du konfigurerar WinRM för HTTPS. – Linux: Inkommande anslutningar på port 22 (TCP) för att hämta konfigurations- och prestandametadata från Linux-servrar. |
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 hjälper dig att identifiera och planera en migreringsväg som är anpassad för dina lokala arbetsbelastningar.
| Stöd | Detaljer |
|---|---|
| Servrar som stöds | Du kan utföra programvaruinventering på upp till 1 000 servrar som identifieras från varje Azure Migrate-installation. |
| Operativsystem | Servrar som kör alla Windows- och Linux-versioner som uppfyller serverkraven och har de åtkomstbehörigheter som krävs stöds. |
| Serverkrav | Windows-servrar måste ha PowerShell-fjärrkommunikation aktiverat och PowerShell version 2.0 eller senare installerat. 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. Linux-servrar måste ha SSH-anslutning aktiverat och se till att följande kommandon kan köras på Linux-servrarna för att hämta programdata: lista, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Baserat på operativsystemtypen och vilken typ av pakethanterare som används finns här några fler kommandon: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| Åtkomst till Windows-server | Ett gästanvändarkonto för Windows-servrar. |
| Åtkomst till Linux-server | Ett standardanvändarkonto (icke-sudo-åtkomst) för alla Linux-servrar. |
| Portåtkomst | Windows-servrar behöver åtkomst på port 5985 (HTTP). Linux-servrar behöver åtkomst på port 22 (TCP). |
| Upptäckt | Programvaruinventeringen utförs genom att direkt ansluta till servrarna med hjälp av de serverautentiseringsuppgifter som lagts till på installationen. Installationen samlar in information om programvaruinventeringen från Windows-servrar med hjälp av PowerShell-fjärrkommunikation och från Linux-servrar med hjälp av SSH-anslutningen. Programvaruinventeringen är agentlös. Ingen agent är installerad på 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 som anges i installationskonfigurationshanteraren med hjälp av den här informationen. Enheten kan bara ansluta till de SQL Server-instanser som den har nätverksåtkomst till. Programvaruinventering i sig kanske inte behöver direkt nätverkssynlighet.
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.
| Stöd | Detaljer |
|---|---|
| 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 AWS och 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 kräver Windows-/domänkontot eller SQL Server-kontot dessa läsbehörigheter med låg behörighet för varje SQL Server-instans. Du kan använda verktyget för kontoetablering med låg behörighet för att skapa anpassade konton eller använda ett befintligt konto som är medlem i sysadmin-serverrollen för enkelhetens skull. |
| 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. Upptäckt av SQL-distributioner med hög tillgänglighet och katastrofåterställning som drivs av Always On-failover-klusterinstanser och Always On-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. |
Anteckning
Som standard använder Azure Migrate 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-upptäckt
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 visar sig ha 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ällservrarna. 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.
| Stöd | ASP.NET-webbappar | Java-webbappar |
|---|---|---|
| Stapel | 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 och Red Hat Enterprise Linux 5/6/7. |
| Webbserverversioner | IIS 7.5 och senare. | Tomcat 8 eller senare. |
| Privilegier som krävs | Lokal administratör. | Läsbehörigheter (r) och Kör (x) rekursivt på alla CATALINA_HOME kataloger. |
Anteckning
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.
| Stöd | Detaljer |
|---|---|
| Servrar som stöds | Du kan aktivera agentlös beroendeanalys på upp till 1 000 servrar som identifieras per installation. |
| Operativsystem | Servrar som kör alla Windows- och Linux-versioner som uppfyller serverkraven och har de åtkomstbehörigheter som krävs stöds. |
| Serverkrav | Windows-servrar måste ha PowerShell-fjärrkommunikation aktiverat och PowerShell version 2.0 eller senare installerat. Linux-servrar måste ha SSH-anslutning aktiverat och se till att följande kommandon kan köras på Linux-servrarna: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date. |
| Åtkomst till Windows-server | Ett användarkonto (lokalt eller domän) med administratörsbehörighet på servrar. |
| Åtkomst till Linux-server | Se den här länken för Åtkomst till Linux-server. |
| Portåtkomst | Windows-servrar behöver åtkomst på port 5985 (HTTP). Linux-servrar behöver åtkomst på port 22 (TCP). |
| Upptäcktsmetod | Agentlös beroendeanalys utförs genom att direkt ansluta till servrarna med hjälp av de serverautentiseringsuppgifter som lagts till på installationen. Installationen samlar in beroendeinformation från Windows-servrar med hjälp av PowerShell-fjärrkommunikation och från Linux-servrar med hjälp av SSH-anslutningen. Ingen agent installeras på servrarna för att hämta beroendedata. |
Krav för agentbaserad beroendeanalys
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. För närvarande stöds endast agentbaserad beroendeanalys för fysiska servrar.
| Krav | Detaljer |
|---|---|
| Före distributionen | Du bör ha ett projekt klart 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 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. |
| Azure för offentlig sektor | Beroendevisualisering är inte tillgängligt i Azure Government. |
| Logganalys | 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. Arbetsyta måste finnas i samma prenumeration som projektet. Arbetsytan måste finnas i regionerna Östra USA, Sydostasien eller Västra Europa. 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 och Modernize med migreringsprojektnyckeln 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 måste du ladda ned och installera Log Analytics-gatewayen på dem. Läs mer om att installera Beroendeagent och MMA. |
| Log Analytics-arbetsyta | Arbetsytan måste finnas i samma prenumeration som ett projekt. Azure Migrate och Modernize stöder arbetsytor som finns i regionerna Östra USA, Sydostasien och Västeuropa. 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. |
| Kostnader | 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. |
| Förvaltning | 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 för offentlig sektor | Agentbaserad beroendeanalys stöds inte. |
Nästa steg
Förbered för upptäckten av fysiska servrar.