Optimización FIM y mejores prácticas de rendimiento

Para empezar, siga las mejores prácticas de su plataforma de virtualización. Por lo general, las prácticas recomendadas mejoran el rendimiento y la estabilidad. Los siguientes enlaces le guiarán hacia las recomendaciones de mejores prácticas:

• Performance Best Practices for VMware vSphere™ 5.5 (Prácticas recomendadas de rendimiento para VMware vSphere 5.5)
• Performance Best Practices for VMware vSphere™ 5.0 (Mejores prácticas de rendimiento para VMware vSphere™ 5.0)
• Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) (Mejores prácticas de Windows Server 2012 Hyper-V)

• Los servicios de integración deben instalarse en cada máquina virtual invitada
• Los servicios de integración deben tener la versión correcta para el hipervisor.

• Sobre-comprometer procesadores virtuales (asignar más núcleos de procesador al huésped de los que pueden estar disponibles de forma consistente debido al uso de otros procesos) puede crear latencia en el cumplimiento de las solicitudes en los sistemas de rendimiento. Por ejemplo, tener cuatro (4) máquinas virtuales con cuatro (4) procesadores cuando sólo hay ocho (8) núcleos.

Si necesita sobrecomprometer procesadores, por favor lea el siguiente punto (CPU Ready Time) para saber cómo detectar una condición de estancamiento.

• Revisar la Tiempo de preparación de la CPU (VMWare) o Procesador virtual\CPU Tiempo de espera por despacho (Hyper-V) de forma regular para garantizar que la solución no se paraliza esperando el tiempo del procesador.
  • Este post proporciona la siguiente orientación sobre el significado del contador CPU Ready Time:

• • El equivalente de Hyper-V al tiempo de preparación de la CPU de VMware (Kehayias, Hyper-V Equivalent to VMware CPU Ready Time, 2013.

• Los siguientes artículos proporcionan información adicional sobre el tema y son de buena lectura:
  • Sobrecompromiso de CPU y su impacto en el rendimiento de SQL Server en VMware (Klee, 2012)
  • SQL SERVER - vCPUs - ¿Cuántas son demasiadas CPU para la virtualización de SQL Server? - Notes from the Field #003 (SQL SERVER - vCPUs - ¿Cuántas CPU son demasiadas para la virtualización de SQL Server? - Notas del campo #003)

• La sobreasignación de memoria es una capacidad de virtualización útil cuando se utiliza correctamente. El sobrecompromiso debe evitarse en situaciones en las que los invitados de la VM tengan rutinariamente periodos prolongados en los que necesiten la RAM para propósitos de la aplicación. Sin embargo, SQL Server es una aplicación que probablemente utilice memoria durante largos periodos de tiempo y puede experimentar penalizaciones de rendimiento debido al intercambio.

Configurar correctamente el cliente antivirus puede reducir drásticamente el tiempo que los recursos están bloqueados mientras se realiza el escaneo en tiempo real. Utilice la siguiente información de configuración para mejorar el rendimiento reduciendo los tiempos de espera de los recursos bloqueados:

Las siguientes recomendaciones para configurar el cliente antivirus para el rol Hyper-V están tomadas de WINDOWS ANTIVIRUS EXCLUSION RECOMMENDATIONS (Helmick, 2014).

• Vmms.exe
• Vmwp.exe

• Todos los archivos VHD,VHDX,AVHD,VSV e ISO
  • *.vhd
  • *.vhdx
  • *.avhd
  • *.vsv
  • *.iso

• Directorio de configuración de la máquina virtual por defecto: C:\ProgramData\Microsoft\Windows\Hyper-V
• Directorios personalizados de configuración de máquinas virtuales
• Directorio por defecto de la unidad de disco duro virtual: C:\NUsuarios\Públicos\Documentos\Hyper-V\Discos Duros Virtuales
• Directorios personalizados de unidades de disco duro virtual
• Directorios de datos de replicación personalizados, si utiliza Hyper-V Replica.
• Directorios de instantáneas
• C:\Clusterstorage y todos los subdirectorios (si se utiliza Live Migration junto con Cluster Shared Volumes)

Nota: Las rutas mostradas a continuación son rutas por defecto y pueden haber sido modificadas en su instalación.

Las siguientes recomendaciones para configurar el cliente antivirus para la aplicación SQL están tomadas de RECOMENDACIONES DE EXCLUSIÓN DEL ANTIVIRUS DE WINDOWS (Helmick, 2014).

• %ProgramFiles%\Microsoft SQL Server\MSSQL11.<Instance Name>\MSSQL\Binn\SQLServr.exe

• %ProgramFiles%\Microsoft SQL Server\MSRS11.<Instance Name>\Reporting Services\ReportServer\Bin\ReportingServicesService.exe

• %ProgramFiles%\Microsoft SQL Server\MSAS11.<Instance Name>\OLAP\Bin\MSMDSrv.exe

En caso de que esté utilizando un clúster de Windows, se deben utilizar las siguientes prácticas recomendadas (el antivirus software que no sea compatible con clústeres puede causar problemas con los servicios de clúster, 2012)

• Antivirus software debe ser consciente del clúster
• Se excluyen los siguientes lugares:
  • Q:\ (Unidad de Quórum)
  • C:Windows Cluster
  • Directorio temporal de la cuenta de servicio del cluster SQL

• Archivos de datos de SQL Server
  • *.mdf
  • *.ldf
  • *.ndf

• Archivos de copia de seguridad de SQL Server
  • *.bak
  • *.trn

• Ubicaciones de archivos de catálogo de texto completo: (Ubicaciones de archivos para instancias predeterminadas y con nombre deSQL Server)
  • Instancia por defecto: Archivos de programa\Microsoft SQL Server\MSSQL\FTDATA
  • Instancia con nombre: Archivos de programa\Microsoft SQL Server\MSSQL$instancename\FTDATA

• Archivos de seguimiento
  • *.trc - estos archivos pueden ser generados cuando se configura el rastreo del perfilador manualmente o cuando se habilita la auditoría C2 para el servidor.

• Archivos de auditoría SQL (para SQL Server 2008 o versiones posteriores)
  • *.sqlaudit

• Archivos de consulta SQL
  • *.sql

• Datos de Analysis Services
  • La ubicación predeterminada es C:Archivos de programa de Microsoft SQL Server.

• Archivos temporales de Analysis Services
  • La ubicación predeterminada es C:Archivos de programa de Microsoft SQL Server.

• Archivos de copia de seguridad de Analysis Services
  • La ubicación predeterminada es C:Archivos de programa de Microsoft SQL Server.

• Archivos de registro de Analysis Services
  • La ubicación predeterminada es C:Archivos de programa de Microsoft SQL Server.

• Archivos de datos Filestream (SQL 2008 y versiones posteriores)
• Archivos remotos Blob Storage (SQL 2008 y versiones posteriores)
• Archivos temporales y Logs de Reporting Services (RSTempFiles y LogFiles)

Nota: Las rutas mostradas arriba son rutas por defecto y pueden haber sido modificadas en su instalación.

Las siguientes recomendaciones para configurar el cliente antivirus para el rol IIS están tomadas de RECOMENDACIONES DE EXCLUSIÓN DEL ANTIVIRUS DE WINDOWS (Helmick, 2014).

• %systemroot%\system32\inetsrv\w3wp.exe
• %systemroot%\SysWOW64\inetsrv\w3wp.exe

• Directorio de compresión IIS: %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Las siguientes recomendaciones para configurar el cliente antivirus para la aplicación SharePoint están tomadas de RECOMENDACIONES DE EXCLUSIÓN DEL ANTIVIRUS DE WINDOWS (Helmick, 2014).

• Unidad:Archivos de programa\Archivos comunes\Microsoft Shared\Web Server Extensions
• Si no desea excluir toda la carpeta Extensiones de servidor web del análisis antivirus, puede excluir sólo las dos carpetas siguientes:
  • * Unidad: Archivos de programa, archivos comunes, archivos compartidos de Microsoft, extensiones de servidor web, registros.
  • * Unidad:Archivos de programa\NArchivos comunes\NMicrosoft Shared\NWeb Server Extensions\15\Data\Applications

• Nota: Si utiliza una cuenta específica para los servicios de SharePoint o las identidades de los grupos de aplicaciones, es posible que también tenga que excluir las siguientes carpetas:
  • * Drive:\Users\ServiceAccount\AppData\Local\Temp
  • * Drive:\Users\Default\AppData\Local\Temp

Las siguientes exclusiones de directorios pueden utilizarse para minimizar el escaneo de archivos de solución durante el procesamiento de FIM:

• Excluya los binarios FIM: C:Archivos de programa Microsoft Forefront Identity Manager 2010 Servicio de sincronización
• Excluya los clientes necesarios para los agentes de gestión:
  • Notas Cliente: E:Notas
  • Binarios Oracle: E:Oracle

• Excluya los binarios FIM: C:Archivos de programa Microsoft Forefront Identity Manager 2010 Service

La correcta configuración y optimización del servidor SQL es fundamental para lograr el mejor rendimiento posible de FIM. Si se producen problemas de rendimiento, yo validaría primero la configuración de SQL. Los elementos enumerados a continuación no siguen ningún orden de prioridad de ajuste. Cada elemento debe tenerse en cuenta al validar la configuración del servidor SQL.

• Siga las mejores prácticas mencionadas en la puesta a punto del cliente antivirus del servidor SQL enumeradas en la sección anterior.

• Todas las particiones de disco deben ser validadas por problemas de desplazamiento de alineación de disco antes de realizar cualquier instalación. Esto es especialmente cierto para todas las particiones creadas por un sistema operativo Windows anterior a Windows 2008. Disk Partition Alignment Best Practices for SQL Server (May & Lee, 2009) ofrece orientación prescriptiva sobre cómo detectar y solucionar este problema. Aunque está escrito para SQL 2008, la guía sigue siendo válida para las versiones más recientes de SQL.
• Debajo de las particiones lógicas de disco hay elementos que afectan al rendimiento, como el tamaño de bloque RAID y el tamaño del sector físico del disco duro. La orientación varía entre los proveedores de RAID y los fabricantes de discos duros. Consulte a los proveedores adecuados para asegurarse de que la implementación física de su espacio de disco lógico está optimizada.

• Las E/S de disco por segundo (IOP) deben pensarse detenidamente y diseñarse adecuadamente. No dé por sentado que la SAN ofrece IO ilimitadas o que la configuración de la SAN es ideal para lo que requiere el diseño.
• El subsistema de disco subyacente y los niveles RAID son extremadamente importantes para optimizar el rendimiento del disco. Esta afirmación es especialmente cierta cuando se utilizan servidores físicos con almacenamiento conectado localmente. Los proveedores de SAN suelen proporcionar directrices de ajuste para que la configuración de la SAN admita de forma óptima aplicaciones como SQL Server.
• Un servidor SQL tiene diferentes patrones de uso de IO. Estos patrones de uso pueden beneficiarse del uso de diferentes niveles de rendimiento de los discos. SQL SERVER - Virtualized SQL Server Performance and Storage System - Notes from the Field #013 sugiere separar los componentes SQL en diferentes discos virtuales con diferentes características de almacenamiento. (por ejemplo, la base de datos SQL necesita un disco rápido, mientras que SQL Backup no necesita el disco rápido pero necesita mucho espacio en disco).
• Los siguientes contadores son útiles para detectar problemas de diskIO:
  • Disco lógico - Longitud media de cola de disco Longitud de cola de disco > 1 indica una acumulación sostenida de solicitudes de E/S.
  • Disco lógico - E/S dividida - útil para detectar la fragmentación
  • Disco lógico - %Tiempo de disco >= 80%

• Desfragmentar los discos del host virtual y del invitado virtual para reducir la fragmentación.
• Utilice una utilidad comercial de desfragmentación de disco que pueda desfragmentar archivos grandes. La desfragmentación predeterminada del sistema operativo software no es capaz de desfragmentar archivos grandes (> 64 MB), lo que puede dejar archivos grandes, como una base de datos, repartidos por un espacio no contiguo.
• Disco físico (host virtual)
  • Los discos físicos pueden fragmentarse cuando se amplían archivos de gran tamaño, como los discos duros virtuales (VHD).
  • Predimensione los archivos del disco virtual al tamaño deseado. No permita que los VHD crezcan automáticamente.
  • Desfragmentar los volúmenes físicos si se redimensionan los discos duros virtuales para mantener el uso de discos contiguos.
  • No coloque discos virtuales en particiones del sistema

• Disco virtual
  • Programe la desfragmentación durante las horas en las que no se realizan copias de seguridad.
  • Limite el número de discos virtuales para desfragmentación simultánea para reducir la carga IO en el subsistema de disco.
  • Desfragmentar los volúmenes antes de la instalación, después de la instalación y después de pre dimensionar la base de datos.
  • Evite la desfragmentación en máquinas invitadas que tengan una instantánea. La desfragmentación puede hacer crecer la instantánea.
  • Los archivos de página deben colocarse en su propio disco virtual para reducir la fragmentación de la partición del sistema.

• Fragmentación de archivos de base de datos
  • Los archivos de bases de datos suelen ser archivos más grandes que se colocan en volúmenes de unidades físicas o lógicas y no se pueden desfragmentar fácilmente con las herramientas de desfragmentación del sistema operativo. Si estos archivos crecen, es posible que las propias bases de datos se dividan en espacio de disco no contiguo, lo que ralentiza el rendimiento. Si esto ocurre, se recomienda utilizar un desfragmentador comercial software para reducir la fragmentación. Para reducir la fragmentación causada por el crecimiento de las bases de datos, consulte "Predimensionamiento de las bases de datos" para obtener más información.

• Predimensionar las bases de datos FIM con el tamaño inicial del entorno de laboratorio. Predimensionar la base de datos al tamaño esperado reduce la futura fragmentación del disco cuando existan otros archivos en el mismo volumen. Por ejemplo, si hay dos bases de datos en el mismo volumen, cuando una base de datos crece puede necesitar utilizar espacio no contiguo para el crecimiento. La pre-dimensión permite que las bases de datos alcancen el tamaño previsto sin necesidad de expandirse a un espacio no contiguo.
• Lo ideal sería que una base de datos predimensionada no creciera, pero a menudo se producen acontecimientos que nos impiden mantenernos dentro de los límites establecidos durante el dimensionamiento inicial. Se recomienda que el DBA permita el crecimiento por bloques más grandes (500 MB) para evitar que la base de datos crezca constantemente durante los ciclos de procesamiento. Esta práctica también ayuda a reducir la fragmentación del disco.
• Los siguientes comandos pueden utilizarse para ampliar el tamaño de las bases de datos y los archivos de registro, así como para cambiar los patrones de crecimiento:

• Consulte con el DBA el tamaño y el número adecuados de archivos Temp DB que deben añadirse a la solución. Una regla general es un Temp DB por núcleo de procesador siempre que el subsistema de disco pueda soportar eficientemente las peticiones IO de múltiples archivos. La idea es maximizar el rendimiento del Temp DB para aumentar el rendimiento de la aplicación.
• Las bases de datos temporales deben colocarse en un disco rápido, ya que son muy utilizadas por el servicio FIM.
• Normalice el tamaño de la Temp DB por defecto al tamaño de las temp DB adicionales que se crearán. Recuerde dimensionar según los patrones típicos de tamaño y crecimiento.

• Añada otras bases de datos temporales por recomendación del administrador de bases de datos.

• En un clúster SQL, utilice discos locales para bases de datos temporales (nueva función en SQL 2012).

La fragmentación SQL se produce cuando los índices y catálogos están muy fragmentados. SQL utiliza esto para aumentar el rendimiento de las consultas. Para mantener el rendimiento óptimo de SQL, es una buena práctica reconstruir los índices y los catálogos de texto completo de forma rutinaria.

• Fragmentación de índices
  • Crear un plan de mantenimiento semanal para Reconstruir Índices y Actualizar Estadísticas para todas las bases de datos de Usuarios.

• Texto completo Fragmentación del catálogo
  • Programe la reorganización del Catálogo de Texto Completo fuera de las horas punta. El siguiente artículo proporciona orientación sobre cómo configurarlo: How to Automate the Rebuilding of FIM Full Text Indexes (Cómo automatizar la reconstrucción de los índices de texto completo de la FIM ) (Bradley, 2014).
  • En el siguiente artículo se explica cómo determinar el nivel de fragmentación de los catálogos de texto completo: Fragmentación del texto completo (iFTS)

• Asegúrese de que todos los componentes FIM ejecutan los mismos niveles de versión en toda la solución. (Motor de sincronización FIM, Servicio FIM, Cliente FIM, etc.)

• Instalar y ejecutar el Analizador de mejores prácticas FIM (FIM Best Practice Analyzer for FIM 2010 R2, s.f.)

• Asegúrese de que todos los atributos que se utilizan en "Joins" o búsquedas metaverso están correctamente indexados en la configuración metaverso para el atributo.
• Elimina la indexación de los atributos del metaverso que no estén activos utilizándolo en Joins o búsquedas en el metaverso.
• Evaluar las actividades de codificación "fuera de banda". Las llamadas realizadas a sistemas dentro del código de aprovisionamiento FIM a recursos externos (AD, base de datos SQL) son costosas en latencia. Incluso pequeños retrasos (10 milisegundos) se acumulan cuando se realizan sobre miles de objetos. Haga un uso juicioso de las actividades "fuera de banda". Considere el uso de flujos de trabajo personalizados para ofrecer la funcionalidad realizada en la actividad "fuera de banda".
• Si los recursos externos (por ejemplo, base de datos SQL) deben ser llamados durante una actividad de codificación "fuera de banda", entonces la configuración y desmontaje de las conexiones a estos recursos externos debe hacerse en los métodos "Inicializar" y "Terminar" para la extensión, y no en los métodos "Provision" o "Flow". Para el código que no es seguro para los hilos, se debe implementar el agrupamiento o el almacenamiento en caché.
• Evalúe el rendimiento de la lógica "in bound". El código .NET mal ajustado (aunque nunca salga del contexto de proceso del motor de sincronización) tiene un gran impacto. Incluso cosas tan sencillas como utilizar indicadores de cadena ("Y"/"N") frente a valores booleanos pueden suponer una gran diferencia en el rendimiento subyacente.
• Si hay un gran número de desconectores válidos, utilice la característica de filtro Declarado (Filtro de importación) en lugar de la característica de filtro Declarado. Esto puede acelerar drásticamente los tiempos de sincronización, ya que no es necesario procesar los objetos durante el ciclo. Puede encontrar más información sobre este tema aquí (Drewes, 2012).

• Eliminar el servicio de búsqueda de SharePoint Foundation
• Habilite sólo los MPR necesarios para la solución. Deshabilite los MPR que no sean necesarios para la solución, como un "MPR todopoderoso" que pueda haberse creado para solucionar problemas de permisos FIM, ya que estos MPR crearán varias solicitudes para cada transacción.
• Elimine los Sets innecesarios de la solución
• Garantizar que no haya TMP circulares asegurándose de que los filtros de los TMP estén definidos lo más estrechamente posible para evitar solapamientos que puedan dar lugar a un bucle circular.
• Asegúrese de que las solicitudes de actualización de los clientes sólo actualizan atributos que realmente están cambiando. Por ejemplo, establecer un atributo al valor que ya tiene iniciará MPRs que probablemente no necesiten ejecutarse.
• Asegúrese de que se utiliza el número mínimo de solicitudes necesarias para resolver el problema empresarial (combine varias actualizaciones de atributos del mismo objeto en una única solicitud).
• Combinar múltiples actualizaciones de atributos en una sola solicitud. Esto significa que el evaluador de funciones incorporado debe evitarse cuando se actualizan múltiples atributos en el mismo objeto. En su lugar, utilice la WAL, otra actividad de terceros o escriba la suya propia.
• Considerar el uso de particiones del Servicio FIM para repartir la carga de solicitudes entre varias instancias del Servicio FIM.
• Para operaciones masivas, considere la posibilidad de utilizar un cliente de servicios web para comunicarse directamente con el servicio FIM en lugar de los cmdlets de PowerShell

• En algunos casos, tiene sentido separar las bases de datos del motor de sincronización y del Servicio FIM en servidores distintos. Hay que tener en cuenta que los datos de una base de datos entran o salen de la otra. Si se producen limitaciones de recursos en una base de datos, se producirán problemas de rendimiento en la otra.
• Lo ideal es que las bases de datos SCSM se ubiquen en un servidor SQL distinto de la base de datos del Servicio FIM, debido a posibles problemas de limitación de recursos, como se mencionó anteriormente en el debate sobre la base de datos del Servicio FIM Sync/FIM.
• Si virtualiza los servidores, debe prestar especial atención a la dirección hardware subyacente. Por ejemplo, si tiene tres servidores SQL distintos en el mismo host físico o utilizando los mismos discos, es posible que no obtenga el rendimiento esperado debido a la limitación de recursos.

El antivirus software que no es compatible con clústeres puede causar problemas con los servicios de clúster. (2012, 17 de agosto). Obtenido de https://support.microsoft.com/kb/250355

Bradley, B. (2014, 1 de enero). Cómo automatizar la reconstrucción de índices de texto completo FIM. Obtenido de https://social.technet.microsoft.com/wiki/contents/articles/5701.how-to-automate-the-rebuilding-of-fim-full-text-indexes.aspx

Drewes, F. (2012, 8 de enero). Filtrado previo a la importación de objetos AD en FIM 2010 R2. Obtenido de https://social.technet.microsoft.com/wiki/contents/articles/6600.pre-import-filtering-of-ad-objects-in-fim-2010-r2.aspx

Ubicaciones de archivos para instancias predeterminadas y con nombre de SQL Server. (sin fecha). Obtenido de https://msdn.microsoft.com/en-us/library/ms143547%28v=sql.110%29.aspx

Analizador de mejores prácticas FIM para FIM 2010 R2. (sin fecha). Obtenido de https://technet.microsoft.com/en-us/library/jj203402%28v=ws.10%29.aspx

Helmick, B. (2014, 16 de enero). Documento integral de exclusión AV. Obtenido de https://sdrv.ms/LES7gB

Kehayias, J. (2012, 29 de noviembre). CPU Ready Time en VMware y cómo interpretar su significado real. Obtenido de https://www.sqlskills.com/blogs/jonathan/cpu-ready-time-in-vmware-and-how-to-interpret-its-real-meaning/

Kehayias, J. (2013, 13 de noviembre). Tiempo de preparación de la CPU de Hyper-V equivalente al de VMware. Obtenido de https://www.sqlskills.com/blogs/jonathan/hyper-v-equivalent-to-vmware-cpu-ready-time/

Klee, D. (2012, diciembre 12 17). CPU Overcommitment y su impacto en el rendimiento de SQL Server en VMware. Obtenido de https://www.davidklee.net/2012/12/17/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/

May, J., & Lee, D. (2009, mayo). Mejores prácticas de alineación de particiones de disco para SQL Server. Obtenido de https://msdn.microsoft.com/en-us/library/dd758814.aspx

Prácticas recomendadas de rendimiento para VMware vSphere 5.5. (sin fecha). Obtenido de https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

Prácticas recomendadas de rendimiento para VMware vSphere™ 5.0. (s.f.). Obtenido de https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Pinal, D. (2014, enero). SQL SERVER - Rendimiento de SQL Server virtualizado y sistema de almacenamiento - Notas desde el campo #013. Obtenido de https://blog.sqlauthority.com/2014/01/30/sql-server-virtualized-sql-server-performance-and-storage-system-notes-from-the-field-013/

SQL SERVER - vCPUs - ¿Cuántas CPU son demasiadas para la virtualización de SQL Server? - Notas de campo #003. (sin fecha). Obtenido de https://blog.sqlauthority.com/2013/11/21/sql-server-vcpus-how-many-are-too-many-cpu-for-sql-server-virtualization-notes-from-the-field-003/

Mejores prácticas de Hyper-V para Windows Server 2012. (sin fecha). Obtenido de https://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

SQL SERVER - Rendimiento de SQL Server virtualizado y sistema de almacenamiento - Notas desde el campo #013 (Pinal, 2014)

Gracias a Rex Wheeler y Sami Van Vliet por su ayuda con esta guía.