Consideraciones de diseño de SQL Server

System Center Operations Manager se basa en Microsoft SQL Server para admitir sus bases de datos operativas, de almacenamiento de datos y de auditoría de ACS. Estas bases de datos son esenciales y se crean durante la implementación del primer servidor de administración o recopilador de ACS en el grupo de administración.

En un entorno de laboratorio o una implementación a pequeña escala de Operations Manager, SQL Server se puede colocar en el primer servidor de administración del grupo de administración.

En una implementación distribuida a escala mediana a empresarial, la instancia de SQL Server debe encontrarse en un servidor independiente dedicado o en una configuración de alta disponibilidad de SQL Server. En cualquier caso, SQL Server ya debe existir y ser accesible antes de comenzar la instalación del primer servidor de administración o del recopilador de ACS.

No se recomienda el uso de bases de datos de Operations Manager desde una instancia de SQL que tenga otras bases de datos de aplicación para evitar posibles problemas con la E/S y otras restricciones de recursos de hardware.

Importante

Operations Manager no admite instancias de plataforma como servicio (PaaS) de SQL, incluidos productos como Azure SQL Managed Instance o Amazon Relational Database Service (AWS RDS). Usa una instancia de SQL Server instalada en una máquina Windows. La única excepción a esto se encuentra en la Instancia administrada de Azure Monitor SCOM, que usa Azure SQL MI y no es reconfigurable.

Requisitos de SQL Server

Se admiten las siguientes versiones de SQL Server Enterprise y Standard Edition para una instalación existente de la versión de System Center Operations Manager para hospedar bases de datos del servidor de informes, operativas, de almacenamiento de datos y ACS:

• SQL Server 2022 con una actualización acumulativa mínima 11 (CU11) o una actualización posterior como disponible aquí
• SQL Server 2019 con una actualización acumulativa mínima 8 (CU8) o una actualización posterior como está disponible aquí
• SQL Server 2017 con la actualización disponible más reciente como disponible aquí

Antes de actualizar SQL Server, consulte la información de actualización para las versiones posteriores de 2017 y la información de actualización de SQL 2019.

Controladores de SQL Server

Los controladores OLE DB y ODBC SQL Server deben instalarse en todos los servidores de administración y en el servidor de consola web, ya que estos componentes interactúan directamente con las bases de datos y estos controladores permiten el acceso de nivel de API a SQL.

Se recomienda utilizar una conexión cifrada de SQL Server; al hacerlo, debe instalar las versiones más recientes de los controladores SQL:

• Versión más reciente del controlador OLE DB de Microsoft.
• Versión más reciente de Microsoft ODBC Driver .

Puede encontrar más información sobre cómo configurar el cifrado de conexión SQL aquí: Configuración de sql Server Motor de base de datos para cifrar conexiones

Si no usa conexiones SQL cifradas, use versiones anteriores de los controladores SQL que no aplican cifrado:

• Microsoft ODBC Driver versión 17.10.6.
• Microsoft OLE DB Driver , versión 18.7.4.

Actualizaciones de SQL Server

Cada uno de los siguientes componentes de SQL Server que admiten una infraestructura de Operations Manager debe estar en la misma versión principal de SQL Server:

• Instancias del motor de base de datos de SQL Server que hospedan cualquiera de las bases de datos de Operations Manager, entre las que se incluyen:
  • OperationManager
  • OperationManagerDW
  • Bases de datos de SSRS ReportServer y ReportServerTempDB
• Instancia de SQL Server Reporting Services (SSRS).

Modo de autenticación de SQL Server

De forma predeterminada, SQL funciona en una configuración de autenticación en modo mixto. Sin embargo, Operations Manager solo utiliza autenticación de Windows para comunicarse con SQL Server. Si se deja de forma predeterminada, la configuración autenticación en modo mixto de SQL seguirá funcionando si ninguna cuenta local tiene el db_owner rol. Se sabe que las cuentas locales con el db_owner rol provocan problemas con Operations Manager.

Se recomienda quitar el db_owner rol de todas las cuentas locales antes de instalar el producto y no agregar el rol a ninguna cuenta local después de la db_owner instalación.

Otras consideraciones

Otras consideraciones de hardware y software se aplican en el planeamiento de diseño:

• Se recomienda tener discos SQL en formato de archivo NTFS.
• Debe tener al menos 1 GB de espacio libre en disco para la base de datos operativa y de almacenamiento de datos, que se aplica en el momento de la creación de la base de datos. Tenga en cuenta que el uso del disco de las bases de datos aumentará significativamente después de la instalación, asegúrese de tener un montón de espacio libre en disco por encima de este requisito base.
• Se requiere .NET Framework 4.
• .NET Framework 4.8 se admite desde Operations Manager 2022.
• No se admite la instalación del servidor de informes en Windows Server Core.
• La configuración de intercalación de SQL Server debe ser uno de los tipos admitidos, tal como se describe en la sección: Configuración de intercalación de SQL Server.
• La búsqueda de texto completo de SQL Server es necesaria para todas las instancias del motor de base de datos de SQL Server que hospedan cualquiera de las bases de datos de Operations Manager.
• Las opciones de instalación de Windows Server (Server Core, Server con experiencia de escritorio y Nano Server) compatibles con los componentes de base de datos de Operations Manager se basan en qué opciones de instalación son compatibles con SQL Server.

Para obtener más información, consulte la sección Requisitos de hardware y software en la documentación de instalación y planeación de SQL Server aquí: Planear una instalación de SQL Server

Configuración de intercalación de SQL Server

Las siguientes intercalaciones de SQL Server y Windows se admiten en System Center Operations Manager.

Nota:

Para evitar problemas de compatibilidad al comparar o copiar operaciones, se recomienda usar la misma intercalación para la base de datos de SQL y Operations Manager.

Intercalación de SQL Server

• SQL_Latin1_General_CP1_CI_AS

Intercalación de Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Si la instancia de SQL Server no está configurada con una de las intercalaciones admitidas enumeradas anteriormente, se produce un error al realizar una nueva configuración de Operations Manager. Sin embargo, una actualización local se completa correctamente.

Configuración de firewall

Operations Manager depende de SQL Server para hospedar sus bases de datos y una plataforma de informes para analizar y presentar datos operativos históricos. Los roles de servidor de administración, operaciones y consola web deben poder comunicarse correctamente con SQL Server y es importante comprender la ruta de comunicación y los puertos para configurar el entorno correctamente.

Si diseña una implementación distribuida que usa grupos de disponibilidad AlwaysOn de SQL, hay opciones de configuración de firewall adicionales que deben incluirse en la estrategia de seguridad del firewall.

En la tabla siguiente se identifican los puertos de firewall requeridos por SQL Server para que los servidores de administración se comuniquen con las bases de datos:

Escenario	Port	Dirección	Rol de Operations Manager
SQL Server que hospeda bases de datos de Operations Manager	TCP 1433 *	Entrada	servidor de administración y consola web (para Application Advisor y Diagnóstico de aplicaciones)
servicio SQL Server Browser	UDP 1434	Entrada	servidor de administración
Conexión de administración dedicada de SQL Server	TCP 1434	Entrada	servidor de administración
Otros puertos usados por SQL Server - Llamadas a procedimiento remoto de Microsoft (MS RPC) - Instrumental de administración de Windows (WMI) - Coordinador de transacciones distribuidas de Microsoft (MS DTC)	TCP 135	Entrada	servidor de administración
Escucha de grupo de disponibilidad Always On de SQL Server.	Puerto configurado de administrador	Entrada	servidor de administración
SQL Server Reporting Services que hospeda Operations Manager Reporting Server	TCP 80 (valor predeterminado)/443 (SSL)	Entrada	servidor de administración y consola del operador

Nota:

Aunque TCP 1433 es el puerto estándar para la instancia predeterminada del Motor de base de datos, cuando se crea una instancia con nombre en un servidor SQL Server independiente o se ha implementado un grupo de disponibilidad AlwaysOn de SQL, se define un puerto personalizado y se debe documentar como referencia para que configure correctamente los firewalls y escriba esta información durante la instalación.

Para obtener información general más detallada sobre los requisitos de firewall para SQL Server, consulta Configuración de firewall de Windows para permitir el acceso a SQL Server.

Consideraciones sobre capacidad y almacenamiento

Base de datos de Operations Manager

La base de datos de Operations Manager es una base de datos de SQL Server que contiene todos los datos que necesita Operations Manager para la supervisión diaria. El dimensionamiento y la configuración del servidor de bases de datos es crítico para el rendimiento general del grupo de administración. El recurso más crítico que usa la base de datos de Operations Manager es el subsistema de almacenamiento, pero la CPU y la RAM también son importantes.

Los factores que influyen en la carga en la base de datos de Operations Manager incluyen:

• Tasa de recopilación de datos operativos.
  • La tasa de recopilación de datos operativos se ve afectada por factores como el número de módulos de administración importados, el número de agentes agregados y el tipo de equipo que se está supervisando. Por ejemplo, un agente que supervisa un equipo de escritorio crítico para la empresa recopila menos datos en comparación con un agente que supervisa un servidor que ejecuta SQL Server con varias bases de datos.
• Tasa de cambios de espacio de instancia.
  • La actualización de los datos existentes en la base de datos de Operations Manager consume muchos recursos en comparación con la escritura de nuevos datos operativos. Además, cuando hay cambios en los datos del espacio de instancia, los servidores de administración deben realizar más consultas en la base de datos para calcular la configuración y agrupar los cambios. La tasa de cambios de espacio de instancia aumenta al importar nuevos módulos de administración o agregar nuevos agentes al grupo de administración.
• El número de consolas del operador y otras conexiones del SDK que se ejecutan simultáneamente también afecta a la carga en la base de datos.
  • Cada consola del operador lee datos de la base de datos de Operations Manager. La consulta de estos datos consume potencialmente grandes cantidades de recursos de E/S de almacenamiento, tiempo de CPU y RAM. Las consolas de operaciones que muestran grandes cantidades de datos operativos en la vista eventos, la vista estado, la vista alertas y la vista de datos de rendimiento tienden a provocar la mayor carga en la base de datos.

La base de datos de Operations Manager es un único origen de error para el grupo de administración, por lo que se puede hacer de alta disponibilidad mediante configuraciones de conmutación por error admitidas, como grupos de disponibilidad AlwaysOn de SQL Server o instancias de clúster de conmutación por error.

Puede configurar y actualizar bases de datos de Operations Manager con una configuración Always On de SQL sin necesidad de realizar cambios posteriores a la configuración.

Habilitación de SQL Broker en la base de datos de Operations Manager

System Center Operations Manager depende de SQL Server Service Broker para implementar todas las operaciones de tareas. Si SQL Server Service Broker está deshabilitado, todas las operaciones de tareas se ven afectadas. El comportamiento resultante puede variar según la tarea iniciada. Por lo tanto, es importante comprobar el estado de SQL Server Service Broker siempre que se observe un comportamiento inesperado en torno a una tarea en System Center Operations Manager.

Para habilitar SQL Server Service Broker, sigue estos pasos.

1. Ejecute la siguiente consulta SQL para comprobar si el agente ya está habilitado, indicado por un resultado de 1 (uno) en el is_broker_enabled campo:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Si el valor que se muestra en el is_broker_enabled campo es 0 (cero), ejecute la siguiente instrucción SQL para habilitar el agente:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Base de datos de Almacenamiento de datos de Operations Manager

Nota:

El almacenamiento de datos de Operations Manager también se conoce como la base de datos "Almacenamiento de datos de informes" o simplemente "Almacenamiento de datos" en alguna documentación.

System Center Operations Manager inserta datos en el almacenamiento de datos casi en tiempo real, es importante tener suficiente capacidad en este servidor que admita la escritura de todos los datos que se recopilan en el almacenamiento de datos. Al igual que con la base de datos de Operations Manager, el recurso más crítico en el almacenamiento de datos es el subsistema de E/S de almacenamiento. En la mayoría de los sistemas, las cargas en el almacenamiento de datos son similares a la base de datos de Operations Manager, pero pueden variar. Además, la carga de trabajo puesta en el almacenamiento de datos mediante informes es diferente de la carga puesta en la base de datos de Operations Manager por uso de la consola del operador.

Los factores que influyen en la carga en el almacenamiento de datos incluyen:

• Tasa de recopilación de datos operativos.
  • El almacenamiento de datos realiza cálculos y almacena datos agregados, junto con una cantidad limitada de datos sin procesar, para permitir informes más eficaces. Como resultado, el costo de recopilar datos operativos en el almacenamiento de datos es ligeramente mayor en comparación con la base de datos de Operations Manager. Sin embargo, este costo se compensa con el costo de procesamiento reducido de los datos de detección en el almacenamiento de datos en comparación con la base de datos de Operations Manager.
• Número de usuarios de informes simultáneos o generación de informes programada.
  • Cada usuario de informes puede agregar una carga significativa en el sistema porque los informes suelen resumir grandes volúmenes de datos. Las necesidades generales de capacidad se ven afectadas por el número de informes que se ejecutan simultáneamente y el tipo de informes que se ejecutan. Informes que consultan intervalos de fechas grandes o un gran número de objetos requieren recursos adicionales del sistema.

En función de estos factores, hay varias prácticas recomendadas que se deben tener en cuenta al cambiar el tamaño del almacenamiento de datos:

• Elige un subsistema de almacenamiento adecuado.
  • Dado que el almacenamiento de datos es una parte integral del flujo de datos general a través del grupo de administración, es importante elegir un subsistema de almacenamiento adecuado para el almacenamiento de datos. Al igual que con la base de datos de Operations Manager, RAID 0 + 1 suele ser la mejor opción. En general, el subsistema de almacenamiento para el almacenamiento de datos debe ser similar al subsistema de almacenamiento de la base de datos de Operations Manager y las instrucciones que se aplican a la base de datos de Operations Manager también se aplican al almacenamiento de datos.
• Considera la colocación adecuada de los registros de datos frente a los registros de transacciones.
  • En cuanto a la base de datos de Operations Manager, separar los datos SQL y los registros de transacciones suele ser una opción adecuada a medida que se escala verticalmente el número de agentes. Si la base de datos y el almacenamiento de datos de Operations Manager se encuentran en el mismo servidor y desea separar los datos y los registros de transacciones, debe colocar los registros de transacciones para la base de datos de Operations Manager en un volumen físico independiente y los spindles de disco del almacenamiento de datos para recibir cualquier ventaja. Los archivos de datos de la base de datos y el almacenamiento de datos de Operations Manager pueden compartir el mismo volumen físico siempre que el volumen proporcione una capacidad adecuada y el rendimiento de E/S de disco no afecte negativamente a la funcionalidad de supervisión e informes.
• Considere la posibilidad de colocar el almacenamiento de datos en un servidor independiente de la base de datos de Operations Manager.
  • Aunque las implementaciones a menor escala a menudo pueden consolidar la base de datos y el almacenamiento de datos de Operations Manager en el mismo servidor, es ventajoso separarlas a medida que se escala verticalmente el número de agentes y el volumen de datos operativos entrantes. Cuando el almacenamiento de datos y el servidor de informes están en un servidor independiente de la base de datos de Operations Manager, experimentará un mejor rendimiento de informes.

La base de datos de Almacenamiento de datos de Operations Manager es un único origen de error para el grupo de administración, por lo que se puede hacer de alta disponibilidad mediante configuraciones de conmutación por error admitidas, como grupos de disponibilidad AlwaysOn de SQL Server o instancias de clúster de conmutación por error.

SQL Server AlwaysOn

Los grupos de disponibilidad SQL Server Always On admiten entornos de conmutación por error para un conjunto discreto de bases de datos de usuario (bases de datos de disponibilidad). Cada conjunto de bases de datos de disponibilidad se hospeda en una réplica de disponibilidad.

Con System Center 2016 y versiones posteriores: Operations Manager, es preferible SQL Always On a agrupación de clústeres de conmutación por error para proporcionar alta disponibilidad para las bases de datos. Todas las bases de datos excepto la instalación de Reporting Services en modo nativo, que usa dos bases de datos para separar el almacenamiento de datos persistente de los requisitos de almacenamiento temporal, se pueden hospedar en un grupo de disponibilidad Always On.

Para configurar un grupo de disponibilidad, implemente un clúster de clústeres de conmutación por error de Windows Server (WSFC) para hospedar la réplica de disponibilidad y habilite AlwaysOn en los nodos del clúster. Entonces, puedes agregar la base de datos de SQL Server de Operations Manager como base de datos de disponibilidad.

• Más información sobre los requisitos previos de Always On.
• Más información sobre cómo configurar un WSFC para grupos de disponibilidad Always On.
• Más información sobre cómo configurar un grupo de disponibilidad.

Sugerencia

A partir de Operations Manager 2022, puede configurar y actualizar bases de datos de Operations Manager con una configuración always-On de SQL existente sin necesidad de realizar cambios posteriores a la configuración.

Para configurar un grupo de disponibilidad, implemente un clúster de clústeres de conmutación por error de Windows Server (WSFC) para hospedar la réplica de disponibilidad y habilite AlwaysOn en los nodos del clúster. Entonces, puedes agregar la base de datos de SQL Server de Operations Manager como base de datos de disponibilidad.

• Más información sobre los requisitos previos de Always On.
• Más información sobre cómo configurar un WSFC para grupos de disponibilidad Always On.
• Más información sobre cómo configurar un grupo de disponibilidad.

Nota:

Después de implementar Operations Manager en los nodos de SQL Server que participan en SQL Always On, para habilitar CLR strict security, ejecuta el script SQL en cada base de datos de Operations Manager.

Cadena de varias subredes

Operations Manager no admite las cadena de conexión palabras clave (MultiSubnetFailover=True). Dado que un grupo de disponibilidad tiene un nombre de cliente de escucha (conocido como nombre de red o punto de acceso de cliente en el Administrador de clústeres de WSFC) en función de varias direcciones IP de diferentes subredes, como cuando se implementa en una configuración de conmutación por error entre sitios, las solicitudes de conexión de cliente de los servidores de administración al cliente de escucha de grupo de disponibilidad alcanzarán un tiempo de espera de conexión.

El enfoque recomendado para solucionar esta limitación con los nodos de servidor del grupo de disponibilidad implementados en un entorno de varias subredes es:

1. Establece el nombre de red del cliente de escucha de grupo de disponibilidad para registrar solo una sola dirección IP activa en DNS.
2. Configura el clúster para usar un valor TTL bajo para el registro DNS registrado.

Esta configuración permite una recuperación y resolución más rápidas del nombre del clúster con la nueva dirección IP al conmutar por error a un nodo de otra subred.

Ejecute los siguientes comandos de PowerShell en cualquiera de los nodos SQL para modificar esta configuración:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Si usas Always On con un nombre de cliente de escucha, también debes realizar estos cambios de configuración en el cliente de escucha. Para obtener más información sobre cómo configurar un agente de escucha de grupo de disponibilidad, consulte la documentación aquí: Configuración del agente de escucha del grupo de disponibilidad: SQL Server AlwaysOn.

Los siguientes comandos de PowerShell se pueden ejecutar en el nodo SQL que hospeda actualmente el agente de escucha para modificar su configuración:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Cuando se usa una instancia de SQL Always On o en clúster para alta disponibilidad, debe habilitarse la característica de recuperación automática en los servidores de administración para evitar que el servicio de acceso a datos de Operations Manager se reinicie siempre que se produzca una conmutación por error entre nodos. Para obtener información sobre la configuración, consulte el siguiente artículo de KB El servicio de administración de System Center deja de responder después de que una instancia de SQL Server se desconecte.

Optimización de SQL Server

Las experiencias de soporte técnico han demostrado que los problemas de rendimiento no suelen deberse a un uso elevado de recursos (es decir, procesador o memoria) con SQL Server; en su lugar, el problema está directamente relacionado con la configuración del subsistema de almacenamiento. Los cuellos de botella de rendimiento se suelen atribuir a no seguir la guía de configuración recomendada con el almacenamiento aprovisionado para la instancia de base de datos de SQL Server. Dichos ejemplos son:

• Asignación insuficiente de ejes para los LUN para admitir los requisitos de E/S de Operations Manager.
• Hospedaje de registros de transacciones y archivos de base de datos en el mismo volumen. Estas dos cargas de trabajo tienen características de E/S y latencia diferentes.
• La configuración de TempDB es incorrecta con respecto a la colocación, el dimensionamiento, etc.
• Desalineación de particiones de disco de los volúmenes que hospedan los registros de transacciones de base de datos, los archivos de base de datos y TempDB.
• Omisión de la configuración básica de SQL Server, como el uso de AUTOGROW para archivos de registro de transacciones y bases de datos, la configuración MAXDOP para paralelismo de consultas, la creación de varios archivos de datos tempDB por núcleo de CPU, etc.

La configuración de almacenamiento es uno de los componentes críticos para una implementación de SQL Server para Operations Manager. Los servidores de bases de datos tienden a estar muy enlazados a E/S debido a una rigurosa actividad de lectura y escritura de base de datos y procesamiento del registro de transacciones. El patrón de comportamiento de E/S de Operations Manager suele ser del 80 % de escrituras y el 20 % de lecturas. Como resultado, una configuración incorrecta de subsistemas de E/S puede dar lugar a un rendimiento y funcionamiento deficientes de los sistemas de SQL Server y se vuelve notable en Operations Manager.

Es importante probar el diseño de SQL Server realizando pruebas de rendimiento del subsistema de E/S antes de implementar SQL Server. Asegúrate de que estas pruebas pueden lograr los requisitos de E/S con una latencia aceptable. Usa la utilidad Diskspd para evaluar la capacidad de E/S del subsistema de almacenamiento que admite SQL Server. En el siguiente artículo de blog, creado por un miembro del equipo del servidor de archivos del grupo de productos, se proporcionan instrucciones detalladas y recomendaciones sobre cómo realizar pruebas de esfuerzo mediante esta herramienta: DiskSpd, PowerShell y rendimiento de almacenamiento: medición de E/SPS, rendimiento y latencia para discos locales y recursos compartidos de archivos SMB.

Tamaño de la unidad de asignación de NTFS

La alineación del volumen, comúnmente denominada alineación del sector, debe realizarse en el sistema de archivos (NTFS) cada vez que se crea un volumen en un dispositivo RAID. Si no se hace, se puede provocar una degradación significativa del rendimiento y suele ser el resultado de la desalineación de particiones con límites de unidad de sección. También puede provocar desalineación de caché de hardware, lo que da lugar a un uso ineficaz de la caché de matriz.

Al aplicar formato a la partición usada para los archivos de datos de SQL Server, la recomendación es usar un tamaño de unidad de asignación de 64 KB (es decir, 65 536 bytes) para datos, registros y TempDB. Sin embargo, tenga en cuenta que el uso de tamaños de unidad de asignación mayores de 4 KB da como resultado la incapacidad de usar la compresión NTFS en el volumen. Aunque SQL Server admite datos de solo lectura en volúmenes comprimidos, no se recomienda.

Reservar memoria

Nota:

Gran parte de la información de esta sección procede de Jonathan Kehayias en su entrada de blog How much memory does my SQL Server actually need? (sqlskills.com).

No siempre es fácil identificar la cantidad correcta de memoria física y procesadores para asignar a SQL Server y admitir System Center Operations Manager (o para otras cargas de trabajo fuera de este producto). La calculadora de dimensionamiento que proporciona el grupo de productos ofrece instrucciones basadas en la escala de cargas de trabajo, pero sus recomendaciones se basan en las pruebas realizadas en un entorno de laboratorio que puede o no alinearse con la carga de trabajo y la configuración reales.

SQL Server permite configurar la cantidad mínima y máxima de memoria que se reservará y usará en su proceso. De forma predeterminada, SQL Server puede cambiar sus requisitos de memoria de manera dinámica basándose en los recursos del sistema disponibles. La configuración predeterminada para memoria mínima del servidor es 0 y para memoria máxima del servidor es 2147483647 MB.

Pueden producirse problemas relacionados con el rendimiento y la memoria si no se establece un valor adecuado para memoria máxima del servidor. Muchos factores influyen en la cantidad de memoria que necesitas asignar a SQL Server para garantizar que el sistema operativo pueda admitir otros procesos que se ejecutan en ese sistema, como la tarjeta HBA, los agentes de administración y el examen antivirus en tiempo real. Si no se establece suficiente memoria, el sistema operativo y SQL se paginarán en el disco. Esto puede hacer que la E/S de disco aumente, disminuyendo aún más el rendimiento y creando un efecto de ondas en el que se vuelve notable en Operations Manager.

Se recomienda especificar al menos 4 GB de RAM para memoria mínima del servidor. Esto debe hacerse para cada nodo SQL que hospeda una de las bases de datos de Operations Manager (operativa, almacenamiento de datos, ACS).

Para memoria máxima del servidor, se recomienda reservar inicialmente un total de:

• 1 GB de RAM para el sistema operativo
• 1 GB de RAM por cada 4 GB de RAM instalado (hasta 16 GB de RAM)
• 1 GB de RAM por cada 8 GB de RAM instalado (por encima de 16 GB de RAM)

Después de establecer estos valores, supervisa el contador Memoria\MBytes disponibles en Windows para determinar si puedes aumentar la memoria disponible para SQL Server. Windows indica que la memoria física disponible se está ejecutando bajo en 96 MB, por lo que idealmente el contador no debe ejecutarse inferior a unos 200-300 MB, para asegurarse de que tiene un búfer. En el caso de los servidores con RAM de 256 GB o superior, asegúrese de que no se ejecuta por debajo de 1 GB.

Ten en cuenta que estos cálculos suponen que quieres que SQL Server pueda usar toda la memoria disponible, a menos que la modifique para tener en cuenta otras aplicaciones. Considera los requisitos de memoria específicos para el sistema operativo, otras aplicaciones, la pila de subprocesos de SQL Server y otros asignadores de varias páginas. Una fórmula típica sería ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), donde la memoria de la pila de subprocesos = ((max worker threads) (stack size)). El tamaño de la pila es de 512 KB para sistemas x86, 2 MB para sistemas x64 y 4 MB para sistemas IA64, y puedes encontrar el valor de máximo de subprocesos de trabajo en la columna max_worker_count de sys.dm_os_sys_info.

Estas consideraciones también se aplican a los requisitos de memoria para que SQL Server se ejecute en una máquina virtual. Dado que SQL Server está diseñado para almacenar en caché los datos del grupo de búferes y usa la mayor cantidad de memoria posible, puede ser difícil determinar la cantidad ideal de RAM necesaria. Al reducir la memoria asignada a una instancia de SQL Server, puede llegar a un punto en el que se intercambia la asignación de memoria inferior para un mayor acceso de E/S de disco.

Para configurar la memoria de SQL Server en un entorno que se ha sobreaprovisionado, empieza por supervisar el entorno y las métricas de rendimiento actuales, incluida la duración prevista de la página SQL Server Buffer Manager y las lecturas de página/s y los valores de lecturas de disco/s de disco físico. Si el entorno tiene memoria excesiva, la duración prevista de la página aumentará en un valor de uno cada segundo sin ninguna disminución de la carga de trabajo, debido al almacenamiento en caché; el valor lecturas de página/s de SQL Server Buffer Manager será bajo después de que la memoria caché se incremente; y las lecturas de disco/s de disco físico también permanecerán bajas.

Una vez que comprendas la base de referencia del entorno, puedes reducir la memoria máxima del servidor en 1 GB y, después, ver cómo afecta a los contadores de rendimiento (después de que se reduzca el vaciado inicial de la memoria caché). Si las métricas siguen siendo aceptables, reduce en otro 1 GB y, luego, vuelve a supervisarlo, repitiendo según lo deseado hasta determinar una configuración ideal.

Para obtener más información, consulta Opciones de configuración de memoria del servidor.

Optimización de TempDB

El tamaño y la ubicación física de la base de datos TempDB pueden afectar al rendimiento de Operations Manager. Por ejemplo, si el tamaño definido para TempDB es demasiado pequeño, parte de la carga de procesamiento del sistema puede tomarse con tempDB de crecimiento automático al tamaño necesario para admitir la carga de trabajo cada vez que reinicie la instancia de SQL Server. Para lograr un rendimiento óptimo de TempDB, se recomienda la siguiente configuración para TempDB en un entorno de producción:

• Establezca el modelo de recuperación de TempDB en SIMPLE.
  • Este modelo reclama automáticamente el espacio de registro para mantener requisitos de espacio pequeños.
• Asigne espacio previamente para todos los archivos de TempDB estableciendo el tamaño de archivo en un valor lo suficientemente alto para acomodar la carga de trabajo habitual del entorno. Impide que TempDB se expanda con demasiada frecuencia, lo que puede afectar al rendimiento. La base de datos TempDB se puede establecer en crecimiento automático, pero se debe usar para aumentar el espacio en disco de las excepciones no planeadas.
• Crea tantos archivos como sea necesario para maximizar el ancho de banda de disco.
  • El uso de varios archivos reduce la contención de almacenamiento de TempDB y produce una escalabilidad mejorada. Sin embargo, no crees demasiados archivos, ya que pueden reducir el rendimiento y aumentar la sobrecarga de administración.
  • Como guía general, crea un archivo de datos para cada procesador lógico en el servidor (teniendo en cuenta cualquier configuración de máscara de afinidad) y, después, ajusta el número de archivos hacia arriba o hacia abajo según sea necesario.
  • Como regla general, si el número de procesadores lógicos es menor o igual a 8, use el mismo número de archivos de datos que procesadores lógicos.
    • Si el número de procesadores lógicos es superior a 8, utiliza 8 archivos de datos y, después, si la contención continúa, aumenta el número de archivos de datos en múltiplos de 4 (hasta el número de procesadores lógicos) hasta que la contención se reduzca a niveles aceptables, o bien, modifica el código o la carga de trabajo.
    • Si la contención no se reduce, es posible que tengas que aumentar más el número de archivos de datos.
• Haz que cada archivo de datos tenga el mismo tamaño, lo que permite un rendimiento óptimo de relleno proporcional.
  • El mismo dimensionamiento de los archivos de datos es crítico porque el algoritmo de relleno proporcional se basa en el tamaño de los archivos. Si los archivos de datos se crean con tamaños desiguales, el algoritmo de relleno proporcional intenta usar el archivo más grande para las asignaciones de GAM en lugar de distribuir las asignaciones entre todos los archivos, lo que anula el propósito de crear varios archivos de datos.
• Coloque la base de datos TempDB en un subsistema de E/S rápido mediante unidades de estado sólido para obtener el rendimiento más óptimo.
  • Cree bandas en disco si hay muchos discos conectados directamente.
• Coloque la base de datos TempDB en discos diferentes de los que utilizan las bases de datos de usuario.

Para configurar TempDB, puede ejecutar la consulta siguiente o modificar sus propiedades en Management Studio.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Ejecute la consulta SELECT * from sys.sysprocesses T-SQL para detectar la contención de asignación de páginas para la base de datos TempDB. En la salida de la tabla del sistema, el recurso de espera puede aparecer como "2:1:1" (página PFS) o "2:1:3" (página mapa de asignación global compartida). En función del grado de contención, esta configuración podría provocar que SQL Server no responda durante períodos cortos. Otro enfoque consiste en examinar las vistas de administración dinámica [sys.dm_exec_request o sys.dm_os_waiting_tasks]. Los resultados muestran que estas solicitudes o tareas están esperando recursos de TempDB y tienen valores similares como se resaltan anteriormente al ejecutar la sys.sysprocesses consulta.

Si las recomendaciones anteriores no reducen significativamente la contención de asignación y la contención está en páginas SGAM, implemente la marca -T1118 de seguimiento en los parámetros de inicio de SQL Server para que la marca de seguimiento permanezca en vigor incluso después de reciclar SQL Server. En esta marca de seguimiento, SQL Server asigna extensiones completas a cada objeto de base de datos, lo que elimina la contención en páginas SGAM.

Nota:

Esta marca de seguimiento afecta a todas las bases de datos de la instancia de SQL Server.

Grado de paralelismo máximo

Sugerencia

Para conocer los procedimientos recomendados y recomendaciones más recientes del equipo de SQL Server, consulte su documentación aquí: Establecer la opción grado máximo de paralelismo para obtener un rendimiento óptimo.

La configuración predeterminada de SQL Server para implementaciones de tamaño pequeño a mediano de Operations Manager es adecuada para la mayoría de las necesidades. Sin embargo, cuando la carga de trabajo del grupo de administración se escala hacia arriba hacia un escenario de clase empresarial (normalmente más de 2000 sistemas administrados por agentes y una configuración de supervisión avanzada, que incluye la supervisión de nivel de servicio con transacciones sintéticas avanzadas, supervisión de dispositivos de red, multiplataforma, etc.), es necesario optimizar la configuración de SQL Server descrita en esta sección del documento. Una opción de configuración no descrita en las instrucciones anteriores es MAXDOP.

La opción de configuración de grado de paralelismo máximo de Microsoft SQL Server (MAXDOP) controla el número de procesadores que se usan para la ejecución de una consulta en un plan paralelo. Esta opción determina los recursos de subproceso y computación que se usan para los operadores de plan de consulta que realizan el trabajo en paralelo. Dependiendo de si SQL Server está configurado en un equipo de multiprocesamiento simétrico (SMP), un equipo de acceso a memoria no uniforme (NUMA) o procesadores habilitados para hyperthreading, tiene que configurar la opción grado máximo de paralelismo de forma adecuada.

Cuando SQL Server se ejecuta en un equipo con más de un microprocesador o CPU, detecta el mejor grado de paralelismo, es decir, el número de procesadores que se emplea para ejecutar una única instrucción en cada ejecución de planes en paralelo. De forma predeterminada, su valor para esta opción es 0, lo que permite a SQL Server determinar el grado de paralelismo máximo.

Los procedimientos almacenados y las consultas predefinidas en Operations Manager en relación con la base de datos operativa, el almacenamiento de datos e incluso la base de datos de auditoría no incluyen la opción MAXDOP, ya que no hay ninguna manera durante la instalación para consultar dinámicamente cuántos procesadores se presentan al sistema operativo, ni intenta codificar de forma difícil el valor de esta configuración, lo que podría tener consecuencias negativas cuando se ejecuta la consulta.

Nota:

La opción de configuración grado de paralelismo máximo no limita el número de procesadores que usa SQL Server. Para configurar el número de procesadores que usa SQL Server, usa la opción de configuración de máscara de afinidad.

• Para los servidores que usan más de ocho procesadores, usa la siguiente configuración: MAXDOP=8

• Para los servidores que usan ocho o menos procesadores, use la siguiente configuración: MAXDOP=0 a N

  Sugerencia

  En esta configuración, N representa el número de procesadores.

• En el caso de los servidores que tienen NUMA configurado, MAXDOP no debe superar el número de CPU que se asignan a cada nodo NUMA.

• En el caso de los servidores que tienen habilitado hyperthreading, el valor MAXDOP no debe superar el número de procesadores físicos.

• En el caso de los servidores que tienen NUMA configurado e hyperthreading habilitado, el valor MAXDOP no debe superar el número de procesadores físicos por nodo NUMA.

Puede supervisar el número de trabajos paralelos consultando select * from sys.dm_os_tasks.

En este ejemplo, la configuración de hardware del servidor era un HP Blade G6 con 24 procesadores de núcleo y 196 GB de RAM. La instancia que hospeda la base de datos de Operations Manager tenía una configuración MAXMEM de 64 GB. Después de realizar las optimizaciones sugeridas en esta sección, se ha mejorado el rendimiento. Sin embargo, todavía se conserva un cuello de botella de paralelismo de consulta. Después de probar diferentes valores, se encontró el rendimiento más óptimo estableciendo MAXDOP=4.

Ajuste de tamaño inicial de la base de datos

Intentar calcular el crecimiento futuro de las bases de datos de Operations Manager, específicamente las bases de datos operativas y de almacenamiento de datos, en los primeros meses después de la implementación no es un ejercicio sencillo. Aunque el asistente de ajuste de tamaño de Operations Manager es razonable para estimar el crecimiento potencial en función de la fórmula derivada por el grupo de productos de sus pruebas en el laboratorio, no tiene en cuenta varios factores, lo que puede influir en el crecimiento a corto plazo frente a largo plazo.

El tamaño inicial de la base de datos, como sugiere el Asistente de ajuste de tamaño, debe asignarse a un tamaño previsto para reducir la fragmentación y la sobrecarga correspondiente, que se puede especificar en el momento de la instalación de las bases de datos operativas y de almacenamiento de datos. Si durante la instalación no hay suficiente espacio de almacenamiento disponible, las bases de datos se pueden expandir más adelante mediante SQL Management Studio y, a continuación, volver a indexar y optimizar en consecuencia. Esta recomendación también se aplica a la base de datos de ACS.

La supervisión proactiva del crecimiento de la base de datos operativa y de almacenamiento de datos debe realizarse en un ciclo diario o semanal. Esto es necesario para identificar los crecimientos inesperados y significativos, y comenzar a solucionar problemas con el fin de determinar la causalidad, ya sea por un error en un flujo de trabajo del módulo de administración (es decir, regla de detección, regla de rendimiento o regla de recopilación de eventos, o supervisión o regla de alerta) u otro síntoma con un módulo de administración que no se identificó durante las pruebas y la fase de control de calidad del proceso de administración de versiones.

Crecimiento automático de la base de datos

Cuando el tamaño del archivo de las bases de datos reservadas se llena, SQL Server puede aumentar automáticamente el tamaño por un porcentaje o por una cantidad fija. Además, se puede configurar un tamaño máximo de base de datos para evitar rellenar todo el espacio disponible en el disco. De forma predeterminada, la base de datos de Operations Manager no está configurada con el crecimiento automático habilitado; solo las bases de datos de ALMACENAMIENTO de datos y ACS son.

Solo se basan en el crecimiento automático como contingencia para un crecimiento inesperado. El crecimiento automático presenta una penalización de rendimiento que se debe tener en cuenta al tratar con una base de datos altamente transaccional. Las sanciones de rendimiento incluyen:

• Si no proporciona un incremento de crecimiento adecuado, puede producirse la fragmentación del archivo de registro o la base de datos.
• Si ejecuta una transacción que requiere más espacio de registro de lo que está disponible y el crecimiento automático está habilitado para el registro de transacciones de esa base de datos, el tiempo que tarda la transacción en completarse incluirá el tiempo que tarda el registro de transacciones en crecer por la cantidad configurada.
• Si ejecuta una transacción grande que requiere que el registro crezca, otras transacciones que requieren una escritura en el registro de transacciones también tendrán que esperar hasta que se complete la operación de crecimiento.

Si se combinan las opciones autogrow y autoshrink, esto puede crear una sobrecarga innecesaria. Asegúrese de que los umbrales que desencadenan las operaciones de crecimiento y reducción no provocarán cambios frecuentes en el tamaño. Por ejemplo, puede ejecutar una transacción que haga que el registro de transacciones crezca en 100 MB en el momento en que se confirma; algún tiempo después de que se inicie el autohrink y reduzca el registro de transacciones en 100 MB. A continuación, ejecuta la misma transacción y hace que el registro de transacciones crezca de nuevo en 100 MB. En ese ejemplo, va a crear una sobrecarga innecesaria y puede crear la fragmentación del archivo de registro, cualquiera de las cuales puede afectar negativamente al rendimiento.

Configure estos dos valores cuidadosamente. La configuración concreta depende realmente de su entorno. La recomendación general es aumentar el tamaño de la base de datos por una cantidad fija para reducir la fragmentación del disco. Vea, por ejemplo, la ilustración siguiente, donde la base de datos está configurada para crecer en 1024 MB cada vez que se requiere crecimiento automático.

Directiva de conmutación por error de clúster

Clústeres de conmutación por error de Windows Server es una plataforma de alta disponibilidad que supervisa constantemente las conexiones de red y el estado de los nodos de un clúster. Si no se puede acceder a un nodo a través de la red, se realiza la acción de recuperación para recuperar y poner aplicaciones y servicios en línea en otro nodo del clúster. La configuración predeterminada está optimizada para los errores en los que se produce una pérdida completa de un servidor, que se considera un error "difícil". Estos serían escenarios de error irrecuperables, como el error de hardware o energía no redundante. En estas situaciones, el servidor se pierde y el objetivo es que los clústeres de conmutación por error detecten rápidamente la pérdida del servidor y se recuperen rápidamente en otro servidor del clúster. Para lograr esta recuperación rápida de errores duros, la configuración predeterminada para la supervisión del estado del clúster es bastante agresiva. Sin embargo, son totalmente configurables para permitir la flexibilidad de varios escenarios.

Esta configuración predeterminada ofrece el mejor comportamiento para la mayoría de los clientes; Sin embargo, a medida que los clústeres se extienden de pulgadas a posiblemente a distancia, el clúster puede exponerse a más componentes de red entre los nodos y, posiblemente, poco confiables. Otro factor es que la calidad de los servidores de productos básicos aumenta constantemente, junto con resistencia aumentada a través de componentes redundantes (como fuentes de alimentación duales, formación de equipos NIC y E/S de múltiples rutas), el número de errores de hardware no redundantes puede ser bastante poco frecuente. Dado que los errores duros pueden ser menos frecuentes, es posible que algunos clientes deseen ajustar el clúster para los errores transitorios, donde el clúster es más resistente a breves errores de red entre los nodos. Al aumentar los umbrales de error predeterminados, puede reducir la sensibilidad a breves problemas de red que duran un breve período de tiempo.

Es importante comprender que no hay respuesta correcta aquí y que la configuración optimizada puede variar según sus requisitos empresariales específicos y acuerdos de nivel de servicio.

Virtualización de SQL Server

En entornos virtuales, por motivos de rendimiento, se recomienda almacenar la base de datos operativa y la base de datos de almacenamiento de datos en un almacenamiento conectado directamente y no en un disco virtual. Puede usar la utilidad Auxiliar de ajuste de tamaño de Operations Manager publicada para Operations Manager 2012 para calcular las IOPS necesarias y probar el esfuerzo de los discos de datos para comprobar. El rendimiento del almacenamiento se puede probar con la utilidad DiskSpd. Consulte también Compatibilidad con la virtualización de Operations Manager para obtener instrucciones adicionales sobre el entorno virtualizado de Operations Manager.

Modelo de recuperación y AlwaysOn

Aunque no es estrictamente una optimización, una consideración importante con respecto al grupo de disponibilidad AlwaysOn es el hecho de que, por diseño, esta característica requiere que las bases de datos se establezcan en el modelo de recuperación "Completa". Es decir, los registros de transacciones nunca se descartan hasta que se realiza una copia de seguridad completa o solo el registro de transacciones. Por este motivo, una estrategia de copia de seguridad no es opcional, sino una parte necesaria del diseño AlwaysOn para las bases de datos de Operations Manager. De lo contrario, con el tiempo, los discos que contienen registros de transacciones se rellenan.

Una estrategia de copia de seguridad debe tener en cuenta los detalles del entorno. En la tabla siguiente se ofrece una programación de copia de seguridad típica.

Tipo de copia de seguridad	Programación
Solo registro de transacciones	Cada una hora
Completo	Semanalmente, domingo a las 3:00 a. m.

Optimización de SQL Server Reporting Services

La instancia de Reporting Services actúa como proxy para el acceso a los datos de la base de datos de Almacenamiento de datos. Genera y muestra informes basados en plantillas almacenadas dentro de los módulos de administración.

El rol De informes de Operations Manager no se puede instalar en paralelo con una versión anterior del rol Informes y debe instalarse solo en modo nativo (no se admite el modo integrado de SharePoint).

En segundo plano de Reporting Services, hay una instancia de base de datos de SQL Server que hospeda las bases de datos ReportServer y ReportServerTempDB. Se aplican recomendaciones generales sobre el ajuste de rendimiento de esta instancia.

Nota:

En SQL Server Reporting Services (SSRS) 2017 versión 14.0.600.1274 y versiones posteriores, la configuración de seguridad predeterminada no permite cargas de extensiones de recursos. Esto conduce a extensiones de ResourceFileFormatNotAllowedException en Operations Manager durante la implementación de componentes de informes.

Para solucionar este error:

1. Abra SQL Management Studio.
2. Conéctese a la instancia de Reporting Services.
3. Haga clic con el botón derecho en la instancia del servidor en la ventana Explorador de objetos.
4. Selecciona Propiedades.
5. Seleccione Avanzadas en la barra lateral izquierda.
6. Agregue *.* a la lista de AllowedResourceExtensionsForUpload.

Como alternativa, puedes agregar la lista completa de extensiones de informes de Operations Manager a la lista de permitidos en SSRS. La lista se describe en "Resolución 2" aquí: Los informes de Operations Manager no se pueden implementar

Pasos siguientes

Para comprender cómo configurar el almacenamiento de datos de hospedaje (informes) detrás de un firewall, consulte Conexión del almacenamiento de datos (informes) a través de un firewall.