Migracja i modernizacja: typowe pytania

  • Artykuł

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i planowanie. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące narzędzia migracji i modernizacji. Jeśli masz inne pytania, sprawdź następujące zasoby:

Pytania ogólne

Jakie są opcje migracji w temacie Migracja i modernizacja?

Narzędzie migracji i modernizacji oferuje dwie opcje migracji serwerów źródłowych i maszyn wirtualnych na platformę Azure: migracja bez agenta i migracja oparta na agentach.

Niezależnie od wybranej opcji migracji pierwszym krokiem migracji serwera przy użyciu narzędzia Migracja i modernizacja jest rozpoczęcie replikacji serwera. Wykonuje to początkową replikację danych maszyny wirtualnej/serwera na platformę Azure. Po zakończeniu replikacji początkowej jest ustanawiana ciągła replikacja (ciągła synchronizacja różnicowa) w celu migracji danych przyrostowych na platformę Azure. Po osiągnięciu etapu synchronizacji różnicowej można w dowolnym momencie przeprowadzić migrację na platformę Azure.

Poniżej przedstawiono kilka zagadnień, które należy wziąć pod uwagę podczas podejmowania decyzji o opcji migracji.

Migracje bez agentów nie wymagają wdrożenia oprogramowania (agentów) na źródłowych maszynach wirtualnych/serwerach, które są migrowane. Opcja bez agenta organizuje replikację przez integrację z funkcjami udostępnianymi przez dostawcę wirtualizacji. Opcje replikacji bez agenta są dostępne dla maszyn wirtualnych VMware i maszyn wirtualnych funkcji Hyper-V.

Migracje oparte na agentach wymagają zainstalowania oprogramowania (agentów) usługi Azure Migrate na źródłowych maszynach wirtualnych/maszynach do migracji. Opcja oparta na agencie nie opiera się na platformie wirtualizacji dla funkcji replikacji. W związku z tym może być używany z dowolnym serwerem z architekturą x86/x64 i wersją systemu operacyjnego obsługiwaną przez metodę replikacji opartej na agencie.

Opcja migracji opartej na agencie może być używana dla maszyn wirtualnych VMware, maszyn wirtualnych funkcji Hyper-V, serwerów fizycznych, maszyn wirtualnych działających na platformie AWS, maszyn wirtualnych uruchomionych na platformie GCP lub maszynach wirtualnych działających u innego dostawcy wirtualizacji. Migracja oparta na agencie traktuje maszyny jako serwery fizyczne do migracji.

Chociaż migracja bez agenta oferuje inną wygodę i prostotę opcji replikacji opartej na agentach dla obsługiwanych scenariuszy (VMware i Hyper-V), warto rozważyć użycie scenariusza opartego na agencie w następujących przypadkach użycia:

  • Środowisko ograniczone liczby operacji we/wy na sekundę: replikacja bez agenta używa migawek i używa liczby operacji we/wy na sekundę magazynu/przepustowości. Zalecamy metodę migracji opartej na agencie, jeśli istnieją ograniczenia dotyczące magazynu/liczby operacji we/wy na sekundę w danym środowisku.
  • Jeśli nie masz programu vCenter Server, możesz traktować maszyny wirtualne VMware jako serwery fizyczne i korzystać z przepływu pracy migracji opartego na agencie.

Aby dowiedzieć się więcej, zapoznaj się z tym artykułem , aby porównać opcje migracji oprogramowania VMware.

Jakie lokalizacje geograficzne są obsługiwane na potrzeby migracji za pomocą usługi Azure Migrate?

Przejrzyj obsługiwane lokalizacje geograficzne chmur publicznych i chmur dla instytucji rządowych.

Czy mogę użyć tego samego projektu usługi Azure Migrate, aby przeprowadzić migrację do wielu regionów?

Chociaż można tworzyć oceny dla wielu regionów w projekcie usługi Azure Migrate, jeden projekt usługi Azure Migrate może służyć do migrowania serwerów tylko do jednego regionu świadczenia usługi Azure. Możesz utworzyć dodatkowe projekty usługi Azure Migrate dla każdego regionu, do którego chcesz przeprowadzić migrację.

  • W przypadku migracji bez agenta VMware region docelowy jest blokowany po włączeniu pierwszej replikacji.
  • W przypadku migracji opartych na agentach (VMware, serwerów fizycznych i serwerów z innych chmur) region docelowy jest zablokowany po wybraniu przycisku "Utwórz zasoby" w portalu podczas konfigurowania urządzenia replikacji.
  • W przypadku migracji bez agenta funkcji Hyper-V region docelowy jest zablokowany po wybraniu przycisku "Utwórz zasoby" w portalu podczas konfigurowania dostawcy replikacji funkcji Hyper-V.

Czy mogę użyć tego samego projektu usługi Azure Migrate do migracji do wielu subskrypcji?

Tak, możesz przeprowadzić migrację do wielu subskrypcji (tej samej dzierżawy platformy Azure) w tym samym regionie docelowym dla projektu usługi Azure Migrate. Możesz wybrać subskrypcję docelową podczas włączania replikacji dla maszyny lub zestawu maszyn. Region docelowy jest zablokowany po pierwszej replikacji na potrzeby migracji bez agenta VMware oraz podczas instalacji urządzenia replikacji i dostawcy funkcji Hyper-V na potrzeby migracji opartych na agencie i migracji bez agenta funkcji Hyper-V odpowiednio.

W jaki sposób dane są przesyłane ze środowiska lokalnego na platformę Azure? Czy jest szyfrowany przed transmisją?

Urządzenie usługi Azure Migrate w przypadku replikacji bez agenta kompresuje dane i szyfruje przed przekazaniem. Dane są przesyłane za pośrednictwem bezpiecznego kanału komunikacyjnego za pośrednictwem protokołu HTTPS i używają protokołu TLS 1.2 lub nowszego. Ponadto usługa Azure Storage automatycznie szyfruje dane, gdy są utrwalane w chmurze (szyfrowanie magazynowane).

Czy mogę użyć magazynu usługi Recovery Services utworzonego przez usługę Azure Migrate na potrzeby scenariuszy odzyskiwania po awarii?

Nie zalecamy używania magazynu usługi Recovery Services utworzonego przez usługę Azure Migrate dla scenariuszy odzyskiwania po awarii. Może to spowodować błędy uruchamiania replikacji w usłudze Azure Migrate.

Jaka jest różnica między operacjami migracji testowej i migracji?

Migracja testowa umożliwia testowanie i weryfikowanie migracji przed rzeczywistą migracją. Migracja testowa działa, umożliwiając testowanie maszyn wirtualnych przed rzeczywistą migracją przy użyciu środowiska piaskownicy na platformie Azure. Środowisko piaskownicy jest oddzielone od określonej testowej sieci wirtualnej. Operacja migracji testowej nie jest zakłócająca, pod warunkiem, że testowa sieć wirtualna jest wystarczająco odizolowana. W tym miejscu izolowana sieć wirtualna oznacza, że reguły połączeń przychodzących i wychodzących zostały zaprojektowane w celu uniknięcia niechcianych połączeń. Na przykład — połączenie z maszynami lokalnymi jest ograniczone.

Aplikacje mogą nadal działać w źródle, umożliwiając wykonywanie testów na sklonowanej kopii w izolowanym środowisku piaskownicy. W razie potrzeby można przeprowadzić wiele testów, aby zweryfikować migrację, przeprowadzić testowanie aplikacji i rozwiązać wszelkie problemy przed rzeczywistą migracją.

Zrzut ekranu przedstawia różnicę w migracji testowej i rzeczywistej migracji.

Czy istnieje opcja wycofywania dla usługi Azure Migrate?

Możesz użyć opcji Migracja testowa, aby zweryfikować funkcjonalność i wydajność aplikacji na platformie Azure. Można wykonać dowolną liczbę migracji testowych i wykonać ostateczną migrację po ustanowieniu zaufania za pomocą operacji migracji testowej. Migracja testowa nie ma wpływu na maszynę lokalną, która pozostaje operacyjna i kontynuuje replikację do momentu przeprowadzenia rzeczywistej migracji. Jeśli podczas migracji testowej UAT wystąpiły jakiekolwiek błędy, możesz odroczyć ostateczną migrację i zachować uruchomioną źródłową maszynę wirtualną/serwer oraz replikować je na platformę Azure. Po usunięciu błędów można ponownie przeprowadzić ostateczną migrację. Uwaga: po zakończeniu migracji na platformę Azure i zamknięciu lokalnej maszyny źródłowej nie można wykonać wycofania z platformy Azure do środowiska lokalnego.

Czy mogę wybrać sieć wirtualną i podsieć do użycia na potrzeby migracji testowych?

Możesz wybrać sieć wirtualną na potrzeby migracji testowych. Podsieć jest wybierana automatycznie na podstawie następującej logiki:

  • Jeśli podsieć docelowa (inna niż domyślna) została określona jako dane wejściowe podczas włączania replikacji, usługa Azure Migrate określa priorytety przy użyciu podsieci o tej samej nazwie w sieci wirtualnej wybranej do migracji testowej.
  • Jeśli podsieć o tej samej nazwie nie zostanie znaleziona, usługa Azure Migrate wybierze pierwszą podsieć dostępną alfabetycznie, która nie jest podsiecią Gateway/Application Gateway/Firewall/Bastion.

Dlaczego przycisk Migracja testu jest wyłączony dla mojego serwera?

Przycisk migracji testowej może być w stanie wyłączonym w następujących scenariuszach:

  • Nie można rozpocząć migracji testowej, dopóki replikacja początkowa (IR) nie zostanie ukończona dla maszyny wirtualnej. Przycisk migracji testowej zostanie wyłączony do momentu ukończenia procesu ir. Migrację testową można wykonać, gdy maszyna wirtualna znajduje się na etapie synchronizacji różnicowej.
  • Przycisk można wyłączyć, jeśli migracja testowa została już ukończona, ale nie wykonano czyszczenia migracji testowej dla tej maszyny wirtualnej. Przeprowadź czyszczenie migracji testowej i ponów próbę wykonania operacji.

Co się stanie, jeśli nie wyczyścim migracji testowej?

Migracja testowa symuluje rzeczywistą migrację, tworząc testową maszynę wirtualną platformy Azure przy użyciu replikowanych danych. Serwer zostanie wdrożony z kopią replikowanych danych do docelowej grupy zasobów (wybranej podczas włączania replikacji) z sufiksem "-test". Migracje testowe są przeznaczone do sprawdzania poprawności funkcjonalności serwera, aby zminimalizować problemy po migracji. Jeśli migracja testowa nie zostanie wyczyszczona po przetestowaniu, testowa maszyna wirtualna będzie nadal działać na platformie Azure i będzie naliczać opłaty. Aby wyczyścić po migracji testowej, przejdź do widoku replikowania maszyn w narzędziu Migracja i modernizacja, a następnie użyj akcji "wyczyść migrację testową" na maszynie.

Jak mogę wiedzieć, czy moja maszyna wirtualna została pomyślnie zmigrowana?

Po pomyślnym przeprowadzeniu migracji maszyny wirtualnej/serwera możesz wyświetlić maszynę wirtualną i zarządzać nią na stronie Maszyny wirtualne. Połączenie do zmigrowanej maszyny wirtualnej w celu zweryfikowania. Alternatywnie możesz przejrzeć stan zadania dla operacji, aby sprawdzić, czy migracja została pomyślnie ukończona. Jeśli widzisz jakiekolwiek błędy, rozwiąż je i spróbuj ponownie wykonać operację migracji.

Co się stanie, jeśli nie zatrzymam replikacji po migracji?

Po zatrzymaniu replikacji narzędzie Migracja i modernizacja czyści dyski zarządzane w subskrypcji utworzonej na potrzeby replikacji.

Co się stanie, jeśli nie ukończym migracji po migracji?

Po zakończeniu migracji narzędzie Migracja i modernizacja czyści dyski zarządzane w subskrypcji utworzonej na potrzeby replikacji. Jeśli nie wybierzesz opcji Zakończ migrację po migracji , nadal będą naliczane opłaty za te dyski. Migracja ukończona nie wpłynie na dyski dołączone do maszyn, które zostały już zmigrowane.

Jak mogę migrować maszyny oparte na interfejsie UEFI na platformę Azure jako maszyny wirtualne generacji 1 platformy Azure?

Narzędzie do migracji i modernizacji migruje maszyny oparte na interfejsie UEFI na platformę Azure jako maszyny wirtualne generacji 2 platformy Azure. Jeśli chcesz przeprowadzić migrację do maszyn wirtualnych generacji 1 platformy Azure, przekonwertuj typ rozruchu na system BIOS przed rozpoczęciem replikacji, a następnie użyj narzędzia migracji i modernizacji, aby przeprowadzić migrację na platformę Azure.

Czy usługa Azure Migrate konwertuje maszyny oparte na interfejsie UEFI na maszyny oparte na systemie BIOS i migruje je na platformę Azure jako maszyny wirtualne generacji 1 platformy Azure?

Narzędzie do migracji i modernizacji migruje wszystkie maszyny oparte na interfejsie UEFI na platformę Azure jako maszyny wirtualne 2. generacji platformy Azure. Nie obsługujemy już konwersji maszyn wirtualnych opartych na interfejsie UEFI na maszyny wirtualne oparte na systemie BIOS. Wszystkie maszyny oparte na systemie BIOS są migrowane na platformę Azure jako tylko maszyny wirtualne generacji 1 platformy Azure.

Które systemy operacyjne są obsługiwane w przypadku migracji maszyn opartych na interfejsie UEFI na platformę Azure?

Systemy operacyjne obsługiwane dla maszyn opartych na interfejsie UEFI Bez agenta VMware na platformę Azure Bez agenta funkcji Hyper-V na platformę Azure Oparte na agencie oprogramowanie VMware, fizyczne i inne chmury na platformie Azure
Windows Server 2019, 2016, 2012 R2, 2012 Y Y Y
Windows 10 Pro, Windows 10 Enterprise Y Y Y
SUSE Linux Enterprise Server 15 SP1 Y Y Y
SUSE Linux Enterprise Server 12 SP4 Y Y Y
Ubuntu Server 16.04, 18.04, 19.04, 19.10 Y Y Y
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x Y Y Y
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x Y Y Y
Oracle Linux 7.7, 7.7-CI Y Y Y

Czy mogę przeprowadzić migrację kontrolerów domeny usługi Active Directory przy użyciu usługi Azure Migrate?

Narzędzie migracji i modernizacji jest niezależne od aplikacji i działa w przypadku większości aplikacji. Podczas migracji serwera przy użyciu narzędzia migracji i modernizacji wszystkie aplikacje zainstalowane na serwerze są migrowane wraz z nim. Jednak w przypadku niektórych aplikacji alternatywne metody migracji inne niż Migracja i modernizacja mogą być lepiej dostosowane do migracji. W przypadku usługi Active Directory, jeśli środowiska hybrydowe, w których lokacja lokalna jest połączona ze środowiskiem platformy Azure, możesz rozszerzyć katalog na platformę Azure, dodając dodatkowe kontrolery domeny na platformie Azure i konfigurując replikację usługi Active Directory. W przypadku migracji do izolowanego środowiska na platformie Azure wymagającego własnych kontrolerów domeny (lub testowania aplikacji w środowisku piaskownicy) można migrować serwery przy użyciu narzędzia Migracja i modernizacja.

Czy mogę uaktualnić system operacyjny podczas migracji?

Narzędzie migracji i modernizacji obsługuje obecnie tylko migracje podobne do podobnych. Narzędzie nie obsługuje uaktualniania wersji systemu operacyjnego podczas migracji. Zmigrowana maszyna będzie mieć ten sam system operacyjny co maszyna źródłowa.

Czy potrzebuję programu VMware vCenter, aby przeprowadzić migrację maszyn wirtualnych VMware?

Aby przeprowadzić migrację maszyn wirtualnych VMware przy użyciu migracji opartej na agencie VMware lub bez agenta, hosty ESXi, na których znajdują się maszyny wirtualne, muszą być zarządzane przez program vCenter Server. Jeśli nie masz programu vCenter Server, możesz migrować maszyny wirtualne VMware, migrując je jako serwery fizyczne. Dowiedz się więcej.

Czy mogę skonsolidować wiele źródłowych maszyn wirtualnych na jednej maszynie wirtualnej podczas migracji?

Obecnie funkcje migracji i modernizacji obsługują migracje podobne do podobnych. Nie obsługujemy konsolidowania serwerów ani uaktualniania systemu operacyjnego w ramach migracji.

Czy systemy Windows Server 2008 i 2008 R2 będą obsługiwane na platformie Azure po migracji?

Możesz przeprowadzić migrację lokalnych serwerów z systemem Windows Server 2008 i 2008 R2 do maszyn wirtualnych platformy Azure i uzyskać rozszerzone Aktualizacje zabezpieczeń przez trzy lata po dacie zakończenia pomocy technicznej bez dodatkowych opłat powyżej kosztu działania maszyny wirtualnej. Narzędzie migracji i modernizacji umożliwia migrowanie obciążeń systemów Windows Server 2008 i 2008 R2.

Jak mogę przeprowadzić migrację systemu Windows Server 2003 działającego na platformie VMware/Hyper-V na platformę Azure?

Rozszerzona pomoc techniczna dla systemu Windows Server 2003 zakończyła się 14 lipca 2015 r. Zespół pomoc techniczna platformy Azure nadal pomaga w rozwiązywaniu problemów, które dotyczą systemu Windows Server 2003 na platformie Azure. Jednak ta obsługa jest ograniczona do problemów, które nie wymagają rozwiązywania problemów na poziomie systemu operacyjnego ani poprawek. Migrowanie aplikacji do wystąpień platformy Azure z nowszą wersją systemu Windows Server jest zalecanym podejściem w celu zapewnienia efektywnego korzystania z elastyczności i niezawodności chmury platformy Azure.

Jeśli jednak nadal zdecydujesz się przeprowadzić migrację systemu Windows Server 2003 na platformę Azure, możesz użyć narzędzia migracji i modernizacji, jeśli system Windows Server jest maszyną wirtualną działającą w programie VMware lub funkcji Hyper-V Zapoznaj się z tym artykułem, aby przygotować maszyny z systemem Windows Server 2003 do migracji.

Migracja bez agenta VMware

Jak działa migracja bez agenta?

Narzędzie migracji i modernizacji udostępnia opcje replikacji bez agenta na potrzeby migracji maszyn wirtualnych VMware i maszyn wirtualnych funkcji Hyper-V z systemem Windows lub Linux. Narzędzie udostępnia również inną opcję replikacji opartej na agencie dla serwerów z systemami Windows i Linux, które mogą służyć do migrowania serwerów fizycznych oraz maszyn wirtualnych x86/x64 na maszynach VMware, Hyper-V, AWS, GCP itp. Opcja replikacji opartej na agencie wymaga instalacji oprogramowania agenta na serwerze/maszynie wirtualnej, która jest migrowana, natomiast w opcji bez agenta nie trzeba instalować oprogramowania na samych maszynach wirtualnych, co zapewnia wygodę i prostotę opcji replikacji opartej na agencie.

Opcja replikacji bez agenta działa przy użyciu mechanizmów udostępnianych przez dostawcę wirtualizacji (VMware, Hyper-V). W przypadku maszyn wirtualnych VMware mechanizm replikacji bez agenta używa migawek VMware i technologii śledzenia zmienionych bloków VMware w celu replikowania danych z dysków maszyny wirtualnej. Ten mechanizm jest podobny do tego, który jest używany przez wiele produktów kopii zapasowych. W przypadku maszyn wirtualnych funkcji Hyper-V mechanizm replikacji bez agenta używa migawek maszyn wirtualnych i możliwości śledzenia zmian repliki funkcji Hyper-V do replikowania danych z dysków maszyny wirtualnej.

Po skonfigurowaniu replikacji dla maszyny wirtualnej najpierw przechodzi fazę replikacji początkowej. Podczas replikacji początkowej wykonywana jest migawka maszyny wirtualnej, a pełna kopia danych z dysków migawki jest replikowana do dysków zarządzanych w ramach subskrypcji. Po zakończeniu replikacji początkowej maszyny wirtualnej proces replikacji przechodzi do fazy replikacji przyrostowej (replikacji różnicowej). W fazie replikacji przyrostowej zmiany danych, które wystąpiły od czasu ostatniego ukończonego cyklu replikacji, są okresowo replikowane i stosowane do dysków zarządzanych repliki, dzięki czemu replikacja jest zsynchronizowana ze zmianami dzieje się na maszynie wirtualnej. W przypadku maszyn wirtualnych VMware technologia śledzenia zmienionych bloków programu VMware służy do śledzenia zmian między cyklami replikacji. Na początku cyklu replikacji wykonywana jest migawka maszyny wirtualnej, a śledzenie zmienionych bloków służy do pobierania zmian między bieżącą migawką a ostatnią pomyślnie zreplikowanymi migawkami. W ten sposób należy replikować tylko dane, które uległy zmianie od ostatniego ukończonego cyklu replikacji, aby zachować synchronizację maszyny wirtualnej. Na końcu każdego cyklu replikacji jest zwalniana migawka, a konsolidacja migawek jest wykonywana dla maszyny wirtualnej. Podobnie w przypadku maszyn wirtualnych funkcji Hyper-V aparat śledzenia zmian repliki funkcji Hyper-V służy do śledzenia zmian między kolejnymi cyklami replikacji.

Po wykonaniu operacji migracji na replikowaniu maszyny wirtualnej możesz zamknąć lokalną maszynę wirtualną i wykonać jedną ostateczną replikację przyrostową w celu zapewnienia zerowej utraty danych. Podczas przeprowadzania migracji dyski zarządzane repliki odpowiadające maszynie wirtualnej są używane do tworzenia maszyny wirtualnej na platformie Azure.

Aby rozpocząć, zapoznaj się z samouczkami migracji bez agentów VMware i migracji bez agenta funkcji Hyper-V.

Jak mogę ocenić wymagania dotyczące przepustowości dla moich migracji?

Przepustowość replikacji danych na platformę Azure zależy od szeregu czynników i jest funkcją tego, jak szybko lokalne urządzenie usługi Azure Migrate może odczytywać i replikować dane na platformę Azure. Replikacja ma dwie fazy: replikację początkową i replikację różnicową.

Po uruchomieniu replikacji dla maszyny wirtualnej następuje cykl replikacji początkowej, w którym są replikowane pełne kopie dysków. Po zakończeniu replikacji początkowej cykle replikacji przyrostowej (cykle różnicowe) są okresowo planowane do transferu wszelkich zmian, które wystąpiły od poprzedniego cyklu replikacji.

Możesz wypracować wymaganie dotyczące przepustowości na podstawie ilości danych potrzebnych do przeniesienia w fali i czasu, w którym chcesz ukończyć replikację początkową (najlepiej, aby replikacja początkowa została ukończona co najmniej 3–4 dni przed rzeczywistym oknem migracji, aby zapewnić wystarczający czas na przeprowadzenie migracji testowej przed rzeczywistym oknem i zatrzymać przestój do minimum w oknie).

Możesz oszacować przepustowość lub czas potrzebny na migrację bez agenta maszyny wirtualnej VMware przy użyciu następującej formuły:

Czas ukończenia replikacji początkowej = {rozmiar dysków (lub używany rozmiar, jeśli jest dostępny) * 0,7 (przy założeniu 30 procent średniej kompresji — konserwatywne oszacowanie)}/przepustowość dostępna na potrzeby replikacji.

Jak mogę ograniczyć replikację przy użyciu urządzenia usługi Azure Migrate na potrzeby replikacji bez agenta VMware?

Ograniczanie można ograniczyć przy użyciu zasad NetQosPolicy. Należy pamiętać, że to ograniczenie ma zastosowanie tylko do połączeń wychodzących z urządzenia usługi Azure Migrate. Na przykład:

Prefiks AppName używany w elemecie NetQosPolicy to "GatewayWindowsService.exe". Możesz utworzyć zasady na urządzeniu usługi Azure Migrate w celu ograniczenia ruchu replikacji z urządzenia, tworząc zasady takie jak następujące:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Aby zwiększyć i zmniejszyć przepustowość replikacji na podstawie harmonogramu, możesz użyć zaplanowanego zadania systemu Windows, aby skalować przepustowość zgodnie z potrzebami. Jedno zadanie będzie używane do zmniejszenia przepustowości, a drugie zadanie zostanie użyte do zwiększenia przepustowości. Uwaga: przed wykonaniem poniższych poleceń należy utworzyć zasady NetQosPolicy opisane powyżej.

#Replace with an account part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) will be used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the Scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

Jak współczynnik zmian wpływa na replikację bez agenta?

Ponieważ replikacja bez agenta składa się w danych, wzorzec zmian jest ważniejszy niż współczynnik zmian. Gdy plik zostanie zapisany ponownie i ponownie, szybkość nie ma dużego wpływu. Jednak wzorzec, w którym każdy inny sektor jest zapisywany, powoduje wysoki współczynnik zmian w następnym cyklu. Ponieważ minimalizujemy ilość przesyłanych danych, pozwalamy na składanie danych możliwie jak najwięcej przed zaplanowanym następnym cyklem.

Jak często zaplanowano cykl replikacji?

Formuła do zaplanowana następnego cyklu replikacji to (poprzedni czas cyklu / 2) lub jedna godzina, w zależności od tego, która wartość jest wyższa.

Jeśli na przykład maszyna wirtualna zajmuje cztery godziny dla cyklu różnicowego, następny cykl jest zaplanowany w ciągu dwóch godzin, a nie w ciągu następnej godziny. Proces jest inny natychmiast po replikacji początkowej, gdy pierwszy cykl różnicowy jest zaplanowany natychmiast.

Wdrożono dwa (lub więcej) urządzeń w celu odnajdywania maszyn wirtualnych w programie vCenter Server. Jednak podczas próby migracji maszyn wirtualnych widzę tylko maszyny wirtualne odpowiadające jednemu z urządzeń.

Jeśli skonfigurowano wiele urządzeń, wymagane jest, aby maszyny wirtualne nie nakładały się na podane konta programu vCenter. Odnajdywanie z takim nakładaniem się jest nieobsługiwane.

Jak replikacja bez agenta wpływa na serwery VMware?

Replikacja bez agenta powoduje pewien wpływ na wydajność hostów VMware vCenter Server i VMware ESXi. Ponieważ replikacja bez agenta używa migawek, zużywa operacje we/wy na sekundę w magazynie, więc wymagana jest przepustowość magazynu we/wy na sekundę. Nie zalecamy używania replikacji bez agenta, jeśli masz ograniczenia dotyczące magazynu lub operacji we/wy w danym środowisku.

Czy mogę użyć usługi Azure Migrate do migrowania aplikacji internetowych do usługi aplikacja systemu Azure Service?

Migrację bez agentów na dużą skalę można wykonywać ASP.NET aplikacji internetowych działających na serwerach internetowych usług IIS hostowanych w systemie operacyjnym Windows w środowisku VMware. Dowiedz się więcej.

Migracja oparta na agencie

Jak mogę przeprowadzić migrację wystąpień usługi AWS EC2 na platformę Azure?

Zapoznaj się z artykułem , aby odnajdywać, oceniać i migrować wystąpienia usługi AWS EC2 na platformę Azure.

Jak działa migracja oparta na agencie?

Oprócz opcji migracji bez agenta dla maszyn wirtualnych VMware i maszyn wirtualnych funkcji Hyper-V narzędzie migracji i modernizacji zapewnia opcję migracji opartej na agencie do migrowania serwerów z systemem Windows i Linux działających na serwerach fizycznych lub działających jako maszyny wirtualne x86/x64 na maszynach wirtualnych VMware, Hyper-V, AWS, Google Cloud Platform itp.

Metoda migracji opartej na agencie używa oprogramowania agenta zainstalowanego na serwerze migrowanym w celu replikowania danych serwera na platformę Azure. Proces replikacji używa architektury odciążania, w której agent przekazuje dane replikacji do dedykowanego serwera replikacji o nazwie urządzenie replikacji lub serwer konfiguracji (lub do serwera przetwarzania skalowalnego w poziomie). Dowiedz się więcej o sposobie działania opcji migracji opartej na agencie.

Uwaga: urządzenie replikacji różni się od urządzenia odnajdywania usługi Azure Migrate i musi być zainstalowane na oddzielnej/dedykowanej maszynie.

Gdzie należy zainstalować urządzenie replikacji na potrzeby migracji opartych na agencie?

Urządzenie replikacji powinno być zainstalowane na dedykowanej maszynie. Urządzenie replikacji nie powinno być zainstalowane na maszynie źródłowej, która ma zostać zreplikowana lub na urządzeniu usługi Azure Migrate (używanym do odnajdywania i oceny), które mogło zostać zainstalowane wcześniej. Aby uzyskać więcej informacji, postępuj zgodnie z samouczkiem.

Czy mogę przeprowadzić migrację maszyn wirtualnych platformy AWS z systemem operacyjnym Amazon Linux?

Maszyny wirtualne z systemem Amazon Linux nie mogą być migrowane tak jak system operacyjny Amazon Linux jest obsługiwany tylko na platformie AWS. Aby przeprowadzić migrację obciążeń uruchomionych w systemie Amazon Linux, możesz uruchomić maszynę wirtualną CentOS/RHEL na platformie Azure i przeprowadzić migrację obciążenia uruchomionego na maszynie z systemem AWS Linux przy użyciu odpowiedniego podejścia do migracji obciążeń. Na przykład w zależności od obciążenia mogą istnieć narzędzia specyficzne dla obciążenia, które ułatwiają migrację — na przykład w przypadku baz danych lub narzędzi wdrażania w przypadku serwerów internetowych.

Jak mogę ocenić wymagania dotyczące przepustowości dla moich migracji?

Przepustowość replikacji danych na platformę Azure zależy od szeregu czynników i jest funkcją tego, jak szybko lokalne urządzenie usługi Azure Migrate może odczytywać i replikować dane na platformę Azure. Replikacja ma dwie fazy: replikację początkową i replikację różnicową.

Po uruchomieniu replikacji dla maszyny wirtualnej następuje cykl replikacji początkowej, w którym są replikowane pełne kopie dysków. Po zakończeniu replikacji początkowej cykle replikacji przyrostowej (cykle różnicowe) są okresowo planowane do transferu wszelkich zmian, które wystąpiły od poprzedniego cyklu replikacji.

W przypadku metody replikacji opartej na agencie planista wdrażania może pomóc w profilowaniu środowiska zmian danych i przewidywaniu niezbędnego wymagania dotyczącego przepustowości. Aby dowiedzieć się więcej, zobacz ten artykuł

Migracja bez agenta funkcji Hyper-V

Jak działa migracja bez agenta?

Narzędzie migracji i modernizacji udostępnia opcje replikacji bez agenta na potrzeby migracji maszyn wirtualnych VMware i maszyn wirtualnych funkcji Hyper-V z systemem Windows lub Linux. Narzędzie udostępnia również dodatkową opcję replikacji opartej na agencie dla serwerów z systemami Windows i Linux, które mogą służyć do migrowania serwerów fizycznych, a także maszyn wirtualnych x86/x64 na maszynach wirtualnych VMware, Hyper-V, AWS, GCP itp. Opcja replikacji opartej na agencie wymaga instalacji oprogramowania agenta na serwerze/maszynie wirtualnej, która jest migrowana, natomiast w opcji bez agenta nie trzeba instalować oprogramowania na samych maszynach wirtualnych, co zapewnia dodatkową wygodę i prostotę opcji replikacji opartej na agencie.

Opcja replikacji bez agenta działa przy użyciu mechanizmów udostępnianych przez dostawcę wirtualizacji (VMware, Hyper-V). W przypadku maszyn wirtualnych funkcji Hyper-V mechanizm replikacji bez agenta używa migawek maszyn wirtualnych i możliwości śledzenia zmian repliki funkcji Hyper-V do replikowania danych z dysków maszyny wirtualnej.

Po skonfigurowaniu replikacji dla maszyny wirtualnej najpierw przechodzi fazę replikacji początkowej. Podczas replikacji początkowej wykonywana jest migawka maszyny wirtualnej, a pełna kopia danych z dysków migawki jest replikowana do dysków zarządzanych w ramach subskrypcji. Po zakończeniu replikacji początkowej maszyny wirtualnej proces replikacji przechodzi do fazy replikacji przyrostowej (replikacji różnicowej). W fazie replikacji przyrostowej zmiany danych, które wystąpiły od czasu ostatniego ukończonego cyklu replikacji, są okresowo replikowane i stosowane do dysków zarządzanych repliki, dzięki czemu replikacja jest zsynchronizowana ze zmianami dzieje się na maszynie wirtualnej. W przypadku maszyn wirtualnych VMware technologia śledzenia zmienionych bloków programu VMware służy do śledzenia zmian między cyklami replikacji. Na początku cyklu replikacji wykonywana jest migawka maszyny wirtualnej, a śledzenie zmienionych bloków służy do pobierania zmian między bieżącą migawką a ostatnią pomyślnie zreplikowanymi migawkami. W ten sposób należy replikować tylko dane, które uległy zmianie od ostatniego ukończonego cyklu replikacji, aby zachować synchronizację maszyny wirtualnej. Na końcu każdego cyklu replikacji jest zwalniana migawka, a konsolidacja migawek jest wykonywana dla maszyny wirtualnej. Podobnie w przypadku maszyn wirtualnych funkcji Hyper-V aparat śledzenia zmian repliki funkcji Hyper-V służy do śledzenia zmian między kolejnymi cyklami replikacji.

Po wykonaniu operacji migracji na replikowaniu maszyny wirtualnej możesz zamknąć lokalną maszynę wirtualną i wykonać jedną ostateczną replikację przyrostową w celu zapewnienia zerowej utraty danych. Podczas przeprowadzania migracji dyski zarządzane repliki odpowiadające maszynie wirtualnej są używane do tworzenia maszyny wirtualnej na platformie Azure.

Aby rozpocząć, zapoznaj się z samouczkiem migracji bez agenta funkcji Hyper-V.

Jak mogę ocenić wymagania dotyczące przepustowości dla moich migracji?

Przepustowość replikacji danych na platformę Azure zależy od szeregu czynników i jest funkcją tego, jak szybko lokalne urządzenie usługi Azure Migrate może odczytywać i replikować dane na platformę Azure. Replikacja ma dwie fazy: replikację początkową i replikację różnicową.

Po uruchomieniu replikacji dla maszyny wirtualnej następuje cykl replikacji początkowej, w którym są replikowane pełne kopie dysków. Po zakończeniu replikacji początkowej cykle replikacji przyrostowej (cykle różnicowe) są okresowo planowane do transferu wszelkich zmian, które wystąpiły od poprzedniego cyklu replikacji.

Możesz wypracować wymaganie dotyczące przepustowości na podstawie ilości danych potrzebnych do przeniesienia w fali i czasu, w którym chcesz ukończyć replikację początkową (najlepiej, aby replikacja początkowa została ukończona co najmniej 3–4 dni przed rzeczywistym oknem migracji, aby zapewnić wystarczający czas na przeprowadzenie migracji testowej przed rzeczywistym oknem i zatrzymać przestój do minimum w oknie).

Następne kroki

Przeczytaj omówienie usługi Azure Migrate.