Rediseño de la topología de búsqueda empresarial para requisitos de rendimiento específicos en SharePoint
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
Si el entorno de búsqueda tiene rendimiento específico que no se haya cumplido al seguir las instrucciones en Planear la arquitectura de búsqueda empresarial en SharePoint Server 2016, la solución es escalar la topología de la arquitectura de búsqueda de Enterprise Search:
Rediseñar la topología (este artículo)
Implementar la topología rediseñada (Administrar la topología de búsqueda en SharePoint Server)
¿Conoce los componentes del sistema de búsqueda de SharePoint Server 2016 y el modo en que 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 para cumplir requisitos de rendimiento específicos:
Paso 1: ¿Cuáles son los requisitos de rendimiento específicos?
Paso 3: Decidir si los servidores ejecutarán de manera física o virtual
Paso 4: ¿Qué servidor se va a usar para hospedar qué base de datos o componente de búsqueda?
Paso 5: ¿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áles son los requisitos de rendimiento específicos?
Asegúrese de que entiende las necesidades empresariales detrás de los requisitos de rendimiento específicos. Por ejemplo, la búsqueda financiera y de noticias requiere que los datos actualizados se indexen casi en tiempo real, mientras que los servicios de soporte de litigación requieren la ingesta de lotes de datos que se indexan una vez. Exprese los requisitos de rendimiento en una o más de estas formas:
El número de elementos indexados.
Cuántos elementos debe rastrear la solución de búsqueda por segundo y con qué latencia.
Cuántas consultas debe servir la solución de búsqueda por segundo y con qué latencia.
Además de estos requisitos de rendimiento, el entorno también puede tener requisitos para que la relevancia de los resultados de consultas y para que la topología de búsqueda sea redundante. A veces no tiene un requisito de rendimiento específico, pero ha identificado un cuello de botella en la arquitectura de búsqueda que puede afectar al rendimiento. Hablaremos de eso también.
Paso 2: ¿Qué componentes de la búsqueda debo escalar?
Para proporcionar un rendimiento más alto para quitar un cuello de botella, puede agregar más componentes de búsqueda para hacer el trabajo o puede agregar más recursos a los servidores que hospedan componentes de búsqueda. La adición de más componentes de búsqueda se conoce como escalado horizontal, mientras que la adición de más recursos a los servidores se conoce como escalado vertical. Los componentes de servidores que se van a escalar horizontalmente o los servidores que se van a escalar verticalmente dependen de la métrica de rendimiento que se va a mejorar o del cuello de botella que se va a quitar. Estos son algunos ejemplos:
Si el entorno requiere una tasa de consultas más alta y los recursos de CPU para indexar un cuello de botella, agregue otra réplica de índice a cada partición del índice. Esto permite que la búsqueda atienda más consultas en paralelo.
Si los recursos de CPU para procesar contenido rastreado son un cuello de botella, escale el número de componentes de procesamiento de contenido. También puede escalar los componentes de procesamiento de contenido ejecutándolos en servidores con CPU más rápidas. Cualquier forma de escalar implica más recursos de CPU para procesar contenido.
Si los componentes de análisis no completan sus análisis con bastante rapidez, escale verticalmente los recursos del procesador, IOPS de disco o ancho de banda de red de los servidores que hospedan componentes de análisis.
Tenga en cuenta que no admitimos escalado horizontal ilimitado del número de componentes de búsqueda o bases de datos. Consulte los límites máximos en Límites de búsqueda y permanezca dentro de esos límites para asegurar una comunicación oportuna y sólida entre las bases de datos y los componentes de búsqueda. Si es necesario, reduzca la capacidad de su arquitectura de búsqueda reduciendo el número de componentes de búsqueda.
En las siguientes secciones ofrecemos instrucciones sobre las bases de datos o componentes de búsqueda que puede escalar para satisfacer cada requisito:
Cómo aumentar la tasa de ingesta y la actualización de los resultados
Cómo reducir la latencia de consultas y aumentar el rendimiento de consultas
Cómo hacer que las bases de datos y componentes de búsqueda sean redundantes
Cómo controlar más elementos en el índice
Cuando la cantidad de elementos indexados aumenta mientras los elementos indexados cambian a la misma velocidad que antes, aumente la capacidad de su topología de búsqueda escalando horizontalmente estas bases de datos y componentes de búsqueda:
| Base de datos o componente de búsqueda | Instrucciones |
|---|---|
| Componente de índice | Use una partición de índice para cada 20 millones1 de elementos indexados. Cada partición contiene una o más réplicas de la partición. Todas las particiones deben tener el mismo número de réplicas. Un componente de índice representa una réplica de índice. Por ello, si desea dos réplicas del índice, necesitará dos veces más componentes de índice que particiones de índice. Por ejemplo, un índice redundante con 80 millones2 de elementos necesita cuatro particiones. Ocho componentes de índice representan las cuatro particiones cuando se usan dos réplicas para cada partición. |
| Base de datos de rastreo | Use una base de datos de rastreo para cada 20 millones de elementos en el corpus de contenido. Por ejemplo, un índice con 100 millones de elementos necesita cinco bases de datos de rastreo. Si el aumento de la cantidad de elementos indexados implica una tasa de rastreo más alta, también necesita más recursos de IOPS para atender las bases de datos de rastreo. Si la tasa de rastreo es de un documento por segundo, la base de datos de rastreo necesita aproximadamente 10 IOPS. |
| Base de datos de vínculo | Use una base de datos de vínculo para cada 60 millones de elementos en el corpus de contenido. Por ejemplo, un índice con 100 millones de elementos necesita dos bases de datos de vínculo. Si el contenido agregado implica una tasa de rastreo más alta, puede que necesite más recursos de IOPS para atender las bases de datos de vínculo. |
| Base de datos de informes de Analytics | La cantidad de bases de datos de informes de Analytics que necesita depende de la forma en que el entorno de búsqueda usa el análisis y con qué frecuencia. En general, agregue una base de datos de informes de Analytics cuando el rendimiento de análisis empiece a disminuir. Por ejemplo, cuando la actualización nocturna de la base de datos empiece a tardar más. Esto puede suceder cuando la base de datos alcance un tamaño de 250 GB, o 20 millones de filas en total, o cuando en número de vistas por día alcance 500.000 elementos únicos. |
110 millones de elementos con SharePoint Server 2013 o con SharePoint Server 2016 en ejecución con menos recursos que 500 GB de almacenamiento, 32 GB de RAM y ocho núcleos de CPU.
240 millones de elementos con SharePoint Server 2013 o con SharePoint Server 2016 en ejecución con menos recursos que 500 GB de almacenamiento, 32 GB de RAM y ocho núcleos de CPU.
Cómo aumentar la tasa de ingesta y la actualización de los resultados
Hay algunas situaciones en las que tal vez necesite aumentar la tasa de ingesta. Un ejemplo es si el entorno necesita resultados muy recientes y el volumen de contenido está cerca del límite superior de elementos para su arquitectura de búsqueda o el contenido cambia con frecuencia. El contenido puede cambiar con frecuencia si las personas solían archivar archivos en un sitio de equipo, pero ahora almacenan sus archivos en OneDrive mientras trabajan en ellos. La búsqueda indexa todos los cambios que los usuarios realizan en los archivos.
Es útil entender los factores que influyen en la velocidad con la que la búsqueda puede ingerir elementos:
La rapidez con la que la búsqueda puede rastrear elementos. Esto depende de lo siguiente:
La velocidad de la conexión entre los componentes de rastreo y los orígenes de contenido.
El tipo y tamaño promedio de los elementos que se van a rastrear.
El rendimiento del servidor de SQL Server que hospeda las bases de datos de rastreo.
La cantidad de recursos de memoria y CPU que tienen los componentes de rastreo.
La cantidad de procesamiento de contenido que necesita cada elemento antes de la indización.
La cantidad de particiones que tiene el índice. Una mayor cantidad de particiones permite que la búsqueda propague la carga de indización.
Esto es lo que se debe hacer:
Compruebe la actualización de los resultados en la granja buscando la distribución por antigüedad de los elementos rastreados. En el sitio web de Administración central de SharePoint, vaya a Informes de mantenimiento de rastreo y seleccione Actualización de rastreo. La distribución por antigüedad que es aceptable para su granja depende de los requisitos de su empresa. Este es un ejemplo: si la página Actualización de rastreo muestra que se necesitan cuatro horas para indexar 90 % del contenido, pero su requisito es de 30 minutos, aumente la tasa de ingesta.
En la página Actualización de rastreo, identifique los períodos del día en que los resultados no están lo suficientemente actualizados.
Siga las instrucciones para aumentar la velocidad de ingesta en estos períodos de tiempo.
Mejorar la actualización para un origen de contenido específico
Consulte la programación de rastreo e identifique los orígenes de contenido que la búsqueda rastrea en los períodos de tiempo en que la actualización es baja. Si la actualización es baja para un origen de contenido específico, considere hacer lo siguiente:
Aumente la velocidad de la conexión entre el servidor que hospeda el componente de rastreo y dicho origen de contenido. La tasa de rastreo, que descarga elementos de los orígenes de contenido y pasa elementos al componente de procesamiento de contenido, impulsa la necesidad de un ancho de banda de red para el componente de rastreo.
Si el origen de contenido es SharePoint, es posible que esa granja necesite más destinos de rastreo y que estos sean dedicados. Lea sobre los destinos de rastreo en Administración de carga de rastreo (SharePoint Server 2010).
Mejore el rendimiento de la base de datos de contenido. Obtenga información sobre cómo hacerlo en Procedimientos recomendados para SQL Server en una granja de servidores de SharePoint.
Aumentar los recursos de procesamiento para el rastreo
Si el componente de rastreo usa con frecuencia el 100 % de los recursos de procesador, considere la posibilidad de agregar otro componente de rastreo o de agregar más recursos de procesador a los servidores que hospedan los componentes de rastreo. La tasa de rastreo, la detección de vínculos y la administración de rastreo impulsa la necesidad de disponer de recursos de procesador. Normalmente, el rastreo es lo suficientemente rápido cuando se usan dos componentes de rastreo en arquitecturas de búsqueda como las arquitecturas de búsqueda de ejemplo pequeñas y medianas que probó Microsoft. Es posible que las arquitecturas de búsqueda grande y extragrande necesiten más de dos componentes de rastreo.
Aumentar los recursos de procesamiento para la base de datos de rastreo
Consulte si los servidores de SQL Server que hospedan bases de datos de rastreo tienen suficientes recursos. Obtenga información sobre cómo hacerlo en Procedimientos recomendados para SQL Server en una granja de servidores de SharePoint.
Si todas las bases de datos de rastreo usan muchos recursos de procesador, considere la posibilidad de agregar más recursos de procesador al servidor SQL Server que hospeda las bases de datos o agregue otro servidor SQL Server con el mismo número de bases de datos de rastreo que los servidores existentes de SQL Server. Si, por ejemplo, tiene dos servidores SQL Server que tienen tres bases de datos de rastreo, agregue otro servidor SQL Server con tres bases de datos de rastreo.
Si solo una o unas cuantas bases de datos de rastreo usan muchos recursos de procesador, significa que la carga es desigual en las bases de datos de rastreo. Considere la posibilidad de volver a equilibrar el contenido en todas las bases de datos de rastreo. Tenga en cuenta que durante el reequilibrado la búsqueda pone en pausa el rastreo, por lo que los resultados están menos actualizados durante el reequilibrado y hasta que el rastreo se ha puesto al día con los cambios que tuvieron lugar durante la pausa. Puede desencadenar el reequilibrado con el botón Equilibrio en la página Bases de datos. En Administración de búsqueda, vaya a Registro de rastreo y seleccione Bases de datos.
Aumentar los recursos de memoria y procesamiento para el procesamiento de contenido
Si el componente de procesamiento de contenido usa cerca del 100% de los recursos de CPU, considere la posibilidad de agregar más componentes de procesamiento de contenido o agregar más recursos de CPU a los servidores que hospedan componentes de procesamiento de contenido.
Si se da cuenta de que la memoria reinicia con frecuencia, considere la posibilidad de aumentar la cantidad de memoria en los servidores que hospedan componentes de procesamiento de contenido. 2 GB de memoria de trabajo por núcleo de CPU es una buena regla de oro.
Aumentar el número de particiones de índice
Compruebe la actividad de procesamiento de contenido. Para encontrarla, vaya a Administración de búsqueda, seleccione Informe de mantenimiento de rastreo y después seleccione Actividad de procesamiento de contenido. Si la indización es la actividad que tarda más tiempo, considere la posibilidad de dividir el índice en más particiones. Una mayor cantidad de particiones de índice permite que la búsqueda propague la carga de indización.
Si agrega más particiones en una instalación en ejecución, el índice se vuelve a particionar solo. Se pueden necesitar varias horas, o días, para que el índice se vuelva a particionar. La cantidad de tiempo que tarde depende del estado de la granja cuando empiece el reparticionamiento.
Cómo reducir la latencia de consultas y aumentar el rendimiento de consultas
La cantidad de consultas que la búsqueda puede atender por segundo se conoce como rendimiento de consultas. El rendimiento de consultas depende del tiempo que la búsqueda usa para procesar una consulta y cualquier tiempo que la consulta espera porque un recurso de procesamiento no está disponible. La suma del tiempo de espera y procesamiento se conoce como latencia de consulta. La reducción de la latencia de consulta aumenta el rendimiento de consultas. Para reducir la latencia de consulta, siga una o las dos instrucciones siguientes:
| Instrucciones |
|---|
| Reducir el tiempo de procesamiento para las consultas |
| Reducir el tiempo de espera para las consultas |
Reducir el tiempo de procesamiento para las consultas
Considere la posibilidad de agregar más particiones al índice. Una mayor cantidad de particiones significa menos elementos en cada partición. Una menor cantidad de elementos significa que cada partición responde más rápido a las consultas. Pero tener demasiadas particiones tampoco es bueno. Dado que el componente de procesamiento de consultas tiene que combinar las respuestas de cada partición para producir una respuesta a una consulta, una combinación tarda más tiempo cuando el índice tiene más particiones. Todas las particiones deben tener el mismo número de réplicas.
Cuando agrega más particiones en una instalación en ejecución, el índice se vuelve a particionar solo. Se pueden necesitar varias horas, o días, para que el índice se vuelva a particionar. La cantidad de tiempo que tarde depende del estado de la granja cuando empiece el reparticionamiento.
Reducir el tiempo de espera para las consultas
Considere estas acciones:
Agregue más réplicas del índice. Cuando agrega más réplicas, la búsqueda distribuye las consultas en las réplicas y trabaja con ellas en paralelo. Un componente de índice representa una réplica de índice. Todas las particiones deben tener el mismo número de réplicas, por lo que debe agregar un componente de índice a cada partición del índice. Cuando agrega componentes de índice como réplicas a particiones existentes en una instalación en ejecución, la búsqueda propaga automáticamente las nuevas réplicas con datos de la partición de índice. Pueden pasar varias horas antes de que las nuevas réplicas sean operativas.
Agregue más memoria a los servidores que hospedan componentes de índice.
En los servidores que hospedan componentes de índice, cambie a almacenamiento más rápido para el índice, por ejemplo, una unidad de estado sólido (SSD).
Agregue más recursos de procesador a los servidores que hospedan componentes de índice. A continuación, los componentes controlan más consultas por segundo. Por ejemplo, si el servidor tiene una CPU de 2 GHz, un núcleo puede controlar:
5 consultas por segundo cuando hay 1 millón de elementos en el índice.
2 consultas por segundo cuando hay 5 millones de elementos en el índice.
1 consulta por segundo cuando hay 10 millones de elementos en el índice.
Agregue más recursos de procesador a los servidores que hospedan componentes de procesamiento de consultas. A continuación, los componentes controlan más consultas por segundo, particularmente cuando las consultas son poco frecuentes y complejas. La tasa de consultas y el número de transformaciones de consultas impulsan la necesidad de recursos de procesamiento para el componente de procesamiento de consultas. Un componente de procesamiento de consultas normalmente necesita un núcleo de CPU por 4 consultas por segundo.
Cómo disminuir el tiempo de procesamiento de análisis
El procesamiento de análisis tiene lugar cada noche. El componente de procesamiento de análisis almacena datos inmediatos en el servidor que hospeda el componente y almacena los resultados del análisis en la base de datos de informes de Analytics. Si un error obstaculiza el procesamiento de análisis, no se afectará el rastreo de documentos o la respuesta de consultas. Pero los resultados de consulta no tendrán una relevancia óptima.
Considere estas acciones:
Si su entorno requiere relevancia óptima para resultados de consultas y el procesamiento de análisis no es lo suficientemente rápido para satisfacer este requisito, agregue más discos (cilindros) o discos más rápidos.
Si el procesamiento de análisis empieza a tardar más de lo normal, agregue una base de datos de informes de Analytics. Puede ver un aumento semejante cuando la base de datos alcanza un tamaño de 250 GB, o 20 millones de filas en total, o cuando el número de vistas por día alcanza 500.000 elementos únicos.
Si el procesamiento de análisis tarda más de 24 horas en completarse, agregue más componentes de procesamiento de análisis o agregue más recursos de procesador a los servidores que hospedan componentes de procesamiento de análisis. El número de elementos en el índice y la actividad del sitio impulsan la necesidad de recursos de procesador.
Si el procesamiento de análisis nunca se completa, o si obtiene alertas de mantenimiento para los discos en los servidores que hospedan componentes de análisis, agregue más espacio en disco en los servidores. Para que el componente de análisis procese la mayor cantidad de datos intermedios con más rapidez, considere la posibilidad de agregar más componentes de procesamiento de análisis al servidor que hospeda el componente de procesamiento de análisis.
Cómo hacer que las bases de datos y componentes de búsqueda sean redundantes
Una arquitectura de búsqueda admite la alta disponibilidad cuando las bases de datos y componentes de búsqueda redundantes se hospedan en dominios de error distintos. Se recomienda diseñar la topología de búsqueda con componentes y bases de datos de búsqueda redundantes. Todas las arquitecturas de búsqueda de ejemplo que Microsoft ha probado tienen componentes de búsqueda redundantes y bases de datos, es posible que le resulte útil estudiar estos ejemplos al trabajar en su propia topología (vea Arquitecturas de búsqueda empresarial para SharePoint 2016).
Siga estas instrucciones:
Volver redundante el índice
El índice es redundante si tiene dos o más réplicas de índice por partición de índice. Si hay un error en un servidor que hospeda una réplica de índice, esto puede reducir el rendimiento, pero la búsqueda puede seguir atendiendo consultas y elementos de índice. Pero si el entorno requiere el mismo rendimiento todas las veces, la búsqueda necesita más componentes de índice redundantes. Por ejemplo: diseñó su topología de búsqueda con dos réplicas por partición para reducir el tiempo de espera para consultas y su entorno requiere un tiempo de espera breve para las consultas todo el tiempo. Aumente el número de réplicas de índice por partición.
Todas las particiones deben tener el mismo número de réplicas. Un componente de índice representa una réplica de índice. Por ello, si desea dos réplicas del índice, necesitará dos veces más componentes de índice que particiones de índice. Por ejemplo, con SharePoint Server 2016un índice redundante con 80 millones de elementos se necesitan cuatro particiones. Ocho componentes de índice representan las cuatro particiones cuando se usan dos réplicas para cada partición.
Si agrega componentes de índice como réplicas a particiones existentes en una instalación en ejecución, la búsqueda propaga automáticamente las nuevas réplicas con datos de la partición de índice. Pueden pasar varias horas antes de que las nuevas réplicas sean operativas.
Volver redundantes los componentes de rastreo, procesamiento de contenido, procesamiento de consultas, procesamiento de análisis y administración de búsqueda
Vamos a usar el componente de búsqueda como un ejemplo. Si necesita quitar uno de los servidores que hospedan un componente de rastreo para darle mantenimiento, esto podría reducir la actualización de los resultados, pero la búsqueda aún puede rastrear todo el contenido. Pero si el entorno requiere la misma actualización de resultados todo el tiempo, la búsqueda necesita más componentes de rastreo redundantes. Por ejemplo: diseñó su topología de búsqueda con tres componentes de rastreo y desea la misma actualización de resultados aun cuando dos servidores de componentes de rastreo generen errores. Agregué otros dos componentes de rastreo.
El componente de administración de búsqueda es una excepción a este principio. Un componente de administración de búsqueda tiene suficiente capacidad para una topología de búsqueda de cualquier tamaño. Por ello, dos componentes de administración de búsqueda son suficientes para lograr redundancia.
Los componentes de procesamiento de contenido equilibran la carga entre sí, por lo que los componentes de procesamiento de contenido redundantes aumentan la capacidad de procesar elementos.
Volver redundantes las bases de datos de búsqueda
Para que las bases de datos de búsqueda sean redundantes, use las alternativas de alta disponibilidad que ofrece SQL Server (consulte Crear una estrategia y arquitectura de alta disponibilidad para SharePoint Server).
Paso 3: 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. Si ahora tiene muchos más componentes de búsqueda, tal vez quiera usar máquinas virtuales para facilitar la administración de la arquitectura. Por ejemplo, es más fácil reemplazar una máquina virtual con errores que una máquina física. 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.
Paso 4: ¿Qué servidor se va a usar para hospedar qué base de datos o componente de búsqueda?
Ahora que ha rediseñado su topología de búsqueda, el siguiente paso es asignar los componentes de base de datos y búsqueda a servidores virtuales o físicos. No hay una manera óptima de asignar componentes de búsqueda a servidores físicos o máquinas virtuales, pero tenemos instrucciones para usted:
Un tipo de componente de búsqueda por servidor
Cada servidor físico o máquina virtual puede hospedar solamente un componente de búsqueda de cada tipo. El componente de índice es una excepción. Los servidores físicos o máquinas virtuales pueden hospedar hasta cuatro componentes de índice. Puede leer sobre estos límites en Límites de búsqueda.
Separar componentes en tiempo real y procesamiento en masa entre sí
Evite mezclar componentes de búsqueda de procesamiento en tiempo real y de procesamiento en masa en el mismo servidor físico o máquina virtual. Los componentes de rastreo, procesamiento de contenido y procesamiento de análisis realizan procesamiento en masa. Los componentes de consulta y de índice realizan procesamiento en tiempo real.
No mezclar componentes de búsqueda que compitan entre sí
Evite mezclar componentes de búsqueda en una máquina o servidor físico si los componentes competirán por los mismos recursos. Esta es una tabla que ilustra la cantidad relativa de recursos que cada componente necesita.
Por ejemplo, tal vez no sea una buena idea poner un componente de procesamiento de análisis y uno de rastreo en el mismo servidor porque ambos usan mucho ancho de banda de red. Pero, si el servidor físico o la máquina virtual tiene suficiente capacidad red, los componentes no competirán.
Otro ejemplo es el de la arquitectura de búsqueda extragrande que probó Microsoft. En este caso hemos introducido los componentes de administración de rastreo y de búsqueda en máquinas virtuales independientes. Esto beneficia la velocidad de rastreo porque, de lo contrario, los dos componentes podrían competir por hacerse con los recursos del procesador.
Usar dominios de error
Asigne componentes de búsqueda redundantes a los hosts en dominios de error separados.
Paso 5: ¿Cuáles son los requisitos de hardware que debo contemplar?
El siguiente paso es planear el hardware que necesitará:
Elegir la cantidad de recursos de hardware de los servidores host
Recursos mínimos para el componente de procesamiento de análisis
Decidir de qué manera la arquitectura de búsqueda admitirá la alta disponibilidad
Elegir la cantidad de 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.
Almacenamiento general
Procure que cada servidor host tenga espacio en disco suficiente para la instalación base del sistema operativo Windows Server y los archivos de programa de SharePoint Server 2016. 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. Por lo general, 80 GB de espacio en disco suele ser suficiente para el sistema operativo Windows Server y los archivos de programa de SharePoint Server 2016.
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úan los usuarios con SharePoint Server 2016. 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 mínimos para el componente de índice
Estos son los recursos mínimos que un servidor o máquina virtual debe tener para hospedar un componente de índice o para hospedar un componente de índice y un componente de procesamiento de consultas:
| Almacenamiento | Memoria | Procesador | Ancho de banda de red |
| 500 GB para el índice1 | 32 GB1 | 64 bits, 8 núcleos como mínimo1, 2. | 2 Gbps |
1Con SharePoint Server 2013, la cantidad mínima de recursos es de 500 GB de almacenamiento, 16 GB de RAM y cuatro núcleos de CPU.
2Puede usar 16 GB RAM y 4 núcleos de CPU con SharePoint Server 2016, pero en ese caso cada componente de índice podrá contener como máximo 10 millones de elementos (en lugar de 20 millones de elementos)
Recursos mínimos para el componente de procesamiento de análisis
Estos son los recursos mínimos que un servidor o máquina virtual debe tener para hospedar un componente de procesamiento de búsqueda:
| Almacenamiento | Memoria | Procesador | Ancho de banda de red |
| 300 GB para el procesamiento local de análisis | 8 GB | 64 bits, 4 núcleos mínimo, pero 8 núcleos recomendados. | 2 Gbps |
Si el servidor hospeda un componente de procesamiento de análisis y uno o más componentes de procesamiento en masa, aumente la memoria a 16 GB.
Recursos mínimos para los componentes de rastreo, procesamiento de contenido, procesamiento de consulta y administración de búsqueda
Estos son los recursos mínimos que un servidor o máquina virtual debe tener para hospedar uno de estos componentes:
| Almacenamiento | Memoria | Procesador | Ancho de banda de red |
| No necesario | 8 GB | 64 bits, 4 núcleos mínimo, pero 8 núcleos recomendados. | 2 Gbps |
Si el servidor hospeda dos o más de estos componentes, aumente la memoria a 16 GB.
El componente de procesamiento de consultas requiere un buen ancho de banda de red. El número de particiones de índice y el tamaño de las consultas y los resultados impulsan esta necesidad de ancho de banda de red. Por ejemplo, 20 consultas por segundo por componente de procesamiento de consultas (20 CPS/CPC) y un índice con 20 particiones de índice resulta en un tráfico entrante de 200 Mbps y tráfico saliente de 100 Mbps para el servidor o máquina virtual que hospeda el componente de procesamiento de consulta.
Recursos mínimos para las bases de datos de búsqueda
Estos son los recursos mínimos que debe tener un servidor o máquina virtual para poder hospedar una o varias bases de datos de búsqueda:
| Almacenamiento | Memoria | Procesador | Ancho de banda de red |
| El almacenamiento que necesita la base de datos de informes de Analytics varía con la forma en que el entorno de búsqueda usa el análisis, así como la frecuencia. Use la cantidad actual de almacenamiento para la base de datos de informes de Analytics como instrucciones. | 8 GB para implementaciones pequeñas. 16 GB para implementaciones medianas |
64 bits, 4 núcleos. | 2 Gbps |
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 2016 y los registros de diagnóstico en las tres particiones o volúmenes de almacenamiento aparte con 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 datos del componente de búsqueda cuando instale SharePoint Server 2016 en un hospedaje. Cualquier componente de búsqueda en el hospedaje que necesite almacenar datos, se almacena en esta ubicación. Para cambiar esta ubicación posteriormente, tiene que volver a instalar SharePoint Server 2016.
Elegir tipo de almacenamiento
Vea Almacenamiento y configuración y planeamiento de la capacidad de SQL Server (SharePoint Server 2016) 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 varios sistemas de alimentación redundantes con cableado independiente o un sistema 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:
