Uno de los temas más mas recurrentes durante la sesiones con los clientes es el Sizing para SAP HANA.
Aunque anteriormente ya comentamos algunas de las estrategias que SAP ofrece para minimizar la huella de hardware para SAP HANA:
- Virtualización y Multitenancy para SAP HANA. Introducción
- Virtualization and Multitenancy for SAP HANA. Virtualización.
- Virtualization and Multitenancy for SAP HANA. Multitenancy.
Hoy comentaremos algunas pautas a seguir para un Sizing en SAP HANA.
Como hemos hecho en otras series, para que el artículo sea fácil de digerir lo dividiremos en dos partes.
En esta, a modo de introducción trataremos los conceptos básicos a manejar,
En el siguiente, nos centraremos más específicamente en el Sizing para S/4HANA.
Cabe decir que esto pretende ser un punto de partida, no una guía definitiva, ni un curso SAP...
Un sobredimensionamiento acarrea costes innecesarios, un bajo dimensionamiento repercute en el desempeño.
Empecemos.
¿Qué es un Sizing?
Sizing o dimensionamiento es la traducción de los requisitos de negocio a requisitos de hardware.
Esta tarea se ejecuta generalmente al inicio de una nueva implantación o
upgrade que requiera cambio de alguno de los componentes que integran la plataforma.
Es vital que el sizing sea lo más correcto posible,
ya que sobredimensionar, es decir, proveer de más infraestructura de la necesaria,
incurre en gastos innecesarios para nuestros clientes por el contrario,
bajo dimensionar provoca un pésimo comportamiento de las distintas piezas del software.
¿Qué componentes de hardware son tenidos en cuenta?
Básicamente los componentes que debe tener en cuenta un Sizing (para HANA) son:
- Memoria.
Una base de datos en memoria necesita una gran cantidad como es de suponer.
Su tamaño variará dependiendo del tamaño de la BBDD.
Un punto de partida para una tallaje pequeño (XS) son 128 GB.
Su coste está relacionado con su tamaño y la cantidad que alberga un slot. - CPU.
Encargada de procesar las distintas tareas.
Su coste está relacionado con la potencia que es capaz de desempeñar. - Disco.
Necesario para albergar la capa de persistencia.
Tradicionalmente si el sistema era OLAP o OLTP era un factor a tener en cuenta para su elección
ya que se debían tener en cuenta las optimaciones para la lectura o escritura.
Para SAP HANA esto no procede.
- Red
Dependiendo del tipo de despliegue que escojamos, on-premise o un despliegue en Cloud se deben de tener diferentes consideraciones para la misma.
Si por ejemplo se escogiese un despliegue de una instancia SAP HANA en Cloud, factores como la cantidad de datos transferidos o el tiempo de respuesta pueden ser determinantes.
En la siguiente imagen puede apreciarse los distintos componentes.
Como hemos podido observar, el componente crucial para un dimensionamiento SAP HANA es la memoria.
Aunque SAP HANA cuenta con tecnologías avanzadas de almacenamiento y compresión de la información,
la totalidad de la misma estará cargada en memoria.
Además de la totalidad del tamaño que requiere para información propiamente dicha
se requiere el mismo tamaño para todas tareas propias de una base de datos
ya que estas son realizadas en memoria también.
A diferencia de las bases de datos tradicionales,
el espacio para la caché y otras áreas relacionadas son menores en SAP HANA.
¿Qué son los SAPS?
SAP Application Performance Standard (SAPS) es una unidad de medida de hardware independiente
que describe el desempeño de un determinado hardware en un entorno SAP.
Al realizar un sizing desde las distintas herramientas que veremos más adelante,
el resultado será un número determinado de SAPS.
Con este número, nuestro hardware vendor nos ofrecerá el hardware que más se ajusta a nuestros requisitos.
En la siguiente imagen tenemos como referencia la cantidad de SAPS que desempeñan aproximadamente
elementos comunes en nuestra infraestructura.
Nos vemos en la siguiente entrega,
en la que abordaremos las herramientas de las que disponemos para un correcto sizing.
- SAP Managed Tags:
7 Comments
