Matrice di supporto per l'individuazione VMware

Questo articolo riepiloga i prerequisiti e i requisiti di supporto per l'uso dello strumento Azure Migrate: individuazione e valutazione per individuare e valutare i server in un ambiente VMware per la migrazione ad Azure.

Per valutare i server, creare prima di tutto un progetto di Azure Migrate. Lo strumento Azure Migrate: individuazione e valutazione viene aggiunto automaticamente al progetto. Distribuire quindi l'appliance Azure Migrate. L'appliance individua continuamente i server locali e invia metadati di configurazione e prestazioni ad Azure. Al termine dell'individuazione, raccogliere i server individuati in gruppi ed eseguire valutazioni per gruppo.

Quando si pianifica la migrazione dei server VMware in Azure, vedere la matrice di supporto della migrazione.

Requisiti di VMware

VMware	Dettagli
Server vCenter	I server da individuare e valutare devono essere gestite da un server vCenter versione 8.0, 7.0, 6.7, 6.5, 6.0 o 5.5. L'individuazione dei server fornendo i dettagli dell'host ESXi nell'appliance non è attualmente supportata. Gli indirizzi IPv6 non sono supportati per il server vCenter (per l'individuazione e la valutazione dei server) e gli host ESXi (per la replica dei server).
Autorizzazioni	Lo strumento Azure Migrate: individuazione e valutazione richiede un account di sola lettura del server vCenter. Se si vuole usare lo strumento per l'inventario software, l'analisi delle dipendenze senza agente, le app Web e l'individuazione SQL, l'account deve disporre dei privilegi per le operazioni guest nelle macchine virtuali VMware.

Requisiti del server

VMware	Dettagli
Sistemi operativi	Tutti i sistemi operativi Windows e Linux possono essere valutati per la migrazione.
Storage	Sono supportati i dischi collegati a controller basati su SCSI, IDE e SATA.

Requisiti dell'appliance di Azure Migrate

Microsoft Azure Migra e Modernizza usa l'appliance Azure Migrate per l'individuazione e la valutazione. È possibile distribuire l'appliance come server nell'ambiente VMware usando un modello VMware Open Virtualization Appliance importato nel server vCenter. È anche possibile usare lo script di PowerShell. Altre informazioni sui requisiti dell'appliance per VMware.

Ecco altri requisiti per l'appliance:

• In Azure per enti pubblici è necessario distribuire l'appliance tramite lo script.
• L'appliance deve essere in grado di accedere a URL specifici nei cloud pubblici e nei cloud per enti pubblici.

Requisiti di accesso porta

Dispositivo	Connessioni
Appliance di Azure Migrate	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 tramite l'URL https://<appliance-ip-or-name>:44368. Connessioni in uscita sulla porta 443 (HTTPS) per inviare metadati di individuazione e prestazioni a Microsoft Azure Migra e Modernizza.
Server vCenter	Connessioni in ingresso sulla porta TCP 443 per consentire all'appliance di raccogliere metadati di configurazione e prestazioni per le valutazioni. Per impostazione predefinita, l'appliance si connette a vCenter sulla porta 443. Se il server vCenter è in ascolto su una porta diversa, è possibile modificare la porta quando si configura l'individuazione.
Host ESXi	Per l'individuazione dell'inventario software o dell'analisi delle dipendenze senza agente, l'appliance si connette agli host ESXi sulla porta TCP 443 per individuare l'inventario software e le dipendenze nei server.

Requisiti dell'inventario software

Oltre all'individuazione dei server, Azure Migrate: individuazione e valutazione può 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 Microsoft Azure Migra e Modernizza. 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 10.000 server in esecuzione tra server vCenter aggiunti a ogni appliance Azure Migrate.
Sistemi operativi	Sono supportati i server che eseguono tutte le versioni di Windows e Linux.
Requisiti del server	Per l'inventario software, gli strumenti VMware devono essere installati e in esecuzione nei server. La versione degli strumenti VMware deve essere 10.2.1 o successiva. Sui server Windows deve essere installato PowerShell 2.0 o versione successiva. Strumentazione gestione Windows (WMI) deve essere abilitata e disponibile nei server Windows per raccogliere i dettagli dei ruoli e delle funzionalità installati nei server.
Account server vCenter	Per interagire con i server per l'inventario software, l'account di sola lettura del server vCenter usato per la valutazione deve disporre dei privilegi per le operazioni guest nelle macchine virtuali VMware.
Accesso al server	È possibile aggiungere più credenziali di dominio e non dominio (Windows/Linux) in Configuration Manager per le appliance per l'inventario software. È necessario disporre di un account utente guest per i server Windows e di un account utente standard (accesso non sudo) per tutti i server Linux.
Accesso alla porta	L'appliance Azure Migrate deve essere in grado di connettersi alla porta TCP 443 negli host ESXi che eseguono server in cui si vuole eseguire l'inventario software. Il server che esegue vCenter Server restituisce una connessione host ESXi per scaricare il file contenente i dettagli dell'inventario software. Se si usano le credenziali di dominio, l'appliance 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 dal server vCenter usando gli strumenti VMware installati nei server. L'appliance raccoglie le informazioni sull'inventario software dal server che esegue il server vCenter tramite le API vSphere. L'inventario software è senza agente. Non è installato alcun agente nel server e l'appliance non si connette direttamente ai server.

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

L'inventario software identifica le istanze di SQL Server. L'appliance tenta di connettersi alle rispettive istanze di SQL Server tramite l'autenticazione di Windows o le credenziali di autenticazione di SQL Server in Gestione configurazione appliance usando queste informazioni. L'appliance può connettersi solo alle istanze di SQL Server per le quali 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. L'appliance aggiorna i dati di configurazione di SQL Server ogni 24 ore e acquisisce i dati sulle prestazioni ogni 30 secondi.

Supporto tecnico	Dettagli
Server supportati	Supportato solo per i server che eseguono SQL Server in VMware, Microsoft Hyper-V e ambienti fisici/bare metal e server IaaS (Infrastructure as a Service) di altri cloud pubblici, ad esempio Amazon Web Services (AWS) e Google Cloud Platform (GCP). È 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	Sono supportati Windows Server 2008 e versioni successive.
Server Linux	Attualmente non supportato.
Meccanismo di autenticazione	Sono supportati l'autenticazione sia di Windows che di 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 delle distribuzioni SQL con disponibilità elevata e ripristino di emergenza basate su istanze del cluster di failover Always On e dei gruppi di disponibilità AlwaysOn.
Servizi SQL supportati	È supportato solo il motore di database di SQL Server. L'individuazione di SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services non è supportata.

Nota

Per impostazione predefinita, Microsoft Azure Migra e Modernizza usa il modo più sicuro per connettersi alle istanze di SQL. Ovvero, Microsoft Azure Migra e Modernizza crittografa la comunicazione tra l'appliance Azure Migrate e le istanze di SQL Server di origine impostando la proprietà TrustServerCertificate 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à. Pertanto, il server dell'appliance deve essere configurato per considerare attendibile l'autorità radice del certificato.

È possibile, tuttavia, modificare le impostazioni di connessione selezionando Modifica proprietà di connessione di SQL Server nell'appliance. Altre informazioni per comprendere la scelta da effettuare.

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

Usare gli script di esempio seguenti per creare l'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 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 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 un server dispone di un server Web installato, Microsoft Azure Migra e Modernizza 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. Microsoft Azure Migra e Modernizza esegue automaticamente il mapping delle credenziali ai rispettivi server, quindi non è necessario eseguirne il mapping manuale. Soprattutto, 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 le app Web ASP.NET (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 VMware, Hyper-V e fisici.	Server VMware, Hyper-V e fisici.
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 e Red Hat Enterprise Linux 5/6/7.
Versioni del server Web	IIS 7.5 e versioni successive.	Tomcat 8 o versione successiva.
Protocollo	Porta WinRM 5985 (HTTP)	Porta SSH 22 (TCP)
Privilegi obbligatori	Amministratore locale.	Utente radice o sudo.

Nota

I dati vengono sempre crittografati quando sono 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ù server vCenter) individuati per ogni appliance.
Server Windows	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 (64 bit) Windows Server 2008 (32 bit)
Server Linux	Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04, 22.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
Requisiti del server	Gli strumenti VMware (10.2.1 e versioni successive) devono essere installati ed eseguiti nei server da analizzare. Sulle macchine virtuali deve essere installato PowerShell 2.0 o versioni successive. WMI deve essere abilitato e disponibile nei server Windows.
Account server vCenter	L'account di sola lettura usato da Microsoft Azure Migra e Modernizza per la valutazione deve avere privilegi per le operazioni guest nelle macchine virtuali VMware.
Accesso al server Windows	Account utente guest
Accesso al server Linux	Un account utente sudo con autorizzazioni per eseguire comandi ls e netstat. Se si specifica un account utente sudo, assicurarsi di aver abilitato NOPASSWD per l'account per eseguire i comandi necessari senza richiedere una password ogni volta che viene richiamato il comando sudo. In alternativa, è possibile creare un account utente con le autorizzazioni CAP_DAC_READ_SEARCH e CAP_SYS_PTRACE per i file /bin/netstat e /bin/ls impostati usando i comandi seguenti: sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Accesso alla porta	L'appliance Azure Migrate deve essere in grado di connettersi alla porta TCP 443 negli host ESXi che eseguono i server con dipendenze da individuare. Il server che esegue vCenter Server restituisce una connessione host ESXi per scaricare il file contenente i dati relativi alle dipendenze.
Metodo di individuazione	Le informazioni sulle dipendenze tra server vengono raccolte usando gli strumenti VMware installati nel server che esegue vCenter Server. L'appliance raccoglie le informazioni dal server usando le API vSphere. Non è installato alcun agente nel server e l'appliance non si connette direttamente ai server.

Nota

In alcune versioni recenti del sistema operativo Linux, il comando netstat è stato sostituito dal ss comando. Tenere presente che quando si preparano i server.

Requisiti dell'analisi delle dipendenze (basata su agente)

L'analisi delle dipendenze consente di identificare le dipendenze tra server locali che si intende valutare e migrare in Azure. Nella tabella seguente sono riepilogati i requisiti per la configurazione dell'analisi delle dipendenze basata su agente.

Requisito	Dettagli
Prima della distribuzione	È necessario avere implementato un progetto con lo strumento Azure Migrate: individuazione e valutazione aggiunto al progetto. La visualizzazione delle dipendenze viene distribuita dopo aver configurato un'appliance Azure Migrate per individuare i server locali. Informazioni su come creare un progetto per la prima volta. Informazioni su come aggiungere uno strumento di individuazione e valutazione a un progetto esistente. Informazioni su come configurare l'appliance Azure Migrate per la valutazione di server Hyper-V, VMware o fisici.
Server supportati	Supportato per tutti i server nell'ambiente locale.
Log Analytics	Microsoft Azure Migra e Modernizza usa la soluzione Mapping dei servizi in Log di Monitoraggio di Azure per la visualizzazione delle dipendenze. Un'area di lavoro Log Analytics nuova o esistente viene associata al 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 è contrassegnata con la chiave di progetto e con il nome del progetto.
Agenti obbligatori	In ogni server che si desidera analizzare, installare gli agenti seguenti: - Agente di Monitoraggio di Azure (AMA) - Dependency Agent Se i server locali non sono connessi a Internet, scaricare e installare il gateway di Log Analytics. Altre informazioni sull'installazione di Dependency Agent e dell'agente di Monitoraggio di Azure.
area di lavoro Log Analytics	L'area di lavoro deve trovarsi nella stessa sottoscrizione del progetto. Azure Migrate supporta le aree di lavoro che si trovano 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.
Costo	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. Se si usa una soluzione diversa da Mapping dei servizi nell'area di lavoro Log Analytics associata vengono applicati gli addebiti standard di Log Analytics. Quando il progetto viene eliminato, l'area di lavoro non viene eliminata automaticamente. 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 dal 28 febbraio 2018), è possibile che vengano addebitati altri addebiti per Mapping dei servizi. Per assicurarsi che i costi vengano addebitati 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 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 Microsoft Azure Migra e Modernizza. Se si elimina il progetto associato, l'area di lavoro non viene eliminata automaticamente. Eliminarla manualmente. Non eliminare l'area di lavoro creata da Microsoft Azure Migra e Modernizza, a meno che non si rimuova 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, installare il gateway di Log Analytics nei server.
Azure Government	L'analisi delle dipendenze basata su agente non è supportata.

Limiti

Requisito	Dettagli
Limiti di progetto	È possibile creare più progetti di Azure Migrate in una sottoscrizione di Azure. È possibile individuare e valutare fino a 50.000 server in un ambiente VMware in un singolo progetto. Un progetto può includere server fisici e server da un ambiente Hyper-V, fino ai limiti di valutazione.
Individuazione	L'appliance Azure Migrate può individuare fino a 10.000 server in esecuzione in più server vCenter. L'appliance supporta l'aggiunta di più server vCenter. È possibile aggiungere fino a 10 server vCenter per appliance. Questo importo è valido anche per la soluzione Azure VMware.
Valutazione	È possibile aggiungere fino a 35.000 server in un singolo gruppo. È anche possibile valutare fino a 35.000 server in una singola valutazione.

Altre informazioni sulle valutazioni.

Importare server usando RVTools XLSX (anteprima)

Come parte del percorso di migrazione ad Azure usando l'appliance Azure Migrate, è prima possibile individuare server, inventario e carichi di lavoro. Tuttavia, per una valutazione rapida prima di distribuire l'appliance, è possibile importare i server usando il file XLSX RVTools (anteprima).

Vantaggi chiave

Uso di un file XLSX RVTools:

• Consente di creare un caso aziendale o valutare i server prima di distribuire l'appliance.
• In alternativa, quando è presente una restrizione organizzativa per distribuire l'appliance Azure Migrate.
• È utile quando non è possibile condividere le credenziali che consentono l'accesso ai server locali.
• È utile quando i vincoli di sicurezza impediscono la raccolta e l'invio di dati raccolti dall'appliance ad Azure.

Limiti

In questa sezione vengono descritte le limitazioni da considerare.

Considerazioni sul caso aziendale

Se si importano server usando un file XLSX di RVTools e creando un caso aziendale, ecco alcune limitazioni:

• La durata della cronologia delle prestazioni nelle impostazioni di Azure non è applicabile.
• I server vengono classificati come sconosciuti nel grafico delle informazioni dettagliate sull'utilizzo dei casi aziendali e vengono ridimensionati così come sono senza ridimensionamento corretto per i costi della soluzione Azure o Azure VMware.

Considerazioni sulla valutazione

Se si importano server usando un file XLSX di RVTools per la creazione di una valutazione con i criteri seguenti:

• Criteri di dimensionamento come basati sulle prestazioni sulla CPU e sulla memoria configurate (in base alle CPU e alle colonne Memoria di RVTools XLSX).
• Criteri di archiviazione (MiB in uso e MB in uso per le versioni precedenti alla 4.1.2).

Non sarà possibile fornire informazioni sulla cronologia delle prestazioni o sul percentile.

Per ottenere un'idoneità/preparazione accurata del sistema operativo nella macchina virtuale di Azure e nella valutazione della soluzione Azure VMware, immettere la versione e l'architettura del sistema operativo nelle rispettive colonne.

Passaggi successivi

• Rivedere le procedure consigliate per la valutazione.
• Informazioni su come prepararsi per una valutazione VMware.