Kas see on võimalik? Muidugi, SAP-süsteemide migreerimine on keeruline ja põhjalik protsess, mille eduks on kõikide osalejate sujuv koostöö. Ja kui migratsioon toimub lühikese aja jooksul, siis on ülesanne kordades keerulisem. Mitte kõik ei julge seda teha. Sellel võib olla mitu põhjust. Näiteks on protsess iseenesest aeganõudev ja organisatsiooniliselt keeruline. Lisaks on olemas risk ettenägematuteks süsteemide seiskamisteks. Või ei ole kliendid kindlad, et pärast sellise operatsiooni läbimist saavad nad eeliseid, mis oleksid proportsionaalsed kulutatud pingutustega. Kuid on ka erandeid.
Allpool räägime raskustest, millega kliendid silmitsi seisavad SAP-süsteemide migreerimise ja hooldamise protsessis, arutame, miks stereotüübid ei vasta alati tegelikkusele ning jagame juhtumit, kuidas suutsime migreerida kliendi süsteemid uude infrastruktuuri kõigest kolme ja pool kuuga.
SAP-süsteemide häll
Veel viis aastat tagasi oli raske ette kujutada, et kliendid hakkavad massiliselt kasutama hostimislahendusi SAP-rakenduste jaoks. Enamikul juhtudel viidi need ellu kohaliku lahendusena. Kuid koos väljasupoole allhanke ja pilveteenuste turu arenguga hakkasid tellijate arusaamad muutuma. Millised on argumendid, mis mõjutavad valikut pilve suunal SAP-i jaoks?
- Algajate jaoks, kes plaanivad just SAP-i juurutamist, on pilve infrastruktuur praktiliselt standardne valik – ressursi skaleeritavus vastavalt süsteemi praegusele vajadusele ja soovimatus suunata ressursse mittespetsiifiliste kompetentside arendamisele.
- Suure süsteemimaastikuga ettevõtetes võimaldavad SAP-süsteemide hostimise kaudu CIO-d jõuda kvaliteetsemale riskijuhtimise tasemele, kuna SLA eest vastutab partner.
- Kolmas kõige sagedamini esinev argument on infrastruktuuri rajamise kõrged kulud kõrge kättesaadavuse ja DR-skeemide elluviimiseks.
- Faktor 2027 – tootja poolt välja kuulutatud vananenud süsteemide toe lõpetamine 2027. aastal. See tähendab andmebaasi üleviimist HANA-le, mis toob kaasa kulud moderniseerimiseks ja uute arvutusvõimsuste soetamiseks.
SAP-hostingu turg Venemaal on nüüdseks piisavalt küps. See pakub laialdasi võimalusi klientidele, kes soovivad oma hosting-platvorme vahetada. Siiski võivad sellised projektid õigustatult tekitada ettevõtetes muresid migratsiooni keerukuse tõttu. See sunnib tellijaid esitama kõrgendatud nõudmisi teenusepakkujatele, kes peavad omama mitte ainult erituslikke hulkade ja SAP süsteemide haldamise oskusi, vaid ka edukat kogemust migratsiooni vallas.
Millised on SAP-hostingu vahetamise keerukused?
Hostingud on erinevad. Teenuse taseme mittevastavus, palju „aga” ja tähed väikese trükiga, ressursside ja võimaluste piiratus. hostimisettevõttest, kliendiga suhtlemise paindlikkuse puudumine, bürokraatia, tehnilised piirangud, tehnilise toe spetsialistide madal pädevus ning paljud teised nüansid – need on vaid väike osa takistustest, millega kliendid võivad silmitsi seista oma ärisüsteemide kasutamise käigus kolmandate osapoolte infrastruktuurides. Tihti jääb see klientidele varjatuks, mitmeid lehekülgi hõlmava lepingu sügavustes ning ilmneb alles teenuste kasutamise protsessis.
Mingi hetk on tellijale selge, et teenuse tase, mida ta saab, on kaugel tema ootustest. See muutub katalüsaatoriks olukorra parandamise lahenduste otsimiseks ning juhul, kui see ebaõnnestub ja probleemid kuhjuvad maksimaalselt, lähevad nad aktiivsetele tegevustele teenusepakkuja vahetamise alternatiivide välja töötamisel.
Miks venitavad kuni viimase minutini? Põhjuseks on see, et süsteemide üleviimise protsess klientide jaoks ei ole alati läbipaistev ja arusaadav. Kliendil on keeruline hinnata tegelikke riske, mis on seotud migratsiooniprotsessiga. Võib öelda, et kliendi jaoks on migratsioon omamoodi must karp: ei ole selge, milline on hind, süsteemide seiskamise aeg, riskid ja kuidas neid maandada, ning üldiselt on olukord hirmutav. Kui midagi ei õnnestu, siis võivad nii juhtide kui ka töötajate pead lendama minna.
SAP on ettevõtte tasandi süsteemid, keerulised ja pehmelt öeldes mitte odavad. Nende rakendamiseks, kohandamiseks ja toe pakkumiseks kulub märkimisväärseid eelarveid ning nende kättesaadavus ja korrektne töö on ettevõtte elujõulisuse jaoks hädavajalikud. Kujutage nüüd ette mõne suure tootmise seiskumise tagajärgi. Need on finantsilised kahjud, mida saab mõõta suurte nullidega numbrites, samuti maine ja muud, mitte vähem olulised riskid.
Vaatame üle raskused, mis võivad tekkida igal etapil SAP-süsteemide migratsiooni korral ühe meie kliendi näitel.
Ettevalmistus ja projekteerimine
Migratsioon on valem, millel on palju erinevaid komponente. Üks kõige olulisemaid etappe on sihtkoha (uue) infrastruktuuri projekteerimine ja ettevalmistamine.
Me pidime süvenema olemasolevatesse süsteemidesse, nende arhitektuuri. Sihtinfrastruktuuris kordasime kohati olemasolevaid lahendusi, mõnes osas täiendasime ja parandasime neid, mõnikord ümber kujundasime, mõtlesime läbi ja valisime lahendused, et tagada talitlushäirekindlus ja saadavus, ning maksimaalselt konsolideerisime kõik ressursid.
Projekteerimise käigus tehti palju erinevaid harjutusi, mis võimaldasid lõpuks maksimaalselt ette valmistuda migratsiooniks ning arvestada kõikide nüansside ja allakäikude (sellest räägime hiljem) riskidega.
Mida me lõpuks saavutasime — individuaalselt projekteeritud erainfrastruktuur meie andmeruumide põhjal:
- dedikeeritud füüsilised serverid SAP HANA jaoks;
- VMware virtualiseerimisplatvorm rakendusserverite ja infrastruktuuri teenuste jaoks;
- kahefomiikide ühendused andmeruumide vahel L2 jaoks; VPN;
- kaks peamist salvestusseadet tootmise ja „kõikide ülejäänute” eristamiseks;
- Veritas Netbackup põhine SRK, eraldi serveriga, kettaplokiga ja lintkoguja.
Nii on see kõik tehniliselt ellu viidud.
SAP
- Tõhusaks andmemagasiini kasutamiseks tootmis-HANA jaoks kasutasime ühisplaate ilma SAP-i andmebaasi süsteemse replikatsioonita. Kõik see pakiti Active-Standby SUSE HAE klastrisse, mille aluseks on Pacemaker. Jah, taasteaeg on veidi pikem kui replikatsiooni korral, kuid saame kahekordse ruumi kokkuhoiu andmemagasiinis ja seetõttu kliendi eelarve kokkuhoiu.
- Eelproduktsioonikeskkondades loobuti HANA klastritest, kuid tehniliselt korrati produktsiooni konfiguratsiooni.
- Testi- ja arenduskeskkonnad viidi veel eraldi serveritesse ilma klastriteta MCOS konfiguratsioonis.
- Kõik rakenduste serverid virtualiseeriti ja paigutati VMware-i.
Võrgud
- Füüsiliselt eraldasime haldussuvandid ja tootmisvõrgud lülitussteegides, viies tootmisvõrgud kliendi andmekeskuse poole.
- Lubasime piisava arvu võrguliideseid, et mitte segada suurtel andmevoogudel.
- Andmete edastamiseks andmemagasiinist kasutati klassikalisi FC SAN tehaseid.
Salvestussüsteem
- SAP-i produktiivne ja eelhoiakukuormus on paigutatud all-flash-massiivile.
- Arendajate testimiskeskkonnad ja infrastruktuuri teenused on eraldi hübriidmassiivile paigutatud.
SRK
- Tehtud Veritas Netbackup'i baasil.
- Veidi lisasime sisseehitatud skripte, et varundada MCOS-konfiguratsioonid.
- Ajavahemikud on paigutatud ketasule, et kiiresti taastuda, ja pikaajalise ladustamise jaoks kasutame lintkassette.
Jälgimine
- Kõik riistvara, opsüsteem ja SAP on Zabbixi all registreeritud.
- Kogusime mitmeid kasulikke armatuurlaudu Grafanas.
- Alarmi tekkimisel oskab Zabbix avada taotluse sündmuste haldamise süsteemis, mis meil on rakendatud Jira-s. Lisäksi teave dubleeritakse Telegrami kanalisse.
Telegram
HANA üldine seisund
SAP rakenduste serveri seisund:
Infrastruktuuri teenused
- Siseste nimede haldamiseks tõstsime DNS-serverite klastrit, mis sünkroniseerub kliendi serveritega.
- Tehtud eraldi failiserver andmete vahetamiseks.
- Erinevate konfiguratsioonide hoidmiseks lisasime Gitlabi.
- Tundliku teabe jaoks kasutasime HashiCorp Vault'i.
Migratsiooniprotsess
Üldiselt koosneb migreerimisprotsess järgmistest etappidest:
- kogu vajaliku projektidokumendi ettevalmistamine;
- läbirääkimised olemasoleva teenusepakkujaga – organisatsiooniliste küsimuste lahendamine;
- uue seadme soetamine, kohaletoimetamine ja paigaldamine projekti jaoks;
- katsetusmigreerimine ja protsessi häälestamine;
- süsteemide üleviimine, tõeline migratsioon.
Oktoobri lõpus 2019 allkirjastasime leping, seejärel projekteerisime arhitektuuri ja pärast kliendiga kokkulepimist tellisime vajalikud seadmed.
Esmalt tuleb tähelepanu pöörata seadmete tarnetähtaegadele. Sertifitseeritud riistvara, mis vastab SAP NAHA nõuetele ja tarkvara tootjate riistvaraplatvormide nõuetele, tarnimiseks kulub keskmiselt 10-12 nädalat. Arvestades hooajalisust (projekti elluviimine langes täpselt uue aasta peale) – see aeg võis pikendada veel kuu võrra. Seega tuli protsessi võimalikult kiiresti kiirendada: tegelesime tarnijaga, kokkulepitud kiirendatud kohaletoimetamise nimel lennukitega (maanteede ja mereteede asemel).
Novembris ja detsember kulusid migratsiooniks ettevalmistamiseks ja osa varustuse saamiseks. Valmistused toimusid meie avalikus pilves testimisseinal, kus töötasime läbi kõik peamised sammud ja avastasime võimalikke keerukusi ja probleeme:
- valmistasime detailse koostööplaani projektimeeskondade osalejatele minutite ajakavadega;
- ehitasime andmebaasi ja rakendusserverite testseina, peaagu nagu sihtinfrastruktuuris;
- seadsime vajalikud sidekanalid ja infrastruktuuri teenused, et kontrollida integratsioonide toimimist;
- läbisime cutover-skeemid;
- pilv aitas meil ka luua eelhäälestatud virtuaalmasinate šabloone, mille me hiljem lihtsalt importisime ja süsteemi sihtkeskkonnas juurutamise käigus käivitasime.
Oma jõulupidude ajaks saabus meile esimene varustuse parti. See võimaldas meil osa süsteeme paigaldada reaalsesse riistvarasse. Kuna kõik ei olnud saabunud, ühendasime varutooted, mille osas suutsime tarnijate ja edasimüüjatega kokkuleppele jõuda. Sihtinfrastruktuuri ülejäänud osad saime juba lõppetapis.
Ajaks teie projektiga valmis saada, pidid meie insenerid ohverdama uue aasta puhkuse ja alustama sihtinfrastruktuuri ettevalmistamist 2. jaanuaril, pidupäevade keskel. Jah, see juhtub mõnikord, kui olukord on kriitiline ja teisi võimalusi pole. Kõik oli sõltuvuses süsteemidest, mis on ettevõtte elujõudmiseks hädavajalikud.
Üldine migratsiooniprotsess nägi välja järgmine: kõigepealt vähem kriitilised süsteemid (arendusmaastik, testimismaastik), seejärel tootmisse süsteemid. Migratsiooni lõppfaas toimus jaanuari lõpus-veebruari alguses.
Migratsiooniprotsess oli koostatud täpselt minuti täpsusega. See on cutover-plaan, kus on loetletud kõik ülesanded, teostamise ajad ja vastutavad isikud. Kõik sammud olid juba testmigratsioonil läbi käidud, seega tuli teenindusmigratsioonis lihtsalt järgida plaani ja koordineerida protsessi.
Migratsioon toimus süsteemide kaupa mitmes etapis. Igas etapis oli kaks süsteemi.
Kolme kuu sprinti tulemuseks on täiesti toimiv süsteem KROK andmekeskuses. Üldiselt on positiivne tulemus saavutatud tänu koostööle, kus kõigi osalejate panus ja pühendumine olid maksimaalsed.
Tellija roll projektis
Suhtlemine teenusepakkujaga, kelle teenuseid meie klient lõpetas, oli keeruline. See on arusaadav, nad olid viimased, kellel oli huvi projekti edukas lõpetamine. Tellija võttis enda kanda ülesanded, mis hõlmasid kõiki suhtlemise küsimusi, ja suutis sellega hakkama saada 100500%. Selle eest eriline aitäh. Ilma sellise osaluse toeta oleks projekti tulemus võinud olla hoopis teine.
Protsesside formaliseerituse tõttu „endise” teenusepakkuja poolelt tegelevad infrastruktuuri toetamisega spetsialistid, kes olid otseselt kaugel probleemidest, mis tookord veel nende tellijaid puudutasid. Näiteks sama andmebaasi eksportimine võis võtta aega tundidest kuni viie tunnini. Siis näis see olevat mingi maagia, saladus, mida me kunagi ei avastanud. Ilmselt tegid tugitehnika insenerid vahepeal meditatsiooni, unustades, et kuskil seal kaugel Venemaal on tähtaegade täitmine, insenerid ilma uusaasta salatiteta, tellija nutab ja kannatab…
Projekti tulemused
Migreerimise finaalkoht oli süsteemide edastamine hoolduseks.
Praegu pakume kliendi pöördumiste jaoks ühte akent ja katame kogu infrastruktuuri ja SAP basis komponentide hoolduse ülesannete mahu koos partneriga — itelligence. Klient on juba kuue kuu jooksul elanud privaatpilves. Siin on teenusjuhtumite statistika selle aja jooksul:
- 90 intsidenti (20% lahendatud ilma kliendi kaasamiseta)
- Lahendatud SLA raames – 100%
- Planeerimata süsteemide seiskumisi – 0
Kui teil on ülesandeid, mis sarnanevad meie kliendi omadele, ja soovite teada rohkem, kuidas neid lahendada, kirjutage: ahaidukov@croc.ru
Allikas: habr.com
