Tento článek popisuje přístup migrace k opětovnému vytvoření úloh AIX do cloudu. Azure Functions můžete použít pro bezserverovou architekturu nebo pomocí služby Azure Virtual Machines zachovat serverový model.
Při migraci starších aplikací do Azure zvažte strategii migrace pro úlohy AIX, která maximalizuje návratnost investic (ROI). Opakované migrace vyžadují minimální změny, ale poskytují výhody nativní pro cloud, které se podobají migraci refaktoringu.
Mezi výhody opětovné migrace patří:
- Snížení celkových nákladů na vlastnictví (TCO).
- Vylepšená obchodní flexibilita.
- Vylepšená provozní odolnost.
Architektura (přeformátovaná)
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Tento pracovní postup odpovídá předchozí architektuře.
Požadavky uživatelů a integrace příchozích rozhraní API se přenesou do služby Aplikace Azure Gateway na protokolu TCP/443 (HTTPS), který poskytuje funkci firewallu webových aplikací (WAF). Application Gateway odesílá požadavky( jako reverzní požadavky proxy) různým službám hostovaným na platformě EAP (Red Hat JBoss Enterprise Application Platform).
Webové služby Java dotazuje databázi Oracle (TCP/1521). Doba odezvy synchronního webového požadavku je menší než 50 milisekund (ms).
Asynchronní požadavek, například naplánování dávkové úlohy, umístí záznam do databázové tabulky, která funguje jako fronta v aplikační vrstvě.
Poznámka:
V budoucnu služba Azure Queue Storage nahradí tabulku databáze, takže můžete mít vždy přístup ke spouštění analytických úloh.
Úloha cron napsaná ve skriptu KornShellu (ksh) se portuje do Bash a běží na samostatném serveru Red Hat Enterprise Linux (RHEL) ve službě Azure Virtual Machine Scale Sets. Úloha cron se spouští každých 15 minut, včetně při spuštění systému, a dotazuje frontu v databázi Oracle. Úlohy běží po jednom hostiteli. Škálovací sady virtuálních počítačů paralelizují dlouhotrvající úlohy analýzy. Toto řešení nevyžaduje dávkové zpracování mimo špičku, aby omezilo vliv na výkon systému během pracovní doby.
Azure Communication Services odesílá e-mailová upozornění prostřednictvím nástroje Azure CLI (dokumentace). Spravované identity přiřazené systémem Azure, jako
az login --identityje například , ověřují virtuální počítač.Výsledky úlohy analýzy přejdou do sdílené složky Azure Files prostřednictvím zabezpečeného SMBv3 (TCP/445), který také používá spravované identity přiřazené systémem.
Komponenty
Microsoft Entra ID eliminuje vztah důvěryhodnosti na základě sítě a poskytuje spravované identity přiřazené systémem, což zlepšuje zabezpečení.
Aplikace Azure Služba eliminuje potřebu správy operačního systému a serveru, což zvyšuje provozní efektivitu a obchodní flexibilitu.
Application Gateway je plně spravovaná a škálovatelná služba, která poskytuje firewall webových aplikací a funkci reverzního proxy serveru.
Služba Azure Files poskytuje sestavy dat publikované prostřednictvím spravované služby.
Azure Functions je bezserverová výpočetní platforma založená na událostech, která se používá k efektivnímu vývoji kódu v zadaném programovacím jazyce.
Virtuální počítač Azure používá databáze Oracle a analytické uzly SAS.
Galerie služby Azure Compute sestaví a ukládá image pro uzly analýzy Oracle a SAS. Existují dvě galerie: jedna v primární oblasti a jedna v oblasti zotavení po havárii.
Komunikační služby odesílají e-maily pomocí nástroje CLI. Tato služba nahrazuje
mailxpříkaz v AIX.
Alternativy
Alternativou je kompletní serverová architektura, která zachovává všechny komponenty middlewaru tak, jak je.
Toto řešení se podobá původní architektuře, která splňuje podobný mandát jako v rámci toho, pod kterým pracuje mnoho IT organizací. Toto alternativní řešení také stojí přibližně stejně jako původní architektura, ale neposkytuje výhody, které poskytuje replatformovaná architektura. Příklad:
Úspory licencí: Alternativní řešení zachovává WebSphere a přidává další uzly RHEL.
Provozní efektivita: Alternativní řešení zachová stejný počet serverů, které se mají zachovat.
Obchodní flexibilita: Díky alternativnímu řešení zůstává vytváření sestav omezené jenom na noci bez automatické analýzy, která by se automaticky škálovalo.
Podrobnosti scénáře
Zvolte bezserverový nebo serverový model v závislosti na přenositelnosti stávajících aplikací a plánu pracovních postupů vašeho týmu a plánu technologií.
Podobně jako v původní architektuře má replatformovaná architektura databázi Oracle, ale je znovu naformátovaná na operační systém RHEL ve službě Azure Virtual Machines. Pro plně spravovanou službu Aplikace Azure Service v replatformované architektuře nahrazuje Red Hat JBoss EAP aplikaci WebSphere Java.
Architektura (původní)
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Tento pracovní postup odpovídá předchozí architektuře.
Požadavky uživatelů a integrace příchozích rozhraní API se přenesou do místního nástroje pro vyrovnávání zatížení F5 v protokolu TCP/443 (HTTPS) a pak reverzní proxy server do různých webových služeb Java hostovaných ibm WebSphere.
Webové služby Java dotazuje databázi Oracle prostřednictvím protokolu TCP/1521. Ve většině případů je doba odezvy synchronního webového požadavku kratší než 1 sekunda (s), ale více než 300 ms podle analýzy testování a webového protokolu.
Asynchronní požadavek, například naplánování dávkové úlohy, umístí záznam do databázové tabulky Oracle, která funguje jako fronta v aplikační vrstvě.
Úloha cron napsaná ve skriptu ksh dotazuje frontu v databázi Oracle a přebírá úlohy analýzy SAS, které se mají spustit. Zákazník musí provádět dávkové zpracování v noci, aby omezil vliv na výkon systému během pracovní doby.
E-mailová upozornění upozorňují uživatele a správce prostřednictvím protokolu SMTP (TCP/25) o časech zahájení a dokončení úlohy a výsledcích úspěchu nebo selhání.
Výsledky úlohy analýzy přejdou na sdílenou jednotku přes systém souborů NFS (TCP+UDP/111 2049) pro shromažďování přes SMBv3 (TCP/445).
Podrobnosti scénáře
Tato původní architektura vyhodnocuje monolitickou aplikaci Java, která běží na IBM WebSphere, a vyhodnocuje dávkové zpracování ze SAS, které orchestrují skripty ksh. Databáze Oracle, která běží na samostatném hostiteli AIX, podporuje obě aplikační úlohy.
Zvažte původní úlohu, která běží na AIX, a zjistěte, jestli strategie migrace replatformuje váš rozpočet migrace. Pracujte zpětně od požadovaných výsledků a určete transformativní cestu migrace zaměřenou na aplikaci do cloudu. Ujistěte se, že většina kódu aplikace je napsaná v jazyce, který podporují nativní cloudové služby, jako jsou architektury bez serveru a orchestrátory kontejnerů.
V tomto scénáři tidal Accelerator analyzoval kód aplikace Java a určil jeho kompatibilitu s JBoss EAP. V rané fázi projektu se azure Pipelines nebo GitHub Actions používají k opětovnému sestavení aplikace jako pilotního nasazení. Zákazník pak může vytvořit flexibilitu z kanálů kontinuální integrace a průběžného doručování (CI/CD) ve spravované službě, jako je služba Aplikace Azure Service. Zákazník nemůže tuto funkci získat ve svém místním prostředí WebSphere.
Tento příklad uchovává databázi Oracle v této fázi kvůli množství PL/SQL, které akcelerátor Tidal zjistil během fáze analýzy. Budoucí úsilí zákazníka zahrnuje migraci z databáze Oracle na RHEL do plně spravované databáze Azure Database for PostgreSQL, přijetí služby Azure Queue Storage a spouštění plně úloh SAS na vyžádání. Toto úsilí je v souladu s technologickým plánem, vývojovými cykly zákazníka a obchodním směrem, který byl určen v pohovoru vlastníka aplikace. Následující snímek obrazovky ukazuje rozhovor v Akcelerátoru Tidal.
Potenciální případy použití
Tuto architekturu pro AIX můžete použít k migracím do Azure, které pokrývají analýzy dat, správu vztahů se zákazníky (CRM), vrstvy integrace sálových počítačů v hybridní cloudové konfiguraci a další vlastní softwarová řešení ve scénářích inventáře a správy skladů.
Tuto architekturu můžete použít pro tradiční aplikační úlohy s technologiemi, jako jsou:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Spolehlivost
Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.
Tato architektura využívá Azure Site Recovery k zrcadlení databázových virtuálních počítačů Azure do sekundární oblasti Azure pro rychlé převzetí služeb při selhání a zotavení po havárii, pokud selže celá oblast Azure. Podobně služba Azure Files používá geograficky redundantní úložiště.
Uzly zpracování dat používají zónově redundantní spravované disky (RA-ZRS) k zajištění odolnosti během výpadků zón. Během výpadku celé oblasti můžete uzly zpracování dat v jiné oblasti z jiné oblasti z image virtuálního počítače v rámci redundantní galerie výpočetních prostředků Azure znovu vytvořit.
Zabezpečení
Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.
Tato architektura přijímá neměnný přístup k nasazením aplikací a proaktivně kontroluje kód v kanálech Azure, aby pomohl zabezpečit citlivá data v produkčním prostředí. Zahrnuje přístup doleva posunu pro kontrolu zabezpečení a často spouští nasazení s podporou kanálu CI/CD, aby se zlepšilo současné dodržování softwaru a snížil technický dluh.
Optimalizace nákladů
Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.
Toto řešení odebere co nejvíce serverových komponent, což snižuje provozní náklady o více než 70 %. Tato architektura snižuje náklady na licencování výpočetních prostředků a softwaru.
Provozní dokonalost
Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.
Produktový tým se podporuje v Azure, což zkracuje dobu řešení nahlášených lístků incidentů. Počet odkaždých lístků nebo počet lístků přiřazených z jedné skupiny do druhé je navíc nulový, protože jeden produktový tým podporuje celý zásobník aplikací v Azure.
Efektivita výkonu
Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu.
Zákazník přijme Aplikace Azure Service, kde je to možné, aby mohl automaticky vertikálně navýšit kapacitu a vertikálně navýšit kapacitu svých požadavků na výpočetní prostředky tak, aby odpovídal poptávce po aplikacích. Tato elasticita zajišťuje konzistentní výkon aplikace během špičky. Tento přístup je také nákladově efektivní.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
Richard Berry| Vedoucí programu
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Další informace o použití řešení Tidal Accelerator získáte od týmu Microsoft Tidal Cloud.
Další informace o migraci do Azure získáte od technického týmu starší verze migrace.