Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver
Definiciones terminológicas
Alta disponibilidad: se refiere a un conjunto de tecnologías que minimiza las interrupciones de TI al proporcionar una continuidad empresarial de los servicios de TI mediante componentes redundantes, con tolerancia de errores o protegidos mediante conmutación por error dentro del mismo centro de datos. En nuestro caso, el centro de datos se encuentra en una región de Azure.
Recuperación ante desastres: también hace referencia a la reducción de la interrupción de servicios de TI y su recuperación, pero en varios centros de datos que pueden estar a separados por cientos de kilómetros. En nuestro caso, los centros de datos pueden residir en varias regiones de Azure dentro de la misma región geopolítica o en ubicaciones que el usuario haya establecido como cliente.
Información general sobre la alta disponibilidad
La alta disponibilidad SAP en Azure se puede dividir en tres tipos:
Alta disponibilidad de la infraestructura de Azure:
Por ejemplo, la alta disponibilidad del proceso (máquinas virtuales), la red o el almacenamiento, y sus beneficios para aumentar la disponibilidad de las aplicaciones de SAP.
Uso del reinicio de la máquina virtual de infraestructura de Azure para proteger las aplicaciones de SAP:
Si decide no usar funcionalidades como los clústeres de conmutación por error de Windows Server (WSFC) o Pacemaker en Linux, se utiliza el reinicio de Azure VM. Restaura la funcionalidad en los sistemas SAP si hay un tiempo de inactividad planeado y no planeado de la infraestructura de servidor físico de Azure y la plataforma de Azure subyacente general.
Alta disponibilidad de las aplicaciones de SAP:
Para lograr la alta disponibilidad completa del sistema SAP, es necesario proteger todos los componentes críticos de este. Por ejemplo:
- Los servidores de aplicaciones de SAP redundantes.
- Componentes únicos. Un ejemplo podría ser un componente de único punto de error (SPOF), como una instancia de ASCS/SCS de SAP o un sistema de administración de bases de datos (DBMS).
La alta disponibilidad de SAP en Azure presenta algunas diferencias con respecto a la alta disponibilidad de SAP en un entorno local, tanto físico como virtual.
No hay ninguna configuración de alta disponibilidad de SAP integrada en sapinst para Linux, ya que hay para Windows. Para obtener más información sobre la alta disponibilidad local de SAP para Linux, vea Información sobre asociados de alta disponibilidad.
Alta disponibilidad de la infraestructura de Azure
SLA para las máquinas virtuales de instancia única
Actualmente hay un Acuerdo de Nivel de Servicio de una sola máquina virtual del 99,9 % con Premium Storage. Para tener una idea de cómo sería la disponibilidad de una sola máquina virtual, puede compilar el producto de los distintos Acuerdos de Nivel de Servicio de Azure disponibles.
La base para el cálculo es de 30 días al mes o 43 200 minutos. Por ejemplo, un tiempo de inactividad del 0,05 % corresponde a 21,6 minutos. Como es habitual, la disponibilidad de los distintos servicios se calcula de la siguiente manera:
(Servicio de disponibilidad #1/100) x (Servicio de disponibilidad #2/100) x (Servicio de disponibilidad #3/100) *...
Por ejemplo:
(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 o una disponibilidad global del 99,75 %.
Varias instancias de máquinas virtuales en el mismo conjunto de disponibilidad
Para todas las máquinas virtuales que tienen dos o más instancias implementadas en el mismo conjunto de disponibilidad, garantizamos que tiene conectividad de máquina virtual con al menos una instancia al menos un 99,95 % del tiempo.
Cuando dos o más máquinas virtuales forman parte del mismo conjunto de disponibilidad, la plataforma Azure subyacente le asigna a cada una un dominio de actualización y un dominio de error.
- Los dominios de actualización garantizan que varias máquinas virtuales no se reinicien al mismo tiempo durante el mantenimiento planeado de una infraestructura de Azure. Las máquinas virtuales se reinician de una en una.
- Los dominios de error garantizan que las máquinas virtuales se implementan en componentes de hardware que no comparten una fuente de alimentación común y un conmutador de red. Cuando los servidores, el interruptor de red o la fuente de alimentación experimentan un tiempo de inactividad imprevisto, solo una máquina virtual se verá afectada.
Para más información, consulte Administración de la disponibilidad de máquinas virtuales en Azure mediante el conjunto de disponibilidad.
Azure Availability Zones
Azure está en proceso de implementar un concepto de Zonas de disponibilidad de Azure en diferentes regiones de Azure. En las regiones de Azure donde se va a ofrecer zonas de disponibilidad, hay muchos centros de datos en los que el suministro de la fuente de energía, la refrigeración y la red es independiente. El motivo de ofrecer distintas zonas dentro de una única región de Azure es permitirle implementar aplicaciones en dos o tres de estas zonas. Suponiendo que los problemas en las fuentes de energía o la red afectaran únicamente a la infraestructura de una zona de disponibilidad, la implementación de su aplicación dentro de una región de Azure seguiría siendo completamente funcional. En última instancia, con cierta capacidad reducida, dado que algunas máquinas virtuales de una zona podrían perderse. Pero las máquinas virtuales de las otras dos zonas seguirían funcionando. Las regiones de Azure que ofrecen zonas aparecen en Azure Availability Zones.
Al usar Availability Zones, hay algunas cosas que se deben tener en cuenta. Cosas como:
- No se pueden implementar conjuntos de disponibilidad de Azure en una zona de disponibilidad. Solo la posibilidad de combinar conjuntos de disponibilidad y Availability Zones con grupos con ubicación por proximidad. Para obtener más información, consulte el artículo Combinación de conjuntos de disponibilidad y zonas de disponibilidad con grupos de selección de ubicación por proximidad.
- No puede usar Basic Load Balancer para crear soluciones de clúster de conmutación por error basadas en los servicios de clúster de conmutación por error de Windows o en Linux Pacemaker. En su lugar, debe usar la SKU de Azure Standard Load Balancer.
- Las zonas de disponibilidad de Azure no proporcionan ninguna garantía de cierta distancia entre las distintas zonas dentro de una región.
- La latencia de red entre diferentes instancias de Azure Availability Zones en distintas regiones de Azure puede variar de una región a otra. Habría casos en los que, como cliente, puede ejecutar razonablemente la capa de aplicación de SAP implementada en distintas zonas, ya que la latencia de red de una zona a la máquina virtual de DBMS activa sigue siendo aceptable a partir de un impacto en el proceso empresarial. Mientras que podría haber escenarios de cliente en los que la latencia entre la máquina virtual de DBMS activa en una zona y una instancia de aplicación de SAP en una máquina virtual de otra zona puede ser demasiado intrusiva y no aceptable para los procesos empresariales de SAP. Como resultado, las arquitecturas de implementación deben ser diferentes con una arquitectura en modo activo/activo para la aplicación o activo/pasivo si la latencia es demasiado alta.
- El uso de discos administrados de Azure es obligatorio para la implementación en Azure Availability Zones.
Conjunto de escalado de máquinas virtuales con orquestación flexible
En Azure, Virtual Machine Scale Sets con orquestación flexible ofrece un medio para lograr una alta disponibilidad para cargas de trabajo de SAP, al igual que otros marcos de implementación, como conjuntos de disponibilidad y zonas de disponibilidad. Con el conjunto de escalado flexible, las máquinas virtuales se pueden distribuir entre varias zonas de disponibilidad y dominios de error, lo que hace que sea una opción adecuada para implementar cargas de trabajo de SAP de alta disponibilidad.
El conjunto de escalado de máquinas virtuales con orquestación flexible ofrece la flexibilidad para crear el conjunto de escalado dentro de una región o abarcarlo 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 el número especificado de dominios de error de la misma región. Por otro lado, la creación del conjunto de escalado flexible entre zonas de disponibilidad con platformFaultDomainCount=1 (FD=1) distribuiría las máquinas virtuales entre distintas zonas y el conjunto de escalado también distribuiría las máquinas virtuales entre dominios de error diferentes dentro de cada zona con el mejor esfuerzo. Para la carga 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 de zona de disponibilidad tradicional 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 una manera de mejor esfuerzo. Para evitar las limitaciones asociadas al uso del grupo de selección de ubicación de proximidad para garantizar la disponibilidad de las máquinas virtuales en todos los centros de datos de Azure o en cada columna vertebral de red, se recomienda implementar la carga de trabajo de SAP en zonas de disponibilidad mediante un conjunto de escalado flexible con FD=1. Esta estrategia de implementación garantiza que las máquinas virtuales implementadas en cada zona no están restringidas a un único centro de datos o columna vertebral de red, y todos los componentes del sistema SAP, como las bases de datos, ASCS/ERS y el nivel de aplicación se limitan a nivel zonal.
Por lo tanto, para la nueva implementación de cargas de trabajo de SAP en zonas de disponibilidad, se recomienda usar un conjunto de escalado flexible con FD=1. Para más información, consulte el documento conjunto de escalado de máquinas virtuales para la carga de trabajo de SAP.
Mantenimiento planeado y no planeado de las máquinas virtuales
Dos tipos de eventos de la plataforma Azure pueden afectar a la disponibilidad de las máquinas virtuales:
- Los eventos de mantenimiento planeado son las actualizaciones periódicas realizadas por Microsoft a la plataforma Azure subyacente. Las actualizaciones mejoran la confiabilidad general, el rendimiento y seguridad de la infraestructura de plataforma en la que se ejecutan las máquinas virtuales.
- Los eventos de mantenimiento no planeado se producen cuando el hardware o la infraestructura física subyacente a la máquina virtual presentan algún tipo de error. Entre estos podemos encontrar errores de la red local, errores de los discos locales u otros errores a nivel de bastidor. Cuando se detecta un error de este tipo, la plataforma Azure migra automáticamente la máquina virtual del servidor físico en mal estado que la hospeda a un servidor físico con un estado correcto. Estos eventos no son habituales, pero pueden hacer que su máquina virtual se reinicie.
Para más información, consulte mantenimiento de máquinas virtuales en Azure.
Redundancia de Azure Storage
Los datos de la cuenta de almacenamiento se replican siempre para garantizar su durabilidad y alta disponibilidad, en cumplimiento del Acuerdo de Nivel de Servicio de Azure Storage, incluso en caso de errores transitorios del hardware.
Dado que Azure Storage mantiene tres imágenes de los datos de forma predeterminada, no es necesario el uso de RAID 5 o RAID 1 en varios discos de Azure.
Para más información, consulte Replicación de Azure Storage.
Azure Managed Disks
Managed Disks es un tipo de recurso en Azure Resource Manager, es una opción de almacenamiento recomendada en lugar de discos duros virtuales (VHD) que se almacenan en cuentas de almacenamiento de Azure. Los discos administrados se alinean automáticamente con un conjunto de disponibilidad de Azure de la máquina virtual a la que están conectados. Aumentan la disponibilidad de la máquina virtual y de los servicios que se ejecutan en ella.
Para obtener más información, consulte Azure Managed Disks overview (Información general sobre Azure Managed Disks).
Se recomienda usar discos Managed Disks, porque simplifican la implementación y administración de las máquinas virtuales.
Comparación de diferentes tipos de implementación para la carga de trabajo de SAP
Este es un resumen rápido de los distintos tipos de implementación que están disponibles para cargas de trabajo de SAP.
| Características | Conjunto de escalado de máquinas virtuales con orquestación flexible (FD=1) | Zona de disponibilidad | Conjunto de disponibilidad |
|---|---|---|---|
| Comportamiento de implementación | Las instancias llegan a 1, 2 o 3 zonas de disponibilidad y se distribuyen entre bastidores diferentes dentro de cada zona con el mejor esfuerzo. | Las instancias llegan a 1, 2 o 3 zonas de disponibilidad | Las instancias llegan dentro de la región y se distribuyen entre diferentes dominios de error o actualización |
| Asignación de máquinas virtuales y discos administrados a una zona de disponibilidad específica | Sí | Sí | No |
| Dominio de error: propagación máxima (Azure propagará las instancias máximamente) | Sí | No | Sí, en función del número de dominios de error definidos durante la creación. |
| Alineación del dominio de error de proceso al almacenamiento | No | No | Sí |
| Reserva de capacidad | Sí (asignar la reserva de capacidad en el nivel de máquina virtual) | Sí | No |
Nota:
- Los dominios de actualización han quedado en desuso en el modo de orquestación flexible. Para más información, consulte Migración de implementaciones y recursos a virtual Machine Scale Sets en orquestación flexible.
- Para obtener más información sobre la alineación de los dominios de error de proceso a almacenamiento, consulte Elección del número correcto de dominios de error para el conjunto de escalado de máquinas virtuales y ¿Cómo funcionan los conjuntos de disponibilidad?.
- Para habilitar la reserva de capacidad, es importante comprobar las limitaciones y restricciones de la reserva de capacidad.
Opciones de implementación de alta disponibilidad para la carga de trabajo de SAP
Al implementar una carga de trabajo de SAP de alta disponibilidad en Azure, es importante tener en cuenta los distintos tipos de implementación disponibles y cómo se pueden aplicar en diferentes regiones de Azure (como entre zonas, en una sola zona o en una región sin zonas). En la tabla siguiente se muestran varias opciones de alta disponibilidad para sistemas SAP en regiones de Azure.
| Tipo de sistema | Entre diferentes zonas de una región | En una zona singe de una región | En una región sin zonas |
|---|---|---|---|
| Sistema SAP de alta disponibilidad | Conjunto de escalado flexible con FD=1 | Conjuntos de disponibilidad con grupos de selección de ubicación de proximidad | Conjuntos de disponibilidad |
| Conjuntos de disponibilidad y zonas de disponibilidad con grupos de selección de ubicación de proximidad | Conjunto de escalado flexible con FD=1 (seleccione solo una zona) | Conjunto de escalado flexible con FD=1 (no se definen zonas) | |
| Zonas de disponibilidad | Conjuntos de disponibilidad |
- Implementación en diferentes zonas de una región: para obtener la mayor disponibilidad, los sistemas SAP deben implementarse en distintas zonas de una región. Esto garantiza que si una zona no está disponible, el sistema SAP sigue estando disponible en otra zona. Si va a implementar una nueva carga de trabajo de SAP en zonas de disponibilidad, se recomienda usar un conjunto de escalado de máquinas virtuales flexibles con la opción de implementación FD=1. Permite implementar varias máquinas virtuales en diferentes zonas de una región sin preocuparse por las restricciones de capacidad o los grupos de selección de ubicación. El marco del conjunto de escalado garantiza que las máquinas virtuales implementadas con el conjunto de escalado se distribuirán entre distintos dominios de error dentro de la zona de una manera más eficaz. Todos los componentes de SAP de alta disponibilidad, como ASCS/ERS de SAP, las bases de datos de SAP se distribuyen entre diferentes zonas, mientras que varios servidores de aplicaciones de cada zona se distribuyen entre diferentes dominios de error de la mejor manera posible.
- Implementación en una sola zona de una región: para implementar el sistema SAP de alta disponibilidad regionalmente en una ubicación con varias zonas de disponibilidad y, si es esencial para que todos los componentes del sistema estén en una sola zona, se recomienda usar conjuntos de disponibilidad con la opción de implementación Grupos de selección de ubicación de proximidad. Este enfoque permite agrupar todos los componentes del sistema SAP en una sola zona de disponibilidad, lo que garantiza que las máquinas virtuales del conjunto de disponibilidad se reparten entre dominios de error y actualización diferentes. Aunque esta implementación alinea el proceso con los dominios de error de almacenamiento, no se garantiza la proximidad. Sin embargo, como esta opción de implementación es regional, no admite Azure Site Recovery para la recuperación ante desastres de zona a zona. Además, esta opción restringe toda la implementación de SAP a un centro de datos, lo que puede provocar limitaciones de capacidad si necesita cambiar el tamaño de la SKU o las instancias de aplicación de escalabilidad horizontal.
- Implementación en una región sin zonas: si va a implementar el sistema SAP en una región que no tiene ninguna zona, se recomienda usar conjuntos de disponibilidad. Esta opción proporciona redundancia y tolerancia a errores colocando máquinas virtuales en distintos dominios de error y dominios de actualización.
Importante
Debe tenerse en cuenta que las opciones de implementación de las regiones de Azure son solo sugerencias. La estrategia de implementación más adecuada para su sistema SAP dependerá de sus requisitos y entornos concretos.
Uso de la alta disponibilidad de la infraestructura de Azure para proteger las aplicaciones de SAP
Si decide no usar funcionalidades como WSFC o Pacemaker en Linux (compatible con SUSE Linux Enterprise Server 12 y versiones posteriores, y Red Hat Enterprise Linux 7 y versiones posteriores), se usa el reinicio de la máquina virtual de Azure. Restaura la funcionalidad en los sistemas SAP si hay un tiempo de inactividad planeado y no planeado de la infraestructura de servidor físico de Azure y la plataforma de Azure subyacente general.
Para más información sobre el enfoque, consulte Uso del reinicio de máquinas virtuales de infraestructura de Azure para lograr una mayor disponibilidad del sistema SAP.
Alta disponibilidad de las aplicaciones de SAP en IaaS de Azure
Para lograr la alta disponibilidad completa del sistema SAP, es necesario proteger todos los componentes críticos de este. Por ejemplo:
- Los servidores de aplicaciones de SAP redundantes.
- Componentes únicos. Un ejemplo podría ser un componente de único punto de error (SPOF), como una instancia de ASCS/SCS de SAP o un sistema de administración de bases de datos (DBMS).
En la siguiente sección se tratara el tema de cómo lograr alta disponibilidad para los tres componentes críticos del sistema SAP.
Arquitectura de alta disponibilidad en los servidores de aplicaciones de SAP
Logotipo de Windows y
Linux
Por lo general, no se necesita una solución de alta disponibilidad específica para las instancias de diálogo y servidores de aplicaciones de SAP. La alta disponibilidad se obtiene mediante redundancia y se configuran varias instancias de diálogo en distintas instancias de Azure Virtual Machines. Debe tener, como mínimo, dos instancias de aplicaciones de SAP instaladas en dos instancias de Azure Virtual Machines.
Según el tipo de implementación (conjunto de escalado flexible con FD=1, zona de disponibilidad o conjunto de disponibilidad), debe distribuir las instancias del servidor de aplicaciones de SAP en consecuencia para lograr redundancia.
- Conjunto de escalado flexible con platformFaultDomainCount=1 (FD=1): los servidores de aplicaciones de SAP implementados con un conjunto de escalado flexible (FD=1) distribuyen las máquinas virtuales entre diferentes zonas de disponibilidad y el conjunto de escalas también distribuiría las máquinas virtuales entre diferentes dominios de error dentro de cada zona con mayor esfuerzo. Esto garantiza que si una zona no está disponible, los servidores de aplicaciones de SAP implementados en otra zona siguen estando disponibles.
- Zona de disponibilidad: los servidores de aplicaciones de SAP implementados entre zonas de disponibilidad garantizan que las máquinas virtuales se abarquen entre diferentes zonas para lograr redundancia. Esto garantiza que si una zona no está disponible, los servidores de aplicaciones de SAP implementados en otra zona siguen estando disponibles. Para más información, consulte Configuraciones de carga de trabajo de SAP con Azure Availability Zones.
- Conjunto de disponibilidad: los servidores de aplicaciones de SAP implementados en el conjunto de disponibilidad garantizan que las máquinas virtuales se distribuyan entre distintos dominios de error y dominios de actualización. Al colocar máquinas virtuales en distintos dominios de actualización, asegúrese de que las máquinas virtuales no se actualizan al mismo tiempo durante el tiempo de inactividad del mantenimiento planeado. Mientras que colocar máquinas virtuales en un dominio de error diferente garantiza que la máquina virtual esté protegida frente a errores de hardware o interrupciones de energía dentro de un centro de datos. Pero el número de dominios de error y actualización que puede usar en el conjunto de disponibilidad de Azure dentro de una unidad de escalado de Azure es finito. Si sigue agregando máquinas virtuales a un único conjunto de disponibilidad, dos o más máquinas virtuales acabarían en el mismo dominio de error o actualización. Para obtener más información, vea la sección Conjuntos de disponibilidad de Azure del documento sobre implementación y planeamiento de Azure Virtual Machines para SAP NetWeaver.
Solo discos no administrados: cuando se usan discos no administrados con conjunto de disponibilidad, es importante reconocer que la cuenta de almacenamiento de Azure se convierte en un único punto de error. Por lo tanto, es imperativo posar un mínimo de dos cuentas de almacenamiento de Azure, en las que se distribuyen al menos dos máquinas virtuales. En una configuración ideal, los discos de cada máquina virtual que ejecuta una instancia de diálogo de SAP estarían implementados en una cuenta de almacenamiento distinta.
Importante
Es muy recomendable que utilice Azure Managed Disks para las instalaciones de alta disponibilidad de SAP. Los discos Managed Disks se alinean automáticamente con el conjunto de disponibilidad de la máquina virtual a la que están conectados y, por tanto, aumentan la disponibilidad de la máquina virtual y los servicios que se ejecutan en ella.
Arquitectura de alta disponibilidad para una instancia de ASCS/SCS de SAP en Windows
Puede usar una solución WSFC para proteger la instancia de ASCS/SCS de SAP. En función del tipo de configuración del recurso compartido de clúster (recurso compartido de archivos o disco compartido), puede hacer referencia a la solución adecuada en función del tipo de almacenamiento.
Recurso compartido de clúster: recurso compartido de archivos
Recurso compartido de clúster: disco compartido
Arquitectura de alta disponibilidad para una instancia de ASCS/SCS de SAP en Linux
En Linux, la configuración de la agrupación en clústeres de instancias de ASCS/SCS de SAP depende de la distribución del sistema operativo y del tipo de almacenamiento que se usa. Se recomienda implementar la solución adecuada según su marco de clúster de sistema operativo específico.
SUSE Linux Enterprise Server (SLES)
- Alta disponibilidad de la instancia de ASCS/SCS de SAP mediante NFS con montaje sencillo.
- Alta disponibilidad de la instancia de ASCS/SCS de SAP mediante NFS en Azure Files.
- Alta disponibilidad de la instancia de ASCS/SCS de SAP mediante NFS en Azure NetApp Files.
- Alta disponibilidad de la instancia de ASCS/SCS de SAP mediante el servidor NFS.
Red Hat Enterprise Linux (RHEL)
Configuración de varios identificadores de seguridad de SAP NetWeaver para una instancia de ASCS/SCS de SAP agrupada en clúster
Se admiten varios identificadores de seguridad con WSFC mediante los recursos compartidos de archivos y discos compartidos. Para más información sobre la arquitectura de alta disponibilidad con varios identificadores de seguridad en Windows, consulte:
- Recurso compartido de archivos: alta disponibilidad de varios SID de la instancia de ASCS/SCS de SAP para clústeres de conmutación por error de Windows Server y recurso compartido de archivos.
- Disco compartido: alta disponibilidad de varios SID de la instancia de ASCS/SCS de SAP para clústeres de conmutación por error de Windows Server y disco compartido.
La agrupación en clústeres de varios SID es compatible con los clústeres de Linux Pacemaker para ASCS/ERS de SAP, limitado a cinco SID de SAP en el mismo clúster. Para más información sobre la arquitectura de alta disponibilidad con varios identificadores de seguridad en Linux, consulte:
- SUSE Linux Enterprise Server (SLES): alta disponibilidad para SAP NW en máquinas virtuales de Azure en SLES para aplicaciones sap con varios SID.
- Red Hat Linux Enterprise (RHEL): alta disponibilidad para SAP NW en máquinas virtuales de Azure en RHEL para aplicaciones de SAP con varios SID.
Alta disponibilidad de la instancia de DBMS
En un sistema SAP, los servidores DBMS también son el único punto de error. Por lo tanto, es importante proteger la base de datos mediante la implementación de una solución de alta disponibilidad. La solución de alta disponibilidad de DBMS varía en función de la base de datos usada para el sistema SAP. En función de la base de datos, siga las instrucciones para lograr una alta disponibilidad en la base de datos.
| Base de datos | Recomendación de recuperación ante desastres |
|---|---|
| SAP HANA | Replicación del sistema HANA (HSR) |
| Oracle | Protección de datos de Oracle |
| IBM DB2 | Recuperación ante desastres de alta disponibilidad (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| ASE de SAP | ASE HADR Always On |