Editar

Compartir vía

Ejecución de SAP HANA para máquinas virtuales Linux en una arquitectura de escalado vertical en Azure

Azure
Azure Virtual Machines

Esta arquitectura de referencia muestra un conjunto de procedimientos probados para ejecutar SAP HANA en un entorno de alta disponibilidad y escalabilidad vertical que admita recuperación ante desastres en Azure. Esta implementación solo se centra en la capa de base de datos.

Architecture

Esta arquitectura de referencia describe un sistema de producción común. Puede elegir los tamaños de máquina virtual para adaptarse a las necesidades de su organización. Esta configuración también se puede reducir a una máquina virtual, dependiendo de los requisitos empresariales.

En el diagrama siguiente se muestra una arquitectura de referencia para SAP HANA en Azure:

Diagrama que muestra una arquitectura de implementación regional.

Descargue un archivo de Visio que contiene los diagramas de este artículo.

Nota

Para implementar esta arquitectura de referencia, necesita las licencias adecuadas de los productos de SAP y de otras tecnologías que no son de Microsoft.

Flujo de trabajo

Esta arquitectura de referencia describe una base de datos SAP HANA típica que se ejecuta en Azure en una implementación de alta disponibilidad para maximizar la disponibilidad del sistema. La arquitectura y sus componentes se pueden personalizar en función de los requisitos empresariales (RTO, RPO, expectativas de tiempo de actividad, rol del sistema) y se puede reducir potencialmente a una sola máquina virtual. El diseño de red se ha simplificado para mostrar los principios de arquitectura de un entorno de SAP de este tipo y no pretende describir una red empresarial completa.

Redes

Redes virtuales. El servicio Azure Virtual Network conecta los recursos de Azure entre sí con seguridad mejorada. En esta arquitectura, la red virtual se conecta a un entorno local a través de una puerta de enlace de ExpressRoute implementada en el concentrador de una topología en estrella tipo hub-and-spoke. La base de datos de SAP HANA está contenida en su propia red virtual de radio. Las redes virtuales de radio contienen una subred para las máquinas virtuales (VM) de base de datos.

Si las aplicaciones que se conectan a SAP HANA se ejecutan en máquinas virtuales, las máquinas virtuales de la aplicación deben encontrarse en la misma red virtual, pero dentro de una subred de aplicación dedicada. Como alternativa, si la conexión de SAP HANA no es la base de datos principal, las máquinas virtuales de la aplicación se pueden encontrar en otras redes virtuales. La separación en subredes por carga de trabajo permite habilitar con mayor facilidad los grupos de seguridad de red (NSG) para establecer reglas de seguridad aplicables solo a máquinas virtuales de SAP HANA.

Puerta de enlace con redundancia de zona. Una puerta de enlace conecta redes distintas, y extiende la red local a la red virtual de Azure. Se recomienda usar ExpressRoute para crear conexiones privadas que no vayan a través de la red pública de Internet, pero también puede usar una conexión de sitio a sitio. Use instancias de Azure ExpressRoute o VPN Gateway con redundancia de zona para protegerse frente a errores de zona. Consulte Puertas de enlace de red virtual con redundancia de zona para comprender las diferencias entre una implementación zonal y una implementación con redundancia de zona. Merece la pena mencionar aquí que las direcciones IP utilizadas deben ser de la SKU Estándar para una implementación de zona de las puertas de enlace.

Grupos de seguridad de red (NSG). Para restringir el tráfico de red entrante y saliente de la red virtual, cree grupos de seguridad de red que, a su vez, se asignen a subredes específicas. Las subredes de base de datos y de aplicación están protegidas con grupos de seguridad de red específicos de la carga de trabajo.

Grupos de seguridad de aplicaciones (ASG). Para definir directivas de seguridad de red pormenorizadas en sus grupos de seguridad de red en función de las cargas de trabajo que se centran en aplicaciones, use grupos de seguridad de aplicación en lugar de direcciones IP explícitas. Permiten agrupar las interfaces de red de máquinas virtuales por nombre y le ayudan a proteger las aplicaciones mediante el filtrado del tráfico desde segmentos de confianza de la red.

Tarjetas de interfaz de red (NIC). Las tarjetas de interfaz de red permiten todas las comunicaciones entre las máquinas virtuales en una red virtual. En las implementaciones de SAP locales tradicionales, se implementan varias tarjetas de interfaz de red por máquina para aislar el tráfico administrativo del empresarial.

En Azure, no es necesario usar varias tarjetas de interfaz de red para mejorar el rendimiento. Varias tarjetas de interfaz de red comparten el mismo límite de rendimiento de red de una máquina virtual. Pero si su organización necesita separar el tráfico, puede implementar varias NIC por VM y conectar cada NIC a una subred diferente. A continuación, puede usar grupos de seguridad de red para aplicar las distintas directivas de control de acceso en cada subred.

Las NIC de Azure admiten varias direcciones IP. Esta compatibilidad se ajusta al procedimiento recomendado de SAP de usar nombres de host virtuales para las instalaciones. Para obtener un esquema completo, consulte la nota de SAP 962955. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace).

Nota

Tal como se especifica en la nota de SAP 2731110, no coloque ninguna aplicación virtual de red (NVA) entre los niveles de aplicación y de base de datos para cualquier pila de aplicaciones de SAP. Haciendo esto se introducen un tiempo de procesamiento de paquetes de datos significativo y se ralentiza inaceptablemente el rendimiento de la aplicación.

Máquinas virtuales

Esta arquitectura usa máquinas virtuales (VM). Azure ofrece una escala vertical de un solo nodo hasta 32 Tebibytes (TiB) de memoria en máquinas virtuales. El directorio de hardware SAP HANA admitido y certificado por SAP muestra las máquinas virtuales certificadas para la base de datos de SAP HANA. Para más información sobre la compatibilidad de SAP con los tipos de máquina virtual y las métricas de rendimiento (SAPS), consulte la nota de SAP 1928533: Aplicaciones SAP en Microsoft Azure: productos y tipos de máquina virtual de Azure admitidos. (para acceder a esta y a otras notas de SAP, se requiere una cuenta de SAP Service Marketplace).

Microsoft y SAP certifican conjuntamente una variedad de tamaños de máquina virtual para cargas de trabajo de SAP HANA. Por ejemplo, las implementaciones más pequeñas se pueden ejecutar en una máquina virtual Edsv4 o Edsv5 con 160 GiB o más de RAM. Para admitir los tamaños de memoria de SAP HANA más grandes en máquinas virtuales, hasta 30 TiB, puede usar máquinas virtuales de la serie Mv3.

Máquinas virtuales de generación 2 (Gen2). Al implementar máquinas virtuales, puede usar máquinas virtuales de generación 1 o de generación 2. Las máquinas virtuales de generación 2 admiten características clave que no están disponibles para las máquinas virtuales de la generación 1. Para SAP HANA, esto es especialmente importante porque algunas familias de máquinas virtuales, como Mv2, Mdsv2, Msv3 y Mdsv3 solo se admiten como máquinas virtuales Gen2. Del mismo modo, la certificación de SAP en Azure podría requerir que las máquinas virtuales más recientes sean Gen2, incluso si Azure permite Gen1 y Gen2. Para obtener más información, consulte nota de SAP 1928533: Aplicaciones SAP en Microsoft Azure: Productos admitidos y tipos de máquina virtual de Azure.

Dado que todas las demás VM que admiten SAP HANA permiten elegir solo Gen2 o Gen1+2 de forma selectiva, se recomienda implementar todas las VM de SAP solo como Gen2. Esto también se aplica a máquinas virtuales con requisitos de memoria bajos. Incluso la máquina virtual de SAP HANA más pequeña se puede ejecutar como máquina virtual gen2 y puede cambiarse, cuando se desasigna, a la máquina virtual más grande disponible en su región.

Grupos de selección de ubicación por proximidad. Para optimizar la latencia de red, puede usar grupos de selección de ubicación por proximidad, que priorizan la colocación. Las máquinas virtuales se encuentran en el mismo centro de datos para minimizar la latencia entre SAP HANA y conectar máquinas virtuales de aplicación. Para la propia arquitectura de SAP HANA, los grupos de selección de ubicación por proximidad no son necesarios, pero su uso puede ayudarle a optimizar el rendimiento. Debido a posibles restricciones con grupos de selección de ubicación de proximidad, debe agregar el conjunto de disponibilidad de la base de datos al grupo de selección de ubicación de proximidad del sistema SAP solo al hacerlo para la latencia entre la aplicación SAP y el tráfico de base de datos. Para obtener más información sobre los escenarios de uso de los grupos de selección de ubicación de proximidad, consulte Opciones de configuración para minimizar la latencia de red con aplicaciones de SAP. Dado que los grupos de selección de ubicación de proximidad restringen las cargas de trabajo a un único centro de datos, un grupo con ubicación por proximidad no puede abarcar varias zonas de disponibilidad. Las implementaciones de gran volumen que hacen referencia a grupos de selección de ubicación por proximidad pueden estar sujetas a limitaciones de asignación de recursos.

Componentes

Consideraciones

En esta sección se describen las consideraciones clave para ejecutar SAP HANA en Azure.

Escalabilidad

Esta arquitectura ejecuta SAP HANA en máquinas virtuales que pueden escalar verticalmente hasta 32 TiB en una instancia.

Si la carga de trabajo supera el tamaño máximo de la máquina virtual, use configuraciones de escalado horizontal de HANA de varios nodos. En el caso de las aplicaciones de procesamiento de transacciones en línea (OLTP), la capacidad total de memoria escalada puede ser de hasta 4 x 23 TiB. Para las aplicaciones de procesamiento analítico en línea (OLAP), la capacidad de memoria escalada puede ser tan alta como 16 x 7.6 TiB. Por ejemplo, puede implementar SAP HANA en una configuración de escalabilidad horizontal con modo de espera en máquinas virtuales que ejecutan red Hat Enterprise Linux o SUSE Linux Enterprise Server y usar azure NetApp Files para los volúmenes de almacenamiento compartidos. Para identificar las SKU de máquina virtual certificadas que admiten configuraciones de escalabilidad horizontal, consulte el directorio de hardware de SAP HANA certificado y compatible. Revise los detalles del certificado para cada SKU de máquina virtual para garantizar la compatibilidad con la configuración.

Storage

Esta arquitectura usa Azure Managed Disks para el almacenamiento en las máquinas virtuales o Azure NetApp Files. Las directrices para la implementación del almacenamiento con Managed Disks se detallan en el documento Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA. Como alternativa a Managed Disks, se pueden usar volúmenes de NFS de Azure NetApp Files como solución de almacenamiento para SAP HANA.

Para lograr un rendimiento de almacenamiento en disco y un número de operaciones de entrada/salida por segundo (IOPS) alto, las prácticas habituales de optimización del rendimiento del volumen de almacenamiento se aplican también al diseño de Azure Storage. Por ejemplo, la combinación de varios discos con LVM para crear un volumen de disco con secciones mejora el rendimiento de E/S. El almacenamiento en caché de disco de Azure también desempeña un papel importante para lograr el rendimiento de E/S necesario.

En el caso de los discos de registro de SAP HANA que se ejecutan en SSD prémium v1 de Azure, use una de las siguientes tecnologías en ubicaciones que contienen /hana/log para producción:

Estas tecnologías son necesarias para satisfacer de forma coherente la latencia de almacenamiento necesaria de menos de 1 ms.

SSD prémium v2 de Azure está diseñado para cargas de trabajo críticas para el rendimiento, como SAP. El Acelerador de escritura no es necesario cuando /hana/log se ejecuta en SSD prémium v2. Para obtener información sobre las ventajas y las limitaciones actuales de esta solución de almacenamiento, consulte Implementación de una SSD prémium v2.

Para más información acerca de los requisitos de rendimiento de SAP HANA, consulte la nota de SAP 1943937: Herramienta de comprobación de la configuración del hardware.

  • Diseño de almacenamiento con control de costos para sistemas que no son de producción. En el caso de los entornos de SAP HANA que no requieren el máximo rendimiento de almacenamiento en todas las situaciones, puede usar una arquitectura de almacenamiento optimizada para el costo. Esta opción de optimización de almacenamiento se puede aplicar a sistemas de producción que se usan poco o a algunos entornos de SAP HANA que no son de producción. La opción de almacenamiento optimizada para costos usa una combinación de SSD estándar en lugar de SSD Premium o SSD Ultra que se usan para entornos de producción. También combina sistemas de archivos /hana/data y /hana/log en un único conjunto de discos. Hay instrucciones y procedimientos recomendados disponibles para la mayoría de los tamaños de máquina virtual. Si usa Azure NetApp Files para SAP HANA, puede usar volúmenes de tamaño reducido para lograr el mismo objetivo.

  • Cambio de tamaño del almacenamiento al escalar verticalmente. Al cambiar el tamaño de una máquina virtual debido a cambios en las exigencias empresariales o a un aumento del tamaño de la base de datos, la configuración del almacenamiento puede cambiar. Azure admite la expansión de discos en línea, sin interrupciones en el servicio. Con una configuración de disco con bandas, como se usa para SAP HANA, se debe realizar una operación de cambio de tamaño de la misma forma para todos los discos del grupo de volúmenes. La adición de más discos a un grupo de volúmenes puede desequilibrar potencialmente los datos con bandas. Si agrega más discos a una configuración de almacenamiento, es mucho más conveniente crear un nuevo volumen de almacenamiento en discos nuevos. A continuación, copie el contenido durante el tiempo de inactividad y modifique los puntos de montaje. Por último, descarte el grupo de volúmenes antiguo y los discos subyacentes.

  • Grupo de volúmenes de aplicación de Azure NetApp Files. En el caso de las implementaciones con archivos de SAP HANA incluidos en volúmenes de NFS de Azure NetApp Files, los grupos de volúmenes de aplicación permiten implementar todos los volúmenes según los procedimientos recomendados. Este proceso también garantiza un rendimiento óptimo para la base de datos SAP HANA. Hay detalles disponibles sobre cómo continuar con este proceso. Requiere intervención manual. La creación tardará algo de tiempo.

Alta disponibilidad

La arquitectura anterior muestra una implementación de alta disponibilidad, con SAP HANA contenida en dos o más máquinas virtuales. Se usan los siguientes componentes.

Instancias de Load Balancer.Azure Load Balancer se usa para distribuir el tráfico a las máquinas virtuales de SAP HANA. Al incorporar Azure Load Balancer en una implementación zonal de SAP, asegúrese de seleccionar el equilibrador de carga de la SKU estándar. El equilibrador de SKU básico no admite redundancia zonal ni está en desuso. En esta arquitectura, Load Balancer actúa como la dirección IP virtual para SAP HANA. El tráfico de red se envía a la máquina virtual activa con la instancia de base de datos principal. La arquitectura activa/habilitada para lectura de SAP HANA está disponible opcionalmente (SLES/RHEL), donde se usa una segunda dirección IP virtual en el equilibrador de carga para dirigir el tráfico de red a la instancia secundaria de SAP HANA en otra máquina virtual para cargas de trabajo de lectura intensas.

Standard Load Balancer proporciona una capa de seguridad de manera predeterminada. Las máquinas virtuales situadas detrás de Standard Load Balancer no tienen conectividad de salida a Internet. Para habilitar la conectividad de salida a Internet en estas máquinas virtuales, debe actualizar la configuración de Standard Load Balancer. Además, también puede usar una puerta de enlace de Azure NAT para obtener conectividad saliente.

Para los clústeres de base de datos de SAP HANA, debe habilitar Direct Server Return (DSR), también conocido como IP flotante. Esta característica permite al servidor responder con la dirección IP del front-end del equilibrador de carga.

Opciones de implementación. En Azure, la implementación de cargas de trabajo de SAP puede ser regional o zonal, en función de los requisitos de disponibilidad y resistencia de las aplicaciones SAP. Azure proporciona diferentes opciones de implementación, como Virtual Machine Scale Sets con orquestación flexible (FD=1), zonas de disponibilidad y conjuntos de disponibilidad, para mejorar la disponibilidad de los recursos. Para obtener una descripción completa de las opciones de implementación disponibles y su aplicabilidad en diferentes regiones de Azure (incluidas las distintas zonas, dentro de una sola zona o en una región sin zonas), consulte Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver.

SAP HANA. Para lograr una alta disponibilidad, SAP HANA se ejecuta en dos o más máquinas virtuales Linux. La replicación del sistema de SAP HANA se usa para replicar datos entre los sistemas SAP HANA principal y secundario (réplica). HSR también se usa para la recuperación ante desastres entre regiones o entre zonas. En función de la latencia de la comunicación entre las máquinas virtuales, se puede usar la replicación sincrónica dentro de una región. HSR entre regiones para la recuperación ante desastres se ejecutará de forma asincrónica en la mayoría de los casos.

Para el clúster de Linux Pacemaker, debe decidir qué mecanismo de barrera de clúster se va a usar. La barrera de clúster es el proceso de aislamiento de una máquina virtual con errores del clúster y su reinicio. Para RedHat Enterprise Linux (RHEL), el único mecanismo de barrera compatible para Pacemaker en Azure es el agente de barrera de Azure. Para SUSE Linux Enterprise Server (SLES), puede usar el agente de barrera de Azure o el dispositivo de bloques STONITH (SBD). Compare los tiempos de conmutación por error de cada solución y, si existe una diferencia, elija una solución en función de los requisitos empresariales para conseguir el objetivo de tiempo de recuperación (RTO).

Agente de barrera de Azure. Este método de barrera se basa en la API de Azure ARM, con Pacemaker consultando la API de ARM sobre el estado de ambas máquinas virtuales de SAP HANA en el clúster. Si se produce un error en una máquina virtual, por ejemplo, el sistema operativo no responde o se bloquea la máquina virtual, el administrador de clústeres usa de nuevo la API de ARM para reiniciar la máquina virtual y, si es necesario, se produce un error en la base de datos de SAP HANA en el otro nodo activo. Para ello, se usa una entidad de seguridad de nombre de servicio (SPN) con un rol personalizado para consultar y reiniciar las máquinas virtuales para autorizar con la API de ARM. No se necesita ninguna otra infraestructura. Las máquinas virtuales SBD de los diagramas de arquitectura no se implementan si se usa el agente de barrera de Azure.

SBD. El dispositivo de bloques STONITH (SBD) usa un disco al que el administrador de clústeres accede como dispositivo de bloques (sin formato, sin sistema de archivos). Este disco (o discos en caso de que haya varios) actúa como voto. Cada uno de los dos nodos de clúster que ejecutan SAP HANA accede a los discos de SBD y les lee o escribe en ellos de forma periódica pequeños fragmentos de información sobre el estado. Por lo tanto, cada nodo de clúster conoce el estado del otro sin depender solo de las redes entre las máquinas virtuales.

Preferiblemente, se implementan tres máquinas virtuales pequeñas en un conjunto de disponibilidad o en una configuración de zona de disponibilidad. Cada máquina virtual que exporta pequeñas partes de un disco como un dispositivo de bloques al que acceden los dos nodos de clúster de SAP HANA. Tres máquinas virtuales de SBD garantizan que haya suficientes miembros votantes disponibles en el caso de un tiempo de inactividad planeado o no para cualquier máquina virtual de SBD.

Como alternativa al uso de máquinas virtuales de SBD, se puede usar un disco compartido de Azure en su lugar. A continuación, los nodos del clúster de SAP HANA acceden al único disco compartido. El disco compartido puede tener redundancia local (LRS) o zonal (ZRS), si ZRS está disponible en la región de Azure.

Recuperación ante desastres

En la arquitectura siguiente se muestra un entorno de HANA de producción en Azure que proporciona recuperación ante desastres. La arquitectura incorpora zonas de disponibilidad.

Diagrama que muestra una arquitectura con recuperación ante desastres.

Para conocer las estrategias de recuperación ante desastres y los detalles de implementación, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP y Directrices de recuperación ante desastres para la aplicación SAP.

Nota

En caso de que se produzca un desastre regional que provoque un gran evento de conmutación por error para muchos clientes de Azure en una región, la capacidad de recursos de la región de destino no está garantizada. Al igual que todos los servicios de Azure, Azure Site Recovery sigue agregando características y funcionalidades. Para obtener la información más reciente sobre la replicación de Azure a Azure, consulte la matriz de compatibilidad.

Además de una implementación local de alta disponibilidad de dos nodos, HSR admite la replicación de varios niveles y de varios destinos. Por lo tanto, HSR admite la replicación entre zonas y entre regiones. La replicación de múltiples destinos está disponible para SAP HANA 2.0 SPS 03 y versiones posteriores.

Asegúrese de comprobar la capacidad de los recursos de la región de destino.

Azure NetApp Files. Como opción, Azure NetApp Files se puede usar para proporcionar una solución de almacenamiento escalable y de alto rendimiento para archivos de datos y registro de SAP HANA. Azure NetApp Files admite instantáneas para acelerar la copia de seguridad, la recuperación y la replicación local. En el caso de la replicación de contenido entre regiones, se puede usar Replicación de Azure NetApp Files entre regiones para replicar los datos de instantánea entre dos regiones. Hay disponibles detalles sobre la replicación entre regiones y un documento de notas del producto que describen todos los aspectos de la recuperación ante desastres con Azure NetApp Files.

Copia de seguridad

Se puede realizar una copia de seguridad los datos de SAP HANA de muchas maneras. Después de migrar a Azure, puede seguir usando cualquier solución de copia de seguridad de asociado existente que ya tenga. Azure proporciona dos enfoques nativos: la copia de seguridad de SAP HANA en el nivel de archivo y Azure Backup para SAP HANA a través de la interfaz Backint.

En el caso de Azure Backup de SAP HANA en el nivel de archivo, puede usar la herramienta que prefiera, como hdbsql o SAP HANA Studio, y almacenar los archivos de copia de seguridad en un volumen de disco local. Un punto de montaje habitual para este volumen de copia de seguridad es /hana/backup. Las directivas de copia de seguridad definirán el período de retención de datos en el volumen. Tan pronto como se cree la copia de seguridad, una tarea programada deberá copiar los archivos de copia de seguridad en Azure Blob Storage como precaución. Los archivos de copia de seguridad locales se conservan para la recuperación conveniente.

Azure Backup ofrece una solución sencilla de nivel empresarial para las cargas de trabajo que se ejecutan en máquinas virtuales. Azure Backup para SAP HANA proporciona una integración completa con el catálogo de copias de seguridad de SAP HANA y garantiza recuperaciones completas o a un momento dado coherentes con la base de datos. Azure Backup tiene certificación BackInt por SAP. Consulte también las preguntas más frecuentes sobre Azure Backup y la matriz de compatibilidad.

Azure NetApp Files ofrece compatibilidad con copias de seguridad basadas en instantáneas. La integración con SAP HANA para instantáneas coherentes con la aplicación se realiza a través de la herramienta Azure Application Consistent Snapshot (AzAcSnap). Las instantáneas creadas se pueden usar para la restauración en un nuevo volumen para la restauración de sistemas o copiar la base de datos SAP HANA. Las instantáneas creadas se pueden usar para la recuperación ante desastres, donde actúa como punto de restauración con registros de SAP HANA guardados en un volumen NFS diferente.

Supervisión

Para supervisar las cargas de trabajo en Azure, Azure Monitor permite recopilar, analizar y actuar de forma completa sobre la telemetría de los entornos locales y en la nube.

Para las aplicaciones de SAP que se ejecutan en SAP HANA y otras soluciones de base de datos principales, consulte Azure Monitor para soluciones de SAP para obtener información sobre cómo Azure Monitor para SAP puede ayudarle a administrar la disponibilidad y el rendimiento de los servicios de SAP.

Seguridad

Muchas medidas de seguridad se usan para proteger la confidencialidad, integridad y disponibilidad de un entorno de SAP. Por ejemplo, para proteger el acceso de usuario, SAP tiene su propio motor de administración de usuarios (UME) para controlar el acceso basado en rol y la autorización en la aplicación y bases de datos de SAP. Para más información, consulte el artículo SAP HANA Security: An Overview (Seguridad de SAP HANA: información general).

Para los datos en reposo, las diferentes funcionalidades de encriptación proporcionan seguridad como se indica a continuación:

  • Junto con la tecnología de cifrado nativa de SAP HANA, considere la posibilidad de usar una solución de cifrado de un asociado que admita claves administradas por el cliente.

  • Para cifrar discos de máquina virtual, puede usar las funcionalidades descritas en Información general sobre cifrado de discos.

  • Servidores de bases de datos de SAP: utilice el Cifrado de datos transparente que ofrece el proveedor de DBMS (por ejemplo, la tecnología de cifrado nativa de SAP HANA) para ayudar a proteger los archivos de datos y de registro, y para asegurarse de que las copias de seguridad también están cifradas.

  • Los datos del almacenamiento físico de Azure (cifrado del servidor) se cifran automáticamente en reposo con una clave administrada por Azure. También puede elegir una clave administrada por el cliente (CMK) en lugar de la clave administrada de Azure.

  • Para obtener información sobre la compatibilidad con Azure Disk Encryption en distribuciones, versiones e imágenes de Linux concretas, consulte Azure Disk Encryption para máquinas virtuales Linux.

Nota

No combine la tecnología de cifrado nativa de SAP HANA con Azure Disk Encryption ni con cifrado basado en host en el mismo volumen de almacenamiento. Además, los discos de arranque del sistema operativo para máquinas virtuales Linux no admiten Azure Disk Encryption. En su lugar, al usar el cifrado nativo de SAP HANA, combínelo con el cifrado del servidor, que se habilita de forma automática. Tenga en cuenta que el uso de claves administradas por el cliente puede afectar al rendimiento del almacenamiento.

Para la seguridad de red, use grupos de seguridad de red (NSG) y Azure Firewall o una aplicación virtual de red como se indica a continuación:

  • Use grupos de seguridad de red para proteger y controlar el tráfico entre las subredes y las capas de aplicación y de base de datos. Aplique solo grupos de seguridad de red a subredes. Los NSG aplicados a la NIC y a la subred suelen provocar problemas durante la solución de problemas y deben usarse con poca frecuencia si es que se usan alguna vez.

  • Use Azure Firewall o un dispositivo virtual de red de Azure para inspeccionar y controlar el enrutamiento del tráfico desde la red virtual central hasta la red virtual radial donde residen las aplicaciones de SAP y también para controlar la conectividad de salida a Internet.

Para los usuarios y la autorización, implemente el control de acceso basado en rol (RBAC) y los bloqueos de recursos como se indica a continuación:

  • Siga el principio de privilegios mínimos mediante RBAC para asignar privilegios administrativos en los recursos de nivel de IaaS que hospedan la solución de SAP en Azure. El propósito fundamental de RBAC es la segregación y el control de las tareas de los usuarios o grupos. RBAC está diseñado para conceder solo la cantidad de acceso a los recursos necesaria para que los usuarios puedan realizar sus tareas.

  • Use bloqueos de recursos para ayudar a evitar cambios accidentales o malintencionados. Los bloqueos de recursos ayudan a evitar que los administradores eliminen o modifiquen recursos críticos de Azure en los se encuentra la solución de SAP.

Puede encontrar más recomendaciones de seguridad en estos artículos de Microsoft y SAP.

Comunidades

Las comunidades pueden responder preguntas y ayudarle a configurar una implementación correcta. Considere las siguientes comunidades:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Más información sobre las tecnologías de los componentes:

Explore las arquitecturas relacionadas: