Planeación de la tolerancia a errores y disponibilidad en Project Server 2007
Actualizado: octubre de 2008
Última modificación del tema: 2015-02-27
Los términos "tolerancia a errores" y "disponibilidad" hacen referencia a la capacidad de un entorno de varios servidores para aceptar conexiones y funcionar normalmente incluso cuando alguno de los componentes de la granja de servidores no está operativo. La disponibilidad implica redundancia y podría incluir además un mecanismo de conmutación por error y algunas otras características.
Puede usar las siguientes estrategias para mejorar la tolerancia a errores de la implementación de Microsoft Office Project Server 2007:
Agrupación en clústeres
Redundancia de hardware
Configuraciones de RAID
Redundancia de función del servidor
Trasvase de registros
Servidores en espera
En este artículo se proporciona más información acerca de cada una de estas estrategias. Estas estrategias se pueden aplicar individualmente o combinadas. Puesto que cada estrategia conlleva un costo, es importante examinar la relación entre costos y ventajas de cada una de ellas antes de aplicarla en su organización.
Disponibilidad
Se recomienda tener en cuenta los requisitos de disponibilidad como parte del diseño principal de la solución Office Project Server 2007. 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.
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.
| Porcentaje de tiempo activo aceptable | Tiempo de inactividad por día | Tiempo de inactividad por mes | Tiempo de inactividad por año |
|---|---|---|---|
95 |
72 minutos |
36 horas |
18 días |
99 |
14 minutos |
7 horas |
4 días |
99.9 |
86 segundos |
43 minutos |
9 horas |
99,99 |
8,6 segundos |
4 minutos |
53 minutos |
99,999 |
0,8 segundos |
26 segundos |
5 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:
% 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:
Agrupación en clústeres
La agrupación en clústeres puede proteger el sistema frente a errores de aplicaciones o del sistema operativo. También se pueden realizar muchas tareas en equipos agrupados en clúster sin tener que desconectarlos, entre ellas, la actualización de una aplicación o del sistema operativo, y la instalación de un Service Pack o una actualización.
Los clústeres de servidores están diseñados para mantener las aplicaciones disponibles, no para proteger los datos. Para protegerse contra virus, daños y otras amenazas contra los datos, necesitará planes sólidos de protección y recuperación de los datos. La tecnología de clúster no puede proteger frente a errores provocados por virus, daños en el software o errores humanos.
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.
Redundancia de hardware
Puede proporcionar alguna tolerancia a errores en su implementación de Office Project Server 2007 mediante la implementación de configuraciones de hardware adicionales que dupliquen la configuración de hardware de su organización. De este modo, si se produce un error en una ruta de datos de entrada y salida (E/S) o en los componentes de hardware físicos de un servidor (como un equipo, la red y los componentes de red de área de almacenamiento), el sistema no se verá afectado. El hardware que use para reducir los puntos de error únicos variará en función de los componentes que desee que sean redundantes. Los proveedores de hardware suelen incluir hardware duplicado como parte de su solución de almacenamiento.
Configuraciones de RAID
Con una matriz redundante de discos independientes (RAID) puede aumentar la tolerancia a errores de la implementación de Office Project Server 2007. RAID almacena datos idénticos en varios discos para obtener redundancia, mejorar el rendimiento y aumentar el tiempo medio entre errores (MTBF). En una configuración RAID, parte de la capacidad de almacenamiento físico contiene información redundante sobre los datos almacenados en los discos duros. La información redundante es información de paridad (en el caso de un volumen RAID-5), o es una copia completa e independiente de los datos (en el caso de un volumen reflejado). La información redundante permite regenerar los datos si se produce un error en uno de los discos o en la ruta de acceso, o si no se puede leer un sector del disco.
Para asegurarse de que los equipos que ejecutan Office Project Server 2007 sigan funcionando correctamente en caso de que se produzca un error en un solo disco, puede usar la creación de reflejo de discos o el seccionado de discos RAID con paridad en los discos duros de la implementación de Office Project Server 2007. La creación de reflejo de disco y el seccionado de disco con paridad crean datos redundantes en los discos duros.
Las bases de datos de Office Project Server 2007 hacen un uso intensivo de E/S. Por este motivo, se recomienda RAID 10 para obtener un rendimiento óptimo y redundancia de las unidades que contienen las bases de datos Office Project Server 2007.
El uso de configuraciones RAID no impide que los archivos se dañen ni que se produzcan otros errores de archivo. Por este motivo, el uso de configuraciones RAID no debe sustituir la creación de copias de seguridad actualizadas de los datos importantes de los servidores.
Dado que los archivos de registro de transacciones y los archivos de base de datos son críticos para el funcionamiento de los equipos que ejecutan Office Project Server 2007, puede mantenerlos en discos físicos independientes. También puede usar la creación de reflejo de discos o el seccionado de discos RAID con paridad para evitar que la pérdida de un solo disco duro físico provoque un error en la base de datos de Office Project Server 2007.
Si su entorno contiene una red de área de almacenamiento (SAN), es posible que ya tenga la redundancia de disco que necesita en su implementación. En un entorno SAN, se recomienda no colocar la implementación de Office Project Server 2007 y sus componentes asociados en el mismo eje de discos que otras aplicaciones que hacen un uso intensivo de E/S, ya que podría provocar una degradación del rendimiento. Los datos de Office Project Server 2007 están optimizados para lecturas secuenciales, lo que los hace ideales para un entorno SAN.
Redundancia de función del servidor
La topología de servidores de línea de base que elija dependerá de los requisitos para conseguir redundancia de las funciones de servidor de aplicaciones. En esta sección se describen las funciones de servidor de aplicaciones relacionadas con sus opciones de disponibilidad.
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.
Trasvase de registros
Con Microsoft SQL Server, puede usar el trasvase de registros para transferir los registros de transacciones de una base de datos a otra. Al realizar continuamente copias de seguridad de los registros de transacciones de una base de datos de origen y, a continuación, copiar y restaurar los registros en una base de datos de destino, se consigue mantener la base de datos de destino sincronizada con la base de datos de origen. El trasvase de registros es un método automatizado para mantener un servidor en espera.
Servidores en espera
Un servidor en espera es un segundo servidor que se puede conectar si se produce un error en un servidor de producción principal. Los mismos componentes de software que están instalados en el servidor principal se instalan en el servidor en espera. El uso de un servidor en espera permite a los usuarios continuar trabajando con los datos de Office Project Server 2007 si el servidor principal deja de estar disponible.
También se puede usar un servidor en espera cuando un servidor principal no está disponible debido al mantenimiento programado. Por ejemplo, si debe desconectar el servidor principal para una actualización de hardware o software, puede usar el servidor en espera hasta que el servidor principal se conecte de nuevo.
El factor más importante a tener en cuenta para usar servidores en espera es que las actualizaciones de hardware, software y firmware en un servidor en espera deben ser idénticas a las del servidor principal al que reemplazará el servidor en espera.
Si el servidor en espera es un servidor de base de datos, debe contener una copia de las bases de datos del servidor principal. Si desconecta el servidor principal y se conecta el servidor en espera, cuando el servidor principal se vuelva a conectar, los cambios realizados en las copias de la base de datos que se encuentran en el servidor en espera deben copiarse al servidor principal. De lo contrario, se perderán los cambios. Cuando los usuarios comiencen a usar el servidor principal de nuevo, será necesario realizar una copia de seguridad de las bases de datos del servidor principal y copiarlas en el servidor en espera.
El trasvase de registros se usa para garantizar que el servidor en espera permanecerá sincronizado con el servidor principal. Si se produce un error en el servidor principal o incluso si se produce un error sólo en una base de datos, las bases de datos del servidor en espera podrán estar disponibles para los procesos de usuario. Los procesos de usuario que no puedan tener acceso al servidor principal deben usar el servidor en espera en su lugar.
Si tiene diferentes servidores cliente web como parte de su implementación, puede instalar el servicio de la aplicación Project en ellos y dejarlos desactivados. Después, en caso de error de uno de los servidores de Office Project Server 2007, puede activar el servicio de la aplicación Project en el servidor cliente web para conectar fácilmente un servidor en espera.