🥇Iskustvo promjene SAP hostinga: kako migrirati sustave tako da to ne bude nesnosno bolno

Ili je moguće? Naravno, migracija SAP sustava je složen i mukotrpan proces, za čiji uspjeh je potreban dobro koordiniran rad svih sudionika. A ako se migracija provede u kratkom vremenu, zadatak postaje znatno kompliciraniji. Ne odlučuju se svi na ovo. Može postojati nekoliko razloga. Primjerice, sam proces je dugotrajan i organizacijski složen. Osim toga, postoji rizik od neplaniranog prekida rada sustava. Ili klijenti nisu sigurni da će nakon takve operacije dobiti koristi razmjerne uloženom trudu. Međutim, postoje iznimke.

U nastavku ćemo govoriti o poteškoćama s kojima se korisnici susreću u procesu migracije i održavanja SAP sustava, razgovarati o tome zašto stereotipi ne odgovaraju uvijek stvarnosti i podijeliti studiju slučaja o tome kako smo uspjeli migrirati sustave korisnika na nove infrastrukture za nešto više od tri mjeseca.

Hosting SAP sustava

Prije samo pet godina bilo je teško zamisliti da će klijenti masovno početi koristiti hosting resurse za SAP aplikacije. U većini slučajeva bili su implementirani na mjestu. Međutim, s razvojem modela outsourcinga i tržišta usluga u oblaku, svjetonazor kupaca počeo se mijenjati. Koji su argumenti koji utječu na izbor u korist oblaka za SAP?

Za početnike koji su tek planirali implementirati SAP, cloud infrastruktura je gotovo standardni izbor – skalabilnost resursa na trenutne potrebe sustava i nevoljkost preusmjeravanja resursa u razvoj non-core kompetencija.
U tvrtkama s velikim sistemskim krajolikom, uz pomoć hostinga SAP sustava, CIO-ovi postižu kvalitativno drugačiju razinu upravljanja rizikom, jer Partner je odgovoran za SLA.
Treći najčešći argument je visoka cijena izgradnje infrastrukture za implementaciju scenarija visoke dostupnosti i DR.
Faktor 2027. – dobavljač je najavio kraj podrške za naslijeđene sustave 2027. godine. To podrazumijeva prijenos baze podataka u HANA-u, što podrazumijeva troškove modernizacije i nabave nove računalne snage.

Tržište SAP hostinga u Rusiji sada se može smatrati prilično zrelim. A to pruža brojne mogućnosti za korisnike koji žele promijeniti svoje hosting platforme. Međutim, takvi projekti s pravom mogu izazvati zabrinutost kod poduzeća zbog složenosti postupka migracije. To tjera kupce da postavljaju veće zahtjeve pred pružatelje usluga, koji moraju imati ne samo iznimne kompetencije u hostingu i održavanju SAP sustava, već i uspješno iskustvo u području migracije.

Koje su poteškoće promjene SAP hostinga?

Usluge hostinga se razlikuju. Možda ne zadovoljavaju navedenu razinu usluge, imaju brojne "ali" i zvjezdice s odricanjima od odgovornosti napisanim sitnim slovima te imaju ograničene resurse i mogućnosti. pružatelj hostingaNefleksibilnost u komunikaciji s klijentima, birokracija, tehnička ograničenja, loša tehnička podrška i mnoge druge nijanse - to su samo neke od zamki s kojima se klijenti mogu susresti prilikom upravljanja svojim poslovnim sustavima u outsourcing infrastrukturama. Često ti problemi ostaju skriveni od klijenta, zakopani u ugovoru na više stranica i pojavljuju se tek tijekom stvarnog korištenja usluga.

U jednom trenutku korisniku postaje očito da je razina usluge koju dobiva daleko od njegovih očekivanja. Ovo je svojevrsni katalizator za pronalaženje rješenja za ispravljanje situacije i, u slučaju neuspjeha, kada se problemi nakupljaju do krajnjih granica i postanu vrlo bolni, prelaze na aktivne akcije za razvoj alternativnih opcija u smjeru promjene pružatelja usluga. .

Zašto čekaju zadnji čas? Razlog je jednostavan - proces migracije sustava za klijente nije uvijek transparentan i razumljiv. Klijentu je teško procijeniti stvarne rizike povezane s procesom migracije. Možemo reći da je migracija za klijente svojevrsna crna kutija: nejasna je cijena, zastoj sustava, rizici i kako ih ublažiti, a općenito je mračna i zastrašujuća. Kao, ako ne uspije, onda će se glave kotrljati i na vrhu i na izvođačima.

SAP je sustav na razini poduzeća, složen i, blago rečeno, nimalo jeftin. Na njihovu implementaciju, modifikaciju i održavanje troše se pristojni proračuni, a život poduzeća ovisi o njihovoj dostupnosti i ispravnom radu. Sada zamislite posljedice zaustavljanja neke velike proizvodnje. To su financijski gubici, koji se mogu izračunati u brojkama s velikim brojem nula, kao i reputacijski i drugi jednako značajni rizici.

Analizirat ćemo poteškoće koje se mogu pojaviti u svakoj fazi u slučaju migracije SAP sustava od jednog od naših kupaca.

Priprema i dizajn

Migracija je formula s mnogo različitih dijelova. A jedna od najvažnijih je faza projektiranja i pripreme ciljane (nove) infrastrukture.

Morali smo zaroniti u postojeću implementaciju sustava, njihovu arhitekturu. U ciljanoj infrastrukturi negdje smo ponovili postojeća rješenja, u nekim točkama ih dopunili i poboljšali, negdje preradili, promišljali i odabirali rješenja kako bismo osigurali toleranciju na greške i dostupnost, te maksimalno konsolidirali sve resurse.

Tijekom procesa dizajna izvedeno je mnogo različitih vježbi, što je u konačnici omogućilo da se što je više moguće pripremi za migraciju i uzme u obzir sve vrste nijansi i zamki (više o njima kasnije).

Ono što smo dobili je individualno dizajnirana infrastruktura privatnog oblaka temeljena na našem podatkovnom centru:

namjenski fizički poslužitelji za SAP HANA;
VMware virtualizacijska platforma za aplikacijske poslužitelje i infrastrukturne usluge;
duplicirani komunikacijski kanali između podatkovnih centara za L2 VPN;
dva glavna skladišna sustava za odvajanje proizvoda i "svega ostalog";
SRC temeljen na Veritas Netbackupu s zasebnim poslužiteljem, policom diska i bibliotekom traka.

A evo kako smo sve to implementirali s tehničke strane.

SAP

Kako bismo učinkovito koristili pohranu za produktivnu HANA, koristili smo zajedničke diskove bez sistemske replikacije baze podataka pomoću SAP-a. Sve je to bilo umotano u Active-Standby SUSE HAE klaster temeljen na Pacemakeru. Da, vrijeme oporavka je malo dulje nego kod replikacije, ali upola štedimo prostor za pohranu i, kao rezultat toga, štedimo proračun korisnika.
U pretprodukcijskim okruženjima HANA klasteri su napušteni, ali je tehnički konfiguracija proizvodnje ponovljena.
Testna i razvojna okruženja raspodijeljena su na još nekoliko poslužitelja bez klastera u MCOS konfiguraciji.
Svi aplikacijski poslužitelji bili su virtualizirani i hostirani u VMware-u.

Сети

Fizički smo odvojili obrise kontrolne i proizvodne mreže hrpom preklopnika, okrećući one produktivne prema podatkovnim centrima korisnika.
Instalirali smo dovoljan broj mrežnih sučelja kako ne bismo miješali velike tokove prometa.
Za prijenos podataka iz sustava za pohranu napravili smo klasične FC SAN tvornice.

SHD

Produktivno i predproizvodno opterećenje SAP-a ostavljeno je na all-flash polju.
Testna okruženja za razvojne programere i infrastrukturne usluge smještene su na zasebno hibridno polje.

IBS

Izrađen pomoću Veritas Netbackupa.
Dodali smo nešto ugrađenim skriptama za sigurnosno kopiranje MCOS konfiguracija.
Operativne kopije stavljamo na policu diska za brzi oporavak, a trake koristimo za dugotrajnu pohranu.

nadgledanje

Sav hardver, OS i SAP instalirani su pod Zabbixom.
Prikupili smo mnogo korisnih nadzornih ploča u Grafani.
Kada se pojavi upozorenje, Zabbix može kreirati zahtjev u sustavu upravljanja incidentima; mi smo to implementirali na Jiri. Informacije su duplicirane i na Telegram kanalu.

Opće zdravstveno stanje HANA

Status SAP aplikacijskog poslužitelja:

Infrastrukturne usluge

Za servisiranje internih imenskih prostora podignut je klaster DNS poslužitelja koji je sinkroniziran s poslužiteljima korisnika.
Napravili smo zaseban datotečni poslužitelj za razmjenu podataka.
Za pohranu raznih konfiguracija dodan je Gitlab.
Za razne osjetljive informacije uzeli smo HashiCorp Vault.

Proces migracije

Općenito, proces migracije sastoji se od sljedećih faza:

izrada sve potrebne projektne dokumentacije;
pregovori s trenutnim pružateljem - rješavanje organizacijskih pitanja;
kupnja, isporuka i ugradnja nove opreme za projekt;
testiranje migracije i otklanjanje pogrešaka procesa;
prijenos sustava, borbena migracija.

Krajem listopada 2019. godine potpisali smo ugovor, potom izradili arhitekturu, te nakon dogovora s kupcem naručili potrebnu opremu.

Ono na što prvo morate obratiti pozornost je rok isporuke opreme. U prosjeku, isporuka certificiranog hardvera za SAP NAHA koji zadovoljava zahtjeve proizvođača softvera za hardverske platforme traje 10-12 tjedana. A uzimajući u obzir sezonalnost (provedba projekta pala je točno na Novu godinu), ovo se razdoblje moglo povećati za još jedan mjesec. Sukladno tome, bilo je potrebno maksimalno ubrzati proces: radili smo s distributerom-dobavljačem i dogovorili ubrzanu isporuku avionom (umjesto kopnenim i pomorskim putovima).

Studeni i prosinac protekli su u pripremama za selidbu i preuzimanju dijela opreme. Pripremu smo proveli na testnom stolu u našem javnom oblaku, gdje smo obradili sve glavne korake i uhvatili moguće poteškoće i probleme:

pripremio detaljan plan interakcije između članova projektnog tima s vremenskim rasporedima iz minute u minutu;
izgradio testni stol za bazu podataka i aplikacijske poslužitelje na približno isti način kao u ciljnoj infrastrukturi;
konfigurirao potrebne komunikacijske kanale i infrastrukturne usluge za testiranje rada integracija;
razrađeni scenariji prekida;
Oblak nam je također pomogao stvoriti unaprijed konfigurirane predloške virtualnih strojeva, koje smo zatim jednostavno uvezli i implementirali u ciljno okruženje.

Neposredno prije novogodišnjih praznika stigla nam je prva serija opreme. To je omogućilo postavljanje nekih sustava na pravi hardver. Kako nije sve stiglo, priključili smo zamjensku opremu čiju smo nabavku uspjeli dogovoriti s dobavljačem i distributerima. Dobili smo ostatke ciljne infrastrukture u završnoj fazi.
Da bi ispoštovali rok, naši su inženjeri morali žrtvovati novogodišnje praznike i započeti radove na pripremi ciljne infrastrukture 2. siječnja, u jeku praznika. Da, to se ponekad događa kada gori i jednostavno nema drugih opcija. U pitanju je bila izvedba sustava o kojima ovisi život poduzeća.

Opći redoslijed migracije izgledao je ovako: prvo najmanje kritični sustavi (razvojno područje, područje testiranja), zatim produktivni sustavi. Završna faza migracije dogodila se krajem siječnja i početkom veljače.

Proces migracije isplaniran je do minute. Ovo je plan presjeka s popisom svih zadataka, vremenom izvršenja i odgovornim osobama. Svi su koraci već bili razrađeni u testnoj migraciji, tako da je u live migraciji bilo potrebno samo slijediti plan i koordinirati proces.

Migracija se provodila sustavno u nekoliko faza. Postoje dva sustava u svakoj fazi.

Rezultat tromjesečnog sprinta bio je sustav koji je u potpunosti operativan u podatkovnom centru CROC-a. Općenito, timskim radom postignut je pozitivan rezultat, doprinos i predanost svih sudionika u procesu bili su maksimalni.

Uloga kupca u projektu

Komunikacija s ponuđačem kojeg je naš klijent napuštao nije bila laka. To je i razumljivo, oni su bili zadnji na listi zainteresiranih za uspješan završetak projekta. Kupac je preuzeo zadatak eskalacije i pedaliranja svih komunikacijskih problema i nosio se s tim 100500%. Posebno mu hvala na tome. Bez takvog izvedivog sudjelovanja u procesu rezultat projekta mogao je biti potpuno drugačiji.

Zbog formalizacije procesa na strani “bivšeg” pružatelja, infrastrukturnu podršku su provodili stručnjaci koji su doslovno bili daleko od problema, u to vrijeme još uvijek njihov korisnik. Na primjer, proces izvoza iste baze podataka mogao bi trajati od jednog do pet sati. Tada se činilo da je to nekakva magija, tajna koja nam nikad nije otkrivena. Vjerojatno su se inženjeri tehničke podrške u međuvremenu prepustili meditaciji, zaboravivši da negdje u dalekoj Rusiji postoje rokovi, inženjeri bez novogodišnjih salata, kupac plače i pati...

Rezultati projekta

Posljednji korak migracije bio je prijenos sustava na održavanje.

Sada pružamo uslugu jedinstvenog prozora za zahtjeve korisnika i pokrivamo cijeli opseg zadataka vezanih uz prateće infrastrukturne komponente i SAP bazu zajedno s našim partnerom - itelligence. Klijent već šest mjeseci živi u privatnom oblaku. Evo statističkih podataka o servisnim slučajevima za to vrijeme: