Matrice di supporto per la valutazione e l'individuazione di server fisici

Questo articolo riepiloga i prerequisiti e i requisiti di supporto quando si valutano i server fisici per la migrazione a Azure usando lo strumento Azure Migrate: Individuazione e valutazione. Per eseguire la migrazione di server fisici a Azure, vedere la matrice di supporto migration.

Per valutare i server fisici, creare un progetto e aggiungere il Azure Migrate: strumento di individuazione e valutazione al progetto. Dopo aver aggiunto lo strumento, distribuire l'appliance Azure Migrate. L'appliance individua continuamente i server locali e invia metadati e dati sulle prestazioni dei server a Azure. Dopo l'individuazione, è possibile raccogliere i server individuati in gruppi ed eseguire valutazioni per un gruppo.

Limiti

Supporto tecnico Dettagli
Limiti di valutazione È possibile individuare e valutare fino a 35.000 server fisici in un singolo progetto.
Limiti del Progetto È possibile creare più progetti in una sottoscrizione Azure. Oltre ai server fisici, un progetto può includere server in VMware e in Hyper-V, fino ai limiti di valutazione per ognuno di essi.
Individuazione L'appliance Azure Migrate può individuare fino a 1.000 server fisici.
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.

Requisiti per i server fisici

  • Distribuzione di server fisici: Il server fisico può essere autonomo o distribuito in un cluster.

  • Tipo di server: Server bare metal, server virtualizzati in esecuzione in locale o altri cloud come Amazon Web Services (AWS), Google Cloud Platform (GCP) e Xen.

    Nota

    Attualmente, Azure Migrate non supporta l'individuazione di server paravirtualizzati.

  • Operating system: Tutti i sistemi operativi Windows e Linux possono essere valutati per la migrazione.

    Nota

    Windows Server 2008, 2008 R2, 2012 e 2012 R2 hanno raggiunto la fine del supporto (EOS). Esaminare di conseguenza l'utilizzo e pianificare gli aggiornamenti e le migrazioni del sistema operativo. Per altre informazioni, vedere Fine del supporto per:

Di conseguenza, Azure Migrate non garantisce risultati coerenti o affidabili per queste versioni del sistema operativo. I clienti possono riscontrare problemi e consigliano vivamente di eseguire l'aggiornamento a una versione di Windows Server supportata prima di avviare la migrazione.

requisiti dell'appliance Azure Migrate

Azure Migrate usa l'appliance Azure Migrate per l'individuazione e la valutazione. L'appliance per i server fisici può essere eseguita in una macchina virtuale (VM) o in un server fisico.

Accesso alla porta

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

Dispositivo Connessioni
Apparecchio 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 sulle porte 443 (HTTPS) per inviare metadati di individuazione e prestazioni ad Azure Migrate e Modernize.
Server fisici Windows: le connessioni in ingresso sulla porta WinRM 5986 (HTTPS) vengono usate per eseguire il pull dei metadati di configurazione e prestazioni dai server Windows.

Se i prerequisiti HTTPS non sono configurati nei server di Hyper-V di destinazione, la comunicazione dell'appliance eseguirà il fallback alla porta WinRM 5985 (HTTP).

Per applicare la comunicazione HTTPS senza fallback, attivare o disattivare Gestione configurazione appliance.

Dopo l'abilitazione, assicurarsi che i prerequisiti siano configurati nei server di destinazione.

- Se i certificati non sono configurati nei server di destinazione, l'individuazione avrà esito negativo sia nei server attualmente individuati che nei server appena aggiunti.

- WinRM HTTPS richiede un certificato di autenticazione server del computer locale con un nome comune (CN) corrispondente al nome host. Il certificato non deve essere scaduto, revocato o autofirmato. Per la configurazione di WinRM per HTTPS, vedere l'articolo .

- Linux: connessioni in ingresso sulla porta 22 (TCP) per eseguire il pull dei metadati di configurazione e prestazioni dai server Linux.

Requisiti dell'inventario software

Oltre all'individuazione dei server, Azure Migrate: Discovery and assessment esegue l'inventario software sui server. L'inventario software fornisce l'elenco di applicazioni, ruoli e funzionalità in esecuzione in server Windows e Linux individuati usando 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 1.000 server individuati da ogni appliance Azure Migrate.
Sistemi operativi Sono supportati i server che eseguono tutte le versioni Windows e Linux che soddisfano i requisiti del server e dispongono delle autorizzazioni di accesso necessarie.
Requisiti del server I server Windows devono avere il remoting di PowerShell abilitato e la versione 2.0 o successiva di PowerShell 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à 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 Windows Un account utente ospite per i server Windows.
Accesso al server Linux Un account utente standard (accesso non sudo) per tutti i server Linux.
Accesso alla porta Windows server devono accedere alla porta 5986 (HTTPS) o 5985 (HTTP). I server Linux devono accedere alla porta 22 (TCP).
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 usando la connessione SSH.

L'inventario software è senza agente. Nei server non vengono installati agenti.

Requisiti di rilevamento per l'istanza e il database di SQL Server

Inventario software identifica le istanze di SQL Server. L'appliance tenta di connettersi alle rispettive istanze di SQL Server tramite le credenziali di autenticazione di Windows o di SQL Server fornite in Gestione configurazione appliance, utilizzando queste informazioni. L'appliance può connettersi solo a quelle istanze di SQL Server per le quali ha portata 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 SQL Server istanze e database. L'appliance aggiorna i dati di configurazione 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 AWS e GCP.

È possibile individuare fino a 750 istanze di SQL Server o 15.000 database SQL, a seconda di quale tra i due numeri sia inferiore, utilizzando una singola appliance. È 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 supportate.
Server Linux Attualmente non supportato.
Meccanismo di autenticazione Sono supportate sia l'autenticazione di Windows che quella di SQL Server. È possibile specificare le credenziali di entrambi i tipi di autenticazione in Gestione configurazione appliance.
l'accesso a SQL Server Per individuare istanze e database SQL Server, l'account di dominio Windows/SQL Server o SQL Server account require queste autorizzazioni di lettura con privilegi limitati per ogni istanza di SQL Server. È possibile utilizzare l'utilità di provisioning degli account con privilegi limitati per creare account personalizzati o utilizzare qualsiasi account esistente che sia membro del ruolo del server sysadmin per semplicità d'uso.
versioni di SQL Server sono supportati SQL Server 2008 e versioni successive.
edizioni 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 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, Azure Migrate usa il modo più sicuro per connettersi alle istanze DI SQL. Ovvero, Azure Migrate e Modernize 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.

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

Configurare l'accesso personalizzato per il rilevamento di SQL Server

Usare i seguenti script di esempio per creare un account di accesso e assegnarlo con le autorizzazioni necessarie.

Autenticazione 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 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 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. 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 ASP.NET app Web (server Web IIS) e Java app Web (server Tomcat). I dati di configurazione delle app Web vengono aggiornati una volta ogni 24 ore.

Supporto tecnico App Web ASP.NET Applicazioni 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 Server che soddisfano i requisiti
Versioni del server Web IIS 7.5 e versioni successive Tomcat 8 e versioni successive
Protocollo Porta WinRM 5986 (HTTPS) per impostazione predefinita, se i prerequisiti HTTPS non sono configurati nei server di destinazione, la comunicazione esegue il fallback alla porta WinRM 5985 (HTTP) Porta SSH 22 (TCP)
Privilegi obbligatori L'utente con privilegi minimi deve far parte dei due gruppi di utenti 1. Utenti gestione remota 2. IIS_IUSRS. Gli utenti devono disporre delle autorizzazioni di lettura per i percorsi seguenti: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config e C:\Windows\system32\inetsrv\config\redirection.config.

Aggiungere l'utente a "accedere come processo batch" usando secpol.msc e assicurarsi che l'utente non faccia parte di "nega accesso come processo batch".
Autorizzazioni di lettura (r) ed esecuzione (x) applicate in modo ricorsivo a tutte le directory di CATALINA_HOME.

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 Azure Migrate. È possibile usare le dipendenze per raggruppare i server correlati per la migrazione a 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 individuati per ogni appliance.
Sistemi operativi Sono supportati i server che eseguono tutte le versioni Windows e Linux che soddisfano i requisiti del server e dispongono delle autorizzazioni di accesso necessarie.
Requisiti del server I server Windows devono avere il remoting di PowerShell abilitato e la versione 2.0 o successiva di PowerShell 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 al server Windows Un account utente (locale o di dominio) con autorizzazioni di amministratore per i server.
Accesso al server Linux Fare riferimento a questo collegamento per l'accesso al server Linux.
Accesso alla porta Windows server devono accedere alla porta 5986 (HTTPS) o 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 basata su agente è supportata solo nella visualizzazione classica e non è disponibile nella nuova esperienza. La visualizzazione classica sarà ritirata entro la fine del 2026. Fino ad allora, è possibile continuare ad accedere alle aree di lavoro Log Analytics per i server in cui l'analisi delle dipendenze basata su agente è già abilitata. Non è tuttavia possibile eseguire l'onboarding di nuovi server per l'analisi delle dipendenze basata su agente. Per informazioni, vedere Configurare la visualizzazione delle dipendenze.

Se si utilizza Service Map per l'analisi delle dipendenze basata su agenti, esegui la migrazione a VM Insights. ServiceMap è stato ritirato.

Nota

L'analisi delle dipendenze basata su agente non è gratuita. Si applicano addebiti per l'utilizzo dell'area di lavoro Log Analytics. Per informazioni dettagliate, vedere Prezzi di Monitoraggio di Azure.

Passaggi successivi

Preparare l'individuazione dei server fisici.