Rediseño de la topología de búsqueda empresarial para más contenido y usuarios en SharePoint
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
Con el tiempo, la mayoría de los entornos de búsqueda aumentan, tanto en cantidad de contenido como en número de usuarios. En algún momento, el entorno de búsqueda supera la capacidad y el rendimiento de la arquitectura de búsqueda. La solución consiste en escalar la topología de la arquitectura de búsqueda:
Rediseñar la topología (este artículo)
Implementar la topología rediseñada (Administrar la topología de búsqueda en SharePoint Server)
¿Está familiarizado con los componentes del sistema de búsqueda en SharePoint Server y cómo interactúan? Si consulta Información general sobre la arquitectura de búsqueda en SharePoint Server y Arquitecturas de búsqueda en SharePoint Server 2016 (o Arquitecturas de búsqueda para SharePoint Server 2013) antes de empezar, adquirirá los conocimientos necesarios sobre la arquitectura de búsqueda, los componentes de búsqueda, las bases de datos de búsqueda y la topología de búsqueda.
En este artículo, le mostraremos paso a paso cómo rediseñar la topología de búsqueda.
Paso 2: ¿A qué arquitectura de búsqueda de tamaño debo escalar?
Paso 3: ¿Cuáles son los requisitos de hardware que debo contemplar?
Una vez que haya seguido estos pasos sabrá:
Cuántos componentes de búsqueda y bases de datos de búsqueda de cada tipo necesita la topología.
En qué servidores de aplicaciones y servidores de bases de datos se va a implementar cada componente de búsqueda.
Qué recursos de hardware necesita cada servidor de aplicaciones y servidor de bases de datos.
Paso 1: ¿Cuánto contenido tengo?
Los recursos que debe hospedar en la granja de servidores dependen del volumen de contenido que tenga en el índice de búsqueda. Compruebe cuántos elementos se pueden buscar en el entorno de búsqueda existente. Encontrará este número en la página Administración de búsqueda en el sitio web de Administración central de SharePoint. Para abrir la página de administración de búsqueda, haga clic en Administrar aplicaciones de servicio en Administración central y, a continuación, haga clic en el nombre de la aplicación de servicio de búsqueda.
Calcule cuánto espera que el número de elementos que se pueden buscar crezca en los próximos 12 meses y diseñe la topología de búsqueda para esa cantidad. Por ejemplo, si tiene 8 000 000 elementos indexados y espera que el volumen de ese contenido crezca un 50 % en los próximos 12 meses. Debe diseñar para 12 000 000 elementos que se pueden buscar.
Paso 2: ¿A qué arquitectura de búsqueda de tamaño debo escalar?
Evaluar la envergadura de la arquitectura de búsqueda no siempre es fácil. El tamaño de la arquitectura de búsqueda depende del volumen del contenido, la tasa de rastreo, el rendimiento de las consultas y el nivel de alta disponibilidad que se necesite. Hay arquitecturas de búsqueda de ejemplo probadas por Microsoft que se recomienda usar como base para su propia granja de servidores. Compare la arquitectura de búsqueda actual con las arquitecturas de búsqueda de ejemplo y determine qué ejemplo representa mejor la arquitectura de búsqueda actual. A continuación, considere a qué arquitectura de búsqueda de ejemplo se va a escalar. La arquitectura de búsqueda de ejemplo que escoja dependerá de la cantidad de contenido que deba permitir búsquedas:
| Volumen de contenido (SharePoint 2016) | Arquitectura de búsqueda de ejemplo | Volumen de contenido (SharePoint 2013) |
|---|---|---|
| 0-20 millones de artículos | Granja de servidores de búsqueda pequeña | 0-10 millones de elementos |
| 0-80 millones de artículos | Granja de servidores de búsqueda mediana | 0-40 millones de artículos |
| 0-200 millones de artículos | Granja de servidores de búsqueda grande | 0-100 millones de artículos |
| 0-500 millones de artículos | Granja de servidores de búsqueda de gran tamaño | No compatible |
Aunque estas arquitecturas de búsqueda de ejemplo usan máquinas virtuales, puede usar tanto servidores físicos como máquinas virtuales según la estrategia de la solución general de SharePoint Server de la arquitectura de búsqueda.
Granja de servidores de búsqueda pequeña
Hemos estimado que esta arquitectura de búsqueda puede rastrear 50 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene hasta 20 millones de elementos en una granja de servidores de SharePoint Server 2016, la granja de servidores de búsqueda pequeña probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 50 documentos por segundo, la búsqueda tarda 110 horas en rastrear 20 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda mediana
Hemos estimado que esta arquitectura de búsqueda puede rastrear 100 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene entre 20 y 80 millones de elementos en una granja de Servidores de SharePoint Server 2016, la granja de servidores de búsqueda mediana probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 200 documentos por segundo, la búsqueda tarda 280 horas en rastrear 80 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda grande
Hemos estimado que esta arquitectura de búsqueda puede rastrear 200 documentos por segundo y servir en el orden de 10 consultas por segundo. Si tiene entre 80 y 200 millones de elementos en una granja de Servidores de SharePoint Server 2016, la granja de servidores de búsqueda grande probablemente será la granja más adecuada para usted. Con una tasa de rastreo de 200 documentos por segundo, la búsqueda tarda 280 horas en rastrear 200 millones de elementos en el primer rastreo completo.
Granja de servidores de búsqueda de gran tamaño
Microsoft probó esta arquitectura de búsqueda y midió que puede rastrear entre 300 y 500 documentos por segundo y servir en el orden de 10 consultas por segundo. Solo SharePoint Server 2016 admite esta arquitectura de búsqueda de tamaño. Si tiene hasta 500 millones de elementos, una granja de servidores similar a la granja de servidores de búsqueda de gran tamaño adicional es un buen punto de partida. Con una tasa de rastreo de 500 documentos por segundo, la búsqueda tarda aproximadamente 300 horas en rastrear 500 millones de elementos en el primer rastreo completo.
La creación de una granja de servidores de búsqueda de este tamaño requiere que planee y ajuste cuidadosamente la granja de servidores para obtener el rendimiento que desee. Es posible que le resulte ventajoso buscar orientación de expertos. También es importante planear la copia de seguridad y restauración de una granja de servidores de búsqueda de este tamaño y cómo recuperar la granja de servidores si el centro de datos tiene una interrupción importante. Se recomienda practicar la copia de seguridad, la restauración y la recuperación.
Paso 3: ¿Cuáles son los requisitos de hardware que debo contemplar?
Ahora que ha determinado el volumen del contenido y ha elegido una nueva topología a la que pasar, el siguiente paso es planear el hardware que necesitará, como se describe en esta sección:
Decidir si los servidores ejecutarán de manera física o virtual
Decidir de qué manera la arquitectura de búsqueda admitirá la alta disponibilidad
Decidir si los servidores ejecutarán de manera física o virtual
Cuando planeó originalmente su arquitectura de búsqueda, decidió usar servidores físicos o máquinas virtuales, o una mezcla de ambos. Considere si dicha decisión sigue siendo válida. Por ejemplo, si pasa del medio a la arquitectura de búsqueda de ejemplo grande, es posible que le resulte más fácil administrar el mayor número de servidores al usar máquinas virtuales. Tenga en cuenta también que aunque un entorno virtual es más fácil de administrar, su nivel de rendimiento a veces puede ser ligeramente inferior que el de un entorno físico. Un servidor físico puede hospedar más componentes de búsqueda en el mismo servidor que un servidor virtual. Encontrará instrucciones útiles en Overview of farm virtualization and architectures for SharePoint 2013.
Los ejemplos de arquitectura de búsqueda pequeños, medianos, grandes o extra grandes se ejecutan en máquinas virtuales, pero también se pueden ejecutar en servidores físicos. En las arquitecturas de granja de servidores de muestra, mueva los componentes de búsqueda de las máquinas virtuales en el servidor host y quite las máquinas virtuales. Cada servidor físico puede alojar hasta cuatro componentes de índice, pero solo uno de cada tipo de los demás componentes de búsqueda. Si, por ejemplo, cambia la arquitectura de búsqueda de ejemplo medio para usar servidores físicos, verá que tiene dos componentes de procesamiento de contenido en el host E. La solución consiste en quitar uno de los componentes de procesamiento de contenido. Esto funciona porque el rastreo, el procesamiento del contenido y el procesamiento de análisis dependen de la cantidad de recursos disponibles, no del número de componentes de procesamiento de contenido.
Elegir los recursos de hardware de los servidores host
Cada componente de búsqueda y base de datos de búsqueda requiere una cantidad mínima de recursos de hardware del servidor host para funcionar bien. Pero, cuantos más recursos de hardware tenga, mejor será el rendimiento de su arquitectura de búsqueda. Por ello, es aconsejable tener más de la cantidad mínima de recursos de hardware. Los recursos que necesita cada componente de búsqueda dependen de la carga de trabajo, principalmente determinada por la tasa de rastreo, la tasa de consultas y el número de elementos indizados.
Por ejemplo, al hospedar máquinas virtuales en Windows Server 2008 R2 Service Pack 1 (SP1), no puede usar más de cuatro núcleos de CPU por máquina virtual. Con Windows Server 2012 o posterior, puede usar ocho o más núcleos de CPU por máquina virtual. Después puede escalar horizontalmente con más núcleos de CPU para cada máquina virtual en lugar de escalar verticalmente con más máquinas virtuales. Configure servidores o máquinas virtuales que hospeden los mismos componentes de búsqueda, con los mismos recursos de hardware. Vamos a usar el componente de índice como un ejemplo. Al hospedar particiones de índice en máquinas virtuales, la máquina virtual con el rendimiento más débil determina el rendimiento de toda la arquitectura de búsqueda.
Recursos de almacenamiento generales
Asegúrese de que cada servidor host tenga suficiente espacio en disco para la instalación base del sistema operativo Windows Server y para los archivos de programa de SharePoint Server. El servidor host también necesita espacio en disco libre para diagnósticos como los registros, las depuraciones y las creaciones de volcados de memoria, para las operaciones diarias y para el archivo de paginación. Normalmente, 80 GB de espacio en disco son suficientes para el sistema operativo Windows Server y para los archivos de programa de SharePoint Server.
Agregue almacenamiento para el espacio de registro de SQL de cada servidor de bases de datos. Si no establece el servidor de bases de datos para que realice copias de seguridad de las bases de datos con frecuencia, el espacio de registro de SQL usará mucho almacenamiento. Para obtener más información sobre cómo planear bases de datos SQL, vea Configuración y planeamiento de capacidad de almacenamiento y SQL Server (SharePoint Server).
El almacenamiento mínimo que necesita la base de datos de informes de Analytics puede variar. Esto se debe a que la cantidad de almacenamiento depende de cómo interactúen los usuarios con SharePoint Server. Cuando los usuarios interactúan con frecuencia, por lo general hay más eventos para almacenar. Compruebe la cantidad de almacenamiento que su arquitectura de búsqueda actual usa para la base de datos de Analytics y asigne al menos esta cantidad para su topología rediseñada.
Recursos de hardware mínimos de la granja de búsqueda pequeña
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | Memoria RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones con componentes de rastreo, administración de búsqueda, Analytics y procesamiento de contenido. | A, B | 200 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de base de datos que tiene todos los componentes de búsqueda. | C, D | 100 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es almacenamiento de 500 GB, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos de la granja de búsqueda mediana
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | Memoria RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones que tiene un componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones con componentes de procesamiento de contenido y Analytics. | E, F | 300 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de aplicaciones con componentes de rastreo, administración de búsqueda, y procesamiento de contenido. | E, F | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidor de base de datos que tiene todos los componentes de búsqueda. | G, H | 400 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es almacenamiento de 500 GB, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos de la granja de búsqueda grande
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos.
| Servidor | En hospedaje | Almacenamiento | Memoria RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | A, B, C, D, E, G, H | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidor de aplicaciones que tiene un componente de índice. | A, B, C, D, E, F, G, H, I, J | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 núcleos de CPU2,3 | 1 Gbps |
| Servidores de aplicaciones con componentes de procesamiento de contenido y Analytics | K, L, M, N | 300 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de aplicaciones con componentes de rastreo y administración de búsqueda. | K, L | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de base de datos que contienen componentes de búsqueda. | O, P, Q, R | 500 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
número arábigoCon SharePoint Server 2013, la cantidad mínima de recursos necesarios es 500 GB de RAM, 16 GB de RAM y cuatro núcleos de CPU.
3Con SharePoint Server 2016 también puede usar almacenamiento de 250 GB, 16 GB de RAM y cuatro núcleos de CPU, pero cada componente de índice solo puede contener 10 millones de elementos y la granja de servidores de búsqueda solo admite el mismo volumen de contenido que una granja de servidores de búsqueda de SharePoint Server 2013.
Recursos de hardware mínimos para la granja de servidores de búsqueda de gran tamaño adicional
En esta tabla se muestra la cantidad mínima de recursos de hardware que necesita cada servidor de aplicaciones o servidor de bases de datos. Solo puede compilar esta granja de servidores de ejemplo con SharePoint Server 2016.
| Servidor | En hospedaje | Almacenamiento | Memoria RAM | Procesador1 | Ancho de banda de red |
|---|---|---|---|---|---|
| Servidor de aplicaciones que tiene componentes de índice. | A-X | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz y 8x | 1 Gbps |
| Servidor de aplicaciones que tiene componentes de procesamiento de consultas e índice. | Y, Z | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz y 8x | 1 Gbps |
| Servidores de aplicaciones que tienen componentes de rastreo, administración de búsquedas o procesamiento de contenido | AA-AF | 100 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de aplicaciones que tienen componentes de procesamiento de análisis | AG, AH | 800 GB | 8 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
| Servidores de bases de datos que tienen bases de datos de búsqueda | AI-AL | 500 GB | 16 GB | Cuatro núcleos de CPU a 1,8 GHz | 1 Gbps |
1Aquí se especifica el número de núcleos de CPU, no el número de subprocesos de CPU.
Planear el rendimiento del almacenamiento
La velocidad del almacenamiento afecta al rendimiento de la búsqueda. Asegúrese de que el almacenamiento que tiene sea lo suficientemente rápido como para controlar el tráfico de los componentes de búsqueda y las bases de datos. La velocidad del disco se mide en operaciones de E/S por segundo (IOPS).
El rendimiento de la búsqueda también se ve afectado por el modo en que decida distribuir los datos de los componentes de búsqueda y del sistema operativo por el almacenamiento. Una buena idea sería:
Divida los archivos del sistema operativo Windows Server, los archivos de programa de SharePoint Server y los registros de diagnóstico en tres volúmenes de almacenamiento o particiones independientes con un rendimiento normal.
Almacene los datos del componente de búsqueda en una partición o volumen de almacenamiento aparte. Para los componentes de índice, este almacenamiento también debe tener alto rendimiento.
Nota:
Puede establecer una ubicación personalizada para los datos del componente de búsqueda al instalar SharePoint Server en un host. Cualquier componente de búsqueda en el hospedaje que necesite almacenar datos, se almacena en esta ubicación. Para cambiar esta ubicación más adelante, tiene que volver a instalar SharePoint Server.
Elegir tipo de almacenamiento
Vea Almacenamiento y configuración y planeamiento de capacidad de SQL Server (SharePoint Server 2013) para obtener información general sobre las arquitecturas de almacenamiento y los tipos de disco. Los servidores que hospedan los componentes de índice, procesamiento de análisis y administración de búsqueda, o las bases de datos de búsqueda, precisan de un almacenamiento que pueda mantener una baja latencia y proporcionar al mismo tiempo suficientes operaciones de E/S por segundo (IOPS). En las siguientes tablas se indica el número de E/S por segundo que cada una de estas bases de datos o componentes de búsqueda necesita.
Si implementa un almacenamiento compartido de tipo SAN/NAS, la carga de disco máxima de un componente de búsqueda suele coincidir con la carga de disco máxima de otro componente de búsqueda. Para obtener el número de IOPS que la búsqueda requiere del almacenamiento compartido, es necesario incluir el requisito de IOPS de cada uno de estos componentes.
Requisitos de IOPS del componente de búsqueda
| Nombre del componente | Detalles del componente | Requisitos de IOPS | Uso de volumen/partición de almacenamiento aparte |
|---|---|---|---|
| Componente de índice | Usa almacenamiento al combinar el índice y al tratar y responder consultas. | 300 IOPS por cada 64 KB de lecturas aleatorias. 100 IOPS por cada 256 KB de escrituras aleatorias. 200 MB/s para lecturas secuenciales. 200 MB/s para escrituras secuenciales. |
Sí |
| Componente Analytics | Analiza los datos localmente, en procesamientos masivos. | No | Sí |
| Componente de rastreo | Almacena el contenido descargado localmente antes de enviarlo al componente de procesamiento de contenido. El almacenamiento queda limitado al ancho de banda de la red. | No | Sí |
Requisitos de IOPS de la base de datos de búsqueda
| Nombre de la base de datos | Requisitos de IOPS | Carga típica en un subsistema de E/S. |
|---|---|---|
| Base de datos de rastreo | IOPS entre medio y alto | Tasa de rastreo de 10 IOPS por documento y segundo (DPS). |
| Base de datos de vínculo | IOPS medio | 10 IOPS por millón de elementos en el índice de búsqueda. |
| Base de datos de administración de búsqueda | IOPS bajo | No procede. |
| Base de datos de informes de Analytics | IOPS medio | No procede. |
Decidir de qué manera la arquitectura de búsqueda admitirá la alta disponibilidad
Si no está familiarizado con las estrategias de alta disponibilidad, este es un artículo que le ayudará a empezar: Creación de una arquitectura y una estrategia de alta disponibilidad para SharePoint Server. Al hospedar bases de datos y componentes de búsqueda redundantes en dominios de error independientes, una interrupción en una parte de la granja de servidores no quita el servicio completo. Sin embargo, el rendimiento de la búsqueda se degradará porque los componentes de búsqueda ya no pueden compartir la carga. Para reducir la posibilidad de perder un único servidor, es una buena idea mejorar la redundancia local. Para cada servidor host de la arquitectura de búsqueda:
Use almacenamiento RAID en cada servidor.
Instale varias conexiones de red redundantes en cada servidor.
Instale varias fuentes de alimentación redundantes con cableado independiente o una fuente de alimentación ininterrumpida (UPS) para cada servidor.
Todos los ejemplos de arquitecturas de búsqueda hospedan componentes de búsqueda redundantes en servidores independientes. En los ejemplos de arquitecturas de búsqueda, el hospedaje situado más a la derecha en cada par de hospedaje es redundante. Esta es la arquitectura de búsqueda amplia con los hospedajes redundantes indicados:
