Implementación de DBMS de Azure Virtual Machines de SQL Server para la carga de trabajo de SAP NetWeaver

En este documento se describen las diferentes áreas que se deben tener en cuenta al implementar SQL Server para la carga de trabajo de SAP en IaaS de Azure. Como condición previa a este documento, debe haber leído el documento Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP y otras guías de la documentación de carga de trabajo de SAP en Azure.

En general, debería considerar usar las versiones más recientes de SQL Server para ejecutar la carga de trabajo de SAP en IaaS de Azure. Las versiones más recientes de SQL Server ofrecen una mejor integración en algunos de los servicios y funcionalidades de Azure o disponer de cambios que optimicen las operaciones en una infraestructura de IaaS de Azure.

Se recomienda revisar el artículo Qué es SQL Server en Azure Virtual Machines (Windows) antes de continuar.

En las secciones siguientes se agregan y mencionan fragmentos de partes de la documentación del vínculo anterior. Se describen de forma más detallada algunos conceptos y se mencionan consideraciones sobre SAP. Sin embargo, se recomienda encarecidamente consultar la documentación anterior primero antes de leer la documentación específica de SQL Server.

Debe conocer información específica sobre SQL Server en IaaS antes de continuar:

• Soporte para versiones de SQL: para los clientes de SAP se presta soporte para SQL Server 2008 R2 y posteriores en las máquinas virtuales de Microsoft Azure. No se prestará soporte para versiones anteriores. Revise esta declaración de soporte general para más información. En general, Microsoft también presta soporte para SQL Server 2008. Sin embargo, debido a la importante funcionalidad de SAP que se introdujo con SQL Server 2008 R2, SQL Server 2008 R2 es la versión mínima que se requiere para SAP. En general, debería considerar usar las versiones más recientes de SQL Server para ejecutar la carga de trabajo de SAP en IaaS de Azure. Las versiones más recientes de SQL Server ofrecen una mejor integración en algunos de los servicios y funcionalidades de Azure o disponer de cambios que optimicen las operaciones en una infraestructura de IaaS de Azure. Por lo tanto, el documento se limita a SQL Server 2016 y SQL Server 2017.
• Rendimiento de SQL: las máquinas virtuales hospedadas en Microsoft Azure funcionan bien en comparación con otras ofertas de virtualización de nube pública, aunque los resultados individuales pueden variar. Consulte el artículo Procedimientos recomendados para SQL Server en Azure Virtual Machines.
• Uso de imágenes de Azure Marketplace: la forma más rápida de implementar una nueva máquina virtual de Microsoft Azure es utilizando una imagen de Azure Marketplace. Hay imágenes en Azure Marketplace que contienen las versiones más recientes de SQL Server. Las imágenes donde ya se ha instalado SQL Server no se pueden utilizar inmediatamente para aplicaciones de SAP NetWeaver. El motivo es que la intercalación de SQL Server predeterminada está instalada en esas imágenes y no la que requieren los sistemas SAP NetWeaver. Para usar estas imágenes, consulte los pasos que se explican en el capítulo Uso de imágenes de SQL Server desde Microsoft Azure Marketplace.
• Compatibilidad con varias instancias de SQL Server en una sola máquina virtual de Azure: se admite este método de implementación. Sin embargo, tenga en cuenta las limitaciones de los recursos, especialmente en torno al ancho de banda de red y almacenamiento del tipo de máquina virtual que está usando. Puede encontrar información detallada en el artículo Tamaños de las máquinas virtuales en Azure. Estas limitaciones de cuota tal vez no le permitan implementar la misma arquitectura de varias instancias que puede implementar en el entorno local. En cuanto a la configuración y la interferencia de compartir los recursos disponibles dentro de una sola máquina virtual, se deben tener en cuenta las mismas consideraciones que en el entorno local.
• Varias bases de datos de SAP en una sola instancia de SQL Server en una sola máquina virtual: como se mencionó anteriormente, se admiten configuraciones como estas. Las consideraciones sobre varias bases de datos de SAP que comparten los recursos de una sola instancia de SQL Server son las mismas que para las implementaciones en entornos locales. Tenga en cuenta otros límites adicionales, como el número de discos que se pueden conectar a un tipo de máquina virtual específico. O los límites de cuota de red y almacenamiento de tipos de máquina virtual específicos como tamaños detallados para máquinas virtuales en Azure.

Recomendaciones sobre la estructura de máquina virtual y VHD para SAP relacionadas con las implementaciones de SQL Server

Según la descripción general, el sistema operativo, los archivos ejecutables de SQL Server y, en el caso de los sistemas SAP de 2 niveles, los archivos ejecutables de SAP se deben ubicar o instalar en discos de Azure independientes. Normalmente, la carga de trabajo de SAP NetWeaver no utiliza en gran medida la mayoría de las bases de datos de sistema de SQL Server. No obstante, las bases de datos del sistema de SQL Server (maestra, msdb y modelo) deben estar, junto con los demás directorios de SQL Server, en un disco de Azure independiente. tempdb de SQL Server debe encontrarse en la unidad D:\ no persistente o en un disco independiente.

• Con todos los tipos de máquina virtual certificados de SAP (consulte la nota de SAP 1928533), salvo las máquinas virtuales de la serie A, los datos de tempdb y los archivos de registro se pueden colocar en la unidad D:\ no persistente.
• En el caso de las versiones anteriores de SQL Server, donde SQL Server instala tempdb con un archivo de datos de forma predeterminada, se recomienda usar varios archivos de datos de tempdb. Tenga en cuenta que los volúmenes de la unidad D:\ serán diferentes en función del tipo de máquina virtual. Para saber cuáles son los tamaños exactos de la unidad D:\ de las distintas máquinas virtuales, consulte el artículo Tamaños de las máquinas virtuales Windows en Azure.

Estas configuraciones permiten que tempdb consuma más espacio y más importante, más IOPS y ancho de banda de almacenamiento que el que la unidad del sistema puede proporcionar. La unidad D:\ no persistente también ofrece un mejor rendimiento y latencia de E/S (a excepción de las máquinas virtuales de la serie A). Para determinar el tamaño correcto de tempdb, puede comprobar los tamaños de tempdb en los sistemas existentes.

Una configuración de máquina virtual que ejecuta SQL Server con una base de datos de SAP donde el archivo de registro de tempdb y el de datos se colocan en la unidad D:\ tendría el siguiente aspecto:

En el diagrama anterior se muestra un caso sencillo. Como se menciona en el artículo Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP, el tipo de almacenamiento de Azure, el número y el tamaño de los discos dependen de varios factores, pero en general se recomienda lo siguiente:

• Usar un volumen grande, que contenga los archivos de datos de SQL Server. El motivo de esta configuración es que en la vida real hay muchas bases de datos de SAP con archivos de base de datos de distintos tamaños y con diferentes cargas de trabajo de E/S.
• Usar la unidad D:\ para tempdb mientras el rendimiento sea lo suficientemente bueno. Si el rendimiento de la carga de trabajo global está limitado porque tempdb se encuentra en la unidad D:, puede que deba considerar el traslado de tempdb a discos independientes de Azure Storage Premium o Ultra, como se recomienda en este artículo.

Aspectos especiales para las máquinas virtuales de la serie M

Para la máquina virtual de Azure de la serie M, se puede reducir la latencia de escritura en el registro de transacciones mediante factores, en comparación con el rendimiento de Azure Premium Storage, cuando se usa el Acelerador de escritura de Azure. Por tanto, se debe implementar el Acelerador de escritura de Azure para los discos duros virtuales que forman el volumen para el registro de transacciones de SQL Server. En el documento Acelerador de escritura se pueden leer los detalles.

Aplicar formato a los discos

Para SQL Server, el tamaño de bloque NTFS de los discos que contienen los archivos de registro y de datos de SQL Server deben tener un tamaño de 64 KB. No hay que formatear la unidad D:, ya que este proceso se ha realizado previamente.

Para asegurarse de que la restauración o la creación de bases de datos no inicialice los archivos de datos llenando con ceros el contenido de los archivos, debe asegurarse de que el servicio de SQL Server que se ejecuta en el contexto de usuario tiene un permiso determinado. Normalmente, los usuarios del grupo de administrador de Windows tienen estos permisos. Si el servicio SQL Server se ejecuta en el contexto de usuario del usuario no administrador de Windows, debe asignar a ese usuario el derecho de usuario Realizar tareas de mantenimiento del volumen. Consulte los detalles en este artículo de Microsoft Knowledge Base: https://support.microsoft.com/kb/2574695

Impacto de la compresión de las bases de datos

En configuraciones donde el ancho de banda de E/S puede convertirse en un factor de limitación, todas las medidas que reduzcan el número de IOPS podrían ayudar a ajustar la carga de trabajo que se puede ejecutar en un escenario de IaaS como Azure. Por lo tanto, si aún no lo ha hecho, Microsoft y SAP recomiendan que aplique la compresión de página de SQL Server antes de cargar bases de datos de SAP existentes en Azure.

La recomendación para realizar la compresión de la base de datos antes de cargar en Azure viene motivada por dos razones:

• La cantidad de datos que se carga es menor.
• La duración de la ejecución de la compresión es más breve dándose por supuesto que se puede utilizar hardware más eficaz con más CPU, mayor ancho de banda de E/S o menos latencia de E/S en un entorno local.
• Si se utilizan tamaños de base de datos más pequeños, se incurriría en menos costes de asignación de disco.

La compresión de las bases de datos funciona también correctamente en Azure Virtual Machines de la misma forma que en local. Para obtener más información sobre cómo comprimir bases de datos de SQL Server de SAP NetWeaver, consulte el artículo Improved SAP compression tool MSSCOMPRESS (Herramienta de compresión de SAP MSSCOMPRESS mejorada).

SQL Server 2014 y versiones más recientes: almacenamiento de archivos de base de datos directamente en Azure Blob Storage

SQL Server 2014 y versiones posteriores ofrecen la posibilidad de almacenar archivos de base de datos directamente en el almacén de blobs de Azure sin necesidad de usar el contenedor de un disco duro virtual en ellos. Especialmente al usar Standard Azure Storage o tipos de máquina virtual con tamaños más pequeños, este tipo de implementación da lugar a escenarios donde pueden superarse los límites de IOPS impuestos por un número limitado de discos que pueden montarse en tipos de máquinas virtuales de menor tamaño. Aunque este método de implementación funciona con las bases de datos de usuario, no funciona con las de sistema de SQL Server. También funciona con los archivos de registro y de datos de SQL Server. Si quiere implementar una base de datos SQL Server de SAP de este modo, en lugar de contenerla en discos, debe tener en cuenta lo siguiente:

• La cuenta de almacenamiento utilizada debe estar en la misma región de Azure que la que se empleó para implementar la máquina virtual que se está ejecutando en SQL Server.
• Para este método de implementaciones también se aplican las consideraciones que se indicaron anteriormente relacionadas con la distribución de los discos virtuales en diferentes cuentas de Azure Storage. Significa que el número de operaciones de E/S cuenta para los límites de la cuenta de Azure Storage.
• En lugar de contabilizarse en la cuota de E/S de almacenamiento de la máquina virtual, el tráfico de los blobs de almacenamiento que representan los datos y los archivos de registro de SQL Server se contabilizará en el ancho de banda de red de la máquina virtual del tipo de máquina virtual concreto. Para saber cuál es la red y el ancho de banda de red de un determinado tipo de máquina virtual, consulte el artículo Tamaños de las máquinas virtuales Windows en Azure.
• Como resultado de la inserción de E/S de archivos mediante la cuota de red, se eliminará mayormente la cuota de almacenamiento y, con ese uso, solo parcialmente el ancho de banda de red general de la máquina virtual.
• Ya no se aplican los objetivos de rendimiento de E/S y de IOPS que tiene Azure Premium Storage para los distintos tamaños de disco. Incluso si los blobs que ha creado están en Azure Premium Storage. Los objetivos están documentados en el artículo Discos administrados y Premium Storage de alto rendimiento para VM. Como resultado de colocar los archivos de datos y los archivos de registro de SQL Server directamente en blobs que se almacenan en Azure Premium Storage, las características de rendimiento pueden variar respecto a los discos duros virtuales de Azure Premium Storage.
• El almacenamiento en caché basado en host que está disponible para los discos de Azure Premium Storage no está disponible al colocar los archivos de datos de SQL Server directamente en los blobs de Azure.
• En las máquinas virtuales de la serie M no se puede usar el Acelerador de escritura de Azure para admitir escrituras inferiores a milisegundos en el archivo de registro de transacciones de SQL Server.

En el artículo Archivos de datos de SQL Server en Microsoft Azure encontrará información detallada sobre esta funcionalidad.

La recomendación para los sistemas de producción consiste en evitar esta configuración y elegir las ubicaciones de los datos y los archivos de registro de SQL Server en discos duros virtuales de Azure Premium Storage en lugar de colocarlos directamente en blobs de Azure.

Extensión de grupo de búferes de SQL Server 2014

SQL Server 2014 incorporó una nueva característica denominada Extensión del grupo de búferes. Esta funcionalidad amplía el grupo de búferes de SQL Server que se mantiene en memoria con una memoria caché de segundo nivel respaldada por discos SSD locales de un servidor o una máquina virtual. La extensión del grupo de búferes permite tener "en memoria" un espacio de trabajo de datos mayor. En comparación con el acceso a Azure Standard Storage, el acceso a la extensión del grupo de búferes que se almacena en discos SSD locales de una máquina virtual de Azure es mucho más rápido. Si se compara la Extensión del grupo de búferes con la Caché de lectura de Azure Premium Storage, como se recomienda para los archivos de datos de SQL Server, no se esperan ventajas significativas para las extensiones del grupo de búferes. El motivo es que las memorias caché (extensión de grupo de búferes de SQL Server y memoria caché de lectura de Premium Storage) usan los discos locales del nodo de proceso de Azure.

La experiencia adquirida mientras tanto con la Extensión del grupo de búferes de SQL Server con la carga de trabajo de SAP es variada y aún no ofrece unas recomendaciones claras sobre si se debe usar en todos los casos. Lo ideal es que el espacio de trabajo que requiere la aplicación de SAP se adapte a la memoria principal. Con la oferta de Azure de máquinas virtuales de hasta 4 TB de memoria, debería ser factible mantener el espacio de trabajo en memoria. Por lo tanto, el uso de la Extensión del grupo de búferes se limita a algunos casos excepcionales y no debería ser un caso convencional.

Consideraciones de copia de seguridad y recuperación en SQL Server

Al implementar SQL Server en Azure, se debe revisar la metodología de copia de seguridad. Aunque no se trate de un sistema de producción, debe llevarse a cabo de manera periódica una copia de seguridad de la base de datos de SAP hospedada por SQL Server. Como Azure Storage mantiene tres imágenes, una copia de seguridad es menos importante para compensar un bloqueo de almacenamiento. El principal motivo para mantener un plan de copia de seguridad y recuperación adecuado es más que poder compensar los errores lógicos o manuales proporcionando funcionalidades de recuperación a un momento dado. El objetivo es usar las copias de seguridad para restaurar la base de datos a un momento dado o utilizar las copias de seguridad de Azure para propagar otro sistema mediante la copia de la base de datos existente.

Para buscar otras posibilidades de copia de seguridad de SQL Server en Azure, lea el artículo Copias de seguridad y restauración para SQL Server en Azure Virtual Machines. En este artículo se describen varias posibilidades.

Copias de seguridad manuales

Tiene varias posibilidades para hacer copias de seguridad "manuales":

1. Realizar copias de seguridad convencionales de SQL Server en discos de Azure conectados directos. Este método tiene la ventaja de que tiene a su disposición las copias de seguridad con rapidez para las actualizaciones del sistema y la creación de nuevos sistemas como copias de los sistemas SAP existentes.
2. SQL Server 2012 CU4 y posterior puede realizar copias de seguridad de las bases de datos en una dirección URL de almacenamiento de Azure.
3. Copias de seguridad de instantáneas de archivo para archivos de base de datos en Azure Blob Storage. Este método solo funciona si los archivos de registro y los datos de SQL Server se encuentran en Azure Blob Storage.

El primer método es muy conocido y también se aplica en muchos casos de ubicaciones locales. No obstante, le deja la tarea de resolver la ubicación de copia de seguridad a más largo plazo. Como no quiere conservar las copias de seguridad durante 30 o más días en el almacenamiento de Azure Storage conectado localmente, deberá usar los servicios de Azure Backup u otra herramienta de copia de seguridad o recuperación de terceros que incluya la administración de acceso y de retención de las copias de seguridad. La alternativa es crear en Azure un servidor de archivos de gran tamaño usando espacios de almacenamiento de Windows.

El segundo método se describe con más detalle en el artículo Copia de seguridad en URL de SQL Server. Hay distintas versiones de SQL Server que presentan algunas variaciones respecto a esta funcionalidad. Por lo tanto, debe consultar la documentación de la comprobación de su versión de SQL Server concreta. Es importante tener en cuenta que en este artículo se detallan numerosas restricciones. Tiene la posibilidad de hacer la copia de seguridad en:

• Un blob en páginas de Azure, que limita el tamaño de copia de seguridad a 1000 GB. Esta restricción también limita el rendimiento que se puede conseguir.
• Varios blobs en bloques de Azure (hasta 64), que posibilitan un tamaño teórico de copia de seguridad de 12 TB. En cambio, se han hecho pruebas con bases de datos de clientes que revelan que el tamaño máximo de copia de seguridad puede ser menor que el límite teórico. En este caso, usted es responsable de administrar la retención de copias de seguridad, así como del acceso a las copias de seguridad.

Copia de seguridad automatizada para SQL Server

Copia de seguridad automatizada proporciona un servicio de copia de seguridad automático para las ediciones de SQL Server Standard y Enterprise que se ejecutan en una VM de Windows en Azure. Este servicio se proporciona por la extensión del agente de IaaS de SQL Server, que se instala automáticamente en las imágenes de máquina virtual de Windows de SQL Server en Azure Portal. Si implementa sus propias imágenes de sistema operativo con SQL Server instalado, deberá instalar las extensiones de máquina virtual por separado. Los pasos necesarios están documentados en este artículo.

En estos artículos encontrará más información detallada sobre las capacidades de este método:

• SQL Server 2014: Automated Backup para SQL Server 2014 en Azure Virtual Machines (Resource Manager)
• SQL Server 2016/2017: Automated Backup v2 para Azure Virtual Machines (Resource Manager)

Si consulta la documentación, verá que se ha mejorado la funcionalidad con las versiones más recientes de SQL Server. En el artículo Copia de seguridad administrada de SQL Server en Microsoft Azure se publica más información detallada sobre las copias de seguridad automatizadas de SQL Server. El límite de tamaño teórico de copia de seguridad es de 12 TB. Las copias de seguridad automatizadas pueden ser un buen método para las copias de seguridad de hasta 12 TB. Dado que se escriben varios blobs en paralelo, puede prever un rendimiento de más de 100 MB/s.

Azure Backup para VM con SQL Server

Este nuevo método de copias de seguridad de SQL Server está disponible desde junio de 2018 como una versión preliminar pública en los servicios de Azure Backup. El método de copia de seguridad de SQL Server es el mismo que usan otras herramientas de terceros (la interfaz VSS/VDI de SQL Server) para transmitir copias de seguridad a una ubicación de destino. En este caso, la ubicación de destino es el almacén de Azure Recovery Services.

En la página Copia de seguridad de bases de datos de SQL Server en Azure encontrará una descripción más detallada de este método de copia de seguridad, que presenta numerosas ventajas de configuraciones de copia de seguridad central, supervisión y administración.

Soluciones de copia de seguridad de terceros

Para no pocos clientes de SAP no se podía volver a empezar e introducir nuevas soluciones de copia de seguridad completas para la parte de su entorno de SAP que se ejecutaba en Azure. Como resultado, las soluciones de copia de seguridad existentes se tenían que usar y ampliar en Azure. La extensión de las soluciones de copia de seguridad existentes a Azure solía funcionar bien con la mayoría de los proveedores principales en este espacio.

Uso de imágenes de SQL Server desde Microsoft Azure Marketplace

Microsoft ofrece en Azure Marketplace máquinas virtuales que ya contienen versiones de SQL Server. Para los clientes de SAP que requieran licencias de SQL Server y Windows, el uso de estas imágenes podría ser una oportunidad para cubrir la necesidad de licencias activando las máquinas virtuales con SQL Server ya instalado. Para poder utilizar dichas imágenes para SAP, deben tenerse en cuenta las siguientes consideraciones:

• Las versiones de SQL Server que no son de evaluación incurren en costos más elevados que una máquina virtual exclusivamente con Windows implementada desde Azure Marketplace. Consulte estos artículos para comparar los precios: https://azure.microsoft.com/pricing/details/virtual-machines/windows/ y https://azure.microsoft.com/pricing/details/virtual-machines/sql-server-enterprise/.
• Solo se pueden usar las versiones de SQL Server compatibles con SAP.
• La intercalación de la instancia de SQL Server que está instalada en las máquinas virtuales que se ofrecen en Azure Marketplace no es la que requiere SAP NetWeaver para ejecutar la instancia de SQL Server. Puede cambiar la intercalación, aunque debe seguir las instrucciones de la sección que encontrará a continuación.

Modificación de la intercalación de SQL Server de una máquina virtual de Windows o SQL Server

Puesto que las imágenes de SQL Server en Azure Marketplace no están configuradas para usar la intercalación necesaria para las aplicaciones de SAP NetWeaver, debe modificarse inmediatamente después de llevar a cabo la implementación. Para SQL Server, este cambio de intercalación se puede efectuar siguiendo estos pasos en cuanto se haya implementado la máquina virtual y un administrador pueda iniciar sesión en la máquina virtual implementada:

• Abra una ventana de comandos de Windows como administrador.
• Cambie el directorio a C:\Archivos de programa\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
• Ejecute el comando: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2.
  • <local_admin_account_name> es la cuenta que se definió como cuenta de administrador al implementar la máquina virtual por primera vez por medio de la galería.

Este proceso solo debe llevar unos minutos. Para asegurarse de que obtiene el resultado correcto, realice los pasos siguientes:

• Abra SQL Server Management Studio.
• Abra una ventana de consulta.
• Ejecute el comando sp_helpsort en la base de datos maestra de SQL Server.

El resultado deberá ser similar al que se muestra a continuación:

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Si el resultado es diferente, DETENGA la implementación de SAP e investigue por qué el comando de instalación no funcionó como se esperaba. NO se admite la implementación de aplicaciones de SAP NetWeaver en la instancia de SQL Server con páginas de códigos de SQL Server distintas de la mencionada antes.

Alta disponibilidad de SQL Server para SAP en Azure

Si usa SQL Server en implementaciones de IaaS de Azure para SAP, dispondrá de distintas posibilidades para implementar la capa de DBMS de alta disponibilidad. Como ya se ha descrito en Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP, Azure proporciona distintos Acuerdos de nivel de servicio de tiempo de actividad para una máquina virtual y un par de máquinas virtuales implementadas en un conjunto de disponibilidad de Azure. Se supone que tiene como objetivo el acuerdo de nivel de servicio de tiempo de actividad para sus implementaciones de producción que requieren la implementación en conjuntos de disponibilidad de Azure. En tal caso, deberá implementar un mínimo de dos máquinas virtuales en dicho conjunto de disponibilidad. Una máquina virtual ejecutará la instancia activa de SQL Server. La otra máquina virtual ejecutará la instancia pasiva

Clústeres de SQL Server mediante el servidor de archivos de escalabilidad horizontal de Windows o un disco compartido de Azure

Con Windows Server 2016, Microsoft introdujo los espacios de almacenamiento directo. En función de la implementación de Espacios de almacenamiento directo, se admite la agrupación en clústeres de FCI de SQL Server en general. Azure también ofrece discos compartidos de Azure que podrían usarse para la agrupación en clústeres de Windows. En el caso de la carga de trabajo de SAP, no se admiten estas opciones de alta disponibilidad.

Trasvase de registros de SQL Server

Uno de los métodos de alta disponibilidad (HA) consiste en trasvasar los registros de SQL Server. Si las máquinas virtuales que participan en la configuración de alta disponibilidad tienen resolución de nombres de trabajo, no hay ningún problema. La configuración en Azure no difiere de ninguna configuración que se realice localmente relacionada con la configuración del trasvase de registros y los principios en torno al trasvase de registros. En el artículo Acerca del trasvase de registros (SQL Server) encontrará información detallada sobre el trasvase de registros de SQL Server.

La funcionalidad de trasvase de registros de SQL Server apenas se usó en Azure para lograr una alta disponibilidad dentro de una región de Azure. En cambio, en los escenarios siguientes, los clientes de SAP usaban el trasvase de registros adecuadamente con Azure:

• Escenarios de recuperación ante desastres de una región de Azure a otra
• Configuración de la recuperación ante desastres de una ubicación local a una región de Azure
• Escenarios de migración de una ubicación local a Azure. En esos casos, se usa el trasvase de registros para sincronizar la nueva implementación de DBMS en Azure con el sistema de producción actual a nivel local. En el momento de la migración, el sistema de producción se apaga y se garantiza que las copias de seguridad del registro de transacciones más recientes se hayan transferido a la implementación de DBMS de Azure. Después, la implementación de DBMS de Azure se abre para producción.

Creación de reflejo de la base de datos

La funcionalidad de creación de reflejo de la base de datos, que es compatible con SAP (consulte la nota de SAP 965908), se basa en la definición de un asociado de conmutación por error en la cadena de conexión de SAP. Para los casos entre locales, asumimos que las dos máquinas virtuales están en el mismo dominio y que las dos instancias de SQL Server se están ejecutando como un usuario del dominio, así como que tendrán los privilegios suficientes en las dos instancias de SQL Server. Por lo tanto, el proceso configuración de la creación de reflejo de la base de datos de Azure es el mismo en una configuración o instalación local típica.

Al igual que con las implementaciones exclusivas en la nube, el método más fácil es tener otra configuración de dominio en Azure con el fin de albergar esas máquinas virtuales de DBMS (e, idealmente, las máquinas virtuales de SAP específicas) dentro de un dominio.

Si un dominio no es posible, se pueden usar certificados para los puntos de conexión de creación de reflejo de la base de datos como se describe aquí: Uso de certificados para un punto de conexión de creación de reflejo de la base de datos (Transact-SQL).

Aquí encontrará un tutorial para configurar la creación de reflejo de la base de datos en Azure: Creación de reflejo de la base de datos (SQL Server).

SQL Server AlwaysOn

Como AlwaysOn es compatible con un entorno de SAP local (consulte la nota de SAP 1772688), se puede usar en combinación con SAP en Azure. Hay algunas consideraciones especiales respecto a implementar el agente de escucha de grupo de disponibilidad de SQL Server (no debe confundirse con el conjunto de disponibilidad de Azure), ya que Azure en este momento no permite crear un objeto AD o DNS como en las implementaciones locales. Por lo tanto, hay que realizar otros pasos de instalación para solucionar el comportamiento específico de Azure.

Estas son algunas de las consideraciones que hay que tener en cuenta al usar un agente de escucha de grupo de disponibilidad:

• Solo se puede usar un agente de escucha de grupo de disponibilidad con Windows Server 2012 o posterior como SO invitado de la máquina virtual. Para Windows Server 2012, debe asegurarse de que se aplica esta revisión: https://support.microsoft.com/kb/2854082
• Esta revisión no está disponible para Windows Server 2008 R2 y AlwaysOn tendría que usarse de la misma manera que la funcionalidad de creación de reflejo de base de datos mediante la especificación de un asociado de conmutación por error en la cadena de conexiones (se realiza mediante el parámetro de SAP default.pfl dbs/mss/server; consulte la nota de SAP 965908).
• Cuando se utiliza un agente de escucha de grupo de disponibilidad, las máquinas virtuales de la base de datos tienen que estar conectadas a un equilibrador de carga específico. Para evitar que Azure asigne nuevas direcciones IP en casos donde ambas máquinas virtuales se apaguen accidentalmente, se deben asignar direcciones IP estáticas a las interfaces de red de esas máquinas virtuales en la configuración de AlwaysOn (la definición de una dirección IP estática se describe en este artículo)
• Hay que realizar algunos pasos especiales al crear la configuración del clúster WSFC: el clúster necesita una dirección IP especial, ya la funcionalidad actual de Azure asignaría el nombre del clúster a la misma dirección IP que el nodo donde se ha creado dicho clúster. Este comportamiento significa que se debe realizar un paso manual para asignar una dirección IP diferente a la del clúster.
• El agente de escucha de grupo de disponibilidad se va a crear en Azure con puntos de conexión TCP/IP asignados a las máquinas virtuales que ejecutan las réplicas principal y secundarias del grupo de disponibilidad.
• Puede que haya que proteger estos puntos de conexión con ACL.

A continuación encontrará documentación detallada sobre cómo implementar AlwaysOn con SQL Server en máquinas virtuales de Azure:

• Introducción a los grupos de disponibilidad Always On de SQL Server en Azure Virtual Machines.
• Configuración de un grupo de disponibilidad AlwaysOn en máquinas virtuales de Azure en distintas regiones.
• Configuración de un equilibrador de carga para un grupo de disponibilidad AlwaysOn en Azure.

SQL Server AlwaysOn es la funcionalidad de alta disponibilidad y de recuperación ante desastres de uso más común en Azure para las implementaciones de carga de trabajo de SAP. La mayoría de los clientes usan AlwaysOn para la alta disponibilidad en una única región de Azure. Si la implementación está restringida a solo dos nodos, tiene dos opciones de conectividad:

• Usar el agente de escucha de grupo de disponibilidad. Con el agente de escucha del grupo de disponibilidad, deberá implementar un equilibrador de carga de Azure.
• Usar SQL Server 2019 CU8 o versiones más recientes donde puede usar el cliente de escucha DNN en su lugar. Esto eliminará el requisito de usar un equilibrador de carga de Azure.
• Usar los parámetros de conectividad de creación de reflejo de la base de datos de SQL Server. En este caso, deberá configurar la conectividad de las aplicaciones de SAP de manera que se denominen ambos nombres de nodo. En la nota de SAP #965908 se documenta la información exacta de dicha configuración de SAP. Con esta opción no tendría que configurar ningún agente de escucha del grupo de disponibilidad y, con eso, ningún equilibrador de carga de Azure para la alta disponibilidad de SQL Server. Pero debe recordar que esta opción solo funciona si restringe el grupo de disponibilidad para que abarque dos instancias.

Algunos clientes usan la funcionalidad AlwaysOn de SQL Server para la funcionalidad de recuperación ante desastres entre regiones de Azure. Muchos clientes también usan la capacidad de realizar copias de seguridad desde una réplica secundaria.

Cifrado de datos transparente de SQL Server

Muchos clientes usan el Cifrado de datos transparente (TDE) de SQL Server al implementar sus bases de datos de SQL Server de SAP en Azure. La funcionalidad de TDE de SQL Server es totalmente compatible con SAP (consulte la nota de SAP 1380493 #).

Aplicar el TDE de SQL Server

En los casos en que se efectúe una migración heterogénea desde otro DBMS, que se ejecuta en un entorno local, a Windows o SQL Server, que se ejecuta en Azure, se debería crear de antemano una base de datos de destino vacía en SQL Server. El siguiente paso sería aplicaría la funcionalidad de TDE de SQL Server mientras se sigue ejecutando el sistema de producción de forma local. El motivo de seguir esta secuencia es que el proceso de cifrado de la base de datos vacía puede tardar bastante. Luego, los procesos de importación SAP importarían los datos a la base de datos cifrada durante la fase de tiempo de inactividad. La sobrecarga de la importación a una base de datos cifrada tiene un impacto temporal mucho menor de manera que el cifrado de la base de datos después de la fase de exportación en la fase de tiempo de inactividad. Se han dado experiencias negativas al intentar aplicar TDE con la carga de trabajo de SAP en ejecución en la base de datos. Por lo tanto, se recomienda tratar la implementación de TDE como una actividad que debe llevarse a cabo sin ninguna carga de trabajo de SAP en la base de datos concreta.

En casos en los que se mueven bases de datos de SQL Server de SAP desde una ubicación local hasta Azure, se recomienda probar en qué infraestructura se puede aplicar con mayor rapidez el cifrado. Respecto a esto, debe tener en cuenta estos factores:

• No puede definir la cantidad de subprocesos que se usan para aplicar el cifrado de datos a la base de datos. El número de subprocesos depende principalmente del número de volúmenes de disco por los que se distribuyen los datos y los archivos de registro de SQL Server. Significa que, cuantos más diferentes sean los volúmenes (letras de unidad), más subprocesos se ocuparán en paralelo para realizar el cifrado. Esta configuración se contradice un poco con una sugerencia anterior sobre la configuración de disco según la cual se crea uno o unos pocos espacios de almacenamiento para los archivos de base de datos de SQL Server en las máquinas virtuales de Azure. Una configuración con pocos volúmenes daría lugar a pocos subprocesos que ejecutan el cifrado. Un cifrado de un único subproceso lee extensiones de 64 KB, las cifra y, después, escribe un registro en el archivo de registro de transacciones indicando que se ha cifrado la extensión. Como resultado, la carga en el registro de transacciones es moderada.
• En versiones anteriores de SQL Server, la compresión de copia de seguridad ya no implicaba eficacia alguna al cifrar la base de datos de SQL Server. Este comportamiento podría convertirse en un problema si su idea era cifrar la base de datos de SQL Server de forma local y, después, copiar una copia de seguridad en Azure para restaurar la base de datos en Azure. La compresión de copia de seguridad de SQL Server suele generar una razón de compresión de factor 4.
• Con SQL Server 2016, SQL Server introdujo una nueva funcionalidad que también permite comprimir bases de datos cifradas de una forma eficiente. Consulte este blog para obtener información detallada.

Si solo trata la aplicación del cifrado de TDE con poca o ninguna carga de trabajo de SAP, debería efectuar pruebas en su configuración específica sobre si es mejor aplicar el TDE a la base de datos de SAP local o aplicarlo a Azure. En Azure sin duda tiene más flexibilidad en términos de exceso de aprovisionamiento de infraestructura y de reducir la infraestructura una vez aplicado el TDE.

Uso de Azure Key Vault

Azure ofrece el servicio de un almacén de claves para almacenar claves de cifrado. Por otro lado, SQL Server ofrece un conector para usar Azure Key Vault como almacén para los certificados de TDE.

A continuación tiene más información detallada sobre cómo usar Azure Key Vault para el TDE de SQL Server:

• Administración extensible de claves mediante Azure Key Vault (SQL Server).
• Pasos de configuración de Administración extensible de claves de TDE de SQL Server mediante Azure Key Vault.
• Mantenimiento y solución de problemas del Conector de SQL Server.
• Más preguntas de los clientes sobre el cifrado de datos transparente de SQL Server – TDE + Azure Key Vault.

Resumen general de SQL Server para SAP en Azure

En esta guía se ofrecen muchas recomendaciones: le sugerimos que la lea más de una vez antes de planear la implementación de Azure. En general, asegúrese de seguir las principales recomendaciones específicas de DBMS en Azure:

1. Use la versión de DBMS más reciente, como SQL Server 2017, que presenta la mayoría de las ventajas de Azure.
2. Planee cuidadosamente su infraestructura de sistema SAP en Azure para equilibrar el diseño del archivo de datos y las restricciones de Azure:
   • No disponga de un número de discos demasiado elevado, solo el suficiente para asegurarse de que puede alcanzar los IOPS necesarios.
   • Si no utiliza Managed Disks, recuerde que los valores de IOPS también están limitados por cuenta de Azure Storage y que las cuentas de Storage están limitadas en cada suscripción de Azure (más información).
   • Cree secciones en los discos solo si necesita obtener un mayor rendimiento.
3. Nunca instale software o coloque los archivos que requieren persistencia en la unidad D:, ya que no es permanente y todos los datos que albergue se pierden tras reiniciar Windows.
4. No utilice el almacenamiento en caché de disco para Azure Standard Storage.
5. No use cuentas de Azure Standard Storage con replicación geográfica de Azure. Use la redundancia local para las cargas de trabajo de DBMS.
6. Utilice la solución de alta disponibilidad o recuperación ante desastres de su proveedor de DBMS para replicar datos de base de datos.
7. Use siempre la resolución de nombres, no confíe exclusivamente en las direcciones IP.
8. Con el TDE de SQL Server, aplique las revisiones más recientes de SQL Server.
9. Use el nivel de compresión de base de datos más elevado posible. Qué es la comprensión de página de SQL Server.
10. Tenga cuidado al utilizar imágenes de SQL Server de Azure Marketplace. Si lo hace, debe cambiar la intercalación de la instancia antes de instalar cualquier sistema SAP NetWeaver en ella.
11. Instale y configure la funcionalidad de supervisión de hosts de SAP para Azure tal y como se describe en la Guía de implementación.

Pasos siguientes

Lea el artículo

• Consideraciones para la implementación de DBMS de Azure Virtual Machines para la carga de trabajo de SAP