Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule przedstawiono podsumowanie wymagań wstępnych i wymagań dotyczących pomocy technicznej podczas oceniania serwerów fizycznych pod kątem migracji na platformę Azure przy użyciu narzędzia Azure Migrate: Odnajdywanie i ocena . Jeśli chcesz przeprowadzić migrację serwerów fizycznych na platformę Azure, zobacz macierz obsługi migracji.
Aby ocenić serwery fizyczne, należy utworzyć projekt i dodać narzędzie Azure Migrate: Odnajdywanie i ocena do projektu. Po dodaniu narzędzia należy wdrożyć aplikację Azure Migrate. Urządzenie stale odnajduje serwery lokalne i wysyła metadane serwerów i dane wydajności do platformy Azure. Po zakończeniu procesu odkrywania zbiera się zidentyfikowane serwery w grupy i przeprowadza ocenę dla grupy.
Ograniczenia
| Wsparcie | Szczegóły |
|---|---|
| Limity ocen | W jednym projekcie można odnajdywać i oceniać maksymalnie 35 000 serwerów fizycznych. |
| Limity projektów | W ramach subskrypcji platformy Azure można utworzyć wiele projektów. Oprócz serwerów fizycznych projekt może zawierać serwery na platformach VMware i Hyper-V, do ograniczeń oceny dla każdej z platform. |
| Odkrycie | Urządzenie usługi Azure Migrate może odnaleźć maksymalnie 1000 serwerów fizycznych. |
| Ocena | Do jednej grupy można dodać maksymalnie 35 000 serwerów. W ramach jednej oceny można ocenić maksymalnie 35 000 serwerów. |
Dowiedz się więcej o ocenach.
Wymagania dotyczące serwera fizycznego
Wdrożenie serwera fizycznego: Serwer fizyczny może być autonomiczny lub wdrożony w klastrze.
Typ serwerów: Serwery bez systemu operacyjnego, zwirtualizowane serwery działające lokalnie lub inne chmury, takie jak Amazon Web Services (AWS), Google Cloud Platform (GCP) i Xen.
Uwaga / Notatka
Obecnie usługa Azure Migrate nie obsługuje odnajdywania serwerów parawirtualizowanych.
System operacyjny: Wszystkie systemy operacyjne Windows i Linux można ocenić pod kątem migracji.
Ostrzeżenie
W tym artykule odwołuje się do wersji systemu Windows Server, które osiągnęły koniec wsparcia technicznego (EOS). Firma Microsoft oficjalnie zakończyła wsparcie dla następujących systemów operacyjnych:
- Windows Server 2003
- Windows Server 2008 (w tym SP2 i R2 z dodatkiem SP1)
- Windows Server 2012
- W rezultacie system Windows Server 2012 R2 usługa Azure Migrate nie gwarantuje spójnych ani niezawodnych wyników dla tych wersji systemu operacyjnego. Klienci mogą napotkać problemy i zdecydowanie zaleca się uaktualnienie do obsługiwanej wersji systemu Windows Server przed rozpoczęciem migracji.
Wymagania urządzenia usługi Azure Migrate
Usługa Azure Migrate używa urządzenia usługi Azure Migrate do odnajdywania i oceny. Urządzenie dla serwerów fizycznych może działać na maszynie wirtualnej lub serwerze fizycznym.
- Dowiedz się więcej o wymaganiach dotyczących urządzeń dla serwerów fizycznych.
- 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 programu PowerShell pobranego z witryny Azure Portal, aby skonfigurować urządzenie.
- Użyj tego skryptu , aby wdrożyć urządzenie w usłudze 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 umożliwiają zdalny dostęp do aplikacji zarządzającej urządzeniem za pomocą adresu URL https://<appliance-ip-or-name>:44368.Połączenia wychodzące na porty 443 (HTTPS) w celu wysyłania metadanych dotyczących odnajdywania i wydajności do usług Azure Migrate i Modernize. |
| Serwery fizyczne |
Windows: połączenia przychodzące na porcie WinRM 5986 (HTTPS) są używane do ściągania metadanych konfiguracji i wydajności z serwerów z systemem Windows. Jeśli wymagania wstępne protokołu HTTPS nie są skonfigurowane na serwerach docelowych Hyper-V, komunikacja urządzenia powróci do portu 5985 usługi WinRM (HTTP). Aby wymusić komunikację HTTPS bez możliwości powrotu do innych protokołów, przełącz Appliance Config Manager. Po włączeniu upewnij się, że wymagania wstępne zostały skonfigurowane na serwerach docelowych. — Jeśli certyfikaty nie są skonfigurowane na serwerach docelowych, odnajdywanie zakończy się niepowodzeniem zarówno na aktualnie odnalezionych serwerach, jak i na nowo dodanych serwerach. — Protokół HTTPS usługi WinRM wymaga certyfikatu uwierzytelniania serwera lokalnego z nazwą pospolitą (CN) zgodną z nazwą hosta. Certyfikat nie może być wygasły, odwołany ani z podpisem własnym. Zapoznaj się z artykułem dotyczącym konfigurowania usługi WinRM dla protokołu HTTPS. — Linux: połączenia przychodzące na porcie 22 (TCP) w celu ściągnięcia metadanych konfiguracji i wydajności z serwerów z systemem Linux. |
Wymagania dotyczące inwentaryzacji oprogramowania
Oprócz wykrywania serwerów, Azure Migrate: Discovery and Assessment może przeprowadzać inwentaryzację oprogramowania na serwerach. Inwentaryzacja oprogramowania udostępnia listę aplikacji, ról oraz funkcji działających na serwerach Windows i Linux, które zostały wykryte za pomocą 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 1000 serwerach odnalezionych na każdym urządzeniu usługi Azure Migrate. |
| Systemy operacyjne | Obsługiwane są serwery z systemami Windows i Linux, które spełniają wymagania serwera i mają wymagane uprawnienia dostępu. |
| Wymagania serwera | Na serwerach z systemem Windows musi być włączone zdalne zarządzanie PowerShell i zainstalowany program PowerShell w wersji 2.0 lub nowszej. Usługa WMI musi być włączona i dostępna na serwerach z systemem Windows, aby zebrać szczegółowe informacje o rolach i funkcjach zainstalowanych na serwerach. Serwery z systemem Linux muszą mieć włączoną łączność SSH i upewnić się, że na serwerach z systemem Linux można wykonywać 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 używanego typu menedżera pakietów oto kilka innych poleceń: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| Dostęp do serwera z systemem Windows | Konto użytkownika-gościa dla serwerów z systemem Windows. |
| Dostęp do serwera Linux | Konto użytkownika standardowego (dostęp inny niż sudo) dla wszystkich serwerów z systemem Linux. |
| Dostęp do portów | Serwery z systemem Windows wymagają dostępu na porcie 5985 (HTTP). Serwery z systemem Linux wymagają dostępu na porcie 22 (TCP). |
| Odkrycie | 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 inwentarzu oprogramowania z serwerów Windows za pomocą zdalnego dostępu PowerShell oraz z serwerów Linux poprzez połączenie SSH. Inwentaryzacja oprogramowania nie wymaga agenta. Na serwerach nie zainstalowano żadnego agenta. |
Wymagania dotyczące wykrywania instancji i baz danych SQL Server
Spis oprogramowania identyfikuje wystąpienia programu SQL Server. Urządzenie próbuje nawiązać połączenie z odpowiednimi instancjami SQL Server, korzystając z uwierzytelniania systemu Windows lub poświadczeń uwierzytelniania SQL Server, które zostały podane w menedżerze konfiguracji urządzenia, korzystając z tych informacji. Urządzenie może łączyć się tylko z instancjami SQL Server, które są w zasięgu jego sieciowego pola widzenia. Inwentaryzacja oprogramowania sama w sobie może nie wymagać widoczności w sieci.
Po podłączeniu urządzenia zbiera ono dane konfiguracyjne i wydajnościowe dla instancji i baz danych SQL Server. Urządzenie aktualizuje dane konfiguracyjne serwera SQL raz na 24 godziny i rejestruje dane dotyczące wydajności co 30 sekund.
| Wsparcie | Szczegóły |
|---|---|
| Obsługiwane serwery | Obsługiwane tylko w przypadku serwerów z uruchomionym programem SQL Server w środowiskach VMware, Microsoft Hyper-V, środowiskach fizycznych/bare-metal oraz serwerach infrastruktury jako usługi (IaaS) innych chmur publicznych, takich jak AWS i GCP. Z jednego urządzenia można odnaleźć maksymalnie 750 wystąpień programu SQL Server lub 15 000 baz danych SQL. Zalecamy upewnienie się, że urządzenie jest skonfigurowane do wykrywania mniej niż 600 serwerów uruchamiających SQL, aby uniknąć problemów z skalowaniem. |
| serwery Windows | Obsługiwane są systemy Windows Server 2008 i nowsze. |
| Linux serwery | Obecnie nie obsługiwane. |
| mechanizm uwierzytelniania | Obsługiwane jest zarówno uwierzytelnianie Windows, jak i SQL Server. Możesz podać dane uwierzytelniające obu typów uwierzytelnienia w menedżerze konfiguracji urządzenia. |
| Dostęp do programu SQL Server | Aby odnajdywać wystąpienia i bazy danych programu SQL Server, konto domeny systemu Windows/ lub konto programu SQL Server wymaga tych uprawnień odczytu o niskich uprawnieniach dla każdego wystąpienia programu 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 programu SQL Server | Obsługiwane są programy SQL Server 2008 i nowsze. |
| Wersje programu SQL Server | 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 baz danych SQL Server. Odnajdywanie usług SQL Server Reporting Services, SQL Server Integration Services i SQL Server Analysis Services nie jest obsługiwane. |
Uwaga / Notatka
Domyślnie usługa Azure Migrate używa najbezpieczniejszego sposobu nawiązywania połączenia z wystąpieniami SQL. To znaczy, Azure Migrate i Modernize szyfrują komunikację między urządzeniem Azure Migrate a źródłowymi instancjami SQL Server poprzez ustawienie właściwości TrustServerCertificate na 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 programu SQL Server na urządzeniu. Dowiedz się więcej , aby dowiedzieć się, co wybrać.
Skonfiguruj niestandardowe logowanie dla odkrywania serwera SQL
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 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 programu 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
Wymagania dotyczące odnajdywania aplikacji internetowych
Spis oprogramowania identyfikuje rolę serwera internetowego, która istnieje na odnalezionych serwerach. Jeśli na serwerze zostanie wykryty zainstalowany serwer WWW, Azure Migrate and Modernize odkrywa aplikacje internetowe na serwerze.
Możesz dodać zarówno poświadczenia domenowe, jak i niedomenowe na urządzeniu. Upewnij się, że używane konto ma uprawnienia administratora lokalnego na serwerach źródłowych. Usługa Azure Migrate and Modernize automatycznie mapuje poświadczenia na odpowiednie serwery, więc nie trzeba ich mapować ręcznie. Co najważniejsze, te poświadczenia nigdy nie są wysyłane do Microsoftu i pozostają na urządzeniu działającym w środowisku źródłowym.
Po podłączeniu urządzenia zbiera ono dane konfiguracyjne dla aplikacji webowych ASP.NET (serwer IIS) oraz aplikacji webowych Java (serwery Tomcat). Dane konfiguracyjne aplikacji webowych są aktualizowane raz na 24 godziny.
| Wsparcie | Aplikacje internetowe platformy ASP.NET | Aplikacje internetowe Java |
|---|---|---|
| Stos | VMware, Hyper-V i serwery fizyczne. | VMware, Hyper-V i serwery fizyczne. |
| serwery Windows | Obsługiwane są systemy Windows Server 2008 R2 i nowsze. | Niewspierane. |
| Linux serwery | Niewspierane. | Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 i Red Hat Enterprise Linux 5/6/7. |
| Wersje serwera WWW | IIS 7.5 i nowsze. | Tomcat 8 lub nowszy. |
| 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. | Uprawnienia odczytu (r) i wykonywania (x) rekurencyjnie we wszystkich katalogach CATALINA_HOME. |
Uwaga / Notatka
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. Możesz łatwo zobrazować zależności za pomocą widoku mapy w projekcie Azure Migrate. Zależności można używać do grupowania powiązanych serwerów na potrzeby migracji na platformę 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 użycia agenta na maksymalnie 1000 odnalezionych serwerów na urządzenie. |
| Systemy operacyjne | Obsługiwane są serwery z systemami Windows i Linux, które spełniają wymagania serwera i mają wymagane uprawnienia dostępu. |
| Wymagania serwera | Na serwerach z systemem Windows musi być włączone zdalne zarządzanie PowerShell i zainstalowany program PowerShell w wersji 2.0 lub nowszej. 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 z systemem Windows | Konto użytkownika (lokalne lub domenowe) z uprawnieniami administratora na serwerach. |
| Dostęp do serwera Linux | Zapoznaj się z tym linkiem , aby uzyskać dostęp do serwera z systemem Linux. |
| Dostęp do portów | Serwery z systemem Windows wymagają dostępu na porcie 5985 (HTTP). Serwery z systemem Linux wymagają dostępu na porcie 22 (TCP). |
| Metoda odkrycia | 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 z serwerów z systemem Windows, korzystając z zdalnej komunikacji programu PowerShell, oraz z serwerów 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 zależności ułatwia identyfikowanie zależności między serwerami lokalnymi, które chcesz ocenić i przeprowadzić migrację na platformę Azure. Poniższa tabela podsumowuje wymagania dotyczące konfiguracji analizy zależności opartej na agentach. Obecnie tylko analiza zależności oparta na agencie jest obsługiwana w przypadku serwerów fizycznych.
| Wymaganie | Szczegóły |
|---|---|
| Przed wdrożeniem | Powinieneś mieć gotowy projekt, w którym do projektu dodano narzędzie Azure Migrate: Discovery and assessment tool. Po skonfigurowaniu urządzenia Azure Migrate w celu odkrycia swoich lokalnych serwerów, wdrażasz wizualizację zależności. Dowiedz się, jak utworzyć projekt po raz pierwszy. Dowiedz się, jak dodać narzędzie do oceny do istniejącego projektu. Dowiedz się, jak skonfigurować aparat Azure Migrate do oceny Hyper-V, VMware lub serwerów fizycznych. |
| Azure Government | Wizualizacja zależności nie jest dostępna w usłudze Azure Government. |
| Analiza dzienników | Azure Migrate and Modernize korzysta z rozwiązania Service Map w dziennikach Azure Monitor do wizualizacji zależności. Łączysz nowe lub istniejące miejsce pracy Log Analytics z projektem. Nie możesz modyfikować przestrzeni roboczej dla projektu po jej dodaniu. 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. Przestrzenie robocze w innych regionach nie mogą być powiązane 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 usługi Log Analytics. W usłudze Log Analytics obszar roboczy skojarzony z usługą Azure Migrate i Modernizacja jest oznaczony kluczem projektu migracji i nazwą projektu. |
| Wymagane agenty | Na każdym serwerze, który chcesz przeanalizować, zainstaluj następujące agenty. - Microsoft Monitoring Agent (MMA) - Agent obsługujący zależności Jeśli serwery lokalne nie są połączone z Internetem, należy pobrać i zainstalować na nich bramę usługi 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 obsługuje obszary robocze znajdujące się w regionach Wschodnie USA, Azja Południowo-Wschodnia i Europa Zachodnia. 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 usługi Log Analytics. Nie możesz modyfikować przestrzeni roboczej dla projektu po jej dodaniu. |
| Koszty | Rozwiązanie Service Map nie wiąże się z żadnymi opłatami przez pierwsze 180 dni. Liczba rozpoczyna się od dnia skojarzenia obszaru roboczego usługi Log Analytics z projektem. Po 180 dniach obowiązują standardowe opłaty za Log Analytics. Korzystanie z dowolnego rozwiązania innego niż mapa usługi w skojarzonym obszarze roboczym usługi Log Analytics powoduje naliczanie standardowych opłat za usługę Log Analytics. Gdy projekt zostanie usunięty, przestrzeń robocza nie jest automatycznie usuwana. 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 usługi Log Analytics. Jeśli masz projekty utworzone przed ogólną dostępnością Azure Migrate (GA w dniu 28 lutego 2018), mogą wystąpić dodatkowe opłaty za Service Map. Aby upewnić się, że opłaty zostaną naliczone dopiero po 180 dniach, zalecamy utworzenie nowego projektu. Przestrzenie robocze utworzone przed GA są nadal płatne. |
| Zarządzanie | Podczas rejestrowania agentów w przestrzeni roboczej użyj identyfikatora i klucza udostępnionych przez projekt. Możesz użyć obszaru roboczego usługi Log Analytics poza Azure Migrate i Modernize. Jeśli usuniesz powiązany projekt, przestrzeń robocza nie zostanie usunięta automatycznie. Usuń ją ręcznie. Nie usuwaj przestrzeni roboczej utworzonej przez Azure Migrate and Modernize, chyba że usuwasz projekt. Jeśli to zrobisz, funkcja wizualizacji zależności nie działa zgodnie z oczekiwaniami. |
| Łączność z Internetem | Jeśli serwery nie są podłączone do internetu, zainstaluj bramkę Log Analytics na serwerach. |
| Azure Government | Analiza zależności z wykorzystaniem agenta nie jest wspierana. |
Dalsze kroki
Przygotuj się do odnajdywania serwerów fizycznych.