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.
Utilización del reinicio de VM de la infraestructura de Azure para lograr una mayor disponibilidad de 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. Con ello se protegen los sistemas SAP del 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. En el documento Alta disponibilidad y continuidad empresarial de SAP NetWeaver en entornos virtuales con VMware e Hyper-V en Microsoft Windows se describen las configuraciones estándar de alta disponibilidad de SAP en entornos virtualizados en Windows.
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) * (servicio de disponibilidad n.º 2/100) * (servicio de disponibilidad n.º 3/100) *…
Por ejemplo:
(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 o una disponibilidad general 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 obtener más información, vea Administración de la disponibilidad de las máquinas virtuales Windows en Azure.
El conjunto de disponibilidad se utiliza para lograr alta disponibilidad de:
- Los servidores de aplicaciones de SAP redundantes.
- Clústeres con dos o más nodos (máquinas virtuales, por ejemplo) que protegen puntos de error únicos como una instancia de ASCS/SCS de SAP o un administrador de base de datos.
Azure Availability Zones
Azure lanzará próximamente 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. Debe elegir una zona de disponibilidad o un conjunto de disponibilidad como marco de implementación para una máquina virtual.
- 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 el SKU 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á 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 habrá 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
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 obtener más información, vea Administración de la disponibilidad de las máquinas virtuales Windows 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 que es recomendable usar en lugar de discos duros virtuales almacenados en las cuentas de Azure Storage. Los discos Managed Disks 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, vea Introducción a los discos administrados de Azure.
Se recomienda usar discos Managed Disks, porque simplifican la implementación y administración de las máquinas virtuales.
Uso de la alta disponibilidad de la infraestructura de Azure para lograr la alta disponibilidad de las aplicaciones de SAP
Si decide no usar funcionalidades como WSFC o Pacemaker en Linux (actualmente admitido solo para SUSE Linux Enterprise Server [SLES] 12 y versiones posteriores), se utiliza el reinicio de máquina virtual de Azure. Con ello se protegen los sistemas SAP del 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 este enfoque, vea 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
Esta sección es aplicable a:
Windows como para
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.
Ilustración 1: Alta disponibilidad en los servidores de aplicaciones de SAP
Es necesario que coloque todas las máquinas virtuales que hospedan instancias de servidores de aplicaciones de SAP en el mismo conjunto de disponibilidad de Azure. Un conjunto de disponibilidad de Azure garantiza lo siguiente:
No todas las máquinas virtuales forman parte del mismo dominio de actualización.
Un dominio de actualización garantiza que las máquinas virtuales no se actualicen al mismo tiempo durante un tiempo de inactividad por mantenimiento planeado.La funcionalidad básica, que se basa en diversos dominios de actualización y de error dentro de una unidad de escalado de Azure, ya se ha presentado en la sección sobre dominios de actualización.
No todas las máquinas virtuales forman parte del mismo dominio de error.
Un dominio de error garantiza que las máquinas virtuales estén implementadas de tal manera que ningún único punto de error afecte la disponibilidad de todas las máquinas virtuales.
El número de dominios de error y de actualización que puede utilizar un conjunto de disponibilidad de Azure dentro de una unidad de escalado de Azure no es infinito. 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 coincidan en el mismo dominio de error o actualización.
Si se implementan unas cuantas instancias del servidor de aplicaciones de SAP en sus máquinas virtuales dedicadas, y se parte de la base de que hay cinco dominios de actualización, al final se obtendrá la imagen siguiente. El número máximo real de dominios de error y de actualización dentro de un conjunto de disponibilidad podría cambiar en el futuro:
Figura 2: Alta disponibilidad de servidores de aplicaciones de SAP en un conjunto de disponibilidad de Azure
Para obtener más información, vea Administración de la disponibilidad de las máquinas virtuales Windows en Azure.
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: Como la cuenta de almacenamiento de Azure es un punto único de error potencial, es importante tener, como mínimo, 2 cuentas de almacenamiento de Azure, en los cuales hay distribuidas, al menos, 2 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. La solución tiene dos variantes:
Agrupación en clústeres de la instancia ASCS/SCS de SAP mediante discos compartidos en el clúster: Para obtener más información sobre esta arquitectura, vea Agrupación de una instancia de ASCS/SCS de SAP en un clúster de conmutación por error de Windows con un disco compartido de clúster.
Agrupación en clústeres de la instancia ASCS/SCS de SAP mediante un recurso compartido de archivos: Para obtener más información sobre esta arquitectura, vea Agrupación de una instancia de ASCS/SCS de SAP en un clúster de conmutación por error de Windows con un recurso compartido de archivos.
Agrupación en clústeres de la instancia ASCS/SCS de SAP mediante un recurso compartido de SMB de ANF: Para más información sobre esta arquitectura, consulte Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en Windows con Azure NetApp Files (SMB) para aplicaciones SAP.
Arquitectura de alta disponibilidad para una instancia de ASCS/SCS de SAP en Linux
Para más información sobre la agrupación en clústeres de la instancia de ASCS/SCS de SAP mediante el marco de clústeres de SLES, consulte Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para SAP Applications. Para información sobre la arquitectura de alta disponibilidad alternativa en SLES, que no requiere NFS de alta disponibilidad, consulte Guía de alta disponibilidad para SAP NetWeaver en SUSE Linux Enterprise Server con Azure NetApp Files para aplicaciones SAP.
Para más información acerca de la agrupación en clústeres de la instancia de ASCS/SCS de SAP mediante la plataforma de Red Hat, consulte Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver en Red Hat Enterprise Linux.
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:
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:
- Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure en SUSE Linux Enterprise Server para SAP Applications: guía de varios SID
- 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 para la instancia de DBMS
DBMS también es un único punto de contacto de un sistema SAP. Debe protegerlo con una solución de alta disponibilidad. En la siguiente ilustración se muestra una solución de alta disponibilidad de SQL Server AlwaysOn en Azure, con clústeres de conmutación por error de Windows Server y el equilibrador de carga interno de Azure. SQL Server AlwaysOn replica los archivos de datos y de registro del sistema de administración de bases de datos (DBMS) con su propia replicación DBMS. En este caso, no se necesitan discos compartidos en el clúster, lo que simplifica toda la configuración.
Ilustración 3: Ejemplo de DBMS con SAP de alta disponibilidad con SQL Server AlwaysOn
Para más información sobre cómo agrupar clústeres de DBMS de SQL Server en Azure utilizando el modelo de implementación de Azure Resource Manager, consulte estos artículos:
Para obtener más información sobre cómo agrupar clústeres de DBMS de SAP HANA en Azure con el modelo de implementación de Azure Resource Manager, vea Alta disponibilidad de SAP HANA en máquinas virtuales de Azure.