SAP HANA es compatible con la deduplicación inline, la deduplicación inline, la compresión inline y la compactación inline, en una configuración de SSD.

El uso de volúmenes de NetApp FlexGroup no es compatible con SAP HANA. Debido a la arquitectura de SAP HANA, el uso de FlexGroup Volumes no ofrece ningún beneficio y puede dar lugar a problemas de rendimiento.

El uso del cifrado de volúmenes de NetApp (NVE) y el cifrado de agregados de NetApp (NAE) son compatibles con SAP HANA.

La calidad de servicio se puede utilizar para limitar el rendimiento del almacenamiento para sistemas SAP HANA específicos o aplicaciones no SAP en una controladora de uso compartido. Un caso de uso sería limitar el rendimiento de los sistemas de desarrollo y pruebas para que no puedan influir en los sistemas de producción en una configuración mixta.

Durante el proceso de configuración, debe determinar los requisitos de rendimiento de un sistema que no sea de producción. Los sistemas de desarrollo y pruebas pueden ser dimensionados con valores de rendimiento más bajos, normalmente en el rango del 20% al 50% de un KPI de sistemas de producción, según lo define SAP.

A partir de ONTAP 9, la calidad de servicio se configura en el nivel del volumen de almacenamiento y utiliza valores máximos para el rendimiento (MB/s) y la cantidad de I/o (IOPS).

Las grandes I/o de escritura tienen el mayor efecto en el rendimiento del sistema de almacenamiento. Por lo tanto, el límite de rendimiento de calidad de servicio debe definirse como un porcentaje de los valores de KPI de rendimiento de almacenamiento SAP HANA de escritura correspondientes en los volúmenes de datos y registros.

La tecnología FabricPool de NetApp no debe utilizarse para sistemas de archivos primarios activos en sistemas SAP HANA. Esto incluye los sistemas de archivos para el área de datos y registro así como el /hana/shared sistema de archivos. Si lo hace, el rendimiento es impredecible, especialmente durante la inicio de un sistema SAP HANA.

Puede usar la política de organización en niveles de solo Snapshot junto con FabricPool en un destino de backup, como el destino de SnapVault o SnapMirror.

FabricPool es una buena opción para mover los backups de registros a otro nivel de almacenamiento. Mover backups afecta el tiempo necesario para recuperar una base de datos SAP HANA. Por lo tanto, la opción tiering-minimum-cooling-days deben configurarse con un valor que coloque backups de registros, que son necesarios habitualmente para la recuperación, en el nivel de almacenamiento rápido local.

La siguiente información general resume los pasos necesarios para la configuración del almacenamiento. Cada paso se trata con más detalle en las secciones siguientes. En esta sección, asumimos que el hardware de almacenamiento está configurado y que el software ONTAP ya está instalado. Además, debe haberse conectado los puertos FCP del almacenamiento a la estructura SAN.

En general, debe configurar dos agregados por controladora, independientemente de la bandeja de discos o la tecnología de disco (SSD o HDD) que se utilice. Este paso es necesario para poder utilizar todos los recursos disponibles de las controladoras. Para los sistemas de la serie AFF A200, hay suficiente un agregado de datos.

La siguiente figura muestra una configuración de 12 hosts SAP HANA que se ejecutan en una bandeja SAS de 12 GB configurada con ADPv2. Seis hosts SAP HANA están conectados a cada controladora de almacenamiento. Se configuran cuatro agregados separados, dos en cada controladora de almacenamiento. Cada agregado está configurado con 11 discos con nueve particiones de datos y dos particiones de disco de paridad. Para cada controladora, hay dos particiones de repuesto disponibles.

Varios entornos SAP con bases de datos SAP HANA pueden utilizar un único SVM. También puede asignarse una SVM a cada entorno SAP, si es necesario, en caso de que esté gestionada por diferentes equipos dentro de una empresa.

Si hay un perfil de calidad de servicio que se crea y se asigna automáticamente al crear una SVM nueva, quite este perfil creado automáticamente a partir de la SVM para garantizar el rendimiento requerido para SAP HANA:

Dentro de la configuración del clúster de almacenamiento, se debe crear una interfaz de red (LIF) y asignarla a un puerto FCP dedicado. Si, por ejemplo, se necesitan cuatro puertos FCP por motivos de rendimiento, deberá crear cuatro LIF. La figura siguiente muestra una captura de pantalla de las ocho LIF (denominadas fc_*_*) que se configuraron en la hana SVM.

Durante la creación de SVM con ONTAP 9.8 System Manager, puede seleccionar todos los puertos FCP físicos necesarios y un LIF por puerto físico se crea automáticamente.

Un conjunto de puertos FCP se utiliza para definir qué LIF se utilizarán en un iGroup específico. Normalmente, todos los LIF creados para los sistemas HANA se colocan en el mismo conjunto de puertos. En la figura siguiente se muestra la configuración de un conjunto de puertos llamado 32g, que incluye las cuatro LIF ya se han creado.

En la siguiente figura, se muestra la configuración de volúmenes de cuatro sistemas SAP HANA de un solo host. Los volúmenes de datos y de registro de cada sistema SAP HANA se distribuyen a diferentes controladoras de almacenamiento. Por ejemplo, volume SID1_data_mnt00001 Se configura en la controladora A y en un volumen SID1_log_mnt00001 Se configura en la controladora B. Dentro de cada volumen, se configura una única LUN.

Para cada host SAP HANA, un volumen de datos, un volumen de registro y un volumen de para /hana/shared están configurados. La siguiente tabla muestra un ejemplo de configuración con cuatro sistemas SAP HANA de un solo host.

En la siguiente tabla se muestra un ejemplo de la configuración de puntos de montaje para un sistema de un solo host.

Se puede utilizar LVM de Linux para aumentar el rendimiento y solucionar las limitaciones de tamaño de LUN. Los diferentes LUN de un grupo de volúmenes de LVM deben almacenarse en un agregado diferente y en una controladora diferente. En la siguiente tabla se muestra un ejemplo para dos LUN por grupo de volúmenes.

En el host SAP HANA, es necesario crear y montar grupos de volúmenes y volúmenes lógicos, como se indica en la siguiente tabla.

En la siguiente figura, se muestra la configuración de volúmenes de un sistema SAP HANA de 4+1 host múltiple. Los volúmenes de datos y los volúmenes de registro de cada host SAP HANA se distribuyen a diferentes controladoras de almacenamiento. Por ejemplo, el volumen SID_data_mnt00001 Está configurado en la controladora A y el volumen SID_log_mnt00001 Se configura en la controladora B. Se configura un LUN dentro de cada volumen.

La /hana/shared Todos los hosts HANA deben acceder al volumen y, por lo tanto, se exporta mediante NFS. Aunque no existen KPI de rendimiento específicos para el /hana/shared Sistema de archivos, NetApp recomienda utilizar una conexión Ethernet de 10 GB.

Para cada host SAP HANA, se crean un volumen de datos y un volumen de registro. La /hana/shared El volumen lo utilizan todos los hosts del sistema SAP HANA. En la siguiente tabla se muestra un ejemplo de configuración para un sistema SAP HANA de 4+1 host múltiple.

En la siguiente tabla se muestran la configuración y los puntos de montaje de un sistema de varios hosts con cuatro hosts SAP HANA activos.

Se puede utilizar LVM de Linux para aumentar el rendimiento y solucionar las limitaciones de tamaño de LUN. Los diferentes LUN de un grupo de volúmenes de LVM deben almacenarse en un agregado diferente y en una controladora diferente.

La siguiente tabla muestra un ejemplo para dos LUN por grupo de volúmenes para un sistema host SAP HANA múltiple de 2+1.

En el host SAP HANA, es necesario crear y montar grupos de volúmenes y volúmenes lógicos, como se indica en la siguiente tabla.

Las opciones de volumen enumeradas en la siguiente tabla deben verificarse y definirse en todas las SVM.

En esta sección se muestra un ejemplo de configuración mediante la línea de comandos con ONTAP 9.8 para un sistema host múltiple de SAP HANA 2+1 con SID FC5 mediante LVM y dos LUN por grupo de volúmenes LVM: