SAP HANA es una excelente plataforma, sin embargo, muchos clientes se resisten a migrar sus sistemas a ella por los elevados costos del hardware.
Por otro lado, algunos consideran que es una plataforma muy rígida que los obliga a cambiar sus proveedores habituales de HW, no facilita la reutilización de equipos existentes e incluso, no se acomoda a sus procesos de operación en el data center. Para todos ellos, la iniciativa de SAP, HANA Openness es una muy buena noticia, pues ha hecho más accesible esta plataforma desde el punto de vista del hardware, al dar a los clientes más opciones que se traducen en mayor flexibilidad y en una reducción de costos de implementación. El objetivo de SAP es facilitar su implementación e ir acercando los costos de HANA a los de otras plataformas.
SAP HANA Openness ha tenido varios hitos en el último año, dentro de los cuales hay algunos recientes que queremos transmitir a nuestros clientes. Haciendo un recuento, podemos destacar lo siguiente:
- Durante la segunda mitad del año pasado SAP liberó una iniciativa llamada Tailored Datacenter Integration(TDI), que permite a los clientes combinar servidores con storage certificados independientemente. Anteriormente HANA se vendía solo como appliance, es decir una configuración completa y rígida, que venía integrada por el hardware vendor. TDI quebró ese modelo y permitio trabajar con la combinación de servidores y storage que más le gustara al cliente. Por ejemplo, si un cliente prefiere usar servidores de IBM y storage Netapp ahora puede hacerlo sin problemas. Las configuraciones de IBM están certificadas por sus propias tecnologías de almacenamiento, en tanto Netapp tiene configuraciones certificadas con Cisco y con Fujitsu,pero no con IBM. Antes, el cliente estaba amarrado a comprar un paquete certificado como un appliance y gracias a TDI pudo montar un hardware en un servidor certificado, que no necesariamente lo fuera para actuar como appliance, sino que podía tener certificaciones independientes. Todo esto le le dio mayor flexibilidad a la plataforma. Además ya no es necesario que sea instalada por el hardware vendor, si no que cualquier persona certificada puede hacerlo.
- Otro hito importante fue la certificación de HANA para operar en ambientes virtualizados con VMware. En una primera etapa fue solo en ambientes no productivos, pero ya a mediados de 2014 se permitió en ambientes productivos con la restricción de máximo una máquina virtual por cada servidor físico. Si bien es un uso muy limitado, permitía beneficiarse de algunas características de la virtualización, como por ejemplo, mover un sistema HANA de un servidor físico a otro, sin ventana de mantenimiento, ya sea para una contingencia o para hacerlo crecer, sin necesidad de una migración.
En octubre de 2014, durante el TechED, SAP anunció dos nuevas mejoras:
- Hasta ahora todos los servidores que están certificados para HANA ocupan procesadores Intel de la línea E7, la línea high end de Intel. Son servidores robustos, pero con igual capacidad que otros que resultan más caros. SAP anunció que va a certificar configuraciones que estén basadas en procesadores de la línea Intel E5 y eso va a permitir una opción de menor costo, especialmente para los clientes que necesitan sistemas HANA pequeños, de hasta 256 GB en Ram.
Actualmente los hardware vendor están trabajando en obtener las certificaciones para este tipo de servidores. Se espera que en los próximos dos o tres meses estén disponibles en el mercado, esto significa que el equipamiento HANA para las instalaciones pequeñas va a tener una reducción muy importante en su costo.
- Hay nuevos escenarios soportados que permiten un mejor uso de plataforma virtualizadas.
El primero está en categoría “general availability”, es decir, está disponible para cualquier cliente sin autorización previa y permite tener un servidor HANA que comparta el servidor con otras máquinas virtuales no HANA, con la condición de que se le dé a HANA prioridad en el acceso a los recursos del servidor. Esto significa por ejemplo, al instalar un BW, puedo combinar en el mismo hardware el servidor de HANA, que es como la base de datos, y los application server, permitiendo así aprovechar mejor los recursos.
El segundo escenario está en categoría “restricted availability” o disponibilidad restringida, lo cual significa que está permitido previa autorización de SAP. Es decir, si alguien desea usarlo, debe escribir un correo a SAP explicando qué es lo que quiere hacer, justificar, y si la respuesta es positiva, puede utilizarlo.
Esta opción permite tener más de un sistema HANA sobre un servidor físico, pudiendo ser más de uno productivo. Es lo que todo el mundo estaba esperando.
Hay clientes que están pensando en tener varios sistemas en HANA, por ejemplo, el ERP y BW, el ERP en productivo con el desarrollo del BW en una caja y al revés, es decir, los dos sistemas cruzados. Así están en hardware distintos, que es lo recomendado, pero permitiendo un uso más eficiente de los servidores. Antes no había ninguna forma de compartirlo, tenía que tener una caja para el ERP productivo, otra para el BW productivo y, con un poco de suerte, se podía mezclar los ambientes no productivos en una tercera caja.
Como se observa, ha habido una evolución en el tiempo de la iniciativa de Openness, que va permitiendo que HANA sea cada vez más flexible y accesible en costos a todos los clientes.
Feedback/discusión sobre estos temas con patricio.renner@noviscorp.com
Mas información de SAP HANA Openess en http://hana.sap.com/abouthana/hana-technology/data-compatibility.html
Notas relacionadas:
Si alguien todavía no está seguro de qué pueda esperar de migrar su ERP a SAP HANA, tenemos un servicio que le ayudará a aclarar las dudas.
