Agrupación de una instancia de ASCS/SCS de SAP en un clúster de conmutación por error de Windows mediante un disco compartido en Azure

  • Artículo

Windows OS Windows

Clústeres de conmutación por error de Windows Server (WSFC) es la base de una instalación de ASCS/SCS de SAP de alta disponibilidad y sistemas de administración de bases de datos (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, WSFC calcula el número de errores que pueden producirse y mantiene un clúster correcto para proporcionar aplicaciones y servicios. Puede elegir entre varios modos de cuórum para lograr clústeres de conmutación por error.

Requisitos previos

Antes de comenzar las tareas de este artículo, revise el artículo Arquitectura y escenarios de alta disponibilidad para SAP NetWeaver.

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

WSFC con máquinas virtuales (VM) de Azure requiere pasos de configuración adicionales. 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 llegan al 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 mediante 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 y el equilibrador de carga interno controla el enrutamiento de puerto al nodo activo del clúster.

Importante

Las direcciones IP flotantes no se admiten en una configuración IP secundaria para un adaptador de red (NIC) en escenarios de equilibrio de carga. Para ver detalles, consulte Limitaciones de Azure Load Balancer. Si necesita una dirección IP adicional para la VM, implemente una segunda NIC.

Diagram of a Windows Server Failover Clustering configuration in Azure without a shared disk.

Alta disponibilidad de ASCS/SCS de SAP con discos compartidos de clúster

En Windows, una instancia de ASCS/SCS de SAP contiene servicios centrales de SAP, el servidor de mensajes de SAP, procesos del servidor de colas y archivos de host global de SAP. Los archivos de host global de SAP almacenan archivos centrales para todo el sistema SAP.

Una instancia de ASCS/SCS de SAP tiene los siguientes componentes:

  • Servicios centrales de SAP:

    • Dos procesos (para un servidor de mensajes y un servidor de puesta en cola) y un nombre de host virtual ASCS/SCS que se usa para acceder a los dos procesos
    • Estructura de archivos: S:\usr\sap\<SID>\ASCS/SCS<número de instancia>

  • Archivos de host global de SAP :

    • Estructura de archivos: S:\usr\sap\<SID>\SYS...

    • El recurso compartido de archivos sapmnt , que permite el acceso a estos archivos S:\usr\sap\<SID>\SYS... globales mediante la siguiente ruta de acceso UNC:

      \\<ASCS/SCS virtual host name>\sapmnt\<SID>\SYS...

Diagram of processes, file structure, and global host file share of an SAP ASCS/SCS instance.

En una configuración de alta disponibilidad, se agrupan instancias de ASCS/SCS de SAP. Use discos compartidos de clúster (unidad S en el ejemplo de este artículo) para colocar los archivos de host global de SAP ASCS/SCS y SAP.

Diagram that shows an SAP ASCS/SCS high-availability architecture with shared disks.

Con una arquitectura de Enqueue Replication Server 1 (ERS1):

  • El mismo nombre de host virtual ASCS/SCS se usa para acceder al servidor de mensajes de SAP y a los procesos de servidor de cola, además de los archivos de host global de SAP a través del recurso compartido de archivos sapmnt .
  • El mismo disco compartido de clúster (unidad S) se comparte entre ellos.

Con la arquitectura de Enqueue Replication Server 2 (ERS2):

  • El mismo nombre de host virtual ASCS/SCS se usa para acceder al proceso del servidor de mensajes de SAP, además de los archivos de host global de SAP a través del recurso compartido de archivos sapmnt .
  • El mismo disco compartido de clúster (unidad S) se comparte entre ellos.
  • Hay un nombre de host virtual de ERS independiente para acceder al proceso del servidor de puesta en cola.

Diagram of an SAP ASCS/SCS high-availability architecture with a shared disk.

Discos compartidos y servidor de replicación en cola

Los discos compartidos se admiten con una arquitectura ERS1, donde la instancia de ERS1:

  • No está agrupado.
  • Usa un localhost nombre.
  • Se implementa en discos locales en cada uno de los nodos del clúster.

Los discos compartidos también se admiten con una arquitectura de ERS2, donde la instancia de ERS2:

  • Está agrupado.
  • Usa un nombre de host de red o virtual dedicado.
  • Necesita que la dirección IP del nombre de host virtual de ERS se configure en un equilibrador de carga interno de Azure, además de la dirección IP de (A)SCS.
  • Se implementa en discos locales en cada uno de los nodos agrupados, por lo que no es necesario un disco compartido.

Para obtener más información sobre ERS1 y ERS2, consulte Enqueue Replication Server in a Microsoft Failover Cluster and New Enqueue Replicator in Failover Cluster environments on the SAP website (Servidor de replicación de puesta en cola en un clúster de conmutación por error de Microsoft) y New Enqueue Replicator in Failover Cluster environments (Nuevo replicador de cola en entornos de clústeres de conmutación por error) en el sitio web de SAP.

Opciones para discos compartidos en Azure para cargas de trabajo de SAP

Hay dos opciones para los discos compartidos en un clúster de conmutación por error de Windows en Azure:

Al seleccionar la tecnología para discos compartidos, tenga en cuenta las siguientes consideraciones sobre los discos compartidos de Azure para cargas de trabajo de SAP:

  • El uso de discos compartidos de Azure con discos SSD Premium de Azure es compatible con la implementación de SAP en conjuntos de disponibilidad y zonas de disponibilidad.
  • Los discos de Azure Ultra Disk Storage y los discos SSD estándar de Azure no se admiten como discos compartidos de Azure para cargas de trabajo de SAP.
  • Asegúrese de aprovisionar discos SSD Premium de Azure con un tamaño mínimo de disco, tal como se especifica en intervalos SSD Premium, para poder conectarse al número necesario de máquinas virtuales simultáneamente. Normalmente, necesita dos máquinas virtuales para clústeres de conmutación por error de Windows de ASCS de SAP.

Tenga en cuenta las siguientes consideraciones sobre SIOS:

  • La solución SIOS proporciona replicación de datos sincrónicas en tiempo real entre dos discos.
  • Con la solución SIOS, se trabaja con dos discos administrados. Si usa conjuntos de disponibilidad o zonas de disponibilidad, los discos administrados se encuentran en clústeres de almacenamiento diferentes.
  • Se admite la implementación en zonas de disponibilidad.
  • La solución SIOS requiere la instalación y el funcionamiento de software de terceros, que debe comprar por separado.

Discos compartidos de Azure

Puede implementar alta disponibilidad de ASCS/SCS de SAP con discos compartidos de Azure.

Requisitos previos y limitaciones

Actualmente, puede usar discos SSD Premium de Azure como discos compartidos de Azure para la instancia de ASCS/SCS de SAP. Actualmente están en vigor las siguientes limitaciones:

  • Los discos de Azure Ultra Disk Storage y los discos SSD estándar no se admiten como discos compartidos de Azure para cargas de trabajo de SAP.
  • Los discos compartidos de Azure con discos SSD Premium se admiten para la implementación de SAP en conjuntos de disponibilidad y zonas de disponibilidad.
  • Los discos compartidos de Azure con discos SSD Premium incluyen dos opciones de almacenamiento:
    • El almacenamiento con redundancia local (LRS) para discos compartidos SSD Premium (skuName valor de ) se admite con la implementación en conjuntos de Premium_LRSdisponibilidad.
    • El almacenamiento con redundancia de zona (ZRS) para discos compartidos SSD Premium (skuName valor de Premium_ZRS) se admite con la implementación en zonas de disponibilidad.
  • El valor de disco compartido de Azure maxShares determina cuántos nodos de clúster pueden usar el disco compartido. En el caso de una instancia de ASCS/SCS de SAP, normalmente se configuran dos nodos en WSFC. A continuación, establezca el valor de en maxShares2.
  • No se requiere un grupo de selección de ubicación de proximidad (PPG) de Azure para discos compartidos de Azure. Pero para la implementación de SAP con PPG, siga estas directrices:
    • Si usa PPG para un sistema SAP implementado en una región, todas las máquinas virtuales que comparten un disco deben formar parte del mismo PPG.
    • Si usa PPG para un sistema SAP implementado entre zonas, como se describe en Grupos de selección de ubicación de proximidad con implementaciones zonales, puede conectar Premium_ZRS el almacenamiento a máquinas virtuales que comparten un disco.

Para más información, consulte la sección Limitaciones de la documentación de discos compartidos de Azure.

Consideraciones importantes para discos compartidos SSD Premium

Tenga en cuenta estos puntos importantes sobre los discos compartidos SSD Premium de Azure:

  • LRS para discos compartidos SSD Premium:

    • La implementación de SAP con LRS para discos compartidos SSD Premium funciona con un único disco compartido de Azure en un clúster de almacenamiento. Si hay un problema con el clúster de almacenamiento en el que se implementa el disco compartido de Azure, afecta a la instancia de ASCS/SCS de SAP.

  • ZRS para discos compartidos SSD Premium:

    • La latencia de escritura para ZRS es mayor que la de LRS debido a la copia entre zonas de los datos.
    • La distancia entre las zonas de disponibilidad de diferentes regiones varía y, por tanto, la latencia del disco ZRS entre zonas de disponibilidad. Realice pruebas comparativas de los discos para identificar la latencia de los discos ZRS en su región.
    • ZRS para discos compartidos SSD Premium replica de forma sincrónica los datos en tres zonas de disponibilidad de la región. Si hay un problema en uno de los clústeres de almacenamiento, la instancia de ASCS/SCS de SAP continúa ejecutándose porque la conmutación por error de almacenamiento es transparente para la capa de aplicación.
    • Para más información, consulte la sección Limitaciones de la documentación sobre ZRS para discos administrados.

Para conocer otras consideraciones importantes sobre cómo planear la implementación de SAP, revise Planeamiento e implementación de una implementación de SAP en azure y tipos de Azure Storage para cargas de trabajo de SAP.

Versiones de SO admitidas

Se admiten Windows Server 2016, 2019 y versiones posteriores. Use las imágenes más recientes del centro de datos.

Se recomienda encarecidamente usar al menos Windows Server 2019 Datacenter, por estos motivos:

  • WSFC en Windows Server 2019 es consciente de Azure.
  • Windows Server 2019 Datacenter incluye integración y reconocimiento del mantenimiento del host de Azure y una experiencia mejorada mediante la supervisión de eventos programados de Azure.
  • Puede usar nombres de red distribuidos. (Es la opción predeterminada). No es necesario tener una dirección IP dedicada para el nombre de red del clúster. Además, no es necesario configurar una dirección IP en un equilibrador de carga interno de Azure.

Discos compartidos en Azure con SIOS DataKeeper

Otra opción para los discos compartidos es usar SIOS DataKeeper Cluster Edition para crear un almacenamiento reflejado que simula el almacenamiento compartido del clúster. La solución SIOS proporciona replicación sincrónica de datos en tiempo real.

Para crear un recurso de disco compartido para un clúster:

  1. Conecte un disco adicional a cada una de las máquinas virtuales de una configuración de clúster de Windows.
  2. Ejecute SIOS DataKeeper Cluster Edition en ambos nodos de la máquina virtual.
  3. Configure SIOS DataKeeper Cluster Edition para que refleje el contenido del volumen adicional conectado al disco desde la máquina virtual de origen al volumen conectado al disco adicional de la máquina virtual de destino. SIOS DataKeeper abstrae los volúmenes locales de origen y de destino y, a continuación, los presenta a WSFC como un disco compartido.

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper.

Nota:

No necesita discos compartidos para obtener alta disponibilidad con algunos productos de DBMS, como SQL Server. SQL Server Always On replica archivos de registro y datos de DBMS desde el disco local de un nodo del clúster hasta el disco local del otro nodo del clúster. En este caso, la configuración de clúster de Windows no necesita un disco compartido.

Configuraciones opcionales

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

Esta configuración puede ser 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 AlwaysOn de Microsoft SQL Server.

Importante

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

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

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

En este diagrama se muestran los servidores de aplicaciones de SAP en nodos WSFC con el uso de SIOS DataKeeper:

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper and locally installed SAP application servers.

Dado que los servidores de aplicaciones de SAP se instalan localmente, no es necesario configurar ninguna sincronización.

En este diagrama se muestra ASCS/SCS de SAP en nodos AlwaysOn de SQL Server con el uso de SIOS DataKeeper:

Diagram of SAP ASCS/SCS on SQL Server Always On nodes with SIOS DataKeeper.

Para obtener información sobre otras configuraciones, consulte los siguientes recursos:

Pasos siguientes