Udostępnij za pośrednictwem

Migrowanie aplikacji WebSphere do usługi Azure Virtual Machines

  • Artykuł

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej tradycyjnej aplikacji webSphere Application Server (WAS) do uruchamiania na maszynach wirtualnych platformy Azure. Aby zapoznać się z omówieniem dostępnych tradycyjnych rozwiązań WAS w witrynie Azure Marketplace, zobacz Co to są rozwiązania do uruchamiania rodziny produktów IBM WebSphere na platformie Azure?

Przed migracją

Aby zapewnić pomyślną migrację, przed rozpoczęciem wykonaj kroki oceny i spisu opisane w poniższych sekcjach.

Określenie punktu oznaczającego „ukończenie migracji”

Ten przewodnik i odpowiednie oferty witryny Azure Marketplace stanowią punkt wyjścia do przyspieszenia migracji tradycyjnych obciążeń WAS na platformę Azure. Ważne jest, aby zdefiniować zakres nakładów pracy w związku z migracją. Przykładowo, czy stosujesz rygorystyczną metodę migracji „lift and shift” z istniejącej infrastruktury do usługi Azure Virtual Machines? Jeśli tak, idea równoczesnego zastosowania metody „lift and improve” podczas migracji może być kusząca.

Lepiej jednak trzymać się ściśle planu opartego na metodzie „lift and shift”, uwzględniając niezbędne zmiany zgodnie z opisem zawartym w tym przewodniku. Zdefiniuj punkt kontrolny oznaczający „ukończenie migracji”, aby wiedzieć, kiedy zostanie osiągnięty. Po zakończeniu migracji możesz utworzyć migawkę maszyn wirtualnych zgodnie z opisem w temacie Tworzenie migawki wirtualnego dysku twardego. Po zweryfikowaniu, że możesz pomyślnie przywrócić migawkę, możesz wykonać ulepszenia bez obawy przed utratą postępów migracji osiągniętych do tej pory.

Upewnij się, że element docelowy jest odpowiednim celem dla nakładu pracy nad migracją

Pierwszym krokiem pomyślnej migracji aplikacji WAS na platformę Azure jest wybranie najbardziej odpowiedniego celu migracji.

Usługa WAS działa dobrze w usłudze Azure Virtual Machines. Obiekt docelowy maszyny wirtualnej jest najprostszym wyborem, ponieważ najbardziej przypomina wdrożenie lokalne. Środowisko administracyjne i wdrożenie maszyn wirtualnych jest podobne do środowiska lokalnego.

Inną opcją jest migracja do kontenerów przez przekonwertowanie tradycyjnego obciążenia WAS na kontenery aplikacji. Element docelowy kontenera można uruchomić w usługach Azure Kubernetes Service (AKS) i Azure Red Hat OpenShift. Kompromisem za tę łatwość jest koszt ekonomiczny.

Ogólnie rzecz biorąc, koszt za minutę rozwiązania opartego na maszynie wirtualnej jest wyższy w porównaniu z kontenerami. Chociaż rozwiązanie oparte na kontenerze kosztuje mniej do uruchomienia, należy ograniczyć aplikację, aby dopasować się do wymagań platformy orkiestracji kontenerów.

Jeśli minimalizacja zmian jest najważniejszym czynnikiem dla nakładu pracy nad migracją, rozważ migrację opartą na maszynie wirtualnej. W tym przypadku zobacz Migrowanie aplikacji WebSphere do usługi Azure Virtual Machines.

Jeśli możesz tolerować konwertowanie aplikacji do uruchamiania w kontenerach w celu zmniejszenia kosztów środowiska uruchomieniowego, rozważ migrację opartą na usłudze AKS lub migrację opartą na usłudze Azure Red Hat OpenShift.

W przypadku migracji opartej na usłudze AKS możesz rozpocząć korzystanie z warstwy Bezpłatna. Uzyskaj bezpłatne zarządzanie klastrem i zapłać tylko za używane maszyny wirtualne, skojarzony magazyn i zasoby sieciowe. W tym przypadku zobacz Migrowanie aplikacji WebSphere do usługi Azure Kubernetes Service.

W przypadku migracji opartej na platformie Azure Red Hat OpenShift oprócz kosztów obliczeń i infrastruktury węzły aplikacji mają kolejny koszt składnika licencji OpenShift. Ten koszt jest rozliczany na podstawie liczby węzłów aplikacji i typu wystąpienia. Użyj cen na żądanie lub wystąpień zarezerwowanych, w zależności od tego, co najlepiej spełnia potrzeby obciążenia i firmy. W tym przypadku zobacz Migrowanie aplikacji WebSphere do usługi Azure Red Hat OpenShift.

Przewodniki z instrukcjami w dokumentacji usługi Azure Red Hat OpenShift obejmują niektóre aspekty istotne dla migracji. Pełną listę przewodników z instrukcjami można znaleźć w dokumentacji usługi Azure Red Hat OpenShift.

Określanie, czy wstępnie utworzone oferty witryny Azure Marketplace są dobrym punktem wyjścia

Firma IBM i firma Microsoft nawiązali współpracowanie z zestawem szablonów rozwiązań platformy Azure w witrynie Azure Marketplace w celu zapewnienia solidnego punktu wyjścia do migracji na platformę Azure. Aby uzyskać listę ofert, zobacz Run the WebSphere family of products and Liberty on Microsoft Azure (Uruchamianie rodziny produktów WebSphere i Liberty na platformie Microsoft Azure), a następnie wybierz ten, który najlepiej pasuje do istniejącego wdrożenia. Listę ofert można znaleźć w artykule Omówienie Jakie są rozwiązania do uruchamiania rodziny produktów IBM WebSphere na platformie Azure?

Jeśli żadna z istniejących ofert nie jest dobrym punktem wyjścia, musisz odtworzyć wdrożenie ręcznie przy użyciu zasobów maszyny wirtualnej platformy Azure. Wskazówki krok po kroku można znaleźć w artykule Samouczek: Ręczne instalowanie tradycyjnego wdrażania sieci serwera APLIKACJI IBM WebSphere na maszynach wirtualnych platformy Azure. Aby uzyskać więcej informacji, zobacz Co to jest IaaS?

Określanie, czy tradycyjna wersja WAS jest zgodna

Istniejąca tradycyjna wersja WAS musi być zgodna z wersją ofert IaaS. Informacje o wersji można znaleźć na stronie przeglądu pojedynczego wystąpienia serwera aplikacji IBM WebSphere na maszynach wirtualnych platformy Azure i klastrze ibm WebSphere Application Server na maszynach wirtualnych platformy Azure. Jeśli istniejąca tradycyjna wersja WAS nie jest zgodna z tą wersją, musisz odtworzyć wdrożenie ręcznie przy użyciu zasobów IaaS platformy Azure. Aby uzyskać więcej informacji, zobacz Co to jest IaaS?

Utworzenie spisu pojemności serwerów

Zapisz składniki sprzętowe (pamięć, procesor, dysk) bieżących serwerów produkcyjnych, a także średnią i szczytową liczbę żądań oraz użycie zasobów. Te informacje są ważne w kontekście wyboru rozmiaru maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Rozmiary usług Cloud Services.

Utworzenie spisu wszystkich wpisów tajnych

Przed pojawieniem się technologii typu „konfiguracja jako usługa”, takich jak usługa Azure Key Vault, nie było dobrze zdefiniowanego pojęcia „wpisu tajnego”. Zamiast tego korzystano z odrębnych zestawów ustawień konfiguracji, które efektywnie funkcjonowały jak dzisiejsze „wpisy tajne”. W przypadku serwerów aplikacji, takich jak WAS, te wpisy tajne znajdują się w wielu różnych plikach konfiguracji i magazynach konfiguracji. Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych kątem jakichkolwiek wpisów tajnych i haseł. Możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia wewnątrz aplikacji. WAS przechowuje dane konfiguracji w kilku dokumentach w kaskadowej hierarchii katalogów. Większość dokumentów konfiguracyjnych ma zawartość XML. Aby uzyskać więcej informacji, zobacz Dokumenty konfiguracji i Podstawowe pojęcia dotyczące usługi Azure Key Vault.

Utworzenie spisu wszystkich certyfikatów

Zapisz wszystkie certyfikaty używane na potrzeby publicznych punktów końcowych protokołu SSL. Wszystkie certyfikaty na serwerach produkcyjnych można wyświetlić, uruchamiając następujące polecenie:

keytool -list -v -keystore <path to keystore>

Aby uzyskać więcej informacji, zobacz zarządzanie certyfikatami dokumentów IBM w protokole SSL

Sprawdzanie, czy obsługiwana wersja języka Java działa poprawnie

Korzystanie z usługi WAS na maszynach wirtualnych platformy Azure wymaga określonej wersji języka Java, dlatego należy upewnić się, że aplikacja działa prawidłowo przy użyciu tej obsługiwanej wersji.

Ibm Java 8 jest dostarczany z dystrybucją WAS9. Zalecamy używanie dostarczonego przez firmę IBM środowiska Java JRE. Aby uzyskać więcej informacji, zobacz Java SE 8 w webSphere Application Server tradycyjny V9.

Jeśli chcesz przełączyć się do innego zestawu JAVA SDK, postępuj zgodnie z dokumentem IBM Switch the Java SDK in WebSphere Application Server (Przełączanie zestawu JAVA SDK na serwerze aplikacji WebSphere).

Utworzenie spisu zasobów JNDI

Utwórz spis wszystkich zasobów JNDI. Na przykład źródła danych, takie jak bazy danych, mogą mieć skojarzoną nazwę JNDI, która umożliwia interfejsowi JPA prawidłowe powiązanie wystąpień EntityManager z określoną bazą danych. Aby uzyskać więcej informacji na temat zasobów i baz danych JNDI, zobacz WebSphere Data Sources (Źródła danych WebSphere) w dokumentacji ibm. Inne zasoby związane z JNDI, takie jak broker komunikatów JMS, mogą wymagać migracji lub ponownej konfiguracji. Aby uzyskać więcej informacji na temat konfiguracji pakietu JMS, zobacz Using JMS resources (Korzystanie z zasobów JMS).

Sprawdzanie konfiguracji profilu

Główną jednostką konfiguracji w usłudze WAS jest profil. W związku z tym plik resources.xml zawiera wiele konfiguracji, które należy dokładnie rozważyć pod kątem migracji. Plik zawiera odwołania do większej liczby plików XML przechowywanych w podkatalogach. IBM zaleca, aby zwykle używać konsoli IBM do konfigurowania zarządzanych obiektów i usług WAS oraz zezwalać WAS na konserwację folderu profile/profile-name . Aby uzyskać więcej informacji, zobacz Zarządzanie profilami w systemach operacyjnych rozproszonych i IBM i.

W aplikacji

Sprawdź plik deployment.xml i/lub plik WEB-INF/web.xml.

Określenie, czy jest używana replikacja sesji

Jeśli aplikacja korzysta z replikacji sesji, dostępne są następujące opcje:

  • W przypadku sesji HTTP, zgodnie z poziomem zarządzania sesjami, można użyć pamięci lub bazy danych do zbierania danych sesji.
  • W przypadku sesji rozproszonych można zapisywać sesje w bazie danych przy użyciu trwałości sesji bazy danych.
  • W przypadku dynamicznej pamięci podręcznej można zarządzać danymi sesji w replikacji z pamięci do pamięci lub bazy danych.
  • Refaktoryzacja aplikacji w celu użycia bazy danych do zarządzania sesją.
  • Refaktoryzacja aplikacji w celu eksternalizacji sesji do usługi Azure Redis. Aby uzyskać więcej informacji, zobacz Pamięć podręczna Azure Cache for Redis.

W przypadku wszystkich tych opcji dobrym pomysłem jest opanowanie sposobu działania replikacji stanu sesji HTTP. Aby uzyskać więcej informacji, zobacz Administrowanie fasolą sesji w dokumentacji IBM.

Udokumentowanie źródeł danych

Jeśli aplikacja korzysta z dowolnych baz danych, należy przechwycić następujące informacje:

  • Jaka jest nazwa źródła danych?
  • Jaka jest konfiguracja puli połączeń?
  • Gdzie mogę znaleźć plik JAR sterownika JDBC?

Aby uzyskać więcej informacji na temat sterowników JDBC w usłudze WAS, zobacz Using JDBC Drivers with WebSphere Application Server (Używanie sterowników JDBC z serwerem aplikacji WebSphere).

Określanie, czy funkcja WAS została dostosowana

Ustal, które z następujących dostosowań zostały wdrożone, i określ, jakie działania zostały wykonane.

  • Czy zostały zmienione skrypty uruchamiania? Takie skrypty obejmują wsadmin, AdminControl, AdminConfig, AdminApp i AdminTask.
  • Czy do środowiska JVM są przekazywane określone parametry?
  • Czy do ścieżki klas serwera zostały dodane pliki JAR?
  • Czy obiekty na poziomie systemu operacyjnego, takie jak systemd były używane do automatycznego uruchamiania składników WAS po ponownym uruchomieniu serwera?

Należy uwzględnić zagadnienia dotyczące migracji w zależności od odpowiedzi na te pytania.

Określenie, czy jest konieczne połączenie z lokalną usługą

Jeśli aplikacja wymaga dostępu do dowolnych usług lokalnych, musisz aprowizować jedną z usług łączności platformy Azure. Aby uzyskać więcej informacji, zobacz Łączenie sieci lokalnej z platformą Azure. Możesz również przeprowadzić refaktoryzację aplikacji, aby korzystać z publicznie dostępnych interfejsów API uwidacznianych przez Twoje zasoby lokalne.

Określanie, czy używane są kolejki lub tematy Java Message Service (JMS)

Jeśli aplikacja korzysta z kolejek lub tematów JMS, musisz przeprowadzić migrację ich do serwera JMS hostowanego zewnętrznie. Jedną ze strategii dla osób korzystających z programu JMS jest użycie usługi Azure Service Bus i protokołu Advanced Message Queuing Protocol. Aby uzyskać więcej informacji, zobacz Use Java Message Service 1.1 with Azure Service Bus standard and AMQP 1.0 (Używanie usługi Java Message Service Service 1.1 z usługą Azure Service Bus w warstwie Standardowa i AMQP 1.0).

Jeśli skonfigurowano magazyny trwałe JMS, należy przechwycić ich konfigurację i zastosować ją po migracji.

Jeśli używasz oprogramowania IBM MQ, możesz migrować to oprogramowanie do usługi Azure Virtual Machines i używać go w takim stanie, w jakim jest.

Firma Microsoft ma rozwiązanie do integracji oprogramowania IBM MQ z usługą Logic Apps. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia z serwerem IBM MQ z przepływu pracy w usłudze Azure Logic Apps.

Ustalanie, czy są używane niestandardowe, udostępnione biblioteki Java EE

Jeśli korzystasz z funkcji udostępnionych bibliotek Java EE, masz dwie opcje:

  • Przeprowadź refaktoryzację kodu aplikacji, usuwając wszystkie zależności od bibliotek, i dołącz funkcje bezpośrednio do aplikacji.
  • Dodaj biblioteki do ścieżki klas serwera.

Określanie, czy są używane pakiety technologii OSGi

Jeśli użyto pakietów OSGi dodanych do bazy danych WAS, musisz dodać równoważne pliki JAR bezpośrednio do aplikacji internetowej.

Określanie, czy aplikacja zawiera kod właściwy dla systemu operacyjnego

Jeśli aplikacja zawiera jakikolwiek kod z zależnościami systemu operacyjnego hosta, należy go refaktoryzować, aby usunąć te zależności. Na przykład może być konieczne zastąpienie dowolnego użycia ścieżki / systemu plików lub \ w ścieżkach File.Separator systemu plików lub Paths.get jeśli aplikacja jest uruchomiona w systemie Windows.

Określanie, czy jest używana usługa IBM Integration Bus

Jeśli aplikacja korzysta z usługi IBM Integration Bus, musisz przechwycić sposób konfigurowania usługi IBM Integration Bus. Aby uzyskać więcej informacji, zobacz dokumentację usługi IBM Integration Bus.

Ustalanie, czy aplikacja składa się z wielu plików WAR

Jeśli Twoja aplikacja składa się z wielu plików WAR, należy traktować poszczególne pliki jako oddzielne aplikacje. W przypadku każdej z nich należy wykonać instrukcje opisane w tym przewodniku.

Ustalanie, czy aplikacja jest spakowana jako plik EAR

Jeśli aplikacja jest spakowana jako plik EAR, sprawdź application.xml, ibm-application-bnd.xmi i ibm-application-ext.xmi i przechwytywać ich konfiguracje. Aby uzyskać więcej informacji, zobacz Tworzenie pakietu archiwum przedsiębiorstwa (EAR) w witrynie WebSphere.

Identyfikacja wszystkich procesów i demonów zewnętrznych działających na serwerach produkcyjnych

Jeśli masz jakiekolwiek procesy działające poza serwerem aplikacji, takie jak demony monitorowania, musisz wyeliminować je lub zmigrować do innego miejsca.

Określanie, czy i jak jest używany system plików

Pod względem trwałości, uruchamiania i zamykania systemy plików maszyn wirtualnych działają tak samo jak lokalne systemy plików. Mimo to, ważne jest, aby znać wymagania systemu plików i zapewnić maszynom wirtualnym odpowiedni rozmiar oraz wydajność magazynu.

Zawartość statyczna tylko do odczytu

Jeśli aplikacja aktualnie obsługuje zawartość statyczną, potrzebna jest dodatkowa lokalizacja. Warto rozważyć przeniesienie zawartości statycznej do usługi Azure Blob Storage i dodanie usługi Azure CDN, aby zapewnić błyskawiczne pobieranie na całym świecie. Aby uzyskać więcej informacji, zobacz Hostowanie statycznej witryny internetowej w usłudze Azure Storage i Szybki start: integrowanie konta usługi Azure Storage z usługą Azure CDN.

Dynamicznie publikowana zawartość statyczna

Jeśli aplikacja zezwala na zawartość statyczną, która została przekazana/utworzona przez aplikację, ale pozostaje niezmienna po jej utworzeniu, możesz użyć usług Azure Blob Storage i Azure CDN, jak opisano powyżej, oraz usługi Azure Function do obsługiwania przekazywania i odświeżania usługi CDN. Udostępniliśmy przykładową implementację do użycia w temacie Przekazywanie zawartości statycznej i jej wstępne ładowanie w usłudze CDN za pomocą usługi Azure Functions.

Określanie topologii sieci

Bieżący zestaw ofert witryny Azure Marketplace jest punktem wyjścia do migracji. Jeśli oferta nie obejmuje aspektów architektury, które należy zmigrować, musisz przechwycić topologię sieci istniejącego wdrożenia. Następnie należy odtworzyć topologię sieci na platformie Azure, nawet po utworzeniu podstawowej oferty przy użyciu jednego z szablonów rozwiązań.

Topologia sieci jest szerokim tematem, ale następujące odwołania mogą dać pewne wskazówki dla wysiłków związanych z migracją:

  • Poniższe odwołanie wylicza ogólne tematy dotyczące migracji topologii sieci na platformę Azure: Topologie wdrażania sieci serwera aplikacji WebSphere.
  • Ponieważ źródła danych są oddzielnymi serwerami w systemie WAS, należy je wziąć pod uwagę w ramach analizy topologii sieci. Aby uzyskać więcej informacji, zobacz WebSphere Application Server Data Sources (Źródła danych serwera aplikacji WebSphere).
  • Źródła komunikatów są również oddzielnymi serwerami. Aby uzyskać więcej informacji, zobacz Topologie sieci: Współdziałanie przy użyciu dostawcy obsługi komunikatów webSphere MQ.
  • Podstawowym wymogiem jest równoważenie obciążenia. W poniższej dokumentacji opisano stronę was równoważenia obciążenia: klastrowanie z równoważeniem obciążenia serwera aplikacji WebSphere Application Server.

Konto dotyczące używania kart JCA i kart zasobów

Jeśli istniejąca aplikacja używa kart JCA lub innych kart zasobów do łączenia się z innymi systemami przedsiębiorstwa, upewnij się, że zastosowano konfigurację tych artefaktów do usługi WAS uruchomionej w usłudze Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Relacyjne karty zasobów i JCA w dokumentacji ibm.

Konto na potrzeby uwierzytelniania i autoryzacji

Większość aplikacji ma pewnego rodzaju uwierzytelnianie i autoryzację. Jeśli używasz identyfikatora OpenID do uwierzytelniania, możesz skonfigurować uwierzytelnianie openID connect za pomocą identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz OpenID Connect authentication with Microsoft Entra ID (Uwierzytelnianie openID Connect za pomocą identyfikatora entra firmy Microsoft).

Określanie, czy jest używane klastrowanie WAS

Najprawdopodobniej aplikacja została wdrożona na wielu serwerach WAS w celu osiągnięcia wysokiej dostępności. Te klastry można migrować bezpośrednio z instalacji lokalnej do usługi WAS uruchomionej w usłudze Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz WebSphere Application Server Network Deployment (Wdrażanie sieci serwera aplikacji WebSphere) w dokumentacji firmy IBM.

Konto wymagań dotyczących równoważenia obciążenia

Równoważenie obciążenia jest istotną częścią migracji klastra WAS na platformę Azure. Najprostszym rozwiązaniem jest użycie wbudowanej obsługi usługi aplikacja systemu Azure Gateway lub serwera HTTP IBM dostępnego w ofercie witryny Azure Marketplace dla klastra serwera aplikacji IBM WebSphere.

Aby uzyskać podsumowanie możliwości usługi aplikacja systemu Azure Gateway w porównaniu z innymi rozwiązaniami równoważenia obciążenia platformy Azure, zobacz Opcje równoważenia obciążenia.

Określanie, czy jest używana funkcja klienta aplikacji Java EE

Jeśli aplikacja używa funkcji klienta aplikacji Java EE, po zakończeniu migracji do usługi Azure Virtual Machines powinna działać bez żadnych zmian. Aby uzyskać więcej informacji, zobacz Using Java EE Client Application Modules (Używanie modułów aplikacji klienta Java EE).

Migracja

Wybieranie tradycyjnej oferty WAS na maszynach wirtualnych platformy Azure

Poniższe oferty są dostępne dla usługi WAS na maszynach wirtualnych platformy Azure.

Podczas wdrażania oferty zostanie wyświetlony monit o wybranie rozmiaru maszyny wirtualnej dla węzłów WAS. Ważne jest, aby uwzględnić wszystkie aspekty rozmiaru (pamięć, procesor, dysk) wybranej maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Rozmiary usług Cloud Services (wersja klasyczna).

Aprowizacja oferty

Po wybraniu oferty, od której chcesz rozpocząć, aprowizuj ofertę, postępując zgodnie z instrukcjami w temacie Deploy WebSphere Application Server (traditional) Cluster on Azure Virtual Machines (Wdrażanie klastra aplikacji WebSphere (tradycyjny) na maszynach wirtualnych platformy Azure.

Migrowanie profilów

Po aprowizowanej ofercie możesz sprawdzić konfigurację profilu. Aby uzyskać więcej informacji, zobacz Pojęcia dotyczące profilu w dokumentacji firmy IBM.

Łączenie baz danych

Po zmigrowaniu profilów można połączyć bazy danych, postępując zgodnie z instrukcjami w temacie Konfigurowanie źródła danych serwera aplikacji WebSphere w dokumentacji firmy IBM.

Konto magazynów kluczy

Należy uwzględnić migrację wszystkich magazynów kluczy SSL używanych przez aplikację. Aby uzyskać więcej informacji, zobacz Konfiguracje magazynu kluczy dla protokołu SSL w dokumentacji ibm.

Łączenie źródeł interfejsu JMS

Po połączeniu baz danych można skonfigurować program JMS, postępując zgodnie z instrukcjami w temacie Konfigurowanie programu JMS w programie IBM WebSphere Application Server w dokumentacji ibm.

Konto na potrzeby uwierzytelniania i autoryzacji

Większość aplikacji ma pewnego rodzaju uwierzytelnianie i autoryzację. Jeśli używasz identyfikatora OpenID do uwierzytelniania, możesz skonfigurować uwierzytelnianie openID connect za pomocą identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz OpenID Connect authentication with Microsoft Entra ID (Uwierzytelnianie openID Connect za pomocą identyfikatora entra firmy Microsoft).

Konto na potrzeby rejestrowania

Elastyczny stos można skonfigurować, postępując zgodnie z instrukcjami w temacie Analizowanie dzienników serwera aplikacji WebSphere za pomocą usługi Elastic Stack w dokumentacji ibm. Platforma Azure zapewnia obsługę funkcji Elastic. Aby uzyskać więcej informacji, zobacz Co to jest integracja elastyczna z platformą Azure? Możesz połączyć wiedzę z tych dwóch zasobów, aby uzyskać rozwiązanie do rejestrowania zoptymalizowanego pod kątem platformy Azure dla usługi WAS na maszynach wirtualnych.

Migrowanie aplikacji

Techniki używane do wdrażania aplikacji od zespołu programistycznego do serwerów testowych, przejściowych i produkcyjnych różnią się znacznie w poszczególnych przypadkach. W niektórych przypadkach istnieje wysoce rozwinięta platforma ciągłej integracji/ciągłego wdrażania, która powoduje wdrożenie aplikacji na serwerze aplikacji WebSphere. W innych przypadkach proces może być realizowany w większym stopniu ręcznie. Jedną z zalet korzystania z usługi Azure Virtual Machines do migrowania tradycyjnych aplikacji WAS do chmury jest to, że istniejące procesy nadal działają.

Należy skonfigurować sieciową grupę zabezpieczeń, która aprowizuje dostęp z potoku ciągłej integracji/ciągłego wdrażania lub system wdrażania ręcznego. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

Testowanie

Aby uzyskać dostęp do nowych serwerów działających na platformie Azure, należy skonfigurować wszystkie testy w kontenerze względem aplikacji. Podobnie jak w przypadku problemów dotyczących ciągłej integracji/ciągłego wdrażania, należy upewnić się, że niezbędne reguły zabezpieczeń sieci umożliwiają testom dostęp do aplikacji wdrożonych na platformie Azure. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

Po migracji

Po osiągnięciu celów migracji zdefiniowanych w kroku Czynności przed migracją wykonaj niektóre kompleksowe testy akceptacyjne, aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami. Aby uzyskać wskazówki dotyczące niektórych potencjalnych ulepszeń po migracji, zobacz następujące zalecenia: