SAP HANA – Administration – Página 9

Notas para gestionar las alertas de un sistema SAP HANA

Los administradores de un sistema SAP HANA deben controlar activamente el estado del sistema, los servicios que se están ejecutando y el consumo de los recursos que se esté realizando. Un sistema SAP HANA tiene un amplio conjunto de alertas que comunican sobre situaciones críticas, como por ejemplo consumo elevado de memoria, falta espacio en disco, algún servidor detenido o uso de CPU en límites máximos.

Los administradores de un sistema SAP HANA deben controlar activamente el estado del sistema, los servicios que se están ejecutando y el consumo de los recursos que se esté realizando. Un sistema SAP HANA tiene un amplio conjunto de alertas que comunican sobre situaciones críticas, como por ejemplo consumo elevado de memoria, falta espacio en disco, algún servidor detenido o uso de CPU en límites máximos.

El responsable de recopilar esta información es el Servidor de Estadísticas (Statistics Server) de SAP HANA, este componente verifica constantemente las condiciones para la generación de las alertas. La prioridad de la alerta indica la gravedad del problema y depende de la naturaleza de la comprobación y los valores de umbral configurados en la alerta. Por ejemplo, si se está utilizando el 90% del espacio disponible en el disco, se emite una alerta de baja prioridad, si se llega a utilizar el 98%, se emitirá una alerta de alta prioridad.

Las alertas del sistema se pueden consultar y controlar a través de SAP HANA Studio, tanto los valores actuales como los históricos, almacenados en la base de datos de HANA (esquema _SYS_STATISTICS). Saber gestionar las alertas del sistema SAP HANA es muy importante, a continuación compartimos tres notas que detallan las categorías de alertas más críticas:

Factores que influyen en la rapidez de SAP HANA

SAP HANA es una combinación de hardware y software, ambos, especialmente diseñados para trabajar conjuntamente y brindar el máximo rendimiento en el procesamiento de datos. Pero este máximo rendimiento, que a menudo se refiere como menores tiempos de respuesta en el procesamiento de grandes volúmenes de información, de debe a las tecnologías que se han adoptado en esta plataforma:

SAP HANA es una combinación de hardware y software, ambos, especialmente diseñados para trabajar conjuntamente y brindar el máximo rendimiento en el procesamiento de datos. Pero este máximo rendimiento, que a menudo se refiere como menores tiempos de respuesta en el procesamiento de grandes volúmenes de información, de debe a las tecnologías que se han adoptado en esta plataforma:

Procesamiento en memoria,
Almacenamiento basado en columnas (column-based storage)
Técnicas de compresión de datos
Procesamiento paralelo (multicore CPUs y clusters de servidores)

Bases de datos en memoria

Usando la tecnología de base de datos en memoria es el factor que más influye en los menores tiempos de respuesta, porque evita los accesos a dispositivos electromecánicos como pueden ser los discos duros, considerablemente más lentos que el acceso a la memoria.

Procesamiento lógico en base de datos

Los clásicos sistemas de bases de datos generan un tráfico de ida y vuelta con las aplicaciones que requieren procesar los datos. SAP HANA también se diferencia en este aspecto, al ofrecer la posibilidad de efectuar los cálculos lógicos en la base de datos, evitando el tráfico que repercute en el tiempo global de respuesta.

Almacenamiento en columnas

El almacenamiento en columnas es una técnica optimizada para las tareas de lectura de datos, muy superior al clásico sistema de almacenamiento en filas, optimizado para las tareas de escritura de datos. SAP HANA trabaja con los dos sistemas de almacenamiento, lo usual es que la mayoría de tablas sean de tipo de almacenamiento basado en columnas, a menos que se trate de una tabla con tareas intensivas de inserción/modificación de datos o si se recuperarán en los informes todas las columnas de la tabla.

SAP HANA no escribe directamente sobre las tablas basadas en columnas porque esta no están optimizadas para las tareas de escritura, en estos caso hace uso de tablas temporales del tipo basadas en filas y luego en procesos en segundo plano (Delta Merge) lleva los datos a la respectiva tabla.

Diseño en la Implementación

Hay otros aspectos que también influyen en la rapidez de SAP HANA, ajenos a las consideraciones técnicas de la configuración original de la plataforma, más propios a las tareas que deben realizar los implementadores, tales como el diseño de los modelos de datos y o la construcción de las vistas de información.

Consideraciones básicas para el despliegue de “BW on HANA” (I)

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA” (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

SAP no da soporte al despliegue de múltiples sistemas SAP NW BW en un sistema productivo SAP HANA.
SAP brinda soporte al despliegue de múltiples sistemas SAP NW BW on HANA en arquitecturas de nodo único o multinodo con fines distintos a un entorno productivo, con una base de datos por cada sistema SAP NW BW.
El servidor de base de datos de un sistema BW es desplegado en un esquema de la base de datos SAP HANA. La instancia central del sistema BW y todas las aplicaciones de servidor asociadas no se instalan en el appliance SAP HANA, son instalados en un servidor aparte.
Con respecto al párrafo anterior, existen “excepciones” señaladas en la nota 1661202 que permiten aplicaciones residan en el sistema SAP HANA en un entorno productivo. Si una aplicación que no figura en el listado de excepciones es instalada en BW on HANA en un entorno productivo, esta aplicación no tendría soporte por parte de SAP. En un entono distinto a producción si tendría soporte.
BW on HANA permite la aplicación de técnicas de alta disponibilidad (High Availability – HA) y tolerancia a fallos (Disaster Tolerance – DT). En cuanto a HA sigue los mismos mecanismos que un sistema SAP HANA, a través de la activación de nodos pasivos. En general, especialmente en los casos de DT, estas técnicas pueden variar en función del proveedor de Hardware.
Las técnicas que se aplican en un sistema SAP HANA para evitar que los datos en memoria se pierdan ante un fallo en el servicio eléctrico también incluye los datos de BW on HANA.
Es recomendable tener por los menos tres nodos en un sistema SAP HANA en el que se despliegue BW on HANA. En el nodo principal estarían las tablas con almacenamiento basado en filas y en lo nodos esclavos se tendría las particiones de los infocubos y ODSs (Ref. nota 1702409).
Para información adicional y futuras novedades sobre los aspectos comentados en esta entrada revisar las notas 1666670 y 1661202.

Consideraciones para el despliegue de más de una base de datos SAP HANA

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Hace unos días leíamos un listado de acrónimos y términos vinculados al mundo SAP HANA, una buena referencia, pero faltaría considerar otros como MCOS que corresponden a las iniciales de “Multiple Components One System” que describen la arquitectura de múltiple nodo que se señala en el párrafo anterior. Otro término que también se utiliza en el contexto SAP HANA es “Multi-SID” o MSID (Multiple Database on one SAP HANA appliance) que hace referencia a la posibilidad de configurar más de una base de datos en un sistema SAP HANA.

Cabe recordar que en un entorno productivo HANA sólo tendrá soporte si tiene una única base de datos en el sistema (SIDS). Es posible tener más de una base de datos HANA, pero sólo debería ser considerado en entornos que no son con fines de producción, tales como los clásicos entornos de pruebas o desarrollo. Esta consideración se aplica tanto si se trata de una arquitectura de un nodo o multinodo.

Un appliance HANA, recién entregada por los partners de hardware, lo encontraremos con una base de datos SAP HANA, usando “On-Site Configuration tool” se podrá configurar una base de datos adicional, para lo cual deberá considerar lo siguiente:

No debería realizarse en un entorno productivo.
Se debería contar con la configuración de hardware necesaria para soportar el despliegue de más de una base de datos (especialmente en cuanto a memoria).
Se debe tener en cuenta que se puede perder rendimiento o velocidad en la ejecución de varios procesos.
Si hubiera problemas en el sistema y se solicitará el servicio de soporte de SAP, podría indicarse detener las bases de datos para comprobar si el problema es originado por la configuración de las bases de datos adicionales.
Para más información y futuras novedades revisar las notas 1681092 y 1661202.

Conceptos básicos sobre gestión de usuarios en SAP HANA

La autorización que tiene un usuario para “hacer algo” sobre determinados “recursos de la base de datos” de SAP HANA, se denomina “privilegios” y la agrupación de estos privilegios para más fácilmente asignarlos a los usuarios, se denomina “roles”. En el sistema SAP HANA tenemos dos grandes categorías de usuarios:

La autorización que tiene un usuario para “hacer algo” sobre determinados “recursos de la base de datos” de SAP HANA, se denomina “privilegios” y la agrupación de estos privilegios para más fácilmente asignarlos a los usuarios, se denomina “roles”. En el sistema SAP HANA tenemos dos grandes categorías de usuarios:

Database Users. Un usuario de base de datos es un usuario que podrá trabajar con los recursos de SAP HANA Database.
Operating System User. Son usuarios con acceso total a los recursos del sistema, también son referidos como administradores de la operativa del sistema, son los únicos que puede iniciar o detener un servicio o componente del sistema. Un usuario operador del sistema no es un usuario de base de datos.

Usuarios técnicos

Durante la instalación de SAP HANA Database se crean una serie de “usuarios técnicos”, tales como <sid>adm, SYS, _SYS_STATISTICS o SYSTEM. Este último, es un usuario de bases de datos (database user) tiene unos privilegios irrevocables tales como crear usuarios de bases de datos o acceder a las tablas del sistema. Como en cualquier otro sistema o plataforma de bases de datos, se sugiere no utilizar este usuario para las tareas diarias, sino definir uno con privilegios similares.

Autenticación

Los usuarios son definidos y gestionados por SAP HANA Database en SAP HANA Studio.

La autenticación de usuarios puede ser integrada con Kerberos y SAML (Security Assertion Markup Language).

Desde SAP HANA 1.0 SP05 es posible gestionar una lista de palabras que no podrán ser utilizadas en la definición de contraseñas (Password Blacklist). Esta lista es almacenada en la tabla _SYS_PASSWORD_BLACKLIST del esquema _SYS_SECURITY. Si se cuenta con privilegios sobre la tabla o el esquema, se podrá actualizar esta lista vía sentencias SQL desde SAP HANA Studio.

Autorización

Un usuario autenticado como usuario de base de datos indica que podrá realizar operaciones, la confirmación que pueda hacer algo se denomina autorización, la cual se determinará por la verificación de los derechos efectivos sobre los recursos y privilegios para ejecutar la operación. Tipos de privilegios en SAP HANA database:

System privilege. Permiten el control total del sistema con el fin de administrarlo permitiendo la ejecución de tareas tales como creación de esquemas, definición de usuarios y roles, copias de respaldo, gestión de licencias, etc.
Object privilege. Es usado para restringir el acceso y las modificaciones de los objetos de la base de datos.
Anlytic privilege. Son utilizados para determinar el acceso a las vistas de información, estos privilegios son evaluados durante la ejecución de las consultas
Package privillege. Determina si el usuario podrá acceder y trabajar con paquetes del repositorio, los cuales pueden contener vistas de información en tiempo de diseño.
Privilegios para tareas administrativas. Para las tareas típicas de un administrador del sistema, además de tener derechos sobre los objetos a gestionar, debe contarse con privilegios específicos como los siguientes:

Abrir la Consola de Administración (CATALOG READ y DATA ADMIN. MONITORING para sólo conslta)
Iniciar o detener servicios (SERVICE ADMIN)
Gestionar licencias (LICENSE ADMIN)
Gestionar roles (ROLE ADMIN)
Gestionar usuarios (USER ADMIN)
Gestionar tablas, esquemas y particiones (DATA ADMIN o CATALOG READ)
Importar catálogo de objetos (IMPORT)
Exportar catálogo de objetos (EXPORT)