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 en Azure

  • Artículo

Windows logo. Windows

Los clústeres de conmutación por error de Windows Server son la base de una instalación de ASCS/SCS de SAP de alta disponibilidad y DBMS en Windows.

Un clúster de conmutación por error es un grupo de 1+n servidores independientes (nodos) que colaboran para aumentar la disponibilidad de aplicaciones y servicios. Si se produce un error de nodo, los clústeres de conmutación por error de Windows Server calculan el número de errores que se pueden producir y mantiene un clúster en buen estado para proporcionar aplicaciones y servicios. Para conseguir clústeres de conmutación por error, puede elegir entre distintos modos de cuórum.

Prerrequisitos

Antes de comenzar las tareas que se describen en este artículo, revise los siguientes artículos y notas de SAP:

  • Escenarios y arquitectura de alta disponibilidad de Azure Virtual Machines para SAP NetWeaver
  • Nota de SAP 1928533, que contiene:
    • Una lista de los tamaños de máquina virtual de Azure que se admiten para la implementación de software de SAP
    • Información importante sobre la capacidad para los tamaños de máquina virtual de Azure
    • Software de SAP admitido y combinaciones de sistema operativo y base de datos
    • Versión de kernel de SAP necesaria para Windows en Microsoft Azure
  • La nota de SAP 2015553 enumera los requisitos previos para las implementaciones de software de SAP admitidas por SAP en Azure.
  • La nota de SAP 2178632 contiene información detallada sobre todas las métricas de supervisión notificadas para SAP en Azure.
  • La nota de SAP 1999351 contiene más soluciones de problemas de la extensión de supervisión mejorada de Azure para SAP.
  • La nota de SAP 2287140 enumera los requisitos previos para la característica de CA compatible con SAP del protocolo SMB 3.x.
  • La nota de SAP 2802770 tiene información de solución de problemas para el AL11 de transacciones de SAP de ejecución lenta en Windows 2012 y 2016.
  • La nota de SAP 1911507 tiene información sobre la característica de conmutación por error transparente para un recurso compartido de archivos en Windows Server con el protocolo SMB 3.0.
  • La nota de SAP 662452 tiene una recomendación (desactivación de la generación de nombres 8.3) para solucionar errores o el rendimiento del sistema de archivos deficiente durante el acceso a los datos.
  • Instalación de alta disponibilidad de SAP NetWeaver en un clúster de conmutación por error de Windows y un recurso compartido de archivos para instancias de ASCS/SCS de SAP en Azure

Nota:

La agrupación en clústeres de instancias de ASCS/SCS de SAP con un recurso compartido de archivos es compatible con sistemas SAP con kernel de SAP 7.22 (y versiones posteriores). Para más información, consulte la nota de SAP 2698948

Clústeres de conmutación por error de Windows Server en Azure

En comparación con las implementaciones de nube privada o físicas, Azure Virtual Machines requiere pasos adicionales para configurar clústeres de conmutación por error de Windows Server. Al crear un clúster, debe establecer varias direcciones IP y nombres de host virtual para la instancia de ASCS/SCS de SAP.

Resolución de nombres en Azure y el nombre de host virtual del clúster

La plataforma en la nube de Azure no ofrece la opción de configurar direcciones IP virtuales, como direcciones IP flotantes. Necesita una solución alternativa para configurar una dirección IP virtual que se comunique con el recurso de clúster en la nube.

El servicio Azure Load Balancer proporciona un equilibrador de carga interno para Azure. Con el equilibrador de carga interno, los clientes se comunican con el clúster a través de la dirección IP virtual del clúster.

Implemente el equilibrador de carga interno en el grupo de recursos que contiene los nodos del clúster. A continuación, configure todas las reglas de reenvío de puertos necesarias utilizando los puertos de sondeo del equilibrador de carga interno. Los clientes se pueden conectar por medio del nombre de host virtual. El servidor DNS resuelve la dirección IP del clúster. El equilibrador de carga interno controla el reenvío de puertos al nodo activo del clúster.

Figure 1: Windows Server Failover Clustering configuration in Azure without a shared disk

Ilustración 1: Configuración de clústeres de conmutación por error de Windows Server en Azure sin un disco compartido

Alta disponibilidad de ASCS/SCS de SAP con recurso compartido de archivos

SAP ha desarrollado un nuevo enfoque y alternativas para agrupar en clústeres los discos compartidos, a fin de agrupar una instancia de ASCS/SCS de SAP en un clúster de conmutación por error de Windows. En lugar de utilizar discos compartidos de clúster, puede usar un recurso compartido de archivos SMB para implementar los archivos del host global de SAP.

Nota

Un recurso compartido de archivos SMB es una alternativa al uso de discos compartidos de clúster para agrupar en clústeres instancias de ASCS/SCS de SAP.

Esta arquitectura es específica de las maneras siguientes:

  • Los servicios centrales de SAP (con su propia estructura de archivos y procesos de mensajería y puesta en cola) están separados de los archivos del host global de SAP.
  • Los servicios centrales de SAP se ejecutan en una instancia de ASCS/SCS de SAP.
  • La instancia de ASCS/SCS de SAP está en clúster y es accesible mediante el nombre de host virtual <nombre de host virtual ASCS/SCS>.
  • Los archivos globales de SAP se colocan en el recurso compartido de archivos SMB y son accesibles mediante el nombre de host del <host global de SAP>: \\<SAP global host>\sapmnt\<SID>\SYS...
  • La instancia de ASCS/SCS de SAP está instalada en un disco local en ambos nodos del clúster.
  • El nombre de red <nombre de host virtual ASCS/SCS> es diferente del <host global de SAP>.

Figure 2: SAP ASCS/SCS HA architecture with SMB file share

Ilustración 2: Arquitectura de alta disponibilidad de ASCS/SCS de SAP nueva con un recurso compartido de archivos SMB

Requisitos previos para un recurso compartido de archivos SMB:

  • Protocolo SMB 3.0 (o posterior).
  • Capacidad de establecer listas de control de acceso (ACL) de Active Directory para grupos de usuarios de Active Directory y el objeto de equipo computer$.
  • El recurso compartido de archivos debe estar habilitado para alta disponibilidad:
    • Los discos usados para almacenar archivos no deben ser un único punto de error.
    • El tiempo de inactividad del servidor o de la máquina virtual no provoca tiempo de inactividad en el recurso compartido de archivos.

El rol de clúster <SID> de SAP no contiene discos compartidos de clúster ni un recurso compartido de archivos de clúster genérico.

Figure 3: SAP <SID> cluster role resources for using a file share

Ilustración 3: Recursos del rol de clúster <SID> de SAP cuando se usa un recurso compartido de archivos

Recursos compartidos de archivos de escalabilidad horizontal con espacios de almacenamiento directo en Azure como un recurso compartido de archivos SAPMNT

Puede usar un recurso compartido de archivos de escalabilidad horizontal para hospedar y proteger los archivos del host global de SAP. Un recurso compartido de archivos de escalabilidad horizontal también ofrece un servicio de recurso compartido de archivos SAPMNT de alta disponibilidad.

Figure 4: Scale-out file share used to protect SAP global host files

Ilustración 4: Recurso compartido de archivos de escalabilidad horizontal utilizado para proteger los archivos del host global de SAP

Importante

Los recursos compartidos de archivos de escalabilidad horizontal son totalmente compatibles con la nube de Microsoft Azure y en entornos locales.

Un recurso compartido de archivos de escalabilidad horizontal ofrece un recurso compartido de archivos SAPMNT de alta disponibilidad y escalado horizontal.

Los espacios de almacenamiento directo se usan como un disco compartido para un recurso compartido de archivos de escalabilidad horizontal. Puede usar espacios de almacenamiento directo para crear almacenamiento de alta disponibilidad y escalabilidad utilizando servidores con almacenamiento local. El almacenamiento compartido que se utiliza para un recurso compartido de archivos de escalabilidad horizontal, al igual que para los archivos del host global de SAP, no es un punto único de error.

Al elegir Espacios de almacenamiento directo, tenga en cuenta estos casos de uso:

  • Las máquinas virtuales que se usan para compilar el clúster de Espacios de almacenamiento directo deben implementarse en un conjunto de disponibilidad de Azure.
  • Para la recuperación ante desastres de un clúster de Espacios de almacenamiento directo, puede usar Azure Site Recovery Services.
  • No se admite expandir el clúster de Espacios de almacenamiento directo entre distintas instancias de Azure Availability Zones.

Requisitos previos de SAP para recursos compartidos de archivos de escalabilidad horizontal en Azure

Para usar un recurso compartido de archivos de escalabilidad horizontal, el sistema debe cumplir los siguientes requisitos:

  • Al menos dos nodos del clúster para un recurso compartido de archivos de escalabilidad horizontal.
  • Cada nodo debe tener al menos dos discos locales.
  • Por motivos de rendimiento, debe usar la resistencia de creación de reflejo:
    • Creación de reflejo bidireccional para un recurso compartido de archivos de escalabilidad horizontal con dos nodos del clúster.
    • Creación de reflejo triple para un recurso compartido de archivos de escalabilidad horizontal con tres (o más) nodos del clúster.
  • Se recomiendan tres (o más) nodos del clúster para un recurso compartido de archivos de escalabilidad horizontal con creación de reflejo triple. Esta configuración ofrece más escalabilidad y resistencia de almacenamiento que la configuración de recurso compartido de archivos de escalabilidad horizontal con dos nodos del clúster y creación de reflejo bidireccional.
  • Debe usar discos Premium de Azure.
  • Se recomienda utilizar Azure Managed Disks.
  • Se recomienda dar formato a los volúmenes con el sistema de archivos resistente (ReFS).
  • Puede usar los tamaños de máquina virtual de Azure de la serie DS o la serie DSv2.
  • Para un buen rendimiento de red entre las máquinas virtuales, lo cual es necesario para la sincronización de disco de los espacios de almacenamiento directo, utilice un tipo de máquina virtual con un ancho de banda de red "alto" como mínimo. Para más información, consulte las especificaciones de la serie DSv2 y la serie DS.
  • Se recomienda reservar cierta capacidad sin asignar en el grupo de almacenamiento. Dejar cierta capacidad sin asignar en el grupo de almacenamiento da espacio a los volúmenes para una reparación "in situ" si se produce un error en una unidad. Esto mejora el rendimiento y seguridad de los datos. Para obtener más información, vea Elección del tamaño del volumen.
  • No es necesario configurar el equilibrador de carga interno de Azure para el nombre de red del recurso compartido de archivos de escalabilidad horizontal, como para el <host global de SAP>. Esto se hace para el <nombre de host virtual ASCS/SCS> de la instancia de ASCS/SCS de SAP o para el DBMS. Un recurso compartido de archivos de escalabilidad horizontal escala horizontalmente la carga entre todos los nodos del clúster. El <host global de SAP> usa la dirección IP local para todos los nodos del clúster.

Importante

No se puede cambiar el nombre del recurso compartido de archivos SAPMNT, que apunta al <host global de SAP>. SAP admite únicamente el nombre de recurso compartido "sapmnt."

Para obtener más información, vea Nota de SAP 2492395: ¿Se puede cambiar el nombre de recurso compartido sapmnt?

Configuración de instancias de ASCS/SCS de SAP y un recurso compartido de archivos de escalabilidad horizontal en dos clústeres

Debe implementar instancias de ASCS/SCS de SAP en un clúster independiente, con su propio rol de clúster <SID> de SAP. En este caso, configure el recurso compartido de archivos de escalabilidad horizontal en otro clúster con otro rol de clúster.

Importante

La configuración debe cumplir el siguiente requisito: las instancias ASCS/SCS de SAP y el recurso compartido de SOFS deben implementarse en clústeres separados.

Importante

En este escenario, la instancia de ASCS/SCS de SAP se configura para tener acceso al host global de SAP mediante la ruta de acceso UNC \\<SAP global host>\sapmnt\<SID>\SYS.

Figure 5: SAP ASCS/SCS instance and a scale-out file share deployed in two clusters

Ilustración 5: Instancia de ASCS/SCS de SAP y un recurso compartido de archivos de escalabilidad horizontal implementados en dos clústeres

Configuraciones opcionales

En los diagramas siguientes se muestran varias instancias de SAP en máquinas virtuales de Azure que ejecutan el clúster de conmutación por error de Microsoft Windows para reducir el número total de máquinas virtuales.

Se puede tratar de servidores de aplicaciones SAP locales en un clúster de ASCS/SCS de SAP o un rol de clúster de ASCS/SCS de SAP en nodos Always On de Microsoft SQL Server.

Importante

No se admite la instalación de un servidor de aplicaciones de SAP local en un nodo Always On de SQL Server.

Tanto ASCS/SCS de SAP como la base de datos de Microsoft SQL Server, son puntos de error únicos (SPOF). Para proteger estos SPOF en un entorno Windows se usa WSFC.

Aunque el consumo de recursos de ASCS/SCS de SAP es bastante pequeño, se recomienda una reducción de la configuración de memoria de 2 GB para SQL Server o para el servidor de aplicaciones SAP.

Servidores de aplicaciones SAP en nodos WSFC mediante Windows SOFS

Figure 6: Windows Server failover clustering configuration in Azure with Windows SOFS and locally installed SAP Application Server

Nota:

En la imagen se muestra el uso de discos locales adicionales. Esto es opcional para los clientes que no instalarán software de aplicación en la unidad del sistema operativo (C:)

ASCS/SCS de SAP en nodos Always On de SQL Server con Windows SOFS

Figure 7: SAP ASCS/SCS on SQL Server Always On nodes using Windows SOFS

Nota:

En la imagen se muestra el uso de discos locales adicionales. Esto es opcional para los clientes que no instalarán software de aplicación en la unidad del sistema operativo (C:)

Importante

En la nube de Azure, los clústeres que se usan para SAP y los recursos compartidos de archivos de escalabilidad horizontal deben implementarse en su propio conjunto de disponibilidad de Azure o entre instancias de Azure Availability Zones. Esto garantiza la selección de ubicación distribuida de las máquinas virtuales del clúster a través de la infraestructura subyacente de Azure. Las implementaciones de zonas de disponibilidad son compatibles con esta tecnología.

Recurso compartido de archivos genérico con SIOS DataKeeper como discos compartidos de clúster

Otra opción para conseguir un recurso compartido de archivos de alta disponibilidad es un recurso compartido de archivos genérico.

En este caso, puede usar una solución SIOS de terceros como un disco compartido de clúster.

Pasos siguientes