Alta disponibilidad para SAP NetWeaver en máquinas virtuales de Azure

Azure Virtual Machines es la solución para organizaciones que necesitan recursos de red, almacenamiento y proceso, en un tiempo mínimo y sin ciclos de adquisición prolongados. Puede usar Azure Virtual Machines para implementar aplicaciones clásicas como ABAP basado en SAP NetWeaver, Java y la pila de ABAP+Java. Amplíe la confiabilidad y disponibilidad sin recursos locales adicionales. Azure Virtual Machines admite la conectividad entre locales, así que podrá integrar Azure Virtual Machines a los dominios locales, las nubes privadas y la infraestructura de sistema SAP de la organización.

En este artículo analizaremos los pasos que puede llevar a cabo para implementar sistemas SAP de alta disponibilidad en Azure con el uso del modelo de implementación de Azure Resource Manager. Le guiaremos por estas tareas principales:

• Encontrar las notas y guías de instalación de SAP adecuadas, que aparecen en la sección Recursos. Este documento complementa la documentación sobre la instalación de SAP y las notas de SAP, que son los recursos principales que lo ayudan a instalar e implementar software de SAP en plataformas específicas.
• Conocer las diferencias entre el modelo de implementación clásica de Azure y el modelo de implementación de Azure Resource Manager.
• Obtener información sobre los modos de cuórum de Clústeres de conmutación por error de Windows Server, a fin de poder seleccionar el modelo adecuado para la implementación de Azure.
• Obtener información sobre el almacenamiento compartido de Clústeres de conmutación por error de Windows Server en los servicios de Azure.
• Obtener información sobre cómo proteger en Azure los componentes con un único punto de error, como Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)/SAP Central Services (SCS) y sistemas de administración de bases de datos (DBMS), además de componentes redundantes como los servidores de aplicaciones de SAP.
• Seguir un ejemplo detallado de la instalación y configuración de un sistema SAP de alta disponibilidad en un clúster de Clústeres de conmutación por error de Windows Server mediante Azure Resource Manager.
• Obtener información sobre los pasos adicionales que se necesitan para usar Clústeres de conmutación por error de Windows Server en Azure, pero que no son necesarios en una implementación local.

Para simplificar la implementación y configuración, en este artículo usamos las nuevas plantillas de Resource Manager de alta disponibilidad y de tres niveles de SAP. Las plantillas automatizan la implementación de toda la infraestructura que necesita en un sistema SAP de alta disponibilidad. La infraestructura también admite el ajuste de tamaño de SAP Application Performance Standard (SAPS) del sistema SAP.

Requisitos previos

Antes de comenzar, asegúrese de cumplir los requisitos previos que se describen en las secciones siguientes. Además, asegúrese de revisar todos los recursos que aparecen en la sección Recursos.

En este artículo usamos las plantillas de Azure Resource Manager para SAP NetWeaver de tres niveles. Consulte Plantillas de Azure Resource Manager para SAP para ver información general útil sobre las plantillas.

Recursos

Estos artículos también se refieren a las implementaciones de SAP en Azure:

• Implementación y planeamiento de Azure Virtual Machines para SAP NetWeaver
• Implementación de Azure Virtual Machines para SAP NetWeaver
• Implementación de DBMS de Azure Virtual Machines para SAP NetWeaver
• Alta disponibilidad de Azure Virtual Machines para SAP NetWeaver (esta guía)

Estas notas de SAP están relacionadas con el tema de SAP en Azure:

Obtenga más información sobre las limitaciones de las suscripciones de Azure, incluidas las limitaciones máximas y predeterminadas generales.

SAP de alta disponibilidad con el modelo de implementación de Azure Resource Manager en comparación con el modelo de implementación clásica

El modelo de implementación de Azure Resource Manager y el modelo de implementación clásica se diferencian de las siguientes maneras:

• Grupos de recursos
• Dependencia del equilibrador de carga interno de Azure en el grupo de recursos de Azure
• Soporte técnico para el escenario de varios SID de SAP

Grupos de recursos

En Azure Resource Manager, puede usar los grupos de recursos para administrar todos los recursos de aplicación de la suscripción de Azure. En un enfoque integrado, todos los recursos de un grupo de recursos tienen el mismo ciclo de vida. Por ejemplo, todos los recursos se crean en el mismo momento y se eliminan de la misma manera. Más información sobre los grupos de recursos.

Dependencia del equilibrador de carga interno de Azure en el grupo de recursos de Azure

En el modelo de implementación clásica de Azure, hay una dependencia entre el equilibrador de carga interno de Azure (servicio Azure Load Balancer) y el grupo de servicio en la nube. Cada equilibrador de carga interno necesita un grupo de servicio en la nube.

En el modelo de Azure Resource Manager, no necesita un grupo de recursos de Azure para usar Azure Load Balancer. El entorno es más sencillo y flexible.

Soporte técnico para el escenario de varios SID de SAP

En Azure Resource Manager, puede instalar varias instancias de ASCS/SCS de identificador de sistema SAP (SID) en un clúster. Esto es posible gracias a la compatibilidad con las distintas direcciones IP de cada equilibrador de carga interno de Azure.

Si desea usar el modelo de implementación clásica de Azure, siga los procedimientos que se describen en SAP NetWeaver in Azure: Clustering SAP ASCS/SCS instances by using Windows Server Failover Clustering in Azure with SIOS DataKeeper (SAP NetWeaver en Azure: agrupación de clústeres de instancias de ASCS/SCS de SAP mediante Clústeres de conmutación por error de Windows Server en Azure con SIOS DataKeeper).

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

Clústeres de conmutación por error de Windows Server es 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, Clústeres de conmutación por error de Windows Server calcula 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.

Modos de cuórum

Puede elegir entre cuatro modos de cuórum cuando use Clústeres de conmutación por error de Windows Server:

• Mayoría de nodo. Cada nodo del clúster puede votar. El clúster funciona solamente con la mayoría de los votos, es decir, con más de la mitad. Se recomienda esta opción para los clústeres con un número impar de nodos. Por ejemplo, 3 nodos de un clúster de 7 nodos pueden presentar un error y el clúster todavía obtendrá la mayoría y se seguirá ejecutando.
• Mayoría de disco y nodo. Cada nodo y disco designado (un testigo de disco) en el almacenamiento del clúster puede votar siempre que esté disponible y comunicándose. El clúster funciona solamente con la mayoría de los votos, es decir, con más de la mitad. Este modo resulta útil en un entorno de clúster con un número par de nodos. Si la mitad de los nodos y el disco están en línea, el clúster permanece en buen estado.
• Mayoría de recurso compartido de archivos y nodo. Cada nodo más un recurso compartido de archivos designado (un testigo de recurso de archivos) que el administrador crea puede votar, independientemente de si los nodos y el recurso compartido de archivos están disponibles y comunicándose. El clúster funciona solamente con la mayoría de los votos, es decir, con más de la mitad. Este modo resulta útil en un entorno de clúster con un número par de nodos. Es similar al modo Mayoría de disco y nodo, pero usa un recurso compartido de archivos testigo en lugar de un disco testigo. Este modo es fácil de implementar pero, si el recurso compartido de archivos en sí no es de alta disponibilidad, es posible que se convierta en un único punto de error.
• Sin mayoría: solo disco. El clúster tiene cuórum si hay un nodo disponible y comunicándose con un disco específico en el almacenamiento del clúster. Los únicos nodos que pueden unirse al clúster son aquellos que estén comunicándose con ese disco. No se recomienda usar este modo.

Clústeres de conmutación por error de Windows Server local

En la figura 1 se muestra un clúster de dos nodos. Si se produce un error en la conexión de red entre los nodos pero ambos nodos se mantienen activos y en ejecución, un recurso compartido de archivos o un disco de cuórum determinará el nodo que seguirá proporcionando las aplicaciones y servicios del clúster. El nodo que tiene acceso al recurso compartido de archivos o disco de cuórum es el nodo que garantiza la continuación de los servicios.

Debido a que este ejemplo usa un clúster de dos nodos, usamos el modo de cuórum Mayoría de recurso compartido de archivos y nodo. Otra opción válida es el modo Mayoría de disco y nodo. En un entorno de producción, se recomienda usar un disco de cuórum. Puede usar tecnología de sistema de almacenamiento y red para hacerlo de alta disponibilidad.

Ilustración 1: Ejemplo de una configuración de clústeres de conmutación por error de Windows Server para ASCS/SCS de SAP en Azure

Almacenamiento compartido

En la figura 1 también se muestra un clúster de almacenamiento compartido de dos nodos. En un clúster de almacenamiento compartido local, todos los nodos del clúster detectan el almacenamiento compartido. Un mecanismo de bloqueo protege los datos contra daños. Todos los nodos pueden detectar si se produce un error en otro nodo. Si se produce un error en un nodo, el nodo restante asume la propiedad de los recursos de almacenamiento y garantiza la disponibilidad de los servicios.

Redes y resolución de nombres

Los equipos cliente se comunican con el clúster a través de una dirección IP virtual y un nombre de host virtual que el servidor DNS proporciona. Los nodos locales y el servidor DNS pueden administrar varias direcciones IP.

En una configuración típica, puede usar dos o más conexiones de red:

• Una conexión dedicada al almacenamiento.
• Una conexión de red interna del clúster para el latido.
• Una red pública que los clientes usan para conectarse al clúster.

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

En comparación con las implementaciones de nube privada o sin sistema operativo, Azure Virtual Machines requiere pasos adicionales para configurar Clústeres de conmutación por error de Windows Server. Cuando compila un disco de clúster compartido, deberá establecer varias direcciones IP y nombres de host virtual para la instancia de ASCS/SCS de SAP.

En este artículo se analizan los conceptos clave y los pasos adicionales que se requieren para compilar un clúster de servicios centrales de alta disponibilidad de SAP en Azure. Mostramos cómo configurar la herramienta de terceros SIOS DataKeeper y configurar el equilibrador de carga interno de Azure. Puede usar estas herramientas para crear un clúster de conmutación por error de Windows con un testigo de recurso compartido de archivos en Azure.

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

Disco compartido en Azure con SIOS DataKeeper

Se necesita almacenamiento compartido de clúster para una instancia de ASCS/SCS de SAP de alta disponibilidad. A partir de septiembre de 2016, Azure no ofrece almacenamiento compartido que puede usar para crear un clúster de almacenamiento compartido. Puede usar el software de terceros SIOS DataKeeper Cluster Edition para crear un almacenamiento reflejado que simula el almacenamiento compartido de clúster. La solución SIOS proporciona replicación sincrónica de datos en tiempo real. Este es el procedimiento para crear un recurso de disco compartido para un clúster:

1. Conecte un disco duro virtual (VHD) de Azure 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 de forma que refleje el contenido del volumen del VHD adicional conectado desde la máquina virtual de origen al volumen conectado del VHD adicional de la máquina virtual de destino. SIOS DataKeeper abstrae los volúmenes locales de origen y de destino, y los presenta a Clústeres de conmutación por error de Windows Server como un disco compartido.

Obtenga más información sobre SIOS DataKeeper.

Ilustración 3: Configuración de clústeres de conmutación por error de Windows Server en Azure con SIOS DataKeeper

Resolución de nombres en Azure

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. Azure tiene un equilibrador de carga interno en el servicio Azure Load Balancer. 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. Necesita implementar el equilibrador de carga interno en el grupo de recursos que contiene los nodos del clúster. Luego, configure todas las reglas de enrutamiento de puerto necesarias con 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 SAP NetWeaver en infraestructura como servicio (IaaS) de Azure

Para obtener alta disponibilidad en las aplicaciones de SAP, como para los componentes de software de SAP, necesita proteger los componentes siguientes:

• Instancia de servidores de aplicaciones de SAP
• instancia de SAP ASCS/SCS,
• servidor DBMS

Para obtener más información sobre cómo proteger los componentes SAP en escenarios de alta disponibilidad, consulte Planeamiento e implementación de Azure Virtual Machines para SAP NetWeaver.

Alta disponibilidad en los servidores de aplicaciones de SAP

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. Obtiene alta disponibilidad mediante redundancia y configurará varias instancias de diálogo en distintas instancias de Azure Virtual Machines. Debe tener, como mínimo, 2 instancias de aplicaciones de SAP instaladas en 2 instancias de Azure Virtual Machines.

Ilustración 4: Alta disponibilidad en los servidores de aplicaciones de SAP

Debe colocar 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:

• Todas las máquinas virtuales forman parte del mismo dominio de actualización. Por ejemplo, un dominio de actualización garantiza que las máquinas virtuales no se actualicen al mismo tiempo durante un tiempo de inactividad de mantenimiento planeado.
• Todas las máquinas virtuales forman parte del mismo dominio de error. Por ejemplo, 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.

Aprenda cómo administrar la disponibilidad de las máquinas virtuales.

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.

Instancia de ASCS/SCS de SAP de alta disponibilidad

La figura 5 es un ejemplo de una instancia de ASCS/SCS de SAP de alta disponibilidad.

Ilustración 5: Instancia de ASCS/SCS de SAP de alta disponibilidad

Alta disponibilidad de instancia de ASCS/SCS de SAP con Clústeres de conmutación por error de Windows Server en Azure

En comparación con las implementaciones de nube privada o sin sistema operativo, Azure Virtual Machines requiere pasos adicionales para configurar Clústeres de conmutación por error de Windows Server. A fin de compilar un clúster de conmutación por error de Windows, necesita un disco de clúster compartido, varias direcciones IP, varios nombres de host virtual y un equilibrador de carga interno de Azure para la agrupación en clústeres de una instancia de ASCS/SCS de SAP. Analizaremos esto con más detalle más adelante en el artículo.

Figura 6: Clústeres de conmutación por error de Windows Server para una configuración de ASCS/SCS de SAP en Azure con SIOS DataKeeper

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. La figura 7 muestra una solución de alta disponibilidad de SQL Server AlwaysOn en Azure mediante el uso de 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 de DBMS con su propia replicación DBMS. En este caso, no se necesitan discos compartidos de clúster, lo que simplifica toda la configuración.

Figura 7: Ejemplo de DBMS con SAP de alta disponibilidad con SQL Server AlwaysOn

Para más información sobre cómo agrupar el clústeres SQL Server en Azure con el modelo de implementación de Azure Resource Manager, consulte estos artículos:

• Configuración de un grupo de disponibilidad AlwaysOn en Azure Virtual Machines mediante Resource Manager
• Configuración de un equilibrador de carga interno para un grupo de disponibilidad AlwaysOn de Azure

Escenarios de implementación completa de alta disponibilidad

Escenario de implementación con la plantilla 1 de arquitectura

En la figura 8 se muestra un ejemplo de una arquitectura de SAP NetWeaver de alta disponibilidad en Azure para UN sistema SAP. Este escenario se configura como se indica a continuación:

• Se usa un clúster dedicado para la instancia de ASCS/SCS de SAP.
• Se usa un clúster dedicado para la instancia de DBMS.
• Se implementan instancias de servidores de aplicaciones SAP en máquinas virtuales dedicadas propias.

Figura 8: Plantilla 1 de arquitectura de alta disponibilidad de SAP con un clúster dedicado para ASCS/SCS y DBMS

Escenario de implementación con la plantilla 2 de arquitectura

En la figura 9 se muestra un ejemplo de una arquitectura de SAP NetWeaver de alta disponibilidad en Azure para UN sistema SAP. Este escenario se configura como se indica a continuación:

• Se usa un clúster dedicado TANTO para la instancia de ASCS/SCS de SAP como para la de DBMS.
• Se implementan instancias de servidores de aplicaciones SAP en máquinas virtuales dedicadas propias.

Figura 9: Plantilla 2 de arquitectura de alta disponibilidad de SAP, con un clúster dedicado para ASCS/SCS y otro para la instancia de DBMS

Escenario de implementación con la plantilla 3 de arquitectura

En la figura 10 se muestra un ejemplo de una arquitectura de SAP NetWeaver de alta disponibilidad en Azure para DOS sistemas SAP, con <SID1> y <SID2>. Este escenario se configura como se indica a continuación:

• Un clúster dedicado se usa TANTO para la instancia SID1 de ASCS/SCS como para la instancia SID2 de ASCS/SCS de SAP (un clúster).
• Se usa un clúster dedicado para SID 1 de DBMS y otro para SID2 de DBMS (dos clústeres).
• Las instancias de servidores de aplicaciones SAP del SID1 del sistema SAP tienen su propia máquina virtual dedicada.
• Las instancias de servidores de aplicaciones SAP del SID2 del sistema SAP tienen su propia máquina virtual dedicada.

Figura 10: Plantilla 3 de arquitectura de alta disponibilidad de SAP, con un clúster dedicado para las diferentes instancias de ASCS/SCS

Preparación de la infraestructura

Preparación de la infraestructura de la plantilla 1 de arquitectura

Las plantillas de Azure Resource Manager para SAP ayudan a simplificar la implementación de los recursos necesarios.

Las plantillas de 3 niveles de Azure Resource Manager también admiten escenarios de alta disponibilidad, como la plantilla 1 de arquitectura, que tiene 2 clústeres. Cada clúster es un único punto de error de SAP para ASCS/SCS de SAP y DBMS.

Aquí puede obtener las plantillas de Azure Resource Manager para el escenario de ejemplo que se describe en este artículo:

• Imagen de Azure Marketplace
• Imagen personalizada

Para preparar la plantilla 1 de arquitectura, siga estos pasos:

• En Azure Portal, en la hoja Parámetros del cuadro SYSTEMAVAILABILITY, seleccione Alta disponibilidad.

  

Figura 11: Configuración de los parámetros de Azure Resource Manager para alta disponibilidad de SAP

Las plantillas crean:

• Máquinas virtuales:

  • Máquinas virtuales de Servidor de aplicaciones de SAP: <SIDSistemaSAP>-di-<Número>
  • Máquinas virtuales de clúster de ASCS/SCS: <SIDSistemaSAP>-ascs-<Número>
  • Un clúster de DBMS: <SIDSistemaSAP>-db-<Número>

• Tarjetas de red para todas las máquinas virtuales con direcciones IP asociadas:

  • <SIDSistemaSAP>-nic-di-<Número>
  • <SIDSistemaSAP>-nic-ascs-<Número>
  • <SIDSistemaSAP>-nic-db-<Número>

• Cuentas de almacenamiento de Azure

• Grupos de disponibilidad para:

  • Máquinas virtuales de Servidor de aplicaciones de SAP: <SIDSistemaSAP>-avset-di
  • Máquinas virtuales de clúster de ASCS/SCS de SAP: <SIDSistemaSAP>-avset-ascs
  • Máquinas virtuales de clúster de DBMS: <SIDSistemaSAP>-avset-db

• Equilibrador de carga interno de Azure:

  • Con todos los puertos para la dirección IP y la instancia de ASCS/SCS <SIDSistemaSAP>-lb-ascs
  • Con todos los puertos para la dirección IP y DBMS de SQL Server <SIDSistemaSAP>-lb-db

• Grupo de seguridad de red: <SIDSistemaSAP>-nsg-ascs-0

  • Con un puerto de Protocolo de escritorio remoto (RDP) externo abierto para la máquina virtual <SIDSistemaSAP>-ascs-0

Implementación de máquinas virtuales con conectividad de red corporativa (entre locales) para uso en producción

Para los sistemas de producción de SAP, implemente máquinas virtuales de Azure con conectividad de red corporativa mediante el uso de VPN de sitio a sitio de Azure o Azure ExpressRoute.

1. En Azure Portal, en la hoja Parámetros del cuadro NEWOREXISTINGSUBNET, seleccione Existente.

2. En el cuadro SUBNETID, agregue la cadena completa de SubnetID de la red de Azure, donde planea implementar las máquinas virtuales de Azure.

3. Ejecute este comando de PowerShell para obtener una lista de todas las subredes de red de Azure:

   (Get-AzureRmVirtualNetwork -Name <azureVnetName>  -ResourceGroupName <ResourceGroupOfVNET>).Subnets
   

   El campo ID muestra el valor de SUBNETID.

4. Ejecute este comando de PowerShell para obtener una lista de todos los valores de SUBNETID:

   (Get-AzureRmVirtualNetwork -Name <azureVnetName>  -ResourceGroupName <ResourceGroupOfVNET>).Subnets.Id
   

   El aspecto del identificador SUBNETID es similar al siguiente:

   /subscriptions/<SubscriptionId>/resourceGroups/<VPNName>/providers/Microsoft.Network/virtualNetworks/azureVnet/subnets/<SubnetName>
   

Implementación solo en la nube de instancias de SAP para prueba o demostración

Puede implementar el sistema de SAP de alta disponibilidad en un modelo de implementación solo en la nube. Este tipo de implementación se usa principalmente para demostrar o probar casos de uso. No es idóneo para los casos de uso de producción.

• En Azure Portal, en la hoja Parámetros del cuadro NEWOREXISTINGSUBNET, seleccione Nuevo. Deje vacío el campo SUBNETID.

  La plantilla de Azure Resource Manager para SAP crea automáticamente la subred y red virtual de Azure.

Preparación de la infraestructura de la plantilla 2 de arquitectura

Puede usar estas plantillas de Azure Resource Manager para simplificar la implementación de los recursos de la infraestructura necesarios para la plantilla 2 de arquitectura de SAP.

Aquí puede obtener las plantillas de Azure Resource Manager para este escenario de implementación:

• Imagen de Azure Marketplace
• Imagen personalizada

Preparación de la infraestructura de la plantilla 3 de arquitectura

Puede preparar la infraestructura y configurar SAP para varios SID. Por ejemplo, puede agregar una instancia de ASCS/SCS de SAP adicional en una configuración de clúster existente. Para obtener más información, consulte Configuración de una instancia adicional de ASCS/SCS de SAP en una configuración de clúster existente para crear una configuración de varios SID de SAP: Azure Resource Manager.

Si desea crear un nuevo clúster de varios SID, puede usar las plantillas de inicio rápido en GitHub para varios SID. Para crear un nuevo clúster de varios SID, debe implementar las tres plantillas siguientes:

• Plantilla de ASCS/SCS
• Plantilla de base de datos
• Plantilla de servidores de aplicaciones

Las siguientes secciones contienen más detalles sobre las plantillas y los parámetros que debe proporcionar en las plantillas.

Plantilla de ASCS/SCS

La plantilla de ASCS/SCS permite implementar dos máquinas virtuales que se pueden usar para crear un clúster de conmutación por error de Windows Server que hospeda varias instancias de ASCS/SCS.

Para configurar la plantilla de varios SID de ASCS/SCS, en la plantilla de varios SID de ASCS/SCS, especifique valores para los parámetros siguientes:

• Prefijo de recurso. Establezca el prefijo de recurso, que se utiliza para prefijar todos los recursos que se hayan creado durante la implementación. Dado que los recursos no pertenecen a un único sistema SAP, el prefijo del recurso no es el SID de un sistema SAP. El prefijo debe tener entre tres y seis caracteres.
• Tipo de pila. Seleccione el tipo de la pila del sistema SAP. Dependiendo del tipo de la pila, Azure Load Balancer tendrá una (solo ABAP o JAVA) o dos (ABAP + JAVA) direcciones IP privadas por cada sistema SAP.
• Tipo de sistema operativo. Seleccione el sistema operativo de las máquinas virtuales.
• Recuento de sistema SAP. Seleccione número de sistemas SAP que desea instalar en este clúster.
• Disponibilidad del sistema. Seleccione Alta disponibilidad.
• Nombre de usuario y contraseña del administrador. Cree un nuevo usuario que pueda usarse para iniciar sesión en la máquina.
• Subred nueva o existente. Establezca si es necesario crear una red virtual y subred nuevas o si se debe usar una subred existente. Si ya tiene una red virtual conectada a la red local, seleccione la existente.
• Identificador de subred. Si quiere implementar la máquina virtual en una red virtual existente en la que tiene una subred definida a la que se debe asignar la máquina virtual, asigne un nombre al identificador de esa subred específica. El identificador suele tener este formato: /subscriptions/<id. de suscripción>/resourceGroups/<nombre del grupo de recursos>/providers/Microsoft.Network/virtualNetworks/<nombre de la red virtual>/subnets/<nombre la de subred>

La plantilla implementa una instancia de Azure Load Balancer que admite varios sistemas SAP.

• Las instancias de ASCS se configuran según el número de instancia 00, 10, 20...
• Las instancias de SCS se configuran según el número de instancia 01, 11, 21...
• Las instancias de ASCS Enqueue Replication Server (ERS) (solo Linux) se configuran según el número de instancia 02, 12, 22, etc.
• Las instancias de SCS ERS (solo Linux) se configuran según el número de instancia 03, 13, 23...

El equilibrador de carga contiene 1 (2 para Linux) VIP, 1 VIP para ASCS/SCS y 1 VIP para ERS (solo Linux).

En la lista siguiente se incluyen todas las reglas de equilibrio de carga (donde x es el número del sistema SAP, por ejemplo, 1, 2, 3, etc.):

• Puertos específicos de Windows para cada sistema SAP: 445, 5985
• Puertos ASCS (número de instancia x0): 32x0, 36x0, 39x0, 81x0, 5x013, 5x014, 5x016
• Puertos SCS (número de instancia x1): 32x1, 33x1, 39x1, 81x1, 5x113, 5x114, 5x116
• Puertos ASCS ERS en Linux (número de instancia x2): 33x2, 5x213, 5x214, 5x216
• Puertos SCS ERS en Linux (número de instancia x3): 33x3, 5x313, 5x314, 5x316

El equilibrador de carga se configurará para usar los siguientes puertos de sondeo (donde x es el número del sistema SAP, por ejemplo, 1, 2, 3,...):

• Puerto de sondeo del equilibrador de carga interno de ASCS/SCS: 620x0
• Puerto de sondeo del equilibrador de carga interno de ERS (solo para Linux): 621x2

Plantilla de base de datos

La plantilla de la base de datos implementa uno o dos máquinas virtuales que puede usar para instalar el sistema de administración de bases de datos relacionales (RDBMS) de un sistema SAP. Por ejemplo, si ha implementado una plantilla de ASCS/SCS para 5 sistemas SAP, debe implementar esta plantilla cinco veces.

Para configurar la plantilla de varios SID de las bases de datos, especifique en ella los valores para los parámetros siguientes:

• Identificador de sistema SAP. Escriba el identificador del sistema SAP que se va a instalar. El identificador se utilizará como prefijo para los recursos que se implementen.
• Tipo de sistema operativo. Seleccione el sistema operativo de las máquinas virtuales.
• Dbtype. Seleccione el tipo de base de datos que desea instalar en el clúster. Seleccione SQL si desea instalar Microsoft SQL Server. Seleccione HANA si tiene previsto instalar SAP HANA en las máquinas virtuales. Asegúrese de seleccionar el tipo de sistema operativo correcto: Windows para SQL y una distribución de Linux para HANA. La instancia de Azure Load Balancer que está conectada a las máquinas virtuales se configurará para admitir el tipo de base de datos seleccionado:
  • SQL. El equilibrador de carga equilibrará la carga del puerto 1433. Asegúrese de que utiliza este puerto para la configuración de SQL Server Always On.
  • HANA. El equilibrador de carga equilibrará la carga de los puertos 35015 y 35017. Asegúrese de instalar SAP HANA con el número de instancia 50. El equilibrador de carga usará el puerto de sondeo 62550.
• Tamaño del sistema SAP. La cantidad de sistemas SAP que proporcionará el sistema nuevo. Si no está seguro de cuántos SAPS necesitará el sistema, consulte con el integrador de sistemas o el asociado tecnológico de SAP.
• Disponibilidad del sistema. Seleccione Alta disponibilidad.
• Nombre de usuario y contraseña del administrador. Cree un nuevo usuario que pueda usarse para iniciar sesión en la máquina.
• Identificador de subred. Escriba el identificador de la subred que usó durante la implementación de la plantilla de ASCS/SCS o el identificador de la subred que se creó como parte de la implementación de esta plantilla.

Plantilla de servidores de aplicaciones

La plantilla de servidores de aplicaciones permite implementar dos o más máquinas virtuales que se pueden usar como instancias de servidores de aplicaciones SAP en un sistema SAP. Por ejemplo, si ha implementado una plantilla de ASCS/SCS para 5 sistemas SAP, debe implementar esta plantilla cinco veces.

Para configurar la plantilla de varios SID de servidores de aplicaciones, especifique en ella los valores para los parámetros siguientes:

• Identificador de sistema SAP. Escriba el identificador del sistema SAP que se va a instalar. El identificador se utilizará como prefijo para los recursos que se implementen.
• Tipo de sistema operativo. Seleccione el sistema operativo de las máquinas virtuales.
• Tamaño del sistema SAP. La cantidad de SAPS que proporcionará el sistema nuevo. Si no está seguro de cuántos SAPS necesitará el sistema, consulte con el integrador de sistemas o el asociado tecnológico de SAP.
• Disponibilidad del sistema. Seleccione Alta disponibilidad.
• Nombre de usuario y contraseña del administrador. Cree un nuevo usuario que pueda usarse para iniciar sesión en la máquina.
• Identificador de subred. Escriba el identificador de la subred que usó durante la implementación de la plantilla de ASCS/SCS o el identificador de la subred que se creó como parte de la implementación de esta plantilla.

Azure Virtual Network

En nuestro ejemplo, el espacio de direcciones de la máquina virtual de Azure es 10.0.0.0/16. Hay una subred llamada Subnet, con un intervalo de direcciones de 10.0.0.0/24. Todas las máquinas virtuales y los equilibradores de carga internos están implementados en esta red virtual.

Direcciones IP de DNS

Para configurar las direcciones IP de DNS que se requieren, realice los pasos siguientes.

1. En Azure Portal, en la hoja Servidores DNS, asegúrese de que la opción Servidores DNS de la red virtual está establecida en DNS personalizado.

2. Seleccione la configuración según el tipo de red que tiene. Para obtener más información, consulte los siguientes recursos:

   • agregue las direcciones IP de los servidores DNS locales.
     Puede extender los servidores DNS locales a las máquinas virtuales que se ejecutan en Azure. En ese escenario, puede agregar las direcciones IP de las máquinas virtuales de Azure en las que ejecuta el servidor DNS.
   • Para implementaciones aisladas en Azure: implemente una máquina virtual adicional en la misma instancia de Virtual Network que actúa como servidor DNS. Agregue las direcciones IP de las máquinas virtuales de Azure que configuró para ejecutar el servicio DNS.

   

   Figura 12: Configuración de servidores DNS para Azure Virtual Network

   Nota

   Si cambia las direcciones IP de los servidores DNS, debe reiniciar las máquinas virtuales de Azure para aplicar el cambio y propagar los nuevos servidores DNS.

En este ejemplo, el servicio DNS está instalado y configurado en estas máquinas virtuales de Windows:

Nombres de host y direcciones IP estáticas para la instancia en clúster de ASCS/SCS de SAP y la instancia de clúster de DBMS

Para la implementación local, necesita estas direcciones IP y nombres de host reservados:

Cuando crea el clúster, crea los nombres de host virtual pr1-ascs-vir y pr1-dbms-vir, además de las direcciones IP asociadas que administrar el clúster mismo. Para más información sobre cómo hacerlo, consulte Recopilación de nodos del clúster en la configuración de clúster.

Puede crear manualmente los otros 2 nombres de host virtual, pr1-ascs-sap y pr1-dbms-sap, y las direcciones IP asociadas en el servidor DNS. La instancia de ASCS/SCS de SAP en clúster y la instancia de DBMS en clúster usan estos recursos. Para más información sobre cómo hacerlo, vea Creación de un nombre de host virtual para la instancia de ASCS/SCS de SAP en clúster.

Configuración de direcciones IP estáticas para las máquinas virtuales SAP

Después de implementar las máquinas virtuales que usará en el clúster, deberá establecer direcciones IP estáticas para todas las máquinas virtuales. Debe hacerlo en la configuración de Azure Virtual Network y no en el sistema operativo invitado.

1. En Azure Portal, seleccione Grupo de recursos > Tarjeta de red > Configuración > Dirección IP.

2. En la hoja Direcciones IP, en Asignación, seleccione Estática. En el cuadro Dirección IP, escriba la dirección IP que desea usar.

   Nota

   Si cambia la dirección IP de la tarjeta de red, deberá reiniciar las máquinas virtuales de Azure para aplicar el cambio.

   

   Figura 13: Establecimiento de direcciones IP estáticas para la tarjeta de red de cada máquina virtual

   Repita este paso para todas las interfaces de red, es decir, para todas las máquinas virtuales, incluidas las que desea usar para Active Directory/servicio DNS.

En este ejemplo, aparecen estas máquinas virtuales y direcciones IP estáticas:

Configuración de una dirección IP estática para el equilibrador de carga interno de Azure

La plantilla de Azure Resource Manager para SAP crea un equilibrador de carga interno de Azure que se usa para el clúster de instancia de ASCS/SCS de SAP y el clúster de DBMS.

Para configurar una dirección IP estática para el equilibrador de carga interno de Azure, siga estos pasos:

1. En la implementación inicial se establece la dirección IP del equilibrador de carga interno como Dinámica. En la hoja Direcciones IP de Azure Portal, en Asignación, seleccione Estática.

2. Establezca la dirección IP del equilibrador de carga interno pr1-lb-ascs en la dirección IP del nombre de host virtual de la instancia de ASCS/SCS de SAP.

3. Establezca la dirección IP del equilibrador de carga interno pr1-lb-dbms en la dirección IP del nombre de host virtual de la instancia de DBMS.

   

   Figura 14: Establecimiento de direcciones IP estáticas para el equilibrador de carga interno de la instancia de ASCS/SCS de SAP

En este ejemplo, aparecen 2 equilibradores de carga internos de Azure que tienen estas direcciones IP estáticas:

Reglas predeterminadas de equilibrio de carga de ASCS/SCS para el equilibrador de carga interno de Azure

La plantilla de Azure Resource Manager para SAP crea los puertos que necesita:

• Una instancia de ASCS ABAP con el número de instancia predeterminado 00
• Una instancia de SCS de Java con el número de instancia predeterminado 01

Cuando instala la instancia de ASCS/SCS de SAP, debe usar el número de instancia predeterminado 00 para la instancia de ASCS ABAP y el número de instancia predeterminado 01 para la instancia de SCS de Java.

Después, cree estos puntos de conexión de equilibrio de carga interno necesarios para los puertos de SAP NetWeaver.

Para crear estos puntos de conexión de equilibrio de carga interno necesarios, créelos para los puertos de ASCS ABAP de SAP NetWeaver:

Tabla 1: Números de puerto de las instancias de ASCS ABAP de SAP NetWeaver

Luego, cree estos puntos de conexión de equilibrio de carga interno para los puertos de SCS de Java de SAP NetWeaver:

Tabla 2: Números de puerto de las instancias de SCS de Java de SAP NetWeaver

Figura 15: Reglas predeterminadas de equilibrio de carga de ASCS/SCS para el equilibrador de carga interno de Azure

Establezca la dirección IP del equilibrador de carga pr1-lb-dbms en la dirección IP del nombre de host virtual de la instancia de DBMS.

Cambio de las reglas predeterminadas de equilibrio de carga de ASCS/SCS para el equilibrador de carga interno de Azure

Si desea usar otros números para las instancias de ASCS o SCS de SAP, debe actualizar los nombres y valores de sus puertos a partir de los predeterminados.

1. En Azure Portal, seleccione <SID>-lb-ascs load balancer > Reglas de equilibrio de carga.

2. Cambie estos valores para todas las reglas de equilibrio de carga que pertenezcan a la instancia de ASCS o SCS de SAP:

   • Nombre
   • Port
   • Puerto de back-end

   Por ejemplo, si desea cambiar el número de instancia de ASCS predeterminado de 00 a 31, debe hacer cambios en todos los puertos que aparecen en la tabla 1.

   A continuación, se muestra un ejemplo de una actualización para el puerto lbrule3200.

   

   Figura 16: Cambio de las reglas predeterminadas de equilibrio de carga de ASCS/SCS para el equilibrador de carga interno de Azure

Incorporación de máquinas virtuales de Windows al dominio

Después de asignar una dirección IP estática a las máquinas virtuales, agregue las máquinas virtuales al dominio.

Figura 17: Incorporación de una máquina virtual a un dominio

Incorporación de entradas del Registro en ambos nodos del clúster usados para la instancia de ASCS/SCS de SAP

Azure Load Balancer tiene un equilibrador de carga interno que cierra las conexiones cuando están inactivas durante un período establecido (tiempo de espera de inactividad). Los proceso de trabajo de SAP en instancias de diálogo abren conexiones con el proceso de puesta en cola de SAP tan pronto como se deba enviar la primera solicitud para poner en cola y para quitar de la cola. Estas conexiones suelen mantenerse hasta que el proceso de trabajo o el de puesta en cola se reinicia. Sin embargo, si la conexión está inactiva durante un periodo, el equilibrador de carga interno de Azure cierra la conexión. Esto no supone un problema, porque el proceso de trabajo de SAP restablece la conexión con el proceso de puesta en cola si ya no existe. Estas actividades se documentan en los seguimientos de desarrollador de los procesos de SAP, pero crean una gran cantidad de contenido adicional en esos seguimientos. Se recomienda cambiar los parámetros de TCP/IP KeepAliveTime y KeepAliveInterval en ambos nodos del clúster. Combine estos cambios en los parámetros de TCP/IP con los parámetros de perfil de SAP, lo que se describe más adelante en este artículo.

Para agregar entradas de registro en los dos nodos de clúster de la instancia de ASCS/SCS de SAP, en primer lugar, agregue estas entradas del registro de Windows en ambos nodos de clúster de Windows para ASCS/SCS de SAP:

Tabla 3: Cambio del primer parámetro de TCP/IP

Luego, agregue estas entradas del Registro de Windows en los nodos de clúster de Windows para ASCS/SCS de SAP:

Tabla 4: Cambio del segundo parámetro de TCP/IP

Para aplicar los cambios, reinicie ambos nodos del clúster.

Configuración del clúster de Clústeres de conmutación por error de Windows para la instancia de ASCS/SCS de SAP

Para configurar el clúster de Clústeres de conmutación por error de Windows para la instancia de ASCS/SCS de SAP, hay que realizar estas tareas:

• Recopilación de nodos del clúster en la configuración de clúster
• Configuración de un testigo de recurso compartido de archivos de clúster

Recopilación de nodos del clúster en la configuración de clúster

1. En el Asistente para Agregar roles y características, agregue a ambos nodos del clúster agrupaciones en clústeres de conmutación por error.

2. Configure el clúster de conmutación por error mediante el Administrador de clústeres de conmutación por error. En el Administrador de clústeres de conmutación por error, seleccione Crear clúster y, luego, agregue solo el nombre del primer clúster, el nodo A. No agregue el segundo nodo aún, ya que lo agregará en un paso posterior.

   

   Figura 18: Incorporación del nombre de servidor o máquina virtual del primer nodo del clúster

3. Escriba el nombre de red (nombre de host virtual) del clúster.

   

   Figura 19: Escriba el nombre del clúster

4. Una vez creado el clúster, ejecute una prueba de validación del clúster.

   

   Figura 20: Ejecución de la comprobación de validación del clúster

   En este punto del proceso, puede omitir cualquier advertencia sobre los discos. Agregará un testigo de recurso de archivos y los discos compartidos de SIOS más tarde. En esta fase, no es necesario preocuparse por el cuórum.

   

   Figura 21: No se encuentra disco de cuórum

   

   Figura 22: El recurso de clúster principal necesita una dirección IP nueva

5. Cambie la dirección IP del servicio de clúster principal. El clúster no se puede iniciar hasta que no cambie la dirección IP del servicio de clúster principal, porque la dirección IP del servidor apunta a uno de los nodos de la máquina virtual. Para ello, vaya a la página Propiedad del recurso de dirección IP del servicio de clúster principal.

   Por ejemplo, necesitamos asignar una dirección IP (10.0.0.42 en el ejemplo) para el nombre de host virtual del clúster pr1-ascs-vir.

   

   Figura 23: En el cuadro de diálogo Propiedades, cambie la dirección IP

   

   Figura 24: Asignación de la dirección IP reservada para el clúster

6. Escriba el nombre del host virtual del clúster en línea.

   

   Figura 25: El servicio principal del clúster está activo, en ejecución y tiene la dirección IP correcta

7. Agregue el segundo nodo del clúster.

   Ahora que el servicio de clúster principal está en funcionamiento, puede agregar el segundo nodo del clúster.

   

   Figura 26: Incorporación del segundo nodo del clúster

8. Escriba un nombre para el segundo host del nodo de clúster.

   

   Figura 27: Escriba el segundo nombre de host del nodo de clúster

   Importante

   Asegúrese de que la casilla Agregar todo el almacenamiento apto al clúster NO esté activada.

   

   Figura 28: No active la casilla

   Puede pasar por alto las advertencias sobre el cuórum y los discos. Establecerá el cuórum y compartirá el disco más adelante, tal como se describe en Instalación de SIOS DataKeeper Cluster Edition para un disco compartido de clúster de ASCS/SCS de SAP.

   

   Figura 29: Omisión de las advertencias sobre el cuórum de disco

Configuración de un testigo de recurso compartido de archivos de clúster

Para configurar un testigo de recurso compartido de archivos de clúster, hay que realizar las siguientes tareas:

• Creación de un recurso compartido de archivos
• Configuración del cuórum de testigo del recurso compartido de archivos en el Administrador de clústeres de conmutación por error

Creación de un recurso compartido de archivos

1. Seleccione un testigo de recurso de archivos en lugar de un disco de cuórum. SIOS DataKeeper admite esta opción.

   En los ejemplos de este artículo, el testigo de recurso compartido de archivos se encuentra en la instancia de Active Directory/el servidor DNS que se ejecuta en Azure. El testigo de recurso compartido de archivos se llama domcontr-0. Dado que habría configurado una conexión de VPN con Azure (a través de VPN de sitio a sitio o Azure ExpressRoute), su instancia de Active Directory/servidor DNS es local y no es apta para ejecutar un testigo de recurso compartido de archivos.

   Nota

   Si la instancia de Active Directory/el servidor DNS solo se ejecuta localmente, no configure el testigo de recurso compartido de archivos en la instancia de Active Directory/sistema operativo Windows de DNS que se ejecuta localmente. La latencia de red entre los nodos de clúster que se ejecutan en Azure y Active Directory/DNS local puede ser demasiado grande y provocar problemas de conectividad. Asegúrese de configurar el testigo de recurso compartido de archivos en una máquina virtual de Azure que se ejecuta cerca del nodo del clúster.

   La unidad de cuórum necesita, como mínimo, 1024 MB de espacio disponible. Se recomienda 2048 MB de espacio disponible en la unidad de cuórum.

2. Agregue el objeto de nombre de clúster.

   

   Figura 30: Asignación de los permisos en el recurso compartido para el objeto de nombre de clúster

   Asegúrese de que los permisos incluyan la autoridad para cambiar datos en el recurso compartido para el objeto de nombre de clúster (pr1-ascs-vir$ en el ejemplo).

3. Para agregar el objeto de nombre de clúster a la lista, seleccione Agregar. Cambie el filtro para buscar objetos de equipo, además de los que aparecen en la figura 31.

   

   Figura 31: Cambio de los tipos de objeto para incluir los equipos

   

   Figura 32: Active la casilla Equipos

4. Escriba el objeto de nombre de clúster, como aparece en la figura 31. Como ya se creó el registro, puede cambiar los permisos, tal como aparece en la figura 30.

5. Seleccione la pestaña Seguridad del recurso compartido y, luego, establezca permisos más detallados para el objeto de nombre de clúster.

   

   Figura 33: Establecimiento de los atributos de seguridad para el objeto de nombre de clúster en el cuórum de recurso compartido de archivos

Configuración del cuórum de testigo del recurso compartido de archivos en el Administrador de clústeres de conmutación por error

1. Abra el Asistente para la configuración de cuórum.

   

   Figura 34: Inicio del Asistente para configurar el cuórum de clúster

2. En la página Seleccionar opción de configuración de cuórum, seleccione Seleccionar el testigo de cuórum.

   

   Figura 35: Configuraciones de cuórum que puede elegir

3. En la página Seleccionar testigo de cuórum, elija Configurar un testigo de recurso compartido de archivos.

   

   Figura 36: Selección del testigo de recurso compartido de archivos

4. Escriba la ruta de acceso UNC al recurso compartido de archivos (\domcontr-0\FSW en el ejemplo). Seleccione Siguiente para ver una lista de los cambios que puede hacer.

   

   Figura 37: Definición de la ubicación del recurso compartido de archivos para el recurso compartido testigo

5. Seleccione los cambios que desee y, luego, seleccione Siguiente. En este último paso, necesita volver a configurar correctamente el clúster, tal como aparece en la figura 38.

   

   Figura 38: Confirmación de que volvió a configurar el clúster

Después de instalar correctamente el clúster de conmutación por error de Windows, se deben realizar cambios en algunos umbrales para adaptar la detección de conmutación por error a las condiciones de Azure. Los parámetros que se van a cambiar se documentan en este blog: https://techcommunity.microsoft.com/t5/Failover-Clustering/Tuning-Failover-Cluster-Network-Thresholds/ba-p/371834. Suponiendo que las dos máquinas virtuales que compilación la configuración de clúster de Windows para ASCS/SCS están en la misma subred, los parámetros siguientes deben cambiarse a estos valores:

• SameSubNetDelay = 2000
• SameSubNetThreshold = 15
• RoutingHistoryLength = 30

Esta configuración se ha probado con los clientes y proporciona un buen compromiso para que, por un lado, sea lo suficientemente resistente. Por otro lado, dicha configuración proporciona una conmutación por error lo suficientemente rápida en condiciones de error real en caso de error de máquinas virtuales o nodos, o de software SAP.

Instalación de SIOS DataKeeper Cluster Edition para un disco compartido de clúster de ASCS/SCS de SAP

Ahora tiene una configuración de Clústeres de conmutación por error de Windows Server activa en Azure. Pero, para instalar una instancia de ASCS/SCS de SAP, necesita un recurso de disco compartido. No puede crear los recursos de disco compartido que necesita en Azure. SIOS DataKeeper Cluster Edition es una solución de terceros que puede usar para crear recursos de disco compartido.

Para instalar SIOS DataKeeper Cluster Edition en un disco compartido de clúster de ASCS/SCS de SAP, siga estos pasos:

• Incorporación de .NET Framework 3.5
• Instalación de SIOS DataKeeper
• Configuración de SIOS DataKeeper

Incorporación de la característica .NET Framework 3.5

Microsoft .NET Framework 3.5 no está activo ni instalado automáticamente en Windows Server 2012 R2. Dado que SIOS DataKeeper requiere .NET Framework como en todos los nodos donde se instala DataKeeper, debe instalar .NET Framework 3.5 en el sistema operativo invitado de todas las máquinas virtuales del clúster.

Hay dos maneras de agregar .NET Framework 3.5:

• Use el Asistente para agregar roles y características en Windows, que se muestra en la figura 39.

  

  Figura 39: Instalación de .NET Framework 3.5 por medio del Asistente para agregar roles y características

  

  Figura 40: Barra de progreso de instalación cuando instala .NET Framework 3.5 por medio del Asistente para agregar roles y características

• Utilice la herramienta de línea de comandos dism.exe. Para este tipo de instalación, necesita tener acceso al directorio SxS en los medios de instalación de Windows. En un símbolo del sistema con privilegios elevados, escriba:

  Dism /online /enable-feature /featurename:NetFx3 /All /Source:installation_media_drive:\sources\sxs /LimitAccess
  

Instalación de SIOS DataKeeper

Instale SIOS DataKeeper Cluster Edition en cada nodo del clúster. Con SIOS DataKeeper, para crear el almacenamiento compartido virtual, cree un reflejo sincronizado y, luego, simule el almacenamiento compartido de clúster.

Antes de instalar el software SIOS, cree el usuario de dominio DataKeeperSvc.

Para instalar SIOS DataKeeper, siga estos pasos:

1. Instale el software SIOS en ambos nodos del clúster.

   

   

   Figura 41: Primera página de la instalación de SIOS DataKeeper

2. En el cuadro de diálogo que aparece en la figura 42, seleccione Sí.

   

   Figura 42: DataKeeper le informa que se deshabilitará un servicio

3. En el cuadro de diálogo que aparece en la figura 43, se recomienda seleccionar Cuenta de dominio o de servidor.

   

   Figura 43: Selección del usuario para SIOS DataKeeper

4. Escriba el nombre de usuario y contraseñas de cuenta de dominio que creó para SIOS DataKeeper.

   

   Figura 44: Introducción del nombre de usuario y contraseña de dominio para la instalación de SIOS DataKeeper

5. Instale la clave de licencia para la instancia de SIOS DataKeeper, tal como aparece en la figura 45.

   

   Figura 45: Especificación de la licencia de SIOS DataKeeper

6. Cuando se le solicite, reinicie la máquina virtual.

Configuración de SIOS DataKeeper

Después de instalar SIOS DataKeeper en ambos nodos, debe iniciar la configuración. El objetivo de la configuración es conseguir la replicación sincrónica de datos entre los VHD adicionales conectados a cada una de las máquinas virtuales.

1. Inicie la herramienta de configuración y administración de DataKeeper y, luego, seleccione Servidor de conexión. (En la figura 46, esta opción aparece rodeada de un círculo de color rojo).

   

   Figura 46: Herramienta de configuración y administración de SIOS DataKeeper

2. Escriba el nombre o la dirección TCP/IP del primer nodo al que se debe conectar la herramienta de configuración y administración y, en un segundo paso, el segundo nodo.

   

   Figura 47: Inserte el nombre o la dirección TCP/IP del primer nodo al que se debe conectar la herramienta de configuración y administración y, en un segundo paso, el segundo nodo

3. Cree el trabajo de replicación entre los dos nodos.

   

   Figura 48: Creación de un trabajo de replicación

   Un asistente le guía por el proceso de crear un trabajo de replicación.

4. Defina el nombre, la dirección TCP/IP y el volumen de disco del nodo de origen.

   

   Figura 49: Definición del nombre del trabajo de replicación

   

   Figura 50: Definición de los datos básicos para el nodo que debe ser el nodo de origen actual

5. Defina el nombre, la dirección TCP/IP y el volumen de disco del nodo de destino.

   

   Figura 51: Definición de los datos básicos para el nodo que debe ser el nodo de destino actual

6. Defina los algoritmos de compresión. En el ejemplo, se recomienda comprimir el flujo de replicación. Especialmente en situaciones de resincronización, la compresión del flujo de replicación reduce considerablemente el tiempo que se tarda en resincronizar. Tenga en cuenta que la compresión usa los recursos de CPU y RAM de una máquina virtual. A medida que aumenta la tasa de compresión, también aumenta el volumen de los recursos de CPU usados. También puede ajustar esta configuración más adelante.

7. Otra configuración que debe comprobar es si la replicación se ejecuta de forma sincrónica o asincrónica. Cuando proteja las configuraciones de ASCS/SCS de SAP, debe usar la replicación sincrónica.

   

   Figura 52: Definición de los detalles de la replicación

8. Defina si el volumen que el trabajo de replicación replica se debe representar en una configuración de clúster de Clústeres de conmutación por error de Windows Server como disco compartido. Para la configuración de ASCS/SCS de SAP, seleccione Sí de manera que el clúster de Windows vea el volumen replicado como un disco compartido que puede usar como volumen de clúster.

   

   Figura 53: Selección de Sí para establecer el volumen replicado como volumen de clúster

   Una vez creado el volumen, la herramienta de configuración y administración de DataKeeper muestra que el trabajo de replicación está activo.

   

   Figura 54: El reflejo sincrónico de DataKeeper para el disco compartido de ASCS/SCS de SAP está activo

   Ahora, el Administrador de clústeres de conmutación por error muestra el disco como un disco de DataKeeper, tal como aparece en la figura 55.

   

   Figura 55: El Administrador de clústeres de conmutación por error muestra el disco que DataKeeper replicó

Instalación del sistema SAP NetWeaver

No se describirá la configuración de DBMS porque las opciones varían en función del sistema DBMS que usa. Sin embargo, se da por supuesto que las inquietudes respecto de la alta disponibilidad con DBMS se abordan con las funcionalidades que admiten los diversos proveedores de DBMS para Azure. Por ejemplo, AlwaysOn o creación de reflejo de la base de datos para SQL Server y Oracle Data Guard para Oracle. En el escenario de este artículo, no se agregó más protección a DBMS.

No hay ninguna consideración especial cuando distintos servicios de DBMS interactúan con esta variante de configuración de ASCS/SCS de SAP en clúster en Azure.

Instalación de SAP con una instancia de ASCS/SCS de alta disponibilidad

Para instalar SAP con una instancia de ASCS/SCS de alta disponibilidad, siga estos pasos:

• Creación de un nombre de host virtual para la instancia de ASCS/SCS de SAP en clúster
• Instalación del primer nodo de clúster de SAP
• Modificación del perfil SAP de la instancia de ASCS/SCS
• Incorporación de un puerto de sondeo
• Apertura del puerto de sondeo de Firewall de Windows

Creación de un nombre de host virtual para la instancia de ASCS/SCS de SAP en clúster

1. En el Administrador de DNS de Windows, cree una entrada de DNS para el nombre de host virtual de la instancia de ASCS/SCS.

   Importante

   La dirección IP que asigna al nombre de host virtual de la instancia de ASCS/SCS debe ser la misma dirección IP que asignó a Azure Load Balancer ( <SID>-lb-ascs).

   La dirección IP del nombre de host de ASCS/SCS de SAP virtual (pr1-ascs-sap) es la misma dirección IP de Azure Load Balancer (pr1-lb-ascs).

   

   Figura 56: Definición de la entrada DNS del nombre virtual del clúster de ASCS/SCS de SAP y la dirección TCP/IP

2. Para definir la dirección IP asignada al nombre de host virtual, seleccione Administrador de DNS > Dominio.

   

   Figura 57: Nuevo nombre virtual y dirección TCP/IP para la configuración del clúster de ASCS/SCS de SAP

Instalación del primer nodo de clúster de SAP

1. Ejecute la opción de primer nodo del clúster en el nodo de clúster A, por ejemplo, en el host pr1-ascs-0.

2. Para mantener los puertos predeterminados para el equilibrador de carga interno de Azure, seleccione:

   • Sistema ABAP: número de instancia de ASCS 00
   • Sistema Java: número de instancia de SCS 01
   • Sistema ABAP+Java: número de instancia de ASCS 00 y número de instancia de SCS 01

   Para usar números de instancia diferentes de 00 para la instancia de ASCS de ABAP y 01 para la instancia de SCS de Java, primero debe cambiar las reglas predeterminadas de equilibrio de carga del equilibrador de carga interno de Azure, tal como se describe en Cambio de las reglas predeterminadas de equilibrio de carga de ASCS/SCS para el equilibrador de carga interno de Azure.

Luego, realice unos pasos que no se describen en la documentación de instalación usual de SAP.

Modificación del perfil SAP de la instancia de ASCS/SCS

Debe agregar un nuevo parámetro de perfil. El parámetro de perfil evita el cierre de las conexiones entre los procesos de trabajo de SAP y el servidor de puesta en cola cuando lleven inactivas demasiado tiempo. Mencionamos el escenario del problema en Incorporación de entradas del Registro en ambos nodos del clúster usados para la instancia de ASCS/SCS de SAP. En esa sección, también se presentan 2 cambios para algunos parámetros básicos de la conexión TCP/IP. En el segundo paso, es necesario configurar el servidor de puesta en cola para enviar una señal keep_alive de forma que las conexiones no alcancen el umbral de inactividad del equilibrador de carga interno de Azure.

Para modificar el perfil SAP de la instancia de ASCS/SCS, siga estos pasos:

1. Agregue este parámetro de perfil al perfil de la instancia de ASCS/SCS de SAP si usa ENSA1:

   enque/encni/set_so_keepalive = true
   

   En este ejemplo, la ruta de acceso es:

   <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_ASCS00_pr1-ascs-sap

   Por ejemplo, al perfil de la instancia de SCS de SAP y la ruta de acceso correspondiente:

   <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_SCS01_pr1-ascs-sap

   En el caso de ENSA1 y ENSA2, asegúrese de que los parámetros del sistema operativo keepalive se establecen tal y como se describe en la nota de SAP 1410736.

2. Para aplicar los cambios, reinicie la instancia de ASCS/SCS de SAP.

Incorporación de un puerto de sondeo

Use la funcionalidad de sondeo del equilibrador de carga interno para que toda la configuración del clúster funcione con Azure Load Balancer. Habitualmente, el equilibrador de carga interno de Azure distribuye la carga de trabajo entrante de manera equitativa entre las máquinas virtuales que participan. Sin embargo, esto no funcionará en algunas configuraciones de clúster porque solo hay una instancia activa. La otra instancia es pasiva y no puede aceptar nada de la carga de trabajo. Una funcionalidad de sondeo resulta útil cuando el equilibrador de carga interno de Azure asigna trabajo solo a una instancia activa. Con la funcionalidad de sondeo, el equilibrador de carga interno puede detectar cuáles son las instancias activas y, luego, orientarse solo a la instancia con la carga de trabajo.

Para agregar un puerto de sondeo, siga estos pasos:

1. Primero, compruebe la configuración de ProbePort actual con este comando de PowerShell. Ejecútelo dentro de una de las máquinas virtuales de la configuración del clúster.

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPNetworkIPClusterName = "SAP $SAPSID IP"
   Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
   

2. Defina un puerto de sondeo. El número de puerto de sondeo predeterminado es 0. En el ejemplo, se usa el puerto de sondeo 62000.

   

   Figura 58: El puerto de sondeo de configuración de clúster es 0

   El número de puerto está definido en las plantillas de Azure Resource Manager para SAP. Puede asignar el número de puerto en PowerShell.

   Para establecer un nuevo valor de ProbePort del recurso de clúster SAP <SID> IP, ejecute el siguiente script de PowerShell. Actualice las variables de PowerShell de su entorno. Después de ejecutar el script, se le pedirá que reinicie el grupo de clústeres de SAP para activar los cambios.

   $SAPSID = "PR1"      # SAP <SID>
   $ProbePort = 62000   # ProbePort of the Azure Internal Load Balancer
   
   Clear-Host
   $SAPClusterRoleName = "SAP $SAPSID"
   $SAPIPresourceName = "SAP $SAPSID IP"
   $SAPIPResourceClusterParameters =  Get-ClusterResource $SAPIPresourceName | Get-ClusterParameter
   $IPAddress = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Address" }).Value
   $NetworkName = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Network" }).Value
   $SubnetMask = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "SubnetMask" }).Value
   $OverrideAddressMatch = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "OverrideAddressMatch" }).Value
   $EnableDhcp = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "EnableDhcp" }).Value
   $OldProbePort = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "ProbePort" }).Value
   
   $var = Get-ClusterResource | Where-Object {  $_.name -eq $SAPIPresourceName  }
   
   Write-Host "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" -ForegroundColor Cyan
   Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
   
   Write-Host
   Write-Host "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'." -ForegroundColor Cyan
   Write-Host
   Write-Host "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..." -ForegroundColor Cyan
   Write-Host
   
   $var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
   
   Write-Host
   
   $ActivateChanges = Read-Host "Do you want to take restart SAP cluster role '$SAPClusterRoleName', to activate the changes (yes/no)?"
   
   if($ActivateChanges -eq "yes"){
   Write-Host
   Write-Host "Activating changes..." -ForegroundColor Cyan
   
   Write-Host
   write-host "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..." -ForegroundColor Cyan
   Stop-ClusterResource -Name $SAPIPresourceName
   sleep 5
   
   Write-Host "Starting SAP cluster role '$SAPClusterRoleName' ..." -ForegroundColor Cyan
   Start-ClusterGroup -Name $SAPClusterRoleName
   
   Write-Host "New ProbePort parameter is active." -ForegroundColor Green
   Write-Host
   
   Write-Host "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':" -ForegroundColor Cyan
   Write-Host
   Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
   }else
   {
   Write-Host "Changes are not activated."
   }
   

   Después de conectar el rol de clúster SAP <SID> , compruebe que ProbePort esté establecido en el nuevo valor.

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPNetworkIPClusterName = "SAP $SAPSID IP"
   Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
   
   

   

   Figura 59: Sondeo del puerto de clúster después de establecer el valor nuevo

Apertura del puerto de sondeo de Firewall de Windows

Debe abrir el puerto de sondeo de firewall de Windows en ambos nodos del clúster. El siguiente script permite abrir un puerto de sondeo de firewall de Windows. Actualice las variables de PowerShell de su entorno.

$ProbePort = 62000   # ProbePort of the Azure Internal Load Balancer

New-NetFirewallRule -Name AzureProbePort -DisplayName "Rule for Azure Probe Port" -Direction Inbound -Action Allow -Protocol TCP -LocalPort $ProbePort

El valor ProbePort está establecido en 62000. Ahora puede tener acceso al recurso compartido de archivos \\ascsha-clsap\sapmnt desde otros hosts, como ascsha-dbas.

Instalación de la instancia de base de datos

Para instalar la instancia de base de datos, siga el proceso que se describe en la documentación de instalación de SAP.

Instalación del segundo nodo del clúster

Para instalar el segundo clúster, siga los pasos que aparecen en la guía de instalación de SAP.

Cambio del tipo de inicio del servicio de Windows para la instancia de ERS de SAP

Cambie el tipo de inicio del servicio o servicios de Windows de ERS de SAP a Automático (inicio retrasado) en ambos nodos del clúster.

Figura 60: Cambio del tipo de servicio de la instancia de ERS de SAP a automático retrasado

Instalación del servidor de aplicaciones principal de SAP

Instale la instancia del servidor de aplicaciones principal (PAS) <SID>-di-0 en la máquina virtual que designó para hospedar el PAS. No hay ninguna dependencia de Azure ni aspectos específicos de DataKeeper.

Instalación del servidor de aplicaciones adicional de SAP

Instale un servidor de aplicaciones adicional (AAS) de SAP en todas las máquinas virtuales que designó para hospedar una instancia de servidores de aplicaciones de SAP. Por ejemplo, en <SID>-di-1 to <SID>-di-<n>.

Prueba de la conmutación por error de la instancia de ASCS/SCS de SAP y de la replicación de SIOS

Es fácil probar y supervisar la conmutación por error de la instancia de ASCS/SCS de SAP y la replicación de disco de SIOS mediante el uso del Administrador de clústeres de conmutación por error, la interfaz de usuario de SIOS DataKeeper y la herramienta de configuración.

La instancia de ASCS/SCS de SAP se ejecuta en el nodo de clúster A

El grupo de clústeres SAP PR1 se ejecuta en el nodo de clúster A. Por ejemplo, en pr1-ascs-0. Asigne la unidad de disco compartido S, que forma parte del grupo de clústeres SAP PR1 y que la instancia de ASCS/SCS usa, al nodo de clúster A.

Figura 61: Administrador de clústeres de conmutación por error: El grupo de clústeres <SID> de SAP se ejecuta en el nodo del clúster A

En la interfaz de usuario de SIOS DataKeeper y la herramienta de configuración, puede ver que los datos del disco compartido se replican sincrónicamente desde la unidad de volumen de origen S en el nodo de clúster A. Por ejemplo, de pr1-ascs-0 [10.0.0.40] a pr1-ascs-1 [10.0.0.41] .

Figura 62: En SIOS DataKeeper, replique el volumen local desde el nodo de clústeres A al nodo de clústeres B

Conmutación por error del nodo A al nodo B

1. Elija una de estas opciones para iniciar una conmutación por error del grupo de clústeres <SID> de SAP desde el nodo del clúster A al nodo del clúster B:

   • Uso del Administrador de clústeres de conmutación por error
   • Uso de PowerShell del clúster de conmutación por error

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPClusterGroup = "SAP $SAPSID"
   Move-ClusterGroup -Name $SAPClusterGroup
   
   

2. Reinicie el nodo del clúster A dentro del sistema operativo invitado Windows (inicia una conmutación por error automática del grupo de clústeres <SID> de SAP desde el nodo A al nodo B).

3. Reinicie el nodo del clúster A desde Azure Portal (inicia una conmutación por error automática del grupo de clústeres <SID> de SAP desde el nodo A al nodo B).

4. Reinicie el nodo del clúster A con Azure PowerShell (inicia una conmutación por error automática del grupo de clústeres de SAP <SID> desde el nodo A al nodo B).

   Después de la conmutación por error, el grupo de clústeres <SID> de SAP se ejecuta en el nodo del clúster B. Por ejemplo, en pr1-ascs-1.

   

   Figura 63: En el Administrador de clústeres de conmutación por error, el grupo de clústeres <SID> de SAP se ejecuta en el nodo del clúster B

   Ahora, el disco compartido ahora está montado en el nodo del clúster B. SIOS DataKeeper replica datos desde la unidad de volumen de origen S en el nodo del clúster B a la unidad de volumen de destino S en el nodo del clúster A. Por ejemplo, de pr1-ascs-1 [10.0.0.41] a pr1-ascs-0 [10.0.0.40] .

   

   Figura 64: SIOS DataKeeper replica el volumen local desde el nodo del clúster B al nodo del clúster A