Ili je to moguće? Naravno, migracija SAP sistema je složen i mukotrpan proces, za čiji uspjeh je potreban dobro koordiniran rad svih učesnika. A ako se migracija izvrši u kratkom vremenu, zadatak postaje mnogo složeniji. Ne odlučuju se svi na ovo. Razloga može biti nekoliko. Na primjer, sam proces je dugotrajan i organizacijski složen. Osim toga, postoji rizik od neplaniranog zastoja sistema. Ili klijenti nisu sigurni da će, nakon što su prošli takvu operaciju, dobiti beneficije srazmjerne uloženim naporima. Međutim, postoje izuzeci.
U nastavku ćemo govoriti o poteškoćama s kojima se klijenti suočavaju u procesu migracije i održavanja SAP sistema, diskutovati zašto stereotipi ne odgovaraju uvijek stvarnosti i podijeliti studiju slučaja o tome kako smo uspjeli migrirati sisteme korisnika na nova infrastruktura za nešto više od tri mjeseca.
Hosting SAP sistema
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 implementirani su na licu mjesta. Međutim, s razvojem modela outsourcinga i tržišta usluga u oblaku, svjetonazor korisnika počeo se mijenjati. Koji su argumenti koji utiču na izbor u korist oblaka za SAP?
- Za početnike koji tek planiraju implementaciju SAP-a, infrastruktura oblaka je gotovo standardan izbor – skalabilnost resursa prema trenutnim potrebama sistema i nevoljkost da se resursi preusmjere na razvoj neosnovnih kompetencija.
- U kompanijama sa velikim sistemskim pejzažom, uz pomoć hosting SAP sistema, CIO-ovi dostižu kvalitativno drugačiji nivo upravljanja rizicima, 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 sisteme 2027. godine. To podrazumijeva prijenos baze podataka u HANA-u, što podrazumijeva troškove modernizacije i nabavke nove računarske snage.
Tržište SAP hostinga u Rusiji sada se može smatrati prilično zrelim. A ovo pruža široku priliku za korisnike koji žele promijeniti svoje hosting platforme. Međutim, takvi projekti s pravom mogu izazvati zabrinutost među preduzećima zbog složenosti procedure migracije. To tjera korisnike da postavljaju povećane zahtjeve pred pružaoce usluga, koji moraju imati ne samo izuzetne kompetencije u hostingu i održavanju SAP sistema, već i uspješno iskustvo u oblasti migracija.
Koje su poteškoće promjene SAP hostinga?
Hostingi su različiti. Neusklađenost sa deklariranim nivoom usluge, mnogo „ali“ i zvjezdica sa rezervacijama u malom tekstu, ograničeni resursi i mogućnosti hosting provajdera, nedostatak fleksibilnosti u pitanjima komunikacije sa klijentom, birokratija, tehnička ograničenja, niska kompetentnost tehničke podrške specijaliste, kao i mnoge druge nijanse - ovo je samo mali dio zamki na koje klijenti mogu naići kada upravljaju svojim poslovnim sistemima u infrastrukturi za eksternalizaciju. Često za klijenta sve to ostaje u sjeni, u džungli ugovora na više stranica, i pojavljuje se u procesu korištenja usluga.
U nekom trenutku, korisniku postaje očigledno da je nivo usluge koju dobija 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 nagomilaju do krajnjih granica i postane vrlo bolno, prelaze na aktivne akcije razvijanja alternativnih opcija u smjeru promjene pružaoca usluge. .
Zašto čekaju do posljednjeg trenutka? Razlog je jednostavan - proces migracije sistema 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 neka vrsta crne kutije: nejasno je, cijena, zastoji sistema, rizici i kako ih ublažiti, a općenito je mračno i zastrašujuće. To je kao, ako ne uspije, onda će se vrtjeti glave i na vrhu i na izvođačima.
SAP je sistem na nivou preduzeća, složen i, blago rečeno, nije jeftin. Na njihovu implementaciju, modifikaciju i održavanje troše se pristojni budžeti, a od njihove dostupnosti i ispravnog rada zavisi vek trajanja preduzeća. Sad zamislite posljedice zaustavljanja neke velike proizvodnje. To su finansijski gubici, koji se mogu izračunati u brojevima sa velikim brojem nula, kao i reputacioni i drugi podjednako značajni rizici.
Analiziraćemo poteškoće koje se mogu pojaviti u svakoj fazi u slučaju migracije SAP sistema od jednog od naših kupaca.
Priprema i dizajn
Migracija je formula sa mnogo različitih dijelova. A jedna od najvažnijih je faza projektovanja i pripreme ciljne (nove) infrastrukture.
Trebali smo zaroniti u postojeću implementaciju sistema, njihovu arhitekturu. U ciljnoj infrastrukturi smo negdje ponovili postojeća rješenja, dopunili ih i poboljšali u nekim tačkama, negdje ih preradili, promislili i odabrali rješenja kako bismo osigurali toleranciju kvarova i dostupnost, a isto tako maksimalno objedinili sve resurse.
U procesu dizajna izvedeno je mnogo različitih vježbi, koje su u konačnici omogućile da se što bolje pripremimo za migraciju i uzmu u obzir sve vrste nijansi i zamki (o njima kasnije).
Ono što smo na kraju dobili je individualno dizajnirana privatna cloud infrastruktura zasnovana na našem data centru:
- namjenski fizički serveri za SAP HANA;
- VMware virtualizacijska platforma za poslužitelje aplikacija i infrastrukturne usluge;
- duplirani komunikacijski kanali između podatkovnih centara za L2 VPN;
- dva glavna sistema skladištenja za odvajanje proizvoda i "svega ostalog";
- SRC baziran na Veritas Netbackup-u sa zasebnim serverom, diskovnom policom i bibliotekom traka.
A evo kako smo sve ovo implementirali sa tehničke tačke gledišta.
SAP
- Da bismo efikasno koristili skladište za produktivnu HANA, koristili smo dijeljene diskove bez sistemske replikacije baze podataka koristeći SAP. Sve je to bilo umotano u Active-Standby SUSE HAE klaster baziran na Pejsmejkeru. Da, vrijeme oporavka je malo duže nego kod replikacije, ali štedimo prostor za pohranu upola i, kao rezultat, štedimo budžet korisnika.
- U predprodukcijskim okruženjima, HANA klasteri su napušteni, ali je tehnički konfiguracija proizvodnje ponovljena.
- Testna i razvojna okruženja su distribuirana na još nekoliko servera bez klastera u MCOS konfiguraciji.
- Svi serveri aplikacija su virtuelizirani i hostovani u VMware-u.
Seti
- Fizički smo razdvojili konture kontrolne i proizvodne mreže stekovima prekidača, okrenuvši one produktivne prema podatkovnim centrima korisnika.
- Instalirali smo dovoljan broj mrežnih interfejsa kako ne bismo miješali velike prometne tokove.
- Za prenos podataka iz sistema za skladištenje, napravili smo klasične FC SAN fabrike.
SHD
- Produktivno i predproduktivno opterećenje SAP-a ostavljeno je na all-flash polju.
- Testna okruženja za programere i infrastrukturne usluge stavljene su na odvojeni hibridni niz.
IBS
- Napravljen pomoću Veritas Netbackup-a.
- Dodali smo malo ugrađenim skriptama za sigurnosnu kopiju MCOS konfiguracija.
- Radne kopije stavljamo na policu diska za brzi oporavak, a koristimo trake za dugotrajno skladištenje.
Monitoring
- Sav hardver, OS i SAP su instalirani pod Zabbixom.
- U Grafani smo prikupili mnogo korisnih nadzornih ploča.
- Kada se pojavi upozorenje, Zabbix može kreirati zahtjev u sistemu upravljanja incidentima; mi ga implementiramo u Jira. Informacije se dupliraju i na Telegram kanalu.
telegram
Opće zdravstveno stanje HANA
Status SAP aplikacijskog servera:
Infrastrukturne usluge
- Za servisiranje internih imenskih prostora, podignut je klaster DNS servera koji je sinhronizovan sa serverima korisnika.
- Napravili smo poseban fajl server za razmjenu podataka.
- Za pohranjivanje raznih konfiguracija, dodat je Gitlab.
- Za razne osjetljive informacije uzeli smo HashiCorp Vault.
Proces migracije
Općenito, proces migracije se sastoji od sljedećih faza:
- priprema sve potrebne projektne dokumentacije;
- pregovori sa aktuelnim provajderom - rješavanje organizacionih pitanja;
- nabavka, isporuka i montaža nove opreme za projekat;
- testiranje migracije i otklanjanje grešaka u procesu;
- prenos sistema, borbena migracija.
Krajem oktobra 2019. godine potpisali smo ugovor, zatim projektovali arhitekturu i nakon dogovora sa naručiocem naručili potrebnu opremu.
Ono na šta prvo treba da obratite pažnju je rok isporuke opreme. U prosjeku, isporuka certificiranog hardvera za SAP NAHA koji ispunjava zahtjeve proizvođača softvera za hardverske platforme traje 10-12 sedmica. A uzimajući u obzir sezonalnost (provedba projekta pala je tačno na Novu godinu), ovaj period se mogao povećati za još mjesec dana. Shodno tome, bilo je potrebno maksimalno ubrzati proces: radili smo sa distributerom-isporučiocem i dogovorili se o ubrzanoj isporuci avionom (umjesto kopnenim i morskim putem).
Novembar i decembar protekli su u pripremama za migraciju i dobijanju dijela opreme. Pripremu smo obavili na probnom stolu u našem javnom oblaku, gdje smo proradili sve glavne korake i uhvatili moguće poteškoće i probleme:
- pripremio detaljan plan interakcije između članova projektnog tima sa vremenskim rasporedom minuta po minut;
- izgradili test bench za bazu podataka i aplikacijske servere na približno isti način kao u ciljnoj infrastrukturi;
- konfigurisao potrebne komunikacione kanale i infrastrukturne usluge za testiranje rada integracija;
- razrađeni scenariji prekida;
- Oblak nam je takođe pomogao da kreiramo unapred konfigurisane šablone virtuelnih mašina, koje smo onda jednostavno uvezli i postavili na ciljni krajolik.
Neposredno pred novogodišnje praznike stigla nam je prva serija opreme. Ovo je omogućilo postavljanje nekih sistema na pravi hardver. Kako nije sve stiglo, priključili smo zamjensku opremu čiju nabavku smo uspjeli dogovoriti sa prodavcem i distributerima. Dobili smo ostatke ciljne infrastrukture u završnoj fazi.
Da bi ispoštovali rok, naši inženjeri su morali da žrtvuju novogodišnje praznike i da počnu radove na pripremi ciljne infrastrukture 2. januara, u jeku praznika. Da, to se ponekad dešava kada je u plamenu i jednostavno nema drugih opcija. U igri su bile performanse sistema od kojih zavisi život preduzeća.
Opšti redosled migracije izgledao je ovako: prvo, najmanje kritični sistemi (razvojni krajolik, krajolik za testiranje), zatim produktivni sistemi. Završna faza migracije dogodila se krajem januara i početkom februara.
Proces migracije je bio isplaniran do minute. Ovo je plan preseka sa listom svih zadataka, rokom završetka i odgovornim osobama. Svi koraci su već bili razrađeni u probnoj migraciji, tako da je u živoj migraciji bilo potrebno samo pratiti plan i koordinirati proces.
Migracija se odvijala sistematski u nekoliko faza. U svakoj fazi postoje dva sistema.
Rezultat tromjesečnog sprinta bio je sustav koji je u potpunosti operativan u CROC data centru. Generalno, timskim radom postignut je pozitivan rezultat, doprinos i posvećenost svih učesnika u procesu je bio maksimalan.
Uloga kupca u projektu
Komunikacija sa provajderom koji je naš klijent odlazio nije bila laka. To je i razumljivo, oni su bili posljednji na listi zainteresovanih za uspješan završetak projekta. Kupac je preuzeo zadatak eskaliranja i pedaliranja svih komunikacijskih problema i nosio se s tim 100500%. Posebno mu hvala na ovome. Bez tako izvodljivog učešća u procesu, rezultat projekta bi mogao biti potpuno drugačiji.
Zbog formalizacije procesa na strani „bivšeg“ provajdera, infrastrukturnu podršku su vršili stručnjaci koji su bukvalno bili daleko od problema, u to vrijeme još uvijek njihov korisnik. Na primjer, proces izvoza iste baze podataka može trajati od sat do pet. Tada se činilo da je to neka magija, tajna koja nam nikada nije otkrivena. Vjerovatno su se inženjeri tehničke podrške u međuvremenu prepustili meditaciji, zaboravljajući da negdje u dalekoj Rusiji postoje rokovi, inženjeri bez novogodišnjih salata, mušterija plače i pati...
Rezultati projekta
Završni korak migracije bio je transfer sistema za održavanje.
Sada pružamo uslugu jedinstvenog prozora za zahtjeve kupaca i pokrivamo cijeli niz zadataka koji se odnose na podršku komponentama infrastrukture i SAP bazi zajedno sa našim partnerom - itelligence. Klijent živi u privatnom oblaku šest mjeseci. Evo statistike o slučajevima usluga u ovom periodu:
- 90 incidenata (20% riješeno bez uključivanja kupca)
- Riješeno unutar SLA – 100%
- Neplanirana isključenja sistema – 0
Ako imate probleme slične onima našeg klijenta, a želite saznati više o tome kako ih riješiti, pišite na: [email zaštićen]
izvor: www.habr.com