Aŭ ĉu eblas? Kompreneble, migrado de SAP-sistemoj estas kompleksa kaj peniga procezo, kies sukceso postulas la bone kunordigitan laboron de ĉiuj partoprenantoj. Kaj se la migrado efektiviĝas en mallonga tempo, la tasko fariĝas multe pli komplika. Ne ĉiuj decidas fari ĉi tion. Povas esti pluraj kialoj. Ekzemple, la procezo mem estas longa kaj organize kompleksa. Krome ekzistas risko de neplanita sistemo malfunkcio. Aŭ klientoj ne certas, ke, spertinte tian operacion, ili ricevos profitojn proporciajn al la klopodoj elspezitaj. Tamen, estas esceptoj.
Sub la tranĉo, ni parolos pri la malfacilaĵoj, kiujn klientoj alfrontas en la procezo de migrado kaj konservado de SAP-sistemoj, diskutos kial stereotipoj ne ĉiam respondas al realeco, kaj dividos kazesploron pri kiel ni sukcesis migri la sistemojn de kliento al kliento. nova infrastrukturo en iom pli ol tri monatoj.
Gastigado de SAP-sistemoj
Antaŭ nur kvin jaroj, estis malfacile imagi, ke klientoj amase komencos uzi gastigajn rimedojn por SAP-aplikoj. Plejofte ili estis efektivigitaj surloke. Tamen, kun la disvolviĝo de subkontraktado-modeloj kaj la merkato de nubaj servoj, la mondkoncepto de klientoj komencis ŝanĝiĝi. Kio estas la argumentoj influantaj la elekton favore al la nubo por SAP?
- Por komencantoj, kiuj ĵus planis efektivigi SAP, nuba infrastrukturo estas preskaŭ norma elekto - skaleblo de rimedoj al la nunaj bezonoj de la sistemo kaj malemo deturni rimedojn al la disvolviĝo de ne-kernaj kompetentecoj.
- En kompanioj kun granda sistema pejzaĝo, helpe de gastigado de SAP-sistemoj, CIO-oj atingas kvalite malsaman nivelon de riska administrado, ĉar La partnero respondecas pri la SLA.
- La tria plej ofta argumento estas la alta kosto de konstruado de infrastrukturo por efektivigi altan haveblecon kaj DR-scenarojn.
- Faktoro 2027 - la vendisto anoncis la finon de subteno por heredaj sistemoj en 2027. Ĉi tio signifas translokigi la datumbazon al HANA, kio implicas kostojn por modernigo kaj aĉeto de nova komputika potenco.
La SAP-gastiga merkato en Rusio nun povas esti konsiderata sufiĉe matura. Kaj ĉi tio provizas ampleksan ŝancon por klientoj, kiuj volas ŝanĝi siajn gastigajn platformojn. Tamen, tiaj projektoj povas prave kaŭzi maltrankvilon inter entreprenoj pro la komplekseco de la migra proceduro. Ĉi tio devigas klientojn meti pliajn postulojn al servaj provizantoj, kiuj devas havi ne nur esceptajn kompetentecojn pri gastigado kaj konservado de SAP-sistemoj, sed ankaŭ sukcesan sperton en la kampo de migrado.
Kio estas la malfacilaĵoj ŝanĝi SAP-gastigadon?
Gastigadoj estas malsamaj. Nekongrueco kun la deklarita servonivelo, multaj "sedoj" kaj asteriskoj kun rezervoj en malgranda teksto, limigitaj rimedoj kaj kapabloj de la gastiganta provizanto, manko de fleksebleco en aferoj de komunikado kun la kliento, burokratio, teknikaj limigoj, malalta kompetenteco de teknika subteno specialistoj, same kiel multaj aliaj nuancoj - ĉi tio estas nur malgranda parto de la malfacilaĵoj, kiujn klientoj povas renkonti dum funkciigado de siaj komercaj sistemoj en subkontraktado de infrastrukturoj. Ofte, por la kliento, ĉio ĉi restas en la ombro, en la ĝangalo de plurpaĝa kontrakto, kaj aperas en la procezo de uzado de la servoj.
En iu momento, fariĝas evidente al la kliento, ke la nivelo de servo, kiun li ricevas, estas malproksima de liaj atendoj. Ĉi tio estas speco de katalizilo por trovi solvojn por korekti la situacion kaj, en kazo de malsukceso, kiam problemoj amasiĝas ĝis la limo kaj fariĝas tre dolora, ili transiras al aktivaj agoj por disvolvi alternativajn eblojn en la direkto de ŝanĝi la servoprovizanton. .
Kial ili atendas ĝis la lasta minuto? La kialo estas simpla - la procezo de migrado de sistemoj por klientoj ne ĉiam estas travidebla kaj komprenebla. Estas malfacile por la kliento taksi la realajn riskojn asociitajn kun la migra procezo. Ni povas diri, ke migrado por klientoj estas speco de nigra skatolo: ĝi estas neklara, la prezo, sistemo malfunkcio, riskoj kaj kiel mildigi ilin, kaj ĝenerale ĝi estas malluma kaj timiga. Estas kvazaŭ, se ĝi ne funkcias, tiam la kapoj ruliĝos kaj supre kaj ĉe la prezentistoj.
SAP estas entrepren-nivela sistemo, kompleksa kaj, por paroli milde, ne malmultekosta. Decaj buĝetoj estas elspezitaj por ilia efektivigo, modifo kaj prizorgado, kaj la vivo de la entrepreno dependas de ilia havebleco kaj ĝusta funkciado. Nun imagu la sekvojn de ĉesigo de iu granda produktado. Ĉi tiuj estas financaj perdoj, kiuj povas esti kalkulitaj en nombroj kun granda nombro da nuloj, same kiel reputaciaj kaj aliaj same signifaj riskoj.
Ni analizos la malfacilaĵojn kiuj povas aperi en ĉiu etapo en la kazo de migrado de SAP-sistemoj de unu el niaj klientoj.
Preparado kaj dezajno
Migrado estas formulo kun multaj malsamaj partoj. Kaj unu el la plej gravaj estas la etapo de desegnado kaj preparado de la cela (nova) infrastrukturo.
Ni devis plonĝi en la ekzistantan efektivigon de la sistemoj, ilian arkitekturon. En la cela infrastrukturo, ni ripetis ekzistantajn solvojn ie, kompletigis kaj plibonigis ilin en kelkaj punktoj, refaris ilin ie, pripensis kaj elektis solvojn por certigi misfunkciadon kaj haveblecon, kaj ankaŭ firmigis ĉiujn rimedojn kiel eble plej multe.
Dum la projektprocezo, multaj diversaj ekzercoj estis faritaj, kiuj finfine ebligis prepari kiel eble plej multe por migrado kaj konsideri ĉiajn nuancojn kaj kaptilojn (pli pri ili poste).
Kion ni finis, estas individue desegnita privata nuba infrastrukturo bazita sur nia datumcentro:
- diligentaj fizikaj serviloj por SAP HANA;
- VMware virtualiga platformo por aplikaĵoserviloj kaj infrastrukturaj servoj;
- duobligitaj komunikadkanaloj inter datencentroj por L2 VPN;
- du ĉefaj stokaj sistemoj por apartigi la produkton kaj "ĉion alian";
- SRC bazita sur Veritas Netbackup kun aparta servilo, diskbreto kaj bendbiblioteko.
Kaj jen kiel ni efektivigis ĉion ĉi el teknika vidpunkto.
SAP
- Por efike uzi stokadon por produktiva HANA, ni uzis komunajn diskojn sen sistema datumbaza reproduktado per SAP. Ĉio ĉi estis envolvita en Active-Standby SUSE HAE-areto bazita sur Pacemaker. Jes, la reakiro tempo estas iom pli longa ol kun reproduktado, sed ni ŝparas stokan spacon je duono kaj, kiel rezulto, ŝparas la buĝeton de la kliento.
- En antaŭproduktaj medioj, HANA-aretoj estis forlasitaj, sed teknike la produktadkonfiguracio estis ripetita.
- Testaj kaj evolumedioj estis distribuitaj tra pluraj pli da serviloj sen aretoj en MCOS-agordo.
- Ĉiuj aplikiĝserviloj estis virtualigitaj kaj gastigitaj en VMware.
Konsiloj
- Ni fizike apartigis la konturojn de retoj de kontrolo kaj produktado per stakoj de ŝaltiloj, turnante la produktivajn al la datumcentroj de la kliento.
- Ni instalis sufiĉan nombron da retaj interfacoj por ne miksi grandajn trafikfluojn.
- Por translokigi datumojn de stokaj sistemoj, ni faris klasikajn FC SAN-fabrikojn.
SHD
- La produktiva kaj antaŭproduktiva ŝarĝo de SAP estis lasita sur la tute-fulma tabelo.
- Ellaborantotestmedioj kaj infrastrukturservoj estis metitaj sur apartan hibridan aron.
IBS
- Farita per Veritas Netbackup.
- Ni aldonis iomete al la enkonstruitaj skriptoj al rezervaj MCOS-agordoj.
- Ni metas funkciajn kopiojn sur diskbreton por rapida reakiro, kaj ni uzas bendojn por longdaŭra konservado.
Monitorado
- Ĉiu aparataro, OS kaj SAP estis instalitaj sub Zabbix.
- Ni kolektis multajn utilajn instrumentpanelojn en Grafana.
- Kiam averto okazas, Zabbix povas krei peton en la incidenta administra sistemo; ni havas ĝin efektivigita sur Jira. La informoj ankaŭ estas duobligitaj en la Telegram-kanalo.
Telegramo
Ĝenerala sano de HANA
Statuso de SAP-Aplika Servilo:
Infrastrukturaj servoj
- Por servi internajn nomspacojn, aro de DNS-serviloj estis levita, kiu estas sinkronigita kun la serviloj de la kliento.
- Ni kreis apartan dosierservilon por interŝanĝo de datumoj.
- Por stoki diversajn agordojn, Gitlab estis aldonita.
- Por diversaj Sentemaj informoj ni prenis HashiCorp Vault.
Procezo de migrado
Ĝenerale, la migra procezo konsistas el la sekvaj etapoj:
- preparado de ĉiuj necesaj projektdokumentoj;
- intertraktadoj kun la nuna provizanto - solvado de organizaj problemoj;
- aĉeto, livero kaj instalado de novaj ekipaĵoj por la projekto;
- testa migrado kaj proceza sencimigo;
- sistemoj translokigo, batali migrado.
Fine de oktobro 2019, ni subskribis kontrakton, poste dizajnis la arkitekturon, kaj interkonsentinte kun la kliento, ni mendis la necesajn ekipaĵojn.
Kion vi devas atenti unue estas la livertempo de la ekipaĵo. Averaĝe, livero de atestita aparataro por SAP NAHA, kiu plenumas la postulojn de la programaro-fabrikisto por aparataj platformoj, daŭras 10-12 semajnojn. Kaj konsiderante la sezonecon (la efektivigo de la projekto falis ĝuste sur la Nova Jaro), ĉi tiu periodo povus esti pliigita je alia monato. Sekve, estis necese akceli la procezon kiel eble plej multe: ni laboris kun la distribuisto-provizanto kaj interkonsentis pri rapida livero per aviadilo (anstataŭ teraj kaj maraj vojoj).
Novembro kaj decembro estis pasigitaj preparante por la migrado kaj ricevante iujn el la ekipaĵoj. Ni faris la preparadon sur testbenko en nia publika nubo, kie ni tralaboris ĉiujn ĉefajn paŝojn kaj kaptis eblajn malfacilaĵojn kaj problemojn:
- preparis detalan planon por interagado inter projektteamanoj kun minuto-post-minutaj tempoj;
- konstruis testbenkon por la datumbazo kaj aplikaĵserviloj en proksimume la sama maniero kiel en la celinfrastrukturo;
- agordis la necesajn komunikajn kanalojn kaj infrastrukturajn servojn por testi la funkciadon de la integriĝoj;
- ellaboris eltranĉscenarojn;
- La nubo ankaŭ helpis nin krei antaŭkonfiguritajn virtualajn maŝinajn ŝablonojn, kiujn ni poste simple importis kaj disfaldis al la cela pejzaĝo.
Iom antaŭ la novjaraj ferioj alvenis al ni la unua aro da ekipaĵo. Ĉi tio ebligis deploji kelkajn sistemojn sur reala aparataro. Ĉar ne ĉio alvenis, ni konektis anstataŭajn ekipaĵojn, kies provizon ni sukcesis interkonsenti kun la vendisto kaj distribuistoj. Ni ricevis la restaĵojn de la cela infrastrukturo en la fina etapo.
Por plenumi la limdaton, niaj inĝenieroj devis oferi la novjarajn feriojn kaj komenci labori pri preparado de la cela infrastrukturo la 2-an de januaro, meze de la ferioj. Jes, ĉi tio foje okazas kiam ĝi brulas kaj simple ne ekzistas aliaj ebloj. En ludo estis la agado de la sistemoj, de kiuj dependas la vivo de la entrepreno.
La ĝenerala ordo de migrado aspektis jene: unue, la malplej kritikaj sistemoj (evolua pejzaĝo, testa pejzaĝo), poste produktivaj sistemoj. La fina etapo de migrado okazis fine de januaro kaj frua februaro.
La migradprocezo estis planita ĝis la minuto. Ĉi tio estas tranĉa plano kun listo de ĉiuj taskoj, fintempo kaj respondecaj personoj. Ĉiuj paŝoj jam estis ellaboritaj en la prova migrado, do en la viva migrado nur necesis sekvi la planon kaj kunordigi la procezon.
La migrado estis efektivigita sisteme en pluraj stadioj. Estas du sistemoj en ĉiu stadio.
La rezulto de tri-monata spurto estis sistemo, kiu estas plene funkcianta en la CROC-datumcentro. Ĝenerale, pozitiva rezulto estis atingita per teamlaboro; la kontribuo kaj dediĉo de ĉiuj partoprenantoj en la procezo estis maksimumaj.
La rolo de la kliento en la projekto
Komuniki kun la provizanto, kiun nia kliento foriris, ne estis facila. Ĉi tio estas komprenebla; ili estis la lastaj en la listo de homoj interesitaj pri la sukcesa kompletigo de la projekto. La kliento prenis sur sin la taskon eskaladi kaj pedali ĉiujn komunikajn problemojn kaj traktis ĉi tiun 100500%. Specialan dankon al li pro tio. Sen tia realigebla partopreno en la procezo, la rezulto de la projekto povus esti tute alia.
Pro la formaligo de procezoj flanke de la "iama" provizanto, infrastruktura subteno estis efektivigita de specialistoj, kiuj estis laŭvorte malproksime de la problemoj, tiam ankoraŭ ilia kliento. Ekzemple, la procezo de eksporto de la sama datumbazo povus daŭri de horo ĝis kvin. Tiam ŝajnis, ke tio estas ia magio, sekreto, kiu neniam estis malkaŝita al ni. Verŝajne la teknikaj subtenaj inĝenieroj intertempe sin dediĉis al meditado, forgesante, ke ie en malproksima Rusio estas limdatoj, inĝenieroj sen novjaraj salatoj, la kliento ploras kaj suferas...
Projektaj rezultoj
La fina paŝo de la migrado estis la translokigo de sistemoj por prizorgado.
Nun ni provizas unufenestran servon por klientpetoj kaj kovras la tutan amplekson de taskoj rilataj al subtenado de infrastrukturaj komponantoj kaj SAP-bazo kune kun nia partnero - itelligence. La kliento vivas en privata nubo dum ses monatoj. Jen la statistikoj pri servokazoj dum ĉi tiu tempo:
- 90 okazaĵoj (20% solvitaj sen implikado de la kliento)
- Solvita ene de SLA - 100%
- Neplanitaj sistemhaltigoj - 0
Se vi havas problemojn similajn al tiuj de nia kliento, kaj vi volas lerni pli pri kiel solvi ilin, skribu al: [retpoŝte protektita]
fonto: www.habr.com