Parte de mi trabajo diario, está relacionado a las revisiones pro-activas que realizo a infraestructuras de Forefront Client Security (FCS) a clientes Premier.
En un 99% de mis revisiones, los problemas son derivados de un mal dimensionamiento del tamaño de las bases de datos de SQL que soportan los roles de FCS.
Antes de poder dimensionar una arquitectura de FCS, tenemos que identificar los 4 principales componentes que integran esta solución.
- Consola de Operación: Comúnmente llamada FCS Console, es donde se encuentra la consola de administración principal, muestra los reportes, y es donde se administran las políticas del antivirus.
- Servidor de Recolección: O Servidor de Collect Microsoft Operations Manager (MOM), es el servidor que se encarga de la administrar los agentes que recolectan los datos en los clientes, contiene la base de datos de MOM.
- Servidor de Reporting: Servidor que contiene la base de datos de Reporting, y donde se generan los reportes diarios para poderlos visualizar en la consola principal.
- Servidor de Distribución: Servidor de WSUS, una vez integrado a la arquitectura de FCS, se encarga de distribuir el cliente del antivirus y las definiciones.
Cada uno de estos componentes puede convivir en una sola Caja (Servidor), es aquí donde comienzan las primeras preguntas para dimensionar nuestro ambiente.
¿Cuantos clientes de antivirus soportara nuestra infraestructura? ¿Cuál será el espacio en disco duro que necesito para mis clientes?
Dependiendo del número de clientes a soportar podemos elegir topologías hasta de 6 servidores físicos o cajas, pero lo importante, es adecuar el tamaño de las bases de datos.
Cuestiones a considerar muy importantes:
1. Durante la instalación de FCS, la base de datos de Collect (OnePoint), y la base se de datos de Reporting (SystemCenterReporting) se instalan con un tamaño inadecuado.
2. La base de datos de Reporting, es la más grande porque contiene los datos históricos, en cambio la base de datos de Collect solo puede almacenar 72 horas de información.
3. La base de datos de Reporting puede almacenar hasta 395 de días de historia, los cuales, por recomendación se pueden reducir a petición del cliente. Pueden ver el siguiente Link para realizar el procedimiento: http://support.microsoft.com/kb/887016/
4. La siguiente tabla indica el tamaño estimado que tendrán las bases de datos dependiendo del número de clientes administrados, y el histórico en días.
5. El Log Transaccional de la base de datos de OnePoint solamente requiere una tercera parte con respecto al tamaño de la misma base de datos.
6. Existe un DTS, generado en la instalación de FCS, que cada 72 horas, transfiere los datos recolectados de la base de Onepoint a la base de Reporting. He aquí el detalle de esta falla muy común, el log transaccional de la base de datos de Reporting requiere en espacio, 5 veces más que el tamaño de la base de datos de Onepoint. Basándonos en el siguiente ejemplo:
Infraestructura del cliente que soporta 3000 Clientes, la base de datos Enterprise de OnePoint en 10 días alcanzará un tamaño de 5 GB, eso nos indica que teniendo por default un valor de 395 días de histórico, en ese tiempo la base de datos de Reporting puede alcanzar un tamaño de 54 GB.
El detalle es que como encargados de la infraestructura, muchas veces no nos damos cuenta de este problema, hasta que comenzamos a notar que en la consola, ya no tenemos reportes históricos.
Una manera sencilla de resolverlo es agregando más espacio a la base de datos de Reporting para que el log de transacciones puede procesar todas las operaciones y el DTS termine su ejecución, en ese momento podemos corregir el histórico en días y configurar el tamaño adecuado de las bases de datos con las recomendaciones que aquí les dejo.
