En una base de datos SAP HANA, el elemento principal es la memoria.
Adicional a este componente contamos con el almacenamiento y red para un óptimo desempeño de la plataforma.
En esta entrada trataremos, como su nombre indica, trataremos el primero de los elementos.
SAP HANA usa el almacenamiento para salvaguardar una copia de la información con el propósito de arrancar y recuperar sin pérdida de datos.
La elección de una determinada tecnología de almacenamiento debe tener de en cuenta aspectos como el tamaño, rendimiento y disponibilidad como principales aspectos.
El almacenamiento en SAP HANA cumple 3 grandes propósitos:
En términos de rendimiento, tanto la velocidad de escritura como la de lectura deben ser considerados.
Otro factor de rendimiento, al igual que otras bases de datos,
es la separación física de los volúmenes de logs y data ya que ambos siguen patrones distintos en cuanto a I/O.
Para afrontar el sizing de cualquier aplicativo SAP HANA, contamos con dos enfoques:
Aunque el destino final sea el mismo, el enfoque puede variar,
y como resultado algunas fórmulas diferirán en algunos aspectos.
En este caso, nos centraremos en SAP HANA TDI.
Cuando se dispara un savepoint o un delta merge es ejecutado,
la información pasa a ser persistente en el volumen de datos bajo /hana/data/sid.
El volumen de datos para un SAP HANA es igual al net disk space for data más un 20%.
El tamaño mínimo para los volúmenes de logs dependen del número de cambios que ocurren entre dos savepoints.
Los redo logs son escritos bajo /hana/log/sid.
El tamaño para este volumen es calculado de acuerdo a la memoria del servidor.
Los binarios, los ficheros de configuración, así como los ficheros trace son almacenados bajo /hana/Shared/sid.
Al igual que en los volúmenes de logs, su tamaño variará de acuerdo a la memoria,
distinguiendo entre single-node o instalaciones scale-out.
Para instalaciones single-node la formula sería:
Para instalaciones scale-out la fórmula sería:
Adicional a este componente contamos con el almacenamiento y red para un óptimo desempeño de la plataforma.
En esta entrada trataremos, como su nombre indica, trataremos el primero de los elementos.
Almacenamiento en SAP HANA.
SAP HANA usa el almacenamiento para salvaguardar una copia de la información con el propósito de arrancar y recuperar sin pérdida de datos.
La elección de una determinada tecnología de almacenamiento debe tener de en cuenta aspectos como el tamaño, rendimiento y disponibilidad como principales aspectos.
El almacenamiento en SAP HANA cumple 3 grandes propósitos:
- La propia instalación de SAP HANA.
Este árbol de directorios contiene los binarios de ejecución, scripts de instalación y otros scripts de soporte.
Además, este directorio contiene los archivos de configuración de SAP HANA,
así como los archivos de traza y perfiles (opción por defecto). - Backups.
Los backups son programados y alojados en el almacenamiento. - Información.
SAP HANA almacena regularmente en la persistencia una copia de la información contenida en memoria. Este proceso, denominado “savepoint” es ejecutado por cada servicio, y por defecto se ejecuta cada 5m.
- Redo Log.
Para asegurar la recuperación de la información sin perdida alguna en caso de contingencia,
SAP HANA registra cada transacción en el redo log. Al igual que en el data,
cada proceso se encarga de escribir sus propios redo logs.
En términos de rendimiento, tanto la velocidad de escritura como la de lectura deben ser considerados.
- Velocidad de escritura.
La velocidad de escritura es importante para para sustentar el volumen de operaciones de escritura
dependientes de la operaciones de savepoint y backups.
La latencia en escritura (el tiempo que toma desde que se completa un registro redo log)
es igual de crítica, ya que hasta que la transacción no se dará por completada hasta que haya finalizado la operación. - Velocidad de lectura.
Obviamente es factor de la velocidad es importante en el arranque.
Ya sea un arranque por una parada programada o en el peor de los casos,
un arranque debido a algún tipo de falla.
Adicionalmente a los arranques, la información es leída regularmente,
debido a que ciertas tablas pueden ser cargadas bajo demanda.
Otro factor de rendimiento, al igual que otras bases de datos,
es la separación física de los volúmenes de logs y data ya que ambos siguen patrones distintos en cuanto a I/O.
Sizing de disco para SAP HANA.
Para afrontar el sizing de cualquier aplicativo SAP HANA, contamos con dos enfoques:
- SAP HANA Appliances.
- SAP HANA TDI (Tailored Data Center Integration).
Aunque el destino final sea el mismo, el enfoque puede variar,
y como resultado algunas fórmulas diferirán en algunos aspectos.
En este caso, nos centraremos en SAP HANA TDI.
Requerimientos para el volumen de datos.
Cuando se dispara un savepoint o un delta merge es ejecutado,
la información pasa a ser persistente en el volumen de datos bajo /hana/data/sid.
El volumen de datos para un SAP HANA es igual al net disk space for data más un 20%.
Requerimientos para el volumen de log.
El tamaño mínimo para los volúmenes de logs dependen del número de cambios que ocurren entre dos savepoints.
Los redo logs son escritos bajo /hana/log/sid.
El tamaño para este volumen es calculado de acuerdo a la memoria del servidor.
Requerimientos para el volumen de instalación SAP HANA.
Los binarios, los ficheros de configuración, así como los ficheros trace son almacenados bajo /hana/Shared/sid.
Al igual que en los volúmenes de logs, su tamaño variará de acuerdo a la memoria,
distinguiendo entre single-node o instalaciones scale-out.
Para instalaciones single-node la formula sería:
Para instalaciones scale-out la fórmula sería:
- SAP Managed Tags:
