Mantenimiento impuesto, hojas de ruta poco claras

Los clientes de SAP están insatisfechos, se han escrito muchas líneas sobre cómo y por qué. Mantenimiento impuesto, elevados costes de licencia y hojas de ruta poco claras son algunos de los puntos que se mencionan una y otra vez. Pero, ¿no es precisamente en este momento cuando el gremio de los consultores tecnológicos realiza una importante contribución?

La tecnología subyacente de un sistema SAP no ha cambiado a lo largo de los años. Consiste en un sistema operativo, un montón de archivos ejecutables y una base de datos. Así es, así era y así seguirá siendo por ahora. Ni siquiera la tendencia hacia la nube y S/4 cambiará esto por el momento. Un sistema SAP sigue siendo un sistema SAP.

Buenas condiciones

Muchas empresas, ya sean internas o de consultoría, siguen instalando el software manualmente, paso a paso. Muy pocas utilizan herramientas automáticas y, si lo hacen, es por un buen dinero. Las herramientas de código abierto y sus posibilidades no se utilizan. Especialmente en Alemania, parece que las buenas soluciones siempre cuestan algo. ¿Sigue siendo esto acorde con los tiempos? ¿O tenemos que dar el siguiente paso?

Docker existe desde 2013, Ansible desde 2012, Kubernetes desde 2015. Sin embargo, la tecnología SAP a menudo parece ir a la zaga de la tendencia hacia una mayor agilidad y flexibilidad. El despliegue automático es rudimentario, el rolling kernel switch rara vez se utiliza. La Infraestructura como Código y el Containering parecen haber eludido completamente a SAP hasta ahora. Sin embargo, un sistema SAP ofrece en realidad buenas condiciones para aplicar un enfoque de este tipo.

Así que las preguntas son sencillas: ¿Nos hemos dormido todos? ¿Acaso no podemos desplegar ya hoy los sistemas SAP de forma automática? ¿Y hasta qué punto está ya integrada la implantación automática? Echemos un vistazo a diferentes aspectos de un sistema SAP. Al principio de la vida de un sistema SAP siempre está la cuestión de la estructura y la configuración: ¿Cuántos usuarios trabajan en el sistema? ¿Cuántos sistemas debo conectar a mi sistema SAP y cómo? ¿Sólo necesito un sistema de producción o también son necesarias las pruebas y el desarrollo?

Sobre todo en las pequeñas y medianas empresas, se suele optar por un entorno de 3 sistemas, consistente en una combinación de base de datos y servidor de aplicaciones. A menudo, sólo se utiliza un servidor de aplicaciones, también para reducir costes. Con respecto a Hana, los cálculos suelen hacerse sobre la marcha y se centran principalmente en los costes. Muchas empresas siguen planificando con sus propios centros de datos o externalizando el hardware.

A menudo se pasan por alto las posibilidades a derecha e izquierda de la corriente dominante. Imagine el siguiente escenario: Usted es una empresa comercial de tamaño medio que desea migrar su SAP ECC 6.0 EHP 7 de AnyDB a Hana con garantía de futuro. Los informes de dimensionamiento le dan un requisito de almacenamiento de 1,5 TB para una instancia de Hana y se supone que hay unos 500 usuarios trabajando en el sistema en todo el mundo.

Dado que opera en todo el mundo, naturalmente desea que su sistema productivo esté altamente disponible. Ya ha externalizado el desarrollo y, de todos modos, sus colegas sólo trabajan durante el horario laboral normal. Por supuesto, ahora podría implantar una nueva solución de virtualización y adquirir el hardware correspondiente. Los datos, la instalación y el mantenimiento están en sus manos. Si es necesario, aún puede recurrir a un socio externo para obtener asistencia.

Inesperadamente, su departamento quería un sistema de almacén empresarial. Sin embargo, el hardware no estaba diseñado para ello.

¿Qué hacer? Piensa en el futuro.

Opción 1: Usted crea nuevo hardware. El proceso de adquisición te costará algún tiempo y necesitas el espacio adecuado en el centro de datos.

Opción 2: Usted construye los sistemas externamente. Se ahorrará definitivamente el tedioso proceso de adquisición de hardware y pondrá la responsabilidad del hardware en otras manos. Ya sea Amazon Web Services, Microsoft Azure, Google Cloud Platform u otro host, la responsabilidad del hardware recae en otra parte. Muchos hosts también asumen la responsabilidad del sistema operativo y la base de datos. Enhorabuena, has llegado a la jungla de los servicios. Solo se te permite utilizar el sistema y cada cambio requiere su propio cambio.

Opción 3: Piense en el futuro. Hasta ahora, ha operado su sistema ERP con un sistema de replicación y desea mantenerlo. ¿Qué le parece externalizar la parte de replicación a la nube? Así dispondrá de espacio para el almacén empresarial deseado y, al mismo tiempo, podrá seguir beneficiándose de las ventajas de la nube.

"¡Pero los costes!", pensarán seguramente algunos ahora. La nube no es barata, ninguna de las Tres Grandes te proporcionará infraestructura gratis, y por supuesto siguen queriendo ganar algo. Pero si utilizas la replicación de sistemas sin precarga de memoria, sólo pagas por un sistema virtual relativamente pequeño y el almacenamiento de la base de datos.

En caso de fallo de la base de datos principal, la máquina virtual en la nube puede ajustarse automáticamente y arrancar en cuestión de segundos. Solo ahora pagas por el tamaño completo de la base de datos Hana.

Si llevamos la idea un poco más lejos, también podríamos realizar servidores de aplicaciones y una instancia de ASCS de alta disponibilidad. Si los distribuimos por todo el mundo, los empleados de Japón y EE.UU. también se alegrarán de tener tiempos de ejecución de GUI más cortos. Por supuesto, se pueden esbozar eternamente otras variantes, pero desgraciadamente pronto se llega a regiones que ya no son sostenibles ni utilizables para una empresa mediana.

En una empresa, siempre hay periodos en los que el usuario final quiere más rendimiento del sistema. La incorporación rápida de un servidor de aplicaciones es sin duda una solución sencilla pero eficaz. Los pasos necesarios son manejables, pero incluso los técnicos experimentados pueden dedicar un día al aprovisionamiento, la instalación y la configuración. ¿Cómo sería si se pudiera automatizar gran parte del aprovisionamiento y la instalación?

¿No puedes? ¡Puedes!

Infraestructura como código, Ansible e instalación desatendida son las palabras mágicas. Todo ello no se limita a uno de los hiperescaladores, sino que también puede ejecutarse fácilmente en cualquier ESXi con VSphere.

Empecemos por la creación de la máquina virtual. En VMware, la máquina virtual suele crearse a partir de otra mediante clonación o a partir de una plantilla. A continuación, se crean las controladoras SCSI y los discos duros necesarios y se integran en el sistema operativo. Ya sea con comandos o con Yast, sólo este paso lleva de dos a tres horas.

Con la automatización de Ansible, podemos completar este primer paso en tan solo unos minutos. Además, ya podemos cargar nuestros medios de instalación para el servidor de aplicaciones desde un repositorio de datos central e iniciar el gestor de aprovisionamiento de software en el mismo paso. Tampoco está de más echar un vistazo a los repositorios de GitHub de Google y Amazon. Aquí seguro que puedes aprender un par de cosas para tus propios scripts.

En el caso de Linux, los scripts no son brujería y cualquiera que ya se haya enfrentado a ellos podrá manejarlos. Descargar y configurar los paquetes SLES necesarios, por ejemplo, se convierte en un script de shell muy breve. Proporcionar los puntos de montaje o grupos de volúmenes y volúmenes lógicos necesarios también se hace en unos pocos comandos familiares para la mayoría de los conocedores de Linux. Windows y Linux nos han enseñado a utilizar interfaces gráficas de usuario bonitas y coloridas, y muchas cosas se pueden hacer con unos pocos comandos. Como además se pueden guardar y combinar, las futuras implantaciones serán cada vez más rápidas.

Obstáculos

Ahora que la VM está desplegada y el sistema operativo configurado, se descargan los medios de instalación necesarios y el SWPM. En el caso de Google Cloud Platform, almacenamos los datos necesarios organizados en un cloud bucket y ahora podemos cargar los datos desde el cloud bucket a la nueva VM utilizando simples comandos gsutil. Por supuesto, este procedimiento también funciona con AWS y Azure, así como con un simple montaje NFS en el entorno VMware.

Después de colocar y desempaquetar el Software Provisioning Manager (en adelante SWPM), es hora de empezar. Hay algunos pequeños escollos que hay que evitar. En primer lugar necesitamos el llamado archivo inifile.params y el archivo instkey.pkey. El inifile.params contiene el contenido y los medios y contraseñas a instalar.

Las contraseñas se cifran con la clave del archivo instkey.pkey. Para obtener ambos ficheros, primero hay que realizar la instalación manualmente y detenerla en la vista general de instalación de SWPM. A continuación, guarde ambos archivos y guárdelos en un lugar seguro. Para sistemas posteriores, puede simplemente cambiar el inifile.params y así realizar instalaciones y, sobre todo, copias de sistema mucho más rápidas.

El segundo punto importante es el ID de producto del sistema que se va a instalar. Se encuentra en el archivo inifile.params y es, como su nombre indica, específico del producto.

Ahora sabemos que es posible instalar sistemas automáticamente con SWPM. Pero, ¿cómo nos ayuda eso en las operaciones cotidianas? Volvamos a nuestro caso práctico inicial, la decisión sobre qué hacer con el nuevo BW y el antiguo ERP.

Simplemente suponemos que los sistemas ERP se van a migrar a uno de los tres grandes proveedores de nube durante la migración a Hana. Si recordamos la estructura de un sistema SAP, podemos utilizar los conocimientos para acelerar significativamente la migración a Hana.

Automatizar las implantaciones

Un sistema SAP consta básicamente de unos pocos archivos ejecutables, los perfiles necesarios y una base de datos con la información de la versión. Para que la migración tenga éxito, sólo es necesario que el núcleo coincida con la información almacenada en la base de datos y que nuestro sistema se ejecute en el nuevo hardware o base de datos. El objetivo debe ser instalar los sistemas en la nube lo más rápidamente posible mediante un despliegue automático. Después, se puede convertir al sistema de origen correspondiente mediante una actualización de la base de datos a través de la exportación/importación.

Por supuesto, podemos automatizar aún más el despliegue de los sistemas. Así pues, los playbooks de Ansible son una ocupación que merece la pena para la crisis actual. Incluso para un consultor SAP con experiencia, este tema será un territorio completamente nuevo al principio, pero la comunidad y Red Hat han documentado completamente las funciones más importantes.

Las funciones básicas para proporcionar un sistema se definen en un playbook. Coloquialmente, se trata de una colección de tareas que deben ejecutarse en el host correspondiente. Desde la creación de grupos de volúmenes, pasando por la creación de usuarios y grupos, hasta el inicio de scripts, prácticamente todo es posible. Sin más intervención, podemos instalar sistemas o servidores de aplicaciones, hacer copias del sistema o incluso desinstalar cosas.

Como puede ver, no le he dado aquí una guía completa para el despliegue automático de sistemas SAP. Tampoco es posible, ya que cada entorno de sistemas y cada necesidad es diferente. El camino y la decisión de transformarse a la nube son tan individuales como posibilidades existen. Todas las posibilidades descritas también son posibles en su propio centro de datos y con VMWare y no requieren una gran infraestructura de nube. En última instancia, como suele ocurrir, será el paisaje de sistemas híbridos el que encontremos.