Implementación de la plataforma sap BusinessObjects BI en Azure para Windows

En este artículo se describe la estrategia para implementar la plataforma SAP BusinessObjects Business Intelligence (BOBI) en Azure para Windows. En este ejemplo, se configuran dos máquinas virtuales (VM) con discos administrados SSD prémium de Azure como directorio de instalación. Azure SQL Database, una oferta de plataforma como servicio (PaaS), se usa para el servidor de administración central (CMS) y las bases de datos de auditoría. Azure Premium Files, un protocolo SMB, se usa como almacén de archivos compartido en ambas máquinas virtuales. La aplicación web de Java de Tomcat predeterminada y la aplicación de la plataforma de inteligencia empresarial (BI) se instalan juntas en ambas máquinas virtuales. Para equilibrar la carga de las solicitudes de los usuarios, se usa Azure Application Gateway, que tiene capacidades de descarga nativas de TLS/SSL.

Este tipo de arquitectura es eficaz para entornos pequeños de implementación o de no producción. Para una implementación de producción o a gran escala, debe separar los hosts para las aplicaciones web, y puede tener varios hosts de aplicaciones de SAP BOBI que permitan al servidor procesar más información.

Diagrama que muestra una implementación de SAP BOBI en Azure para Windows.

Sistema de archivos Descripción Tamaño (GB) Acceso necesario Almacenamiento
F: El sistema de archivos para la instalación de la instancia de SAP BOBI, la aplicación web de Tomcat predeterminada y los controladores de base de datos (según proceda). Directrices de dimensionamiento de SAP Privilegios administrativos locales Discos SSD Premium administrados de Azure
\\azusbobi.file.core.windows.net\frsinput El directorio de montaje es para los archivos compartidos en todos los hosts de SAP BOBI que se usan como directorio de almacén de archivos de entrada. Necesidad empresarial Privilegios administrativos locales Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput El directorio de montaje es para los archivos compartidos en todos los hosts de SAP BOBI que se usan como directorio de almacén de archivos de salida. Necesidad empresarial Privilegios administrativos locales Azure NetApp Files

Prerrequisitos

  • Una suscripción de Azure con permisos para crear recursos como máquinas virtuales, cuentas de almacenamiento, instancias de SQL Database y redes virtuales.
  • Completó el ajuste de tamaño de la plataforma SAP BOBI en función de la guía de planeación e implementación de SAP BOBI en Azure.
  • Medios de instalación de la plataforma sap BusinessObjects BI (versión 4.3 SP01 Patch 1 o posterior). Para obtener una clave de licencia temporal, consulte La nota de SAP 1288121.
  • Un controlador ODBC de Microsoft compatible con Azure SQL Database. En este artículo se usa la versión 13.1.
  • Windows Server 2019 o una versión de sistema operativo compatible según la matriz de disponibilidad de productos de SAP.
  • Acceso de red saliente en el puerto 1433 desde servidores de aplicaciones de SAP BOBI a Azure SQL Database.
  • Acceso de red saliente en el puerto 445 desde los servidores de aplicaciones de SAP BOBI si usa Azure Premium Files (SMB).

Implementación de una máquina virtual Windows mediante Azure Portal

En esta sección, creará dos máquinas virtuales con una imagen del sistema operativo Windows para la plataforma SAP BOBI. A continuación, se indican los pasos de nivel superior para crear máquinas virtuales:

  1. Cree un grupo de recursos.

  2. Cree una red virtual:

    • No use una única subred para todos los servicios de Azure en la implementación de la plataforma SAP BI. En función de la arquitectura de la plataforma sap BI, es posible que tenga que crear varias subredes. En esta implementación, creará dos subredes: una subred de aplicación de BI y una subred de Application Gateway.
    • Siga la nota de SAP 2276646 para identificar los puertos para la comunicación de la plataforma SAP BOBI entre distintos componentes.
    • SQL Database se comunica a través del puerto 1433. Se debe permitir el tráfico saliente a través del puerto 1433 desde los servidores de aplicación de SAP BOBI.
    • En Azure, Application Gateway debe estar en una subred independiente. Para más información, consulte Introducción a la configuración de Application Gateway.
    • Si usa Azure NetApp Files para un almacén de archivos en lugar de Azure Files, cree una subred independiente para Azure NetApp Files. Para más información, vea Directrices para el planeamiento de red de Azure NetApp Files.

  3. Seleccione las opciones de disponibilidad adecuadas en función de la configuración del sistema preferida dentro de una región de Azure, si:

    • Implica la expansión entre zonas
    • Reside dentro de una sola zona
    • Funciona en una región sin zona

  4. Creación de la máquina virtual 1 (azuswinboap1):

  5. Crear VM 2 (azuswinboap2).

  6. Agregue un SSD Premium. Se usa como directorio de instalación de SAP BOBI.

Provisionamiento de Archivos Premium de Azure

Antes de continuar con la configuración de Azure Files, familiarícese con la documentación correspondiente.

Azure Files ofrece recursos compartidos de archivos estándar que se hospedan en hardware basado en HDD, y recursos compartidos de archivos prémium que se hospedan en hardware basado en SSD. Para un almacenamiento de archivos SAP BusinessObjects, use Azure Premium Files.

Los recursos compartidos de Azure Premium Files están disponibles con redundancia local y de zona en un subconjunto de regiones. Para averiguar si los recursos compartidos de archivos Premium están disponibles actualmente en su región, consulte Productos disponibles por región. Para información sobre las regiones que admiten el almacenamiento con redundancia de zona (ZRS), consulte Redundancia de Azure Storage.

Implementación de una cuenta de almacenamiento de Azure Files y recursos compartidos NFS

Los recursos compartidos de archivos de Azure se implementan en cuentas de almacenamiento, que son objetos de nivel superior que representan un grupo compartido de almacenamiento. Este grupo de almacenamiento se puede usar para implementar varios recursos compartidos de archivos. Azure admite varios tipos de cuentas de almacenamiento para los distintos escenarios de almacenamiento que los clientes pueden tener. Para el almacenamiento de archivos de SAP BusinessObjects, debe crear una cuenta de FileStorage. Se usa para implementar recursos compartidos de archivos de Azure en hardware basado en SSD prémium.

Nota

Las cuentas de FileStorage solo se pueden usar para almacenar recursos compartidos de archivos de Azure. No se puede implementar ningún otro recurso de almacenamiento, como blobs, contenedores, colas o tablas, en una cuenta de FileStorage.

Se accede a la cuenta de almacenamiento a través de un punto de conexión privado y se implementa en la misma red virtual de una plataforma SAP BOBI. Con esta configuración, el tráfico del sistema SAP nunca sobrepasa los límites de seguridad de la red virtual. A menudo, los sistemas SAP contienen datos confidenciales y críticos para la empresa, por lo que permanecer dentro de los límites de la red virtual es una consideración de seguridad importante para muchos clientes.

Si necesita acceder a la cuenta de almacenamiento desde otra red virtual, puede usar el emparejamiento de red virtual de Azure.

Cuenta de almacenamiento de Azure Files

  1. Para crear una cuenta de almacenamiento mediante el portal de Azure, seleccione Crear un recurso>Almacenamiento>Cuenta de almacenamiento.

  2. En la pestaña Aspectos básicos, complete todos los campos obligatorios para crear una cuenta de almacenamiento:

    1. Seleccione Suscripción>Grupo de recursos>Región.

    2. Escriba el nombre de la cuenta de almacenamiento. Por ejemplo, escriba azusbobi. Este nombre debe ser único globalmente, pero, por lo demás, puede ser cualquier nombre que quiera.

    3. Seleccione Prémium como nivel de rendimiento y FileStorage como el tipo de cuenta.

    4. En la etiqueta Replicación, elija un nivel de redundancia, seleccione Almacenamiento con redundancia local (LRS).

      Para FileStorage Premium, ZRS y LRS son las únicas opciones disponibles. En función de la estrategia de implementación de máquinas virtuales (conjunto de escalado flexible, zona de disponibilidad o conjunto de disponibilidad), elija el nivel de redundancia adecuado. Para más información, vea Redundancia de Azure Storage.

    5. Seleccione Siguiente.

  3. En la pestaña Redes, seleccione Punto de conexión privado para el método de conectividad. Para más información, vea Consideraciones de redes para Azure Files.

    1. Seleccione Agregar en la sección de puntos de conexión privados.

    2. Seleccione Suscripción>Grupo de recursos>Ubicación.

    3. Escriba el Nombre del punto de conexión privado. Por ejemplo, escriba azusbobi-pe.

    4. Seleccione Archivo en Subrecurso de almacenamiento.

    5. En la sección Redes, seleccione la Red virtual y la Subred donde se ha implementado la aplicación SAP BusinessObjects BI.

    6. Acepte el valor predeterminado (sí) para Integrar con la zona DNS privada.

    7. Seleccione la Zona DNS privada en la lista desplegable.

    8. Seleccione Aceptar para volver a la pestaña Redes en Crear cuenta de almacenamiento.

  4. En la pestaña Protección de datos, configure la directiva de eliminación temporal para recursos compartidos de archivos de Azure en la cuenta de almacenamiento. De manera predeterminada, la funcionalidad de eliminación temporal está desactivada. Para más información sobre la eliminación temporal, consulte Evitar la eliminación accidental de recursos compartidos de archivos de Azure.

  5. En la pestaña Avanzadas, seleccione las distintas opciones de seguridad.

    El campo Se requiere transferencia segura indica si la cuenta de almacenamiento requiere cifrado en tránsito para la comunicación con la cuenta de almacenamiento. Si requiere compatibilidad con SMB 2.1, tiene que deshabilitar este campo. Para la plataforma SAP BOBI, conserve el valor predeterminado (habilitado) .

  6. Continúe y cree la cuenta de almacenamiento.

Para más información sobre cómo crear una cuenta de almacenamiento, consulte Creación de una cuenta de almacenamiento de FileStorage.

Crear recursos compartidos de archivos de Azure

El siguiente paso es crear recursos compartidos de archivos de Azure en la cuenta de almacenamiento. Los recursos compartidos de archivos de Azure usan un modelo aprovisionado para recursos compartidos de archivos Premium. En un modelo de negocio aprovisionado, especifique proactivamente en el servicio Azure Files cuáles son los requisitos de almacenamiento, en lugar de facturarse en función de lo que use. Para comprender mejor este modelo, consulte Modelo aprovisionado. En este ejemplo, creará dos recursos compartidos de archivos de Azure: frsinput (256 GB) y frsoutput (256 GB) para el almacén de archivos DE SAP BOBI.

  1. Vaya a la cuenta de almacenamiento azusbobi a >Archivos compartidos.
  2. Seleccione Nuevo recurso compartido de archivos.
  3. Escriba el Nombre del recurso compartido de archivos. Por ejemplo, escriba frsinput o frsoutput.
  4. Escriba el tamaño necesario del recurso compartido de archivos en Capacidad aprovisionada. Por ejemplo, escriba 256 GB.
  5. Seleccione SMB como Protocolo.
  6. Seleccione Crear.

Configuración de un disco de datos en una máquina virtual Windows

En los pasos de esta sección se usan los siguientes prefijos:

[A] : El paso se aplica a todos los hosts.

Inicio de un nuevo disco de datos

La aplicación SAP BusinessObjects BI requiere una partición en la que se puedan instalar sus archivos binarios. Puede instalar una aplicación SAP BOBI en la partición del sistema operativo (C:), pero debe asegurarse de tener suficiente espacio para la implementación y el sistema operativo. Se recomienda tener al menos 2 GB disponibles para archivos temporales y aplicaciones web. Además, se recomienda separar los archivos binarios de instalación de SAP BOBI en particiones independientes.

En este ejemplo, una aplicación SAP BOBI se instala en una partición independiente (F:). Inicialice el SSD Premium que adjuntó durante el aprovisionamiento de la máquina virtual:

  1. [A] Si no hay ningún disco de datos conectado a la máquina virtual (azuswinboap1 y azuswinboap2), siga los pasos descritos en Agregar un disco de datos para conectar un nuevo disco de datos administrado.
  2. [A] Después de conectar el disco administrado a la máquina virtual, inicialice el disco siguiendo los pasos descritos en Inicialización de un nuevo disco de datos.

Montaje de Azure Premium Files

Para usar Azure Files como almacén de archivos, debe montarlo, lo que significa asignarle una letra de unidad o una ruta de acceso a un punto de montaje.

[A] Para montar un recurso compartido de archivos de Azure, siga los pasos de Montaje del recurso compartido de archivos de Azure.

Para montar un recurso compartido de archivos de Azure en un servidor Windows, el protocolo SMB requiere que el puerto TCP 445 esté abierto. Se produce un error en las conexiones si el puerto 445 está bloqueado. Puede comprobar si el firewall o el ISP bloquean el puerto 445 mediante el Test-NetConnection cmdlet . Consulte Puerto 445 bloqueado.

Configuración de la base de datos CMS: Azure SQL

En esta sección se proporcionan detalles sobre cómo aprovisionar Azure SQL mediante Azure Portal. También se proporcionan instrucciones sobre cómo crear las bases de datos CMS y de auditoría para la plataforma SAP BOBI y una cuenta de usuario para acceder a la base de datos.

Las instrucciones solo se aplican si usa SQL Database. En el caso de otras bases de datos, vea la documentación específica de SAP o de la base de datos para obtener instrucciones.

Creación de un servidor de SQL Database

SQL Database ofrece diferentes opciones de implementación: base de datos única, grupo elástico y servidor de bases de datos. Para una plataforma SAP BOBI, necesita dos bases de datos, CMS y auditoría. En lugar de crear dos bases de datos únicas, puede crear un servidor de SQL Database que pueda administrar el grupo de bases de datos únicas y los grupos elásticos. Siga estos pasos para crear un servidor de SQL Database:

  1. Vaya a la página Seleccione una opción de implementación de SQL.

  2. En Bases de datos SQL, cambie Tipo de recurso a Servidor de bases de datos. Seleccione Crear.

  3. En la pestaña Aspectos básicos , complete todos los campos necesarios para crear SQL Database Server:

    1. En Detalles del proyecto, seleccione la Suscripción y Grupo de recursos.

    2. Escriba el Nombre de servidor. Por ejemplo, escriba azussqlbodb. El nombre del servidor debe ser único globalmente, pero, por lo demás, puede ser cualquier nombre que quiera.

    3. Seleccione la Ubicación.

    4. Escriba el Inicio de sesión del administrador del servidor. Por ejemplo, escriba boadmin. A continuación, escriba una Contraseña.

  4. En la pestaña Redes, cambie Permitir que los servicios y recursos de Azure accedan a este servidora No en Reglas de firewall.

  5. En Configuración adicional, mantenga la configuración predeterminada.

  6. Continúe y cree el servidor de bases de datos SQL.

En el paso siguiente, cree el CMS y las bases de datos de auditoría en el servidor de SQL Database (azussqlbodb.database.windows.net).

Creación de las bases de datos CMS y de auditoría

Después de aprovisionar el servidor de base de datos SQL, vaya al recurso azussqlbodb. A continuación, siga estos pasos para crear las bases de datos CMS y de auditoría.

  1. En la página de información general de azussqlbodb, seleccione Crear base de datos.

  2. En la pestaña Aspectos básicos, complete todos los campos obligatorios :

    1. Escriba el Nombre de la base de datos. Por ejemplo, escriba bocms o boaudit.

    2. En la opción Proceso y almacenamiento, seleccione Configurar base de datos. Elija el modelo adecuado en función del resultado de dimensionamiento. Para información sobre las opciones, vea Modelos de ajuste de tamaño para Azure SQL Database.

  3. En la pestaña Redes, seleccione Punto de conexión privado para el método de conectividad. El punto de conexión privado se usa para acceder a SQL Database dentro de la red virtual configurada.

    1. Seleccione Agregar punto de conexión privado.

    2. Seleccione Suscripción>Grupo de recursos>Ubicación.

    3. Escriba el Nombre del punto de conexión privado. Por ejemplo, escriba azusbodb-pe.

    4. En Subrecurso de destino, seleccione SqlServer.

    5. En la sección Redes, seleccione la Red virtual y la Subred donde se ha implementado la aplicación SAP BusinessObjects BI.

    6. Acepte el valor predeterminado (sí) para Integrar con la zona DNS privada.

    7. Seleccione la Zona DNS privada en la lista desplegable.

    8. Seleccione Aceptar para volver a la pestaña Redes en Crear base de datos SQL.

  4. En la pestaña Configuración adicional, cambie la configuración de Intercalación a SQL_Latin1_General_CP850_BIN2.

  5. Continúe y cree la base de datos CMS.

De forma similar, puede crear la base de datos de auditoría. Por ejemplo, escriba boaudit.

Descarga e instalación de un controlador ODBC

Los servidores de aplicaciones de SAP BOBI requieren que el cliente o controladores de la base de datos accedan a la base de datos CMS o de auditoría. El controlador ODBC de Microsoft se usa para acceder a las bases de datos CMS y de auditoría que se ejecutan en SQL Database. En esta sección se proporcionan instrucciones sobre cómo descargar y configurar un controlador ODBC en Windows.

  1. Vea la sección Compatibilidad del repositorio CMS + auditoría por SO en Matriz de disponibilidad de productos (PAM) para la plataforma SAP BusinessObjects BI para averiguar los conectores de base de datos que son compatibles con SQL Database.
  2. Descargue el controlador ODBC. En este ejemplo, en este artículo se usa el controlador ODBC 13.1.
  3. Instale el controlador ODBC en todos los servidores de inteligencia empresarial (azuswinboap1 y azuswinboap2).
  4. Después de instalar el controlador en azuswinboap1, vaya a Inicio>Herramientas administrativas de Windows>Orígenes de datos ODBC (64 bits) .
  5. Vaya a la pestaña Sistema DSN.
  6. Seleccione Agregar para crear una conexión a la base de datos CMS.
  7. Seleccione Controlador ODBC 13 para SQL Server y seleccione Finalizar.
  8. Escriba la información de la base de datos CMS como se muestra a continuación y seleccione Siguiente:
    • Nombre: el nombre de la base de datos creada en la sección "Crear el CMS y la base de datos de auditoría". Por ejemplo, escriba bocms o boaudit.
    • Descripción: la descripción que describe el origen de datos. Por ejemplo, escriba Base de datos CMS o Base de datos de auditoría.
    • Servidor: el nombre del servidor creado en la sección "Crear un servidor de SQL Database". Por ejemplo, escriba azussqlbodb.database.windows.net.
  9. Seleccione With SQL Server authentication using a login ID and password entered by user (Con la autenticación de SQL Server mediante un id. de inicio de sesión y una contraseña escritos por el usuario) para comprobar la autenticidad en Azure SQL Server. Escriba la credencial de usuario que se creó en el momento de la creación del servidor de SQL Database. Por ejemplo, escriba boadmin. Seleccione Siguiente.
  10. Cambie la base de datos predeterminada a bocmsy mantenga todo lo demás como predeterminado. Seleccione Siguiente.
  11. Seleccione la casilla Usar cifrado de alta seguridad para los datos y mantenga todo lo demás con los valores predeterminados. Seleccione Finalizar.
  12. Se crea el origen de datos en la base de datos CMS. Ahora puede seleccionar Fuente de datos de prueba para validar la conexión a la base de datos CMS desde la aplicación de BI. Debería completarse con éxito. Si se produce un error, solucione el problema de conectividad.

Nota

SQL Database se comunica a través del puerto 1433. Se debe permitir el tráfico saliente a través del puerto 1433 desde los servidores de aplicación de SAP BOBI.

Repita los mismos pasos anteriores para crear una conexión para la base de datos de auditoría en el servidor azuswinboap1. De forma similar, instale y configure los orígenes de datos ODBC (bocms y boaudit) en todos los servidores de aplicaciones de BI (azuswinboap2).

Preparación del servidor

Siga la guía más reciente de SAP para preparar los servidores para la instalación de la plataforma BI. Para obtener la información más actualizada, consulte la sección "Preparación" del Manual de instalación de la plataforma SAP Business Intelligence para Windows.

Instalación de la plataforma de BI en un host de Windows

Para instalar la plataforma de BI en un host de Windows, inicie sesión con un usuario que tenga privilegios administrativos locales.

Vaya a los medios de la plataforma de SAP BusinessObjects BI y ejecute setup.exe.

Siga las instrucciones del Manual de instalación de la plataforma SAP Business Intelligence para Windows que son específicas de su versión. Estos son algunos puntos a tener en cuenta al instalar la plataforma SAP BOBI en Windows:

  • En la pantalla Configure Destination Folder (Configurar carpeta de destino), proporcione la carpeta de destino donde quiere instalar la plataforma BI. Por ejemplo, especifique F:\SAP BusinessObjects*.

  • En la pantalla Configure Product Registration (Configurar el registro del producto), puede usar una clave de licencia temporal para las soluciones de SAP BusinessObjects de la nota de SAP 1288121, o puede generar una clave de licencia en el marketplace de servicios de SAP.

  • En la pantalla Select Install Type (Seleccionar tipo de instalación), seleccione la instalación Completa en el primer servidor (azuswinboap1). Para el otro servidor (azuswinboap2), seleccione Custom / Expand (Personalizar/Expandir), que expande la configuración de SAP BOBI existente.

  • En Select Default or Existing Database (Seleccionar base de datos predeterminada o existente), seleccione Configure an existing database (Configurar una base de datos existente), que le solicitará que seleccione la base de datos CMS y de auditoría. Seleccione Microsoft SQL Server using ODBC (Microsoft SQL Server con ODBC) para el tipo CMS Database (Base de datos CMS) y el tipo Audit Database (Base de datos de auditoría).

    También puede seleccionar No auditing database (Ninguna base de datos de auditoría) si no quiere configurar la auditoría durante la instalación.

  • Seleccione las opciones adecuadas en la pantalla Select Java Web Application Server (Seleccionar servidor de aplicaciones web de Java) según la arquitectura de SAP BOBI. En este ejemplo, se selecciona la opción 1, que instala un servidor tomcat en la misma plataforma sap BOBI.

  • Escriba la información de la base de datos CMS en Configure CMS Repository Database - SQL Server (ODBC) (Configurar la base de datos del repositorio de CMS: SQL Server [ODBC]). En la imagen siguiente se muestra una entrada de ejemplo para la información de la base de datos CMS para una instalación de Windows.

    Captura de pantalla que muestra la información de la base de datos CMS para Windows.

  • (Opcional) Escriba la información de la base de datos de auditoría en Configure Auditing Database - SQL Server (ODBC) (Configurar la base de datos de auditoría: SQL Server [ODBC]). En la imagen siguiente se muestra una entrada de ejemplo para la información de la base de datos de auditoría para una instalación de Windows.

    Captura de pantalla que muestra la información de la base de datos de auditoría para Windows.

  • Complete la instalación siguiendo las instrucciones y escriba las entradas necesarias.

Para una implementación de varias instancias, ejecute la configuración de la instalación en el segundo host (azuswinboap2). En la pantalla Select Install Type (Seleccionar tipo de instalación), seleccione Custom / Expand (Personalizar/Expandir), que expande la configuración de SAP BOBI existente. Para más información, vea el blog de SAP Configuración de la plataforma SAP BusinessObjects Business Intelligence con Azure SQL Database.

Importante

Los números de versión del motor de base de datos para SQL Server y SQL Database no son comparables entre sí. Son números de versión internos para estos productos distintos. El motor de base de datos de SQL Database se basa en el mismo código base que el de SQL Server. Lo más importante es que el motor de base de datos de SQL Database siempre tiene los bits más recientes del motor de SQL Database. La versión 12 de SQL Database es más reciente que la versión 15 de SQL Server.

Para averiguar la versión actual de SQL Database, puede comprobar la configuración de la Consola de administración central (CMC), o puede ejecutar la consulta siguiente mediante sqlcmd o SQL Server Management Studio (SSMS). La alineación de las versiones de SQL con la compatibilidad predeterminada se puede encontrar en el artículo sobre el nivel de compatibilidad de bases de datos.

Captura de pantalla que muestra la información de la base de datos en CMC. 

1> select @@version as version;
2> go
version
------------------------------------------------------------------------------------------
Microsoft SQL Azure (RTM) - 12.0.2000.8
        Feb 20 2021 17:51:58
        Copyright (C) 2019 Microsoft Corporation

(1 rows affected)

1> select name, compatibility_level from sys.databases;
2> go
name                                                                  compatibility_level
--------------------------------------------------------------------- -------------------
master                                                                                150
bocms                                                                                 150
boaudit                                                                               150

(3 rows affected)

Después de la instalación

Después de la instalación de varias instancias de la plataforma SAP BOBI, deben seguirse algunos pasos adicionales posteriores a la configuración para admitir la alta disponibilidad de la aplicación.

Configuración de un nombre de clúster

En la implementación de varias instancias de la plataforma de SAP BOBI, se quiere ejecutar varios servidores CMS juntos en un clúster. Un clúster consta de dos o más servidores CMS que funcionan conjuntamente en una base de datos común del sistema CMS. Si un nodo que se ejecuta en CMS falla, un nodo con otro CMS continúa atendiendo las solicitudes de la plataforma de BI. De manera predeterminada, en una plataforma de SAP BOBI, un nombre de clúster refleja el nombre de host del primer CMS que instale.

Para configurar el nombre del clúster en Windows, siga las instrucciones de la Guía del administrador de la plataforma de SAP Business Intelligence. Después de configurar el nombre del clúster, siga la nota de SAP 1660440 para establecer la entrada predeterminada del sistema en la página de inicio de sesión de Launchpad para CMC o BI.

Configuración de la ubicación del almacén de archivos de entrada y salida en Azure Premium Files

El almacén de archivos hace referencia a los directorios de disco en los que se encuentran los archivos reales de SAP BusinessObjects BI. La ubicación predeterminada del servidor de repositorios de archivos para la plataforma SAP BOBI se encuentra en el directorio de instalación local. En una implementación de varias instancias, es importante configurar el almacén de archivos en un almacenamiento compartido, como Azure Premium Files o Azure NetApp Files, para que se pueda acceder a él desde todos los servidores de capa de almacenamiento.

  1. Si no se crea, siga las instrucciones proporcionadas en la sección anterior, "Aprovisionamiento de Azure Premium Files" para crear y montar Azure Premium Files.

    Sugerencia

    En función de si la máquina virtual se implementa de forma zonal o regional, se debe determinar la selección de redundancia de almacenamiento para Azure Premium Files (ZRS o LRS).

  2. Siga la nota de SAP 2512660 para cambiar la ruta de acceso del repositorio de archivos (entrada y salida).

Clúster de Tomcat: replicación de sesión

Tomcat admite la agrupación en clústeres de dos o más servidores de aplicaciones para la replicación de sesión y la conmutación por error. Si las sesiones de la plataforma de SAP BOBI están serializadas, una sesión de usuario puede cambiar de forma transparente a otra instancia de Tomcat, incluso cuando un servidor de aplicaciones falla. Por ejemplo, un usuario puede estar conectado a un servidor web en el que se produce un error mientras el usuario navega por una jerarquía de carpetas en una aplicación de SAP BI. En un clúster configurado correctamente, el usuario puede seguir navegando por la jerarquía de carpetas sin que se le redirija a la página de inicio de sesión.

En la nota de SAP 2808640, se proporcionan los pasos para configurar la agrupación en clústeres de Tomcat mediante multidifusión. Sin embargo, en Azure no se admite la multidifusión. Para que el clúster de Tomcat funcione en Azure, debe usar StaticMembershipInterceptor (nota de SAP 2764907).

Para configurar un clúster de Tomcat en Azure, vea Agrupación en clústeres de Tomcat mediante pertenencia estática para la plataforma de SAP BusinessObjects BI en el blog de SAP.

Equilibrio de la carga de un nivel web de una plataforma de SAP BI

En una implementación de varias instancias de SAP BOBI, los servidores de aplicaciones web de Java (nivel web) se ejecutan en dos o más hosts. Para distribuir la carga de usuarios uniformemente entre los servidores web, puede usar un equilibrador de carga entre los usuarios finales y los servidores web. Puede usar Azure Load Balancer o Azure Application Gateway para administrar el tráfico a los servidores de aplicaciones web. Las ofertas se explican en las siguientes secciones:

  • Load Balancer es un equilibrador de carga de nivel 4 (TCP, UDP) de alto rendimiento y baja latencia que distribuye el tráfico entre máquinas virtuales correctas. Un sondeo de estado de equilibrador de carga supervisa un puerto determinado en cada máquina virtual y solo distribuye tráfico a las máquinas virtuales operativas. Puede elegir un equilibrador de carga público o un equilibrador de carga interno, en función de si quiere que la plataforma SAP BI sea accesible desde Internet o no. Es redundante entre zonas, lo que garantiza una alta disponibilidad entre zonas de disponibilidad.

    En la ilustración siguiente, consulte la sección "Equilibrador de carga interno" donde el servidor de aplicaciones web se ejecuta en el puerto 8080. Este puerto es el puerto HTTP predeterminado de Tomcat que supervisa un sondeo de estado. Cualquier solicitud entrante de los usuarios se redirige a los servidores de aplicaciones web (azuswinboap1 o azuswinboap2) en el grupo de servidores posterior. Load Balancer no admite la terminación TLS/SSL, que también se conoce como descarga TLS/SSL. Si usa Load Balancer para distribuir el tráfico entre servidores web, se recomienda usar Standard Load Balancer.

    Nota

    Cuando las máquinas virtuales sin direcciones IP públicas se colocan en el grupo de back-end de un Load Balancer Estándar interno (sin dirección IP pública), no hay conectividad saliente a Internet, a menos que se realice una configuración adicional para permitir el enrutamiento a puntos de conexión públicos. Para obtener información sobre cómo lograr la conectividad saliente, consulte Conectividad de punto de conexión público para máquinas virtuales mediante Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.

    Captura de pantalla que muestra una instancia de Load Balancer que se usa para equilibrar el tráfico entre servidores web.

  • Application Gateway proporciona un controlador de entrega de aplicaciones como servicio, que se usa para ayudar a las aplicaciones a dirigir el tráfico de usuario a uno o varios servidores de aplicaciones web. Ofrece diversas funcionalidades de equilibrio de carga de capa 7, como la descarga TLS/SSL, firewall de aplicaciones web y afinidad de sesión basada en cookies para tus aplicaciones.

    En una plataforma de SAP BI, Application Gateway dirige el tráfico web de la aplicación a los recursos especificados en un grupo de back-end. En este caso, es azuswinboap1 o azuswinboap2. Se asigna una escucha al puerto, se crean reglas y se agregan recursos a un grupo de back-end. En la figura siguiente, Application Gateway con una dirección IP (10.31.3.25) de front-end privada actúa como punto de entrada para los usuarios, controla las conexiones entrantes de TLS/SSL (HTTPS: TCP/443), descifra TLS/SSL y pasa la solicitud (HTTP: TCP/8080) a los servidores del grupo de back-end. Con la característica de terminación TLS/SSL integrada, es necesario mantener solo un certificado TLS/SSL en la puerta de enlace de aplicación, lo que simplifica las operaciones.

    Captura de pantalla que muestra una instancia de Application Gateway que se usa para equilibrar el tráfico entre servidores web.

    Para configurar Application Gateway para un servidor web de SAP BOBI, consulte Equilibrio de carga para servidores web de SAP BOBI mediante Application Gateway en el blog de SAP.

    Nota

    Se recomienda usar Application Gateway para equilibrar la carga del tráfico en el servidor web, ya que proporciona características como la descarga SSL, la centralización de la administración de SSL para reducir la sobrecarga de cifrado y descifrado en el servidor, el algoritmo Round-Robin para distribuir el tráfico, las capacidades de Web Application Firewall y la alta disponibilidad.

Confiabilidad de la plataforma de SAP BusinessObjects BI en Azure

La plataforma de SAP BusinessObjects BI incluye diferentes niveles, que están optimizados para operaciones y tareas específicas. Cuando un componente de cualquier nivel deja de estar disponible, la aplicación SAP BOBI deja de estar accesible o no funciona ninguna funcionalidad de la aplicación. Debe asegurarse de que cada nivel esté diseñado para ser confiable y mantener la aplicación operativa sin interrupción empresarial.

Esta sección se centra en cómo las características nativas de Azure se combinan con una configuración de la plataforma SAP BOBI para mejorar la disponibilidad de una implementación de SAP. En esta sección se describen las siguientes opciones para la confiabilidad de la plataforma SAP BOBI en Azure:

  • Copia de seguridad y restauración: este proceso crea copias periódicas de datos y aplicaciones en ubicaciones independientes. Si los datos o aplicaciones originales se pierden o se dañan, las copias se pueden usar para restaurar o recuperar el estado anterior.
  • Alta disponibilidad: una plataforma de alta disponibilidad tiene al menos dos de todo en la región de Azure para mantener la aplicación operativa si uno de los servidores deja de estar disponible.
  • Recuperación ante desastres (DR) : este proceso restaura la funcionalidad de la aplicación si hay pérdidas catastróficas. Por ejemplo, toda una región de Azure podría dejar de estar disponible debido a un desastre natural.

La implementación de esta solución varía en función de la naturaleza de la configuración del sistema en Azure. Debe adaptar las soluciones de copia de seguridad y restauración, alta disponibilidad y recuperación ante desastres en función de sus requisitos empresariales.

Copia de seguridad y restauración

El proceso de copia de seguridad y restauración crea copias periódicas de datos y aplicaciones en una ubicación independiente. Se pueden restaurar o recuperar en un estado anterior si los datos o aplicaciones originales se pierden o dañan. También es un componente esencial de cualquier estrategia empresarial de recuperación ante desastres. Estas copias de seguridad permiten la restauración de aplicaciones y bases de datos a un momento dado dentro del período de retención configurado.

Para desarrollar una estrategia completa de copia de seguridad y restauración para la plataforma de SAP BOBI, identifique los componentes que provocan el tiempo de inactividad del sistema o la interrupción de la aplicación. En una plataforma de SAP BOBI, la copia de seguridad de los componentes siguientes es fundamental para proteger la aplicación:

  • Directorio de instalación de SAP BOBI (Discos Premium Administrados)
  • Almacén de archivos (Azure Premium Files o Azure NetApp Files para una instalación distribuida)
  • Base de datos de auditoría y CMS (SQL Database, Azure Database for MySQL o una base de datos en máquinas virtuales de Azure)

En la siguiente sección se describe cómo implementar una estrategia de copia de seguridad y restauración para cada componente en una plataforma de SAP BOBI.

Copia de seguridad y restauración para un directorio de instalación de SAP BOBI

En Azure, la manera más sencilla de realizar copias de seguridad de las máquinas virtuales y de todos los discos conectados es mediante Azure Backup. Proporciona una copia de seguridad independiente y aislada para impedir la destrucción accidental de los datos en las VM. Las copias de seguridad se almacenan en un almacén de Recovery Services con administración integrada de puntos de recuperación. La configuración y el escalado son sencillos. Las copias de seguridad están optimizadas y puede restaurarlas fácilmente cuando sea necesario.

Como parte del proceso de copia de seguridad, se toma una instantánea. Los datos se transfieren al almacén de Recovery Services sin afectar a las cargas de trabajo de producción. La instantánea proporciona un nivel diferente de coherencia, como se describe en Coherencia de instantáneas. Backup también ofrece compatibilidad en paralelo con la copia de seguridad de los discos administrados mediante Azure Disk Backup, además de una solución de copia de seguridad de VM de Azure. Resulta útil cuando necesita copias de seguridad coherentes de las máquinas virtuales una vez al día y copias de seguridad más frecuentes, que sean coherentes ante fallos, de los discos del sistema operativo o de un disco de datos específico. Para obtener más información, consulte Acerca de la copia de seguridad de VM de Azure, Azure Disk Backup y Preguntas más frecuentes sobre la copia de seguridad de VM de Azure.

Copia de seguridad y restauración del almacén de archivos

En función de la implementación, el almacén de archivos de la plataforma de SAP BOBI puede estar en Azure NetApp Files o Azure Files. Elija entre las siguientes opciones de copia de seguridad y restauración en función del almacenamiento que use para el almacén de archivos:

Si crea un servidor NFS independiente, asegúrese de implementar la estrategia de copia de seguridad y restauración para él.

Copia de seguridad y restauración de la base de datos CMS y de auditoría

Para una plataforma SAP BOBI que se ejecuta en máquinas virtuales Windows, la base de datos CMS y auditoría se puede ejecutar en cualquiera de las bases de datos admitidas. Para más información, consulte la matriz de compatibilidad en la guía de implementación y planeamiento de la plataforma SAP BOBI en Azure. Por lo tanto, es importante que adopte la estrategia de copia de seguridad y restauración en función de la base de datos usada para el almacenamiento de datos CMS y de auditoría.

  • SQL Database emplea tecnología de SQL Server para crear copias de seguridad completas cada semana, copias de seguridad diferenciales cada 12 a 24 horas y copias de seguridad del registro de transacciones cada 5 a 10 minutos. La frecuencia de las copias de seguridad del registro de transacciones se basa en el tamaño de proceso y en la cantidad de actividad de la base de datos.

    Los usuarios pueden elegir una opción para configurar la redundancia del almacenamiento de copia de seguridad entre los blobs LRS, ZRS o GRS. Los mecanismos de redundancia de almacenamiento almacenan varias copias de los datos para protegerlos de eventos planeados y no planeados, que incluyen errores transitorios del hardware, interrupciones del suministro eléctrico o cortes de la red, y desastres naturales masivos. De forma predeterminada, SQL Database almacena la copia de seguridad en blobs GRS que se replican en una región emparejada. Se puede cambiar en función del requisito empresarial a blobs LRS o ZRS. Para obtener información más actualizada sobre la programación, la retención y el consumo de almacenamiento de copias de seguridad de SQL Database, consulte Copias de seguridad automatizadas: Azure SQL Database y Azure SQL Managed Instance.

  • Azure Database for MySQL crea automáticamente copias de seguridad del servidor y las almacena en LRS o GRS configurado por el usuario. Azure Database for MySQL hace copias de seguridad de los archivos de datos y del registro de transacciones. En función del tamaño de almacenamiento máximo admitido, se realizan copias de seguridad completas y diferenciales (servidores de almacenamiento de hasta 4 TB) o copias de seguridad de instantáneas (servidores de almacenamiento de hasta 16 TB). Estas copias de seguridad permiten restaurar un servidor a un momento dado dentro del período de retención de copias de seguridad configurado. El período de retención de copia de seguridad predeterminado es de siete días, que opcionalmente puede configurar hasta 35 días. Todas las copias de seguridad se cifran mediante cifrado AES de 256 bits. Estos archivos de copia de seguridad no están expuestos al usuario y no se pueden exportar. Estas copias de seguridad solo se pueden usar en operaciones de restauración de Azure Database for MySQL. Puede usar mysqldump para copiar una base de datos. Para más información, consulte Copia de seguridad y restauración en Azure Database for MySQL.

  • En el caso de una base de datos instalada en una máquina virtual de Azure, puede usar las herramientas de copia de seguridad estándar o Backup para bases de datos compatibles. Además, si los servicios y las herramientas de Azure no cumplen sus requisitos, puede usar herramientas de copia de seguridad compatibles de terceros que proporcionen un agente para la copia de seguridad y recuperación de todos los componentes de la plataforma de SAP BOBI.

Alta disponibilidad

Alta disponibilidad se refiere a un conjunto de tecnologías que pueden minimizar las interrupciones de TI ya que proporcionan continuidad empresarial de las aplicaciones o los servicios mediante componentes redundantes, con tolerancia a errores o protegidos mediante conmutación por error dentro del mismo centro de datos. En este caso, los centros de datos se encuentran dentro de una región de Azure. El artículo Arquitectura y escenarios de alta disponibilidad para SAP proporciona información sobre las distintas técnicas y recomendaciones de alta disponibilidad que se ofrecen en Azure para aplicaciones de SAP, que complementa las instrucciones de esta sección.

En función del resultado del dimensionamiento de la plataforma de SAP BOBI, debe diseñar el panorama y determinar la distribución de los componentes de BI en máquinas virtuales de Azure y subredes. El nivel de redundancia en la arquitectura distribuida depende del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (RPO) necesarios para la empresa. La plataforma de SAP BOBI incluye diferentes niveles y los componentes de cada nivel se deben diseñar para lograr redundancia. A continuación, si se produce un error en un componente, no habrá ninguna interrupción en la aplicación SAP BOBI. Por ejemplo:

  • Servidores de aplicaciones redundantes, como servidores de aplicaciones de BI y servidores web
  • Componentes únicos, como la base de datos CMS, el almacén de archivos y Load Balancer

En la siguiente sección se describe cómo lograr una alta disponibilidad en cada componente de la plataforma de SAP BOBI.

Alta disponibilidad en los servidores de aplicaciones

Los servidores de aplicaciones web y de BI no necesitan una solución de alta disponibilidad específica, independientemente de si se instalan por separado o de manera conjunta. Puede lograr una alta disponibilidad mediante redundancia, es decir, configurando varias instancias de BI y servidores web en varias máquinas virtuales de Azure. Puede implementar las máquinas virtuales en un conjunto de escalado flexible, conjuntos de disponibilidad o zonas de disponibilidad en función del RTO necesario para la empresa. Para la implementación en zonas de disponibilidad, asegúrese de que todos los demás componentes de la plataforma de SAP BOBI también estén diseñados para tener redundancia de zona.

Actualmente, no todas las regiones de Azure ofrecen zonas de disponibilidad, por lo que debe adoptar la estrategia de implementación en función de su región. Las regiones de Azure que ofrecen zonas aparecen en zonas de disponibilidad de Azure.

Importante

  • Los conceptos de zonas de disponibilidad de Azure y conjuntos de disponibilidad de Azure son mutuamente excluyentes. Puede implementar dos o varias máquinas virtuales en una zona de disponibilidad específica o en un conjunto de disponibilidad, pero no en ambos.
  • Si tiene pensado implementar en zonas de disponibilidad, le recomendamos que use un conjunto de escalado flexible con FD=1 en lugar de la implementación de zona de disponibilidad estándar.

Alta disponibilidad de la base de datos CMS

Si usa una base de datos de Azure como solución para las bases de datos CMS y de auditoría, el marco de alta disponibilidad con redundancia local se proporciona de manera predeterminada. Seleccione las capacidades de alta disponibilidad, redundancia y resistencia inherentes a la región y el servicio, sin necesidad de configurar ningún componente adicional. Si la estrategia de implementación de la plataforma de SAP BOBI se encuentra en la zona de disponibilidad, asegúrese de lograr la redundancia de zona para las bases de datos CMS y de auditoría. Para más información sobre la alta disponibilidad para las ofertas de base de datos admitidas en Azure, consulte Alta disponibilidad para Azure SQL Database. Consulte también Alta disponibilidad en Azure Database for MySQL.

Consulte guías de implementación de DBMS para la carga de trabajo de SAP para obtener información sobre una implementación de DBMS diferente y su enfoque para lograr una alta disponibilidad para una base de datos CMS.

Alta disponibilidad para Filestore

El almacén de archivos hace referencia a los directorios del disco donde se almacena contenido como informes, universos y conexiones. Se comparte en todos los servidores de aplicaciones de ese sistema. Por lo tanto, debe asegurarse de que tenga alta disponibilidad, junto con otros componentes de la plataforma de SAP BOBI.

Para una plataforma SAP BOBI que se ejecuta en Windows, puede elegir Azure Premium Files o Azure NetApp Files para el almacén de archivos. Ambas opciones están diseñadas para ser de alta disponibilidad y altamente duraderas. Azure Premium Files admite ZRS, que puede ser útil para la implementación entre zonas de la plataforma de SAP BOBI. Para más información, consulte la sección Redundancia para Azure Files.

Dado que el servicio de recursos compartidos de archivos no está disponible en todas las regiones, asegúrese de consultar la lista de productos disponibles por región para buscar la información actualizada. Si el servicio no está disponible en su región, puede crear un servidor NFS desde el que pueda compartir el sistema de archivos con la aplicación SAP BOBI. Sin embargo, también debe tener en cuenta su alta disponibilidad.

Alta disponibilidad para el equilibrador de carga

Para distribuir el tráfico a través de un servidor web, puede usar Load Balancer o Application Gateway. La redundancia para cualquiera de los equilibradores de carga se puede lograr en función de la SKU que elija para la implementación:

  • Load Balancer: la redundancia se puede lograr mediante la configuración del front-end de Standard Load Balancer como con redundancia de zona. Para más información, consulte Standard Load Balancer y zonas de disponibilidad.

  • Application Gateway: la alta disponibilidad se puede lograr en función del tipo de nivel seleccionado durante la implementación:

    • La SKU v1 admite escenarios de alta disponibilidad al implementar dos o más instancias. Azure distribuye estas instancias entre dominios de actualización y de errores para asegurarse de que las instancias no produzcan un error todas al mismo tiempo. Con esta SKU, se puede lograr redundancia dentro de la zona.

    • La SKU v2 garantiza automáticamente que las nuevas instancias se reparten entre dominios de error y dominios de actualización. Si elige la redundancia de zona, las instancias más recientes también se distribuyen entre las zonas de disponibilidad para ofrecer resistencia ante errores de zona. Para más información, consulte Escalabilidad automática y Application Gateway con redundancia de zona v2.

Arquitectura de alta disponibilidad de referencia para la plataforma de SAP BusinessObjects BI

En la arquitectura de referencia siguiente se describe la configuración de la plataforma de SAP BOBI en las zonas de disponibilidad que se ejecutan en servidores Windows. La arquitectura muestra el uso de diferentes servicios de Azure como Application Gateway, Azure Premium Files (almacén de archivos) y SQL Database (bases de datos CMS y de auditoría). La plataforma de SAP BOBI ofrece redundancia de zona integrada, lo que reduce la complejidad de administrar diferentes soluciones de alta disponibilidad.

En la figura siguiente, la carga del tráfico entrante (HTTPS - TCP/443) se equilibra mediante una SKU de Application Gateway v2, que abarca varias zonas de disponibilidad. Application Gateway distribuye la solicitud de usuario entre los servidores web, que se distribuyen en varias zonas de disponibilidad. El servidor web reenvía la solicitud a las instancias del servidor de administración y procesamiento que se han implementado en máquinas virtuales independientes entre las zonas de disponibilidad. Azure Premium Files con ZRS se conecta a través de un vínculo privado a las máquinas virtuales de capa de almacenamiento y administración para acceder al contenido, como informes, universo y conexiones. La aplicación accede a las bases de datos CMS y de auditoría que se ejecutan en una instancia de SQL Database con redundancia de zona, la cual replica estas bases de datos en varias ubicaciones físicas dentro de una región de Azure.

Diagrama que muestra la arquitectura de alta disponibilidad para una plataforma de SAP BOBI en Windows.

En la arquitectura anterior se proporciona información sobre cómo se puede realizar la implementación de SAP BOBI en Azure. Sin embargo, no cubre todas las posibles opciones de configuración de una plataforma de SAP BOBI en Azure. Puede adaptar su implementación en función de las necesidades empresariales, eligiendo diferentes productos o servicios para los componentes, como Load Balancer, el servidor de repositorio de archivos y DBMS.

En el caso de que las zonas de disponibilidad no estén disponibles en la región seleccionada, puede implementar máquinas virtuales de Azure en conjuntos de disponibilidad. Azure se asegura de que las VM colocadas en un conjunto de disponibilidad se ejecuten en varios servidores físicos, bastidores de proceso, unidades de almacenamiento y conmutadores de red. Si se produce un error de hardware o software, solo un subconjunto de las VM se ve afectado y la solución general permanece operativa.

Recuperación ante desastres

En esta sección se explica la estrategia para proporcionar protección de recuperación ante desastres para una plataforma de SAP BOBI. Complementa el artículo Recuperación ante desastres para SAP , que es el recurso principal para un enfoque general de recuperación ante desastres de SAP. Para la plataforma de SAP BOBI, consulte la nota de SAP 2056228, en la que se describen los métodos siguientes para implementar un entorno de DR de forma segura:

  • Uso total o selectivo de la administración del ciclo de vida o de la federación para promover o distribuir el contenido del sistema principal.
  • Copiar periódicamente los contenidos de CMS y FRS.

En esta sección, se aborda la segunda opción para implementar un entorno de recuperación de desastres. En este artículo no se trata una lista exhaustiva de todas las opciones de configuración posibles para la recuperación ante desastres, pero se trata una solución que incluye servicios nativos de Azure en combinación con la configuración de la plataforma SAP BOBI.

Importante

  • La disponibilidad de cada componente en la plataforma de SAP BOBI debe tenerse en cuenta en la región secundaria. Toda la estrategia de DR debe probarse exhaustivamente.
  • Si la plataforma de SAP BI está configurada con un conjunto de escalado flexible con FD=1, debe usar PowerShell para configurar Azure Site Recovery para la recuperación ante desastres.

Arquitectura de DR de referencia para una plataforma de SAP BusinessObjects BI

Esta arquitectura de referencia ejecuta una implementación de varias instancias de la plataforma de SAP BOBI con servidores de aplicaciones redundantes. Para DR, debe conmutar por error todos los componentes de la plataforma de SAP BOBI a una región secundaria. En la figura siguiente, Azure Premium Files se usa como almacén de archivos, SQL Database como repositorio de CMS y de auditoría, y Application Gateway para equilibrar la carga del tráfico. La estrategia para lograr la protección de DR para cada componente es diferente, lo que se describe en la siguiente sección.

Diagrama que muestra la recuperación de desastres de la plataforma SAP BusinessObjects BI para Windows.

Balanceador de Carga

Load Balancer se usa para distribuir el tráfico entre servidores de aplicaciones web de la plataforma de SAP BOBI. En Azure, puede usar Load Balancer o Application Gateway para equilibrar la carga del tráfico entre los servidores web. Para lograr la recuperación ante desastres de los servicios del equilibrador de carga, debe implementar otro equilibrador de carga o puerta de enlace de aplicación en una región secundaria. Para mantener la misma dirección URL después del fallo de DR, cambie la entrada en el DNS para que apunte al servicio de equilibrio de carga que se ejecuta en la región secundaria.

Máquinas virtuales que ejecutan servidores de aplicaciones web y de BI

Azure Site Recovery se puede usar para replicar máquinas virtuales que ejecutan servidores de aplicaciones web y de BI en la región secundaria. Site Recovery replica los servidores y todos los discos administrados conectados a la región secundaria. Cuando se producen desastres o interrupciones, puede activar la conmutación por error fácilmente al entorno replicado y continuar trabajando. Para empezar a replicar todas las máquinas virtuales de la aplicación SAP en el centro de datos de Recuperación ante desastres de Azure, siga las instrucciones de Replicación de una máquina virtual en Azure.

Directorio de disco de almacén de archivos

El almacén de archivos es un directorio de disco donde se almacenan archivos reales, como informes y documentos de BI. Asegúrese de que todos los archivos del almacén de archivos se sincronizan con la región de recuperación ante desastres. La estrategia de recuperación ante desastres (DR) que utiliza para sincronizar contenido depende del tipo de servicio de uso compartido de archivos para su plataforma SAP BOBI en Windows. Por ejemplo:

Base de datos CMS

Las bases de datos CMS y de auditoría de la región de DR deben ser una copia de las bases de datos que se ejecutan en la región primaria. En función del tipo de base de datos, es importante copiar la base de datos en la región de DR según el RTO y el RPO necesarios para la empresa. En esta sección se describen las distintas opciones disponibles para cada solución de base de datos en Azure compatible con una aplicación SAP BOBI que se ejecuta en Windows.

Azure SQL Database

Para una estrategia de DR de SQL Database, hay dos opciones disponibles para copiar la base de datos en la región secundaria. Ambas opciones de recuperación ofrecen diferentes niveles de RTO y RPO. Para más información sobre el RTO y el RPO para cada opción de recuperación, consulte Recuperación de una base datos en un servidor existente.

Opción 1: Restauración de una copia de seguridad de base de datos con redundancia geográfica

  • De forma predeterminada, SQL Database almacena los datos en blobs GRS que se replican en una región emparejada. En el caso de una base de datos SQL, la redundancia de almacenamiento de copia de seguridad se puede configurar en el momento de la creación de la base de datos CMS y la base de datos de auditoría. También se puede actualizar para una base de datos existente. Los cambios realizados en una base de datos existente solo se aplican a las copias de seguridad futuras. Una base de datos situada en cualquier base de datos de SQL de cualquier región de Azure se puede restaurar desde las copias de seguridad con replicación geográfica más recientes. La restauración geográfica usa una copia de seguridad con replicación geográfica como su origen. Se produce un retraso entre el momento en que el sistema crea una copia de seguridad y la hora en que replica geográficamente la copia de seguridad en un blob de Azure en otra región. Como resultado, la base de datos restaurada puede encontrarse hasta una hora por detrás de la base de datos original.

    Importante

    La restauración geográfica está disponible para bases de datos de SQL configuradas con almacenamiento de copia de seguridad con redundancia geográfica.

Opción 2: Replicación geográfica o un grupo de conmutación por error automática

  • La replicación geográfica es una característica de SQL Database que permite crear bases de datos secundarias legibles de bases de datos individuales en un servidor en la misma región o en otra distinta. Si la replicación geográfica está habilitada para las bases de datos CMS y de auditoría, la aplicación puede iniciar la conmutación por error en una base de datos secundaria de otra región de Azure. La replicación geográfica está habilitada para bases de datos individuales. Para habilitar la conmutación por error transparente y coordinada de varias bases de datos (de auditoría y CMS) para una aplicación SAP BOBI, se recomienda usar un grupo de conmutación por error automática. Proporciona la semántica de grupo, además de la replicación geográfica activa, por lo que todo el servidor SQL (todas las bases de datos) se replica en otra región, en lugar de las bases de datos individuales. Consulte la tabla de capacidades que compara la replicación geográfica con los grupos de conmutación por error.

  • Los grupos de conmutación por error automática proporcionan puntos de conexión de agentes de escucha de lectura y escritura y de solo lectura que no se modifican durante las conmutaciones por error. El punto de conexión de lectura y escritura se puede mantener como cliente de escucha en la entrada de conexión ODBC para las bases de datos CMS y de auditoría. Por lo tanto, ya sea que use la activación de conmutación por error automática o manual, la conmutación por error transforma todas las bases de datos secundarias del grupo en primarias. Después de que la conmutación por error de una base de datos finaliza, el registro de DNS se actualiza automáticamente para redirigir los puntos de conexión a la nueva región. La aplicación se conecta automáticamente a la base de datos de CMS, ya que el punto de conexión de lectura y escritura se mantiene como cliente de escucha en la conexión ODBC.

    En la imagen siguiente, el grupo de conmutación por error automática para un servidor de SQL (azussqlbodb) que se ejecuta en la región Este de EE. UU. 2 se replica en la región secundaria Este de EE. UU. (sitio de DR). El punto de conexión del cliente de escucha de lectura y escritura se mantiene como cliente de escucha en la conexión ODBC para el servidor de aplicaciones de BI que se ejecuta en Windows. Después de la conmutación por error, el punto de conexión sigue siendo el mismo. No se requiere ninguna intervención manual para conectar la aplicación de BI a la base de datos de Azure SQL en la región secundaria.

    Captura de pantalla que muestra los grupos de conmutación por error automática de la base de datos SQL.

    Esta opción proporciona un RTO y RPO inferiores a la opción 1. Para obtener más información sobre esta opción, vea Uso de grupos de conmutación por error automática para habilitar la conmutación por error transparente y coordinada de varias bases de datos.

Base de Datos de Azure para MySQL

Azure Database for MySQL proporciona opciones para recuperar una base de datos si se produce algún desastre. Elija la opción adecuada que se adapte a su empresa:

  • Habilite las réplicas de lectura entre regiones para mejorar la planificación de la continuidad empresarial y DR. Puede crear hasta cinco réplicas desde el servidor de origen. Las réplicas de lectura se actualizan de forma asincrónica mediante la tecnología de replicación de registros binarios de Azure Database for MySQL. Las réplicas son nuevos servidores que se administran de forma similar a los servidores de Azure Database for MySQL normales. Para más sobre las réplicas de lectura, las regiones disponibles, las restricciones y la conmutación por error, vea Réplicas de lectura en Azure DB for MySQL.

  • Use la característica de restauración geográfica de Azure Database for MySQL que permite restaurar el servidor mediante copias de seguridad con redundancia geográfica. Se puede acceder a estas copias de seguridad incluso cuando la región en la que se hospeda el servidor está sin conexión. Puede realizar la restauración a partir de estas copias de seguridad en cualquier otra región y volver a poner en línea el servidor.

    Importante

    La restauración geográfica solo es posible si se ha aprovisionado el servidor con almacenamiento de copia de seguridad con redundancia geográfica. No se admite el cambio de las opciones de redundancia de copia de seguridad después de la creación del servidor. Para más información, vea Redundancia de copia de seguridad.

En la tabla siguiente se enumeran las recomendaciones para DR en cada nivel usado en este ejemplo.

Niveles de la plataforma de SAP BOBI Recomendación
Azure Application Gateway o Azure Load Balancer Configuración paralela de Application Gateway en una región secundaria
Servidores de aplicaciones web Replicación con Azure Site Recovery
Servidores de aplicaciones de BI Replicación mediante Site Recovery
Azure Archivos Premium AzCopy o Azure PowerShell
Azure NetApp Files Herramienta de copia basada en archivos para replicar datos en una región secundaria o replicación entre regiones de Azure NetApp Files
Azure SQL Database Grupos de replicación geográfica/conmutación por error automática o restauración geográfica.
Base de Datos de Azure para MySQL Réplicas de lectura entre regiones o restauración de la copia de seguridad de copias de seguridad con redundancia geográfica

Contenido relacionado

  • Last updated on