Või on see võimalik? Loomulikult on SAP-süsteemide üleviimine keeruline ja vaevarikas protsess, mille õnnestumiseks on vaja kõikide osalejate hästi koordineeritud tööd. Ja kui migratsioon viiakse läbi lühikese aja jooksul, muutub ülesanne palju keerulisemaks. Mitte igaüks ei otsusta seda teha. Põhjuseid võib olla mitu. Näiteks protsess ise on pikk ja organisatsiooniliselt keeruline. Lisaks on oht süsteemi planeerimata seisakuteks. Või pole kliendid kindlad, et pärast sellise operatsiooni läbimist saavad nad tehtud jõupingutustele vastavat kasu. Siiski on erandeid.
Allpool räägime raskustest, millega kliendid SAP-süsteemide migreerimisel ja hooldamisel kokku puutuvad, arutame, miks stereotüübid alati tegelikkusele ei vasta, ja jagame juhtumiuuringut selle kohta, kuidas meil õnnestus kliendi süsteemid üle viia uus infrastruktuur veidi enam kui kolme kuuga.
SAP-süsteemide hostimine
Veel viis aastat tagasi oli raske ette kujutada, et kliendid hakkavad SAP-rakenduste jaoks massiliselt kasutama hostimisressursse. Enamikul juhtudel rakendati neid kohapeal. Allhankemudelite ja pilveteenuste turu arenedes hakkas aga klientide maailmapilt muutuma. Millised argumendid mõjutavad valikut SAP-i pilve kasuks?
- Algajatele, kes on äsja SAP juurutamist plaaninud, on pilveinfrastruktuur peaaegu standardvalik – ressursside skaleeritus süsteemi hetkevajadustele ning soovimatus suunata ressursse mittepõhikompetentside arendamisse.
- Suure süsteemimaastikuga ettevõtetes jõuavad CIO-d SAP-süsteemide hostimise abil kvalitatiivselt erinevale riskijuhtimise tasemele, kuna SLA eest vastutab partner.
- Kolmas levinum argument on infrastruktuuri ehitamise kõrge hind kõrge kättesaadavuse ja DR-stsenaariumide rakendamiseks.
- Factor 2027 – müüja teatas pärandsüsteemide toe lõpetamisest 2027. aastal. See tähendab andmebaasi ülekandmist HANA-sse, millega kaasnevad kulud moderniseerimiseks ja uue arvutusvõimsuse ostmiseks.
SAP-i hostimisturgu Venemaal võib nüüd pidada üsna küpseks. See pakub palju võimalusi klientidele, kes soovivad oma hostimisplatvorme muuta. Sellised projektid võivad aga rändemenetluse keerukuse tõttu ettevõtetes õigustatult muret tekitada. See sunnib kliente esitama kõrgendatud nõudmisi teenusepakkujatele, kellel peab olema lisaks erakordsetele kompetentsidele SAP-süsteemide hostimisel ja hooldamisel ka edukas migratsioonialane kogemus.
Millised on SAP-hostimise muutmise raskused?
Hostingid on erinevad. Mittevastavus deklareeritud teenusetasemega, palju "agasid" ja tärnike koos reservatsioonidega väikeses tekstis, piiratud ressursid ja hostiteenuse pakkuja võimalused, paindlikkuse puudumine kliendiga suhtlemisel, bürokraatia, tehnilised piirangud, tehnilise toe madal pädevus spetsialistid, aga ka palju muid nüansse – need on See on vaid väike osa lõksudest, millega kliendid võivad kokku puutuda oma ärisüsteemide haldamisel infrastruktuuride sisseostmisel. Tihti jääb see kõik kliendi jaoks varju, mitmeleheküljelise lepingu džunglisse ja ilmneb teenuste kasutamise käigus.
Ühel hetkel saab kliendile selgeks, et teenuse tase, mida ta saab, on kaugel tema ootustest. See on omamoodi katalüsaator olukorra parandamiseks lahenduste leidmisel ja ebaõnnestumise korral, kui probleemid kuhjuvad viimse piirini ja see muutub väga valusaks, liigutakse edasi aktiivsele tegevusele alternatiivsete võimaluste väljatöötamiseks teenusepakkuja vahetamise suunas. .
Miks nad ootavad viimase hetkeni? Põhjus on lihtne – klientide jaoks süsteemide migratsiooniprotsess ei ole alati läbipaistev ja arusaadav. Kliendil on raske hinnata migratsiooniprotsessiga kaasnevaid tegelikke riske. Võib öelda, et klientide jaoks on migratsioon omamoodi must kast: on ebaselge, hind, süsteemi seisakud, riskid ja kuidas neid maandada ning üldiselt on see pime ja hirmutav. See on nii, et kui ei õnnestu, siis käivad pead nii üleval kui esinejatel.
SAP on ettevõtte tasemel süsteem, keeruline ja pehmelt öeldes mitte odav. Nende rakendamiseks, muutmiseks ja hooldamiseks kulutatakse korralikke eelarveid ning nende olemasolust ja korrektsest toimimisest sõltub ettevõtte eluiga. Kujutage nüüd ette, millised tagajärjed võivad olla mõne suure tootmise peatamisel. Need on rahalised kahjud, mida saab arvudes arvutada suure arvu nullidega, aga ka maine- ja muud samaväärsed riskid.
Analüüsime raskusi, mis võivad tekkida igas etapis SAP-süsteemide migreerimisel ühelt meie kliendilt.
Ettevalmistus ja kujundus
Ränne on valem, mis koosneb paljudest erinevatest osadest. Ja üks olulisemaid on sihtotstarbelise (uue) infrastruktuuri projekteerimise ja ettevalmistamise etapp.
Tuli sukelduda süsteemide olemasolevasse juurutusse, nende arhitektuuri. Sihttaristus kordasime kuskil olemasolevaid lahendusi, mõnes punktis täiendasime ja täiustasime, kuskil tegime ümber, mõtlesime läbi ja valisime lahendused, et tagada tõrketaluvus ja käideldavus ning koondasime ka kõik ressursid nii palju kui võimalik.
Projekteerimise käigus tehti palju erinevaid harjutusi, mis lõppkokkuvõttes võimaldasid võimalikult palju migratsiooniks valmistuda ning kõikvõimalike nüansside ja lõksudega arvestada (neist pikemalt hiljem).
Lõppkokkuvõttes saime meie andmekeskusel põhineva individuaalselt kujundatud privaatse pilve infrastruktuuri:
- spetsiaalsed füüsilised serverid SAP HANA jaoks;
- VMware virtualiseerimisplatvorm rakendusserverite ja infrastruktuuriteenuste jaoks;
- dubleeritud sidekanalid andmekeskuste vahel L2 VPN jaoks;
- kaks peamist salvestussüsteemi toote ja "kõige muu" eraldamiseks;
- Veritas Netbackupil põhinev SRC koos eraldi serveri, kettariiuli ja lindikoguga.
Ja siin on see, kuidas me seda kõike tehnilisest vaatenurgast rakendasime.
SAP
- Tootliku HANA jaoks salvestusruumi tõhusaks kasutamiseks kasutasime jagatud kettaid ilma süsteemse andmebaasi replikatsioonita SAP-i abil. Kõik see oli ümbritsetud südamestimulaatoril põhineva aktiivse ooterežiimi SUSE HAE klastriga. Jah, taastumisaeg on veidi pikem kui replikatsiooni puhul, kuid säästame salvestusruumi poole võrra ja säästame seeläbi kliendi eelarvet.
- Tootmiseelsetes keskkondades HANA klastritest loobuti, kuid tehniliselt korrati tootmiskonfiguratsiooni.
- Testimis- ja arenduskeskkonnad jaotati veel mitme serveri vahel ilma klastriteta MCOS-i konfiguratsioonis.
- Kõik rakendusserverid virtualiseeriti ja hostiti VMware'is.
Võrgud
- Eraldasime juhtimis- ja tootmisvõrkude kontuurid füüsiliselt lülitite virnadega, suunates produktiivsed kliendi andmekeskuste poole.
- Paigaldasime piisava arvu võrguliideseid, et mitte segada suuri liiklusvooge.
- Andmete ülekandmiseks salvestussüsteemidest tegime klassikalised FC SAN-i tehased.
SHD
- SAP-i produktiivne ja tootmiseelne koormus jäeti täisvälkmassiivile.
- Arendajate testkeskkonnad ja infrastruktuuriteenused paigutati eraldi hübriidmassiivi.
IBS
- Valmistatud Veritas Netbackupi abil.
- MCOS-i konfiguratsioonide varundamiseks lisasime veidi sisseehitatud skriptidele.
- Kiireks taastamiseks paneme töökoopiad kettariiulile ja pikaajaliseks säilitamiseks kasutame linte.
Jälgimine
- Zabbixi alla installiti kogu riistvara, OS ja SAP.
- Oleme Grafanasse kogunud palju kasulikke armatuurlaudu.
- Hoiatuse ilmnemisel saab Zabbix luua päringu juhtumihaldussüsteemis; oleme selle Jiras juurutanud. Teave dubleeritakse ka Telegrami kanalis.
Telegramm
HANA üldine tervis
SAP-i rakendusserveri olek:
Infrastruktuuriteenused
- Sisemiste nimeruumide teenindamiseks loodi DNS-serverite klaster, mis sünkroonitakse kliendi serveritega.
- Andmevahetuseks lõime eraldi failiserveri.
- Erinevate konfiguratsioonide salvestamiseks lisati Gitlab.
- Erineva tundliku teabe saamiseks kasutasime HashiCorp Vaulti.
Migratsiooniprotsess
Üldiselt koosneb migratsiooniprotsess järgmistest etappidest:
- kogu vajaliku projektdokumentatsiooni koostamine;
- läbirääkimised senise pakkujaga - korralduslike küsimuste lahendamine;
- projekti jaoks uute seadmete ostmine, tarnimine ja paigaldamine;
- migratsiooni testimine ja protsesside silumine;
- süsteemide ülekandmine, võitlus migratsiooniga.
2019. aasta oktoobri lõpus sõlmisime lepingu, seejärel projekteerisime arhitektuuri ning pärast kliendiga kokkuleppimist tellisime vajalikud seadmed.
Kõigepealt peate tähelepanu pöörama seadmete tarneajale. Keskmiselt võtab SAP NAHA sertifitseeritud riistvara tarnimine, mis vastab tarkvaratootja riistvaraplatvormide nõuetele, 10-12 nädalat. Ja võttes arvesse hooajalisust (projekti elluviimine langes täpselt aastavahetusele), oleks see periood võinud veel kuu võrra pikeneda. Sellest lähtuvalt oli vaja protsessi nii palju kui võimalik kiirendada: tegime koostööd turustaja-tarnijaga ja leppisime kokku kiires kohaletoimetamises lennukiga (maismaa- ja mereteede asemel).
November ja detsember möödusid rändeks valmistumisel ja osa varustuse vastuvõtmisel. Ettevalmistuse viisime läbi meie avalikus pilves asuval katsestendil, kus töötasime läbi kõik põhietapid ning tabasime võimalikud raskused ja probleemid:
- koostas projektimeeskonna liikmete vahelise suhtluse üksikasjaliku plaani minuti kaupa;
- ehitas andmebaasi ja rakendusserverite katsestendi ligikaudu samamoodi nagu sihtinfrastruktuuris;
- konfigureeris integratsioonide toimimise testimiseks vajalikud sidekanalid ja infrastruktuuriteenused;
- töötasid välja lõikestsenaariumid;
- Pilv aitas meil luua ka eelkonfigureeritud virtuaalmasina malle, mille me seejärel lihtsalt importisime ja sihtmaastikule juurutasime.
Veidi enne uusaastapühi jõudis meieni esimene partii varustust. See võimaldas mõningaid süsteeme juurutada päris riistvarale. Kuna kõike ei jõudnud, ühendasime asendusseadmed, mille tarnimine õnnestus müüja ja edasimüüjatega kokku leppida. Lõppfaasis saime sihttaristu jäänused kätte.
Tähtajast kinnipidamiseks pidid meie insenerid ohverdama uusaastapühad ja alustama tööd sihttaristu ettevalmistamisega 2. jaanuaril keset pühi. Jah, see juhtub mõnikord siis, kui see põleb ja muid võimalusi lihtsalt pole. Kaalul oli nende süsteemide toimivus, millest sõltub ettevõtte eluiga.
Rände üldine järjekord nägi välja selline: esiteks kõige vähem kriitilised süsteemid (arengumaastik, testimismaastik), seejärel tootlikud süsteemid. Rände viimane etapp toimus jaanuari lõpus ja veebruari alguses.
Migratsiooniprotsess oli hetkeni planeeritud. See on läbilõikeplaan koos kõigi ülesannete, täitmise aja ja vastutavate isikute loeteluga. Testmigratsioonis olid kõik sammud juba läbi töötatud, nii et reaalajas migratsioonis tuli lihtsalt plaani järgida ja protsessi koordineerida.
Ränne viidi läbi süstemaatiliselt mitmes etapis. Igas etapis on kaks süsteemi.
Kolmekuulise sprindi tulemuseks oli süsteem, mis on CROC andmekeskuses täielikult töökorras. Üldiselt saavutati meeskonnatööga positiivne tulemus, kõigi protsessis osalejate panus ja pühendumus oli maksimaalne.
Tellija roll projektis
Suhtlemine teenusepakkujaga, kelle klient lahkus, ei olnud lihtne. See on arusaadav, nad olid projekti edukast lõpuleviimisest huvitatud inimeste nimekirjas viimased. Klient võttis enda peale ülesande eskaleerida ja pedaalida kõik sideprobleemid ning sai sellega 100500% hakkama. Eriline tänu talle selle eest. Ilma sellise teostatava protsessis osalemiseta oleks projekti tulemus võinud olla hoopis teistsugune.
Seoses protsesside vormistamisega “endise” pakkuja poolel tegelesid infrastruktuuri toega spetsialistid, kes olid sõna otseses mõttes probleemidest kaugel, tol ajal veel nende klient. Näiteks võib sama andmebaasi eksportimine kesta tunnist viieni. Siis tundus, et see on mingi maagia, saladus, mida meile kunagi ei avaldatud. Küllap andsid tehnilise toe insenerid vahepeal meditatsiooni, unustades, et kuskil kaugel Venemaal on tähtajad, insenerid ilma uusaasta salatiteta, klient nutab ja kannatab...
Projekti tulemused
Migratsiooni viimane etapp oli süsteemide üleandmine hoolduseks.
Nüüd pakume ühe akna teenust klientide soovidele ja katame koos oma partneriga - itelligence'iga kogu infrastruktuuri komponentide toetamise ja SAP-i baasiga seotud ülesanded. Klient on kuus kuud elanud privaatpilves. Siin on selle aja teenindusjuhtumite statistika:
- 90 intsidenti (20% lahendati ilma klienti kaasamata)
- SLA raames lahendatud – 100%
- Süsteemi plaanivälised väljalülitused – 0
Kui teil on meie kliendiga sarnaseid probleeme ja soovite nende lahendamise kohta lisateavet, kirjutage aadressile: [meiliga kaitstud]
Allikas: www.habr.com