Karanasan sa pagbabago ng SAP hosting: kung paano mag-migrate ng mga system nang hindi ito masyadong masakit

O posible ba? Siyempre, ang paglipat ng mga sistema ng SAP ay isang masalimuot at maingat na proseso, na ang tagumpay ay nangangailangan ng maayos na pagkakaugnay na gawain ng lahat ng mga kalahok. At kung ang paglipat ay isinasagawa sa maikling panahon, ang gawain ay nagiging mas kumplikado. Hindi lahat ay nagpasiya na gawin ito. Maaaring may ilang dahilan. Halimbawa, ang proseso mismo ay mahaba at kumplikado sa organisasyon. Dagdag pa, mayroong panganib ng hindi planadong pag-downtime ng system. O hindi sigurado ang mga kliyente na, na sumailalim sa naturang operasyon, makakatanggap sila ng mga benepisyo na naaayon sa mga pagsisikap na ginugol. Gayunpaman, may mga pagbubukod.

Sa ibaba ng cut, pag-uusapan natin ang tungkol sa mga paghihirap na kinakaharap ng mga customer sa proseso ng paglipat at pagpapanatili ng mga SAP system, tatalakayin kung bakit ang mga stereotype ay hindi palaging tumutugma sa katotohanan, at magbahagi ng isang case study kung paano namin nagawang ilipat ang mga system ng isang customer sa isang bagong imprastraktura sa loob lamang ng tatlong buwan.

Pagho-host ng SAP system

Limang taon lamang ang nakalipas, mahirap isipin na ang mga kliyente ay sisimulan nang gumamit ng mga mapagkukunan sa pagho-host para sa mga aplikasyon ng SAP. Sa karamihan ng mga kaso, ipinatupad ang mga ito on-premise. Gayunpaman, sa pagbuo ng mga modelo ng outsourcing at ang merkado ng mga serbisyo sa ulap, ang pananaw sa mundo ng mga customer ay nagsimulang magbago. Ano ang mga argumento na nakakaimpluwensya sa pagpili na pabor sa cloud para sa SAP?

• Para sa mga baguhan na kakaplano pa lamang na ipatupad ang SAP, ang cloud infrastructure ay halos isang karaniwang pagpipilian - scalability ng mga mapagkukunan sa kasalukuyang mga pangangailangan ng system at pag-aatubili na ilihis ang mga mapagkukunan sa pagbuo ng mga hindi pangunahing kakayahan.
• Sa mga kumpanyang may malaking sistema ng landscape, sa tulong ng pagho-host ng mga SAP system, naabot ng mga CIO ang isang naiibang antas ng pamamahala sa peligro, dahil Ang kasosyo ay responsable para sa SLA.
• Ang pangatlo sa pinakakaraniwang argumento ay ang mataas na halaga ng pagtatayo ng imprastraktura upang ipatupad ang mataas na kakayahang magamit at DR na mga sitwasyon.
• Factor 2027 – inanunsyo ng vendor ang pagtatapos ng suporta para sa mga legacy system sa 2027. Nangangahulugan ito na ilipat ang database sa HANA, na nangangailangan ng mga gastos para sa modernisasyon at pagbili ng bagong kapangyarihan sa pag-compute.

Ang merkado ng pagho-host ng SAP sa Russia ay maaari na ngayong ituring na medyo mature. At nagbibigay ito ng sapat na pagkakataon para sa mga customer na gustong baguhin ang kanilang mga platform sa pagho-host. Gayunpaman, ang mga naturang proyekto ay maaaring maging sanhi ng pagkabahala sa mga negosyo dahil sa pagiging kumplikado ng pamamaraan ng paglipat. Pinipilit nito ang mga customer na maglagay ng mas mataas na mga pangangailangan sa mga service provider, na hindi lamang dapat magkaroon ng mga natatanging kakayahan sa pagho-host at pagpapanatili ng mga SAP system, kundi pati na rin ang matagumpay na karanasan sa larangan ng paglipat.

Ano ang mga kahirapan sa pagpapalit ng SAP hosting?

Iba ang mga hosting. Hindi pagkakatugma sa ipinahayag na antas ng serbisyo, maraming "ngunit" at mga asterisk na may mga reserbasyon sa maliit na teksto, limitadong mapagkukunan at kakayahan ng hosting provider, kawalan ng kakayahang umangkop sa mga usapin ng komunikasyon sa kliyente, burukrasya, teknikal na limitasyon, mababang kakayahan sa teknikal na suporta mga espesyalista, pati na rin ang maraming iba pang mga nuances - ito ay Ito ay isang maliit na bahagi lamang ng mga pitfalls na maaaring makaharap ng mga kliyente kapag nagpapatakbo ng kanilang mga sistema ng negosyo sa mga imprastraktura ng outsourcing. Kadalasan, para sa kliyente, ang lahat ng ito ay nananatili sa mga anino, sa gubat ng isang multi-page na kontrata, at lumalabas sa proseso ng paggamit ng mga serbisyo.

Sa ilang mga punto, nagiging halata sa customer na ang antas ng serbisyong natatanggap niya ay malayo sa kanyang inaasahan. Ito ay isang uri ng katalista para sa paghahanap ng mga solusyon upang iwasto ang sitwasyon at, sa kaso ng pagkabigo, kapag ang mga problema ay naipon sa limitasyon at ito ay naging napakasakit, sila ay nagpapatuloy sa mga aktibong aksyon upang bumuo ng mga alternatibong opsyon sa direksyon ng pagpapalit ng service provider .

Bakit sila maghihintay hanggang sa huling minuto? Ang dahilan ay simple - ang proseso ng paglipat ng mga system para sa mga kliyente ay hindi palaging transparent at naiintindihan. Mahirap para sa kliyente na tasahin ang mga aktwal na panganib na nauugnay sa proseso ng paglipat. Masasabi nating ang paglipat para sa mga kliyente ay isang uri ng itim na kahon: ito ay hindi malinaw, ang presyo, system downtime, mga panganib at kung paano pagaanin ang mga ito, at sa pangkalahatan ito ay madilim at nakakatakot. Ito ay tulad ng, kung hindi ito gagana, pagkatapos ay ang mga ulo ay gumulong pareho sa tuktok at sa mga performer.

Ang SAP ay isang enterprise-level system, kumplikado at, sa madaling salita, hindi mura. Ang mga disenteng badyet ay ginugugol sa kanilang pagpapatupad, pagbabago, at pagpapanatili, at ang buhay ng negosyo ay nakasalalay sa kanilang kakayahang magamit at tamang operasyon. Ngayon isipin ang mga kahihinatnan ng pagpapahinto ng ilang malalaking produksyon. Ito ay mga pagkalugi sa pananalapi, na maaaring kalkulahin sa mga numero na may malaking bilang ng mga zero, pati na rin ang reputasyon at iba pang mga pantay na makabuluhang panganib.

Susuriin namin ang mga paghihirap na maaaring lumitaw sa bawat yugto sa kaso ng paglipat ng mga SAP system mula sa isa sa aming mga customer.

Paghahanda at disenyo

Ang migration ay isang formula na may maraming iba't ibang bahagi. At isa sa pinakamahalaga ay ang yugto ng pagdidisenyo at paghahanda ng target (bagong) imprastraktura.

Kailangan naming sumisid sa umiiral na pagpapatupad ng mga sistema, ang kanilang arkitektura. Sa target na imprastraktura, inulit namin ang mga kasalukuyang solusyon sa isang lugar, dinagdagan at pinahusay ang mga ito sa ilang mga punto, muling ginawa ang mga ito sa isang lugar, pinag-isipang mabuti at pinili ang mga solusyon upang matiyak ang pagpapahintulot at pagkakaroon ng pagkakamali, at pinagsama-sama rin ang lahat ng mapagkukunan hangga't maaari.

Sa panahon ng proseso ng disenyo, maraming iba't ibang mga pagsasanay ang isinagawa, na sa huli ay naging posible upang maghanda hangga't maaari para sa paglipat at isinasaalang-alang ang lahat ng uri ng mga nuances at pitfalls (higit pa sa mga ito sa ibang pagkakataon).

Ang natapos namin ay isang indibidwal na dinisenyong pribadong imprastraktura ng ulap batay sa aming data center:

• nakalaang mga pisikal na server para sa SAP HANA;
• VMware virtualization platform para sa mga server ng application at mga serbisyo sa imprastraktura;
• nadobleng mga channel ng komunikasyon sa pagitan ng mga data center para sa L2 VPN;
• dalawang pangunahing sistema ng imbakan para sa paghihiwalay ng produkto at "lahat ng iba pa";
• SRC batay sa Veritas Netbackup na may hiwalay na server, disk shelf at tape library.

At narito kung paano namin ipinatupad ang lahat ng ito mula sa teknikal na pananaw.

Panghinain

• Para epektibong magamit ang storage para sa produktibong HANA, gumamit kami ng mga shared disk na walang systemic database replication gamit ang SAP. Ang lahat ng ito ay nakabalot sa isang Active-Standby na SUSE HAE cluster batay sa Pacemaker. Oo, mas mahaba ng kaunti ang oras ng pag-recover kaysa sa pagtitiklop, ngunit nakakatipid kami ng kalahating espasyo sa storage at, bilang resulta, nakakatipid kami ng badyet ng customer.
• Sa mga kapaligiran bago ang produksyon, ang mga kumpol ng HANA ay inabandona, ngunit sa teknikal na paraan, naulit ang configuration ng produksyon.
• Ang mga kapaligiran sa pagsubok at pag-develop ay ipinamahagi sa ilang higit pang mga server na walang mga cluster sa isang configuration ng MCOS.
• Ang lahat ng mga server ng application ay virtualized at naka-host sa VMware.

Mga network

• Pisikal naming pinaghiwalay ang mga contour ng control at production network gamit ang mga stack ng switch, na ginagawa ang mga produktibo patungo sa mga data center ng customer.
• Nag-install kami ng sapat na bilang ng mga interface ng network upang hindi maghalo ng malalaking daloy ng trapiko.
• Para maglipat ng data mula sa mga storage system, gumawa kami ng mga klasikong pabrika ng FC SAN.

SHD

• Naiwan sa all-flash array ang productive at pre-productive load ng SAP.
• Ang mga kapaligiran sa pagsubok ng developer at mga serbisyo sa imprastraktura ay inilagay sa isang hiwalay na hybrid array.

IBS

• Ginawa gamit ang Veritas Netbackup.
• Nagdagdag kami ng kaunti sa mga built-in na script sa mga backup na configuration ng MCOS.
• Naglalagay kami ng mga operational na kopya sa isang disk shelf para sa mabilis na pagbawi, at gumagamit kami ng mga tape para sa pangmatagalang imbakan.

Pagsubaybay

• Ang lahat ng hardware, OS at SAP ay na-install sa ilalim ng Zabbix.
• Nakakolekta kami ng maraming kapaki-pakinabang na dashboard sa Grafana.
• Kapag nagkaroon ng alerto, maaaring gumawa ng kahilingan ang Zabbix sa sistema ng pamamahala ng insidente; ipinatupad namin ito sa Jira. Ang impormasyon ay nadoble din sa Telegram channel.

Telegrama

Pangkalahatang kalusugan ng HANA

Katayuan ng SAP Application Server:

Mga serbisyo sa imprastraktura

• Upang magserbisyo sa mga panloob na namespace, isang kumpol ng mga DNS server ang itinaas, na naka-synchronize sa mga server ng customer.
• Gumawa kami ng hiwalay na file server para sa pagpapalitan ng data.
• Upang mag-imbak ng iba't ibang mga pagsasaayos, idinagdag ang Gitlab.
• Para sa iba't ibang Sensitibong impormasyon kinuha namin ang HashiCorp Vault.

Proseso ng migrasyon

Sa pangkalahatan, ang proseso ng paglipat ay binubuo ng mga sumusunod na yugto:

• paghahanda ng lahat ng kinakailangang dokumentasyon ng proyekto;
• negosasyon sa kasalukuyang provider - paglutas ng mga isyu sa organisasyon;
• pagbili, paghahatid at pag-install ng mga bagong kagamitan para sa proyekto;
• pagsubok sa paglipat at pag-debug ng proseso;
• paglilipat ng mga sistema, labanan ang paglipat.

Sa pagtatapos ng Oktubre 2019, pumirma kami ng isang kontrata, pagkatapos ay nagdisenyo ng arkitektura, at pagkatapos sumang-ayon sa customer, nag-order kami ng mga kinakailangang kagamitan.

Ang kailangan mo munang bigyang pansin ay ang oras ng paghahatid ng kagamitan. Sa karaniwan, ang paghahatid ng certified hardware para sa SAP NAHA na nakakatugon sa mga kinakailangan ng software manufacturer para sa mga hardware platform ay tumatagal ng 10-12 na linggo. At isinasaalang-alang ang seasonality (ang pagpapatupad ng proyekto ay nahulog nang eksakto sa Bagong Taon), ang panahong ito ay maaaring tumaas ng isa pang buwan. Alinsunod dito, kinakailangan na pabilisin ang proseso hangga't maaari: nakipagtulungan kami sa distributor-supplier at sumang-ayon sa pinabilis na paghahatid sa pamamagitan ng eroplano (sa halip na mga ruta sa lupa at dagat).

Ang Nobyembre at Disyembre ay ginugol sa paghahanda para sa paglipat at pagtanggap ng ilan sa mga kagamitan. Isinagawa namin ang paghahanda sa isang test bench sa aming pampublikong ulap, kung saan ginawa namin ang lahat ng mga pangunahing hakbang at nahuli ang mga posibleng paghihirap at problema:

• naghanda ng isang detalyadong plano para sa pakikipag-ugnayan sa pagitan ng mga miyembro ng pangkat ng proyekto na may mga minutong oras;
• bumuo ng isang test bench para sa database at mga application server sa humigit-kumulang sa parehong paraan tulad ng sa target na imprastraktura;
• isinaayos ang mga kinakailangang channel ng komunikasyon at mga serbisyo sa imprastraktura upang subukan ang pagpapatakbo ng mga pagsasama;
• nagsagawa ng mga senaryo ng cutover;
• Tinulungan din kami ng cloud na gumawa ng mga paunang na-configure na template ng virtual machine, na pagkatapos ay na-import lang namin at na-deploy sa target na landscape.

Ilang sandali bago ang pista opisyal ng Bagong Taon, dumating sa amin ang unang batch ng kagamitan. Ginawa nitong posible na mag-deploy ng ilang system sa totoong hardware. Dahil hindi dumating ang lahat, ikinonekta namin ang mga pamalit na kagamitan, ang supply kung saan nagawa naming sumang-ayon sa vendor at mga distributor. Natanggap namin ang mga labi ng target na imprastraktura sa huling yugto.
Upang matugunan ang deadline, kinailangang isakripisyo ng aming mga inhinyero ang mga pista opisyal ng Bagong Taon at magsimulang magtrabaho sa paghahanda ng target na imprastraktura sa Enero 2, sa gitna ng mga pista opisyal. Oo, nangyayari ito kung minsan kapag ito ay nasusunog at wala nang ibang mga opsyon. Ang nakataya ay ang pagganap ng mga sistema kung saan nakasalalay ang buhay ng negosyo.

Ganito ang hitsura ng pangkalahatang pagkakasunud-sunod ng paglipat: una, ang hindi bababa sa kritikal na mga sistema (landscape ng pag-unlad, testing landscape), pagkatapos ay mga produktibong sistema. Ang huling yugto ng paglipat ay naganap noong huling bahagi ng Enero at unang bahagi ng Pebrero.

Ang proseso ng paglipat ay pinlano hanggang sa minuto. Ito ay isang cutover plan na may listahan ng lahat ng mga gawain, oras ng pagkumpleto at mga responsableng tao. Naisasagawa na ang lahat ng hakbang sa pagsubok na paglilipat, kaya sa live na paglilipat ay kailangan lang na sundin ang plano at i-coordinate ang proseso.

Ang paglipat ay isinagawa nang sistematikong sa ilang mga yugto. Mayroong dalawang sistema sa bawat yugto.

Ang resulta ng tatlong buwang sprint ay isang sistema na ganap na gumagana sa CROC data center. Sa pangkalahatan, ang isang positibong resulta ay nakamit sa pamamagitan ng pagtutulungan ng magkakasama; ang kontribusyon at dedikasyon ng lahat ng mga kalahok sa proseso ay pinakamataas.

Ang papel ng customer sa proyekto

Ang pakikipag-usap sa provider na aalis ng aming kliyente ay hindi madali. Naiintindihan ito; sila ang huli sa listahan ng mga taong interesado sa matagumpay na pagkumpleto ng proyekto. Kinuha ng customer ang gawain ng pagtaas at pagpedal sa lahat ng mga isyu sa komunikasyon at nakayanan ang 100500%. Espesyal na pasasalamat sa kanya para dito. Kung walang tulad na magagawang pakikilahok sa proseso, ang resulta ng proyekto ay maaaring maging ganap na naiiba.

Dahil sa pormalisasyon ng mga proseso sa panig ng "dating" provider, ang suporta sa imprastraktura ay isinasagawa ng mga espesyalista na literal na malayo sa mga problema, sa oras na iyon ay kanilang customer pa rin. Halimbawa, ang proseso ng pag-export ng parehong database ay maaaring tumagal mula sa isang oras hanggang lima. Pagkatapos ay tila ito ay isang uri ng mahika, isang lihim na hindi nabubunyag sa amin. Marahil ang mga inhinyero ng teknikal na suporta ay nagpakasawa sa pagmumuni-muni, nakalimutan na sa isang lugar sa malayong Russia ay may mga deadline, mga inhinyero na walang mga salad ng Bagong Taon, ang customer ay umiiyak at nagdurusa...

Mga resulta ng proyekto

Ang huling hakbang ng paglipat ay ang paglipat ng mga sistema para sa pagpapanatili.

Ngayon ay nagbibigay kami ng isang solong window na serbisyo para sa mga kahilingan ng customer at sumasaklaw sa buong saklaw ng mga gawain na may kaugnayan sa pagsuporta sa mga bahagi ng imprastraktura at batayan ng SAP kasama ang aming kasosyo - intelligence. Ang kliyente ay naninirahan sa isang pribadong ulap sa loob ng anim na buwan. Narito ang mga istatistika sa mga kaso ng serbisyo sa panahong ito:

• 90 insidente (20% nalutas nang hindi kinasasangkutan ng customer)
• Nalutas sa loob ng SLA – 100%
• Mga hindi nakaiskedyul na pagsasara ng system – 0

Kung mayroon kang mga problemang katulad ng sa aming kliyente, at gusto mong matuto nang higit pa tungkol sa kung paano lutasin ang mga ito, sumulat sa: [protektado ng email]

Pinagmulan: www.habr.com