Of is dit moontlik? Natuurlik is die migrasie van SAP-stelsels 'n komplekse en moeisame proses, waarvan die sukses die goed gekoördineerde werk van alle deelnemers vereis. En as migrasie in 'n kort tyd uitgevoer word, word die taak baie meer ingewikkeld. Nie almal besluit om dit te doen nie. Daar kan verskeie redes wees. Die proses self is byvoorbeeld lank en organisatories kompleks. Boonop is daar 'n risiko van onbeplande stelselstilstand. Of kliënte is nie seker dat hulle, nadat hulle so 'n operasie ondergaan het, voordele sal ontvang wat ooreenstem met die moeite wat hulle aangewend word nie. Daar is egter uitsonderings.
Onder die snit sal ons praat oor die probleme waarmee kliënte te kampe het in die proses om SAP-stelsels te migreer en in stand te hou, bespreek waarom stereotipes nie altyd met die werklikheid ooreenstem nie, en 'n gevallestudie deel van hoe ons daarin geslaag het om 'n kliënt se stelsels na 'n nuwe infrastruktuur in net meer as drie maande.
SAP stelsel hosting
Net vyf jaar gelede was dit moeilik om te dink dat kliënte massaal gasheerhulpbronne vir SAP-toepassings sou begin gebruik. In die meeste gevalle is hulle op die perseel geïmplementeer. Met die ontwikkeling van uitkontrakteringsmodelle en die wolkdienstemark het die wêreldbeskouing van kliënte egter begin verander. Wat is die argumente wat die keuse ten gunste van die wolk vir SAP beïnvloed?
- Vir beginners wat pas beplan het om SAP te implementeer, is wolkinfrastruktuur amper 'n standaardkeuse - skaalbaarheid van hulpbronne na die huidige behoeftes van die stelsel en onwilligheid om hulpbronne na die ontwikkeling van nie-kernbevoegdhede te lei.
- In maatskappye met 'n groot stelsel landskap, met die hulp van die gasheer van SAP-stelsels, bereik CIO's 'n kwalitatief verskillende vlak van risikobestuur, omdat Die vennoot is verantwoordelik vir die SLA.
- Die derde mees algemene argument is die hoë koste van die bou van infrastruktuur om hoë beskikbaarheid en DR scenario's te implementeer.
- Faktor 2027 – die verkoper het in 2027 die einde van ondersteuning vir verouderde stelsels aangekondig. Dit beteken die oordrag van die databasis na HANA, wat koste vir modernisering en die aankoop van nuwe rekenaarkrag meebring.
Die SAP-gasheermark in Rusland kan nou as redelik volwasse beskou word. En dit bied ruim geleentheid vir kliënte wat hul gasheerplatforms wil verander. Sulke projekte kan egter met reg kommer onder besighede wek weens die kompleksiteit van die migrasieprosedure. Dit dwing kliënte om verhoogde eise aan diensverskaffers te stel, wat nie net uitsonderlike bevoegdhede moet hê om SAP-stelsels te huisves en in stand te hou nie, maar ook suksesvolle ervaring op die gebied van migrasie.
Wat is die probleme om SAP-gasheer te verander?
Gasheer is anders. Inkonsekwentheid met die verklaarde vlak van diens, baie "maar" en sterretjies met besprekings in klein teks, beperkte hulpbronne en vermoëns van die gasheerverskaffer, gebrek aan buigsaamheid in sake van kommunikasie met die kliënt, burokrasie, tegniese beperkings, lae bevoegdheid van tegniese ondersteuning spesialiste, asook baie ander nuanses - dit is Dit is net 'n klein deel van die slaggate wat kliënte kan teëkom wanneer hulle hul besigheidstelsels in die uitkontraktering van infrastruktuur bedryf. Dikwels, vir die kliënt, bly dit alles in die skaduwees, in die oerwoud van 'n multi-bladsy kontrak, en kom na vore in die proses om die dienste te gebruik.
Op 'n stadium word dit vir die kliënt duidelik dat die vlak van diens wat hy ontvang ver van sy verwagtinge is. Dit is 'n soort katalisator om oplossings te vind om die situasie reg te stel en, in geval van mislukking, wanneer probleme tot die uiterste ophoop en dit baie pynlik word, gaan hulle oor na aktiewe aksies om alternatiewe opsies te ontwikkel in die rigting van die verandering van die diensverskaffer .
Hoekom wag hulle tot op die laaste oomblik? Die rede is eenvoudig - die proses om stelsels vir kliënte te migreer is nie altyd deursigtig en verstaanbaar nie. Dit is moeilik vir die kliënt om die werklike risiko's verbonde aan die migrasieproses te evalueer. Ons kan sê dat migrasie vir kliënte 'n soort swart boks is: dit is onduidelik, die prys, stelselstilstand, risiko's en hoe om dit te versag, en in die algemeen is dit donker en skrikwekkend. Dit is soos, as dit nie uitwerk nie, dan sal die koppe beide bo en by die kunstenaars rol.
SAP is 'n ondernemingsvlakstelsel, kompleks en, om dit sagkens te stel, nie goedkoop nie. Ordentlike begrotings word aan die implementering, wysiging en instandhouding daarvan bestee, en die lewensduur van die onderneming hang af van hul beskikbaarheid en korrekte werking. Stel jou nou die gevolge voor om een of ander groot produksie te stop. Dit is finansiële verliese, wat in getalle met 'n groot aantal nulle bereken kan word, sowel as reputasie- en ander ewe beduidende risiko's.
Ons sal die probleme ontleed wat in elke stadium mag ontstaan in die geval van migrasie van SAP-stelsels vanaf een van ons kliënte.
Voorbereiding en ontwerp
Migrasie is 'n formule met baie verskillende dele. En een van die belangrikste is die stadium van ontwerp en voorbereiding van die teiken (nuwe) infrastruktuur.
Ons moes duik in die bestaande implementering van die stelsels, hul argitektuur. In die teikeninfrastruktuur het ons bestaande oplossings iewers herhaal, dit op sommige punte aangevul en verbeter, iewers oorgedoen, deurdink en oplossings gekies om foutverdraagsaamheid en beskikbaarheid te verseker, en ook alle hulpbronne sover moontlik gekonsolideer.
Tydens die ontwerpproses is baie verskillende oefeninge uitgevoer, wat dit uiteindelik moontlik gemaak het om soveel as moontlik vir migrasie voor te berei en allerhande nuanses en slaggate in ag te neem (meer daaroor later).
Waarmee ons geëindig het, is 'n individueel ontwerpte private wolkinfrastruktuur gebaseer op ons datasentrum:
- toegewyde fisiese bedieners vir SAP HANA;
- VMware-virtualiseringsplatform vir toepassingsbedieners en infrastruktuurdienste;
- gedupliseerde kommunikasiekanale tussen datasentrums vir L2 VPN;
- twee hoofbergingstelsels om die produk en "alles anders" te skei;
- SRC gebaseer op Veritas Netbackup met 'n aparte bediener, skyf rak en band biblioteek.
En hier is hoe ons dit alles vanuit 'n tegniese oogpunt geïmplementeer het.
SAP
- Om effektief berging vir produktiewe HANA te gebruik, het ons gedeelde skywe gebruik sonder sistemiese databasisreplikasie deur SAP te gebruik. Dit alles is toegedraai in 'n Active-Standby SUSE HAE-kluster gebaseer op Pacemaker. Ja, die hersteltyd is 'n bietjie langer as met replikasie, maar ons bespaar bergingspasie met die helfte en as gevolg daarvan bespaar ons die kliënt se begroting.
- In voorproduksie-omgewings is HANA-klusters laat vaar, maar tegnies is die produksiekonfigurasie herhaal.
- Toets- en ontwikkelingsomgewings is oor verskeie meer bedieners versprei sonder groepe in 'n MCOS-konfigurasie.
- Alle toepassingsbedieners is gevirtualiseer en in VMware gehuisves.
Сети
- Ons het die kontoere van beheer- en produksienetwerke fisies geskei met stapels skakelaars, wat die produktiewes na die kliënt se datasentrums draai.
- Ons het 'n voldoende aantal netwerkkoppelvlakke geïnstalleer om nie groot verkeersvloeie te meng nie.
- Om data vanaf bergingstelsels oor te dra, het ons klassieke FC SAN-fabrieke gemaak.
SHD
- Die produktiewe en pre-produktiewe las van SAP is op die al-flits-skikking gelaat.
- Ontwikkelaartoetsomgewings en infrastruktuurdienste is op 'n aparte hibriede skikking geplaas.
IBS
- Gemaak met behulp van Veritas Netbackup.
- Ons het 'n bietjie by die ingeboude skrifte gevoeg om MCOS-konfigurasies te rugsteun.
- Ons plaas operasionele kopieë op 'n skyfrak vir vinnige herstel, en ons gebruik bande vir langtermynberging.
Monitering
- Alle hardeware, OS en SAP is onder Zabbix geïnstalleer.
- Ons het baie nuttige dashboards in Grafana versamel.
- Wanneer 'n waarskuwing plaasvind, kan Zabbix 'n versoek in die voorvalbestuurstelsel skep; ons het dit in Jira geïmplementeer. Die inligting word ook in die Telegram-kanaal gedupliseer.
telegram
Algemene gesondheid van HANA
SAP Toepassing Bediener Status:
Infrastruktuurdienste
- Om interne naamruimtes te bedien, is 'n groep DNS-bedieners geskep, wat gesinchroniseer is met die kliënt se bedieners.
- Ons het 'n aparte lêerbediener vir data-uitruiling geskep.
- Gitlab is bygevoeg om verskeie konfigurasies te stoor.
- Vir verskeie sensitiewe inligting het ons HashiCorp Vault geneem.
Migrasie proses
Oor die algemeen bestaan die migrasieproses uit die volgende fases:
- voorbereiding van alle nodige projekdokumentasie;
- onderhandelinge met die huidige verskaffer - die oplossing van organisatoriese kwessies;
- aankoop, aflewering en installering van nuwe toerusting vir die projek;
- toetsmigrasie en prosesontfouting;
- stelseloordrag, bekamp migrasie.
Aan die einde van Oktober 2019 het ons 'n kontrak geteken, toe die argitektuur ontwerp, en nadat ons met die kliënt ooreengekom het, het ons die nodige toerusting bestel.
Waaraan u eerstens aandag moet gee, is die afleweringstyd van die toerusting. Die aflewering van gesertifiseerde hardeware vir SAP NAHA wat aan die sagtewarevervaardiger se vereistes vir hardewareplatforms voldoen, neem gemiddeld 10-12 weke. En met inagneming van seisoenaliteit (die implementering van die projek het presies op die Nuwe Jaar geval), kon hierdie tydperk met nog 'n maand toegeneem het. Gevolglik was dit nodig om die proses soveel as moontlik te bespoedig: ons het saam met die verspreider-verskaffer gewerk en ooreengekom op versnelde aflewering per vliegtuig (in plaas van land- en seeroetes).
November en Desember is bestee om vir die migrasie voor te berei en van die toerusting te ontvang. Ons het die voorbereiding op 'n toetsbank in ons openbare wolk uitgevoer, waar ons deur al die hoofstappe gewerk het en moontlike probleme en probleme opgespoor het:
- 'n gedetailleerde plan vir interaksie tussen projekspanlede met minuut-vir-minuut tydsberekening opgestel;
- 'n toetsbank vir die databasis en toepassingsbedieners op ongeveer dieselfde manier as in die teikeninfrastruktuur gebou;
- die nodige kommunikasiekanale en infrastruktuurdienste opgestel om die werking van die integrasies te toets;
- afsny-scenario's uitgewerk;
- Die wolk het ons ook gehelp om vooraf-gekonfigureerde virtuele masjien-sjablone te skep, wat ons dan eenvoudig ingevoer en na die teikenlandskap ontplooi het.
Kort voor die Nuwejaarsvakansie het die eerste bondel toerusting by ons opgedaag. Dit het dit moontlik gemaak om sommige stelsels op regte hardeware te ontplooi. Aangesien nie alles opgedaag het nie, het ons vervangingstoerusting gekoppel, waarvan ons met die verkoper en verspreiders ooreengekom het. Ons het die oorblyfsels van die teikeninfrastruktuur in die finale stadium ontvang.
Om die sperdatum te haal, moes ons ingenieurs die Nuwejaarsvakansie opoffer en op 2 Januarie te midde van die vakansie begin werk aan die voorbereiding van die teikeninfrastruktuur. Ja, dit gebeur soms wanneer dit aan die brand is en daar eenvoudig geen ander opsies is nie. Op die spel was die prestasie van die stelsels waarvan die lewe van die onderneming afhang.
Die algemene orde van migrasie het soos volg gelyk: eerstens die minste kritieke stelsels (ontwikkelingslandskap, toetslandskap), dan produktiewe stelsels. Die finale stadium van migrasie het aan die einde van Januarie en vroeg in Februarie plaasgevind.
Die migrasieproses is tot op die minuut beplan. Dit is 'n afsnyplan met 'n lys van alle take, voltooiingstyd en verantwoordelike persone. Alle stappe was reeds in die toetsmigrasie uitgewerk, so in die lewendige migrasie was dit net nodig om die plan te volg en die proses te koördineer.
Die migrasie is sistematies in verskeie stadiums uitgevoer. Daar is twee stelsels in elke stadium.
Die resultaat van 'n drie-maande-naelloop was 'n stelsel wat ten volle in werking is in die CROC-datasentrum. Oor die algemeen is 'n positiewe resultaat deur spanwerk behaal; die bydrae en toewyding van alle deelnemers aan die proses was maksimum.
Die rol van die kliënt in die projek
Dit was nie maklik om met die verskaffer te kommunikeer wat ons kliënt verlaat het nie. Dit is verstaanbaar; hulle was die laaste op die lys van mense wat belangstel in die suksesvolle voltooiing van die projek. Die kliënt het die taak opgeneem om alle kommunikasiekwessies te eskaleer en te trap en het hierdie 100500% hanteer. Spesiale dank aan hom hiervoor. Sonder sulke haalbare deelname aan die proses kon die resultaat van die projek heeltemal anders gewees het.
As gevolg van die formalisering van prosesse aan die kant van die “voormalige” verskaffer, is infrastruktuurondersteuning uitgevoer deur spesialiste wat letterlik ver van die probleme was, toe nog hul klant. Die proses om dieselfde databasis uit te voer kan byvoorbeeld van 'n uur tot vyf neem. Toe het dit gelyk of dit 'n soort towerkrag was, 'n geheim wat nooit aan ons geopenbaar is nie. Waarskynlik het die tegniese ondersteuningsingenieurs intussen aan meditasie oorgegee, en vergeet dat daar iewers in verre Rusland sperdatums is, ingenieurs sonder Nuwejaarsslaaie, die kliënt huil en ly...
Projek resultate
Die laaste stap van die migrasie was die oordrag van stelsels vir instandhouding.
Nou verskaf ons 'n enkele venster diens vir kliënte versoeke en dek die hele omvang van take wat verband hou met die ondersteuning van infrastruktuur komponente en SAP basis saam met ons vennoot - itelligence. Die kliënt woon al ses maande in 'n private wolk. Hier is die statistieke oor diensgevalle gedurende hierdie tyd:
- 90 voorvalle (20% opgelos sonder om die kliënt te betrek)
- Opgelos binne SLA – 100%
- Ongeskeduleerde stelselafskakelings – 0
As jy probleme soortgelyk aan dié van ons kliënt het, en jy wil meer leer oor hoe om dit op te los, skryf aan: [e-pos beskerm]
Bron: will.com