Ou é posible? Por suposto, migrar sistemas SAP é un proceso complexo e minucioso, cuxo éxito require o traballo ben coordinado de todos os participantes. E se a migración se realiza en pouco tempo, a tarefa faise moito máis complicada. Non todos deciden facelo. Pode haber varias razóns. Por exemplo, o proceso en si é longo e complexo organizativamente. Ademais, hai un risco de inactividade do sistema non planificada. Ou os clientes non están seguros de que, tras ser sometidos a tal operación, recibirán beneficios acordes aos esforzos realizados. Non obstante, hai excepcións.
Debaixo do corte, falaremos das dificultades ás que se enfrontan os clientes no proceso de migración e mantemento dos sistemas SAP, discutiremos por que os estereotipos non sempre se corresponden coa realidade e compartiremos un caso práctico de como conseguimos migrar os sistemas dun cliente a un novas infraestruturas en pouco máis de tres meses.
Aloxamento de sistemas SAP
Hai só cinco anos, era difícil imaxinar que os clientes comezarían a usar masivamente recursos de hospedaxe para aplicacións SAP. Na maioría dos casos implementáronse localmente. Non obstante, co desenvolvemento de modelos de subcontratación e o mercado de servizos na nube, a visión do mundo dos clientes comezou a cambiar. Cales son os argumentos que inflúen na elección a favor da nube para SAP?
- Para os principiantes que acaban de planear implementar SAP, a infraestrutura na nube é case unha opción estándar: escalabilidade dos recursos ás necesidades actuais do sistema e reticencia a desviar recursos ao desenvolvemento de competencias non básicas.
- Nas empresas cun gran panorama de sistemas, coa axuda do hospedaxe de sistemas SAP, os CIO alcanzan un nivel cualitativamente diferente de xestión de riscos, porque O socio é responsable do SLA.
- O terceiro argumento máis común é o alto custo da construción de infraestruturas para implementar escenarios de alta dispoñibilidade e DR.
- Factor 2027: o vendedor anunciou o fin do soporte para os sistemas legados en 2027. Isto significa transferir a base de datos a HANA, o que supón custos de modernización e compra de nova potencia informática.
O mercado de hospedaxe SAP en Rusia agora pódese considerar bastante maduro. E isto ofrece unha ampla oportunidade para os clientes que queren cambiar as súas plataformas de hospedaxe. Non obstante, estes proxectos poden xustamente causar preocupación entre as empresas debido á complexidade do procedemento de migración. Isto obriga aos clientes a exixir cada vez máis aos provedores de servizos, que deben ter non só competencias excepcionais no hospedaxe e mantemento de sistemas SAP, senón tamén experiencia exitosa no campo da migración.
Cales son as dificultades de cambiar o hospedaxe de SAP?
Os aloxamentos son diferentes. Incoherencia co nivel de servizo declarado, moitos “peros” e asteriscos con reservas en texto pequeno, recursos e capacidades limitados do provedor de hospedaxe, falta de flexibilidade en materia de comunicación co cliente, burocracia, limitacións técnicas, pouca competencia do soporte técnico. especialistas, así como moitos outros matices - estes son Esta é só unha pequena parte das trampas que poden atopar os clientes cando operan os seus sistemas comerciais en infraestruturas de subcontratación. Moitas veces, para o cliente, todo isto queda na sombra, na selva dun contrato de varias páxinas, e xorde no proceso de utilización dos servizos.
Nalgún momento, faise obvio para o cliente que o nivel de servizo que recibe está lonxe das súas expectativas. Trátase dunha especie de catalizador para buscar solucións para corrixir a situación e, en caso de fracaso, cando os problemas se acumulan ata o límite e se fai moi penoso, pasan a accións activas para desenvolver opcións alternativas na dirección do cambio de prestador do servizo. .
Por que agardan ata o último momento? A razón é sinxela: o proceso de migración dos sistemas para os clientes non sempre é transparente e comprensible. É difícil para o cliente avaliar os riscos reais asociados ao proceso de migración. Podemos dicir que a migración para os clientes é unha especie de caixa negra: non está claro o prezo, o tempo de inactividade do sistema, os riscos e como mitigalos, e en xeral é escuro e asustado. É como, se non funciona, entón as cabezas rodarán tanto na parte superior como nos intérpretes.
SAP é un sistema de nivel empresarial, complexo e, por dicilo suavemente, non barato. Gastan orzamentos dignos na súa implementación, modificación e mantemento, e a vida da empresa depende da súa dispoñibilidade e funcionamento correcto. Agora imaxina as consecuencias de parar unha gran produción. Trátase de perdas financeiras, que se poden calcular en números cun gran número de ceros, así como de riscos reputacionais e outros igualmente significativos.
Analizaremos as dificultades que poidan xurdir en cada etapa no caso de migrar sistemas SAP dun dos nosos clientes.
Preparación e deseño
A migración é unha fórmula con moitas partes diferentes. E unha das máis importantes é a fase de deseño e preparación da (nova) infraestrutura obxectivo.
Necesitabamos mergullarnos na implementación existente dos sistemas, na súa arquitectura. Na infraestrutura de destino, repetimos solucións existentes nalgún lugar, complementámolas e mellorámolas nalgúns puntos, refixémolas nalgún lugar, pensamos e seleccionamos solucións para garantir a tolerancia e dispoñibilidade de fallos, e tamén consolidamos todos os recursos na medida do posible.
Durante o proceso de deseño realizáronse moitos exercicios diferentes, que finalmente permitiron preparar o máximo posible para a migración e ter en conta todo tipo de matices e trampas (máis delas máis adiante).
O que acabamos é unha infraestrutura de nube privada deseñada individualmente baseada no noso centro de datos:
- servidores físicos dedicados para SAP HANA;
- Plataforma de virtualización VMware para servidores de aplicacións e servizos de infraestrutura;
- canles de comunicación duplicadas entre centros de datos para VPN L2;
- dous sistemas principais de almacenamento para separar o produto e "todo o demais";
- SRC baseado en Veritas Netbackup cun servidor separado, estante de discos e biblioteca de cintas.
E velaí como implementamos todo isto dende o punto de vista técnico.
SAP
- Para utilizar de forma eficaz o almacenamento para HANA produtivo, utilizamos discos compartidos sen replicación de bases de datos sistémicas mediante SAP. Todo isto foi envolto nun clúster SUSE HAE en espera activa baseado en Pacemaker. Si, o tempo de recuperación é un pouco máis longo que coa replicación, pero aforramos espazo de almacenamento á metade e, como resultado, aforramos o orzamento do cliente.
- Nos contornos de preprodución, os clústeres de HANA foron abandonados, pero tecnicamente repetiuse a configuración de produción.
- Os contornos de proba e desenvolvemento distribuíronse en varios servidores máis sen clúster nunha configuración MCOS.
- Todos os servidores de aplicacións foron virtualizados e aloxados en VMware.
Сети
- Separamos fisicamente os contornos das redes de control e produción con pilas de interruptores, dirixindo os produtivos cara aos centros de datos do cliente.
- Instalamos un número suficiente de interfaces de rede para non mesturar grandes fluxos de tráfico.
- Para transferir datos desde sistemas de almacenamento, creamos fábricas FC SAN clásicas.
SHD
- A carga produtiva e preprodutiva de SAP quedou na matriz totalmente flash.
- Os ambientes de proba de programadores e os servizos de infraestrutura colocáronse nunha matriz híbrida separada.
IBS
- Feito usando Veritas Netbackup.
- Engadimos un pouco aos scripts integrados para facer copias de seguridade das configuracións MCOS.
- Poñemos copias operativas nun estante de discos para unha recuperación rápida e usamos cintas para almacenamento a longo prazo.
Seguimento
- Todo o hardware, OS e SAP instaláronse baixo Zabbix.
- Recopilamos moitos paneis útiles en Grafana.
- Cando se produce unha alerta, Zabbix pode crear unha solicitude no sistema de xestión de incidentes; témolo implementado en Jira. A información tamén se duplica na canle de Telegram.
Telegrama
Saúde xeral de HANA
Estado do servidor de aplicacións SAP:
Servizos de infraestrutura
- Para dar servizo aos espazos de nomes internos, levantouse un clúster de servidores DNS, que está sincronizado cos servidores do cliente.
- Creamos un servidor de ficheiros separado para o intercambio de datos.
- Para almacenar varias configuracións, engadiuse Gitlab.
- Para varias informacións sensibles tomamos HashiCorp Vault.
Proceso migratorio
En xeral, o proceso de migración consta das seguintes etapas:
- preparación de toda a documentación do proxecto necesaria;
- negociacións co provedor actual - resolver problemas organizativos;
- compra, entrega e instalación de novos equipos para o proxecto;
- proba de migración e depuración de procesos;
- transferencia de sistemas, combate a migración.
A finais de outubro de 2019 asinamos un contrato, despois deseñamos a arquitectura e, logo de acordo co cliente, pedimos o equipamento necesario.
O que debes prestar atención primeiro é o prazo de entrega do equipo. De media, a entrega de hardware certificado para SAP NAHA que cumpra os requisitos do fabricante de software para plataformas de hardware leva entre 10 e 12 semanas. E tendo en conta a estacionalidade (a execución do proxecto recaeu exactamente no ano), este período podería ter aumentado un mes máis. En consecuencia, foi necesario axilizar o proceso ao máximo: traballamos co distribuidor-provedor e acordamos a entrega acelerada en avión (en lugar de rutas terrestres e marítimas).
Novembro e decembro pasáronse preparando a migración e recibindo parte do equipamento. Levamos a cabo a preparación nun banco de probas na nosa nube pública, onde traballamos todos os pasos principais e detectamos posibles dificultades e problemas:
- preparou un plan detallado para a interacción entre os membros do equipo do proxecto con horarios minuto a minuto;
- construíu un banco de probas para os servidores de bases de datos e aplicacións aproximadamente do mesmo xeito que na infraestrutura de destino;
- configurou as canles de comunicación e os servizos de infraestrutura necesarios para probar o funcionamento das integracións;
- elaborou escenarios de corte;
- A nube tamén nos axudou a crear modelos de máquinas virtuais preconfigurados, que despois simplemente importamos e despregamos na paisaxe de destino.
Pouco antes das vacacións de Ano Novo chegounos o primeiro lote de equipamento. Isto fixo posible implantar algúns sistemas en hardware real. Como non chegou todo, conectamos equipos de substitución, cuxa subministración conseguimos pactar co vendedor e distribuidores. Recibimos os restos da infraestrutura obxectivo na fase final.
Para cumprir co prazo, os nosos enxeñeiros tiveron que sacrificar as vacacións do ano novo e comezar o 2 de xaneiro, en plenas vacacións, os traballos de preparación da infraestrutura de destino. Si, isto ocorre ás veces cando está en chamas e simplemente non hai outras opcións. Estaba en xogo o rendemento dos sistemas dos que depende a vida da empresa.
A orde xeral da migración semellaba así: primeiro, os sistemas menos críticos (paisaxe de desenvolvemento, paisaxe de proba), despois os sistemas produtivos. A etapa final da migración tivo lugar a finais de xaneiro e principios de febreiro.
O proceso de migración planificouse ao minuto. Este é un plan de corte cunha lista de todas as tarefas, o tempo de realización e as persoas responsables. Todos os pasos xa estaban traballados na migración de proba, polo que na migración en directo só era necesario seguir o plan e coordinar o proceso.
A migración realizouse de forma sistemática en varias etapas. Hai dous sistemas en cada etapa.
O resultado dun sprint de tres meses foi un sistema que está totalmente operativo no centro de datos CROC. En xeral, acadouse un resultado positivo a través do traballo en equipo, a contribución e dedicación de todos os participantes no proceso foi máxima.
O papel do cliente no proxecto
Non foi doado comunicarse co provedor que deixaba o noso cliente. Isto é comprensible, foron os últimos da lista de persoas interesadas na finalización exitosa do proxecto. O cliente asumiu a tarefa de escalar e pedalear todos os problemas de comunicación e enfrontouse a este 100500%. Grazas especial a el por isto. Sen esa participación viable no proceso, o resultado do proxecto podería ter sido completamente diferente.
Debido á formalización de procesos por parte do "antigo" provedor, o apoio á infraestrutura foi realizado por especialistas que estaban literalmente lonxe dos problemas, naquel momento aínda o seu cliente. Por exemplo, o proceso de exportación da mesma base de datos pode levar entre unha hora e cinco. Entón parecía que se trataba dunha especie de maxia, un segredo que nunca nos foi revelado. Probablemente os enxeñeiros de soporte técnico entremáronse á meditación mentres tanto, esquecendo que nalgún lugar da distante Rusia hai prazos, enxeñeiros sen ensaladas de ano novo, o cliente chora e sofre...
Resultados do proxecto
O paso final da migración foi a transferencia de sistemas para o mantemento.
Agora ofrecemos un servizo de xanela única para as solicitudes dos clientes e cubrimos todo o ámbito das tarefas relacionadas co soporte de compoñentes de infraestrutura e a base de SAP xunto co noso socio itelligence. O cliente leva seis meses vivindo nunha nube privada. Estas son as estatísticas dos casos de servizo durante este tempo:
- 90 incidencias (20% resoltas sen implicar o cliente)
- Resolveuse dentro do SLA: 100 %
- Apagados non programados do sistema - 0
Se tes problemas similares aos do noso cliente, e queres saber máis sobre como resolvelos, escribe a: [protexido por correo electrónico]
Fonte: www.habr.com