Compartir a través de

Configuraciones de cargas de trabajo de SAP con Azure Availability Zones

  • Artículo

La implementación de las distintas capas de arquitectura de SAP en Azure Availability Zones es la arquitectura recomendada para las implementaciones de cargas de trabajo de SAP en Azure. Una zona de disponibilidad de Azure se define como: "Ubicaciones físicas exclusivas dentro de una región. Cada zona consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes". Azure Availability Zones no está disponible en todas las regiones. En el caso de las regiones de Azure que proporcionan Availability Zones, compruebe el mapa de regiones de Azure. En el artículo se enumeran las regiones que proporcionan Availability Zones. La mayoría de las regiones de Azure que están equipadas para hospedar cargas de trabajo de SAP más grandes proporcionan Availability Zones. Las nuevas regiones de Azure proporcionan Availability Zones desde el principio. Algunas de las regiones anteriores estaban o están en el proceso de retroajustarse con Availability Zones.

A partir de la arquitectura típica de SAP NetWeaver o S/4HANA, debe proteger tres capas diferentes:

  • Capa de aplicación de SAP, que puede ser de una a unas docenas de máquinas virtuales (VM). Desea minimizar la posibilidad de que las máquinas virtuales se implementen en el mismo servidor host. También desea que esas máquinas virtuales estén en una proximidad aceptable a la capa de base de datos para mantener la latencia de red en una ventana aceptable
  • La capa de ASCS/SCS de SAP que representa un único punto de error en la arquitectura de SAP NetWeaver y S/4HANA. Normalmente, se examinan dos máquinas virtuales que se desean cubrir con un marco de conmutación por error. Por lo tanto, estas máquinas virtuales deben asignarse en diferentes dominios de error de infraestructura.
  • La capa de base de datos de SAP, que representa también un único punto de error. En los casos habituales, se compone de dos máquinas virtuales que cubre un marco de conmutación por error. Por lo tanto, estas máquinas virtuales deben asignarse en diferentes dominios de error de infraestructura. Las excepciones son implementaciones escaladas de SAP HANA en las que se pueden usar más de dos máquinas virtuales

Las principales diferencias entre implementar máquinas virtuales críticas a través de conjuntos de disponibilidad o Availability Zones son:

  • La implementación con un conjunto de disponibilidad alinea las máquinas virtuales dentro del conjunto en una sola zona o centro de datos (lo que se aplique a la región específica). Como resultado, la implementación a través del conjunto de disponibilidad no está protegida por problemas de alimentación, refrigeración o redes que afectan a los centros de datos de la zona en su conjunto. Con los conjuntos de disponibilidad, tampoco hay ninguna alineación forzada entre una máquina virtual y sus discos. Significa que los discos pueden estar en cualquier centro de datos de la región de Azure, independientemente de la estructura zonal de la región. En el lado positivo, las máquinas virtuales se alinean con los dominios de error y de actualización dentro de esa zona o centro de datos. Específicamente para el nivel de base de datos o ASCS de SAP donde protegemos dos máquinas virtuales por conjunto de disponibilidad, la alineación con dominios de error impide que ambas máquinas virtuales terminen en el mismo hardware host.
  • Al implementar máquinas virtuales a través de Azure Availability Zones y elegir diferentes zonas (máximo de tres posibles), va a implementar las máquinas virtuales en las diferentes ubicaciones físicas y con eso se agrega protección frente a problemas de alimentación, refrigeración o red que afectan a los centros de datos de la zona en su conjunto. Las máquinas virtuales y sus discos relacionados también se colocan en la misma zona de disponibilidad. Sin embargo, a medida que implemente más de una máquina virtual de la misma familia de máquinas virtuales en la misma zona de disponibilidad, ninguna protección de esas máquinas virtuales terminará en el mismo host o el mismo dominio de error. Como resultado, la implementación a través de Availability Zones es ideal para el nivel de base de datos y ASCS de SAP, donde normalmente se examinan dos máquinas virtuales cada una. Para el nivel de aplicación de SAP, que puede ser drásticamente más de dos máquinas virtuales, es posible que tenga que recurrir a un modelo de implementación diferente (consulte más adelante).

Los motivos para una implementación en Azure Availability Zones deberían ser su deseo de, por encima de cubrir el error de una sola máquina virtual crítica o la capacidad de reducir el tiempo de inactividad para la aplicación de revisiones de software dentro de un nivel crítico, protegerse de problemas de infraestructura mayores que podrían afectar a la disponibilidad de uno o varios centros de datos de Azure.

Como una funcionalidad más de implementación de resistencia, Azure introdujo los conjuntos de escalado de máquinas virtuales con orquestación flexible para la carga de trabajo de SAP. El conjunto de escalado de máquinas virtuales proporciona una agrupación lógica de máquinas virtuales administradas mediante plataforma. La orquestación flexible del conjunto de escalado de máquinas virtuales proporciona la opción de crear el conjunto de escalado dentro de una región o distribuirlo entre zonas de disponibilidad. Al crear, el conjunto de escalado flexible dentro de una región con platformFaultDomainCount>1 (FD>1), las máquinas virtuales implementadas en el conjunto de escalado se distribuirían entre un número especificado de dominios de error en la misma región. Por otro lado, la creación del conjunto de escalado flexible a través de zonas de disponibilidad con platformFaultDomainCount=1 (FD=1) distribuiría las máquinas virtuales a través de diferentes zonas y el conjunto de escalado también distribuiría las máquinas virtuales a través de diferentes dominios de fallo dentro de cada zona en base al mejor esfuerzo. Con las cargas de trabajo de SAP, solo se admite el conjunto de escalado flexible con FD=1. La ventaja de usar conjuntos de escalado flexibles con FD=1 para la implementación entre zonas, en lugar de la implementación tradicional de zonas de disponibilidad, es que las máquinas virtuales implementadas con el conjunto de escalado se distribuirían entre dominios de error diferentes dentro de la zona de la mejor manera posible. Para más información, consulte la guía de implementación del conjunto de escalado flexible para la carga de trabajo de SAP.

Consideraciones de implementación entre Availability Zones

Al usar Availability Zones, tenga en cuenta lo siguiente:

  • Se presenta más información sobre Azure Availability Zones en el documento Regiones y zonas de disponibilidad.
  • La latencia de ida y vuelta de red experimentada no es necesariamente indicativa de la distancia geográfica real de los centros de datos que forman las distintas zonas. La latencia de ida y vuelta de red también se ve afectada por las conexiones de cable y el enrutamiento de los cables entre estos diferentes centros de datos.
  • Si usa zonas de disponibilidad como solución de recuperación ante desastres de pequeña distancia, tenga en cuenta que experimentamos desastres naturales que causan daños generalizados en diferentes regiones del mundo, incluidos daños pesados y generalizados en las infraestructuras de energía. Es posible que las distancias entre varias zonas no siempre sean lo suficientemente grandes como para compensar tales desastres naturales más grandes.
  • La latencia de red entre las zonas de Availability Zones no es la misma en todas las regiones de Azure. Incluso dentro de una región de Azure, las latencias de red entre las distintas zonas pueden variar. Aunque incluso en el peor de los casos, la replicación sincrónica en el nivel de base de datos basada en la replicación del sistema de HANA o SQL Server AlwaysOn funcionará sin afectar a la escalabilidad de la carga de trabajo.
  • Al decidir dónde usar Availability Zones, base la decisión en la latencia de red entre las zonas. La latencia de red desempeña un papel importante en dos áreas:
    • Latencia entre las dos instancias de base de datos que necesitan tener replicación sincrónica. Basado en operaciones muy exitosas de sistemas NetWeaver y S/4HANA más grandes entre zonas con latencias de red más altas (menos de 1,5 milisegundos), esta consideración se puede descuidar
    • La diferencia en la latencia de red entre una máquina virtual que ejecuta una instancia de diálogo de SAP en la zona con la instancia de base de datos activa y una máquina virtual similar en otra zona. A medida que aumenta esta diferencia, la influencia en el tiempo de ejecución de los procesos empresariales y los trabajos por lotes también aumenta, en función de si se ejecutan en zona con la base de datos o en otra zona (consulte más adelante en este artículo).
  • La latencia de red con Azure Availability Zones, incluso en las zonas más grandes, es lo suficientemente baja para ejecutar procesos empresariales de SAP. Hasta ahora, solo vimos algunos casos excepcionales en los que los clientes necesitaban colocar la capa de aplicación de SAP y la capa de base de datos en una sola columna de red del centro de datos.

Hay algunas restricciones al implementar máquinas virtuales de Azure entre zonas de Availability Zones y el establecimiento de las soluciones de conmutación por error en la misma región de Azure.

Combinación ideal de Availability Zones

A menos que configure la asignación de procesos empresariales con funcionalidades de SAP como grupos de inicio de sesión, grupos de servidores RFC, grupos de servidores por lotes y procesos empresariales similares, se pueden ejecutar en las distintas instancias de aplicación en el nivel de aplicación de SAP. El efecto secundario de este hecho es que las instancias de aplicación de SAP pueden ejecutar trabajos por lotes independientemente de si se ejecutan en la misma zona con la instancia de base de datos activa o no. Si la diferencia en la latencia de red entre las zonas de diferencia es pequeña en comparación con la latencia de red dentro de una zona, la diferencia en los tiempos de ejecución de los trabajos por lotes podría no ser significativa. Sin embargo, cuanto mayor sea la diferencia de latencia de red dentro de una zona, en comparación con el tráfico de red de la zona, el tiempo de ejecución de los trabajos por lotes puede verse afectado más si el trabajo se ejecutó en una zona donde la instancia de base de datos no está activa. Usted como cliente debe decidir cuáles son las diferencias aceptables en tiempo de ejecución. Y, con ello, cuál es la latencia de red tolerable para el tráfico entre zonas de la carga de trabajo. Desde un punto de vista técnico, las latencias de red entre Azure Availability Zones dentro de una región de Azure funcionan para la arquitectura de NetWeaver, S/4HANA u otras aplicaciones de SAP. También es posible que como cliente mitigue estas diferencias mediante los conceptos de SAP de grupos de inicio de sesión, grupos de servidores RFC, grupos de servidores por lotes y similares cuando decida uno de los conceptos de implementación que se presentan en este artículo.

Si desea implementar un sistema SAP NetWeaver o S/4HANA entre zonas, hay dos patrones de arquitectura que puede implementar:

  • Activo/activo: el par de máquinas virtuales que ejecutan ASCS/SCS y el par de máquinas virtuales que ejecutan la capa de base de datos se distribuyen entre dos zonas. Las máquinas virtuales que ejecutan la capa de aplicación de SAP se implementan en números pares en las mismas dos zonas. Si una base de datos o una máquina virtual ASCS/SCS conmuta por error, es posible que algunas de las transacciones abiertas y activas se revierten. Sin embargo, los usuarios siguen con la sesión iniciada. Realmente no importa en qué zonas se ejecuta la máquina virtual de base de datos activa y las instancias de aplicación. Esta arquitectura es la arquitectura preferida para implementar entre zonas. En los casos en los que las latencias de red entre zonas provocan mayores diferencias al ejecutar procesos empresariales, puede usar funcionalidades como grupos de inicio de sesión de SAP, grupos de servidores RFC, grupos de servidores por lotes y similares a la ejecución de los procesos empresariales a instancias de diálogo específicas que se encuentran en la misma zona con la instancia de base de datos activa
  • Activo/pasivo: el par de máquinas virtuales que ejecutan ASCS/SCS y el par de máquinas virtuales que ejecutan la capa de base de datos se distribuyen entre dos zonas. Las máquinas virtuales que ejecutan el nivel de aplicación de SAP se implementan en una de las zonas de disponibilidad. Ejecute la capa de aplicación en la misma zona que la instancia de base de datos y ASCS/SCS activa. Puede usar esta arquitectura de implementación si considera que la latencia de red en las distintas zonas es demasiado alta. Y con eso provocando diferencias inaceptables en el tiempo de ejecución de los procesos empresariales. O bien, si desea usar implementaciones de zona de disponibilidad como implementaciones de recuperación ante desastres de corta distancia. las zonas. Si una máquina virtual ASCS/SCS o una máquina virtual de base de datos conmuta por error a la zona secundaria, es posible que encuentre una mayor latencia de red y con esa reducción del rendimiento. Además, debe conmutar por recuperación la máquina virtual conmutada por error anteriormente tan pronto como sea posible para volver a los niveles de rendimiento anteriores. Si se produce una interrupción de zona, la capa de aplicación debe conmutarse por error a la zona secundaria. Una actividad que los usuarios experimentan como cierre completo del sistema.

Así pues, antes de decidir cómo usar Availability Zones, debe determinar lo siguiente:

  • La latencia de red entre las tres zonas de una región de Azure. Conocer la latencia de red entre las zonas de una región le permitirá elegir las zonas con la menor latencia de red en el tráfico de red entre zonas.
  • La diferencia entre la latencia de máquina virtual a máquina virtual dentro de una de las zonas elegidas y la latencia de red entre las dos zonas seleccionadas.
  • Una determinación que indique si los tipos de máquinas virtuales que tiene que implementar están disponibles en las dos zonas seleccionadas. Con algunas SKU de máquinas virtuales, pueden producirse situaciones en las que algunas de las SKU están disponibles en solo dos de las tres zonas.

Latencia de red entre zonas y dentro de una zona

Para determinar la latencia entre las distintas zonas, debe hacer lo siguiente:

  • Implemente la SKU de máquina virtual que desea usar para la instancia de base de datos en las tres zonas. Asegúrese de que Azure Accelerated Networking está habilitado al realizar esta medición. Redes aceleradas es la configuración predeterminada desde hace unos años. Sin embargo, compruebe si está habilitado y en funcionamiento.
  • Tan pronto encuentre las dos zonas con la mínima latencia de red, implemente otras tres máquinas virtuales de la SKU de máquina virtual que desea usar como máquina virtual de nivel de aplicación en las tres zonas de disponibilidad. Mida la latencia de red en las dos máquinas virtuales de base de datos de las dos zonas seleccionadas.
  • Use niping como herramienta de medición. Esta herramienta de SAP se describe en las notas de soporte técnico de SAP #500235 y #1100926. Trate la clasificación de latencia de red en la nota de SAP #1100926 como guía aproximada. Las latencias de red mayores de 0,7 milisegundos no significan que el sistema no funcione técnicamente o que los procesos empresariales no satisfagan sus acuerdos de nivel de servicio individuales. La nota no está pensada para indicar lo que se admite o no es compatible con SAP o Microsoft. Céntrese en los comandos documentados para medir la latencia. Dado que ping no funciona a través de las rutas de código Azure Accelerated Networking, no se recomienda que lo use.

No es necesario realizar estas pruebas manualmente. Puede encontrar un procedimiento de PowerShell llamado prueba de latencia de zonas de disponibilidad que automatiza las pruebas de latencia descritas.

En función de las medidas y la disponibilidad de las SKU de máquina virtual de Availability Zones, debe tomar las siguientes decisiones:

  • Defina las zonas ideales para la capa de base de datos.
  • Determine si desea distribuir el nivel de aplicación de SAP activo a una, dos o las tres zonas, en función de las diferencias de latencia de red dentro de una zona o entre zonas.
  • Determine si desea implementar una configuración en modo activo/pasivo o activo/activo desde el punto de vista de una aplicación. (Estas configuraciones se explican posteriormente en este artículo).

Importante

Las medidas y decisiones tomadas son válidas para la suscripción de Azure utilizada para realizar estas medidas. Si usa otra suscripción de Azure, la asignación de las zonas enumeradas podría ser diferente para otra suscripción de Azure. Como resultado, debe repetir las medidas o averiguar la asignación de la nueva suscripción en relación con la suscripción anterior del script Avzone-Mapping de la herramienta.

Importante

Se espera que las medidas descritas anteriormente proporcionen resultados diferentes en cada región de Azure que admita Availability Zones. Aunque los requisitos de latencia de red sean los mismos, puede que deba adaptar diferentes estrategias de implementación en distintas regiones de Azure, ya que la latencia de red entre zonas puede variar. En algunas regiones de Azure, la latencia de red entre las tres zonas diferentes puede variar significativamente. En otras regiones, la latencia de red entre las tres zonas diferentes puede ser más uniforme. La afirmación de que siempre hay una latencia de red entre 1 y 2 milisegundos no es correcta. La latencia de red entre las zonas de Availability Zones de las regiones de Azure no se puede generalizar.

Implementación activa/activa

Esta arquitectura de implementación se denomina activa/activa porque se implementan los servidores de aplicaciones de SAP activos en dos o tres zonas. La instancia de Servicios centrales de SAP que usa la replicación en cola se implementa entre dos zonas. Lo mismo sucede con la capa de base de datos, que se implementa en las mismas zonas que SAP Central Service. Al considerar esta configuración, debe encontrar las dos Availability Zones de la región que ofrecen latencia de red entre zonas aceptable para la carga de trabajo. También quiere asegurarse de que la diferencia entre la latencia de red dentro de las zonas seleccionadas y la latencia de red entre zonas es aceptable para la carga de trabajo.

Un esquema simplificado de una implementación activa/activa entre dos zonas podría ser similar a este:

Implementación activa/activa

Las siguientes consideraciones se aplican a esta configuración:

Importante

En este escenario activo/activo se aplican cargos por el tráfico entre zonas. Consulte el documento Detalles de precios de ancho de banda. La transferencia de datos entre la capa de aplicación de SAP y la capa de base de datos de SAP es bastante intensiva. Por consiguiente, el escenario activo/activo puede contribuir al aumento de costos.

Implementación activa/pasiva

Si no encuentra una configuración que mitigue la diferencia potencial en tiempo de ejecución de los procesos empresariales de SAP o si desea implementar una configuración de recuperación ante desastres de corta distancia, puede implementar una arquitectura que tenga un carácter activo/pasivo desde el punto de vista de la capa de aplicación de SAP. Defina una zona activa, que es la zona donde se implementa la capa de aplicación completa y donde se intenta ejecutar tanto la instancia de base de datos activa como la instancia de Servicios centrales de SAP. Con esta configuración, debe asegurarse de que no tiene variaciones extremas en tiempo de ejecución, en función de si un trabajo se ejecuta en zona con la instancia de base de datos activa o no, en transacciones empresariales y trabajos por lotes.

El diseño básico de este tipo de arquitectura tiene el siguiente aspecto:

Implementación de zona activa/pasiva

Las siguientes consideraciones se aplican a esta configuración:

  • Los conjuntos de disponibilidad no se pueden implementar en Azure Availability Zones. Para mitigarlo, puede usar grupos de ubicación de proximidad de Azure, tal como se documenta en el artículo Grupos de selección de ubicación de proximidad de Azure para una latencia de red óptima con aplicaciones SAP.
  • Al usar esta arquitectura, debe supervisar estrechamente el estado e intentar mantener la instancia de base de datos activa y las instancias de Servicios centrales de SAP en la misma zona que la capa de aplicación implementada. Si se produjo una conmutación por error de Servicios centrales de SAP o la instancia de base de datos, quiere asegurarse de que puede conmutar por recuperación manualmente en la zona con la capa de aplicación de SAP implementada lo antes posible.
  • Para los equilibradores de carga de los clústeres de conmutación por error de los servicios centrales de SAP y la capa de base de datos, necesita instancias de Azure Load Balancer de SKU estándar. La instancia básica de Load Balancer no funciona entre zonas.
  • Debe implementar la versión zonal de la puerta de enlace de ExpressRoute, VPN Gateway y direcciones IP públicas estándar para obtener la protección zonal que desee.
  • La red virtual de Azure implementada para hospedar el sistema SAP, junto con sus subredes, se extienden entre zonas. No necesita separar las redes virtuales para cada zona.
  • Para todas las máquinas virtuales implementadas, debe usar Azure Managed Disks. Los discos no administrados no se admiten para implementaciones zonales.
  • SSD prémium de Azure v2, almacenamiento SSD Ultrao Azure NetApp Files no admiten ninguna replicación de almacenamiento sincrónica entre zonas. En el caso de las implementaciones de bases de datos, nos basamos en métodos de base de datos para replicar datos entre zonas.
  • SSD prémium v1 que admite la replicación zonal sincrónica en Availability Zones no se ha probado con la carga de trabajo de base de datos de SAP. Por lo tanto, la replicación sincrónica zonal configurable de Azure SSD prémium v1 debe considerarse no compatible con las cargas de trabajo de base de datos de SAP.
  • En el caso de los recursos compartidos de SMB y NFS basados en Azure Premium Files, se ofrece redundancia zonal con replicación sincrónica. Consulte este documento para ver la disponibilidad de ZRS para Azure Premium Files en la región en la que desea realizar la implementación. El uso de recursos compartidos de NFS y SMB replicados zonales es totalmente compatible con implementaciones de capas de aplicaciones de SAP y clústeres de conmutación por error de alta disponibilidad para los servicios centrales de NetWeaver o S/4HANA. Los documentos que tratan sobre estos casos son:
  • La tercera zona se usa para hospedar el dispositivo SBD si crea unclúster SUSE Linux Pacemaker y usa dispositivos SBD en lugar del agente de delimitación de Azure. O bien, para instancias de aplicación adicionales.
  • Debe implementar máquinas virtuales inactivas en la zona pasiva (desde un punto de vista de base de datos) para poder iniciar los recursos de la aplicación en caso de error de zona. Otra posibilidad podría ser usar Azure Site Recovery, que es capaz de replicar máquinas virtuales activas en máquinas virtuales inactivas entre zonas.
  • Debe invertir en una automatización que le permita iniciar automáticamente la capa de aplicación de SAP en la segunda zona en caso de interrupción zonal.

Configuración combinada de alta disponibilidad y recuperación ante desastres

Microsoft no comparte ninguna información sobre las distancias geográficas entre las instalaciones que hospedan zonas de Azure Availability Zones diferentes en la región de Azure. Sin embargo, algunos clientes usan zonas para una configuración combinada de alta disponibilidad y recuperación ante desastres (recuperación ante desastres de corta distancia) que promete un objetivo de punto de recuperación (RPO) de cero. Un RPO de cero significa que no debe perder ninguna transacción de base de datos confirmada incluso en el caso de una recuperación ante desastres.

Nota:

Si utiliza Availability Zones como solución de recuperación ante desastres a corta distancia, tenga en cuenta que hemos experimentado desastres naturales que causaron daños generalizados en diferentes regiones del mundo, incluidos daños graves y generalizados a las infraestructuras eléctricas. Es posible que las distancias entre varias zonas no siempre sean lo suficientemente grandes como para compensar tales desastres naturales más grandes.

Este es un ejemplo del aspecto que podría tener este tipo de configuración:

Recuperación ante desastres de alta disponibilidad combinada en zonas

Las siguientes consideraciones se aplican a esta configuración:

  • Se supone que hay una distancia significativa entre las instalaciones que hospedan una zona de disponibilidad. O bien, se le obliga a permanecer dentro de una determinada región de Azure. Los conjuntos de disponibilidad no se pueden implementar en Azure Availability Zones. Como compensación, puede usar grupos con ubicación por proximidad de Azure, tal como se documenta en el artículo Grupos con ubicación por proximidad de Azure para una latencia de red óptima con aplicaciones SAP.
  • Al usar esta arquitectura, debe supervisar estrechamente el estado e intentar mantener la instancia de base de datos activa y las instancias de Servicios centrales de SAP en la misma zona que la capa de aplicación implementada. Si se produjo una conmutación por error de Servicios centrales de SAP o la instancia de base de datos, quiere asegurarse de que puede conmutar por recuperación manualmente en la zona con la capa de aplicación de SAP implementada lo antes posible.
  • Debería tener varias instancias de aplicaciones de producción preinstaladas en las máquinas virtuales que ejecutan las instancias de aplicaciones activas de control de calidad.
  • En caso de error zonal, apague las instancias de aplicación de control de calidad e inicie las instancias de producción en su lugar. Debe utilizar los nombres virtuales de las instancias de aplicación para que esto funcione.
  • Para los equilibradores de carga de los clústeres de conmutación por error de los servicios centrales de SAP y la capa de base de datos, necesita instancias de Azure Load Balancer de SKU estándar. La instancia básica de Load Balancer no funciona entre zonas.
  • Debe implementar la versión zonal de la puerta de enlace de ExpressRoute, VPN Gateway y direcciones IP públicas estándar para obtener la protección zonal que desee.
  • La red virtual de Azure implementada para hospedar el sistema SAP, junto con sus subredes, se extienden entre zonas. No necesita separar las redes virtuales para cada zona.
  • Para todas las máquinas virtuales implementadas, debe usar Azure Managed Disks. Los discos no administrados no se admiten para implementaciones zonales.
  • SSD prémium de Azure v2, almacenamiento SSD Ultrao Azure NetApp Files no admiten ninguna replicación de almacenamiento sincrónica entre zonas. En el caso de las implementaciones de bases de datos, nos basamos en métodos de base de datos para replicar datos entre zonas.
  • SSD prémium v1 que admite la replicación zonal sincrónica en Availability Zones no se ha probado con la carga de trabajo de base de datos de SAP. Por lo tanto, la replicación sincrónica zonal configurable de Azure SSD prémium v1 debe considerarse no compatible con las cargas de trabajo de base de datos de SAP.
  • En el caso de los recursos compartidos de SMB y NFS basados en Azure Premium Files, se ofrece redundancia zonal con replicación sincrónica. Consulte este documento para ver la disponibilidad de ZRS para Azure Premium Files en la región en la que desea realizar la implementación. El uso de recursos compartidos de NFS y SMB replicados zonales es totalmente compatible con implementaciones de capas de aplicaciones de SAP y clústeres de conmutación por error de alta disponibilidad para los servicios centrales de NetWeaver o S/4HANA. Los documentos que tratan sobre estos casos son:
  • La tercera zona se usa para hospedar el dispositivo SBD si crea unclúster SUSE Linux Pacemaker y usa dispositivos SBD en lugar del agente de delimitación de Azure.

Pasos siguientes

Estos son algunos pasos para implementar entre zonas de Azure Availability Zones: