Hemos tenido que hacer un capacity planning en un cliente para darles la lista de la compra. Es algo poco común (en mi experiencia) ya que muchos clientes suelen decidir el hardware sin contar con nosotros mirando las especificaciones mínimas.
Bueno pues el tema es que para una vez que nos dejan hacerlo, casi mejor hacerlo bien y no fliparse y meter 50 servidores, así que estuve documentandome y leyendo, aqui van mis conclusiones:
Herramientas de estimación "automáticas"
Yo las veo como ayudas que te pueden decir más o menos por donde tirar, lo bueno es que tras trabajar con las dos nos dan estimaciones mas o menos parecidas, por lo que no debemos ir muy desencaminados :)
Ambas son gratis, que conste :P
System Center Capacity Planner 2007
Es muy completo, te deja ajustar muy bien el hardware de la NAS, discos duros, etc. Disponible aquí.
No se le va mucho la pinza con el las especificaciones que pide, salvo tal vez por la RAM, ya que empieza a pedir a partir de 8Gb.
El punto fuerte es que te permite hacer una simulación de distintas acciones unos tiempos estimados de las acciones (ver una página, crear un item, etc.), además se puede ver como cuando cambias el hardware varian los distintos tiempos y la carga sobre las máquinas.
Te permite ver la carga que soportará cada máquina, los posibles cuellos de botella, las capacidades de almacenamiento y esas cosas.
Una cosa que está muy bien es que no siempre añadiendo mas servidores tienes mas rendimiento, sino que jugando con los roles puedes sacar mejor rendimiento (en mi caso 2 servidores frontales + 2 servidores de búsqueda daban peor rendimiento que 3 servidores con los dos roles)
HP Sizing and Configuration Tool for Microsoft Office SharePoint Server 2007
Es mas sencillita, el punto fuerte es que trabaja sobre hardware HP y practicamente te da una lista de la compra con los partsnumbers y todo. Disponible aqui.
Tampoco se le va la cabeza con las máquinas que pide, el problema es que con la SAN si se le va la cabeza y que parece que se queda corto con la capacidad de los discos de los nodos.
El tamaño de los índices de búsqueda y las bases de datos
Este es un tema que nunca ha quedado muy claro, se dicen bastantes barbaridades respecto a los tamaños y esas cosas, aqui voy a ponerlo tal y como lo entiendo:
En nuestro caso vamos a pensar que tenemos que almacenar 30Gb de documentos.
Por un lado tenemos el tamaño de la base de datos de contenidos, la estimación que nos dicen es coger el tamaño de todos los documentos que almacenamos, junto con las versiones que queremos guardar y lo multiplicamos por 1,2. En nuestro caso si queremos guardar hasta 3 versiones, pues 30*3*1.2 = 108Gb
Por otro lado tenemos el tamaño del índice de las búsquedas, factores a tener en cuenta:
Tamaño medio de los archivos
- Si es igual o mayor de 100KB multiplicar el tamaño de los archivos por 0.05
- Si está en torno a 10KB multiplicar el tamaño de los archivos por 0.12
- Si está en torno a 1KB multiplicar el tamaño de los archivos por 1
Tipo de archivos
Hay que tener en cuenta que según el tipo de los archivos se indexará más o menos información, si el archivo es un word tendrá mucho texto, si es un jpg no tendrá tanto, hay que ver los tipos de archivo que guardamos y si tenemos o no los ifilters instalados.
La recomendación en los documentos es bastante variable antes llegaba al 50% del tamaño de los datos, ahora 30% o 20% y en blogs como el de Joel Oleson nos dice que si nos ponemos en el caso pesimista estimemos un 10% del tamaño con una espectativa realista de entre el 1 y el 5%.
Para cubrirnos las espaldas pondremos un 15%, por lo que el tamaño sería 30*0,15 = 4,5Gb
Ahora bien esto que acabamos de calcular no son los archivos, es un "ente" que luego se guardará en los servidores de indexación y de búsqueda.
Espacio en disco de los índices de búsqueda
Los índices se guardan en disco, pero hace falta multiplicar el tamaño del índice por 2,85 (antes del SP1 era 2.5) para calcular el tamaño que ocuparán, este extra viene motivado por la necesidad de hacer los merges de las indexaciones y los backups. Este espacio hace falta tanto en la máquina que realiza la indexación como en las que tengan el rol de búsqueda. Si el servidor tiene solo el rol de servidor web, no necesitaremos ese espacio.
Nosotros los indices los pusimos en 3 discos duros en RAID 5 que solo se usarán para eso. Necesitariamos 4,5 * 2,85 = 12,825Gb.
Espacio de la base de datos de búsqueda
Los archivos de los índices realmente tienen un catalogo de texto con los datos contenidos en los archivos, la base de datos de búsqueda lo que contiene son los metadatos de los sitios, archivos, etc, así como estadísticas de rastreo. La recomendación es que se reserve un espacio equivalente a 4 veces el tamaño del índice.
Hay que hacer notar que esta base de datos es la que más actividad de escritura suele tener, por lo que puede que tengamos que tenerlo en cuenta si vamos a tener muchas indexaciones para poner los ficheros de log y de datos en grupos de discos separados o con un RAID especial.
Análisis de uso
Estuvimos analizando el uso de la intranet con herramientas que analizaban el log del IIS (no teniamos otras herramientas mejores), yo use el Sawmill 7.0 y el Weblog Expert Lite que nos dan una idea del uso que puede tener la intranet. Nos salió que habia unos 8.000 usuarios reales haciendo uso de la intranet.
Básicamente hay que mirar el número de usuarios que usan la intranet, el uso de las búsquedas (yo miré las vistas de la página que muestra los resultados), y esas cosas. Como curiosidad, una manera de ver si la gente usa o no la intranet es comparar el numero de páginas vistas de la intranet con respecto al numero de vistas de la home y también mirar la hora a la que se producen las visitas, si las visitas son a la hora de entrar a trabajar y la home es con mucha diferencia la más vista no lo usan mucho...
Otra acción interesante es poner un performance monitor de la CPU, memoria, etc en las horas pico de uso para ver como van las máquinas (en caso de ser una migración).
Conclusión y otras cosas a tener en cuenta
Al final nos salia para nuestro numero de usuarios una granja con 3 máquinas: 2 Frontales + Busquedas y 1 de Indexación. Las máquinas son de 64bits (ojo con el ifilter de adobe). Si se quedara corto, pondriamos otro frontal también con doble rol, pienso que tener un rol de busqueda dedicado es solo necesario en casos muy puntuales. Otra cosa interesante es que en casos con mucho tráfico se puede hacer que el indexador solo se pegue con uno de los frontales y dejamos dedicado ese frontal para que el indexador lo "tueste" (el indexador llama a los webservices de los frontales para indexar los contenidos).
Pedimos servidores con 5 discos SAS, los discos los organizaremos de la siguiente manera:
- Dos discos en mirroring para el SO y los logs: Pondremos el SO y programas en una particion y los ficheros de log en otra, el motivo es que si pasa algo los logs no saturen la unidad del sistema. Si tuvieramos muchisimo tráfico (un portal) se podrian poner los logs en discos aparte.
- Tres discos en RAID 5 para los ficheros de índice.
Respecto al micro de las máquinas usaremos un xeon quad core por cada máquina, preferimos usar un quad core en vez de dos dual core dado que como hemos visto que no tendremos mucha carga nos deja via libre para poner otro micro en caso de que veamos que se vuelve un cuello de botella.
Aunque se sale de lo que viene a ser el capacity planner, estaria bien instalar el Management Pack de System Center Operations Manager para MOSS y WSS, que pueden dar información de como está tanto el servidor como la instalación.
Aqui os dejo unas referencias que me han venido genial: