Compartir a través de

Planeación de la disponibilidad (Office SharePoint Server)

  • Artículo

En este artículo se describe la disponibilidad en general, los costos y los desafíos de la disponibilidad en un entorno de Productos y Tecnologías de SharePoint, así como las estrategias y soluciones que se pueden usar en el entorno. Se recomienda leer este artículo si en la granja de servidores se ejecuta Microsoft Office SharePoint Server 2007. Podría resultar útil descargar e imprimir el modelo de disponibilidad de Office SharePoint Server 2007 (en inglés) (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0xC0A) (en inglés) que acompaña a este artículo, en el que se proporciona un resumen de tamaño póster del contenido del artículo.

Introducción a la disponibilidad

La disponibilidad es el grado con el que los usuarios consideran que un entorno de Productos y Tecnologías de SharePoint está disponible. Garantizar la disponibilidad significa asegurarse de que un sistema es resistente, es decir, que se produzcan incidentes que afecten al servicio con poca frecuencia y que se realicen acciones oportunas y eficaces cuando esto suceda. Las estrategias de disponibilidad minimizan la percepción de los usuarios de los tiempos de inactividad planeados y no planeados.

Una de las medidas más habituales de la disponibilidad es el porcentaje de tiempo de actividad expresado como número de nueves, es decir, el porcentaje de tiempo durante el que un sistema determinado está activo y en funcionamiento. Por ejemplo, se considera que un sistema con un porcentaje de tiempo de actividad de 99,999 tiene una disponibilidad de cinco nueves.

En la siguiente tabla se correlaciona el número de nueves con los equivalentes en tiempo de calendario.

Porcentaje de tiempo activo aceptable Tiempo de inactividad por día Tiempo de inactividad por mes Tiempo de inactividad por año

95

72,00 minutos

36 horas

18,26 días

99

14,40 minutos

7 horas

3,65 días

99,9

86,40 segundos

43 minutos

8,77 horas

99,99

8,64 segundos

4 minutos

52,60 minutos

99,999

0,86 segundos

26 segundos

5,26 minutos

Si puede realizar una estimación informada sobre el número de horas totales de inactividad que es probable que se produzcan, puede usar las fórmulas siguientes para calcular el porcentaje de tiempo de actividad para un año, un mes o una semana:

% de tiempo de actividad/año = 100 - (8760 - número total de horas de inactividad al año)/8760

% de tiempo de actividad/mes = 100 - ((24 * número de días del mes) - número total de horas de inactividad del mes del calendario)/(24 * número de días del mes)

% de tiempo de actividad/semana = 100 - (168 - número total de horas de inactividad de la semana)/168

Qué no es la disponibilidad

La disponibilidad no consiste en proteger y recuperar los datos ni en realizar una recuperación ante desastres, aunque estos conceptos están relacionados y debe disponer de planes de protección de datos y recuperación ante desastres en cualquier sistema con alta disponibilidad. La protección y la recuperación de datos es la necesidad empresarial general subyacente en las siguientes necesidades empresariales específicas:

  • Mantener y ser capaz de revisar más de una versión de un elemento o sitio.

  • Recuperación de sitios o elementos eliminados accidentalmente.

  • Archivar datos por motivos legales, normativos o empresariales.

  • Restauración de sistemas en el caso de errores de hardware o software inesperados.

Además, la disponibilidad no consiste en la administración de la continuación del negocio (BCM). BCM consiste en las decisiones, procesos y herramientas empresariales que se aplican por anticipado para poder enfrentarse a crisis. Una crisis puede ser local, regional o nacional, o bien estar sólo relacionada con su negocio.

Las estrategias de administración de protección de datos y disponibilidad de Productos y Tecnologías de SharePoint pueden formar parte de su plan técnico de BCM, pero el plan global de BCM debería ser mucho más completo e incluir los siguientes elementos:

  • Procedimientos documentados claramente.

  • Almacenamiento fuera del sitio de los registros empresariales clave.

  • Contactos designados claramente.

  • Formación continua del personal.

  • Mecanismos de recuperación fuera del sitio.

Costos de la disponibilidad

La disponibilidad es uno de los requisitos más caros de un sistema. Cuanto mayor sea el nivel de disponibilidad y más sistemas haya que proteger, tanto más compleja y costosa es probable que sea una solución de disponibilidad. Al invertir en disponibilidad, se incluyen los costos siguientes:

  • Hardware y software adicionales, que a menudo implican operaciones complejas entre el software, como scripts personalizados para la recuperación y la conmutación por error.

  • Complejidad operativa adicional.

Los costos que implica conseguir una alta disponibilidad deben evaluarse según sus necesidades empresariales; no es probable que todas las soluciones de una organización requieran el mismo nivel de disponibilidad. Puede ofrecer distintos niveles de disponibilidad para distintos sitios y servicios: por ejemplo, inteligencia empresarial y búsquedas o distintas granjas de servidores.

La disponibilidad es un área clave en la que los grupos de tecnología de la información (TI) ofrecen contratos de nivel de servicio (SLA) para establecer las expectativas con los grupos de clientes. Muchas organizaciones de TI ofrecen diversos SLA asociados con distintos niveles de facturación.

Nota

Al calcular la disponibilidad, la mayoría de las organizaciones excluyen o agregan horas expresamente para las actividades de mantenimiento planeado.

Retos de disponibilidad en Productos y Tecnologías de SharePoint

Una implementación de Productos y Tecnologías de SharePoint plantea los siguientes retos para proporcionar disponibilidad:

  • Mientras se aplican revisiones o se actualiza la granja de servidores, ésta no está disponible.

  • No se puede obtener la redundancia del servidor de índices al instalar la función de índice en varios servidores. Para solucionar la pérdida de un servidor de índices, debe volver a instalar el servidor y restaurarlo a partir una copia de seguridad o depender de resultados algo obsoletos mientras la búsqueda rastrea el contenido. Si lo desea, puede usar una de las técnicas descritas en Disponibilidad de la búsqueda en una granja de servidores y Disponibilidad de la búsqueda entre granjas de servidores para reducir el tiempo que se tarda en recuperar la búsqueda.

  • Productos y Tecnologías de SharePoint no reconoce la creación de reflejos de bases de datos de Microsoft SQL Server 2005. Aunque se recomienda considerar la opción de usar la creación de reflejo de SQL Server como una técnica de disponibilidad para SharePoint, esto requiere tareas de automatización adicionales.

Cuándo tener en cuenta la disponibilidad

Se recomienda tener en cuenta los requisitos de disponibilidad como parte del diseño principal de la solución SharePoint. Además, puede aumentar la disponibilidad después de implementar la solución. Desde un punto de vista operativo, se recomienda implementar y ajustar la solución principal en la granja de servidores y, a continuación, probar las soluciones de disponibilidad.

Determinación de los requisitos de disponibilidad

Para evaluar la tolerancia frente al tiempo de inactividad de un sitio, servicio o granja de servidores por parte de la organización, responda a las preguntas siguientes para el sitio, servicio o granja de servidores.

  • Si el sitio, el servicio o la granja de servidores dejan de estar disponibles, ¿dejarán los empleados de la organización de poder cumplir razonablemente sus responsabilidades laborales?

  • Si el sitio, el servicio o la granja de servidores dejan de estar disponible, ¿se detendrán las transacciones comerciales y las relaciones con los clientes, con las consiguientes pérdidas que ello supone para dichos ámbitos?

Si respondió afirmativamente a alguna de estas preguntas, debe invertir en una solución de disponibilidad.

Elección de una estrategia de disponibilidad

Puede elegir entre muchos enfoques diferentes para aumentar la disponibilidad, entre los que se incluyen:

  • Tolerancia a errores de componentes.

  • Redundancia y conmutación por error entre las funciones de servidor y las bases de datos en una granja de servidores.

  • Redundancia y conmutación por error entre granjas de servidores.

Requisitos del sistema para la disponibilidad

En un escenario ideal, los componentes de conmutación por error y los sistemas coinciden con los componentes principales y el sistema en todos los aspectos: plataforma, hardware y número de servidores. Como mínimo, el entorno de conmutación por error debe poder controlar el tráfico previsto durante una conmutación por error. Tenga en cuenta que es posible que el sitio de conmutación por error sólo pueda atender un subconjunto de usuarios. Los sistemas deben coincidir como mínimo en lo siguiente:

  • Versión del sistema operativo y todas las actualizaciones

  • Versiones de SQL Server y todas las actualizaciones

  • Versiones de Productos y Tecnologías de SharePoint y todas las actualizaciones

Aunque en este artículo se describe principalmente la disponibilidad de Productos y Tecnologías de SharePoint, el tiempo de actividad del sistema también se verá afectado por el resto de los componentes del sistema. Concretamente, tenga en cuenta lo siguiente:

Disponibilidad en una granja de servidores

Para admitir la disponibilidad en una granja de servidores, debe usar componentes con tolerancia a errores y funciones de servidores redundantes, y admitir la disponibilidad de bases de datos, ya sea en una agrupación en clústeres, una creación de reflejo de la base de datos o ambas.

Tolerancia a errores de componentes

En cualquier sistema, se recomienda colaborar con los proveedores de hardware para que aprovisionen hardware tolerante a errores que sea adecuado para el sistema, incluidas las matrices redundantes de discos independientes (RAID). Para obtener recomendaciones, vea Planeación de rendimiento y capacidad (Office SharePoint Server).

Al planear la tolerancia a errores de los componentes, tenga en cuenta lo siguiente:

  • La redundancia completa de todos los componentes en de un servidor puede no ser posible o poco práctica. Use servidores adicionales para lograr una redundancia adicional.

  • Considere la posibilidad de una redundancia de componentes para la función del servidor de índices, ya que dicha función no se puede convertir en redundante.

  • Asegúrese de que los servidores tienen varios sistemas de alimentación conectados a distintas fuentes de alimentación para conseguir una redundancia máxima.

Redundancia y conmutación por error entre las funciones de servidor en una granja de servidores

Productos y Tecnologías de SharePoint es compatible con las funciones del servidor en ejecución en equipos redundantes (es decir, ampliación de capacidad agregando mayor número de servidores) de una granja de servidores para aumentar la capacidad y mejorar el rendimiento, además de proporcionar disponibilidad básica. La capacidad y el rendimiento determinan el número de servidores y el tamaño de los servidores de una granja. Una vez cumplidos los requisitos básicos, es posible agregar servidores para aumentar la disponibilidad general del servicio.

Redundancia en una única granja de servidores

Disponibilidad de una única granja de servidores

En la siguiente tabla se describen los servicios y las funciones de servidor en un entorno de Productos y Tecnologías de SharePoint, tal y como se enumeran en la página Servicios del servidor del sitio web de Administración central de SharePoint, además de las estrategias básicas de redundancia que se pueden usar para cada uno de ellos en la granja de servidores.

Servicios del servidor Estrategia básica de redundancia preferida en una granja de servidores

Servidores web

Implementación en varios servidores y equilibrio de carga mediante software o equilibrio de carga de hardware.

Servidor web para granjas de servidores medianas (servicios de consulta de búsqueda y de aplicación web)

Implementación en varios servidores.

Indización de búsqueda

No se puede implementar en varios servidores y lograr que sea redundante. Debe usar una estrategia de disponibilidad diferente. Para obtener más información, vea Disponibilidad de la búsqueda en una granja de servidores.

Excel Calculation

Implementación en varios servidores.

Aplicación Project

Implementación en varios servidores.

Para obtener más información, vea Planeación de la redundancia (Office SharePoint Server).

Estrategias de disponibilidad de bases de datos para una única granja de servidores

La disponibilidad de las bases de datos en una granja de servidores se puede proporcionar con la agrupación en clústeres de SQL Server o la creación de reflejo de alta disponibilidad (también denominada creación de reflejo sincrónico) de SQL Server.

Agrupación en clústeres. La agrupación en clústeres de conmutación por error ofrece disponibilidad para una instancia completa de SQL Server. Un clúster de conmutación por error es una combinación de uno o más nodos o servidores con dos o más discos compartidos. Una instancia de clúster de conmutación por error se muestra como un equipo único, pero tiene una funcionalidad que proporciona la conmutación por error de un nodo a otro si el nodo actual no está disponible.

Dado que Office SharePoint Server 2007 hace referencia al clúster en su conjunto, la conmutación por error es automática y perfecta desde el punto de vista de Productos y Tecnologías de SharePoint.

Creación de reflejo sincrónico de la base de datos. La creación de reflejo de la base de datos ofrece compatibilidad con la disponibilidad mediante el envío directo de las transacciones desde una base de datos y un servidor principales a una base de datos y servidor reflejados siempre que el búfer del registro de transacciones de la base de datos principal se escriba en el disco. Se recomienda usar la creación de reflejo de la base de datos de alta disponibilidad, que se denomina también modo de alta seguridad con conmutación por error automática. La creación de reflejo de la base de datos de alta disponibilidad implica tres instancias de servidor: principal, reflejado y testigo. El servidor testigo permite que SQL Server conmute por error automáticamente del servidor principal al servidor reflejado. La conmutación por error de la base de datos principal a la base de datos reflejada suele tardar unos segundos.

Cada tecnología tiene ventajas y desventajas. La agrupación en clústeres es más fácil de implementar, pero puede resultar más cara. La creación de reflejo de SQL Server no se admite para bases de datos de Microsoft Office Project Server 2007.

En la siguiente tabla se compara el clúster de conmutación por error con la creación de reflejo de alta disponibilidad de SQL Server.

Clúster de conmutación por error de SQL Server Creación de reflejo de alta disponibilidad de SQL Server

El reflejo asume el control inmediatamente tras el error.

El reflejo asume el control inmediatamente tras el error.

Coherente en el nivel de transacción.

Coherente en el nivel de transacción.

Simultáneo en el nivel de transacción.

Simultáneo en el nivel de transacción.

Reducción del tiempo de recuperación (de segundos a minutos).

Leve aumento del tiempo de recuperación (de segundos a minutos).

Los nodos de la base de datos detectan automáticamente el error; Productos y Tecnologías de SharePoint hace referencia al clúster, por lo que la conmutación por error desde el punto de vista de Productos y Tecnologías de SharePoint es perfecta y automática.

Requiere scripting para lograr la conmutación por error de Productos y Tecnologías de SharePoint.

No protege contra el almacenamiento con errores, dado que el almacenamiento se comparte entre los nodos del clúster.

Protege contra el almacenamiento con errores porque los servidores de base de datos principal y reflejada escriben en discos locales.

Requiere un almacenamiento compartido más caro.

Puede usar almacenamiento de acceso directo (DAS), que resulta menos caro.

Se obtiene la misma subred.

Hasta 1 milisegundos (ms) en la latencia entre servidores de SQL Server y web.

Puede usar el modelo de recuperación simple de SQL Server, aunque el único punto de recuperación disponible si se pierde el clúster será la última copia de seguridad completa.

Requiere el modelo de recuperación completa de SQL Server.

No hay sobrecarga en el rendimiento.

Presenta latencia transaccional. Agrega una sobrecarga de memoria y procesador.

Mínima carga operativa.

Carga operativa adicional, incluido el scripting y la configuración de alias de SQL Server.

Para obtener más información acerca de la agrupación en clústeres, vea Configuración de disponibilidad en una única granja de servidores mediante la agrupación en clústeres de SQL Server.

Para obtener más información acerca de la creación de reflejos sincrónicos, vea Configuración de la disponibilidad en una única granja de servidores mediante la creación de reflejo de la base de datos de SQL Server y Uso de la creación de reflejo de la base de datos (Office SharePoint Server) (notas del producto).

Redundancia y conmutación por error entre centros de datos cercanos configurados como una única granja de servidores (granja “expandida”)

Algunas empresas tienen centros de datos próximos con conexiones de ancho de banda alto para poder configurarlos como una única granja de servidores. Esto se denomina granja "expandida". Para que una granja de estas características funcione, debe haber una latencia de menos de 1 milisegundo entre SQL Server y los servidores web en una dirección, y un ancho de banda de al menos 1 gigabit por segundo.

  • En este escenario, puede proporcionar redundancia para bases de datos de SharePoint con la creación de reflejo síncrona. Dentro de la granja expandida, puede crear un reflejo de la base de datos de configuración y de las bases de datos de contenido. Para ver un caso práctico sobre cómo una empresa usó una granja "expandida", vea Caso práctico de alta disponibilidad para SharePoint mediante la creación de reflejo de la base de datos (notas del producto).

  • Póngase en contacto con su proveedor de SAN para determinar si puede usar la replicación de SAN u otro mecanismo compatible para proporcionar disponibilidad en los centros de datos, como ejecutar SQL Server en clústeres de servidores dispersos geográficamente. Compruebe si la solución de replicación de SAN ofrece un nivel suficiente de simultaneidad y coherencia de transacciones.

En una granja de servidores expandida, se puede proporcionar tolerancia a errores para servidores de aplicaciones que ejecutan SSP mediante:

  • Varios servidores de consultas

  • Varios servidores que ejecutan Excel Calculation Services

El servidor de índices es un punto único de error en este escenario. Puede hacer una copia de seguridad y una restauración de la búsqueda o, si la simultaneidad de búsquedas tras la recuperación es muy importante, puede usar una granja de servidores del SSP de conmutación por error. Para obtener más información, vea Disponibilidad de la búsqueda en una granja de servidores.

Project Server es otro punto único de error en este escenario. Planee la copia de seguridad y la restauración de las bases de datos de Project Server.

Granja de servidores "expandida"

Granja de servidores "extendida"

Disponibilidad de la búsqueda en una granja de servidores

La función del servidor de índices no puede ser redundante en una granja de servidores. Las necesidades de la empresa de contar con una simultaneidad de búsquedas tras la conmutación por error podrían determinar la arquitectura lógica de la solución.

Si la empresa no requiere una simultaneidad de búsquedas y disponibilidad inmediatas tras la conmutación por error, puede hacer una copia de seguridad y restaurar el SSP de búsqueda en el sitio de conmutación por error.

Si la empresa requiere una simultaneidad de búsquedas y disponibilidad rápidas, puede usar uno de los métodos siguientes:

  • Arquitectura de granja de servidores única con dos SSP idénticos.

    Nota

    Si la empresa requiere simultaneidad de búsquedas y disponibilidad rápidas y se usan perfiles, los perfiles de los SSP de conmutación por error no estarán sincronizados con los perfiles de los SSP principales, sino que se encontrarán en el mismo estado en el que estaban cuando se importaron por primera vez. Para mantener sincronizados los perfiles en todos los SSP, se debe usar el motor de replicación de perfiles de usuario que se incluye con SharePoint Administration Toolkit de 32 bits (en inglés) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0xC0A) (en inglés) o SharePoint Administration Toolkit de 64 bits (en inglés) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0xC0A) (en inglés). Para obtener más información, vea el tema User Profile Replication Engine (Office SharePoint Server).

  • Una granja de servidores primaria centralizada que hospede la búsqueda y otros SSP. El servicio de búsqueda en la granja de servidores primaria rastrea el contenido de todas las demás granjas de servidores. Esta arquitectura sirve para admitir una o varias granjas de servidores.

Granja de servidores única con dos SSP

La siguiente arquitectura protege frente a un error del servidor de índices. En esta topología, los dos SSP rastrean el mismo contenido y usan las mismas reglas. El SSP de conmutación por error no está conectado al sitio web principal a menos que se produzca una conmutación por error.

Granja de servidores única con dos SSP

Granja de servidores con 2 SSP

Esta topología tiene las siguientes limitaciones:

La capacidad para rastrear conjuntos de datos de gran tamaño de forma oportuna se ve afectada por varios factores, entre los que se incluyen la latencia y el ancho de banda entre servidores de índices y servidores web.

En un entorno con un ancho de banda limitado, esta topología puede reducir considerablemente el rendimiento. Al rastrear el contenido dos veces, se cargan aún más los repositorios de contenido que se van a rastrear, lo que afecta al rendimiento de los repositorios. Es posible que también se vea afectada adversamente la capacidad de búsqueda para mantener el índice actualizado.

Granjas de servidores de SSP centralizadas

En la siguiente arquitectura, el uso de una granja de servidores primaria de SSP protege contra los errores de un servidor de índices. Aunque puede parecer una solución que requiere mucho hardware, las distintas granjas de servidores de SSP pueden compartir una parte del hardware, como el servidor de base de datos reflejada o agrupada en clústeres, siempre que los servidores de índices residan en servidores distintos. Para obtener más información sobre cómo planear y configurar granjas de servidores de SSP, vea Planeación de la arquitectura de SSP.

Esta topología tiene las siguientes ventajas:

  • La administración de SSP está centralizada.

  • Tras un error en una granja de servidores no es necesario volver a rastrear.

Granjas de servidores de SSP centralizadas

Granjas de servidores de conmutación por error del SSP

Esta topología tiene las siguientes limitaciones:

Redundancia y conmutación por error entre centros de datos con varias granjas de servidores

Puede configurar una granja de servidores de conmutación por error para proporcionar disponibilidad en un centro de datos independiente de la granja de servidores principal. Un entorno que cuente con una granja de servidores de conmutación por error independiente tiene las siguientes características:

  • En la granja de servidores de conmutación por error debe mantenerse una base de datos de configuración independiente y una base de datos de contenido de Administración central.

    Nota

    Si ha configurado la asignación alternativa de acceso para la granja de servidores principal, es especialmente importante configurarla de forma idéntica en la granja de servidores de conmutación por error.

  • Todas las personalizaciones se deben implementar en ambas granjas de servidores.

  • Las revisiones se deben aplicar a ambas granjas de forma individual.

  • La creación de reflejo asincrónica o el trasvase de registros a la granja de servidores de conmutación por error sólo se puede realizar correctamente con las bases de datos de contenido.

  • Las bases de datos reflejadas o cuyos registros se han trasvasado deben configurarse para usar el modelo de recuperación completa.

  • Se pueden hacer copias de seguridad y restaurar las bases de datos de Office Project 2007, incluidas las bases de datos del proyecto, en la granja de servidores de conmutación por error.

Póngase en contacto con su proveedor de SAN para determinar si puede usar la replicación de SAN u otro mecanismo compatible para proporcionar disponibilidad en los centros de datos.

Esta topología se puede repetir en muchos centros de datos si configura el trasvase de registros de SQL Server para uno o varios centros de datos.

Nota

La creación de reflejo de SQL Server sólo se puede usar con un servidor reflejado, pero se pueden trasvasar los registros a varios servidores secundarios.

Granjas de servidores principales y de conmutación por error antes de la conmutación por error

Granjas de servidores principal y de conmutación por error antes de la conmutación por error

En la siguiente tabla se enumeran los servicios y las funciones de servidor en un entorno de Productos y Tecnologías de SharePoint, y las estrategias básicas de redundancia que se pueden usar entre las granjas de servidores.

Servidor o función de servidor Estrategia básica de redundancia preferida entre granjas de servidores

SQL Server

Creación de reflejo de la base de datos asincrónica de SQL Server, trasvase de registros de SQL Server y otros mecanismos de replicación asincrónica.

Nota

No se puede usar para las bases de datos del SSP que hospedan información de búsqueda, ni para bases de datos de Project Server.

Servidores cliente web

Implementar en ambas granjas de servidores, incluidas las personalizaciones.

Servidor web para granjas de servidores medianas (servicios de consulta de búsqueda y de aplicación web)

Implementar en ambas granjas de servidores.

Indización de búsqueda

Implementar en ambas granjas de servidores. Recuperar la copia de seguridad de la granja de servidores original para moverla a la granja de servidores de conmutación por error.

Excel Calculation

Implementar en ambas granjas de servidores. Si el SSP no hospeda la búsqueda, puede usar la creación de reflejo de base de datos asincrónica, el trasvase de registros de SQL Server u otro mecanismo de replicación asincrónica para mover los datos a una granja de servidores de conmutación por error.

Si el SSP también hospeda la búsqueda, debe recuperar la copia de seguridad de la granja de servidores original para moverla.

Aplicación Project

Implementar en ambas granjas de servidores. Recuperar la copia de seguridad de la granja de servidores original para moverla a la granja de servidores de conmutación por error.

Disponibilidad de la búsqueda entre granjas de servidores

La búsqueda requiere la sincronización completa entre la base de datos de búsqueda, la base de datos del SSP y el índice. Debido a este requisito, la búsqueda no se puede replicar entre granjas de servidores mediante un mecanismo de replicación asincrónica (creación de reflejo de la base de datos asincrónica, trasvase de registros o replicación asincrónica de SAN).

Nota

Si está ejecutando un SSP sin búsqueda o Project, puede usar un mecanismo de replicación asincrónica para mover los datos.

Para permitir la búsqueda en una granja de conmutación por error, debe usar uno de los siguientes métodos:

  • Recupere una copia de seguridad del SSP de búsqueda para la granja de conmutación por error.

  • Use una granja de servidores primaria centralizada que hospede la búsqueda y otros SSP. El servicio de búsqueda de la granja de servidores primaria rastrea el contenido de las demás granjas de servidores.

Resumen

Revise detenidamente los requisitos de disponibilidad. Cuanto mayor sea el nivel de disponibilidad y el número de sistemas que hay que proteger, más compleja y costosa será una solución de disponibilidad con toda probabilidad.

Los costos necesarios para lograr la disponibilidad deberán evaluarse según las necesidades de la empresa. Probablemente no todas las soluciones de una organización requieran el mismo nivel de disponibilidad. Se pueden ofrecer distintos niveles para distintos sitios, servicios (por ejemplo, búsqueda e inteligencia empresarial) o granjas de servidores.

Agradecimientos

El equipo de publicación de contenido de Microsoft Office SharePoint Server agradece la participación de los siguientes revisores técnicos en este documento:

  • Bill Baer, Servicios en línea de Microsoft, SharePoint hospedado, arquitecto tecnológico

  • James Petrosky, Servicios de consultoría de Microsoft, consultor sénior

  • Steve Peschka, Servicios de consultoría de Microsoft, arquitecto sénior de IW

  • Dan Winter, Servicios de soporte al cliente de Microsoft, ingeniero de escalación

  • Sean Livingston, Productos y Tecnologías de Microsoft SharePoint, jefe de programa

  • Mike Watson, arquitecto tecnológico

  • Todd Carter, Ingeniería de Microsoft Premier Field, ingeniero jefe de Premier Field

  • Mike Plumley, Microsoft Office Project Server, redactor

  • Christophe Fiessinger, Microsoft Office Project, director sénior de producto técnico

  • Sid Shah, Microsoft Search, jefe de programa

  • Luca Bandinelli, Productos y Tecnologías de Microsoft SharePoint, jefe de programa

Descargar este libro

En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:

Vea también

Conceptos

Configuración de alta disponibilidad (Office SharePoint Server)