Planeación de la tolerancia a errores y disponibilidad en Project Server 2007

Definición de disponibilidad

La disponibilidad es el grado en que un sistema como Office Project Server 2007 es percibido como disponible por los usuarios. Asegurar la disponibilidad significa asegurar que un sistema es resistente, es decir, que presenta pocos incidentes que afecten al servicio y que, cuando estos suceden, se llevan a cabo acciones efectivas e inmediatas. Las estrategias de disponibilidad minimizan la percepción de los usuarios de los tiempos de inactividad planeados y no planeados.

Una de las formas más habituales de medir la disponibilidad es el porcentaje de tiempo activo expresado como número de nueves; es decir, el porcentaje de tiempo durante el cual un determinado sistema permanece activo y en funcionamiento. Por ejemplo, se considera que un sistema con un porcentaje de tiempo activo 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.

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:

• 
  % tiempo de actividad/año = 100 – (8760 – número total de horas de inactividad por año)/8760

• 
  % tiempo de actividad/mes = 100 – ([24 * número de días del mes] – número total de horas de inactividad en ese mes de calendario)/(24 * número de días del mes)

• 
  % tiempo de actividad/semana = 100 – (168 – número total de horas en esa semana)/168

Definición de lo que no es la disponibilidad

La disponibilidad no es la protección ni la recuperación de datos, ni es la recuperación ante desastres. Debe disponer de planes independientes de protección de datos y de recuperación ante desastres en cualquier sistema de alta disponibilidad.

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 las crisis. Una crisis puede ser local, regional o nacional, o bien estar sólo relacionada con su negocio.

Costo 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 de 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 para establecer las expectativas con los grupos de clientes. Muchas organizaciones de TI ofrecen diversos contratos de nivel de servicio asociados con distintos niveles de facturación.

Acerca de la redundancia

La redundancia es una parte clave de la disponibilidad. Incluye el uso de varios servidores en un entorno de equilibrio de carga para mejorar el rendimiento de la granja de servidores o para escalar en horizontal para dar cabida a más usuarios. La redundancia también incluye el uso de componentes de copia de seguridad idénticos, como sistemas de alimentación o equipos de red, para ofrecer funcionalidad continuada en caso de error en el componente principal.

En este artículo se describe cómo implementar servidores redundantes en una granja de servidores de Office Project Server 2007.

Office Project Server 2007 admite granjas de servidores escalables para capacidad, rendimiento y disponibilidad. Normalmente, la capacidad es la primera consideración a la hora de determinar el número inicial de equipos servidor. 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 equipos servidor de una granja de servidores.

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 siguientes preguntas para el sitio, servicio o granja de servidores.

• Si Office Project Server 2007 deja de estar disponible, ¿los empleados de su organización podrán llevar a cabo sus responsabilidades laborales?

• Si Office Project Server 2007 deja de estar disponible, ¿se detendrán las transacciones comerciales y de relaciones con los clientes, con las consiguientes pérdidas que ello supone en ambos ámbitos?

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

Aunque en este artículo se describe principalmente la disponibilidad de Office Project Server 2007, el tiempo de actividad del sistema también se verá afectado por el resto de los componentes del sistema. En particular, tenga en cuenta lo siguiente:

Debe asegurarse de que las dependencias de infraestructura como la electricidad, la refrigeración, la red, el directorio y SMTP sean totalmente redundantes.

Elija un mecanismo de conmutación para el sistema, ya sea DNS o equilibrio de carga del hardware, que se ajuste a sus necesidades. En los siguientes artículos encontrará los procedimientos recomendados para servidores web de equilibrio de carga:

• Diseño empresarial para el equilibrio de carga (en inglés) (https://go.microsoft.com/fwlink/?linkid=122194\&clcid=0xC0A) (en inglés)

• Diseño empresarial para DNS (en inglés) (https://go.microsoft.com/fwlink/?linkid=122196\&clcid=0xC0A) (en inglés)

Clúster de conmutación por error de SQL Server

Los clústeres de conmutación por error están diseñados para aplicaciones con estado. Las aplicaciones con estado tienen un estado en la memoria de ejecución prolongada o tienen estados de datos grandes que se actualizan con frecuencia.

Los clústeres de conmutación por error proporcionan alta disponibilidad ya que permiten la conmutación por error de los recursos. Los clústeres de conmutación por error también mantienen conexiones de cliente con las aplicaciones y servicios.

En los clústeres de conmutación por error, los nodos comparten el acceso a los datos. Pueden ser nodos activos o pasivos, y su configuración depende del modo operativo (activo o pasivo) y de cómo se configure la conmutación por error en el clúster. Un servidor designado para administrar la conmutación por error debe tener un tamaño adecuado para administrar la carga de trabajo del nodo con error, además de su propia carga de trabajo.

En las implementaciones de Office Project Server 2007, puede usar clústeres de conmutación por error con SQL Server.

Clústeres con equilibrio de carga

Los clústeres con equilibrio de carga son grupos de equipos idénticos, normalmente clonados, que sirven para mejorar la disponibilidad de los servidores web, servidores de Microsoft Internet Security and Acceleration (ISA) (servidores proxy y servidor de seguridad) y otras aplicaciones que reciben tráfico del Protocolo de control de transmisión (TCP) y Protocolo de datagramas de usuario (UDP). Debido a que los nodos del clúster normalmente son clones idénticos entre sí y, por lo tanto, pueden funcionar de forma independiente, todos los nodos de un clúster están activos.

Office Project Server 2007 admite dos métodos de equilibrio de carga:

• Software, como los servicios de equilibrio de carga de red (NLB) del sistema operativo de Microsoft Windows Server 2003. NLB se ejecuta en los servidores cliente web y usa TCP/IP para enrutar las solicitudes. Dado que NLB (y otras soluciones de equilibrio de carga de software) se ejecuta en los servidores cliente web, usa los recursos del sistema cliente web, lo que reduce los recursos que puede emplear para dar servicio a páginas web. Sin embargo, el impacto sobre los recursos del sistema no es importante, y una solución de software puede controlar hasta 32 servidores cliente web.

• Hardware, como un enrutador o una caja de distribución. El hardware de equilibrio de carga usa la red para dirigir el tráfico del sitio web entre los servidores cliente web. El hardware de equilibrio de carga es más caro de instalar que el software, pero no afecta a los recursos del servidor cliente web. Office Project Server 2007 se puede usar en 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). Este método puede emplear un volumen significativo de recursos en los servidores cliente web, es más lento que el equilibrio de carga de software o hardware y no se recomienda usarlo con Office Project Server 2007. Además, el equilibrio de carga por turnos con DNS no tiene en cuenta la carga de la sesión al enrutar un usuario a un servidor, lo que puede provocar la sobrecarga del servidor.

Funciones que pueden ser redundantes

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

El servicio de la aplicación Project de Office Project Server 2007 se puede implementar de manera redundante. Esto permite obtener un mayor rendimiento para las solicitudes de datos de PWA y puede aumentar la capacidad de la implementación. Sin embargo, implementar el servicio de la aplicación Project en varios servidores no aumenta la disponibilidad de la granja de servidores. En caso de error en uno de los servidores, la granja no detectará automáticamente el error y continuará enviando solicitudes al servidor del servicio de la aplicación Project con error hasta que se quite manualmente de la granja.

Funciones que no pueden ser redundantes

Algunas funciones del servidor de aplicaciones que puede habilitar en Office Project Server 2007 no pueden ser redundantes, como la búsqueda de Windows SharePoint Services 3,0. Esta función del servidor de aplicaciones se puede implementar en varios servidores; sin embargo, éstos no son redundantes. Esta función de servidor está configurada para rastrear contenido y generar índices de contenido. Si se implementa en varios servidores, cada servidor rastreará contenido diferente.

Redundancia del servidor de base de datos

La función de servidor de base de datos afecta más a la disponibilidad de su solución que ninguna otra función. En caso de error en el servidor web o en el servidor de aplicaciones, estas funciones pueden restaurarse y volver a implementarse rápidamente. Sin embargo, en caso de error en el servidor de base de datos, su solución depende de que se restaure el servidor de base de datos. En esta operación se puede incluir la regeneració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. Además, la solución dejará de estar disponible durante el tiempo que se tarde en restaurar la función de servidor de base de datos.

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 RAID.

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

• La redundancia completa de todos los componentes de un servidor podría no ser posible o práctica. Use servidores adicionales para lograr más redundancia.

• 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.