Matrice di supporto per la valutazione di Hyper-V

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux che si avvicina allo stato di fine vita. Prendere in considerazione l'uso e il piano di conseguenza.

Questo articolo riepiloga i prerequisiti e i requisiti di supporto quando si individuano e valutano i server locali in esecuzione in un ambiente Hyper-V per la migrazione ad Azure usando lo strumento Di individuazione e valutazione di Azure Migrate. Per eseguire la migrazione dei server in esecuzione in Hyper-V in Azure, vedere la matrice di supporto per la migrazione.

Per configurare l'individuazione e la valutazione dei server in esecuzione in Hyper-V, creare un progetto e aggiungere lo strumento Azure Migrate: Individuazione e valutazione al progetto. Dopo avere aggiunto lo strumento, distribuire l'appliance di Azure Migrate. L'appliance individua continuamente i server locali e invia i metadati del server e i dati sulle prestazioni ad Azure. Al termine dell'individuazione, si raccolgono i server individuati in gruppi ed è possibile eseguire una valutazione per un gruppo.

Limiti

Supporto tecnico Dettagli
Limiti di valutazione È possibile individuare e valutare fino a 35.000 server in un singolo progetto.
Limiti di progetto In una sottoscrizione di Azure è possibile creare più progetti. Oltre ai server in Hyper-V, un progetto può includere server in VMware e server fisici, fino ai limiti di valutazione per ognuno di essi.
Individuazione L'appliance Azure Migrate può individuare fino a 5.000 server in esecuzione in Hyper-V.

L'appliance può connettersi a un massimo di 300 host Hyper-V.
Valutazione È possibile aggiungere fino a 35.000 server in un singolo gruppo.

È possibile valutare fino a 35.000 server in una singola valutazione per un gruppo.

Altre informazioni sulle valutazioni.

Requisiti dell'host Hyper-V

Supporto tecnico Dettagli
Host Hyper-V L'host Hyper-V può essere autonomo o distribuito in un cluster.

L'host Hyper-V può eseguire Windows Server 2022, Windows Server 2019, Windows Server 2016 o Windows Server 2012 R2. Sono supportate anche le installazioni dei componenti di base del server di questi sistemi operativi.
Non è possibile valutare i server che si trovano in host Hyper-V che eseguono Windows Server 2012.
Autorizzazioni Sono necessarie autorizzazioni Amministrazione istrator nell'host Hyper-V.
Se non si vogliono assegnare autorizzazioni Amministrazione istrator, creare un account utente locale o di dominio e aggiungere l'account utente a questi gruppi: Utenti di gestione remota, Hyper-V Amministrazione istrator e utenti Monitor prestazioni.
Comunicazione remota di PowerShell La comunicazione remota di PowerShell deve essere abilitata in ogni host Hyper-V.
replica Hyper-V Se si usa la replica Hyper-V (o si dispone di più server con gli stessi identificatori del server) e si individuano sia i server originali che replicati usando Azure Migrate e Modernize, la valutazione generata da Azure Migrate e Modernize potrebbe non essere accurata.

Requisiti del server

Supporto tecnico Dettagli
Sistema operativo Tutti i sistemi operativi possono essere valutati per la migrazione.
Integration Services Hyper-V Integration Services deve essere in esecuzione nei server valutati per acquisire informazioni sul sistema operativo.
Storage Disco locale, DAS, JBOD, spazi Archiviazione, CSV e SMB. Queste risorse di archiviazione host Hyper-V in cui sono archiviati VHD/VHDX sono supportate.
Sono supportati controller virtuali IDE e SCSI.

Requisiti dell'appliance di Azure Migrate

Azure Migrate e Modernize usano l'appliance di Azure Migrate per l'individuazione e la valutazione. È possibile distribuire l'appliance usando un disco rigido virtuale Hyper-V compresso scaricato dal portale o usando uno script di PowerShell. Per altre informazioni:

Accesso alla porta

La tabella seguente riepiloga i requisiti delle porte per la valutazione.

Dispositivo Connessioni
Appliance Connessioni in ingresso sulla porta TCP 3389 per consentire la connessione dal desktop remoto al dispositivo.

Connessioni in ingresso sulla porta 44368 per accedere in remoto all'app di gestione dell'appliance usando l'URL: https://<appliance-ip-or-name>:44368

Connessioni in uscita sulle porte 443 (HTTPS) per inviare i metadati di individuazione e prestazioni ad Azure Migrate e modernizzare.
Host/cluster Hyper-V Connessione in ingresso sulla porta WinRM 5985 (HTTP) per eseguire il pull dei metadati e dei dati sulle prestazioni per i server in Hyper-V tramite una sessione CIM (Common Information Model).
Server I server Windows devono accedere alla porta 5985 (HTTP). I server Linux devono accedere alla porta 22 (TCP) per eseguire l'inventario software e l'analisi delle dipendenze senza agente.

Requisiti di inventario software

Oltre all'individuazione dei server, Azure Migrate: l'individuazione e la valutazione possono eseguire l'inventario software nei server. L'inventario software fornisce l'elenco di applicazioni, ruoli e funzionalità in esecuzione in server Windows e Linux individuati tramite Azure Migrate e Modernize. Consente di identificare e pianificare un percorso di migrazione personalizzato per i carichi di lavoro locali.

Supporto tecnico Dettagli
Server supportati È possibile eseguire l'inventario software su un massimo di 5.000 server in esecuzione in host/cluster Hyper-V aggiunti a ogni appliance di Azure Migrate.
Sistemi operativi Tutte le versioni di Windows e Linux con i servizi di integrazione Hyper-V abilitati.
Requisiti del server I server Windows devono avere la comunicazione remota di PowerShell abilitata e PowerShell versione 2.0 o successiva installata.

WMI deve essere abilitato e disponibile nei server Windows per raccogliere i dettagli dei ruoli e delle funzionalità installati nei server.

I server Linux devono avere la connettività Secure Shell (SSH) abilitata e assicurarsi che i comandi seguenti possano essere eseguiti nei server Linux per eseguire il pull dei dati dell'applicazione: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. In base al tipo di sistema operativo e al tipo di gestione pacchetti in uso, ecco alcuni altri comandi: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Accesso al server È possibile aggiungere più credenziali di dominio e non dominio (Windows/Linux) in Gestione configurazione appliance per l'inventario software.

È necessario avere un account utente guest per i server Windows e un account utente standard (accesso non sudo) per tutti i server Linux.
Accesso alla porta I server Windows devono accedere alla porta 5985 (HTTP). I server Linux devono accedere alla porta 22 (TCP).

Se si usano le credenziali di dominio, l'appliance di Azure Migrate deve essere in grado di connettersi alle porte TCP e UDP seguenti:

TCP 135 - Endpoint RPC
TCP 389 - LDAP
TCP 636 - LDAP SSL
TCP 445 - SMB
TCP/UDP 88 - Autenticazione Kerberos
TCP/UDP 464 - Operazioni di modifica Kerberos
Individuazione L'inventario software viene eseguito connettendosi direttamente ai server usando le credenziali del server aggiunte nell'appliance.

L'appliance raccoglie le informazioni sull'inventario software dai server Windows usando la comunicazione remota di PowerShell e dai server Linux tramite la connessione SSH.

L'inventario software è senza agente. Nei server non è installato alcun agente.

Requisiti per l'istanza di SQL Server e l'individuazione del database

L'inventario software identifica le istanze di SQL Server. L'appliance usa queste informazioni e tenta di connettersi alle rispettive istanze di SQL Server tramite le credenziali di autenticazione di autenticazione di Windows o SQL Server fornite nella gestione configurazione dell'appliance. L'appliance può connettersi solo alle istanze di SQL Server a cui dispone di una linea di rete. L'inventario software di per sé potrebbe non avere bisogno di una linea di rete.

Dopo la connessione dell'appliance, raccoglie i dati di configurazione e prestazioni per le istanze e i database di SQL Server. I dati di configurazione di SQL Server vengono aggiornati una volta ogni 24 ore. I dati sulle prestazioni vengono acquisiti ogni 30 secondi.

Supporto tecnico Dettagli
Server supportati Supportato solo per i server che eseguono SQL Server in ambienti VMware, Microsoft Hyper-V e fisici/bare metal e server IaaS (Infrastructure as a Service) di altri cloud pubblici, ad esempio Servizi Web di Azure e Google Cloud Platform.

È possibile individuare fino a 750 istanze di SQL Server o 15.000 database SQL, a meno di un'appliance singola. È consigliabile assicurarsi che un'appliance sia con ambito per individuare meno di 600 server che eseguono SQL per evitare problemi di ridimensionamento.
Server Windows Windows Server 2008 e versioni successive sono supportati.
Server Linux Attualmente non supportato.
Meccanismo di autenticazione Sono supportati sia l'autenticazione di Windows che SQL Server. È possibile specificare le credenziali di entrambi i tipi di autenticazione in Gestione configurazione appliance.
Accesso a SQL Server Per individuare istanze e database di SQL Server, l'account di Windows o SQL Server deve essere membro del ruolo del server sysadmin o disporre di queste autorizzazioni per ogni istanza di SQL Server.
Versioni di SQL Server Sono supportati SQL Server 2008 e versioni successive.
Edizioni di SQL Server Sono supportate le edizioni Enterprise, Standard, Developer ed Express.
Configurazione SQL supportata È supportata l'individuazione di distribuzioni SQL autonome, a disponibilità elevata e protette da emergenza. È supportata anche l'individuazione di distribuzioni SQL a disponibilità elevata e ripristino di emergenza basate su istanze del cluster di failover AlwaysOn e gruppi di disponibilità AlwaysOn.
Servizi SQL supportati È supportato solo SQL Server motore di database.

L'individuazione di SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services non è supportata.

Nota

Per impostazione predefinita, Azure Migrate e Modernize usano il modo più sicuro per connettersi alle istanze DI SQL. Ovvero, Azure Migrate e Modernize crittografa la comunicazione tra l'appliance di Azure Migrate e le istanze di SQL Server di origine impostando la TrustServerCertificate proprietà su true. Inoltre, il livello di trasporto usa Secure Socket Layer per crittografare il canale e ignorare la catena di certificati per convalidare l'attendibilità. Per questo motivo, il server dell'appliance deve essere configurato per considerare attendibile l'autorità radice del certificato.

È tuttavia possibile modificare le impostazioni di connessione selezionando Modifica proprietà di connessione di SQL Server nell'appliance. Altre informazioni su cosa scegliere.

Configurare l'account di accesso personalizzato per l'individuazione di SQL Server

Usare gli script di esempio seguenti per creare un account di accesso ed eseguirne il provisioning con le autorizzazioni necessarie.

Autenticazione di Windows

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

Autenticazione di SQL Server

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

Requisiti di individuazione delle app Web

L'inventario software identifica il ruolo del server Web esistente nei server individuati. Se viene rilevato che un server Web è installato, Azure Migrate e Modernize individua le app Web nel server.

È possibile aggiungere credenziali sia di dominio che di non dominio nell'appliance. Assicurarsi che l'account usato disponga dei privilegi di amministratore locale nei server di origine. Azure Migrate e Modernize esegue automaticamente il mapping delle credenziali ai rispettivi server, quindi non è necessario eseguirne il mapping manuale. Queste credenziali non vengono mai inviate a Microsoft e rimangono nell'appliance in esecuzione nell'ambiente di origine.

Dopo aver connesso l'appliance, raccoglie i dati di configurazione per ASP.NET app Web (server Web IIS) e app Web Java (server Tomcat). I dati di configurazione delle app Web vengono aggiornati una volta ogni 24 ore.

Supporto tecnico App Web ASP.NET App Web Java
Stack Server fisici, Hyper-V e VMware. Server fisici, Hyper-V e VMware.
Server Windows Windows Server 2008 R2 e versioni successive sono supportati. Non supportato.
Server Linux Non supportato. Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7 e Red Hat Enterprise Linux 5/6/7.
Versioni del server Web IIS 7.5 e versioni successive. Tomcat 8 o versione successiva.
Privilegi obbligatori Amministratore locale. Utente radice o sudo.

Nota

I dati vengono sempre crittografati inattivi e durante il transito.

Requisiti di analisi delle dipendenze (senza agente)

L'analisi delle dipendenze consente di analizzare le dipendenze tra i server individuati. È possibile visualizzare facilmente le dipendenze con una visualizzazione mappa in un progetto di Azure Migrate. È possibile usare le dipendenze per raggruppare i server correlati per la migrazione ad Azure. La tabella seguente riepiloga i requisiti per la configurazione dell'analisi delle dipendenze senza agente.

Supporto tecnico Dettagli
Server supportati È possibile abilitare l'analisi delle dipendenze senza agente su un massimo di 1.000 server (in più host/cluster Hyper-V) individuati per ogni appliance.
Sistemi operativi Tutte le versioni di Windows e Linux con i servizi di integrazione Hyper-V abilitati.
Requisiti del server I server Windows devono avere la comunicazione remota di PowerShell abilitata e PowerShell versione 2.0 o successiva installata.

I server Linux devono avere la connettività SSH abilitata e assicurarsi che i comandi seguenti possano essere eseguiti nei server Linux: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Accesso a Windows Server Un account utente (locale o di dominio) con autorizzazioni di amministratore per i server.
Accesso al server Linux Un account utente sudo con autorizzazioni per eseguire comandi ls e netstat. Se si fornisce un account utente sudo, assicurarsi di abilitare NOPASSWD per l'account per eseguire i comandi necessari senza richiedere una password ogni volta che viene richiamato un comando sudo.

In alternativa, è possibile creare un account utente con autorizzazioni CAP_DAC_READ_edizione Standard ARCH e CAP_SYS_PTRACE per i file /bin/netstat e /bin/ls, impostati usando i comandi seguenti:
sudo setcap CAP_DAC_READ_edizione Standard ARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_edizione Standard ARCH,CAP_SYS_PTRACE=ep /bin/netstat
Accesso alla porta I server Windows devono accedere alla porta 5985 (HTTP). I server Linux devono accedere alla porta 22 (TCP).
Metodo di individuazione L'analisi delle dipendenze senza agente viene eseguita connettendosi direttamente ai server usando le credenziali del server aggiunte nell'appliance.

L'appliance raccoglie le informazioni sulle dipendenze dai server Windows usando la comunicazione remota di PowerShell e dai server Linux usando la connessione SSH.

Nei server non è installato alcun agente per eseguire il pull dei dati delle dipendenze.

Requisiti dell'analisi delle dipendenze basata su agente

L'analisi delle dipendenze consente di identificare le dipendenze tra i server locali da valutare ed eseguire la migrazione ad Azure. Nella tabella sono riepilogati i requisiti per la configurazione dell'analisi delle dipendenze basata su agente. Hyper-V supporta attualmente solo la visualizzazione delle dipendenze basata su agente.

Requisito Dettagli
Prima della distribuzione È necessario avere un progetto sul posto con lo strumento Di individuazione e valutazione di Azure Migrate aggiunto al progetto.

La visualizzazione delle dipendenze viene distribuita dopo aver configurato un'appliance di Azure Migrate per individuare i server locali.

Informazioni su come creare un progetto per la prima volta.
Informazioni su come aggiungere lo strumento Di individuazione e valutazione di Azure Migrate a un progetto esistente.
Informazioni su come configurare l'appliance per l'individuazione e la valutazione dei server in Hyper-V.
Azure per enti pubblici La visualizzazione delle dipendenze non è disponibile in Azure per enti pubblici.
Log Analytics Azure Migrate e Modernize usano la soluzione Mapping dei servizi nei log di Monitoraggio di Azure per la visualizzazione delle dipendenze.

Si associa un'area di lavoro Log Analytics nuova o esistente a un progetto. Non è possibile modificare l'area di lavoro per un progetto dopo aver aggiunto l'area di lavoro.

L'area di lavoro deve trovarsi nella stessa sottoscrizione del progetto.

L'area di lavoro deve trovarsi nelle aree Stati Uniti orientali, Asia sud-orientale o Europa occidentale. Non è possibile associare a un progetto aree di lavoro di altre regioni.

L'area di lavoro deve trovarsi in una regione in cui la soluzione Mapping dei servizi è supportata. È possibile monitorare le macchine virtuali di Azure in qualsiasi area. Le macchine virtuali stesse non sono limitate alle aree supportate dall'area di lavoro Log Analytics.

In Log Analytics l'area di lavoro associata ad Azure Migrate e Modernize viene contrassegnata con la chiave del progetto di migrazione e il nome del progetto.
Agenti obbligatori In ogni server da analizzare installare gli agenti seguenti:

Microsoft Monitoring Agent (MMA)
Dependency Agent

Se i server locali non sono connessi a Internet, è necessario scaricare e installare il gateway di Log Analytics.

Altre informazioni sull'installazione di Dependency Agent e MMA.
Area di lavoro Log Analytics L'area di lavoro deve trovarsi nella stessa sottoscrizione del progetto.

Azure Migrate e Modernize supporta le aree di lavoro che risiedono nelle aree Stati Uniti orientali, Asia sud-orientale ed Europa occidentale.

L'area di lavoro deve trovarsi in una regione in cui la soluzione Mapping dei servizi è supportata. È possibile monitorare le macchine virtuali di Azure in qualsiasi area. Le macchine virtuali stesse non sono limitate alle aree supportate dall'area di lavoro Log Analytics.

Non è possibile modificare l'area di lavoro per un progetto dopo aver aggiunto l'area di lavoro.
Costi La soluzione Mapping dei servizi non comporta addebiti per i primi 180 giorni. Il conteggio inizia dal giorno in cui si associa l'area di lavoro Log Analytics al progetto.

Dopo 180 giorni vengono applicati gli addebiti standard di Log Analytics.

L'uso di qualsiasi soluzione diversa da Mapping dei servizi nell'area di lavoro Log Analytics associata comporta addebiti standard per Log Analytics.

Quando il progetto viene eliminato, l'area di lavoro non viene eliminata insieme a essa. Dopo aver eliminato il progetto, l'utilizzo di Mapping dei servizi non è gratuito. Ogni nodo viene addebitato in base al livello a pagamento dell'area di lavoro Log Analytics.

Se sono presenti progetti creati prima della disponibilità generale di Azure Migrate (disponibilità generale il 28 febbraio 2018), è possibile che vengano addebitati altri addebiti per Mapping dei servizi. Per garantire il pagamento solo dopo 180 giorni, è consigliabile creare un nuovo progetto. Le aree di lavoro create prima della disponibilità generale sono ancora addebitabili.
Gestione Quando si registrano gli agenti nell'area di lavoro, si usano l'ID e la chiave forniti dal progetto.

È possibile usare l'area di lavoro Log Analytics all'esterno di Azure Migrate e modernizzare.

Se si elimina il progetto associato, l'area di lavoro non viene eliminata automaticamente. Eliminarla manualmente.

Non eliminare l'area di lavoro creata da Azure Migrate e Modernizzare a meno che non si elimini il progetto. In tal caso, la funzionalità di visualizzazione delle dipendenze non funziona come previsto.
Connettività Internet Se i server non sono connessi a Internet, è necessario installare il gateway di Log Analytics.
Azure per enti pubblici L'analisi delle dipendenze basata su agente non è supportata.

Passaggi successivi

Preparare la valutazione dei server in esecuzione in Hyper-V.