🥇Zkušenosti s přechodem SAP hostingu: jak migrovat systémy bez bolestivých následků

Nebo můžeme? Samozřejmě, migrace systémů SAP je složitý a náročný proces, jehož úspěch závisí na koordinované práci všech účastníků. A pokud je migrace prováděna ve zkrácených lhůtách, úkol se několikrát komplikuje. Ne každý se na to odváží. Důvodů může být několik. Například, proces je sám o sobě dlouhý a organizačně složitý. K tomu existuje riziko neplánovaných prostoje systémů. Nebo zákazníci nejsou jisti, že po takové operaci získají benefity úměrné vynaloženým úsilím. Nicméně, výjimky se také vyskytují.

Podrobněji se zaměříme na obtíže, s nimiž se objednatelé setkávají během migrace a podpory systémů SAP, probereme, proč stereotypey ne vždy odpovídají realitě, a podělíme se o případ, jak se nám podařilo migrovat systémy zákazníka na novou infrastrukturu za pouhé tři a kousek měsíce.

Hosting systémů SAP

Ještě před pěti lety bylo těžké si představit, že klienti začnou masově využívat hostingové zdroje pro aplikace SAP. V drtivé většině případů byly zaváděny on-premise. Nicméně s vývojem modelů outsourcingu a trhu cloudových služeb se pohled zákazníků začal měnit. Jaké jsou argumenty, které ovlivňují výběr v prospěch cloudu pro SAP?

Pro nováčky, kteří teprve plánují zavedení SAP, je cloudová infrastruktura téměř standardní volbou – škálovatelnost zdrojů podle aktuální potřeby systému a neochota odvádět zdroje na rozvoj nepodstatných kompetencí.
V společnostech s rozsáhlou systémovou krajinou zajišťuje hosting systémů SAP CIO kvalitativně jinou úroveň řízení rizik, protože za SLA odpovídá partner.
Třetí z nejčastěji uváděných argumentů je vysoká cena výstavby infrastruktury pro realizaci scénářů vysoké dostupnosti a DR.
Faktor 2027 – oznámené dodavatelem ukončení podpory zastaralých systémů v roce 2027. To znamená převod DB na HANA, což s sebou nese náklady na modernizaci a nákup nových výpočetních výkonů.

Trh SAP hostingu v Česku lze nyní považovat za dostatečně zralý. To poskytuje široké možnosti pro klienty, kteří chtějí změnit své hostingové platformy. Takové projekty však mohou spravedlivě vzbuzovat obavy u firem kvůli složitosti migračního procesu. To nutí zákazníky klást vyšší nároky na poskytovatele služeb, kteří musí mít nejen výjimečné kompetence v oblasti hostingu a podpory SAP systémů, ale také úspěšné zkušenosti v oblasti migrace.

Jaké jsou obtíže při změně SAP hostingu?

Hostování může mít různé formy. Nesoulad se slíbenou úrovní služeb, řada "ale" a hvězdiček s drobným písmem, omezené zdroje a možnosti hostingového poskytovatele, nedostatek flexibility v komunikaci se zákazníkem, byrokracie, technická omezení, nízká odbornost specialistů technické podpory a také mnohé další nuance – to je jen malá část skrytých nástrah, se kterými se mohou zákazníci setkat při provozování svých podnikových systémů v outsourcingových infrastrukturách. Často zůstávají tyto problémy pro klienta skryté, zakopané v mnohastránkových kontraktech, a objevují se až během využívání služeb.

V určitém okamžiku se zákazníkovi stane zřejmým, že úroveň služeb, které dostává, je daleko od jeho očekávání. To se stává jakýmsi katalyzátorem pro hledání řešení na zlepšení situace a v případě neúspěchu, kdy se problémy nahromadí na maximum a bolesti se stanou nesnesitelnými, přecházejí k aktivním akcím v hledání alternativních možností pro změnu poskytovatele služeb.

Proč se čeká na poslední chvíli? Důvod je prostý – proces přenosu systémů pro klienty není vždy průhledný a srozumitelný. Klientovi se obtížně posuzují skutečné rizika spojená s migračním procesem. Lze říci, že migrace pro klienty je jakýmsi černým boxem: nejsou jasné náklady, doba výpadku systémů, rizika a jak je minimalizovat, a vůbec je to temné a děsivé. Tady platí, že pokud se to nepodaří, hlavy létají jak u vrcholových manažerů, tak u realizátorů.

SAP — to jsou podnikové systémy, které jsou složité a ne zrovna levné. Na jejich implementaci, úpravy a podporu se vynakládají značné rozpočty a jejich dostupnost a správný chod závisí na životaschopnosti podniku. A nyní si představte důsledky zastavení nějaké velké výroby. To jsou finanční ztráty, které mohou být vyjádřeny čísly s velkým počtem nul, a také reputační a další, neméně významné rizika.

Podíváme se na problémy, které mohou nastat na každé fázi v případě migrace SAP systémů jednoho z našich zákazníků.

Příprava a projektování

Migrace je formula s mnoha různými složkami. A jedním z nejdůležitějších je fáze projektování a přípravy cílové (nové) infrastruktury.

Bylo třeba se ponořit do současné realizace systémů, jejich architektury. V cílové infrastruktuře jsme někde zopakovali existující řešení, v některých okamžicích doplnili a zlepšili, někde předělali, promysleli a vybrali řešení zajišťující odolnost vůči poruchám a dostupnost, a také maximálně konsolidovali všechny zdroje.

V průběhu projektování bylo provedeno mnoho různých cvičení, které nakonec umožnily co nejlépe se připravit na migraci a zohlednit všechny možné drobnosti a nástrahy (o nich později).

Co se nám nakonec podařilo — individuálně navržená infrastruktura soukromého cloudu na základě našeho datacentra:

vyhrazené fyzické servery pro SAP HANA;
virtualizační platforma VMware pro aplikační servery a infrastrukturní služby;
duplikované komunikační kanály mezi datacentry pro L2; VPN;
dva hlavní úložné systémy pro oddělení produkce a "všech ostatních";
Zálohovací systém na bázi Veritas Netbackup s odděleným serverem, diskovou policí a pásem knihovny.

A teď, jak jsme to všechno realizovali z technického hlediska.

SAP

Pro efektivní využití úložišť pro produktivní HANA jsme použili sdílené disky bez systémové replikace DB prostředky SAP. Vše bylo zabaleno do Active-Standby clusteru SUSE HAE na bázi Pacemaker. Ano, doba obnovy je o něco delší než s replikací, ale ušetříme prostor v úložišti STH v hodnotě dvoukrát a tím pádem i rozpočet zákazníka.
V přípravných prostředích byly klastry HANA opuštěny, ale technicky byla zopakována konfigurace produkce.
Testovací prostředí a prostředí pro vývoj byly rozloženy na několik serverů bez klastrů v konfiguraci MCOS.
Všechny servery aplikací byly virtualizovány a umístěny do VMware.

Sítě

Fyzicky byly odděleny okruhy řídicích sítí a produkčních sítí pomocí switchových stohů, přičemž produkční sítě byly směrovány k datovému centru klienta.
Bylo zajištěno dostatečné množství síťových rozhraní, aby nedocházelo ke míchání velkých toků dat.
Pro přenos dat ze úložišť bylo vytvořeno klasické FC SAN uspořádání.

Úložiště dat

Produkční a přípravné zátěže SAP byly ponechány na all-flash poli.
Testovací prostředí vývojářů a infrastrukturní služby byly umístěny na samostatném hybridním poli.

Záloha

Byla vytvořena na základě Veritas Netbackup.
Trochu jsme doplnili integrované skripty pro zálohování konfigurací MCOS.
Pohotovostní kopie byly uloženy na diskovou skříň, aby bylo možné rychle obnovit, a pro dlouhodobé uchování používáme pásky.

Monitoring

Všechny hardware, OS a SAP byly zavedeny do Zabbixu.
Sestavili jsme mnoho užitečných dashboardů v Grafana.
Při vzniku alertu Zabbix umí založit tiket v systému správy incidentů, který máme implementovaný na Jira. Také se informace duplikují do Telegram kanálu.

Celkový stav HANA

Stav serveru aplikací SAP:

Infrastrukturní služby

Pro obsluhu interních prostor názvů byl spuštěn cluster DNS serverů, který se synchronizuje se servery klienta.
Byl vytvořen samostatný souborový server pro výměnu dat.
Aby bylo možné uchovávat různé konfigurace, přidali jsme Gitlab.
Pro různé Sensitive informace jsme zvolili HashiCorp Vault.

Proces migrace

V obecném případě se proces migrace skládá z následujících fází:

příprava veškeré potřebné projektové dokumentace;
jednání s aktuálním poskytovatelem — řešení organizačních záležitostí;
nákup, doprava a instalace nového zařízení pro projekt;
testovací migrace a ladění procesu;
přenos systémů, ostrá migrace.

Na konci října 2019 jsme podepsali smlouvu, poté jsme navrhli architekturu, a po jejím schválení klientem objednali potřebné vybavení.

Na co se zaměřit jako na první — dodací lhůty vybavení. Dodávka certifikovaného hardwaru pro SAP NAHA, který odpovídá požadavkům výrobce softwaru na hardware, průměrně trvá 10-12 týdnů. A s ohledem na sezónnost (realizace projektu spadla přesně na nové vánoce) se tento čas mohl prodloužit ještě o měsíc. Je tedy nutné maximálně urychlit proces: spolupracovali jsme s dodavatelem-distributorem a vyjednávali o urychlené dodávce letadly (místo pozemních a námořních cest).

Listopad a prosinec byly věnovány přípravě na migraci a získání části vybavení. Přípravy jsme provedli na testovacím stanovišti v našem veřejném cloudu, kde jsme si vyzkoušeli všechny hlavní kroky a zachytili možné složitosti a problémy:

připravili jsme podrobný plán spolupráce účastníků projektových týmů s minutovými časovými harmonogramy;
vytvořili jsme testovací stanoviště pro databáze a aplikační servery zhruba tak, jak v cílové infrastruktuře;
nastavili jsme potřebné komunikační kanály a infrastrukturní služby k ověření funkčnosti integrací;
propracovali jsme scénáře cutover;
cloud nám také pomohl vytvořit přednastavené šablony virtuálních strojů, které jsme následně jednoduše importovali a nasadili v cílové infrastruktuře.

Nedlouho před vánočními svátky k nám dorazila první dávka vybavení. To umožnilo nasadit část systémů na skutečném hardwaru. Jelikož nepřišlo vše, připojili jsme náhradní vybavení, jehož dodávku se nám podařilo domluvit s dodavatelem a distributory. Zbylé části cílové infrastruktury jsme obdrželi až v závěrečné fázi.
Abychom stihli termín, museli naši technici obětovat vánoční prázdniny a začít pracovat na přípravě cílové infrastruktury 2. ledna, v největším rozmachu svátků. Ano, takové věci se občas stávají, když hoří a není jiná možnost. Šlo o funkčnost systémů, od kterých závisí činnost firmy.

Celkový plán migrace vypadal takto: nejprve — nejméně kritické systémy (vývojové prostředí, testovací prostředí), poté — produkční systémy. Konečná fáze migrace probíhala na konci ledna a začátkem února.

Plán migrace byl napsán s přesností na minuty. Je to cutover plán se seznamem všech úkolů, časem provedení a odpovědnými osobami. Všechny kroky byly testovány na zkušební migraci, takže při finální migraci stačilo pouze dodržovat plán a koordinovat proces.

Migrace probíhala systémově v několika fázích. V každé fázi byly dvě systémy.

Výsledkem tříměsíčního sprintu byl systém plně funkční v datovém centru KROK. V zásadě bylo dosaženo pozitivního výsledku díky spolupráci, přičemž příspěvek a oddanost všech účastníků procesu byly maximální.

Role zákazníka v projektu

Komunikace s poskytovatelem, kterého náš klient opouštěl, byla složitá. Je to pochopitelné, byli poslední na seznamu osob zainteresovaných na úspěšném dokončení projektu. Zákazník se chopil úkolů spojených s eskalací a vedením všech komunikačních otázek a zvládl to na 100500%. Za to mu patří zvláštní díky. Bez takového aktivního zapojení do procesu by mohl být výsledek projektu zcela odlišný.

Vzhledem k formalizovanosti procesů u 'bývalého' poskytovatele se o infrastrukturu starali specialisté, kteří byli doslova vzdálení problémům, které ještě v té době měli. Například proces exportu jedné a té samé databáze mohl trvat od jedné hodiny do pěti. Tenkrát se zdálo, že to je nějaká magie, jejíž tajemství nám nebylo odhaleno. Asi se technici podpory ve volných chvílích věnovali meditaci, zapomínaje, že někde daleko v Rusku jsou termíny, inženýři bez novoročních salátů, pláč a utrpení zákazníka...

Závěry projektu

Finálním akordem migrace byla převod systémů do údržby.

Nyní poskytujeme službu jednoho okna pro žádosti zákazníka a pokrýváme celý objem úkolů spojených s údržbou komponent infrastruktury a SAP basis společně s partnerem — itelligence. Klient žije v privátním cloudu již půl roku. Zde jsou statistiky ohledně servisních případů za tuto dobu: