Guía

Seleccionar una VM para una base de datos SAP HANA de producción.

→Utilizar VMs de la serie Mv2 o M para bases de datos grandes (>4TB). Utilizar VMs de la serie Edsv5 certificadas por SAP para bases de datos HANA de producción más pequeñas (<4TB).

Por qué: Las series M/Mv2 están certificadas por SAP para cargas de trabajo de gran memoria. La serie Edsv5 ofrece una opción certificada rentable para instancias HANA más pequeñas. Otras series (D, F, L) no están certificadas para bases de datos HANA de producción.

Referencia↗

Seleccionar una VM para un servidor de aplicaciones SAP NetWeaver.

→Utilizar VMs de la serie Edsv5 o Ddsv5. Dimensionar según los requisitos de SAPS de los informes SAP EarlyWatch Alert o SAP Quick Sizer.

Por qué: Las VMs de la serie E y D proporcionan una relación CPU-a-memoria equilibrada adecuada para las cargas de trabajo del servidor de aplicaciones SAP y están certificadas por SAP para NetWeaver.

Garantizar una latencia de red mínima entre los servidores de aplicaciones SAP y el servidor de base de datos.

→Implementar todas las VMs relacionadas (servidores de aplicaciones, ASCS/ERS, base de datos) dentro de un único Grupo de Colocación por Proximidad (PPG).

Por qué: Los PPGs co-ubican físicamente las VMs en el mismo centro de datos, minimizando el tiempo de ida y vuelta de la red para cumplir con el requisito de latencia sub-milisegundo de SAP entre los niveles de aplicación y base de datos.

Proporcionar un sistema de archivos compartido para el volumen /hana/shared en una implementación de escalado horizontal de SAP HANA.

→Utilizar Azure NetApp Files (ANF) con el protocolo NFS.

Por qué: ANF es la solución de almacenamiento NFS compartido de alto rendimiento certificada por SAP requerida para configuraciones de escalado horizontal de HANA. El almacenamiento de bloques como los Managed Disks no se puede utilizar para este propósito.

Proporcionar un sistema de archivos compartido de alta disponibilidad para /sapmnt y el directorio de transporte global (/usr/sap/trans).

→Utilizar Azure NetApp Files (NFS) o Azure Files Premium (NFS). Para Windows, utilizar Azure Files Premium (SMB) o un clúster SOFS.

Por qué: Estos servicios proporcionan recursos compartidos de archivos administrados y de alta disponibilidad con el rendimiento y el soporte de protocolo requeridos (NFS para Linux, SMB para Windows), eliminando la necesidad de construir y administrar un clúster de servidores de archivos separado.

Diseñar el almacenamiento para los volúmenes de producción /hana/data y /hana/log de SAP HANA que requieren altas IOPS y latencia sub-milisegundo.

→Utilizar Azure Ultra Disk o Premium SSD v2 managed disks. Para /hana/log en VMs de la serie M, Premium SSD con Write Accelerator también es una opción válida.

Por qué: Ultra Disk y Premium SSD v2 cumplen con los estrictos KPIs de IOPS, rendimiento y latencia sub-milisegundo definidos por SAP para cargas de trabajo HANA de producción. Las capas de almacenamiento estándar no son compatibles.

Diseñar una arquitectura de red segura para cargas de trabajo SAP, aislando los entornos de producción de los que no lo son.

→Utilizar una topología hub-spoke. Implementar sistemas SAP en VNets spoke dedicadas para cada entorno (Prod, QA, Dev). Utilizar Network Security Groups (NSGs) para aplicar reglas de tráfico estrictas entre subredes.

Por qué: Esto proporciona un fuerte aislamiento de red a nivel de VNet y control de tráfico granular con NSGs, siguiendo las mejores prácticas de seguridad y el concepto de Azure Landing Zone.

Implementar entornos SAP en Azure utilizando un enfoque de Infraestructura como Código (IaC) para consistencia y automatización.

→Utilizar el marco oficial de automatización de implementación de SAP en Azure, que aprovecha Terraform y Ansible. Alternativamente, construir módulos personalizados de Bicep o Terraform.

Por qué: El marco proporciona plantillas preconstruidas y validadas por SAP para implementar todo el entorno (plano de control, zonas de carga de trabajo, sistemas SAP), reduciendo el esfuerzo manual y asegurando el cumplimiento de las mejores prácticas.

Publicar de forma segura SAP Fiori u otras aplicaciones SAP basadas en web a usuarios externos a través de internet.

→Utilizar Azure Application Gateway con el Firewall de Aplicaciones Web (WAF) habilitado.

Por qué: App Gateway proporciona equilibrio de carga de Capa 7, terminación SSL y protección WAF contra vulnerabilidades web comunes, lo que lo convierte en el punto de entrada ideal y seguro para aplicaciones SAP basadas en web.

Implementar una base de datos SAP HANA extremadamente grande (>12 TB de memoria) que excede la capacidad de las VMs de Azure.

→Utilizar SAP HANA en Azure Large Instances (HLI). La conectividad requiere un circuito ExpressRoute que conecte la estampilla HLI a una VNet de Azure a través de un gateway de ExpressRoute.

Por qué: HLI son servidores bare-metal construidos específicamente para proporcionar la memoria masiva y el rendimiento necesarios para las cargas de trabajo HANA más grandes, que están más allá de la escala de la infraestructura virtualizada actual.

Implementar un sistema SAP a través de Zonas de Disponibilidad mientras se minimiza la latencia dentro de cada zona.

→Crear un Grupo de Colocación por Proximidad (PPG) separado para los recursos en cada Zona de Disponibilidad. Fijar cada PPG a su zona respectiva.

Por qué: Un único PPG no puede abarcar varias zonas. Este enfoque asegura la co-ubicación de recursos con baja latencia *dentro* de una zona, mientras se logra alta disponibilidad *entre* zonas.

Crear y distribuir imágenes de VM estandarizadas, parcheadas y preconfiguradas para implementaciones de SAP en múltiples regiones.

→Utilizar Azure Image Builder para definir un proceso de creación de imágenes repetible. Almacenar y replicar las imágenes administradas resultantes utilizando Azure Compute Gallery.

Por qué: Esto proporciona una fábrica de "imágenes doradas" automatizada y con control de versiones, asegurando la consistencia y reduciendo el tiempo de implementación en comparación con la configuración manual de cada nueva VM.

Proporcionar acceso administrativo seguro RDP/SSH a VMs SAP sin exponerlas a la internet pública.

→Implementar Azure Bastion (SKU Estándar) en una subred dedicada dentro de la red virtual de SAP. Utilizar Bastion para conectarse a las VMs a través del portal de Azure o clientes nativos.

Por qué: Bastion actúa como una jump box segura y administrada, eliminando la necesidad de direcciones IP públicas en las VMs de SAP o configuraciones VPN complejas para el acceso administrativo, reduciendo así la superficie de ataque.

Cifrar volúmenes de datos SAP utilizando claves de cifrado gestionadas por el cliente.

→Utilizar Azure Disk Encryption con una clave administrada por el cliente (CMK) almacenada en Azure Key Vault. Esto se puede combinar con el cifrado nativo de SAP HANA para una defensa en profundidad.

Por qué: Esta configuración otorga al cliente control total sobre las claves de cifrado de datos, cumpliendo con estrictos requisitos de cumplimiento y seguridad para la gestión del ciclo de vida de las claves.

Migrar un sistema SAP local con una base de datos que no sea HANA (por ejemplo, Oracle, Db2) a SAP HANA en Azure.

→Utilizar SAP Software Update Manager (SUM) con la opción de migración de base de datos (DMO). Para un tiempo de inactividad mínimo, utilizar las opciones "DMO con System Move" o tiempo de inactividad casi cero (nZDT).

Por qué: DMO combina la conversión de la base de datos, la actualización del sistema y la migración de datos en un único proceso optimizado. Es la herramienta estándar de SAP para esta tarea, minimizando el tiempo de inactividad en comparación con la exportación/importación clásica.

Migrar un sistema SAP HANA local a Azure con el menor tiempo de inactividad posible.

→Utilizar SAP HANA System Replication (HSR) para replicar continuamente los datos a la VM de Azure de destino. Realizar una migración final y breve (takeover) durante la ventana de mantenimiento.

Por qué: HSR minimiza la ventana de tiempo de inactividad a minutos, ya que solo se requiere la sincronización final y la migración. Los métodos de copia de seguridad/restauración o exportación/importación resultan en horas de tiempo de inactividad para bases de datos grandes.

Transferir un gran volumen de datos SAP (>10 TB) desde el entorno local a Azure para la carga inicial de la migración cuando el ancho de banda de la red es insuficiente.

→Utilizar Azure Data Box para la transferencia masiva inicial de datos. Utilizar ExpressRoute o VPN para la sincronización delta posterior.

Por qué: Data Box proporciona un método de transferencia fuera de línea más rápido que las transferencias basadas en red con ancho de banda limitado, reduciendo significativamente el tiempo de carga inicial.

Implementar y administrar sistemas SAP S/4HANA en Azure utilizando una experiencia simplificada y guiada.

→Utilizar Azure Center para soluciones SAP (ACSS). Los prerrequisitos incluyen registrar el proveedor `Microsoft.Workloads` y crear una identidad administrada asignada por el usuario con los permisos requeridos.

Por qué: ACSS agiliza la implementación al agrupar las mejores prácticas y proporciona un único panel de control en el portal de Azure para la gestión básica (inicio/parada, monitorización) y comprobaciones de calidad.

Determinar los tamaños correctos de VMs de Azure para un sistema SAP nuevo o migrado.

→Utilizar la herramienta SAP Quick Sizer para nuevas implementaciones. Para migraciones, analizar los informes SAP EarlyWatch Alert del sistema existente para obtener el uso actual de SAPS y memoria. Mapearlos a VMs de Azure certificadas por SAP.

Por qué: Estas herramientas nativas de SAP proporcionan la caracterización de carga de trabajo más precisa (SAPS, memoria, I/O), lo cual es esencial para seleccionar correctamente los recursos de Azure y garantizar el rendimiento y la compatibilidad.

Integrar un entorno Azure administrado por el cliente con un sistema SAP S/4HANA implementado a través de RISE with SAP.

→SAP gestiona la infraestructura de Azure subyacente en una suscripción separada. Establecer conectividad desde su VNet de Azure a la VNet gestionada por SAP utilizando VNet Peering.

Por qué: RISE es una oferta de servicio gestionado de SAP. VNet Peering proporciona la ruta de integración de red estándar, segura y privada entre el entorno RISE y otras cargas de trabajo del cliente en Azure.

Aplicar estándares corporativos y mejores prácticas de seguridad en todas las implementaciones de SAP en Azure.

→Utilizar Azure Policy para aplicar reglas, como requerir SKUs de VM específicos, cifrado de discos administrados, asociación de NSG o etiquetado obligatorio. Utilizar el efecto `DeployIfNotExists` para instalar automáticamente la Extensión de VM para SAP.

Por qué: Azure Policy proporciona gobernanza automatizada y a gran escala, asegurando que todas las implementaciones cumplan con las normativas sin depender de verificaciones manuales o configuraciones de plantillas individuales.

Validar que la infraestructura de Azure implementada esté correctamente configurada y cumpla con los requisitos de soporte de SAP antes de la puesta en marcha.

→Instalar y habilitar la extensión de VM de Azure para SAP (Enhanced Monitoring). Ejecutar la herramienta SAP on Azure Quality Check desde GitHub.

Por qué: La extensión de VM es obligatoria para el soporte de SAP. La herramienta Quality Check valida proactivamente las configuraciones (almacenamiento, redes, configuración del sistema operativo) contra una lista de mejores prácticas y requisitos conocidos.

Implementar una solución de copia de seguridad automatizada y consistente con la aplicación para bases de datos SAP HANA en VMs de Azure.

→Utilizar Azure Backup para SAP HANA, que se integra a través de la interfaz Backint certificada por SAP. Configurar una política con copias de seguridad completas/diferenciales y copias de seguridad de logs frecuentes para la recuperación a un momento dado.

Por qué: Azure Backup proporciona una solución nativa, integrada y certificada que automatiza la programación, retención y gestión de copias de seguridad sin requerir scripts personalizados o una infraestructura de copia de seguridad separada.

Implementar una monitorización completa y centralizada para un entorno SAP ejecutándose en Azure.

→Implementar Azure Monitor para SAP Solutions. Configurar proveedores para telemetría de SAP HANA, NetWeaver, OS (Linux) y clúster de alta disponibilidad.

Por qué: Este es un servicio nativo de Azure diseñado para SAP. Proporciona telemetría y visualizaciones ricas y conscientes de SAP, centralizando la monitorización de toda la pila SAP desde la infraestructura hasta la aplicación.

Aplicar parches de OS o del kernel de SAP a un clúster SAP de alta disponibilidad con un tiempo de inactividad mínimo.

→Utilizar un enfoque de actualización gradual. Poner el nodo secundario en modo de mantenimiento, aplicarle el parche, luego reiniciar. Realizar una conmutación por error controlada del clúster para que el nodo parcheado sea el principal. Finalmente, aplicar el parche al nodo que era principal.

Por qué: Este enfoque gradual asegura que el servicio SAP permanezca disponible en un nodo durante todo el proceso de mantenimiento, minimizando la interrupción del servicio empresarial.

Automatizar el proceso de creación de copias o actualización de sistemas SAP (por ejemplo, actualizar un sistema QAS desde PRD).

→Utilizar SAP Landscape Management (LaMa) con el Conector de Azure.

Por qué: LaMa orquesta el proceso de principio a fin, incluyendo tareas de infraestructura de Azure (parada/inicio de VM, instantáneas de disco) y automatización posterior a la copia específica de SAP (BDLS), reduciendo significativamente el esfuerzo manual.

Validar el plan de recuperación ante desastres de SAP sin impactar el entorno de producción.

→Utilizar la función "Test Failover" de Azure Site Recovery que levanta VMs replicadas en una VNet aislada. Para HSR, utilizar restauraciones basadas en instantáneas a un sistema aislado o un objetivo de replicación terciario dedicado.

Por qué: Las pruebas en una red aislada evitan conflictos de IP y cualquier interferencia con los sistemas de producción o la replicación en curso, permitiendo una validación segura y exhaustiva del manual de DR.

Planificar los requisitos futuros de recursos (CPU, memoria, almacenamiento) para un sistema SAP en crecimiento en Azure.

→Utilizar las métricas de Azure Monitor y Log Analytics para analizar las tendencias históricas de uso. Utilizar estos datos para la previsión. Para el almacenamiento, aprovechar la capacidad de redimensionar dinámicamente los Azure Managed Disks en línea.

Por qué: La gestión proactiva de la capacidad basada en datos históricos previene la degradación del rendimiento y permite el aprovisionamiento justo a tiempo, optimizando los costos en comparación con un aprovisionamiento excesivo inicial significativo.

Minimizar los costos de Azure para ejecutar un entorno SAP completo.

→Para cargas de trabajo de producción, utilizar Azure Reserved Instances de 1 o 3 años. Para sistemas no de producción, implementar programaciones automáticas de inicio/parada a través de Azure Automation. Utilizar Azure Hybrid Benefit para licencias donde sea elegible.

Por qué: Las Reserved Instances proporcionan grandes descuentos para cargas de trabajo predecibles 24/7. El apagado automático elimina los costos de computación durante los períodos de inactividad para sistemas no de producción. Esta combinación aborda los dos principales factores de costo.

Rastrear y asignar los costos de Azure para las cargas de trabajo SAP a unidades de negocio específicas, proyectos o sistemas SAP (SIDs).

→Implementar una estrategia de etiquetado obligatorio para todos los recursos de Azure. Utilizar etiquetas como `CostCenter`, `Environment`, `SAP-SID` y `BusinessOwner`. Analizar los costos utilizando Azure Cost Management.

Por qué: El etiquetado es el mecanismo nativo de Azure para categorizar recursos. El etiquetado consistente permite un análisis detallado de costos y la asignación de cargos, proporcionando una visibilidad financiera esencial.

Diagnosticar problemas intermitentes de conectividad de red o latencia entre VMs SAP en Azure.

→Utilizar las herramientas de Azure Network Watcher, específicamente Connection Monitor para probar rutas y latencia, y NSG Flow Logs para analizar e identificar tráfico bloqueado.

Por qué: Network Watcher proporciona herramientas proactivas y reactivas para identificar problemas de red a nivel de la plataforma Azure, lo que a menudo es difícil de diagnosticar solo desde el sistema operativo invitado.

Automatizar el parcheo del sistema operativo para VMs SAP, asegurando que las aplicaciones se cierren correctamente.

→Utilizar Azure Update Manager con scripts pre/post. El pre-script detiene la aplicación SAP y la base de datos, y el post-script las reinicia una vez que se completa el parcheo.

Por qué: Esto combina la automatización de la gestión de parches de Azure con la sensibilidad a la aplicación requerida para SAP, evitando inconsistencias de datos que podrían ocurrir al parchear un sistema en ejecución.

Implementar alta disponibilidad para SAP Central Services (ASCS/ERS) o SAP HANA en VMs de SUSE/RHEL Linux.

→Configurar un clúster Pacemaker. Utilizar el agente `fence_azure_arm` para STONITH (fencing) para prevenir escenarios de cerebro dividido, autenticado a través de una identidad administrada.

Por qué: Pacemaker es la solución de clustering compatible con SAP en Linux. `fence_azure_arm` es el mecanismo nativo de Azure para aislar de forma fiable un nodo fallido a través de las APIs de Azure, lo cual es obligatorio para un clúster estable.

Implementar alta disponibilidad para SAP Central Services (ASCS/ERS) en VMs de Windows Server.

→Configurar un Windows Server Failover Cluster (WSFC). Para el almacenamiento compartido del clúster, utilizar Azure Shared Disks o una solución de replicación de terceros como SIOS DataKeeper.

Por qué: WSFC es el estándar para el clustering de Windows. Azure Shared Disks proporciona almacenamiento de bloques compartido nativo, mientras que SIOS crea un clúster "shared-nothing", ambos reemplazando la necesidad de SANs tradicionales en la nube.

Diseñar una estrategia de alta disponibilidad (HA) y recuperación ante desastres (DR) para SAP HANA.

→Para HA (en la región), implementar VMs a través de Zonas de Disponibilidad y utilizar SAP HANA System Replication (HSR) síncrono (SYNC). Para DR (entre regiones), utilizar HSR asíncrono (ASYNC).

Por qué: La replicación síncrona proporciona un RPO cero pero requiere baja latencia (<2ms), lo que la hace ideal para HA entre zonas. La replicación asíncrona tolera una mayor latencia entre regiones, lo que la convierte en la elección para DR.

Configurar un Azure Load Balancer para gestionar la dirección IP virtual de un clúster SAP HA (ASCS/ERS o HANA).

→Utilizar un Azure Standard Load Balancer. Habilitar Floating IP (Direct Server Return) en la regla de equilibrio de carga. Configurar una sonda de salud en el puerto específico monitoreado por el clúster (por ejemplo, 620xx para ASCS).

Por qué: El SKU Standard es necesario para la redundancia de zona. Floating IP es necesario para que la IP virtual del clúster funcione correctamente. La sonda de salud específica asegura que el tráfico solo se envíe al nodo activo.

Comprender el propósito del Enqueue Replication Server (ERS) en un clúster de alta disponibilidad de SAP ASCS.

→La instancia ERS mantiene una réplica de la tabla de bloqueo SAP de la instancia ASCS activa.

Por qué: Si la instancia ASCS falla y se recupera, la nueva instancia ASCS iniciada recupera la tabla de bloqueo replicada del ERS. Esto preserva los bloqueos de transacción y permite a los usuarios continuar trabajando sin interrupción.

Diseñar una solución completa de recuperación ante desastres para un entorno SAP de múltiples niveles.

→Utilizar replicación de base de datos nativa para la capa de base de datos (por ejemplo, HSR asíncrono para HANA). Utilizar Azure Site Recovery (ASR) para la capa de aplicación (ASCS/ERS y servidores de aplicaciones).

Por qué: Este enfoque "best-of-breed" garantiza la consistencia de la aplicación para la base de datos a través de su replicación nativa, mientras que ASR proporciona una forma rentable y automatizada de replicar y conmutar por error las VMs del servidor de aplicaciones.

Implementar alta disponibilidad para una base de datos SAP ejecutándose en Microsoft SQL Server en VMs de Azure.

→Utilizar SQL Server Always On Availability Groups, típicamente con modo de confirmación síncrona para HA dentro de una región, combinado con un WSFC.

Por qué: Always On AG es la solución HA/DR recomendada y totalmente compatible para SQL Server, proporcionando replicación a nivel de base de datos y capacidades de conmutación por error automática.

Implementar SBD (STONITH Block Device) como mecanismo de quórum para un clúster Pacemaker de dos nodos.

→Configurar un pequeño Azure Shared Disk y adjuntarlo a ambos nodos del clúster. Alternativamente, configurar un servidor iSCSI target dedicado en una tercera VM.

Por qué: Aunque `fence_azure_arm` es el agente de fencing principal, SBD proporciona un mecanismo adicional de testigo/quórum para prevenir el cerebro dividido, especialmente en clústeres sin un tercer nodo votante.