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 máquina virtual de la 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 servidores físicos de Azure y la plataforma subyacente general de Azure.
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 como la que existe 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 del 99,9 % para una única máquina virtual 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 n.º 1/100) x (servicio de disponibilidad n.º 2/100) x (servicio de disponibilidad n.º 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 tengan dos o más instancias implementadas en el mismo conjunto de disponibilidad, garantizamos conectividad de las máquinas virtuales a una instancia como mínimo al menos durante el 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 diferentes máquinas virtuales no se reinician al mismo tiempo durante el mantenimiento planificado 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 diferentes que no comparten interruptor de red ni fuente de alimentación. 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 Administrar la disponibilidad de las máquinas virtuales en Azure mediante el conjunto de disponibilidad.
Azure Availability Zones
Azure lanzará próximamente un concepto de Azure Availability Zones 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.
Hay algunas cosas a tener en cuenta a la hora de usar Availability Zones. 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 más información, consulte el artículo Combinación de conjuntos de disponibilidad y zonas de disponibilidad con grupos con 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 deberá usar la SKU de Azure Standard Load Balancer.
- Azure Availability Zones no proporciona ninguna garantía de una determinada distancia entre las diferentes zonas 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 puede, como cliente, ejecutar de manera razonable el nivel de aplicación de SAP implementado en diferentes zonas ya que la latencia de red de una zona a la máquina virtual de DBMS activa es aceptable desde el punto de vista del impacto del proceso empresarial. Sin embargo, también podría haber escenarios de cliente en los que la latencia entre la máquina virtual del DBMS de una zona y una instancia de la aplicación de SAP en una máquina virtual de otra zona sea demasiado intrusiva o 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 distribuirlo entre zonas de disponibilidad. Al crea 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 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 error 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 evitar las limitaciones asociadas al uso de grupos 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 la red, se recomienda implementar la carga de trabajo de SAP en todas las 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 tronco de red, y todos los componentes del sistema SAP, como las bases de datos, ASCS/ERS y la capa 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
Los discos Managed Disks son un tipo de recurso de Azure Resource Manager, es una opción de almacenamiento recomendada en lugar de los discos duros virtuales (VHD) que se almacenan en las cuentas de almacenamiento de Azure. Los discos administrados se alinearán 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 breve resumen 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 la implementación | Las instancias se distribuyen en una, dos o tres zonas de disponibilidad y en diferentes bastidores dentro de cada zona en función del mejor esfuerzo | Instancias en una, dos o tres zonas de disponibilidad | Las instancias llegan a 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á al máximo las instancias) | 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 con el de almacenamiento | No | No | Sí |
| Reserva de capacidad | Sí (asignar la reserva de capacidad a 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 obtener más información, consulte Migrar implementaciones y recursos Virtual Machine Scale Sets en orquestación flexible
- Para obtener más información sobre la alineación de dominios de error de proceso y almacenamiento, consulte Elección del número correcto de dominios de error para el VMSS 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 cargas de trabajo de SAP
Cuando implementa 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, por ejemplo, entre zonas, en una sola zona o en una región sin zonas). En la siguiente tabla 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 sola zona 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 Availability Zones con grupos de selección de ubicación por 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 diferentes zonas de una región. Esto garantiza que si una zona no está disponible, el sistema SAP siga estándolo 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 distribuyan en diferentes dominios de error dentro de la zona de la mejor manera posible. Todos los componentes SAP de alta disponibilidad, como ASCS/ERS de SAP y las bases de datos de SAP, se distribuyen en diferentes zonas, mientras que los servidores de aplicaciones múltiples de cada zona se distribuyen en diferentes dominios de error en función de los mejores esfuerzos.
- Implementación en una sola zona de una región: para implementar el sistema SAP de alta disponibilidad a nivel regional en una ubicación con varias zonas de disponibilidad, y si es esencial que todos los componentes del sistema se encuentren en una única 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 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 zonas, 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 tener 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 (se admite para SUSE Linux Enterprise Server 12 y Red Hat Enterprise Linux 7 y versiones posteriores), se utiliza el reinicio de 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 servidores físicos de Azure y la plataforma subyacente general de Azure.
Para obtener más información sobre el enfoque, consulte Utilización del reinicio de VM de la infraestructura de Azure para lograr una "mayor disponibilidad" de un sistema de 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.
En función del tipo de implementación (conjunto de escalado flexible con FD=1, zona de disponibilidad o conjunto de disponibilidad), deberá 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 en distintas 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 en función del mejor esfuerzo. Esto garantiza que si una zona no está disponible, los servidores de aplicaciones de SAP implementados en otra zona sigan estándolo.
- Zona de disponibilidad: los servidores de aplicaciones de SAP implementados en 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 sigan estándolo. Para más información, vea Configuraciones de cargas 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 diferentes dominios de error y dominios de actualización. Al colocar máquinas virtuales en diferentes dominios de actualización, asegúrese de que las máquinas virtuales no se actualizan al mismo tiempo durante el tiempo de inactividad por mantenimiento planificado. Mientras que la colocación de las máquinas virtuales en un dominio de error diferente garantiza que la máquina virtual esté protegida frente a fallos de hardware o interrupciones del suministro eléctrico 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 agrega continuamente máquinas virtuales a un único conjunto de disponibilidad, llegará un momento en el que dos o más máquinas virtuales coincidirí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 imprescindible poseer un mínimo de dos cuentas de almacenamiento de Azure, en las que se distribuyan 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 consultar 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 simple.
- Alta disponibilidad de la instancia de ASCS/SCS de SAP usando NFS en Azure Files.
- Alta disponibilidad de la instancia de ASCS/SCS de SAP usando 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 con varios identificadores de seguridad de instancia SAP ASCS/SCS para los clústeres de conmutación por error de Windows Server y los recursos compartidos de archivos.
- Disco compartido: Alta disponibilidad con varios identificadores de seguridad de instancia SAP ASCS/SCS para los clústeres de conmutación por error de Windows Server y el 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 NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para SAP Applications: guía de varios SID.
- Red Hat Enterprise Linux (RHEL): alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en Red Hat Enterprise Linux para SAP Applications: guía de 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 |