Planeación de la redundancia (Search Server 2008)

Actualizado: 2008-07-31

En este artículo:

• Acerca de la redundancia

• Definición de los requisitos de redundancia de servidores

• Planeación para un nivel mínimo de redundancia de servidores

• Elección de una topología de granja de servidores de línea de base

• Planeación de la redundancia de servidores de consultas

• Planeación de la redundancia de servidores de base de datos

• Análisis de los riesgos inherentes a los errores de servidor

En este artículo se describen las opciones para escalar en horizontal las funciones de servidor redundantes incluidas en una granja de servidores de Microsoft Search Server 2008. Tras leer este artículo, podrá determinar y registrar las opciones de redundancia adecuadas para el entorno.

Antes de leer este tema, lea los siguientes temas:

• Planeación para la implementación de Search Server 2008 o Search Server 2008 Express

• Determinación de los requisitos de hardware y software (Search Server 2008)

• Planeación de la disponibilidad (Search Server 2008)

Tenga en cuenta que Search Server 2008 y Search Server 2008 Express no suelen hospedar contenido, sino que se usan principalmente para hospedar servicios de búsqueda, rastrear contenido en granjas de servidores de Windows SharePoint Services y Microsoft Office SharePoint Server, u otras fuentes de contenido remoto, y responder a consultas. En algunos entornos, Search Server 2008 y Search Server 2008 Express pueden usarse para hospedar contenido. Si planea usar Search Server 2008 o Search Server 2008 Express para hospedar contenido, lea los artículos de Planeación del rendimiento y la capacidad (Windows SharePoint Services) para asegurarse de que conoce los requisitos para hospedar contenido y ejecutar Search Server 2008 o Search Server 2008 Express en la misma granja de servidores.

Acerca de la redundancia

El término redundancia suele interpretarse de forma incorrecta como un sinónimo de disponibilidad. Aunque estos conceptos están relacionados, no son equivalentes. La redundancia hace referencia al uso de varios servidores en un entorno con equilibrio de carga para varios fines, como aumentar el rendimiento de la granja de servidores, escalar en horizontal para incluir usuarios adicionales y aumentar la disponibilidad.

La disponibilidad es un concepto más especializado que hace referencia a un entorno de varios servidores diseñado para aceptar conexiones y funcionar normalmente incluso si uno o más servidores de la granja no están operativos. Por lo tanto, la disponibilidad implica redundancia e implica, además, un mecanismo de conmutación por error y algunas otras características posibles. Sin embargo, un sistema redundante podría no tener una alta disponibilidad.

Para obtener más información acerca de la disponibilidad, vea Planeación de la disponibilidad (Search Server 2008).

En este artículo se describe el procedimiento para implementar servidores redundantes en una granja de servidores de Search Server 2008.

Definición de los requisitos de redundancia de servidor

Search Server 2008 admite granjas de servidores escalables en capacidad, rendimiento y disponibilidad. Normalmente, la capacidad es la primera consideración a la hora de determinar el número inicial de servidores. Después de factorizar el rendimiento, la disponibilidad también desempeña un papel importante en la determinación del número de servidores y el tamaño o capacidad de los servidores de una granja de servidores.

Al final de esta sección, será capaz de determinar si es necesario crear una capacidad expandible en la topología de implementación del servidor mediante la implementación de servidores redundantes, o si tiene sentido para la organización planear una implementación de servidor limitada que no tenga servidores redundantes.

Planeación para un nivel mínimo de redundancia de servidores

Para implementar una solución redundante, debe implementar una granja de servidores.

Existen varias topologías de servidor que se pueden usar como línea de base. Cada una de dichas topologías se crea con un nivel de redundancia de servidores. En esta sección se ofrece un resumen sobre estas granjas de servidores.

Topologías redundantes

En esta sección se ofrecen ejemplos de topologías redundantes.

Granja de cinco o más servidores

La topología óptima de una granja de servidores redundante introduce un servidor de índices independiente y está formada por cinco o más servidores; incluye al menos dos servidores de base de datos en una configuración en clúster y al menos dos servidores de consultas.

Con esta topología, se puede instalar la función de servidor de índices en el servidor de aplicaciones dedicado. Este diseño optimiza el rendimiento de los servidores de consultas, ya que permite descargar la indización en el nivel intermedio.

Tenga en cuenta que esta topología muestra una configuración en clúster de SQL Server que proporciona una conmutación por error manual. Para obtener más información sobre el procedimiento para configurar un clúster de SQL Server para la conmutación por error automática, vea el artículo de notas del producto de agrupación en clústeres de conmutación por error de SQL Server 2005 (en inglés) o el artículo acerca de la instalación de un clúster de conmutación por error de SQL Server 2008, según la versión de SQL Server que esté usando.

Granja de cuatro servidores

La granja de servidores más pequeña que incorpora la redundancia está compuesta por cuatro servidores:

• Servidores 1 y 2: función Consulta instalada en ambos equipos.

• Servidores 3 y 4: servidor de base de datos en clúster o reflejado.

Cuando se usa una granja de cuatro servidores, se debe decidir cuidadosamente dónde implementar la función de servidor de índices. La función Consulta no se puede implementar en el servidor de índices y en otro servidor de la granja para obtener redundancia. Esto se debe a que cuando la función Índice se instala en el mismo servidor que la función Consulta, la función Índice ya no propaga los índices de contenido a otros servidores de consultas. En consecuencia, si instala la función de servidor de índices en uno de los servidores web, perderá la posibilidad de hospedar la función Consulta en los dos servidores web. Se puede instalar la función Índice en el servidor de base de datos, con lo que se logra la redundancia de la función Consulta en los servidores web. Sin embargo, el rendimiento del servidor de base de datos se verá afectado, especialmente cuando se esté rastreando contenido.

Granja de tres servidores

Existe otra alternativa para obtener redundancia cuando se implementan pocos servidores. Cuando se usa una granja de tres servidores, debe decidir cuál de las funciones de servidor se hará redundante: la función de servidor web o la función de servidor de base de datos.

Si agrega un tercer servidor al nivel de servidores web, conseguirá la redundancia de la función de servidor web. Las funciones Consulta e Índice pueden instalarse en el mismo servidor web (vea la opción A de esta sección) o en diferentes servidores web (vea la opción B de esta sección).

Con esta topología, la función Consulta no se puede implementar en ambos servidores web para conseguir redundancia. Esto se debe a que, si la función de servidor de consulta está instalada en el mismo servidor que el servidor de índices, el servidor de índices no propagará el índice a otros servidores de consultas. Sin embargo, puede instalar la función Índice en el servidor de base de datos. Esto permite implementar la función Consulta en ambos servidores web. No obstante, el rendimiento del servidor de base de datos se verá afectado.

Aunque la disponibilidad es limitada, dedicar dos servidores a la función de servidor web aumenta el rendimiento global de una granja de servidores pequeña. Use esta topología cuando el rendimiento sea más importante que la redundancia de datos.

Topologías no redundantes

Las topologías no redundantes pueden contener más de un servidor, pero no son redundantes porque sólo hay un servidor para cada función de servidor. Por ejemplo, una granja de servidores que contiene un servidor de consultas, un servidor de índices y un servidor de base de datos no es redundante.

Si no tiene que crear más capacidad y rendimiento en la implementación de servidores, el punto inicial de la topología de servidores es uno o dos servidores. Para un uso limitado, puede implementar un único servidor Search Server 2008 o implementar Microsoft Search Server 2008 Express, que se limita a un único servidor de aplicaciones.

En los siguientes diagramas se muestran ejemplos de topologías no redundantes.

Elección de una topología de granja de servidores de línea de base

Cada una de las topologías de granja de servidores descritas en este artículo representa el punto de partida de una línea de base para el diseño de la implementación. El punto de inicio que mejor se adapta a su organización depende de las funciones de servidor para las que debe tener redundancia.

En el resto de este artículo se describen las opciones de redundancia de cada una de las funciones de servidor. Cuando termine este artículo, será capaz de determinar la topología de línea de base que pueda aportar la redundancia que necesita su organización. Se trata de la topología que usará como línea de base cuando planee la capacidad y el rendimiento.

Planeación de la redundancia de servidores de consultas

En esta sección podrá:

• Determinar si la organización necesita incorporar la redundancia en el nivel web.

• Planear qué tecnología de equilibrio de carga de servidor de consultas se va a implementar.

La función de servidor de consultas se puede implementar en varios servidores. El código que se implementa en cada servidor es idéntico y los servidores de consultas no almacenan ningún dato. En otras palabras, cada instancia de la función de servidor de consultas permanece idéntica. Si se produce un error en uno de los servidores no se perderá ningún dato guardado. Los servidores de consultas equilibran automáticamente la carga de solicitudes a estas funciones de servidor entre los servidores de aplicaciones disponibles.

La función Consulta puede implementarse en cualquier número de servidores web. Sin embargo, existe una limitación: si la función Consulta se implementa en el mismo servidor que hospeda la función Índice, la función Consulta no podrá implementarse en ningún otro servidor. Esto se debe a que la función Índice reconoce que la función Consulta se encuentra en el mismo servidor. Por tanto, no intenta propagar el índice.

La función de servidor de aplicaciones de índice no puede ser redundante en Search Server 2008. En Search Server 2008, la función de servidor de índices está asociada con un proveedor de servicios compartidos (SSP). La función Índice crea un índice por SSP. No se pueden implementar varios servidores de índices para aumentar la capacidad. El servidor de índices está asociado con un SSP único, y en Search Server 2008, sólo se puede tener un único SSP.

El siguiente paso consiste en planear la tecnología de esquema de equilibrio de carga que se va a implementar. Search Server 2008 admite dos métodos de equilibrio de carga:

• Software, como los servicios de equilibrio de carga de red (NLB) en el sistema operativo de Windows Server 2003. NLB se ejecuta en los servidores de consultas y usa TCP/IP para enrutar las consultas. Dado que NLB y otras soluciones de equilibrio de carga de software se ejecutan en los servidores de consultas, usan recursos del sistema del servidor de consultas. Esto reduce los recursos que se pueden usar para atender las consultas. No obstante, no afecta considerablemente a los recursos del sistema y una solución de software puede controlar hasta 32 servidores de consultas.

• Hardware, como un enrutador o un conmutador. El hardware de equilibrio de carga usa la red para dirigir el tráfico de consultas entre los servidores de consultas. El hardware de equilibrio de carga resulta más costoso de configurar que el software. Sin embargo, no afecta al uso de recursos en los servidores de consultas. Search Server 2008 se puede usar con cualquier hardware de equilibrio de carga.

Aunque no se recomienda, existe un tercer método de equilibrio de carga: el equilibrio de carga por turnos con sistema de nombres de dominio (DNS). El equilibrio de carga por turnos puede usar una cantidad considerable de recursos en los servidores de consultas, por lo que es más lento que cualquier software o hardware de equilibrio de carga. No se recomienda su uso con Search Server 2008. Además, el equilibrio de carga por turnos con DNS no tiene en cuenta la carga de la sesión cuando enruta un usuario a un servidor, lo que puede provocar una sobrecarga del servidor.

El artículo acerca del procedimiento para configurar los parámetros de equilibrio de carga de red en Windows Server 2003 (https://go.microsoft.com/fwlink/?linkid=124067&clcid=0xC0A) proporciona instrucciones para configurar NLB. Si decide implementar una tecnología distinta para el equilibrio de carga, tenga en cuenta este factor durante el proceso de planeación e implementación.

Planeación de la redundancia de servidores de base de datos

Esta sección le ayudará a determinar si la redundancia de la función de servidor de base de datos es necesaria para la solución. Los temas de planeación siguientes le ayudarán a decidir qué tecnología de redundancia de base de datos es la más adecuada para el entorno. Para obtener más información, vea Planeación y diseño de la administración y el almacenamiento de bases de datos.

La función de servidor de base de datos afecta a la disponibilidad de la solución más que ninguna otra función. Si se produce un error en el servidor de consultas o en el servidor de índices, estas funciones pueden restaurarse o volver a implementarse rápidamente. Sin embargo, en caso de error en el servidor de base de datos, la solución depende de que se restaure el servidor de base de datos. Esta operación puede incluir la reconstrucción del servidor de base de datos y la posterior restauración de los datos desde el medio de copia de seguridad. En tal caso, existe la posibilidad de que pierda los datos nuevos o modificados desde la fecha del último trabajo de copia de seguridad, en función de cómo esté configurado SQL Server 2005. Además, la solución dejará de estar disponible durante el tiempo necesario para restaurar la función de servidor de base de datos.

Análisis de los riesgos inherentes a los errores de servidor

En esta sección se resumen las consecuencias que cabe esperar si se produce un error en un solo servidor de consultas o servidor de índices. Es decir, si implementa la función de servidor de consultas en un único servidor y éste genera un error, ¿qué posibles consecuencias tendrá dicho error? El hecho de conocer las posibles consecuencias le ayudará a dar prioridad a la asignación de servidores en la granja de servidores. En la tabla siguiente se enumeran las funciones del servidor de aplicaciones y se describen las consecuencias que tiene el tiempo de inactividad para cada una de ellas.

La recomendación general para redundancia es planear la instalación de la función del servidor de consultas al menos en dos servidores, si el requisito de disponibilidad para el servidor de consultas es del 99% o superior.

Si la organización puede tolerar la pérdida temporal de esta funcionalidad durante el tiempo que necesita el equipo de TI para implementar una función de servidor de aplicaciones en un servidor diferente o para restaurar el servicio en el servidor existente, considere la posibilidad de implementar la función en un único servidor de aplicaciones.

Vea también

Planeación de la disponibilidad (Search Server 2008)

Otros recursos

Planeación y diseño de la administración y el almacenamiento de bases de datos
Procedimiento para configurar los parámetros de equilibrio de carga de red en Windows Server 2003
Notas del producto de agrupación en clústeres de conmutación por error de SQL Server 2005 (en inglés)
Instalación de un clúster de conmutación por error de SQL Server 2008