Migrace aplikací WebSphere do služby Azure Virtual Machines

  • Článek

Tato příručka popisuje, o čem byste měli vědět, když chcete migrovat stávající tradiční aplikaci WebSphere Application Server (WAS) pro spuštění na virtuálních počítačích Azure. Přehled dostupných tradičních řešení WAS na Azure Marketplace najdete v tématu Co jsou řešení pro provozování řady produktů IBM WebSphere v Azure?

Před migrací

Pokud chcete zajistit úspěšnou migraci, dokončete kroky posouzení a inventáře popsané v následujících částech.

Definice, co se rozumí pod pojmem „Migrace je hotová“

Tento průvodce a odpovídající nabídky Azure Marketplace představují výchozí bod pro zrychlení migrace tradičních úloh WAS do Azure. Je důležité definovat rozsah své migrace. Provádíte například migraci striktně metodou „lift and shift“ z existující infrastruktury do služby Azure Virtual Machines? Pokud ano, možná budete v pokušení při migraci provést nějaká vylepšení.

Je lepší se v maximální míře držet čisté metody „lift and shift“, ale vzít v úvahu nutné změny, jak je podrobně popsáno v této příručce. Definujte, co se rozumí pod pojmem „Migrace je hotová“, abyste věděli, kdy jste tohoto milníku dosáhli. Po dosažení "dokončení migrace" můžete pořídit snímek virtuálních počítačů, jak je popsáno v části Vytvoření snímku virtuálního pevného disku. Po ověření úspěšného obnovení ze snímku můžete provést vylepšení bez obav ze ztráty průběhu migrace, kterého jste zatím dosáhli.

Ujistěte se, že cíl je vhodným cílem pro vaše úsilí o migraci.

Prvním krokem úspěšné migrace aplikace WAS do Azure je výběr nejvhodnějšího cíle migrace.

Was Traditional funguje dobře na virtuálních počítačích Azure. Cíl virtuálního počítače je nejjednodušší volbou, protože se nejvíce podobá místnímu nasazení. Prostředí pro správu a nasazení virtuálních počítačů je podobné tomu, co máte místně.

Další možností je migrovat na kontejnery převodem tradiční úlohy WAS na kontejnery aplikací. Cíl kontejneru můžete spustit ve službě Azure Kubernetes Service (AKS) a Azure Red Hat OpenShiftu. Kompromis pro tuto jednoduchost je ekonomické náklady.

Obecně řečeno, náklady na minutu pro řešení založené na virtuálních počítačích jsou ve srovnání s kontejnery vyšší. I když náklady na řešení založené na kontejnerech jsou méně spuštěné, musíte aplikaci omezit tak, aby vyhovovala požadavkům platformy orchestrace kontejnerů.

Pokud je minimalizace změn nejdůležitějším faktorem pro vaše úsilí o migraci, zvažte migraci založenou na virtuálních počítačích. V tomto případě si přečtěte téma Migrace aplikací WebSphere do služby Azure Virtual Machines.

Pokud můžete tolerovat převod aplikace tak, aby běžela v kontejnerech, abyste snížili náklady na běh, zvažte migraci založenou na AKS nebo migraci založenou na Azure Red Hat OpenShiftu.

U migrace založené na AKS můžete začít používat úroveň Free. Získejte bezplatnou správu clusteru a platíte jenom za virtuální počítače, přidružené úložiště a síťové prostředky spotřebované. V tomto případě si přečtěte téma Migrace aplikací WebSphere do služby Azure Kubernetes Service.

U migrace založené na Azure Red Hat OpenShiftu kromě nákladů na výpočetní prostředky a infrastrukturu mají uzly aplikací další náklady na komponentu licence OpenShift. Tyto náklady se účtují na základě počtu uzlů aplikace a typu instance. Používejte ceny na vyžádání nebo rezervované instance, podle toho, co nejlépe vyhovuje potřebám vaší úlohy a firmy. V tomto případě si přečtěte téma Migrace aplikací WebSphere do Azure Red Hat OpenShiftu.

Průvodci postupy v dokumentaci k Azure Red Hat OpenShiftu pokrývají některé aspekty, které jsou relevantní pro migraci. Úplný seznam návodů najdete v dokumentaci k Azure Red Hat OpenShiftu.

Určení, jestli jsou předem připravené nabídky Azure Marketplace dobrým výchozím bodem

IBM a Microsoft se spojili s uvedením sady šablon řešení Azure na Azure Marketplace, které poskytují solidní výchozí bod pro migraci do Azure. Seznam nabídek najdete v tématu Spuštění řady produktů WebSphere a Liberty v Microsoft Azure a pak vyberte ten, který nejvíce odpovídá vašemu stávajícímu nasazení. Seznam nabídek najdete v článku Přehled: Co jsou řešení pro spuštění řady produktů IBM WebSphere v Azure?

Pokud žádná z existujících nabídek není dobrým výchozím bodem, musíte nasazení reprodukovat ručně pomocí prostředků virtuálního počítače Azure. Podrobné pokyny najdete v kurzu: Ruční instalace nasazení sítě IBM WebSphere Application Server Network Na Virtuální počítače Azure. Další informace najdete v tématu Co je IaaS?

Určení, jestli je tradiční verze WAS kompatibilní

Vaše stávající tradiční verze WAS musí být kompatibilní s verzí v nabídkách IaaS. Informace o verzi najdete na stránce přehledu jednoúčelové instance aplikačního serveru IBM WebSphere na virtuálním počítači Azure a clusteru aplikačního serveru IBM WebSphere na virtuálních počítačích Azure. Pokud vaše stávající tradiční verze WAS není s danou verzí kompatibilní, musíte nasazení reprodukovat ručně pomocí prostředků Azure IaaS. Další informace najdete v tématu Co je IaaS?

Inventarizace kapacity serverů

Zdokumentujte hardware (paměť, procesor, disk) aktuálních produkčních serverů a také průměrný a maximální počet žádostí a využití prostředků. Výběr velikosti virtuálního počítače musí vycházet z těchto údajů. Další informace najdete v článku Velikosti cloudových služeb.

Inventarizace všech tajných kódů

Před nástupem technologií „konfigurace jako služba“ typu Azure Key Vault neexistoval řádně definovaný koncept „tajných kódů“. Místo toho jste měli různorodou sadu konfiguračních nastavení, která v podstatě fungovala stejně jako dnešní „tajné kódy“. U aplikačních serverů, jako je WAS, jsou tyto tajné kódy v mnoha různých konfiguračních souborech a úložištích konfigurace. Ve všech vlastnostech a konfiguračních souborech na produkčních serverech vyhledejte tajné kódy a hesla. Konfigurační soubory obsahující hesla nebo přihlašovací údaje se mohou nacházet také ve vaší aplikaci. Was ukládá konfigurační data do několika dokumentů v kaskádové hierarchii adresářů. Většina konfiguračních dokumentů obsahuje obsah XML. Další informace najdete v tématu Dokumenty konfigurace a základní koncepty služby Azure Key Vault.

Inventarizace všech certifikátů

Zdokumentujte všechny certifikáty používané pro veřejné koncové body SSL. Všechny certifikáty na produkčních serverech zobrazíte spuštěním následujícího příkazu:

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

Další informace najdete v tématu Správa certifikátů dokumentů IBM v SSL

Ověření správné funkce podporované verze jazyka Java

Použití WAS ve službě Azure Virtual Machines vyžaduje konkrétní verzi Javy, takže je potřeba ověřit, že vaše aplikace funguje správně pomocí této podporované verze.

IBM Java 8 se dodává s distribucí WAS9. Doporučujeme použít JAVA JRE poskytovanou IBM. Další informace najdete v tématu Java SE 8 v tradičním aplikačním serveru WebSphere V9.

Pokud chcete přepnout na jinou sadu Java SDK, postupujte podle dokumentu IBM Switching the Java SDK in WebSphere Application Server.

Inventarizace prostředků JNDI

Proveďte inventarizaci všech prostředků JNDI. Zdroje dat, jako jsou databáze, mohou mít například přidružený název JNDI, který umožňuje JPA správně navazovat instance EntityManager ke konkrétní databázi. Další informace o prostředcích a databázích JNDI naleznete v tématu Zdroje dat WebSphere v dokumentaci IBM. Jiné prostředky související s JNDI, například zprostředkovatelé zpráv JMS, mohou vyžadovat migraci nebo změnu konfigurace. Další informace o konfiguraci JMS najdete v tématu Použití prostředků JMS.

Kontrola konfigurace profilu

Hlavní konfigurační jednotka ve was je profil. Soubor resources.xml proto obsahuje řadu konfigurací, které je nutné pečlivě zvážit při migraci. Soubor obsahuje odkazy na více souborů XML, které jsou uloženy v podadresářích. IBM doporučuje, abyste normálně používali konzolu IBM ke konfiguraci spravovatelných objektů a služeb WAS a umožnili WAS udržovat profily/složku s názvem profilu. Další informace najdete v tématu Správa profilů v distribuovaných operačních systémech a operačních systémech IBM i.

Ve vaší aplikaci

Zkontrolujte soubor deployment.xml nebo soubor WEB-INF/web.xml.

Určení, zda se používá replikace relace

Pokud vaše aplikace spoléhá na replikaci relací, máte následující možnosti:

  • U relací HTTP můžete v závislosti na úrovni správy relací použít paměť nebo databázi ke shromažďování dat relace.
  • U distribuovaných relací můžete ukládat relace do databáze pomocí trvalosti relace databáze.
  • V případě dynamické mezipaměti můžete spravovat data relací v replikaci mezi pamětí nebo v databázi.
  • Refaktorujte aplikaci tak, aby používala databázi pro správu relace.
  • Refaktorujte aplikaci tak, aby externalizovala relaci do služby Azure Redis. Další informace najdete v článku, který se věnuje službě Azure Cache for Redis.

Pro všechny tyto možnosti je vhodné nastavit, jak was dělá replikace stavu relace HTTP. Další informace najdete v tématu Správa istering session beans v dokumentaci IBM.

Dokumentování zdrojů dat

Pokud vaše aplikace používá nějaké databáze, potřebujete shromáždit následující informace:

  • Jaký je název zdroje dat?
  • Jaká je konfigurace fondu připojení?
  • Kde najdu soubor JAR ovladače JDBC?

Další informace o ovladačích JDBC v WAS naleznete v tématu Použití ovladačů JDBC s Webovým aplikačním serverem WebSphere.

Určení, jestli byla was přizpůsobená

Určete, která z následujících přizpůsobení byla provedena, a zachyťte provedenou akci.

  • Došlo ke změně spouštěcích skriptů? Mezi tyto skripty patří wsadmin, Správa Control, Správa Config, Správa App a Správa Task.
  • Byly do prostředí JVM předány nějaké konkrétní parametry?
  • Byly do cesty ke třídě serveru přidány nějaké soubory JAR?
  • Mají zařízení na úrovni operačního systému, jako systemd je například použití k automatickému spuštění komponent WAS po restartování serveru?

V závislosti na odpovědích na tyto otázky je potřeba vzít v úvahu aspekty migrace.

Určení, jestli je potřeba připojení k místnímu prostředí

Pokud vaše aplikace potřebuje přístup k některým místním službám, budete muset zřídit jednu ze služeb připojení Azure. Další informace najdete v článku Volba řešení pro připojení místní sítě k Azure. Alternativně budete muset aplikaci refaktorovat tak, aby používala veřejně přístupná rozhraní API, která nabízejí vaše místní prostředky.

Určení, jestli se používají fronty nebo témata JMS (Java Message Service)

Pokud vaše aplikace používá fronty nebo témata JMS, musíte je migrovat na externě hostovaný server JMS. Jednou ze strategií pro ty, kteří používají JMS, je použití služby Azure Service Bus a rozšířeného protokolu řízení front zpráv. Další informace najdete v tématu, které se věnuje použití JMS se službou Azure Service Bus a protokolem AMQP 1.0.

Pokud jste nakonfigurovali trvalá úložiště JMS, musíte zaznamenat jejich konfiguraci a použít ji po migraci.

Pokud používáte IBM MQ, můžete tento software migrovat do služby Azure Virtual Machines a používat ho tak, jak je.

Microsoft má řešení pro integraci IBM MQ s Logic Apps. Další informace najdete v tématu Připojení k serveru IBM MQ z pracovního postupu v Azure Logic Apps.

Určení, jestli používáte své vlastní vytvořené sdílené knihovny Java EE

Pokud používáte funkci sdílených knihoven Java EE, máte dvě možnosti:

  • Refaktorováním kódu své aplikace odeberte všechny závislosti na těchto knihovnách a místo toho začleňte jejich funkčnost přímo do aplikace.
  • Přidejte tyto knihovny do cesty ke třídám serveru.

Určení, jestli se používají sady OSGi

Pokud jste použili sady OSGi přidané do was, musíte přidat ekvivalentní soubory JAR přímo do webové aplikace.

Určení, jestli aplikace obsahuje kód specifický pro operační systém

Pokud vaše aplikace obsahuje jakýkoli kód se závislostmi na hostitelském operačním systému, budete muset refaktorováním tyto závislosti odebrat. Pomocí File.Separator nebo Paths.get budete například muset nahradit použití znaků / nebo \ v cestách systému souborů.

Určení, jestli se používá IBM Integration Bus

Pokud vaše aplikace používá IBM Integration Bus, musíte zaznamenat konfiguraci IBM Integration Bus. Další informace naleznete v dokumentaci IBM Integration Bus.

Určení, jestli se aplikace skládá z několika souborů WAR

Pokud se vaše aplikace skládá z několika souborů WAR, měli byste s těmito soubory WAR zacházet jako se samostatnými aplikacemi a projít tuto příručku pro každý z nich.

Určení, jestli je aplikace zabalená jako soubor EAR

Pokud je vaše aplikace zabalená jako soubor EAR, nezapomeňte prozkoumat soubory application.xml, ibm-application-bnd.xmi a ibm-application-ext.xmi a zachytit jejich konfigurace. Další informace naleznete v tématu Vytvoření balíčku podnikového archivu (EAR) na WebSphere.

Zjištění všech vnějších procesů a démonů běžících na produkčních serverech

Pokud používáte nějaké procesy, které běží mimo aplikační server, například monitorovací démony, budete je muset eliminovat nebo migrovat jinam.

Určení, jestli a jak se používá systém souborů

Systémy souborů virtuálních počítačů fungují z hlediska trvalosti, spouštění a vypínání stejně jako místní systémy souborů. I tak je důležité mít na paměti potřeby systému souborů a zajistit, aby virtuální počítače měly odpovídající velikost úložiště a výkon.

Statický obsah jen pro čtení

Pokud vaše aplikace aktuálně poskytuje statický obsah, budete pro ni potřebovat alternativní umístění. Možná budete chtít statický obsah přesunout do Azure Blob Storage a přidat Azure CDN, abyste umožnili bleskově rychlé globální stahování. Další informace najdete v tématu Hostování statického webu ve službě Azure Storage a rychlém startu: Integrace účtu úložiště Azure s Azure CDN. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

Dynamicky publikovaný statický obsah

Pokud vaše aplikace umožňuje nahrávání nebo vytváření statického obsahu, který je ale po vytvoření neměnný, můžete použít Azure Blob Storage a Azure CDN, jak je popsáno výše, s funkcí Azure Functions, která zpracovává nahrávání a aktualizace CDN. Pro vaše použití jsme poskytli ukázkovou implementaci na GitHubu – Uploading and CDN-preloading static content with Azure Functions. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

Určení síťové topologie

Aktuální sada nabídek Azure Marketplace je výchozím bodem pro vaši migraci. Pokud nabídka nepokrývá aspekty vaší architektury, kterou potřebujete migrovat, musíte zachytit síťovou topologii stávajícího nasazení. Pak je potřeba tuto topologii sítě v Azure reprodukovat i po umístění základní nabídky pomocí jedné ze šablon řešení.

Síťová topologie je široké téma, ale následující odkazy můžou dát vašemu úsilí o migraci nějaký směr:

  • Následující referenční informace uvádí témata vysoké úrovně související s migrací síťové topologie do Azure: Topologie nasazení sítě aplikačního serveru WebSphere.
  • Vzhledem k tomu, že zdroje dat jsou samostatné servery v systému WAS, musíte je vzít v úvahu jako součást analýzy topologie sítě. Další informace naleznete v tématu Zdroje dat aplikačního serveru WebSphere.
  • Také zdroje zasílání zpráv jsou samostatnými servery. Další informace naleznete v tématu Topologie sítě: Spolupráce pomocí poskytovatele zasílání zpráv WebSphere MQ.
  • Vyrovnávání zatížení je zásadním požadavkem. Následující referenční informace se týkají strany WAS vyrovnávání zatížení: Clustering s vyrovnáváním zatížení aplikačního serveru WebSphere.

Účet pro použití adaptérů JCA a adaptérů prostředků

Pokud vaše stávající aplikace používá adaptéry JCA nebo jiné adaptéry prostředků pro připojení k jiným podnikovým systémům, ujistěte se, že použijete konfiguraci těchto artefaktů na was spuštěné ve službě Azure Virtual Machines. Další informace naleznete v tématu Relační adaptéry prostředků a JCA v dokumentaci IBM.

Účet pro ověřování a autorizaci

Většina aplikací má nějaký druh ověřování a autorizace. Pokud pro ověřování používáte OpenID, můžete nakonfigurovat ověřování pomocí OpenID connect pomocí Microsoft Entra ID. Další informace naleznete v tématu OpenID Připojení ověřování pomocí Microsoft Entra ID.

Určení, jestli se používá clustering WAS

S největší pravděpodobností jste aplikaci nasadili na několik serverů WAS, abyste dosáhli vysoké dostupnosti. Tyto clustery můžete migrovat přímo z místní instalace do systému WAS spuštěného ve službě Azure Virtual Machines. Další informace naleznete v tématu Nasazení sítě aplikačního serveru WebSphere v dokumentaci IBM.

Účet pro požadavky na vyrovnávání zatížení

Vyrovnávání zatížení je důležitou součástí migrace clusteru WAS do Azure. Nejjednodušším řešením je použít integrovanou podporu pro Aplikace Azure Gateway nebo IBM HTTP Server poskytované v nabídce Azure Marketplace pro cluster aplikačního serveru IBM WebSphere.

Souhrn možností služby Aplikace Azure Gateway v porovnání s jinými řešeními pro vyrovnávání zatížení Azure najdete v tématu Možnosti vyrovnávání zatížení.

Určení, jestli se používá funkce klienta aplikace Java EE

Pokud vaše aplikace používá funkci klienta aplikace Java EE, měla by po migraci do služby Azure Virtual Machines fungovat beze změny. Další informace najdete v článku Používání modulů klientských aplikací Java EE.

Migrace

Výběr tradiční nabídky WAS na virtuálních počítačích Azure

Následující nabídky jsou k dispozici pro WAS na virtuálních počítačích Azure.

Během nasazování nabídky se zobrazí výzva k výběru velikosti virtuálního počítače pro uzly WAS. Při výběru velikosti virtuálního počítače je důležité zvážit všechny aspekty změny velikosti (paměť, procesor, disk). Další informace najdete v tématu Velikosti cloudových služeb (classic).

Zřízení nabídky

Jakmile vyberete nabídku, se kterou chcete začít, zřiďte ji podle pokynů v tématu Nasazení aplikačního serveru WebSphere (tradičního) clusteru na virtuálních počítačích Azure.

Migrace profilů

Po zřízení nabídky můžete prozkoumat konfiguraci profilu. Další informace naleznete v tématu Koncepty profilu v dokumentaci IBM.

Připojení databází

Po migraci profilů můžete databáze připojit podle pokynů v konfiguraci zdroje dat Aplikačního serveru WebSphere v dokumentaci IBM.

Účet pro úložiště klíčů

Musíte zajistit migraci všech úložišť klíčů SSL, které aplikace používá. Další informace najdete v tématu Konfigurace úložiště klíčů pro PROTOKOL SSL v dokumentaci IBM.

Připojení zdrojů JMS

Po připojení databází můžete JMS nakonfigurovat podle pokynů v části Nastavení JMS v aplikačním serveru IBM WebSphere v dokumentaci IBM.

Účet pro ověřování a autorizaci

Většina aplikací má nějaký druh ověřování a autorizace. Pokud pro ověřování používáte OpenID, můžete nakonfigurovat ověřování pomocí OpenID connect pomocí Microsoft Entra ID. Další informace naleznete v tématu OpenID Připojení ověřování pomocí Microsoft Entra ID.

Účet pro protokolování

Elastic Stack můžete nakonfigurovat podle pokynů v tématu Analýza protokolů aplikačního serveru WebSphere pomocí elastického stacku v dokumentaci IBM. Azure poskytuje podporu pro Elastic. Další informace najdete v tématu Co je integrace Elastic s Azure? Znalosti v těchto dvou prostředcích můžete kombinovat, abyste dosáhli řešení protokolování optimalizovaného pro Azure pro WAS na virtuálních počítačích.

Migrace aplikací

Techniky používané k nasazení aplikací z vývoje na testovací, přípravné a produkční servery se v jednotlivých případech velmi liší. V některých případech existuje vysoce vyvinutá platforma CI/CD, která vede k nasazení aplikací na aplikační server WebSphere. V jiných případech může být nutné některé kroky provést ručně. Jednou z výhod použití služby Azure Virtual Machines k migraci tradičních aplikací WAS do cloudu je to, že vaše stávající procesy budou dál fungovat.

Musíte nakonfigurovat skupinu zabezpečení sítě, kterou nabídka zřizuje, aby umožňovala přístup z kanálu CI/CD nebo systému ručního nasazení. Další informace najdete v tématu Skupiny zabezpečení sítě.

Testování

Abyste měli přístup k novým serverům spuštěným v Azure, musíte nakonfigurovat všechny testy v kontejneru pro aplikace. Stejně jako v případě problémů s CI/CD musíte zajistit, aby vaše testy umožňovaly přístup k aplikacím nasazeným do Azure. Další informace najdete v tématu Skupiny zabezpečení sítě.

Po migraci

Po dosažení cílů migrace, které jste definovali v části Před migrací, proveďte několik kompletních akceptačních testů, abyste ověřili, že vše funguje podle očekávání. Pokyny k některým možným vylepšením po migraci najdete v následujících doporučeních: