Nebo je to možné? Migrace systémů SAP je samozřejmě složitý a pečlivý proces, jehož úspěch vyžaduje dobře koordinovanou práci všech účastníků. A pokud je migrace provedena v krátké době, úkol se stává mnohem komplikovanějším. Ne každý se k tomu odhodlá. Důvodů může být několik. Například samotný proces je zdlouhavý a organizačně složitý. Navíc existuje riziko neplánovaného výpadku systému. Nebo klienti nemají jistotu, že po takové operaci dostanou benefity úměrné vynaloženému úsilí. Existují však výjimky.
Pod sestřihem budeme hovořit o potížích, se kterými se zákazníci potýkají v procesu migrace a údržby systémů SAP, diskutovat o tom, proč stereotypy vždy neodpovídají realitě, a sdílet případovou studii, jak se nám podařilo migrovat systémy zákazníka na novou infrastrukturu za něco málo přes tři měsíce.
Hosting systémů SAP
Ještě před pěti lety bylo těžké si představit, že klienti začnou masivně využívat hostingové prostředky pro aplikace SAP. Ve většině případů byly implementovány on-premise. S rozvojem modelů outsourcingu a trhu cloudových služeb se však pohled zákazníků na svět začal měnit. Jaké jsou argumenty ovlivňující volbu ve prospěch cloudu pro SAP?
- Pro začátečníky, kteří teprve plánovali implementaci SAP, je cloudová infrastruktura téměř standardní volbou – škálovatelnost zdrojů na aktuální potřeby systému a neochota přesměrovat zdroje na rozvoj vedlejších kompetencí.
- Ve společnostech s rozsáhlou systémovou krajinou dosahují CIO s pomocí hostingu systémů SAP kvalitativně jiné úrovně řízení rizik, protože Partner je odpovědný za SLA.
- Třetím nejčastějším argumentem jsou vysoké náklady na vybudování infrastruktury pro implementaci scénářů vysoké dostupnosti a DR.
- Faktor 2027 – dodavatel oznámil ukončení podpory starších systémů v roce 2027. To znamená převedení databáze do HANA, což s sebou nese náklady na modernizaci a nákup nového výpočetního výkonu.
Hostingový trh SAP v Rusku lze nyní považovat za docela vyspělý. A to poskytuje dostatek příležitostí pro zákazníky, kteří chtějí změnit své hostingové platformy. Takové projekty však mohou oprávněně vyvolávat obavy mezi podniky kvůli složitosti postupu migrace. To nutí zákazníky klást zvýšené nároky na poskytovatele služeb, kteří musí mít nejen výjimečné kompetence v hostingu a údržbě systémů SAP, ale také úspěšné zkušenosti v oblasti migrace.
Jaké jsou potíže se změnou hostingu SAP?
Hostingy jsou různé. Nesoulad s deklarovanou úrovní služeb, mnoho „ale“ a hvězdiček s výhradami v malém textu, omezené zdroje a možnosti poskytovatele hostingu, neflexibilita v otázkách komunikace s klientem, byrokracie, technická omezení, nízká kompetentnost technické podpory specialisté, stejně jako mnoho dalších nuancí - to jsou To je jen malá část úskalí, se kterými se mohou klienti setkat při provozování svých obchodních systémů v outsourcingových infrastrukturách. To vše pro klienta často zůstává ve stínu, v džungli mnohastránkové smlouvy a vynoří se v procesu využívání služeb.
V určitém okamžiku je zákazníkovi zřejmé, že úroveň služeb, které dostává, je daleko od jeho očekávání. Jedná se o jakýsi katalyzátor pro hledání řešení k nápravě situace a v případě neúspěchu, kdy se problémy nahromadí na hranici možností a je to velmi bolestivé, přejdou k aktivním akcím s cílem vyvinout alternativní možnosti ve směru změny poskytovatele služeb. .
Proč čekají do poslední chvíle? Důvod je jednoduchý – proces migrace systémů pro klienty není vždy transparentní a srozumitelný. Pro klienta je obtížné posoudit skutečná rizika spojená s procesem migrace. Dá se říci, že migrace je pro klienty jakousi černou skříňkou: je nejasná, cena, výpadky systému, rizika a jak je zmírnit, a obecně je temná a děsivá. Je to jako, když to nevyjde, pak se hlavy budou kutálet jak nahoře, tak na účinkujících.
SAP je systém na podnikové úrovni, komplexní a mírně řečeno není levný. Na jejich implementaci, úpravu a údržbu se vynakládají slušné rozpočty a na jejich dostupnosti a správném provozu závisí životnost podniku. Nyní si představte důsledky zastavení nějaké velké výroby. Jde o finanční ztráty, které se dají spočítat jak v číslech s velkým počtem nul, tak o reputační a další neméně významná rizika.
Budeme analyzovat potíže, které mohou nastat v každé fázi v případě migrace systémů SAP od jednoho z našich zákazníků.
Příprava a návrh
Migrace je vzorec s mnoha různými částmi. A jednou z nejdůležitějších je fáze návrhu a přípravy cílové (nové) infrastruktury.
Potřebovali jsme se ponořit do stávající implementace systémů, jejich architektury. V cílové infrastruktuře jsme někde zopakovali stávající řešení, v některých bodech je doplnili a vylepšili, někde předělali, promysleli a vybírali řešení pro zajištění odolnosti a dostupnosti a také v maximální možné míře konsolidovali všechny zdroje.
Během procesu návrhu bylo provedeno mnoho různých cvičení, která v konečném důsledku umožnila co nejvíce se připravit na migraci a zohlednit nejrůznější nuance a úskalí (o nich později).
To, co jsme skončili, je individuálně navržená privátní cloudová infrastruktura založená na našem datovém centru:
- vyhrazené fyzické servery pro SAP HANA;
- Virtualizační platforma VMware pro aplikační servery a infrastrukturní služby;
- duplicitní komunikační kanály mezi datovými centry pro L2 VPN;
- dva hlavní skladovací systémy pro oddělení produktu a „všeho ostatního“;
- SRC založené na Veritas Netbackup se samostatným serverem, diskovou policí a páskovou knihovnou.
A tady je návod, jak jsme to všechno implementovali z technického hlediska.
SAP
- Abychom efektivně využili úložiště pro produktivní HANA, použili jsme sdílené disky bez systémové replikace databáze pomocí SAP. To vše bylo zabaleno do clusteru Active-Standby SUSE HAE založeného na Pacemaker. Ano, doba obnovy je o něco delší než u replikace, ale ušetříme úložný prostor o polovinu a v důsledku toho šetříme rozpočet zákazníka.
- V předprodukčních prostředích byly clustery HANA opuštěny, ale technicky se produkční konfigurace opakovala.
- Testovací a vývojová prostředí byla distribuována na několik dalších serverů bez clusterů v konfiguraci MCOS.
- Všechny aplikační servery byly virtualizovány a hostovány ve VMware.
Seti
- Fyzicky jsme oddělili obrysy řídicí a produkční sítě stohy přepínačů a ty produktivní jsme otočili směrem k datovým centrům zákazníka.
- Instalovali jsme dostatečné množství síťových rozhraní, abychom nesměšovali velké dopravní toky.
- Pro přenos dat z úložných systémů jsme vyrobili klasické továrny FC SAN.
SHD
- Produktivní a předproduktivní zátěž SAP byla ponechána na all-flash poli.
- Vývojářská testovací prostředí a infrastrukturní služby byly umístěny na samostatném hybridním poli.
IBS
- Vytvořeno pomocí Veritas Netbackup.
- Přidali jsme trochu k vestavěným skriptům pro zálohování konfigurací MCOS.
- Provozní kopie ukládáme na diskovou polici pro rychlou obnovu a pásky používáme k dlouhodobému skladování.
Sledování
- Veškerý hardware, OS a SAP byly nainstalovány pod Zabbixem.
- V Grafaně jsme shromáždili mnoho užitečných dashboardů.
- Když dojde k upozornění, Zabbix může vytvořit požadavek v systému správy incidentů; máme to implementováno na Jira. Informace jsou také duplikovány v kanálu Telegram.
Telegram
Celkový zdravotní stav HANA
Stav aplikačního serveru SAP:
Infrastrukturní služby
- Pro obsluhu interních jmenných prostorů byl vytvořen cluster serverů DNS, který je synchronizován se servery zákazníka.
- Vytvořili jsme samostatný souborový server pro výměnu dat.
- Pro ukládání různých konfigurací byl přidán Gitlab.
- Pro různé citlivé informace jsme vzali HashiCorp Vault.
Proces migrace
Obecně se proces migrace skládá z následujících fází:
- příprava veškeré potřebné projektové dokumentace;
- jednání se stávajícím poskytovatelem - řešení organizačních záležitostí;
- nákup, dodávka a instalace nového zařízení pro projekt;
- testovací migrace a ladění procesů;
- přenos systémů, boj s migrací.
Na konci října 2019 jsme podepsali smlouvu, následně navrhli architekturu a po dohodě se zákazníkem jsme objednali potřebné vybavení.
Na co si musíte dát pozor jako první, je dodací lhůta zařízení. Dodání certifikovaného hardwaru pro SAP NAHA, který splňuje požadavky výrobce softwaru na hardwarové platformy, trvá v průměru 10–12 týdnů. A s přihlédnutím k sezónnosti (realizace projektu připadla přesně na Nový rok) se toto období mohlo prodloužit o další měsíc. V souladu s tím bylo nutné proces co nejvíce urychlit: spolupracovali jsme s distributorem-dodavatelem a dohodli jsme se na urychleném dodání letadlem (místo pozemních a námořních cest).
Listopad a prosinec byly věnovány přípravě na migraci a příjmu části vybavení. Přípravu jsme prováděli na testovací stolici v našem veřejném cloudu, kde jsme propracovali všechny hlavní kroky a zachytili možné potíže a problémy:
- připravil podrobný plán interakce mezi členy projektového týmu s načasováním minutu po minutě;
- vybudoval testovací lavici pro databázové a aplikační servery přibližně stejným způsobem jako v cílové infrastruktuře;
- nakonfiguroval potřebné komunikační kanály a infrastrukturní služby pro testování provozu integrací;
- vypracované scénáře cutover;
- Cloud nám také pomohl vytvořit předkonfigurované šablony virtuálních strojů, které jsme pak jednoduše importovali a nasadili do cílového prostředí.
Krátce před novoročními svátky k nám dorazila první várka techniky. To umožnilo nasadit některé systémy na skutečný hardware. Protože ne vše dorazilo, připojili jsme náhradní zařízení, na jejichž dodávce se nám podařilo dohodnout s prodejcem a distributory. V konečné fázi jsme obdrželi zbytky cílové infrastruktury.
Aby naši inženýři dodrželi termín, museli obětovat novoroční svátky a začít pracovat na přípravě cílové infrastruktury 2. ledna, uprostřed prázdnin. Ano, to se někdy stává, když hoří a prostě nejsou žádné jiné možnosti. V sázce byl výkon systémů, na kterých závisí životnost podniku.
Obecné pořadí migrace vypadalo takto: nejprve nejméně kritické systémy (vývojové prostředí, testovací prostředí), poté produktivní systémy. Konečná fáze migrace proběhla koncem ledna a začátkem února.
Proces migrace byl naplánován na minutu. Jedná se o střihový plán se seznamem všech úkolů, časem dokončení a odpovědných osob. Všechny kroky již byly zpracovány v testovací migraci, takže v živé migraci bylo jen nutné dodržet plán a koordinovat proces.
Migrace probíhala systematicky v několika fázích. V každé fázi jsou dva systémy.
Výsledkem tříměsíčního sprintu byl systém, který je plně funkční v datovém centru CROC. Celkově bylo dosaženo pozitivního výsledku týmovou prací, přínos a obětavost všech účastníků procesu byla maximální.
Role zákazníka v projektu
Komunikace s poskytovatelem, od kterého náš klient odcházel, nebyla jednoduchá. Je to pochopitelné, byli poslední na seznamu zájemců o úspěšné dokončení projektu. Zákazník se ujal úkolu eskalovat a šlapat všechny komunikační problémy a vyrovnal se s tím na 100500 %. Za to mu patří zvláštní poděkování. Bez takové proveditelné účasti na procesu by výsledek projektu mohl být úplně jiný.
Vzhledem k formalizaci procesů na straně „bývalého“ poskytovatele byla podpora infrastruktury realizována specialisty, kteří byli k problémům doslova daleko, tehdy ještě jejich zákazníkem. Například proces exportu stejné databáze může trvat hodinu až pět. Pak se zdálo, že to byla nějaká magie, tajemství, které nám nikdy nebylo odhaleno. Nejspíš se inženýři technické podpory mezitím oddávali meditaci, zapomněli, že někde v dalekém Rusku jsou termíny, inženýři bez novoročních salátů, zákazník pláče a trpí...
Výsledky projektu
Posledním krokem migrace byl převod systémů pro údržbu.
Nyní poskytujeme službu jediného okna pro požadavky zákazníků a pokrýváme celý rozsah úkolů souvisejících s podpůrnými komponentami infrastruktury a základem SAP společně s naším partnerem – společností itelligence. Klient žije šest měsíců v privátním cloudu. Zde jsou statistiky servisních případů během této doby:
- 90 incidentů (20 % vyřešeno bez zapojení zákazníka)
- Vyřešeno v rámci SLA – 100 %
- Neplánovaná vypnutí systému – 0
Pokud máte podobné problémy jako náš klient a chcete se dozvědět více o tom, jak je řešit, napište na: [chráněno e-mailem]
Zdroj: www.habr.com