Cómo prepararse para una instalación de SAP HANA

Primero, el hardware

Para el hardware, tenemos la opción de comprar hardware de una variedad de proveedores aprobados. A principios de este año, SAP comenzó a permitir a los clientes que llevaran su propio hardware para usarlo con las licencias de HANA. Los clientes todavía deben tener la combinación adecuada de especificaciones de hardware (memoria, unidades de estado sólido para los archivos de registro, unidades rápidas para los datos, la proporción adecuada de memoria y núcleos de CPU, etc.), pero parece que SAP está aflojando sus estrictas reglas en dispositivos HANA. También sabemos que SAP permitirá a los clientes realizar sus propias instalaciones de HANA. A partir de  mayo pasado, VMware está certificado para una instancia de HANA de hasta 1TB. Añadir socios de virtualización a la mezcla con el hardware proporcionará a los clientes aún más opciones de respaldo y recuperación.

Al planificar un paisaje HANA, podemos utilizar el tradicional paisaje de tres sistemas en el que cada instancia es aislada de las actividades en la otra. Por ejemplo, puede utilizar una pieza de hardware para cada componente del ciclo de vida de desarrollo de software –una para el desarrollo, uno para la garantía de calidad (QA) y uno para la producción. HANA tiene la capacidad de soportar más de una base de datos HANA por servidor. Por ejemplo, podríamos ser capaces de aprovechar una única pieza de hardware para el sandbox y el desarrollo, mientras se utiliza otra para el control de calidad y el entrenamiento. HANA también nos permite realizar instalaciones distribuidas en las que tenemos nodos maestros y trabajadores, lo que nos permite configurar fácilmente un entorno en control de calidad para que coincida con su escenario de producción, en el cual podría tener múltiples nodos en producción. Por ejemplo, dos nodos podrían soportar una única instancia de desarrollo HANA y una instancia distribuida de control de calidad.

Al planificar el hardware para un entorno de producción, también debemos tener en cuenta nuestras necesidades de estrategia de respaldo y de recuperación de desastres. En mi opinión, un ambiente "activo-activo" es uno donde ambos hosts están aceptando solicitudes. Y si falla un host, las conexiones de cliente pueden inmediatamente ser restablecidas. Dentro de un entorno HANA, SAP no proporciona esta configuración de clúster "activo-activo". SAP provee una conmutación por error automática de host, que también requiere algunos cambios de DNS que se pueden automatizar igualmente. ¿Esto es inmediato? No. ¿Pero puede ser rápido? Sí.

Podemos utilizar un sistema de espera replicado que permitirá una conmutación por error en cuestión de minutos, pero no es verdadera alta disponibilidad como la entendemos con NetWeaver. En el escenario de base de datos de espera replicada, tenemos que recordar dos puntos clave. Uno, tendremos que re-apuntar las peticiones de base de datos de clientes a través de cambios de DNS en el caso de una conmutación por error; y dos, podemos utilizar la base de datos de espera como base de datos no productiva para otra instancia, digamos, para control de calidad y pruebas. Nosotros en NIMBL estamos impresionados con la flexibilidad que ofrece SAP con su escenario de base de datos de espera. SAP ha puesto mucha consideración en permitir que los clientes puedan hacer el mejor uso del hardware, para que no tengamos máquinas ociosas en nuestro centro de datos.

Los respaldos

Trabajar con respaldos en HANA debe ser familiar para cualquier administrador de centro de datos o ejecutivo de TI de nivel medio. Debemos respaldar la base de datos y los archivos de registro de forma recurrente para proporcionar una recuperación de punto en el tiempo. Fuera de la caja, podemos realizar las copias de seguridad a través de SAP HANA Studio o la línea de comandos a nivel de sistema operativo. Vemos a varios clientes explorando socios de respaldo certificados en HANA como Symantec, IBM, HP, etc. La certificación específica que los socios son capaces de lograr para respaldar HANA se llama HANA-Brint 1.1. Usted puede encontrar varios productos de respaldo en la tienda de SAP cuando busque "HANA-Brint 1.1".

Ahora que entendemos lo que constituye HANA, la siguiente pregunta es: "¿Cómo vamos a estructurar nuestro panorama y cómo vamos a respaldar nuestro panorama?" Además, implementar HANA impacta en las demandas de conjuntos de habilidades en los recursos internos. Desde la perspectiva de la administración, los especialistas en SAP Basis Administrators deben realizar fácilmente la transición a ser administradores HANA si tienen experiencia soportando las plataformas UNIX. El mecanismo de instalación para HANA se ve y se siente como SAP. Todavía tenemos que conectar HANA a SAP Solution Manager para servicios de soporte corporativo (más a seguir sobre este tema), que es una tarea común Basis que realizamos con cualquier instalación de SAP NetWeaver. Los administradores Basis idealmente darán la bienvenida a la nueva tecnología y estarán contentos de soportarla. Tener una base de datos en memoria le añade otra dimensión de monitoreo del sistema, y SAP hace un buen trabajo proporcionando las herramientas que necesitamos tanto para análisis de desempeño en tiempo real, como para el análisis histórico.

Seguridad y soporte

Gestionar la seguridad en HANA es una de las mayores áreas de cambio, en mi opinión, para los clientes que actualmente tienen equipos de seguridad gestionando la seguridad de aplicaciones en  SAP Business Suite u otras aplicaciones basadas en NetWeaver. Si está ejecutando NetWeaver BW o SAP Business Suite sobre HANA, el equipo de seguridad seguirá trabajando mañana como lo hace hoy. Sin embargo, si decide implementar HANA como un almacén de datos independiente o un servidor de aplicaciones, el equipo de seguridad requerirá un considerable tiempo de aceleración. Responder a la pregunta: "¿Quién debe realizar la seguridad en HANA?”, es aún discutible para mí. En el mundo del sistema de gestión de base de datos tradicional, un administrador de base de datos (DBA) podría llevar a cabo la administración de la seguridad, además de actividades de DBA. En entornos SAP NetWeaver, muy rara vez la seguridad funciona en la capa en la que ocurre la base de datos, ya que SAP gestiona la seguridad en la capa de aplicación. En el escenario de un almacén de datos independiente, podríamos requerir autorizaciones por código de compañía u organización de ventas. Los administradores Basis rara vez son buenos administradores de seguridad. Si soy un cliente enfrentando un despliegue de producción de HANA, entonces yo tendría que mirar a la experiencia interna y los requisitos para determinar quién asumirá la administración de seguridad de HANA.

Un punto clave que algunos clientes pueden olvidar o entender mal es el uso de Solution Manager con su despliegue HANA. Solution Manager sigue siendo el único mecanismo para HANA Early Watch Reports, y es el vehículo para SAP Continuos Quality Checks, que están incluidos como parte de cada acuerdo de mantenimiento de clientes de SAP, estándar o para empresas. Los clientes que están invirtiendo gastos significativos en un despliegue HANA deben absolutamente tomar ventaja de los servicios de verificación Going Live de SAP antes de poner en funcionamiento HANA. Solution Manager sigue siendo la puerta de entrada hacia el soporte de SAP. Junto con sus capacidades de monitoreo proactivo –incluido como parte de las operaciones técnicas de Solution Manager– Solution Manager debe ser parte del plan de despliegue de HANA de todos los clientes.

Implementar HANA es de hecho emocionante, y obviamente existen retos, pero con la colaboración y el intercambio de conocimientos, su nuevo despliegue tiene una tremenda oportunidad para complementar su propio mundo SAP. Esto es solo el comienzo; no puedo esperar por lo que venga después.

Acerca del autor: Michael Pytel es el director de innovación y co-fundador de la consultoría NIMBL, con sede en Denver. Puede encontrarlo en: [email protected] o en Twitteren @michaelpytel.