MOSS 2007 presenta una mayor flexibilidad en cuanto a las topologías que podamos implementar en una solución. A diferencia de la versión anterior del producto, los roles ahora están “reducidos” a dos: WFE (web front-end server) y Application Server.
Los servidores que asumen el rol exclusivo de WFE llevan instalados únicamente los binarios que les permiten presentar contenido al usuario, recortar la interfaz basada en la autorización que éste tenga, solicitar data de la(s) base(s) de datos u otros servidores cuando sea necesario para presentar resultados de búsquedas. Se puede implementar una granja de servidores con múltiples servidores WFE y se pueden ir añadiendo si los requerimientos así lo dictaran (alta disponibilidad, redundancia, recuperación de desastres, mayor rendimiento, etc.). En un servidor exclusivo de WFE no se puede habilitar otro servicio mas que Windows SharePoint Services Web Application y Windows SharePoint Services Incoming E-mail. Para instalar este rol, en el wizard de instalación elegimos la opción “Servidor Web”.
Los servidores de aplicaciones están compuestos por el resto de opciones, las cuales en realidad son un conjunto de servicios que habilitamos o deshabilitamos en determinado servidor para asignarle tal rol. Estos servicios pueden ser:
-
Administración Central
-
Servicio de conversión de documentos
-
Servicio de balanceo de carga y conversiones
-
Excel Calculation Service
-
InfoPath Form Services
-
Office SharePoint Server Search
-
Windows SharePoint Services Incoming E-mail
-
Windows SharePoint Services Search
-
Windows SharePoint Services Web Application
Típicamente podemos implementar servidores WFE, servidores de Query (búsqueda), un servidor de índice (index server), un servidor de administración central, un servidor con Excel services y los demás servicios. Podemos además combinar estos roles, de modo que los WFE sean también servidores de Query, o combinar la administración central con el resto de servicios. Cuando hacerlo? De eso trata este post ;)
Para instalar un servidor de aplicaciones, elegimos la opción “Completa” en el wizard de instalación.
Como nota aparte, es requerido al menos un Proveedor de Servicios Compartidos (SSP) por granja, lo cual no conforma un rol de servidor per se, pero ciertamente es lo primero que creamos en una instalación de MOSS.
Entonces, si queremos podemos tener en un solo servidor todos los roles, o distribuirlos de acuerdo a nuestra conveniencia. Vamos a ver esto en detalle.
Sizing
Este es un tema del cual se habla mucho. Así que me toca =D. Trataré de resumir lo que necesitamos para determinar el tipo de implementación.
Ante todo: dado que MOSS puede ser configurado y desplegado de tantas maneras, no hay una manera simple de estimar el número de usuarios que pueden ser soportados por una determinada configuración sin asumir ciertos parámetros. En este post asumiré:
· Servidores con CPU dual-core y dos sockets (esto es, dos procesadores, cuatro núcleos)
· CPU’s x86 (32 bits)
· 2 GB de RAM al menos, por servidor
· Autenticación NTLM (Windows Authentication en dominio)
· Configuración de caché por defecto (tocaremos el tema de caché luego)
En la documentación de SharePoint, Microsoft propone métricas en términos de Requests por Segundo (RPS) para calificar a los usuarios en función al acceso que tengan al producto: (http://technet2.microsoft.com/Office/en-us/library/0a7b2b45-f633-46d2-a4fd-78691d4b8f631033.mspx?mfr=true)
· Usuario leve, genera un request cada 180 segundos (20/hr), 1 RPS = 180 usuarios activos
· Usuario típico, genera un request cada 100 segundos (36/hr), 1 RPS = 100 usuarios activos
· Usuario pesado, genera un request cada 60 segundos (60/hr), 1 RPS = 60 usuarios activos
· Usuario extremo, genera un request cada 30 segundos (120/hr), 1 RPS = 30 usuarios activos
Puedes crear tu propia tabla de patrones de uso analizando los logs de IIS (http://go.microsoft.com/fwlink/?LinkId=78825&clcid=0x409 ) para alguna solución de colaboración ya existente en tu entorno.
1. Configuración básica
Consta de un único servidor donde residirá MOSS y SQL Server. Obviamente hablamos de SQL Server Standard o Enterprise Edition. Yo recomiendo utilizar dos servidores separados, uno para MOSS y otro para SQL Server. Esto permitirá escalar la implementación si es que se requiere otorgarle alta disponibilidad, soporte a mayor número de usuarios, entre otras cosas. Se podrá añadir luego un servidor WFE (creando un pool NLB – balanceo de carga Windows) para incrementar la performance y para proveer redundancia al componente WFE, así como configurar mirroring en SQL Server.
Uso ideal: colaboración de equipos de trabajo, pequeña intranet corporativa.
RPS (un único servidor) = 50 – 70
RPS (dos servidores –MOSS y SQL) = 75 – 100
Si haces un promedio de los RPS en el primer caso (60 RPS), y asumiendo que tienes 10% de usuarios leves, 50% de usuarios típicos, 30% de usuarios pesados y 10% de usuarios extremos, tu implementación soportaría
Usuarios = 0.10(180*60) + 0.50(100*60) + 0.30(60*60) + 0.10(30*60) = 5,340
Si haces lo mismo para el segundo caso (dos servidores, 87.5 ≈ 88 RPS), obtendrás
Usuarios = 0.10(180*88) + 0.50(100*88) + 0.30(60*88) + 0.10(30*88) = 7,832
2. Configuración de alta disponibilidad
Consta al menos de cinco (5) servidores: dos (2) WFE + Query en un pool NLB, un (1) servidor de aplicaciones y dos (2) servidores SQL Server en un cluster activo/pasivo conectado a un almacenamiento común (típicamente provisto por una SAN), ó con una configuración de mirroring (lo que elimina la necesidad de un almacenamiento compartido).
Primero se instala el servidor de aplicaciones, que constituirá la granja y almacenará la Administración Central, el SSP, el índice e inicialmente tendrá el servicio de aplicación web habilitado (mucho cuidado con la configuración del índice, ya que podríamos romper su propagación a los servidores de Query). Luego se instalan los servidores WFE con la opción de instalación “Completa”, y se les habilita el servicio de Search. Una vez hecho esto podemos habilitar (si deseamos) los demás servicios en el servidor de aplicaciones (Excel services, entre otros). Por supuesto, la configuración del back-end SQL es anterior a todo esto, ya sea en Cluster o Mirroring.
Esta implementación ofrece redundancia para el componente WFE, de modo que en caso de falla de un WFE la solución todavía funciona, y aun si no falle, otorgará mayor rendimiento. El cluster simple activo/pasivo será suficiente para dos servidores WFE, ya que cada nodo SQL puede soportar entre tres y seis servidores WFE. Asume tres (3) WFE por cada nodo SQL como base. Si SQL tiene dos CPU’s x64 (64 bits) dual core, entonces puedes calcular 6 WFE por nodo SQL (HP estima que un servidor con 4 CPU’s cual-core provee 1.8 veces la capacidad de procesamiento de un servidor de 2 CPU’s dual-core).
En caso de falla del índice, las búsquedas de los usuarios no sería interrumpidas, ya que una copia del índice es propagada a cada servidor de Query (en este caso, WFE + Query) para realizar las consultas. El problema real es que no se continuará la indexación del contenido añadido o modificado posteriormente a la caída del servicio, y no estará disponible en los resultados de búsqueda.
Si se estima que una gran cantidad de información va a ser almacenada (y en consecuencia, indexada), entonces es una buena idea dedicar un servidor de aplicaciones exclusivamente al rol de indexación. El número de procesadores juega un papel muy importante para la velocidad de indexación y cuántos threads de indexación podrán ser ejecutados simultáneamente (un thread por núcleo). En este caso un servidor con 4 CPU’s dual-core es una buena opción (8 threads). La memoria RAM es muy importante ya que los documentos son cargados en buffers en memoria para su procesamiento (si hablamos de memoria, los CDPu’s de 64 bits amplían el espacio de memoria disponible). Dada la restricción de un servidor de índice por SSP, es mejor escalar en términos de procesador y memoria (scale-up) que en términos de número de servidores (scale-out), ya que implicaría la creación de más SSPs, mayor consumo de disco en la base de datos, mayor tráfico de red, etc.
Uso ideal: intranets, extranets, publicación en internet.
RPS (con dos WFE) = 175 – 250
Asumimos un promedio de 212.5 ≈213 RPS para calcular el número de usuarios
Usuarios = 0.10(180*213) + 0.50(100*213) + 0.30(60*213) + 0.10(30*213) = 18,957
NOTA: Se estima que cada servidor WFE extra puede soportar aproximadamente 100 RPS. Si este servidor también será de Query (WFE + Query) asume 85 RPS. Recuerda que puedes expandir esta configuración añadiendo más servidores WFE, separando el rol de índice y agregar mas nodos al cluster SQL, lo que me lleva al siguiente punto…
3. Configuraciones optimizadas en función a aplicaciones
Son básicamente extensiones la configuración de alta disponibilidad, donde básicamente se despliegan servidores dedicados para ciertos roles (Búsqueda, índice, Excel services, InfoPath Forms Services, etc.).
Disponer de varios servidores y poder separar el rol de Query del WFE quita carga al servidor de WFE. Si Excel services será extensamente utilizado entonces es recomendable dedicarle un servidor. En cuanto al índice, ya hice mi recomendación líneas arriba.
Estas configuraciones también emplean NLB en los servidores WFE para otorgar redundancia y mayor rendimiento. Para SQL Server puedes utilizar database mirroring en modo de alta disponibilidad con un servidor testigo para habilitar failover automático, y añadir log shipping para asegurar la continuidad del servicio en caso de desastres; un cluster “N+1” (un cluster N+1 tiene N nodos activos y un nodo pasivo). Esto sería utilizado en caso de que la carga por servidor excediera la capacidad de un nodo SQL activo (típicamente entre 3 y 6 WFE por cada nodo SQL activo) . Seguramente utilizarías un arreglo SAN que provea redundancia (fully-redundant dual-path & dual controller fibre connecivity). Vendors como HP proveen soluciones de este tipo.
Utilizando la base de 100 RPS por WFE y la regla de WFEs por nodo SQL, además de una estimación del tipo de usuarios que soportará tu implementación y evaluando la necesidad de un índice dedicado y en general del uso que será dado a cada servicio, puedes estimar el número de servidores que requieres.
Rendimiento
Este punto lo podemos atacar por varios lados. Tenemos la red, tenemos el uso de memoria, el acceso a disco, caché, autenticación…
1. Red
Existe el potencial para que se dé un alto tráfico entre clientes y servidores WFE, lo mismo que entre WFE’s y los servidores de aplicaciones o de base de datos. Para implementaciones de alta disponibilidad en adelante, recomiendo utilizar dos VLAN’s para poder separar el tráfico cliente-WFE del tráfico WFE-aplicación/BD. Inclusive, para el caso de database mirroring se pueden utilizar NIC’s adicionales para el tráfico entre servidores SQL (sincronización de logs de transacciones y heartbeat del testigo).
Para el caso de las NICs puedes utilizar Gigabit Ethernet. Existen observaciones realizadas en pruebas de con un rendimiento aproximado de 100 RPS que mostraron las siguientes características:
· Tráfico hacia clientes = 9,000 KB/seg
· Tráfico WFE (lectura/escritura) = 11,000 KB/seg recibidos; 20,000 KB/seg enviados
· Tráfico WFE (sólo lectura) = 5,000 KB/seg recibidos; 20,000 KB/seg enviados
· Tráfico SQL (lectura/escritura) = 4,000 KB/seg recibidos; 10,000 KB/seg enviados
· Tráfico SQL (sólo lectura) = 2,000 KB/seg recibidos; 10,000 KB/seg enviados
Memoria y CPU
Los procesadores de 64 bits amplían el espacio de memoria. Ciertamente es conveniente escalar hacia 64 bits en el caso de una implementación MOSS, tanto para MOSS en sí como para SQL. En pruebas realizadas en los laboratorios de HP, se ha determinado que los procesadores de 64 bits tienen un rendimiento ligeramente menor que los de 32 --así es, y no es una contradicción a lo que afirmé primero, explico: las aplicaciones se benefician con el incremento potencial de memoria, ya que métodos de tuning como caching utilizarán memoria (y esto se gana en 64 bits) y requerirán menos recursos de CPU, lo que resulta en un incremento del rendimiento y eficiencia potencial, además de que se prepara el entorno para el futuro (64 bits).
Además, el índice utiliza mucha memoria al cargar la información que está indexando en ella, de modo que es mejor darle un buen pedazo de RAM.
Las aplicaciones web de MOSS tienen cada una, por defecto, su propio Application Pool. Este es el comportamiento típico a la hora de crear una aplicación web (y la correspondiente colección de sitios). Mientras que esto puede ser beneficioso (se pueden reciclar los AppPools independientemente, se aisla la memoria de cada uno, el worker process w3wp.exe tiene en caché datos por cada aplicación web, etc.), también puede ser contraproducente. Se han observado worker procesess de 250 – 300 MB en servidores de 32 bits, y de 400 – 500 MB en servidores de 64 bits, siendo en todos los casos siempre el mínimo 100 MB al crear un AppPool. Cada AppPool tiene una instancia del runtime de .NET en memoria. Recuerda que existen adicionalmente otros AppPools y worker procesess para la Administración Central, el SSP, posiblemente MySite, etc., en varios de los servidores WFE. Evalúa entonces qué aplicaciones web se pueden consolidar en un solo AppPool para ahorrar memoria.
Cahing
Utilizar la memoria de los servidores WFE y/o disco de éstos como caché incrementará el rendimiento (menos viajes hacia la base de datos y otros), reduciendo el tiempo de respuesta. MOSS trae tres (3) esquemas de caché:
-
Caché de salida (output cache): ideal para sitios que no cambian constantemente de contenido, por ejemplo, sitios de acceso público tales como extranets, creados con el feature de publicación. Se activa a nivel de sitio en el menú de configuración del sitio. Utiliza memoria de los servidores WFE.
-
Caché BLOB (Binary Large OBjects): ideal para elementos de páginas, tales como imágenes, sonidos, animaciones, javascript, CSS, etc., que son objetos almacenados dentro de la base de datos como grandes objetos binarios. Se activa para evitar la repetición de un acceso innecesario a la base de datos por objetos que son esencialmente estáticos, mejorando el tiempo de respuesta de la página. Este caché está desactivado por defecto y se activa a nivel de web.config. Para ello busca la segunda instancia de “BLOB” en el web.config de la aplicación deseada, y te llevará al siguiente código:
<BlobCache location=”c:\blobCache” path=”\.(gif|jpg|png|css|js)$” maxSize=”10” max-age=”86400” enabled=”false”>
El parámetro maxSize expresa el tamaño máximo para el caché en GB; location dice dónde estará el caché (debes crear el folder blobCache manualmente); max-age expresa el tiempo de vida en segundos del caché (24hrs por defecto) y path dice que tipos de archivo entrarán al caché. Quizás te interese agregarle un .jscss (es posible combinar css y javascript en un único archivo). Por último, el parámetro enabled permite su habilitación, y para ello dale el valor enabled=”true”.
- Caché de objetos: funciona a nivel de contenido. Ideal para web parts, listas, controles, field controls, etc. Normalmente se utiliza para querys pesados o para los controles de navegación. Reduce los accesos a la base de datos e incrementa el tiempo de respuesta de la página. Este tipo de caché casi siempre puede ser utilizado, aunque cuando un usuario hace check-out a un documento, el caching se ignora. Este tipo de caché está activado por defecto, y el tamaño de memoria asignado y otros parámetros puedes modificarse a nivel de sitio desde la página de configuración de sitio.
Autenticación
Muchos no consideran el tráfico que puede generar la autenticación, y ciertamente lo hace. Seamos honestos, cuántos se preocupan por el número de DCs para una implementación MOSS? Quizás sí en el diseño de AD, pero se preocupan por el tráfico que genera la autenticación de usuarios? Si observas los logs de IIS y ves errores tipo 401 precedentes a errores tipo 200, entonces cada uno de esos logs genera tráfico de ida y vuelta al controlador de dominio (DC). Si utilizas FBA (forms-based authentication) o NTLM, deberás tener en cuenta el rendimiento a consecuencia del tráfico por autenticación. Ciertamente FBA reduce el tráfico, pero NLTM no. Piensa en utilizar Kerberos en lugar de NTLM. El paquete Kerberos tiene una cabecera mayor, pero los tiempos de expiración por ticket (10 minutos) alivian el tráfico en la red en comparación con NTLM.
Microsoft recomienda utilizar un máximo soportado de tres (3) WFE’s por cada DC. Esto no significa que si dispones únicamente de un DC no vayas con una implementación grande, pero piensa en escalar AD.
Almacenamiento
En discos duros SCSI es obvio. En cuanto a servidores empresariales, para el back-end SQL es conveniente utilizar una SAN con redundancia de canales. Se pueden utilizar las bahías de almacenamiento propias de los servidores también.
-
WFE: utilizan aproximadamente 6 GB para Windows Server, .NET Framework 3 y los binarios de MOSS. Considera el archivo de paginación (SWAP) del mismo tamaño de la memoria (4 GB idealmente). El espacio de logs de IIS es variable dependiendo del plazo de retención planeado. Un servidor WFE de una implementación para 30,000 usuarios puede general un millón (1’000,000) de entradas diarias.
-
Servidor de aplicaciones y de índice: aproximadamente 6 GB para Windows Server, .NET Framework 3 y los binarios de MOSS. Considera el archivo de paginación (SWAP) del mismo tamaño de la memoria (4 GB idealmente). Estima el tamaño total de información que almacenarás en las bases de datos de contenido a lo largo del tiempo y otorga el 30% de ese valor como tamaño máximo para el índice (esto para los servidores de Query y para el índice).
-
Bases de datos: aproximadamente 5 GB para Windows Server, .NET Framework 2 y los binarios de SQL. Considera el archivo de paginación (SWAP) del mismo tamaño de la memoria (4 GB idealmente). Suma 1.5 GB para la base de datos de configuración. Calcula el tamaño de las bases de datos de contenido estimando el tamaño total de la información que almacenarás a lo largo del tiempo multiplicándola por 1.2. Recuerda que si activarás el versionamiento entonces la cantidad de información puede crecer bastante. El espacio en disco para los logs de la base de datos variarán dependiendo del número total de bases de datos y las configuraciones de log. Para asegurar espacio necesario para el crecimiento de las bases de datos, planea otorgar el doble del espacio que inicialmente estimaste (esto es, un fill factor de 50%) –esto es una buena práctica ya que el versionamiento y la papelera de reciclaje (que tiene 2 stages) mantienen todavía información que podrías pensar que ha sido eliminada.
Adicionalmente a todo esto, siempre es bueno dejar un 25% del espacio en disco libre en todos los servidores, emplear prácticas de administración del almacenamiento adecuadas (defragmentación) y aplicar buenas prácticas de backup a nivel de granja, colección de sitios, sitios y SQL server.
En cuanto a los límites, el índice puede almacenar hasta 50 millones de ítems, y se deben considerar los siguientes límites para los objetos:
-.M.-