🥇SAP-i hostimise muutmise kogemus: kuidas migreerida süsteeme, et see ei oleks valus

Või on see võimalik? Loomulikult on SAP-süsteemide migratsioon keeruline ja aeganõudev protsess, mille edu sõltub kõikide osaliste koostööst. Kuid kui migratsioon toimub lühikese aja jooksul, muutub ülesanne märkimisväärselt keerulisemaks. Mitmed ei julge sellega tegeleda. Põhjuseid võib olla mitmeid. Näiteks on protsess iseenesest ajamahukas ja organisatoorselt keeruline. Lisaks on olemas risk planeerimata süsteemi seiskumiseks. Või ei ole kliendid kindlad, et pärast sellist operatsiooni saavad nad kasu, mis oleks proportsionaalne kulutatud jõupingutustega. Siiski võivad olla ka erandid.

Allpool räägime raskustest, millega tellijad silmitsi seisavad SAP-süsteemide migratsiooni ja hooldamise protsessis, arutame, miks stereotüübid ei vasta alati tegelikkusele, ja jagame juhtumit, kuidas me suutsime tellija süsteemid uude infrastruktuuri migreerida vähem kui kolme ja poole kuuga.

SAP-süsteemide hostimine

Veel viis aastat tagasi oleks olnud raske ette kujutada, et kliendid hakkavad massiliselt kasutama hostimise ressursse SAP-rakenduste jaoks. Enamasti rakendati neid kohapeal (on-premise). Kuid koos outsourcingu mudelite ja pilveteenuste turu arenguga on tellijate maailmavaade hakanud muutuma. Millised on argumendid, mis mõjutavad valikut pilve suunas SAP jaoks?

Uustulnukate jaoks, kes alles plaanivad SAP-i rakendamist, on pilveinfrastruktuur praktiliselt standardne valik – süsteemi praeguste vajadustega skaleeritavad ressursid ja soov mitte suunata ressursse mitteprofitioskuste arendamisele.
Suure süsteemimaastikuga ettevõtetes võimaldab SAP-süsteemide hostimine CIO-l jõuda kvaliteetselt uuele riskihalduse tasemele, kuna SLA eest vastutab partner.
Kolmas kõige sagedamini esinev argument on kõrge infrastruktuuri rajamise hind, et rakendada kõrge kättesaadavuse ja DR stsenaariume.
Faktori 2027 – tootja poolt välja kuulutatud vananenud süsteemide toe lõpetamine 2027. aastal. See tähendab andmebaasi üleminekut HANA-le, mis toob kaasa kulutused moderniseerimisele ja uute arvutusvõimsuste hankimisele.

SAP-hosteeri turg Venemaal on praegu piisavalt küps. See pakub laialdasi võimalusi klientidele, kes soovivad oma hostimisplatvorme muuta. Kuid sellised projektid võivad õigustatult tekitada äriühingute seas muresid migratsiooniprotsessi keerukuse tõttu. See sunnib tellijaid esitama kõrgendatud nõudmisi teenusepakkujatele, kes peavad omama mitte ainult suurepäraseid teadmisi SAP-i hostimise ja süsteemide toetamise kohta, vaid ka edukat kogemust migratsioonivaldkonnas.

Millised on SAP-hosteeri vahetuse raskused?

Hostimise tüübid on erinevad. Teenuse taseme mittevastavus, palju 'aga' ja tähega tingimusi peene tekstiga, piiratud ressursid ja võimalused hostimise teenusepakkuja, suhtlemise küsimustes paindlikkuse puudumine kliendiga, bürokraatia, tehnilised piirangud, tehnilise toe spetsialistide madal kompetentsus ning paljusid muid nüansse — see on vaid väike osa varjatud lõksudest, millega kliendid võivad kokku puutuda oma äritesüsteemide kasutamisel outsourced-infrastruktuurides. Sageli jääb kõik see kliendile varjatuks, paljusõnalise lepingu sügaval ja mõistetamatul pinnal, ning tuleb esile juba teenuste kasutamise protsessis.

Kuidagi muutub tellijale selgeks, et teenustase, mida ta saab, on kaugel tema ootustest. See on mingi katalüsaator, et otsida lahendusi olukorra parandamiseks ja juhul, kui see ei õnnestu, kui probleemid kuhjuvad viimase piirini ja tekib tõsine valu, hakatakse aktiivselt otsima alternatiivseid teenusepakkujaid.

Miks venitatakse viimase minutini? Põhjus on lihtne — süsteemide üleviimise protsess ei ole alati klientidele läbipaistev ja arusaadav. Kliendil on keeruline hinnata tõelisi riske, mis on seotud migratsiooniprotsessiga. Võib öelda, et migratsioon klientide jaoks on omamoodi must kast: ei ole selge hind, süsteemide seismise aeg, riskid ja kuidas neid minimeerida ning üldiselt on kõik hämar ja hirmutav. Asja on nii, et kui ei õnnestu, siis lendavad pead nii tippspetsialistidelt kui ka teostajatelt.

SAP on ettevõtte tasemel süsteem, mis on keeruline ja öeldes otse, mitte just odav. Nende rakendamine, ümberkujundamine ja toetamine nõuab muljetavaldavaid eelarveid ning nende kergesti kergesti kergesti kergesti sain ja õige toimimine sõltub ettevõtte elujõudest. Kujutage nüüd ette, millised on tagajärjed mõne suurt tootmist peatades. Need on rahalised kaotused, mis võivad ulatuda numbritesse, kus on palju nullide chercher, samuti maine ja muud, mitte vähem olulised riskid.

Vaadake keerukusi, mis võivad ilmneda igas etapis SAP-süsteemide migratsiooni juhtumi näitel ühelt meie kliendilt.

Ettevalmistamine ja projekteerimine

Migratsioon on valem, mis koosneb paljusid erinevaid komponente. Ja ühe tähtsama ettevalmistuse etapi on uue (siht) infrastruktuuri projekteerimine ja ettevalmistamine.

Me pidime süüvima olemasolevatesse süsteemidesse ja nende arhitektuuri. Sihtinfra struktuuris kordasime kohati olemasolevaid lahendusi, mõnes punktis täiendasime ja parandasime, ning kusagil ümber tegime, mõtlesime ja valisime lahendusi, et tagada talitlushäire ja kergesti kergesti kergesti kergesti ning me konsolideerimisele kõiki ressursse.

Projedeerimisprotsessi käigus tehti palju erinevaid harjutusi, mis lõppkokkuvõttes võimaldasid maksimaalselt ette valmistuda migratsiooniks ja arvestada kõiki võimalikke nüansse ja alammõjusid (sellest hiljem).

Mida meie tulemuseks saime, on individuaalselt projekteeritud erasektori pilve infrastruktuur, mis põhineb meie andmekeskusel:

dedikeeritud füüsilised serverid SAP HANA jaoks;
virtuaalitamise platvorm VMware rakenduste ja infrastruktuuri teenuste jaoks;
dubleeritud ühenduste kanalid andmekeskuste vahel L2 jaoks; VPN;
kaks peamist andmesalvestust, et eraldada tootmine ja "kõik muu";
Veritase Netbackup põhinev andmevaru, millel on eraldi server, ketaspink ja lindikoguja.

Ja see, kuidas me seda kõike tehniliselt ellu viisime.

SAP

Tõhusaks HANA toodete salvestamiseks kasutasime ühiseid kettaid ilma SAP andmebaasi süsteemsete replikatsioonideta. Kõik on pakitud Active-Standby klastrisse SUSE HAE Pacemakeri alusel. Jah, taastumisaeg on mõnevõrra pikem kui replikatsiooni korral, kuid saame andmesalvestuse ruumi vabastamist kaks korda ja seega tellija eelarve kokkuhoiu.
HANA klastrite eelproduktsioonikeskkondadest loobuti, kuid tehniliselt replitseeriti tootmiskonfiguratsioon.
Testkeskkonnad ja arenduskeskkonnad paigutati mitmele serverile ilma klastriteta MCOS konfiguratsiooniga.
Kõik rakenduste serverid virtualiseeriti ja paigutati VMware-sse.

Võrgud

Füüsiliselt eraldati haldusvõrkude ja tootmisvõrkude kontuurid lülitite pugede abil, suunates tootmisvõrgud kliendi andmekeskuse poole.
Pakuti piisav arv võrguinterfääre, et vältida suurte liiklusvoogude segamist.
Andmete edastamiseks salvestusseadmetest tehti klassikalised FC SAN tehased.

Salvestusseadmed

Tootmis- ja eeltootmiskoormus SAP-i jaoks jäi all-flash salvestusse.
Arendajate testkeskkonnad ja infrastruktuuri teenused paigutati eraldi hübriidmassiivi.

KRK

Tehti Veritas Netbackup'i põhjal.
Veidi täiustati sisseehitatud skripte, et varundada MCOS konfiguratsioone.
Kiired koopiad pandi kettale, et kiiresti taastuda, ja pikaajalise ladustamise jaoks kasutame teipe.

Jälgimine

Kogu riistvara, operatsioonisüsteem ja SAP pandi Zabbixi alla.
Koondati palju kasulikke juhtpaneele Grafanas.
Häirete korral suudab Zabbix avada piletit häirehaldamise süsteemis, meil on see rakendatud Jira-s. Samuti teave dubleeritakse Telegrami kanalis.

HANA üldine seisund

SAP rakenduste serveri seisund:

Infrastruktuuri teenused

Siseste nimede haldamiseks tõsteti DNS-serverite klaster, mis sünkroonitakse kliendi serveritega.
Andmevahetuseks loodi eraldi failiserver.
Erinevate konfiguratsioonide salvestamiseks lisati Gitlab.
Erinevate tundlike andmete jaoks kasutati HashiCorp Vault'i.

Migreerimise protsess

Üldiselt koosneb migratsiooniprotsess järgmistest etappidest:

kogu vajaliku projektidokumendi ettevalmistamine;
läbirääkimised praeguse teenusepakkujaga – organisatsiooniliste küsimuste lahendamine;
uue seadme ostmine, kohaletoimetamine ja paigaldamine projekti jaoks;
katsetusmigratsioon ja protsessi häälestamine;
süsteemide üleviimine, tootmismigratsioon.

2019. aasta oktoobri lõpus sõlmisime lepingu, seejärel projekteerisime arhitektuuri ja pärast selle kooskõlastamist kliendiga tellisime vajalikud seadmed.

Esimese asjana tuleb tähelepanu pöörata seadmete kohaletoimetamise tähtaegadele. Sertifitseeritud riistvara tarnimine SAP NAHA jaoks, mis vastab tarkvara tootja nõudmistele riistvaraplatvormide osas, kestab keskmiselt 10-12 nädalat. Arvestades hooajalisust (projekti käivitamine langes täpselt uusaastale) - võis see tähtaeg pikeneda veel ühe kuu võrra. Seega oli vajadus protsessi maksimaalselt kiirendada: tegutsesime tarnija ja distributori ning leppisime kokku kiirendatud lennutranspordis (maanteetranspordi ja mereteed asemel).

November ja detsember möödusid migratsiooni ettevalmistamise ja osa seadmete saamisega. Valmistamine toimus meie avalikus pilves teststandil, kus töötasime läbi kõik peamised sammud ja tuvastasime võimalikud keerukused ja probleemid:

valmistatud detailne plaan projektigruppide osalejate koostöö jaoks minutite kaupa ajakavaga;
ehitatud teststand andmebaaside ja rakenduste serverite jaoks enam-vähem samamoodi nagu sihtinfrastruktuuris;
seatud vajalikud suhtluskanalid ja infrastruktuuri teenused, et testida integratsioonide toimimist;
läbiviidud ülemineku stsenaariumid;
pilv aitas meil samuti luua eelkonfigureeritud virtuaalmasinate malle, mille me hiljem lihtsalt importisime ja juurutamisime sihtkeskkonnas.

Vahetult enne uue aasta pühi saabus meile esimene seadmeerakond. See võimaldas osaliselt süsteeme reaalsete seadmetega juurutada. Kuna kõik ei olnud saabunud, ühendame asendusriistvara, mille tarnimise osas oleme suutnud leppida kokku müüjaga ja distributoreid. Sihtinfrastruktuuri jäägid saime juba lõppfaasis.
Selleks, et tähtaega täita, pidid meie insenerid loobuma uusaasta puhkusest ja alustama sihtinfrastruktuuri ettevalmistamist 2. jaanuaril, pidustuste kõrgaegadel. Jah, selliseid olukordi juhtub vahel, kui on kiire ja teisi valikuid ei ole. Süsteemide töökindlus, millest sõltub ettevõtte elujõud, oli kaalul.

Üldine migratsiooniprotsess nägi välja järgmine: kõigepealt - vähem kriitilised süsteemid (arendusmaastik, testimismaastik), seejärel - tootmissüsteemid. Migratsiooni viimane etapp toimus jaanuari lõpus - veebruari alguses.

Migreerimisprotsess oli detailne ja täpselt ajastatud. See on cutover-plaan, mis sisaldab kõiki ülesandeid, tähtaegade ja vastutavate isikute loetelu. Kõik sammud olid juba testmigreerimise käigus harjutatud, seega tuli lihtsalt järgida plaani ja koordineerida protsessi.

Migreerimine toimus süsteemipõhiselt mitmes etapis. Igas etapis oli kaks süsteemi.

Kolme kuu sprinti tulemuseks sai süsteem, mis töötab täielikult KROK andmekeskuses. Üldiselt saavutati positiivne tulemus tänu koostööl, kus kõik osalised andsid maksimumi.

Tellija roll projektis

Kommunikatsioon meie kliendi lahkuva teenusepakkujaga oli keeruline. See on arusaadav, nad olid viimased, kellel oli huvi projekti eduka lõpetamise suhtes. Tellija võttis endale ülesanded eskaleerimise ja kõikide kommunikatsiooniküsimuste edendamise osas ning täitis neid 100500% ulatuses. Selle eest suur tänu. Ilma sellise aktiivse osalusega protsessis oleks projekti tulemus olnud hoopis teine.

Endise teenusepakkuja poolt formaliseeritud protsesside tõttu hooldas infrastruktuuri spetsialistid, kes olid otseselt kaugel probleemidest, mis tol ajal veel nende tellija. Näiteks ühe ja sama andmebaasi eksportimine võis võtta aega tunni kuni viie tunni vahel. Toona näis, et see on mingi maagia, mille saladust me ei avastanud. Ilmselt olid tehnilise toe insenerid vahel mediteerimisele pühendunud, unustades, et kaugel Venemaal olid tähtaegadega probleemid, insenerid ilma uusaasta salatiteta ja tellija nuttis ja kannatas...

Projekti kokkuvõtted

Migreerimise lõppakord oli süsteemide üleminek hooldusettevõttele.

Praegu pakume kliendi pöördumiste jaoks ühtse teenuse ja katame kogu infrastruktuuri koostisosade ja SAP basi hooldusega seotud ülesannete mahu koos partneriga — itelligence. Klient elab juba pool aastat privaatpilves. Siin on statistika teenusjuhtumite kohta selle aja jooksul: