Macierz wspierania analizy Hyper-V

W tym artykule omówiono wymagania wstępne i wymagania dotyczące pomocy technicznej podczas odnajdywania i oceniania serwerów lokalnych działających w środowisku Hyper-V w ramach migracji do platformy Azure z użyciem narzędzia Azure Migrate: Discovery and assessment. Jeśli chcesz migrować serwery działające na Hyper-V do Azure, zobacz macierz wsparcia migracji.

Aby skonfigurować odnajdywanie i ocenę serwerów działających na Hyper-V, należy utworzyć projekt i dodać Azure Migrate: narzędzie odnajdywania i oceny do projektu. Po dodaniu narzędzia należy wdrożyć urządzenie Azure Migrate. Urządzenie stale odnajduje serwery lokalne i wysyła metadane serwera i dane wydajności do Azure. Zaraz po zakończeniu procesu odkrywania można zebrać odnalezione serwery w grupach i uruchomić ocenę dla tej grupy.

Ograniczenia

Wsparcie	Szczegóły
Limity ocen	W jednym projekcie można odnajdywać i oceniać maksymalnie 35 000 serwerów.
Ograniczenia projektu	Możesz utworzyć wiele projektów w subskrypcji Azure. Oprócz serwerów na Hyper-V projekt może zawierać serwery na VMware i serwery fizyczne, do limitów ustalonych dla oceny każdego z nich.
Odnajdowanie	Urządzenie Azure Migrate może odnaleźć maksymalnie 5000 serwerów działających na Hyper-V. Urządzenie może łączyć się z maksymalnie 300 Hyper-V hostami.
Ocena	Do jednej grupy można dodać maksymalnie 35 000 serwerów. W jednej ocenie grupy można ocenić maksymalnie 35 000 serwerów.

Dowiedz się więcej o ocenach.

wymagania dotyczące hosta Hyper-V

Wsparcie	Szczegóły
host Hyper-V	Host Hyper-V może być autonomiczny lub wdrożony w klastrze. Host Hyper-V może uruchamiać Windows Server 2022, Windows Server 2019, Windows Server 2016 lub Windows Server 2012 R2. Obsługiwane są również instalacje podstawowe serwera tych systemów operacyjnych. Nie można ocenić serwerów znajdujących się na hostach Hyper-V z systemem Windows Server 2012.
Uprawnienia	Musisz mieć uprawnienia administratora na hoście Hyper-V. Jeśli nie chcesz przypisywać uprawnień administratora, utwórz konto użytkownika lokalnego lub domeny i dodaj konto użytkownika do następujących grup: Użytkownicy zdalnego zarządzania, administratorzy Hyper-V i użytkownicy monitor wydajności.
Zdalne zarządzanie PowerShell	Komunikacja zdalna programu PowerShell musi być włączona na każdym hoście Hyper-V.
replika Hyper-V	Jeśli używasz technologii Hyper-V Replica (lub masz wiele serwerów z tymi samymi identyfikatorami serwera) i odnajdujesz zarówno oryginalne, jak i zreplikowane serwery za pomocą Azure Migrate and Modernize, ocena wygenerowana przez Azure Migrate and Modernize może nie być dokładna.

Wymagania dotyczące serwera

Wsparcie	Szczegóły
System operacyjny	Wszystkie systemy operacyjne można ocenić pod kątem migracji.
Usługi Integracji	Hyper-V Integration Services musi być uruchomiony na serwerach, które oceniasz, aby przechwycić informacje o systemie operacyjnym.
Magazyn	Dysk lokalny, DAS, JBOD, Miejsca do magazynowania, CSV i SMB. Te magazyny hostów Hyper-V, na których są przechowywane dyski VHD/VHDX, są obsługiwane. Obsługiwane są kontrolery wirtualne IDE i SCSI.

wymagania dotyczące urządzenia Azure Migrate

Azure Migrate and Modernize używa urządzenia Azure Migrate do odkrywania i oceniania. Urządzenie można wdrożyć przy użyciu skompresowanego dysku VHD Hyper-V pobranego z portalu lub przy użyciu skryptu programu PowerShell. Więcej informacji:

• Dowiedz się więcej o wymaganiach aplikacji dla Hyper-V.
• Dowiedz się więcej o adresach URL, do których urządzenie musi uzyskiwać dostęp w chmurach publicznych i rządowych .
• Użyj skryptu w celu wdrożenia urządzenia w Azure Government.

Dostęp do portów

W poniższej tabeli przedstawiono podsumowanie wymagań dotyczących portów na potrzeby oceny.

Urządzenie	Połączenie
Urządzenie	Połączenia przychodzące na porcie TCP 3389 umożliwiają nawiązywanie połączeń pulpitu zdalnego z urządzeniem. Połączenia przychodzące na porcie 44368 w celu zdalnego uzyskiwania dostępu do aplikacji do zarządzania urządzeniami przy użyciu adresu URL: https://<appliance-ip-or-name>:44368 Połączenia wychodzące na portach 443 (HTTPS) w celu wysyłania metadanych dotyczących odkrywania i wydajności do Azure Migrate i Modernize.
host/klaster Hyper-V	Połączenie przychodzące domyślnie używa portu WinRM 5986 (HTTPS). Jeśli wymagania wstępne protokołu HTTPS nie są skonfigurowane na serwerach docelowych, komunikacja wraca do portu 5985 usługi WinRM (HTTP) w celu zbierania metadanych i danych wydajności dla serwerów funkcji Hyper-V przy użyciu sesji modelu wspólnych informacji (CIM).
Serwery	Windows serwery potrzebują dostępu na porcie 5986 (HTTPS) lub 5985 (HTTP). Serwery z systemem Linux potrzebują dostępu na porcie 22 (TCP), aby przeprowadzić spis oprogramowania i analizę zależności bez agenta.

Wymagania dotyczące spisu oprogramowania

Oprócz odnajdywania serwerów, Azure Migrate: Discovery and assessment może także wykonywać spis oprogramowania na serwerach. Spis oprogramowania zawiera listę aplikacji, ról i funkcji działających na serwerach Windows i Linux, które są odnajdywane z użyciem Azure Migrate i Modernize. Ułatwia ona identyfikowanie i planowanie ścieżki migracji dostosowanej do obciążeń lokalnych.

Wsparcie	Szczegóły
Obsługiwane serwery	Spis oprogramowania można wykonywać na maksymalnie 5000 serwerach działających na Hyper-V hostach/klastrach dodanych do każdego urządzenia Azure Migrate.
Systemy operacyjne	Wszystkie wersje Windows i Linux z włączonymi usługami integracji Hyper-V.
Wymagania dotyczące serwera	Serwery Windows wymagają włączonej zdalnej komunikacji PowerShell i zainstalowanej wersji 2.0 lub nowszej programu PowerShell. Usługa WMI musi być włączona i dostępna na serwerach Windows w celu zebrania szczegółów ról i funkcji zainstalowanych na serwerach. Serwery z systemem Linux muszą mieć włączoną łączność protokołu Secure Shell (SSH) i upewnić się, że na serwerach z systemem Linux można wykonać następujące polecenia, aby ściągnąć dane aplikacji: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Na podstawie typu systemu operacyjnego i typu używanego menedżera pakietów poniżej przedstawiono kilka dodatkowych poleceń: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Dostęp do serwera	Możesz dodać wiele domen oraz poświadczeń spoza domeny (Windows/Linux) w menedżerze konfiguracji urządzenia w celu inwentaryzacji oprogramowania. Musisz mieć konto użytkownika-gościa dla serwerów Windows i konta użytkownika standardowego (dostęp inny niż sudo) dla wszystkich serwerów z systemem Linux.
Dostęp do portów	Windows serwery potrzebują dostępu na porcie 5986 (HTTPS) lub 5985 (HTTP). Serwery z systemem Linux wymagają dostępu na porcie 22 (TCP). Jeśli używasz poświadczeń domeny, urządzenie Azure Migrate musi mieć możliwość nawiązania połączenia z następującymi portami TCP i UDP: TCP 135 — punkt końcowy RPC TCP 389 — LDAP TCP 636 — LDAP SSL TCP 445 — SMB TCP/UDP 88 — uwierzytelnianie Kerberos TCP/UDP 464 — operacje zmiany protokołu Kerberos
Odnajdowanie	Spis oprogramowania jest wykonywany przez bezpośrednie łączenie się z serwerami przy użyciu poświadczeń serwera dodanych na urządzeniu. Urządzenie zbiera informacje o spisie oprogramowania z serwerów Windows za pomocą zdalnego zarządzania PowerShell, a z serwerów Linux przy użyciu połączenia SSH. Inwentaryzacja oprogramowania nie wymaga agenta. Na serwerach nie zainstalowano żadnego agenta.

wymagania dotyczące instancji SQL Server i odkrywania bazy danych

Software inventory identyfikuje wystąpienia SQL Server. Urządzenie używa tych informacji i próbuje nawiązać połączenie z odpowiednimi wystąpieniami SQL Server za pośrednictwem uwierzytelniania Windows lub SQL Server, o których mowa w menedżerze konfiguracji urządzenia. Urządzenie może łączyć się tylko z tymi instancjami SQL Server, z którymi ma widoczność sieciową. Spis oprogramowania sam w sobie może nie potrzebować widoczności sieci.

Po nawiązaniu połączenia urządzenie zbiera dane dotyczące konfiguracji i wydajności dla wystąpień i baz danych SQL Server. SQL Server dane konfiguracji są aktualizowane co 24 godziny. Dane wydajności są przechwytywane co 30 sekund.

Wsparcie	Szczegóły
Obsługiwane serwery	Obsługiwane tylko w przypadku serwerów z systemem SQL Server w środowisku VMware, Microsoft Hyper-V, środowiskach fizycznych/bare-metal oraz serwerach infrastruktury jako usługi (IaaS) innych chmur publicznych, takich jak Microsoft Azure i Google Cloud Platform. Na jednym urządzeniu można odnaleźć maksymalnie 750 SQL Server wystąpień lub 15 000 baz danych SQL. Zalecamy, aby urządzenie miało możliwość odnalezienia mniej niż 600 serwerów uruchomionych SQL, aby uniknąć problemów ze skalowaniem.
serwery Windows	obsługiwane są Windows Server 2008 i nowsze.
Serwery z systemem Linux	Obecnie nie obsługiwane.
Mechanizm uwierzytelniania	Obsługiwane są zarówno uwierzytelnianie Windows, jak i SQL Server. Poświadczenia obu typów uwierzytelniania można podać w menedżerze konfiguracji urządzenia.
Dostęp do SQL Server	Aby odnaleźć wystąpienia i bazy danych SQL Server, konto Windows/domeny lub konto SQL Server wymaga niskich uprawnień odczytu dla każdego wystąpienia SQL Server. Możesz użyć narzędzia aprowizowania konta o niskim poziomie uprawnień, aby utworzyć konta niestandardowe lub dla uproszczenia użyć dowolnego istniejącego konta, które jest członkiem roli serwera sysadmin.
wersje SQL Server	obsługiwane są SQL Server 2008 i nowsze.
SQL Server edycje	Obsługiwane są wersje Enterprise, Standard, Developer i Express.
Obsługiwana konfiguracja SQL	Obsługuje się odnajdywanie autonomicznych, wysoce dostępnych i zabezpieczonych przed awariami wdrożeń SQL. Odkrywanie wdrożeń SQL o wysokiej dostępności i odzyskiwaniu po awarii z wykorzystaniem Always On failover cluster instances oraz Always On availability groups jest również obsługiwane.
Obsługiwane usługi SQL	Obsługiwany jest tylko silnik bazy danych SQL Server. Odnajdywanie SQL Server Reporting Services, SQL Server Integration Services i SQL Server Analysis Services nie jest obsługiwane.

Uwaga

Domyślnie Azure Migrate i Modernize korzystają z najbezpieczniejszego sposobu łączenia się z wystąpieniami SQL. Oznacza to, że Azure Migrate and Modernize szyfruje komunikację między urządzeniem Azure Migrate a wystąpieniami SQL Server źródłowymi, poprzez ustawienie właściwości TrustServerCertificate na wartość true. Ponadto warstwa transportu używa protokołu Secure Socket Layer do szyfrowania kanału i pomijania łańcucha certyfikatów w celu zweryfikowania zaufania. Z tego powodu serwer urządzenia musi być skonfigurowany tak, aby ufał głównej instytucji certyfikującej certyfikatu.

Można jednak zmodyfikować ustawienia połączenia, wybierając pozycję Edytuj właściwości połączenia SQL Server na urządzeniu. Dowiedz się więcej , aby dowiedzieć się, co wybrać.

Konfigurowanie niestandardowego logowania na potrzeby odnajdywania SQL Server

Użyj poniższych przykładowych skryptów, aby utworzyć login i przypisać mu niezbędne uprawnienia.

uwierzytelnianie 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

Uwierzytelnianie 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

Wymagania dotyczące odnajdywania aplikacji internetowych

Spis oprogramowania identyfikuje rolę serwera internetowego, która istnieje na odnalezionych serwerach. Jeśli na serwerze zostanie wykryta zainstalowana usługa internetowa, Azure Migrate i Modernize odkrywa aplikacje internetowe na tym serwerze.

Możesz dodać zarówno poświadczenia domeny, jak i niedomeny na urządzeniu. Upewnij się, że używane konto ma uprawnienia administratora lokalnego na serwerach źródłowych. Azure Migrate i Modernizacja automatycznie mapują poświadczenia na odpowiednie serwery, dlatego nie trzeba ich mapować ręcznie. Te poświadczenia nigdy nie są wysyłane do Microsoft i pozostają na urządzeniu uruchomionym w środowisku źródłowym.

Po nawiązaniu połączenia urządzenie zbiera dane konfiguracji dla aplikacji internetowych ASP.NET (serwer internetowy usług IIS) i Java aplikacji internetowych (serwery Tomcat). Dane konfiguracji aplikacji internetowych są aktualizowane co 24 godziny.

Wsparcie	ASP.NET aplikacji internetowych	Java aplikacje internetowe
Stos	Serwery VMware, Hyper-V i fizyczne.	Serwery VMware, Hyper-V i fizyczne.
serwery Windows	obsługiwane są Windows Server 2008 R2 i nowsze.	Niewspierane.
Serwery z systemem Linux	Niewspierane	Serwery spełniające wymagania.
Wersje serwera internetowego	IIS 7.5 lub nowszy	Tomcat 8 lub nowszy
Protokół	Port WinRM 5986 (HTTPS) jest używany domyślnie, jeśli wymagania wstępne HTTPS nie są skonfigurowane na serwerach docelowych, komunikacja wraca do portu usługi WinRM 5985 (HTTP).	Port SSH 22 (TCP)
Wymagane uprawnienia	Najmniej uprzywilejowany użytkownik powinien być częścią dwóch grup użytkowników 1. Użytkownicy zarządzania zdalnego 2. IIS_IUSRS. Użytkownicy muszą mieć uprawnienia do odczytu do następujących lokalizacji: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config i C:\Windows\system32\inetsrv\config\redirection.config. Dodaj użytkownika do "zalogowanie się jako zadanie wsadowe" przy użyciu polecenia secpol.msc i upewnij się, że użytkownik nie jest częścią "odmów zalogowania się jako zadanie wsadowe".	Uprawnienia odczytu (r) i wykonywania (x) rekursywnie we wszystkich katalogach CATALINA_HOME.

Uwaga

Dane są zawsze szyfrowane w stanie spoczynku i podczas przesyłania.

Wymagania dotyczące analizy zależności (bez agenta)

Analiza zależności ułatwia analizowanie zależności między odnalezionymi serwerami. Zależności można łatwo wizualizować za pomocą widoku mapy w projekcie Azure Migrate. Zależności można używać do grupowania powiązanych serwerów na potrzeby migracji do Azure. W poniższej tabeli przedstawiono podsumowanie wymagań dotyczących konfigurowania analizy zależności bez agenta.

Wsparcie	Szczegóły
Obsługiwane serwery	Możesz włączyć analizę zależności bez agenta na maksymalnie 1000 serwerach (w wielu hostach/klastrach Hyper-V) odnalezionych na urządzeniu.
Systemy operacyjne	Wszystkie wersje Windows i Linux z włączonymi usługami integracji Hyper-V.
Wymagania dotyczące serwera	Serwery Windows wymagają włączonej zdalnej komunikacji PowerShell i zainstalowanej wersji 2.0 lub nowszej programu PowerShell. Serwery z systemem Linux muszą mieć włączoną łączność SSH i należy upewnić się, że na serwerach z systemem Linux można wykonywać następujące polecenia: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
dostęp do serwera Windows	Konto użytkownika (lokalne lub domena) z uprawnieniami administratora na serwerach
Dostęp do serwera z systemem Linux	Konto użytkownika sudo z uprawnieniami do wykonywania poleceń ls i netstat. Jeśli udostępniasz konto użytkownika sudo, upewnij się, że włączysz dla konta noPASSWD uruchamianie wymaganych poleceń bez monitowania o hasło przy każdym wywołaniu polecenia sudo.
Dostęp do portów	Windows serwery potrzebują dostępu na porcie 5986 (HTTPS) lub 5985 (HTTP). Serwery z systemem Linux wymagają dostępu na porcie 22 (TCP).
Metoda odnajdywania	Analiza zależności bez agenta jest wykonywana przez bezpośrednie łączenie się z serwerami przy użyciu poświadczeń serwera dodanych na urządzeniu. Urządzenie zbiera informacje o zależnościach na serwerach Windows przy użyciu zdalnego zarządzania PowerShell oraz na serwerach z systemem Linux przy użyciu połączenia SSH. Żaden agent nie jest zainstalowany na serwerach w celu ściągnięcia danych zależności.

Wymagania dotyczące analizy zależności opartej na agencie

Analiza współzależności pomaga zidentyfikować zależności między serwerami lokalnymi, które chcesz ocenić i przeprowadzić migrację do Azure. Tabela zawiera podsumowanie wymagań dotyczących konfigurowania analizy zależności opartej na agencie. Hyper-V obecnie obsługuje tylko wizualizację zależności opartą na agencie.

Wymaganie	Szczegóły
Przed wdrożeniem	Projekt powinien być przygotowany tak, aby zawierał narzędzie Azure Migrate: Odkrywanie i ocena dodane do projektu. Wizualizacja zależności jest wdrażana po skonfigurowaniu urządzenia Azure Migrate w celu odnalezienia serwerów lokalnych. Dowiedz się, jak utworzyć projekt po raz pierwszy. Dowiedz się, jak dodać Azure Migrate: narzędzie odnajdywania i oceny do istniejącego projektu. Dowiedz się, jak skonfigurować narzędzie do wykrywania i oceny serwerów na Hyper-V.
Azure Government	Wizualizacja zależności nie jest dostępna w Azure Government.
Analiza dzienników	Azure Migrate i Modernize używa rozwiązania Service Map w dziennikach Azure Monitor dla wizualizacji zależności. Skojarzysz nowy lub istniejący obszar roboczy Log Analytics z projektem. Nie można zmodyfikować obszaru roboczego dla projektu po dodaniu obszaru roboczego. Obszar roboczy musi znajdować się w tej samej subskrypcji co projekt. Obszar roboczy musi znajdować się w regionach Wschodnie stany USA, Azja Południowo-Wschodnia lub Europa Zachodnia. Nie można skojarzyć obszarów roboczych w innych regionach z projektem. Obszar roboczy musi znajdować się w regionie, w którym jest obsługiwana mapa usługi. Możesz monitorować maszyny wirtualne Azure w dowolnym regionie. Same maszyny wirtualne nie są ograniczone do regionów obsługiwanych przez obszar roboczy Log Analytics. W Log Analytics obszar roboczy przypisany do Azure Migrate i Modernize jest oznaczony kluczem Projekt migracji i nazwą projektu.
Wymagane agenty	Na każdym serwerze, który chcesz przeanalizować, zainstaluj następujących agentów: Agent monitorowania firmy Microsoft (MMA) Agent zależności Jeśli serwery lokalne nie są połączone z Internetem, należy pobrać i zainstalować na nich bramę Log Analytics. Dowiedz się więcej o instalowaniu agenta zależności i MMA.
obszar roboczy usługi Log Analytics	Obszar roboczy musi znajdować się w tej samej subskrypcji co projekt. Azure Migrate i Modernize wspierają obszary robocze znajdujące się w regionach Wschodnich Stanów Zjednoczonych, Azji Południowo-Wschodniej i Europy Zachodniej. Obszar roboczy musi znajdować się w regionie, w którym jest obsługiwana mapa usługi. Możesz monitorować maszyny wirtualne Azure w dowolnym regionie. Same maszyny wirtualne nie są ograniczone do regionów obsługiwanych przez obszar roboczy Log Analytics. Nie można zmodyfikować obszaru roboczego dla projektu po dodaniu obszaru roboczego.
Koszty	Rozwiązanie Service Map nie powoduje naliczania opłat za pierwsze 180 dni. Liczba rozpoczyna się od dnia skojarzenia obszaru roboczego Log Analytics z projektem. Po upływie 180 dni obowiązują standardowe opłaty za Log Analytics. Użycie dowolnego rozwiązania innego niż Service Map w skojarzonym obszarze roboczym Log Analytics powoduje naliczenie standardowych opłat dla Log Analytics. Po usunięciu projektu obszar roboczy nie zostanie usunięty wraz z nim. Po usunięciu projektu użycie usługi Service Map nie jest bezpłatne. Opłaty za każdy węzeł są naliczane zgodnie z płatną warstwą obszaru roboczego Log Analytics. Jeśli masz projekty utworzone przed ogólną dostępnością Azure Migrate, która miała miejsce 28 lutego 2018 r., mogą zostać naliczone inne opłaty za usługę Service Map. Aby zapewnić płatność dopiero po upływie 180 dni, zalecamy utworzenie nowego projektu. Obszary robocze, które zostały utworzone przed datą ogólnej dostępności, nadal podlegają opłatom.
Zarządzanie	Podczas rejestrowania agentów w obszarze roboczym należy użyć identyfikatora i klucza dostarczonego przez projekt. Obszar roboczy Log Analytics może być używany poza programem Azure Migrate and Modernize. Jeśli usuniesz skojarzony projekt, obszar roboczy nie zostanie usunięty automatycznie. Usuń ją ręcznie. Nie usuwaj obszaru roboczego utworzonego przez Azure Migrate i modernizuj, chyba że usuniesz projekt. Jeśli tak, funkcja wizualizacji zależności nie działa zgodnie z oczekiwaniami.
Łączność z Internetem	Jeśli serwery nie są połączone z Internetem, należy zainstalować na nich bramę Log Analytics.
Azure Government	Analiza zależności z wykorzystaniem agenta nie jest wspierana.

Następne kroki

Przygotuj się na odkrywanie serwerów uruchomionych w Hyper-V.