O és possible? Per descomptat, migrar sistemes SAP és un procés complex i minuciós, l'èxit del qual requereix el treball ben coordinat de tots els participants. I si la migració es fa en poc temps, la tasca es fa molt més complicada. No tothom decideix fer això. Hi pot haver diversos motius. Per exemple, el procés en si és llarg i complex organitzatiu. A més, hi ha un risc d'aturada del sistema no planificada. O els clients no estan segurs que, després d'haver-se sotmès a una operació d'aquest tipus, rebran beneficis proporcionals als esforços invertits. Tanmateix, hi ha excepcions.
A sota del tall, parlarem de les dificultats que pateixen els clients en el procés de migració i manteniment dels sistemes SAP, parlarem per què els estereotips no sempre es corresponen amb la realitat i compartirem un cas pràctic de com hem aconseguit migrar els sistemes d'un client a un nova infraestructura en poc més de tres mesos.
Allotjament de sistemes SAP
Fa només cinc anys, era difícil imaginar que els clients comencessin a utilitzar massivament recursos d'allotjament per a aplicacions SAP. En la majoria dels casos, es van implementar on-premise. No obstant això, amb el desenvolupament de models d'externalització i el mercat de serveis al núvol, la visió del món dels clients va començar a canviar. Quins són els arguments que influeixen en l'elecció a favor del núvol per a SAP?
- Per als principiants que acaben de planejar implementar SAP, la infraestructura del núvol és gairebé una opció estàndard: escalabilitat dels recursos a les necessitats actuals del sistema i reticència a desviar recursos al desenvolupament de competències no bàsiques.
- En empreses amb un gran panorama de sistemes, amb l'ajuda de l'allotjament de sistemes SAP, els CIO assoleixen un nivell qualitativament diferent de gestió del risc, perquè El soci és responsable del SLA.
- El tercer argument més comú és l'alt cost de construcció d'infraestructura per implementar escenaris d'alta disponibilitat i DR.
- Factor 2027: el venedor va anunciar el final del suport per als sistemes heretats el 2027. Això significa transferir la base de dades a HANA, la qual cosa comporta costos de modernització i compra de nova potència informàtica.
El mercat d'allotjament SAP a Rússia ara es pot considerar bastant madur. I això ofereix una àmplia oportunitat per als clients que volen canviar les seves plataformes d'allotjament. No obstant això, aquests projectes poden causar preocupació entre les empreses a causa de la complexitat del procediment de migració. Això obliga els clients a exigir més exigències als proveïdors de serveis, que han de tenir no només competències excepcionals en l'allotjament i manteniment de sistemes SAP, sinó també experiència d'èxit en el camp de la migració.
Quines són les dificultats de canviar l'allotjament SAP?
Els hostings són diferents. Incoherència amb el nivell de servei declarat, molts “peròs” i asteriscs amb reserves en text petit, recursos i capacitats limitats del proveïdor d'allotjament, manca de flexibilitat en matèria de comunicació amb el client, burocràcia, limitacions tècniques, baixa competència del suport tècnic. especialistes, així com molts altres matisos: aquests són només una petita part dels inconvenients que poden trobar els clients quan operen els seus sistemes empresarials en infraestructures d'externalització. Sovint, per al client, tot això queda a l'ombra, a la selva d'un contracte de diverses pàgines, i sorgeix en el procés d'ús dels serveis.
En algun moment, es fa obvi per al client que el nivell de servei que rep està lluny de les seves expectatives. Es tracta d'una mena de catalitzador per trobar solucions per corregir la situació i, en cas de fracàs, quan els problemes s'acumulen al límit i esdevé molt dolorós, passen a accions actives per desenvolupar opcions alternatives en la direcció del canvi de prestador del servei. .
Per què esperen fins l'últim moment? El motiu és senzill: el procés de migració de sistemes per als clients no sempre és transparent i comprensible. És difícil per al client avaluar els riscos reals associats al procés de migració. Podem dir que la migració per als clients és una mena de caixa negra: no està clar, el preu, el temps d'inactivitat del sistema, els riscos i com mitigar-los, i en general és fosc i aterridor. És com, si no funciona, els caps rodaran tant a la part superior com als intèrprets.
SAP és un sistema a nivell empresarial, complex i, per dir-ho suaument, no barat. Es gasten pressupostos dignes en la seva implementació, modificació i manteniment, i la vida de l'empresa depèn de la seva disponibilitat i funcionament correcte. Ara imagineu-vos les conseqüències d'aturar una gran producció. Es tracta de pèrdues financeres, que es poden calcular en números amb un gran nombre de zeros, així com de riscos reputacionals i altres igualment significatius.
Analitzarem les dificultats que poden sorgir en cada etapa en el cas de migrar sistemes SAP d'un dels nostres clients.
Preparació i disseny
La migració és una fórmula amb moltes parts diferents. I una de les més importants és l'etapa de disseny i preparació de la (nova) infraestructura objectiu.
Havíem de submergir-nos en la implementació existent dels sistemes, la seva arquitectura. A la infraestructura objectiu, hem repetit les solucions existents en algun lloc, les hem complementat i millorat en alguns moments, les hem refet en algun lloc, hem pensat i seleccionat solucions per garantir la tolerància a errors i la disponibilitat, i també hem consolidat tots els recursos al màxim.
Durant el procés de disseny, es van realitzar molts exercicis diferents, que finalment van permetre preparar el màxim possible per a la migració i tenir en compte tota mena de matisos i trampes (més endavant més endavant).
El que vam acabar és una infraestructura de núvol privat dissenyada individualment basada en el nostre centre de dades:
- servidors físics dedicats per a SAP HANA;
- Plataforma de virtualització VMware per a servidors d'aplicacions i serveis d'infraestructura;
- canals de comunicació duplicats entre centres de dades per a VPN L2;
- dos sistemes principals d'emmagatzematge per separar el producte i “tota la resta”;
- SRC basat en Veritas Netbackup amb un servidor separat, prestatge de disc i biblioteca de cintes.
I així és com hem implementat tot això des del punt de vista tècnic.
SAP
- Per utilitzar eficaçment l'emmagatzematge per a HANA productiu, hem utilitzat discs compartits sense replicació sistèmica de bases de dades mitjançant SAP. Tot això estava embolicat en un clúster SUSE HAE en espera actiu basat en Pacemaker. Sí, el temps de recuperació és una mica més llarg que amb la rèplica, però estalviem l'espai d'emmagatzematge a la meitat i, per tant, estalviem el pressupost del client.
- En entorns de preproducció, els clústers HANA es van abandonar, però tècnicament es va repetir la configuració de producció.
- Els entorns de prova i desenvolupament es van distribuir en diversos servidors més sense clústers en una configuració MCOS.
- Tots els servidors d'aplicacions estaven virtualitzats i allotjats a VMware.
Сети
- Vam separar físicament els contorns de les xarxes de control i producció amb piles d'interruptors, orientant els productius cap als centres de dades del client.
- Hem instal·lat un nombre suficient d'interfícies de xarxa per no barrejar grans fluxos de trànsit.
- Per transferir dades dels sistemes d'emmagatzematge, hem creat fàbriques FC SAN clàssiques.
SHD
- La càrrega productiva i preproductiva de SAP es va deixar a la matriu totalment flash.
- Els entorns de prova de desenvolupadors i els serveis d'infraestructura es van col·locar en una matriu híbrida independent.
IBS
- Fet amb Veritas Netbackup.
- Hem afegit una mica als scripts integrats per fer còpies de seguretat de les configuracions MCOS.
- Col·loquem còpies operatives en un prestatge de disc per a una recuperació ràpida i fem servir cintes per a l'emmagatzematge a llarg termini.
Seguiment
- Tot el maquinari, el sistema operatiu i SAP es van instal·lar sota Zabbix.
- Hem recopilat molts quadres de comandament útils a Grafana.
- Quan es produeix una alerta, Zabbix pot crear una sol·licitud al sistema de gestió d'incidències; la tenim implementada a Jira. La informació també es duplica al canal de Telegram.
telegram
Salut general de HANA
Estat del servidor d'aplicacions SAP:
Serveis d'infraestructures
- Per donar servei als espais de noms interns, es va crear un clúster de servidors DNS, que es sincronitza amb els servidors del client.
- Hem creat un servidor de fitxers separat per a l'intercanvi de dades.
- Per emmagatzemar diverses configuracions, es va afegir Gitlab.
- Per obtenir informació sensible, vam agafar HashiCorp Vault.
Procés migratori
En general, el procés de migració consta de les següents etapes:
- preparació de tota la documentació necessària del projecte;
- negociacions amb el proveïdor actual: resolució de problemes organitzatius;
- compra, lliurament i instal·lació de nous equips per al projecte;
- prova de migració i depuració de processos;
- transferència de sistemes, combat la migració.
A finals d'octubre de 2019 vam signar un contracte, després vam dissenyar l'arquitectura i, després d'acordar amb el client, vam demanar l'equipament necessari.
El que primer cal parar atenció és el termini de lliurament de l'equip. De mitjana, el lliurament de maquinari certificat per a SAP NAHA que compleix els requisits del fabricant de programari per a plataformes de maquinari triga de 10 a 12 setmanes. I tenint en compte l'estacionalitat (la implementació del projecte va caure exactament l'any nou), aquest període podria haver augmentat un mes més. En conseqüència, calia accelerar el procés al màxim: vam treballar amb el distribuïdor-proveïdor i vam acordar un lliurament accelerat per avió (en comptes de rutes terrestres i marítimes).
El novembre i el desembre es van dedicar a preparar la migració i a rebre part dels equips. La preparació la vam realitzar en un banc de proves al nostre núvol públic, on vam treballar tots els passos principals i vam detectar possibles dificultats i problemes:
- va preparar un pla detallat per a la interacció entre els membres de l'equip del projecte amb cronometratges minut a minut;
- va crear un banc de proves per a la base de dades i els servidors d'aplicacions aproximadament de la mateixa manera que a la infraestructura de destinació;
- configurat els canals de comunicació i serveis d'infraestructura necessaris per provar el funcionament de les integracions;
- es van elaborar escenaris de tall;
- El núvol també ens va ajudar a crear plantilles de màquines virtuals preconfigurades, que després simplement vam importar i desplegar al paisatge objectiu.
Poc abans de les vacances d'Any Nou, ens va arribar el primer lot d'equips. Això va permetre desplegar alguns sistemes en maquinari real. Com que no va arribar tot, vam connectar equips de substitució, el subministrament dels quals vam aconseguir pactar amb el venedor i els distribuïdors. Vam rebre les restes de la infraestructura objectiu en l'etapa final.
Per complir amb el termini, els nostres enginyers van haver de sacrificar les vacances d'Any Nou i començar a treballar en la preparació de la infraestructura objectiu el 2 de gener, en plena vacances. Sí, això de vegades passa quan està en flames i simplement no hi ha altres opcions. Es tractava del rendiment dels sistemes dels quals depèn la vida de l'empresa.
L'ordre general de la migració era el següent: primer, els sistemes menys crítics (paisatge de desenvolupament, paisatge de proves), després els sistemes productius. L'etapa final de la migració va tenir lloc a finals de gener i principis de febrer.
El procés de migració es va planificar al minut. Aquest és un pla de canvi amb una llista de totes les tasques, temps de finalització i persones responsables. Tots els passos ja s'havien treballat en la migració de prova, així que en la migració en directe només calia seguir el pla i coordinar el procés.
La migració es va dur a terme sistemàticament en diverses etapes. Hi ha dos sistemes a cada etapa.
El resultat d'un sprint de tres mesos va ser un sistema que està totalment operatiu al centre de dades CROC. En general, s'ha aconseguit un resultat positiu amb el treball en equip, la contribució i dedicació de tots els participants en el procés ha estat màxima.
El paper del client en el projecte
Comunicar-se amb el proveïdor que el nostre client marxava no va ser fàcil. Això és comprensible; van ser els últims de la llista de persones interessades en la realització satisfactòria del projecte. El client va assumir la tasca d'escalar i pedalejar tots els problemes de comunicació i va fer front a aquest 100500%. Gràcies especials a ell per això. Sense aquesta participació factible en el procés, el resultat del projecte podria haver estat completament diferent.
A causa de la formalització de processos per part de l'“antic” proveïdor, el suport d'infraestructura es va dur a terme per especialistes que estaven literalment lluny dels problemes, en aquell moment encara el seu client. Per exemple, el procés d'exportació de la mateixa base de dades pot trigar d'una hora a cinc. Aleshores va semblar que això era una mena de màgia, un secret que mai ens va ser revelat. Probablement els enginyers de suport tècnic es van dedicar a la meditació mentrestant, oblidant que en algun lloc de la llunyana Rússia hi ha terminis, enginyers sense amanides de Cap d'Any, el client plora i pateix...
Resultats del projecte
El pas final de la migració va ser la transferència de sistemes per al manteniment.
Ara oferim un servei de finestra única per a les sol·licituds dels clients i cobrim tot l'abast de les tasques relacionades amb els components d'infraestructura de suport i la base de SAP juntament amb el nostre soci: itelligence. El client fa sis mesos que viu en un núvol privat. Aquestes són les estadístiques dels casos de servei durant aquest temps:
- 90 incidències (20% resoltes sense implicar el client)
- S'ha resolt dins del SLA: 100%
- Tancaments no programats del sistema - 0
Si tens problemes similars als del nostre client, i vols saber més sobre com resoldre'ls, escriviu a: [protegit per correu electrònic]
Font: www.habr.com