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 en Azure
Windows
Los clústeres de conmutación por error de Windows Server (WSFC) son la base de una instalación de ASCS/SCS de SAP de alta disponibilidad (HA) 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, los WSFC 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 varios modos de cuórum.
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 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 y el equilibrador de carga interno controla el enrutamiento de puerto al nodo activo del clúster.
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 utilizando la siguiente ruta de acceso UNC:
\\<ASCS/SCS nombre de host virtual>\sapmnt\<SID>\SYS...
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 ASCS/SCS de SAP y SAP.
Con una arquitectura de servidor de replicación de puesta en cola 1 (ERS1):
- Se usa el mismo nombre de host virtual ASCS/SCS para acceder a los procesos de servidor de mensajes y de puesta en cola de SAP, además de los archivos de host global de SAP mediante el recurso compartido de archivos sapmnt.
- El mismo disco compartido de clúster (unidad S) se comparte entre ellos.
Con arquitectura de servidor de replicación de puesta en cola 2 (ERS2):
- Se usa el mismo nombre de host virtual ASCS/SCS para acceder al proceso del servidor de mensajes de SAP y los archivos de host globales de SAP mediante el 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 distinto para acceder al proceso del servidor de puesta en cola.
Discos compartido y servidor de replicación de puesta en cola
Los discos compartidos se admiten con una arquitectura ERS1, donde la instancia de ERS1:
- No está agrupada en clústeres.
- Usa un nombre
localhost. - Está implementada en discos locales en cada uno de los nodos del clúster.
Los discos compartidos también se admiten con una arquitectura ERS2, donde la instancia de ERS2:
- Está agrupada en clústeres.
- Usa un nombre de host virtual o de red dedicado.
- Necesita la dirección IP del nombre de host virtual de ERS que se va a configurar en el equilibrador de carga interno de Azure, además de la dirección IP de (A)SCS.
- Está implementada en discos locales en cada uno de los nodos del clúster y, por lo tanto, no hay necesidad de disco compartido.
Para obtener más información sobre ERS1 y ERS2, consulte Servidor de replicación de puesta en cola en un clúster de conmutación por error de Microsoft y Nuevo replicador de puesta en cola en entornos de clústeres de conmutación por error en el sitio web de SAP.
Opciones de discos compartidos en Azure para cargas de trabajo de SAP
Hay dos opciones de disco compartido en un clúster de conmutación por error de Windows en Azure:
- Use discos compartidos de Azure para conectar discos administrados de Azure a varias máquinas virtuales simultáneamente.
- Usar SIOS DataKeeper Cluster Edition para crear un almacenamiento reflejado que simule almacenamiento compartido de clúster.
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 prémium de Azure se admite para la implementación de SAP en conjuntos de disponibilidad y zonas de disponibilidad.
- Los discos SSD Ultra de Azure y 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 prémium de Azure con un tamaño de disco mínimo, según lo especificado en Rangos de discos SSD prémium, para poder asociarlo al número requerido 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ónica en tiempo real entre dos discos.
- Con la solución de 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 manipulación 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 prémium 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 SSD Ultra de Azure y discos SSD estándar no se admiten como discos compartidos de Azure para cargas de trabajo de SAP.
- Se admiten discos compartidos de Azure con discos SSD prémium para la implementación de SAP en conjuntos de disponibilidad y zonas de disponibilidad.
- Los discos compartidos de Azure con discos SSD prémium incluyen dos opciones de almacenamiento:
- El almacenamiento con redundancia local (LRS) para discos compartidos SSD prémium (
skuNamevalor dePremium_LRS) se admite con la implementación en conjuntos de disponibilidad. - El almacenamiento con redundancia de zona (ZRS) para discos compartidos SSD prémium (
skuNamevalor dePremium_ZRS) se admite con la implementación en zonas de disponibilidad.
- El almacenamiento con redundancia local (LRS) para discos compartidos SSD prémium (
- El valor de disco compartido de Azure maxShares determina cuántos nodos de clúster puede 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
maxSharesen2. - No es necesario un Grupo con ubicación por proximidad (PPG) de Azure para discos compartidos de Azure. Pero para la implementación de SAP con PPG, siga estas instrucciones:
- 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 con ubicación por proximidad con implementaciones zonales, puede asociar el almacenamiento
Premium_ZRSa 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 prémium
Tenga en cuenta estos puntos importantes sobre los discos compartidos SSD prémium de Azure:
LRS para discos compartidos SSD prémium:
- La implementación de SAP con LRS para discos compartidos SSD prémium 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 prémium:
- 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 también lo hace. Realice pruebas comparativas en los discos para identificar la latencia de los discos ZRS en su región.
- ZRS para discos compartidos SSD prémium 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 planificar la implementación de SAP, revise Planificar e implementar 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 el Centro de datos de Windows Server 2019, por estos motivos:
- WSFC en Windows Server 2019 es consciente de Azure.
- El Centro de datos de Windows Server 2019 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 de discos compartidos es usar SIOS DataKeeper Cluster Edition para crear un almacenamiento reflejado que simule el almacenamiento compartido de 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:
- Conecte un disco adicional a cada una de las máquinas virtuales de una configuración de clúster de Windows.
- Ejecute SIOS DataKeeper Cluster Edition en ambos nodos de la máquina virtual.
- Configure SIOS DataKeeper Cluster Edition de forma que refleje el contenido del volumen del disco adicional asociado desde la máquina virtual de origen al volumen del disco adicional asociado de la máquina virtual de destino. SIOS DataKeeper abstrae los volúmenes locales de origen y de destino y los presenta a los WSFC como un disco compartido.
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 tratarse 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). 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 una reducción de la configuración de memoria de 2 GB para SQL Server o para el servidor de aplicaciones SAP.
En este diagrama se muestran los servidores de aplicaciones SAP en nodos WSFC con el uso de SIOS DataKeeper:
Puesto que los servidores de aplicaciones 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:
Para obtener información sobre otras configuraciones, consulte los siguientes recursos: