Exportar (0) Imprimir
Expandir todo

Descripción de la disponibilidad, la confiabilidad y la escalabilidad

 

Última modificación del tema: 2005-05-20

Aunque esta guía se centra principalmente en cómo lograr la disponibilidad, es importante que entienda también que la confiabilidad y la escalabilidad son componentes fundamentales para el diseño y la implementación de un sistema de mensajería de Exchange 2003 con alta disponibilidad.

En la comunidad de IT, la métrica empleada para medir la disponibilidad es el porcentaje de tiempo que un sistema es capaz de realizar las funciones para las que está diseñado. En lo que se refiere a los sistemas de mensajería, la disponibilidad es el porcentaje de tiempo que el servicio de mensajería está activo y en funcionamiento. Se emplea la fórmula siguiente para calcular los niveles de disponibilidad:

Percentage of availability = (total elapsed time - sum of downtime)/total elapsed time

La disponibilidad suele medirse en “nueves”. Por ejemplo, una solución cuyo nivel de disponibilidad sea de “tres nueves” es capaz de realizar su función prevista el 99,9 por ciento del tiempo, lo que equivale a un tiempo de inactividad anual de 8,76 horas por año sobre una base de 24x7x365 (24 horas al día, siete días a la semana, 365 días al año). En la tabla siguiente se muestran los niveles de disponibilidad frecuentes que muchas organizaciones intentan conseguir.

Porcentajes de disponibilidad y tiempo de inactividad anual

Porcentaje de disponibilidad Día de 24 horas Día de 8 horas

90%

876 horas (36,5 días)

291,2 horas (12,13 días)

95%

438 horas (18,25 días)

145,6 horas (6,07 días)

99%

87,6 horas (3,65 días)

29,12 horas (1,21 días)

99.9%

8,76 horas

2,91 horas

99.99%

52,56 minutos

17,47 minutos

99,999% (“cinco nueves”)

5,256 minutos

1,747 minutos

99.9999%

31,536 segundos

10,483 segundos

Desgraciadamente, la medida de la disponibilidad no es tan sencillo como seleccionar uno de los porcentajes de disponibilidad que se muestran en la tabla anterior. Debe decidir primero qué métrica desea utilizar para calificar el tiempo de inactividad. Por ejemplo, una organización puede considerar que se produce tiempo de inactividad cuando una base de datos no está montada. Otra organización puede considerar que sólo se produce tiempo de inactividad cuando más de la mitad de sus usuarios se ven afectados por una interrupción del servicio.

Además, los requisitos de disponibilidad deben establecerse en el contexto del servicio y de la organización que utiliza el servicio. Por ejemplo, los requisitos de disponibilidad para los servidores que alojan datos de carpetas públicas que no son críticos pueden ser inferiores que los de los servidores que contienen bases de datos de buzones fundamentales para la empresa.

Para obtener información acerca de las métricas que puede utilizar para medir la disponibilidad, y de cómo establecer requisitos de disponibilidad basándose en el contexto del servicio y en los requisitos de la organización, consulte Establecimiento de objetivos de disponibilidad.

Las medidas de confiabilidad suelen utilizarse para calcular la probabilidad de que se produzca un error en un único componente de la solución. Una medida empleada para definir la confiabilidad de un componente o del sistema es el tiempo medio entre errores (MTBF). El MTBF es el intervalo de tiempo promedio, normalmente expresado en miles o en decenas de miles de horas (a veces llamadas horas de encendido o POH), que transcurre hasta que se produce un error en un componente y es preciso repararlo. El MTBF se calcula mediante la ecuación siguiente:

MTBF = (total elapsed time - sum of downtime)/number of failures

Una medida relacionada es el tiempo medio de reparación (MTTR). El MTTR es el intervalo de tiempo promedio (normalmente expresado en horas) que se tarda en reparar un componente que ha sufrido un error. La confiabilidad de todos los componentes de la solución (por ejemplo, hardware de servidor, sistema operativo, software de aplicación y funciones de red) puede afectar a la disponibilidad de una solución.

Un sistema es más confiable si es tolerante a errores. La tolerancia a errores es la capacidad de un sistema para seguir funcionando cuando se produce un error en parte del sistema. Para conseguir tolerancia a errores hay que diseñar el sistema con un alto grado de redundancia de hardware. Si se produce un error en un único componente, el componente redundante asumirá su función sin que se produzca un tiempo de inactividad apreciable. Para obtener más información acerca de los componentes de tolerancia a errores, consulte Cómo hacer que su organización de Exchange 2003 sea tolerante a errores.

En las implementaciones de Exchange, la escalabilidad es la medida de la capacidad de crecimiento de un servicio o de una aplicación para satisfacer demandas de rendimiento cada vez mayores. Cuando se aplica a la tecnología de clústeres de Exchange, la escalabilidad es la posibilidad de agregar equipos incrementalmente a un clúster existente cuando la carga global del clúster supera las capacidades del mismo para ofrecer un rendimiento adecuado. Para satisfacer las demandas de mayor rendimiento de su infraestructura de mensajería se pueden implementar dos estrategias de escalabilidad: vertical u horizontal.

El escalado vertical implica aumentar los recursos del sistema (como procesadores, memoria, discos y adaptadores de red) al hardware existente o reemplazar hardware existente por otro con mayores recursos de sistema. El escalado vertical es idóneo cuando se desea mejorar el tiempo de respuesta de los clientes, como en una configuración de Equilibrio de carga de red (NLB) de un servidor de aplicaciones para usuario de Exchange. Por ejemplo, si el hardware actual no ofrece un rendimiento adecuado para los usuarios, puede considerar la posibilidad de agregar memoria RAM o unidades centrales de procesamiento (CPU) a los servidores del clúster NLB para satisfacer esa demanda.

Windows Server 2003 es compatible con una o varias CPU que cumplan el estándar de multiprocesamiento simétrico (SMP). Mediante SMP, el sistema operativo puede ejecutar subprocesos en cualquier procesador disponible, lo que permite que las aplicaciones utilicen varios procesadores cuando se necesite mayor capacidad de procesamiento para aumentar las capacidades de un sistema.

El escalado horizontal implica agregar servidores para atender a la demanda. En un clúster de servidor de servicios de fondo, esto significa agregar nodos al clúster. En una situación NLB de aplicaciones para usuario, significa agregar equipos al conjunto de servidores de protocolo de aplicaciones para usuario de Exchange 2003. El escalado horizontal también es adecuado cuando se desea mejorar el tiempo de respuesta de los clientes con los servidores.

Para obtener información acerca de la escalabilidad en lo que respecta a las soluciones de clúster de servidor, consulte “Consideraciones de rendimiento y escalabilidad” en Consideraciones de diseño de la organización en clústeres.

Para obtener información detallada sobre la selección de hardware y el ajuste de Exchange 2003 para rendimiento y escalabilidad, consulte la Exchange Server 2003 Performance and Scalability Guide.

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft