¿O es posible? Por supuesto, la migración de sistemas SAP es un proceso complejo y laborioso, cuyo éxito requiere el trabajo bien coordinado de todos los participantes. Y si la migración se realiza en poco tiempo, la tarea se vuelve mucho más complicada. No todo el mundo decide hacer esto. Puede haber varias razones. Por ejemplo, el proceso en sí es largo y complejo desde el punto de vista organizativo. Además, existe el riesgo de que se produzca una inactividad no planificada del sistema. O los clientes no están seguros de que, tras someterse a una operación de este tipo, recibirán beneficios acordes con los esfuerzos realizados. Sin embargo, hay excepciones.
Debajo del corte, hablaremos sobre las dificultades que enfrentan los clientes en el proceso de migración y mantenimiento de sistemas SAP, discutiremos por qué los estereotipos no siempre corresponden a la realidad y compartiremos un estudio de caso de cómo logramos migrar los sistemas de un cliente a un nueva infraestructura en poco más de tres meses.
Alojamiento de sistemas SAP.
Hace apenas cinco años, era difícil imaginar que los clientes comenzarían a utilizar masivamente recursos de hosting para aplicaciones SAP. En la mayoría de los casos se implementaron on-premise. Sin embargo, con el desarrollo de los modelos de subcontratación y el mercado de servicios en la nube, la visión del mundo de los clientes comenzó a cambiar. ¿Cuáles son los argumentos que influyen en la elección de SAP a favor de la nube?
- Para los principiantes que acaban de planear implementar SAP, la infraestructura en la nube es casi una opción estándar: escalabilidad de recursos a las necesidades actuales del sistema y falta de voluntad para desviar recursos al desarrollo de competencias no básicas.
- En empresas con un gran panorama de sistemas, con la ayuda del alojamiento de sistemas SAP, los CIO alcanzan un nivel cualitativamente diferente de gestión de riesgos, porque El socio es responsable del SLA.
- El tercer argumento más común es el alto costo de construir infraestructura para implementar escenarios de recuperación ante desastres y alta disponibilidad.
- Factor 2027: el proveedor anunció el fin del soporte para sistemas heredados en 2027. Esto significa transferir la base de datos a HANA, lo que conlleva costes de modernización y compra de nueva potencia informática.
El mercado de alojamiento de SAP en Rusia ahora puede considerarse bastante maduro. Y esto brinda amplias oportunidades para los clientes que desean cambiar sus plataformas de alojamiento. Sin embargo, estos proyectos pueden, con razón, causar preocupación entre las empresas debido a la complejidad del procedimiento de migración. Esto obliga a los clientes a imponer mayores exigencias a los proveedores de servicios, que deben tener no sólo competencias excepcionales en el alojamiento y mantenimiento de sistemas SAP, sino también experiencia exitosa en el campo de la migración.
¿Cuáles son las dificultades de cambiar el hosting de SAP?
Los hosting son diferentes. Inconsistencia con el nivel de servicio declarado, muchos "peros" y asteriscos con reservas en texto pequeño, recursos y capacidades limitados del proveedor de hosting, falta de flexibilidad en materia de comunicación con el cliente, burocracia, limitaciones técnicas, baja competencia del soporte técnico especialistas, así como muchos otros matices: estos son solo una pequeña parte de los peligros que pueden encontrar los clientes al operar sus sistemas comerciales en infraestructuras de subcontratación. A menudo, para el cliente, todo esto permanece en la sombra, en la jungla de un contrato de varias páginas, y emerge en el proceso de utilización de los servicios.
En algún momento, al cliente le resulta obvio que el nivel de servicio que recibe está lejos de sus expectativas. Se trata de una especie de catalizador para encontrar soluciones que corrijan la situación y, en caso de fracaso, cuando los problemas se acumulan hasta el límite y se vuelve muy doloroso, se pasa a acciones activas para desarrollar opciones alternativas en la dirección de cambiar de proveedor de servicios. .
¿Por qué esperan hasta el último momento? La razón es simple: el proceso de migración de sistemas para los clientes no siempre es transparente y comprensible. Es difícil para el cliente evaluar los riesgos reales asociados con el proceso de migración. Podemos decir que la migración para los clientes es una especie de caja negra: no está claro el precio, el tiempo de inactividad del sistema, los riesgos y cómo mitigarlos y, en general, es oscuro y aterrador. Es como si no funciona, entonces las cabezas rodarán tanto en la cima como en los artistas.
SAP es un sistema de nivel empresarial, complejo y, por decirlo suavemente, nada barato. Se gastan presupuestos decentes en su implementación, modificación y mantenimiento, y la vida de la empresa depende de su disponibilidad y correcto funcionamiento. Ahora imaginemos las consecuencias de detener una gran producción. Se trata de pérdidas financieras, que pueden calcularse en cifras con un gran número de ceros, así como riesgos reputacionales y otros riesgos igualmente importantes.
Analizaremos las dificultades que pueden surgir en cada etapa en el caso de migrar sistemas SAP de alguno de nuestros clientes.
Preparación y diseño
La migración es una fórmula con muchas partes diferentes. Y una de las más importantes es la etapa de diseño y preparación de la (nueva) infraestructura objetivo.
Necesitábamos sumergirnos en la implementación existente de los sistemas, su arquitectura. En la infraestructura de destino, repetimos las soluciones existentes en algún lugar, las complementamos y mejoramos en algunos puntos, las rehicimos en algún lugar, pensamos y seleccionamos soluciones para garantizar la tolerancia a fallas y la disponibilidad, y también consolidamos todos los recursos tanto como fue posible.
Durante el proceso de diseño, se realizaron muchos ejercicios diferentes, que finalmente permitieron prepararse lo más posible para la migración y tener en cuenta todo tipo de matices y trampas (más sobre ellos más adelante).
Al final obtuvimos una infraestructura de nube privada diseñada individualmente basada en nuestro centro de datos:
- servidores físicos dedicados para SAP HANA;
- Plataforma de virtualización VMware para servidores de aplicaciones y servicios de infraestructura;
- canales de comunicación duplicados entre centros de datos para VPN L2;
- dos sistemas principales de almacenamiento para separar el producto y “todo lo demás”;
- SRC basado en Veritas Netbackup con un servidor, estante de discos y biblioteca de cintas independientes.
Y así es como implementamos todo esto desde un punto de vista técnico.
SAP
- Para utilizar eficazmente el almacenamiento para HANA productivo, utilizamos discos compartidos sin replicación sistémica de bases de datos mediante SAP. Todo esto se envolvió en un clúster SUSE HAE activo-en espera basado en Pacemaker. Sí, el tiempo de recuperación es un poco más largo que con la replicación, pero ahorramos la mitad del espacio de almacenamiento y, como resultado, ahorramos el presupuesto del cliente.
- En entornos de preproducción, se abandonaron los clústeres de HANA, pero técnicamente se repitió la configuración de producción.
- Los entornos de prueba y desarrollo se distribuyeron en varios servidores más sin clústeres en una configuración MCOS.
- Todos los servidores de aplicaciones fueron virtualizados y alojados en VMware.
red
- Separamos físicamente los contornos de las redes de control y producción con pilas de conmutadores, dirigiendo las productivas hacia los centros de datos del cliente.
- Instalamos una cantidad suficiente de interfaces de red para no mezclar grandes flujos de tráfico.
- Para transferir datos desde sistemas de almacenamiento, creamos fábricas FC SAN clásicas.
Almacenamiento
- La carga productiva y preproductiva de SAP se dejó en la matriz totalmente flash.
- Los entornos de prueba de los desarrolladores y los servicios de infraestructura se colocaron en una matriz híbrida separada.
SII
- Realizado con Veritas Netbackup.
- Agregamos un poco a los scripts integrados para realizar copias de seguridad de las configuraciones de MCOS.
- Colocamos copias operativas en un estante de discos para una recuperación rápida y utilizamos cintas para almacenamiento a largo plazo.
Monitoreo
- Todo el hardware, sistema operativo y SAP se instalaron bajo Zabbix.
- Hemos recopilado muchos paneles útiles en Grafana.
- Cuando se produce una alerta, Zabbix puede crear una solicitud en el sistema de gestión de incidencias, lo tenemos implementado en Jira. La información también está duplicada en el canal de Telegram.
Telegram
Salud general de HANA
Estado del servidor de aplicaciones SAP:
Servicios de infraestructura
- Para dar servicio a los espacios de nombres internos, se creó un grupo de servidores DNS, que se sincroniza con los servidores del cliente.
- Creamos un servidor de archivos separado para el intercambio de datos.
- Para almacenar varias configuraciones, se agregó Gitlab.
- Para obtener información confidencial diversa, tomamos HashiCorp Vault.
Proceso de migración
En general, el proceso de migración consta de las siguientes etapas:
- preparación de toda la documentación necesaria del proyecto;
- negociaciones con el proveedor actual: resolución de problemas organizativos;
- compra, entrega e instalación de nuevos equipos para el proyecto;
- probar la migración y la depuración de procesos;
- transferencia de sistemas, lucha contra la migración.
A finales de octubre de 2019 firmamos un contrato, luego diseñamos la arquitectura y, tras acordar con el cliente, encargamos el equipamiento necesario.
Lo primero a lo que debes prestar atención es al tiempo de entrega del equipo. En promedio, la entrega de hardware certificado para SAP NAHA que cumpla con los requisitos del fabricante de software para plataformas de hardware demora entre 10 y 12 semanas. Y teniendo en cuenta la estacionalidad (la implementación del proyecto coincidió exactamente con el Año Nuevo), este período podría haberse incrementado un mes más. En consecuencia, era necesario acelerar el proceso al máximo: trabajamos con el distribuidor-proveedor y acordamos una entrega rápida por avión (en lugar de por vía terrestre y marítima).
Noviembre y diciembre los pasamos preparándonos para la migración y recibiendo parte del equipo. Llevamos a cabo la preparación en un banco de pruebas en nuestra nube pública, donde trabajamos en todos los pasos principales y detectamos posibles dificultades y problemas:
- preparó un plan detallado para la interacción entre los miembros del equipo del proyecto con tiempos minuto a minuto;
- construyó un banco de pruebas para la base de datos y los servidores de aplicaciones aproximadamente de la misma manera que en la infraestructura de destino;
- configuró los canales de comunicación y servicios de infraestructura necesarios para probar el funcionamiento de las integraciones;
- elaboraron escenarios de transición;
- La nube también nos ayudó a crear plantillas de máquinas virtuales preconfiguradas, que luego simplemente importamos e implementamos en el entorno de destino.
Poco antes de las vacaciones de Año Nuevo nos llegó el primer lote de equipamiento. Esto hizo posible implementar algunos sistemas en hardware real. Como no llegó todo, conectamos equipos de repuesto, cuyo suministro logramos acordar con el vendedor y los distribuidores. Recibimos los restos de la infraestructura objetivo en la etapa final.
Para cumplir con el plazo, nuestros ingenieros tuvieron que sacrificar las vacaciones de Año Nuevo y comenzar a trabajar en la preparación de la infraestructura objetivo el 2 de enero, en plenas vacaciones. Sí, esto sucede a veces cuando está en llamas y simplemente no hay otras opciones. Lo que estaba en juego era el rendimiento de los sistemas de los que depende la vida de la empresa.
El orden general de la migración fue el siguiente: primero, los sistemas menos críticos (panorama de desarrollo, panorama de pruebas), luego los sistemas productivos. La etapa final de la migración tuvo lugar a finales de enero y principios de febrero.
El proceso de migración fue planificado al minuto. Este es un plan de transición con una lista de todas las tareas, el tiempo de finalización y las personas responsables. Todos los pasos ya se habían resuelto en la migración de prueba, por lo que en la migración en vivo solo era necesario seguir el plan y coordinar el proceso.
La migración se llevó a cabo sistemáticamente en varias etapas. Hay dos sistemas en cada etapa.
El resultado de un sprint de tres meses fue un sistema que está completamente operativo en el centro de datos de CROC. En general, se logró un resultado positivo gracias al trabajo en equipo, el aporte y dedicación de todos los participantes en el proceso fue máximo.
El papel del cliente en el proyecto.
Comunicarse con el proveedor que nuestro cliente dejaba no fue fácil. Esto es comprensible, ellos eran los últimos en la lista de personas interesadas en la finalización exitosa del proyecto. El cliente asumió la tarea de intensificar y solucionar todos los problemas de comunicación y lo resolvió al 100500-XNUMX%. Un agradecimiento especial a él por esto. Sin una participación tan factible en el proceso, el resultado del proyecto podría haber sido completamente diferente.
Debido a la formalización de los procesos por parte del “antiguo” proveedor, el soporte de la infraestructura fue realizado por especialistas que estaban literalmente lejos de los problemas, en ese momento todavía sus clientes. Por ejemplo, el proceso de exportar la misma base de datos podría tardar entre una hora y cinco. Entonces pareció que se trataba de una especie de magia, un secreto que nunca nos fue revelado. Probablemente los ingenieros de soporte técnico se entregaron mientras tanto a la meditación, olvidando que en algún lugar de la lejana Rusia hay plazos, los ingenieros sin ensaladas de Año Nuevo, el cliente llora y sufre...
Resultados del proyecto.
El paso final de la migración fue la transferencia de sistemas para mantenimiento.
Ahora brindamos un servicio de ventanilla única para las solicitudes de los clientes y cubrimos todo el alcance de las tareas relacionadas con el soporte de los componentes de la infraestructura y la base de SAP junto con nuestro socio itelligence. El cliente lleva seis meses viviendo en una nube privada. Aquí están las estadísticas sobre casos de servicio durante este tiempo:
- 90 incidencias (20% resueltas sin implicar al cliente)
- Resuelto dentro del SLA – 100%
- Apagados del sistema no programados – 0
Si tienes problemas similares a los de nuestro cliente, y quieres saber más sobre cómo solucionarlos, escríbenos a: [email protected]
Fuente: habr.com