🥇Skúsenosti so zmenou SAP hostingu: ako migrovať systémy, aby to nebolelo

Alebo je to možné? Samozrejme, migrácia SAP systémov je zložitý a zdĺhavý proces, ktorého úspech závisí od koordinovanej práce všetkých zúčastnených. Ak je migrácia vykonaná v stiesnených termínoch, úloha sa stáva mnohonásobne zložitejšou. Nie každý sa na to odváži. Dôvodov môže byť niekoľko. Napríklad, proces je sám o sebe dlhodobý a organizačne náročný. Plus existuje riziko neplánovaných výpadkov systémov. Alebo klienti nie sú presvedčení, že po prežití takej operácie získajú výhody, ktoré sú úmerné vynaloženým úsiliam. Avšak existujú aj výnimky.

Podrobne sa pozrieme na ťažkosti, s ktorými sa zákazníci stretávajú počas migrácie a podpory SAP systémov, prediskutujeme, prečo stereotypy nie vždy zodpovedajú realite, a podelíme sa o prípad, ako sa nám podarilo migrovať systémy zákazníka na novú infraštruktúru za niečo viac ako tri mesiace.

Hosting SAP systémov

Ešte pred piatimi rokmi bolo ťažké si predstaviť, že klienti začnú masovo využívať hostingové zdroje pre SAP aplikácie. Vo väčšine prípadov ich implementovali on-premise. Avšak s rozvojom modelov outsourcingu a trhu cloudových služieb sa názor zákazníkov začal meniť. Aké sú argumenty, ktoré ovplyvňujú výber cloudového riešenia pre SAP?

Pre nováčikov, ktorí práve plánujú implementáciu SAP, je cloudová infraštruktúra prakticky štandardnou voľbou – škálovateľnosť zdrojov podľa aktuálnych potrieb systému a nechcenie odkláňať zdroje na rozvoj nepodporných kompetencií.
V spoločnostiach s rozsiahlym systémovým prostredím dosahujú CIO pomocou hostingu SAP systémov kvalitne nový úroveň riadenia rizík, pretože za SLA zodpovedá partner.
Tretím z najčastejšie uvádzaných argumentov je vysoká cena vybudovania infraštruktúry na realizáciu scenárov vysokého dostupnosti a DR.
Faktor 2027 – oznámené dodávateľom ukončenie podpory zastaraných systémov v roku 2027. To znamená prevod databázy na HANA, čo so sebou prináša náklady na modernizáciu a nákup nových výpočtových kapacít.

Trh SAP hosťovania na Slovensku možno považovať za dosť zrelý. To poskytuje široké možnosti pre klientov, ktorí chcú zmeniť svoje hostingové platformy. Takéto projekty však oprávnene môžu vyvolávať obavy u podnikov kvôli zložitosti migračného procesu. To núti zákazníkov klásť vyššie požiadavky na poskytovateľov služieb, ktorí by mali mať nielen výnimočné kompetencie v oblasti hostingu a správy systémov SAP, ale aj úspešné skúsenosti v oblasti migrácie.

V čom spočívajú ťažkosti pri zmene SAP hosťovania?

Existujú rôzne oblasti hostingu. Nesúlad s deklarovanou úrovňou služieb, množstvo „ale“ a hviezdičiek s drobným písmom, obmedzené zdroje a možnosti hostingového poskytovateľa, nedostatok flexibility v otázkach komunikácie so zákazníkom, byrokracia, technické obmedzenia, nízka kvalifikácia odborníkov technickej podpory, ako aj mnohé ďalšie nuansy — to je len malá časť skrytých nástrah, s ktorými sa môžu klienti stretnúť pri prevádzkovaní svojich obchodných systémov v outsourcingových infraštruktúrach. Často zostáva všetko toto v pozadí, v hĺbkach obsiahlej zmluvy, a vypláva na povrch až počas využívania služieb.

V istom momente sa zákazníkovi stáva jasným, že úroveň služieb, ktorú dostáva, je vzdialená od jeho očakávaní. Toto je akýmsi katalyzátorom k hľadaniu riešení na nápravu situácie a v prípade neúspechu, keď sa problémy nahromadia do extrému a bolí to, prechádzajú k aktívnym krokom pri hľadaní alternatívnych možností v smere zmeny poskytovateľa služby.

Prečo sa čaká na poslednú chvíľu? Dôvod je prostý — proces presunu systémov nie je pre klientov vždy priesvitný a zrozumiteľný. Klientovi sa ťažko posudzuje skutočné riziko spojené s migračným procesom. Dalo by sa povedať, že migrácia pre klientov je akýmsi čiernym boxom: nie je jasné, aké sú náklady, doba výpadku systémov, riziká a ako ich minimalizovať, a vlastne je to celé temné a desivé. Veď ak sa to nepodarí, hlavy padnú u top manažérov aj vykonávateľov.

SAP — to sú systémy podnikovej úrovne, komplexné a, jemne povedané, nie lacné. Na ich nasadenie, úpravy a údržbu sú vynakladané značné rozpočty a od ich dostupnosti a správneho fungovania závisí životaschopnosť podniku. A teraz si predstavte dôsledky zastavenia niektorej veľkej výroby. To sú finančné straty, ktoré môžu byť vyčíslené na sumy s veľkým počtom núl, ako aj reputačné a iné, rovnako dôležité riziká.

Rozoberieme komplikácie, ktoré môžu nastat' v každej fáze na prípade migrácie SAP systémov jedného z našich zákazníkov.

Príprava a projektovanie

Migrácia je formulou s mnohými rôznymi zložkami. A jednou z najdôležitejších je fáza projektovania a prípravy cieľovej (novej) infraštruktúry.

Museli sme sa ponoriť do existujúcej realizácie systémov, ich architektúry. V cieľovej infraštruktúre sme niekde zopakovali existujúce riešenia, v niektorých aspektoch doplnili a vylepšili, niekde prerobili, premysleli a vybrali riešenia pre zabezpečenie odolnosti a dostupnosti, a zároveň maximálne skonsolidovali všetky zdroje.

V priebehu projektovania bolo vykonaných mnoho rôznych cvičení, ktoré nakoniec umožnili maximálne sa pripraviť na migráciu a zohľadniť všetky možné nuansy a nástrahy (o nich neskôr).

Čo sa nám nakoniec podarilo — individuálne navrhnutá infraštruktúra súkromného cloudu na báze nášho dátového centra:

vyhradené fyzické servery pre SAP HANA;
platforma virtualizácie VMware pre aplikačné servery a infraštruktúrne služby;
duplicované komunikačné kanály medzi dátovými centrami pre L2 VPN;
dve hlavné úložiská pre oddelenie produktivity a "všetkého ostatného";
Zálohovací systém na báze Veritas Netbackup s oddeleným serverom, diskovým boxom a páskovou knižnicou.

A tu je, ako sme to všetko realizovali z technického hľadiska.

SAP

Pre efektívne využitie úložísk pre produktívne HANA sme použili zdieľané disky bez systémovej replikácie DB prostriedkami SAP. Toto všetko sme zabalili do klastra Active-Standby SUSE HAE na báze Pacemaker. Áno, čas obnovy je trochu dlhší ako s replikáciou, ale získavame úsporu miesta úložiska dvakrát a tým pádom úsporu rozpočtu zákazníka.
V prepodražovacích prostrediach sa od klastrov HANA upustilo, ale technicky bola zopakovaná konfigurácia produkcie.
Testovacie prostredia a prostredia pre vývoj boli rozdelené na niekoľko serverov bez klastrov v konfigurácii MCOS.
Všetky aplikačné servery boli virtualizované a umiestnené do VMware.

Siete

Fyzicky sme oddelili obvody správy sietí a produktívnych sietí pomocou prepínačov, pričom produktívne sme nasmerovali smerom k datovému centru zákazníka.
Zabezpečili sme dostatočný počet sieťových rozhraní, aby sme nemiešali veľké objemy prevádzky.
Na prenos dát z úložiska sme urobili klasické FC SAN fabriky.

SÚS

Produktívne a prepodružné zaťaženie SAP zostalo na all-flash poli.
Testovacie prostredia vývojárov a infraštruktúrne služby boli umiestnené na samostatnom hybridnom poli.

Zálohovaná služba

Vybudovali sme ju na báze Veritas Netbackup.
Trochu sme doplnili vstavané skripty, aby sme zálohovali konfigurácie MCOS.
Aktuálne kópie sme uložili na diskový regál, aby sme sa rýchlo mohli obnoviť, a na dlhodobé uchovávanie používame pásky.

Monitorovanie

Všetok hardvér, OS a SAP sme zaznamenali do Zabbix.
Zostavili sme množstvo užitočných dashboardov v Grafana.
Pri výskyte alertu Zabbix vie otvoriť požiadavku v systéme správy incidentov, ktorý máme realizovaný na Jira. Informácie sú tiež duplikované do kanála Telegram.

Celkový stav HANA

Stav aplikačného servera SAP:

Infraštúrne služby

Na obsluhu interných priestorov názvov sme postavili cluster DNS serverov, ktorý sa synchronizuje so servermi zákazníka.
Vytvorili sme samostatný súborový server na výmenu údajov.
Aby sme mohli uchovávať rôzne konfigurácie, pridali sme Gitlab.
Na rôznu citlivú informáciu sme použili HashiCorp Vault.

Proces migrácie

Všeobecne sa proces migrácie skladá z nasledujúcich fáz:

príprava všetkej potrebnej projektovej dokumentácie;
rokovania s aktuálnym poskytovateľom – riešenie organizačných otázok;
nákup, dodávka a inštalácia nového hardvéru podľa projektu;
testovacia migrácia a ladenie procesu;
presun systémov, bojová migrácia.

Na konci októbra 2019 sme podpísali zmluvu, následne navrhli architektúru a po jej schválení so zákazníkom objednali potrebný hardvér.

Na čo je potrebné sa zamerať najprv, sú dodacie lehoty zariadenia. Priemerne dodanie certifikovaného hardvéru pod SAP NAHA, ktorý spĺňa požiadavky výrobcu softvéru na hardvérové platformy, trvá 10-12 týždňov. A vzhľadom na sezónnosť (realizácia projektu sa kryla práve s novým rokom) sa tento termín mohol predĺžiť ešte o mesiac. Preto bolo potrebné maximálne urýchliť proces: pracovali sme s distribútorom-dodávateľom, dohadovali sme sa na urýchlenom dodaní letadlom (namiesto pozemnej a námornej dopravy).

November a december sme venovali príprave na migráciu a získaniu časti zariadenia. Prípravu sme vykonali na testovacom stánku v našej verejnej cloude, kde sme prešli všetkými hlavnými krokmi a odhalili možné komplikácie a problémy:

pripravili sme podrobný plán spolupráce účastníkov projektových tímov s časovými harmonogramami;
postavili sme testovací stánok pre databázy a servery aplikácií približne tak, ako je to v cieľovej infraštruktúre;
nastavili sme potrebné komunikačné kanály a infraštruktúrne služby, aby sme overili funkciu integrácií;
prepracovali sme cutover scenáre;
cloud nám tiež pomohol vytvoriť prednastavené šablóny virtuálnych strojov, ktoré sme následne jednoducho importovali a nasadili v cieľovej infraštruktúre.

Tesne pred novoročnými sviatkami k nám prišla prvá dávka zariadenia. To umožnilo nasadiť časť systémov na skutočnom hardvéri. Pretože dorazilo ďaleko nie všetko, pripojili sme náhradné zariadenie, o dodaní ktorého sme sa dohodli s dodávateľom a distribútormi. Zvyšky cieľovej infraštruktúry sme získali už v záverečnej fáze.
Aby sme stihli termín, naši inžinieri museli obetovať novoročné prázdniny a začať prácu na príprave cieľovej infraštruktúry 2. januára, v najväčšom rozkvete sviatkov. Áno, také sa niekedy stáva, keď sú naliehavé situácie a iné možnosti nie sú. Na hre bola funkčnosť systémov, od ktorých závisí životaschopnosť podniku.

Celkový priebeh migrácie vyzeral takto: najprv najmenej kritické systémy (vývojové prostredie, testovacie prostredie), potom produktívne systémy. Finálna fáza migrácie prebiehala koncom januára a začiatkom februára.

Proces migrácie bol naplánovaný na minútu presne. Ide o cutover plán so zoznamom všetkých úloh, časom vyhotovenia a zodpovednými osobami. Všetky kroky už boli odskúšané na testovacej migrácii, takže v reálnej migrácii bolo potrebné len nasledovať plán a koordinovať proces.

Migrácia sa realizovala systémovo v niekoľkých etapách. V každej fáze sú dve systémy.

Výsledkom trojmesačného sprintu bol systém, ktorý plne fungoval v dátovom centre KROK. Celkovo bol pozitívny výsledok dosiahnutý vďaka spoločnej práci, príspevok a nasadenie všetkých účastníkov procesu bolo maximálne.

Úloha objednávateľa v projekte

Komunikácia s poskytovateľom, od ktorého náš klient odchádzal, nebola jednoduchá. Je to pochopiteľné, boli poslední na zozname osôb zainteresovaných na úspešnom dokončení projektu. Objednávateľ prevzal úlohy týkajúce sa eskalácie a riešenia všetkých komunikačných problémov a zvládol to na 100500%. Za to mu patrí osobitné poďakovanie. Bez takéhoto aktívneho zapojenia do procesu by mohol byť výsledok projektu úplne iný.

V dôsledku formálnosti procesov na strane „bývalého“ poskytovateľa sa o správu infraštruktúry starali odborníci, ktorí boli v priamom zmysle slova vzdialení od problémov, v tom čase ešte ich zákazníka. Napríklad proces exportu jednej a tej istej databázy mohol trvať od hodiny do piatich. Vtedy sa zdalo, že je to akákoľvek mágia, tajomstvo, ktoré sa nám nikdy neodhalilo. Asi inžinieri technickej podpory medzičasom prepadli meditácii, zabúdajúc na to, že niekde tam v ďalekom Rusku sú termíny, inžinieri bez novoročných šalátov, plače a trpí zákazník…

Záver projektu

Finálnym akordom migrácie bolo odovzdanie systémov do správy.

Teraz poskytujeme službu jedného okna pre požiadavky zákazníka a pokrývame celý objem úloh týkajúcich sa správy komponentov infraštruktúry a SAP basis spolu s partnerom — itelligence. Klient žije v súkromnej cloudovej infraštruktúre už pol roka. Tu sú štatistiky o servisných prípadoch za toto obdobie: